Bug#699888: new nss packages fixing cve-2013-1620

Thijs Kinkhorst thijs at debian.org
Sat Mar 16 09:19:37 UTC 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/attachments/20130316/ffcb332b/attachment.pgp>


More information about the pkg-mozilla-maintainers mailing list