DSA-1571 is totally embarrassing. But I disagree with Julien BLACHE: we don’t need a new openssl maintainer. Mistakes sometimes happen to people who do things. That sucks, but it’s unavoidable, no matter how many levels of checking you add. Kurt has done a lot of excellent work on Debian in the past years, and I’m sure he will continue.
Of course, it’s a lot easier and less risky to write tons of stupid blog posts.
By the way, Julien, there’s an RFH bug for openssl open for more than 2 years. What about getting involved and helping Kurt yourself?
On a more constructive side: it’s not the first time that a Debian-specific change broke something (I can think of a recent grep change …). It might be useful to provide a simpler way to review those changes (reading the diff.gz files is not really user-friendly). We could have something like http://patches.ubuntu.com/ (or even something nicer :-).
This is not a mistake. This is sheer, unadulterated idiocy. It’s on par with surrounding the body of the
main()function with a cute pair of#if 0 /* prevent segfaults */and#endif. Doubly so when presented with a patch that clearly remedies the issue!It is my personal opinion that the person responsible should be kicked in the beanbag with a steel-capped boot, and then ejected from OpenSSL maintainership. If not, he will simply go ahead and crap all over a well-audited (OpenBSD ring a bell?) code base like a rabid, diarrhoeic chimpanzee. Again.
And what the butt is it with this finger-pointing? “Well your blog entries are stupid! And you smell bad!” is what comes across. The openssl maintainer made a series of stupid damned errors in judgement and as a result, hundreds if not thousands of working hours will be wasted hunting down defective RSA/DSA keys. Calling for everyone to play nicey-nicey is NOT the way to go here.
As a user I just want to know what’s being done to make sure nothing like this happens again.
I don’t care how long releases take, there need to be audits for this kind of thing. If that means developers need to be paid to do the work, I’ll be glad to chip in a little bit. I bet canonical and other groups that sell support for these packages would be too.
Debian maintainers should learn their lessons that “Upstream knows better” and stop thinking they are smarter than everyone else and apply stupid patches. I suggest to follow a simple policy of only applying patches coming from upstream unless there is a very pressing reason (security mostly). And please please never apply a patch before first trying to contact upstream and getting their opinion.. And listen to their opinions!
Human beings are inherently fallible. Having a go at the maintainer is pointless. He’s made a very public mistake and no doubt feels bad enough already. I hope he’s handling it ok.
I think it’s a matter of process as much as anything. Security critical modules really should have more oversight so that something like this can’t happen and only have one persons name against it.
Perhaps Ubuntu also has a role to play here. For security critical pieces of software they should have the resources to have reviewed these changes and caught them earlier rather than simply sucking in the Debian packages.
Speaking about code review platforms, reviewboard (used internally at VMware) is an open source project that does an awesome job of making code reviews ridiculously easy. I strongly think more open source developers should start using it instead of sending around patches.
I was always looking for an opportunity to make some more noise about it, this seemed like a good one : http://www.review-board.org/
I have to agree with Kalle A. Sandström and Tester. This was a preventable, stupid error, and is the direct result of Debian’s long-standing acceptance for applying wholly inappropriate patches to upstream software.
There’s a simple fix here — stop modifying upstream software unless there is a pressing (ie, security) reason. Period.
How many other bugs (security related or otherwise) has Debian introduced with your rampant predilection for patching whatever you want?
@Tester: note that in the openssl case, upstream was contacted, and OKed the patch (apparently, the maintainer then decided to apply the same patch to the same code elsewhere, which caused the problem). In an ideal world, I would totally agree with you. But in the real world, upstream are busy, don’t answer emails, and are not interested in patches that only interest Debian (patches that add support for more strange arches, for example).
(Also note that the policy you suggest (waiting for upstream for each patch) is the one the Mozilla Foundation wants to force distributions to follow.)
We need to work on our processes and our tools, to make such mistakes less likely to happen. We could:
(1) provide a simple way to browse debian-specific changes (hint: that’s something that any Debian derivative could do)
(2) encourage even more developers to submit patches upstream.
(3) recruit more developers to help with our (critical) packages.
(1) is simply a matter of doing it. (2) and (3) are harder.
@Lucas:
Most of these patches are just not debian specific. (2) is very easy, you just have to require it. There is no good reason not to send patches upstream.. And the problem is not a lack of manpower, its that you guys have too much manpower. Leading to packages who have way too much free time and want to become developers instead of packagers. Having custom patches should be the exceptio, not the norm.
Btw, they didn’t send the patch to the right upstream ML.
> Most of these patches are just not debian specific.
For a few packages, maybe. For most of the packages, I don’t think that’s true.
> (2) is very easy, you just have to require it.
Non-cooperative upstreams exist. Sending patches without receiving answers won’t help. The only thing that we could require is more documentation of the Debian-specific changes. Funnily, a long time ago, I pushed something similar for Ubuntu-specific changes: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-August/000182.html
Regarding the “right upstream ML” issue, I’m sure that you noted that openssl-team@ is never mentioned on http://www.openssl.org or in openssl’s source code.
> Non-cooperative upstreams exist.
Packages from dead or non-existent upstreams should just be dropped (thats the Gentoo policy). But this is not the case here.
I think the maintainer of an important package from the largest community based distro should know better, and should know its upstreams. Especially considering that DDs don’t do that many packages.
And frankly only apply patches when there is a serious need.. The threshold to apply patches to debian packages is too low.
Very interesting post. This blog is awnesome !
I’ve just started with my site and I really love this particular template. Is it free or maybe one of those premium templates? Sorry, I am new to this and simply looking for ideas. BTW, I check your site almost daily.