Op zaterdag 16 maart 2013 09:37:25 schreef Yves-Alexis Perez: > On sam., 2013-03-16 at 08:34 +0100, Mike Hommey wrote: > > So, here are a few more info: > > - 3.13 disabled SSL 2.0 by default > > - 3.13 added a defense against the Rizzo and Duong attack, which is > > > > known to break applications. It can be disabled easily. > > > > - 3.14 removed support for md5 signature of certificates. > > > > > > > > These are the main compatibility issues we'd have with bumping NSS to > > 3.14 in stable (where it's 3.12) and testing (where it's 3.13). All of > > them can be fixed by turning some constants to PR_FALSE. That would > > leave us with the possibility of pure bugs emerging. I think we should > > take that risk, especially considering the fixes we can't backport. > > That would also fix bug 697865 (that one is backportable, but that's > > painful and risky). > > > > > > > > FWIW, AFAIK, RedHat is pushing 3.14 to all its long term support > > releases. > > I know it's invasive but I'm not sure we won't have to do anyway during > Wheezy support life. I mean, nobody should do SSL 2.0 at all anyway > (OpenSSL already disable SSLv2 in 1.0.1, even though it doesn't matter > for browsers), and md5 for certificates is known broken too.
Well, wheezy already has 3.13 so SSLv2 and Rizzo (BEAST) are already gone in wheezy, right? I'm all for adding the md5 part aswell to wheezy. Indeed, we need to be proactive with this before it becomes a stable release. So let's go with 3.14 for wheezy. > I'ts definitely late for such surprise for users, but will it be better > if it's done during the life of a stable release? I think the main question is if we can push this out to users of squeeze. I'm not against that per se. If disabling SSLv2 hurts someone seriously, it's about time because they'd have a big problem otherwise. This is also the case for BEAST, but perhaps the risk of it breaking something legitimate is higher. We can consider to put it into a DSA in which the text details how to disable the options if they cause trouble. An alternative is to put it into spu instead, where it may be slightly (probably just slightly) more acceptable to change behaviour than in a DSA. But it will also mean having to wait a few months at least. Do you know if RHEL is pushing it through the security channels or the stable updates channels? Cheers, Thijs
signature.asc
Description: This is a digitally signed message part.
