[Pkg-openssl-devel] [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator

[Rene Mayrhofer]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/attachments/20080514/124423aa/attachment.pgp