Dear Thijs, On Mittwoch, 14. Mai 2008, Thijs Kinkhorst wrote: > > I also don't think it's > > reasonable for all packages that somehow use(d) openssl to create keys to > > do their own security fix as openssh-server did (for openssh, I think > > that's a good thing because it's the primary entry point for additional, > > potentially manual fixing). Fixing different packages should be able to > > re-use code and would only bother the user/admin once. > > Since the commit was already publically made last week we had no choice as > to delay the release not more than a few days. Please don't misunderstand me - I fully support the quick fix that already went out to minimize the problem for new keys. But I still think that, given a few more days, we can - and should - do better, e.g. with an additional security upload for libssl. > Fixing certificates for an > ssl-using package is mostly a process specific to that package. I think > we'll accept updated packages like the openssh one just as well for other > ssl-using packages, but "somone has to do it". The maintainers of course > being the most likely candidate since they know their package best. I don't really agree with this, but think that bundling all the fixes together into one package will be less effort for all involved maintainers and - much more importantly - less hassle for our users/admins than already caused by the whole incident. I would highly appreciate if the openssl packaging team could co-ordinate these efforts and e.g. prepare template scriptlets where every maintainer of an affected package can provide "hooks" for automatic re-creation of keys and warning users appropriately. Just taking openssh and open/strongswan we see that they can be handled similarly, and I suspect the same to hold true for apache, openvpn, etc. If we had 15 packages with critical security updates, each solving the issue differently _and at a different time_, then I think users/admins would (rightly) be a lot more annoyed than if we had one openssl-recreate-keys package that bundled together all the scriptlets and asked/warned the user/admin just once. We need to think about the administrative pain for many people here. > > As it stands now, I don't think this issue is fixed from a user point of > > view (just thinking about user ssh keys, which are still wide open....). > > I'm not sure what that last part about user keys means, since the recent > openssh update is designed to block weak user ssh keys. Or what do you > mean? Yes, if the user logs into a patched Debian box, but not if the user logs into _any_ other ssh server using insecure keys. I applaud the openssh package maintainers for such a quick solution for Debian servers, which is IMHO a very good thing to have as a first fix while dealing with the issue. But the current package does not care about user-generated keys on the client side, which is still a security issue as far as I understand the current problem. So it's not even solved for openssh yet, let alone all the other packages. I really think that having one "fixer" package pulled in by the libssl security update is the best solution right now, but I am certainly open to any suggestions on how else to deal with the problem and trying to minimize the hassle that users/admins have to go through. best regards, Rene -- ------------------------------------------------- Gibraltar firewall http://www.gibraltar.at/
Attachment:
signature.asc
Description: This is a digitally signed message part.