[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ssl security desaster



Hi Martin,

Martin Uecker wrote:
> "Kevin B. McCarty" <kmccarty@debian.org> wrote:
> 
>> If you see packages for which a Debian-specific patch seems unnecessary,
>> please by all means file a bug (severity wishlist) requesting that the
>> patch be either reverted or submitted upstream. 
> 
> Most time the patch is already submitted upstream, but not yet applied
> or released. If you look into the Debian changelogs you find a lot of
> "drop XXX patch, applied upstream". This is done to bring the fix
> faster to the user. The question is, is this worth it? Maybe it is,
> but only for certain patches? Is there a policy?

Well, *assuming* the patch is good, a subset of users of the software
(i.e. Debian users and users of downstream distributions) benefit from
it between the time it's applied in Debian and the time it's applied
upstream, and there are no major negatives that I can think of.

But that assumption is what you really want to discuss, I guess.  As far
as I know, Debian policy is silent about when to apply a patch or how to
decide if it's good.  If upstream is responsive, it might make sense to
wait until someone from there reviews the patch and gives a thumbs-up or
-down.  That supposes it is clear how to get in touch with upstream,
which I gather was one of the big mis-communications leading to the
current state of affairs [1].

[1] http://advogato.org/person/branden/diary/5.html

>> Speaking only for myself, let me comment on some "extensive patching".
>> I guess that some of my physics-related packages (cernlib, paw) are
>> among the more heavily patched in Debian.  Unfortunately upstream is
>> dead, so there is *no way* to see the patches incorporated there.
> 
> As other have already pointed out: In this case, it should be
> considered a fork.

It's really just an argument over semantics.  I personally think of a
"real" fork as one where someone purports to have taken over the role of
upstream.  You're welcome to have a different opinion (clearly you do).
The XFree86 4.3.0 that Debian shipped with Sarge was also extremely
heavily patched from the upstream version, but I don't believe most
people thought of it as a "real" fork (unlike X.org).

>> And even before they gave up the ghost, they were very conservative,
>> refusing to consider most patches more complicated than trivial changes
>> to fix complete breakage.
> 
> Open source development does work well only if splitting up the
> development in different branches or even forks is strongly
> avoided and done only if it is strictly necessary. IMHO the
> Debian way of doing things makes it far too easy for package
> maintainers to diverge from the upstream source. I can't really
> comment on the examples you have provided, but in general, I feel
> that Debian has not found the right balance here.

At least for the example of my packages that I brought up, if I could
not make an extensive set of patches, it is unlikely that the software
could have met the policy and quality standards to be accepted into
Debian.  Whether it's better for Debian to ship heavily-patched software
(that is still quite popular in the physics community) from a dead
upstream, or not to ship it at all (forcing users to download it on
their own from upstream's web site, then find and apply some set of
patches grabbed from elsewhere on the web [2,3], then going through a
baroque and obsolete build procedure [4]) is of course open for debate.
You can guess that I hold the former of these opinions.

[2] http://www.public.asu.edu/~comfort/cernlib.html
[3] http://www-zeuthen.desy.de/linear_collider/cernlib/new/cernlib_2005.html
[4] http://cernlib.web.cern.ch/cernlib/install/install.html

One could certainly envision a distribution that used a Debian-like
packaging infrastructure, but had a goal of trying to deviate from
upstream's source code as little as possible.  I think that such a
distribution would either have serious QA problems (think for instance
of embedded code copies, a security nightmare) or would be restricted to
packaging a much smaller set of software than Debian does. YMMV.

best regards,

-- 
Kevin B. McCarty <kmccarty@gmail.com>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: