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

Re: ssl security desaster

Hi Kevin!

"Kevin B. McCarty" <kmccarty@debian.org> wrote:
> Martin Uecker wrote:


> 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. 

I think it is problematic even if the patch is good, because
having different software branches fragments all kind of
bug fixing/development and reviewing work, which could
otherwise be shared upstream.

> 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

This might be part of the problem, but there was discussion with other
upstream developers on openssl-dev. So the problem was not that there 
was no communication, but that the actual patch was not forwarded
to the upstream developers.


> > 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).

I guess you are right, it's not a fork, more like a branch.
I could imagine that there are good reasons for having a Debian 
branch for something like X, but I don't think this is true
for many packages.


> 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.

Surely, this is very valuable work and I am not implying
at all that you should stop it. But if upstream is dead, then their is
no reason not to step in and simply take ownership of the package.
Traditionally, if upstream was dead, somebody formally declared
ownership of the software and took over development. I think this
is the right thing to do, because then there is a new upstream where
all other work can be shared.

If upstream is incompetent, that somebody can step in and fork
the software. Again, with a clear announcement. Then this step
can be discussed openly and other users might switch over to
the fork. Just integration all changes which are not accepted
upstream as part of the packaging work just makes it too easy
to diverge from upstream without good reason, without discussion
and without an easy way for other users/distributions to see
whats going on and to eventually switch over.

> 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.

I don't now. I see no reason why all this good work which now
ends up in Debian patches can't be seperated from the actual
packaging work.


Attachment: signature.asc
Description: Digital signature

Reply to: