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.
CVE-2011-3389 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3389): 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, in conjunction with JavaScript code that uses (1) the HTML5 WebSocket API, (2) the Java URLConnection API, or (3) the Silverlight WebClient API, aka a "BEAST" attack.
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. Thanks, Jory. Arches, please test and mark stable: =dev-libs/nss-3.14 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.
amd64 stable
Stable for HPPA.
x86 stable
arm stable
alpha/ia64/sparc stable
ppc stable
stable ppc64, closing
Thanks, everyone. 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).