# doesn't break the system in general, and even when it does is totally # justifiable; see below severity 481192 wishlist thanks
On Wed, May 14, 2008 at 03:22:07PM +0200, Helmut Grohne wrote: > The recent update has two big problems: > 1) Yes it tells the admin that it will replace the host key, but does > not allow him to stop and do that step later. > 2) It disables weak keys without further notice. > > This was both documented in the DSA, however only about 30000 admins > will read that and as such cannot be considered an information source > that reaches everyone. I was aware of this problem but considered it absolutely acceptable given the severity of the bug. > Suggestions: > * Add a notice to NEWS.Debian. (Suggestion from Nico Golde.) I thought of that, but the problem with that is that there's no way to stop it showing up again on upgrade to lenny. > * Make "no" an option on replacing the host key. I don't think it's acceptable to give people a nice easy way to ignore this problem; it's far too severe. The old host keys are backed up in .broken so the admin can put them back. If admins are paying enough attention to think of answering "no" to a host key regeneration prompt, I see no reason why they wouldn't also be paying enough attention to confirm the new host key immediately after it's generated and update their client. I can't imagine any situation where you would be awake enough to do the former but not the latter. > * Ask whether weak keys should be disabled. > > Especially the last point can result in the admin locking himself out of > the system which is bad. Which is worse: not being able to log into your own system, or everyone on the Internet being able to log into your system? Clearly the latter. I am not exaggerating in the slightest here; the exploit is *trivial* and if you have weak keys then it is only a matter of time before every script kiddie on the planet can log into your system. It was imperative that use of these keys be disabled as soon as possible. If that involves a few people being inconvenienced, it's worth the trouble. (For the avoidance of doubt, I have never previously encountered a problem severe enough to merit such a statement, and I hope to never encounter another.) There will probably be a few systems in isolated networks where the exploit is not important, and those admins will be inconvenienced with less justification if they fail to notice the ability to use "PermitBlacklistedKeys yes". However, I expect that most such systems will have local admins available (e.g. corporate networks), and again I think this is worth it. > Even if this is a users fault this behaviour is not nice and Debian's > priority should by policy be its users. I realise that this upgrade is not the best experience that could have been offered in an ideal world, but this is not an ideal situation. Please don't lecture me about priorities being users; my priority is precisely our users, but I consider their security to be of higher importance than their comfort, and in a situation where there is very little opportunity to manage both, I'll go for the former. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
