I'm a network administrator for a large company. I am responsable for a large server infrastructure which is based on Debian GNU/Linux, deployed domesticly and internationally wherever our network goes. Flaky software isn't just an annoyance for me. If I deploy a bad patch and lock myself out of even a small percentage of my servers, I'm royally screwed. In many cases, I don't even have IT staff within a thousand miles of some of our small field offices to log in on the console to fix it. That's why I run Debian in the first place - they have an incredible record of software quality.
So, when Theo comes along and declares that I have a security hole, and that the way for me to fix it is to upgrade to the newest version of his code that he released a couple days ago, and to enable the new feature that he's just finished working on, just to limit the damage to compromising a chroot-jail account instead of root, I just have to laugh. Beta-testing his latest pet project is not an acceptable risk; it's a joke.
What *should* he have done?
Well, in his message to bugtraq, I think he spent more time talking about how terrible it was that all the distro vendors weren't falling all over themselves to play along with his joke, instead of giving us the key bits of information we needed. Specifically:
What versions are affected? (The version that ships with the stable version of Debian isn't even affected by this.)
The fact that there would be a workaround available to prevent the problem without upgrading. This would have been very valuable information for determining the need to upgrade. He wouldn't even need to specify which features, as long as I knew that there would be a workaround.
Instead of just telling vendors that the sky was falling and that the only way to save yourself was to upgrade to hot-off-the-skillet code, he should have provided them with the patch (which is a very simple one involving only a few lines of code) so they could incorporate it into the versions of SSH they ship. QAing a backported security fix is a lot easier than QAing a huge jump forward in software versions. This is how Debian usually handles security - they backport the fix into the production code. It keeps me secure without having to play the version-of-the-week game.
Any of these would have given everyone enough to work on to evaluate how they wanted to proceed. None of these options would have required disclosing exactly where the problem was to the public, or even vaguely where in the code to find it.
IMHO, it looks to me that the real reason he's handling it this way is that he wants to coerce us into upgrading all our old software to his latest and greatest, for whatever reason.
This goes completely against the controlled release cycle that is necessary to maintain high quality software. I believe this is one of the reasons he's getting flamed so hard for this release.
[ Parent ]