2008/5/16 Thibaut Paumard [EMAIL PROTECTED]:
the topic has already been changed to ssl security desaster, and in my
opinion this is precisely what my post is about: what can we learn from this
disaster. (More precisely, I'm giving my 2c on what level of patching is
acceptable in a Debian package. Since the disaster allegedly originates in
abusive patching, this is relevant).
I disagree. The cause of the disaster was not that Debian does its own
patching, but the fact that that patch was buggy. On the whole I think
that Debian benefits a lot from custom patches, and in fact many
packages would be severely buggy and/or wouldn't integrate properly
with the rest of the system without them. It's not a secret that many
projects benefit from Debian patches, so there might be something good
with them. Also, I don't think we should always wait for upstream's
new releases for adding them if we have them available. It might
depend on every case.
Maybe there's a problem with the fact that some of those patches are
just reviewed by just one person, but then again, I seriously think
that it would have been quite difficult to discover that there was a
problem with this one. The proof that it wasn't evident is not only
that upstream didn't see the problem either, nor any other developer
or derivative distribution or independent reviewers in 2 years.
I think that defending the position of using pristine upstream source
code are just a conservative position to guarantee that we can blame
upstream or someone else if something like this happens again, not
that bugs won't happen. Only those who don't do anything don't make
mistakes. The point is to try to avoid mistakes, not to be able to
blame upstream. Of course, the development and checking of the patches
should be done as cooperatively with upstream as possible, as upstream
might see something we're not seeing, but the way to the solution, in
my opinion, is not to avoid patching but to develop a way to check
them as extensively as possible. Maybe there should also be a
clasification of packages according to how bad would a bug be in them
for the whole system, so that patches in those could be more carefully
reviewed.
Greetings,
Miry
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
