"EV enablement for 6 roots. b=493709 r=kaie
WellsSecure, SECOM Trust, StartCom, SwissSign, Cybertrust, DigiNotar"
"Enable Object Signing Trust Bit in NSS for the StartCom Certification Authority
Target Milestone: 3.12.4"
Steps to Reproduce:
1. Use NSS <dev-libs/nss-3.12.4
2. Attempt to install mozilla-firefox extension signed by StartCom or any other listed CA
E.g. Adblock Plus uses the StartCom certificate, see https://adblockplus.org/en/changelog-1.1.2
This means until we stabilize >=dev-libs/nss-3.12.4 you can't install Adblock Plus on Gentoo anymore.
3.12.5 is in the tree, it does have a fix included to handle security issue, all arches are advised to please mark stable.
Stable for HPPA.
IMHO stabilizing 3.12.5 is not a good idea. It badly breaks user experience and we will get loads of bugs from it. From the release notes:
"All SSL/TLS renegotiation is disabled by default in NSS 3.12.5. This will cause programs that attempt to perform renegotiation to experience failures where they formerly experienced successes, and is necessary for them to not be vulnerable, until such time as a new safe renegotiation scheme is standardized by the IETF."
If you define "secure == doesn't work", then everything is ok. It's a decision between a possible breakdown and a known breakdown. Just my 2 cents.
I'm sure it won't break "user experience badly". TLS renegotioation is not commonly used, usually with client X.509 certs.
Nearly all software using TLS has adopted this "fix" like nss, without a large number if complaints.
IETF proposes a solution, which has to be implemented in the future: http://www.ietf.org/id/draft-ietf-tls-renegotiation-03.txt
Until then it should be fine to simply disable TLS renegotiation, better than working with vulnerable (#2)/malfunctioning(#0,#1) libraries.
We should consider adding an einfo that renegotiation is now (temporarily) disabled.