nss 3.14 has been released by upstream.
I'm opening this as a security bug, because this is the first version to support TLS 1.1 and that's the only way to properly fix the BEAST attack. There are workarounds for BEAST already in place in most client applications, but that doesn't hide the fact that the underlying IV problem is part of TLS 1.0 and thus I'd consider this a security update.
The SSL protocol, as used in certain configurations in Microsoft Windows and
Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Opera, and
other products, encrypts data by using CBC mode with chained initialization
vectors, which allows man-in-the-middle attackers to obtain plaintext HTTP
headers via a blockwise chosen-boundary attack (BCBA) on an HTTPS session,
(2) the Java URLConnection API, or (3) the Silverlight WebClient API, aka a
3.14 is in the tree feel free to take it stable.
(In reply to comment #2)
> 3.14 is in the tree feel free to take it stable.
Arches, please test and mark stable:
Target KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
Tested amd64: looks fine here.
Tested ppc: looks fine here.
Tested x86: looks fine here.
I have recompiled some packages against nss-3.14 and eveything is fine.
=dev-libs/nss-3.14 calls AR and RANLIB directly. bug 440260
In that bug there is a patch that fixes the problem. Maybe it would be a good idea to resolv that bug at the same time as we mark this package stable.
Stable for HPPA.
stable ppc64, closing
GLSA vote: yes, with the Mozilla GLSA.
GLSA Vote: yes too. Added to mozilla GLSA draft.
This issue was resolved and addressed in
GLSA 201301-01 at http://security.gentoo.org/glsa/glsa-201301-01.xml
by GLSA coordinator Sean Amoss (ackle).