This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
This patch also switches all GlobalSign EV roots to using the CA/Browser Forum
EV policy OID.
Differential Revision: https://phabricator.services.mozilla.com/D8258
--HG--
extra : moz-landing-system : lando
There is a late-breaking EV compatibility concern with cross signatures for EV
certificates:
Firefox's EV handling code always validates EV using the first EV policy OID
expressed in a certificate. For compatibility certificates issued under a cross-
signed root, if the first EV policy OID matches the original Symantec EV policy
OID, then Firefox will attempt to verify that the root CA matches the original
Symantec EV CA -- which it won't, as the root will be one of DigiCert's. Without
a patch, EV treatment will break.
This patch removes all EV policy OIDs for roots mentioned in TrustOverride-
SymantecData.inc, letting the moz::pkix algorithm pick other EV policy OIDs to
validate. I verified that I removed all affected OIDs using the BASH shell
commands:
$ cd security/certverifier
$ grep "CN=" TrustOverride-SymantecData.inc | sed -e 's/.*\(CN=.*\).*/\1/' |
sort | uniq | while read r; do
echo $r; grep "$r" ExtendedValidation.cpp;
done
Reviewers should help me ensure that I did not remove any unexpected EV policy
OIDs.
Differential Revision: https://phabricator.services.mozilla.com/D4709
--HG--
extra : moz-landing-system : lando
We can't use memcmp to compare PODs, largely because of undefined
padding. The rest of the Pod* functions are fine though, since we're
replicating or zeroing PODs.
MozReview-Commit-ID: LSspAi8qCWw
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
Also regenerate the test_signed_app.js testcases.
MozReview-Commit-ID: 483uNQT0wuG
--HG--
extra : rebase_source : 4dfddf89d151dceb970a1a9139a5c90e6b578f8c
Per the root program's request, this patch removes EV treatment for four WoSign
roots:
Common Name: CA 沃通根证书
SHA-256 Fingerprint: D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54
Common Name: Certification Authority of WoSign
SHA-256 Fingerprint: 4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08
Common Name: Certification Authority of WoSign G2
SHA-256 Fingerprint: D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16
Common Name: CA WoSign ECC Root
SHA-256 Fingerprint: 8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02
MozReview-Commit-ID: Bxp9LgvxCsp
--HG--
extra : rebase_source : 065d98cc654d3fb22c17ea185253ce917b48e270
In a profile, loading the loadable roots PKCS#11 module (i.e. the built-in root
CA module) accounted for about 60% of the time to initialize PSM/NSS. Since we
only need the roots module loaded when we're actually looking for an issuing
certificate or querying a certificate's trust, we can do the load
asynchronously (where it hopefully finishes before we actually need it, because
otherwise we'll have to wait anyway).
MozReview-Commit-ID: JyY6NtpQAUj
--HG--
extra : rebase_source : f63a697b18a409dd042289afa2b727b09f81f19f
Disable EV treatment in preparation for removing the CNNIC root certificates
from NSS.
MozReview-Commit-ID: Anz1vXqABUM
--HG--
extra : rebase_source : 694d8321b9f5994fe57e81cb3169681c5e491910
The CA, Comodo, has requested that we remove the UTN-USERFirst-Hardware
root certificate from NSS. First remove EV treatment.
MozReview-Commit-ID: 8OTsevYOuKq
--HG--
extra : rebase_source : aabb219bcbee1c667bae29df618449df4b50d548
The "Swisscom Root EV CA 2" root is no longer in use and will be removed from
the built-in root CA list. However, we have to remove its EV treatment first.
MozReview-Commit-ID: 2TZRt5px7bl
--HG--
extra : rebase_source : 68902555ffe62a973cfaac3af531e96aa288a339
In general, the changes here attempt to:
1. Fix up the style to match modern PSM style.
2. Shorten unnecessarily long code.
3. Reduce global scope pollution.
MozReview-Commit-ID: GFyqFgV0RLD
--HG--
extra : source : 8cb5ee464e42ff07324922abeffef00c7cb1fb1b
(adapted from bug 1349762 comment 0)
Google Trust Services (GTS) recently purchased two roots from GlobalSign that
are both enabled for EV treatment: "GlobalSign Root CA - R2" and "GlobalSign ECC
Root CA - R4".
However, GTS does not have an EV audit, so we are going to turn off EV treatment
for both of those root certificates.
But "GlobalSign Root CA - R2" has intermediate cert "GlobalSign Extended
Validation CA - SHA256 - G2" that continues to be controlled by GlobalSign, to
be used to migrate their customers off dependence on that root.
This patch removes EV treatment for "GlobalSign ECC Root CA - R4". It also
removes EV treatment for all chains rooted in "GlobalSign Root CA - R2" unless
the "GlobalSign Extended Validation CA - SHA256 - G2" intermediate is in the
chain.
MozReview-Commit-ID: Ej9L9zTwoPN
--HG--
extra : rebase_source : 575f1a48646cf728d879d0cf53c888654e4a32ad
The NSS Base64 functions are less safe and convenient to use than the XPCOM ones.
They're also an unnecessary dependency on NSS.
The NSS Base64 functions behave slightly differently than the XPCOM ones:
1. ATOB_ConvertAsciiToItem() / NSSBase64_DecodeBuffer() silently ignore invalid
characters like CRLF, space and so on. Base64Decode() will return an error
if these characters are encountered.
2. BTOA_DataToAscii() will produce output that has CRLF inserted every 64
characters. Base64Encode() doesn't do this.
For the reasons listed below, no unexpected compatibility issues should arise:
1. AppSignatureVerification.cpp already filters out CRLF and spaces for Manifest
and Signature values before decoding.
2. ExtendedValidation.cpp is only given what should be valid hard-coded input to
decode.
3. ContentSignatureVerifier.cpp already splits on CRLF for when it needs to
decode PEM certs. Spaces shouldn't be likely.
For Content-Signature header verification, examination of real input to a
running instance of Firefox suggests CRLF and spaces will not be present in
the header to decode.
4. nsCryptoHash.cpp encode is affected, but we actually don't want the CRLF
behaviour.
5. nsDataSignatureVerifier.cpp decode is affected, but we add whitespace
stripping to maintain backwards compatibility.
6. nsKeygenHandler.cpp encode is affected, but the previous CRLF behaviour was
arguably a bug, since neither WHATWG or W3C specs specified this.
MozReview-Commit-ID: IWMFxqVZMeX
--HG--
extra : rebase_source : 4863b2e5eabef0555e8e1ebe39216d0d9393f3e9
R. Martinho Fernandes
Moritz Birghan
Benjamin Beurdouche
Bogdan Tara
Kevin Jacobs
Marcus Burghardt
Dana Keeler
Sylvestre Ledru
Ehsan Akhgari
Franziskus Kiefer
J.C. Jones
Jeff Gilbert
Kate McKinley
Cykesiopka
David Major
Phil Ringnalda