Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)
Le 16 mai 08 à 13:48, Martin Uecker a écrit :
"Kevin B. McCarty" <email@example.com> wrote:
If you see packages for which a Debian-specific patch seems
please by all means file a bug (severity wishlist) requesting that
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?
I personally often discuss the patches with my upstream (but then,
they're really responsive). Most of the time they apply it to their
CVS, and I backport their patch (generally improved over my
approach). If a patch fixes a real bug and looks simple enough that's
its unlikely to break anything, I think it's useful. Other patches
are not supposed to go to upstream, because they are just meant to
implement the Debian policy (also I generally tell upstream anyway,
to have their opinion).
Of course you need to define "simple enough", and "unlikely" (for
openssl, you want it to be _very_ unlikely). I agree with you that
patching should be kept to a minimum : back-porting bug fixes and
implementing Debian policy (even there, I would try to not overdo it,
but a "must" in policy is a must).
By the way, Debian policy is not completely silly, so even those
patches can often go to upstream and be shared with the other
distributions, of be configurable at build time. For instance, my
main package, yorick, traditionally expects user files to be in ~/
Yorick/. Those files can be considered configuration or data, that
really depends on the user. I've triggered a discussion on the matter
that configuration files in a user's home directory should be stored
in hidden files or directories (that's from the FHS). Yorick now
looks at both ~/.yorick/ and ~/Yorick/, so the user can choose. I was
motivated by abiding by Debian policy, but the change was made
upstream, to avoid a fork. If upstream had rejected the idea, I'm not
sure what I would have chosen. I tend to believe the right thing to
do here was to avoid a fork at all cost, but others may disagree.
Let's hope this discussion will, in the end, bring good ideas and
trigger actual work to improve Debian, and perhaps the free software
community at large.
Best regards, Thibaut.