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

Re: ssl security desaster

Hi Mikhail,

Mikhail Gusarov wrote:

> Twas brillig at 10:30:44 15.05.2008 UTC-07 when Kevin B. McCarty did gyre and gimble:
>  KBM> Believe me, there are lots of upstreams for which extensive
>  KBM> patching really is necessary.  (I have no idea whether OpenSSL is
>  KBM> one of those, as I have no familiarity with its code nor the
>  KBM> Debian packaging of it.)
> Probably the work then should be clearly labeled as fork (especially
> given the other distro maintainers also share some patches)? It will
> reduce the confusion, like "oh, erm, our <foo> is not quite upstream
> <foo>, we rewrote it from scratch, and left the name and this cute
> logo".

I'm not sure if you are addressing me specifically, or just maintainers
in general who have a large patch set.

I don't view my maintainership of cernlib, paw, etc. as a fork in the
same sense that, say, X.org is from XFree86 or Xemacs from Emacs.  (In
the most technical sense, *all* Debian packages are forks of upstream,
though in some happy cases the only difference is a little added
packaging infrastructure, and Debian users are generally aware of this.)
 My patches, if somewhat extensive, are still at most a few percent of
the total size of upstream's code, so there is no rewriting from scratch
going on.

I've also tried to make it very clear through README.Debian files, FAQ
web pages, etc. how the software in Debian behaves differently from
upstream's original version in the cases where the difference is visible
to the end user.

I have zero desire to be considered as cernlib upstream myself -- that
would imply that the software was supported at a level that I am not
able to guarantee.  If my upstream were to reanimate (or someone else
took over upstream), I'd happily continue to package new releases from
them, keeping any of my patch set that continued to be necessary that
they wouldn't themselves accept.

Mainly, I see my packaging of this software as a caretaker effort that
makes it possible for people to install it with a minimum of trouble,
while being able to expect that it follows Debian policy and has some
chance of getting fixes for reported bugs.  If some future change to the
operating system occurred that broke cernlib in a hard-to-fix way, I
would be much more likely to orphan the package and request its removal
from Debian than to try to make big changes to the architecture of the
software.  Doing the latter, IMO, *would* deserve to be called a real fork.

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: