It’s been an amusing morning reading more takes on the Debian OpenSSL issue. While I was in the know before most others due to vendor-sec, and was able to quickly verify this didn’t affect Mandriva, the fallout still continues. For those that think otherwise, this is a big issue, and a big mistake, and outlines some very important things about open source development. First, this fellow thinks that the Debian OpenSSL maintainer should be changed, that the individual who caused this catastrophe should be booted as maintainer. Honestly, he’s probably right. If this was something that happened in a corporate setting to affect the security of an individual company to the degree that this thing did, you know for fact that person would be canned within minutes. Should we have more leeway just because it’s open source and he’s not being paid? Frankly, if you’re not good at cryptography and don’t fully understand the code and aren’t willing to work closely with upstream, you shouldn’t be farting around with the package. OpenSSL and other stuff like that is pretty major.
When I was maintaining packages on Mandriva, I was the openssh maintainer. I caught crap from Theo on a few occasions due to modifications Mandriva had made to openssh, despite the fact that I wasn’t the one who made those changes. As a result, this “header” has been in openssh’s spec for the last seven years:
## Do not apply any unauthorized patches to this package! ## - vdanen 05/18/01
Of course, I’ve not maintained openssh in quite a few years and it looks like the current/existing maintainers haven’t been paying attention (or don’t care) about that particular notice. There are 8 patches to openssh, only 3 of which would be there if I were the maintainer. Oh well.
Another scathing post to the OpenSSL issue, with some interesting comments, is on the Practical Technology blog, entitled Open-Source Security Idiots. There are probably others, but I think two is sufficient.
This outlines one reason why I took the philosophy of “least-patching” when it came to Annvix. The things that required patching usually had the patches submitted upstream for inclusion. Some made it, some didn’t. I get there are some distro-specific features that authors won’t want to incorporate. For instance, svlogd would always log in UTC time which to me is useless… when I’m looking at logs and looking at dates, I’m looking for my time, not UTC time. So I patched that. But that’s not how upstream wants it so, fine, that’s one patch maintained by me. But when it comes to big things, or things I don’t understand, or crypto or security, etc. these things I deal with upstream and/or just plain old don’t touch. I’m not a C or C++ expert, I’m not a cryptography specialist, and I won’t pretend to be one. If user X wants fancy feature Y in crypto package Z, well, they can deal with upstream to get it or provide something blessed by upstream.
For instance, take the recently-added blowfish support to glibc. To add it to Mandriva was quite trivial as I’ve been using it on Annvix for years. How does it work? I have very little idea. But I worked closely with Solar Designer of the Openwall GNU/Linux project to make sure it worked and worked properly in Annvix because it was needed for the TCB support I had added (and which I’ll be adding to Mandriva shortly). Now, Solar definitely knows about this stuff, so working with him to get it right helped. Yeah, I suffered through being implied an idiot, but that’s ok because I didn’t come out to sound like any kind of expert. Really, I’m just a glorified patch-monkey, not some deep-crypto-coder.
Anyways, my point is that it’s important to work with upstream for this stuff as much a possible, and taking the path of least-patching makes good sense. It avoids problems like this. After all, you might be the “maintainer” of such-and-such software, but upstream is the author, and presumably understands and knows the code more than you. This is another reason to send patches upstream. If they’re rejected, think about why they’re rejected. It might be for good cause. You may also get the peer review to make the patch better; upstream won’t always want to take your changes, but if there’s something totally wrong with it, they’ll let you know and maybe toss in a name or two for good measure. But, really, that humiliation is better than this one… by no stretch of the imagination would I want to be Kurt Roeckx (the Debian openssl maintainer) right now.