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
MSVC 2017 headers aren't warning free at the -Wall level.
Since PSM enables -Wall in some moz.build files, this breaks
--enable-warnings-as-errors builds.
As a temporary measure, disable enough warnings to get working builds.
MozReview-Commit-ID: G0oUsAYYct2
--HG--
extra : rebase_source : dc37783c89e66a54510c9940f9eaa5a4340ef43e
MozReview-Commit-ID: Gay4bliuiDc
This modifies getCTKnownLogs.py to inject 3 debug-only Certificate Transparency
log keys and 2 organizations ("Mozilla Test Org 1" and "2") for use with
integration tests. Also updates CTKnownLogs.h as generated by the python script.
The debug logs use the "default", "secp256r1", and "alternate" keys that are
already present in our testing infrastructure (see pykey.py).
--HG--
extra : rebase_source : 3d4fc736f840cd080fab6b8c6c5b53cc9361abf2
Firefox essentially does not support running NSS in FIPS mode any longer. This
has always been the case on Android from what I can tell and it has been the
case on OS X since at least version 34 (see bug 1047584). It became the case on
Windows as of version 53 (see bug 1295937). Unfortunately, before this patch,
if a user attempted to run an affected version of Firefox using a profile
directory containing an NSS database collection that had FIPS enabled, NSS
initialization would fail and fall back to running in no DB mode, which had the
side-effect of making any saved passwords and certificates unavailable. This
patch attempts to detect and work around this failure mode by moving the
PKCS#11 module DB (which is where the FIPS bit is set) to a backup location and
basically running with a fresh, non-FIPS module DB. This allows Firefox to
initialize NSS with the preexisting key and certificate databases available.
MozReview-Commit-ID: 1E4u1ngZyRv
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting.js => security/manager/ssl/tests/unit/test_broken_fips.js
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key3.db => security/manager/ssl/tests/unit/test_broken_fips/key3.db
extra : rebase_source : 887f457e998d6e57c6536573fbe3cb10547fe154
Calling VFY_VerifyDigestDirect causes the provided SECKEYPublicKey to be
reimported to the softoken regardless of if it already exists on it. EC keys
must be verified upon import (to see if the point is on the curve to avoid some
small subgroup attacks), and so repeatedly doing this with a static key (say,
for example, a key corresponding to a built-in certificate transparency log) is
inefficient. This patch alters the certificate transparency implementation to
import these keys each once and then use PK11_Verify for ECDSA signature
verification, which doesn't have the same drawback.
Since this change causes CertVerifier to hold an NSS resource (via its
MultiLogCTVerifier having a list of CTLogVerifier, each of which now has a
SECKEYPublicKey), nsNSSComponent has to make sure it goes away before shutting
down NSS. This patch ensures this happens in nsNSSComponent::ShutdownNSS().
MozReview-Commit-ID: 6VSmz7S53y2
--HG--
extra : rebase_source : 4994db9de80a6c1aec3d7e322ff30d040140ce92
The default OCSP timeout for soft-fail DV is still 2 seconds. This patch makes
it configurable on the interval (0, 5] seconds.
The default OCSP timeout for EV and hard-fail DV is still 10 seconds. This patch
makes it configurable on the interval (0, 20] seconds.
MozReview-Commit-ID: CPd8pwYrJhj
--HG--
extra : rebase_source : 45bd7d06ea013f0a776ea18be9408dedb18271d8
(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
The only unhandled call updates nsHTTPListener::mHttpResponseContentType, but
nothing actually uses the value of mHttpResponseContentType.
MozReview-Commit-ID: FQXESvoO2ZN
--HG--
extra : rebase_source : 547158311de136054acff2539ea6a8bdbfb8227b
Changed |print("enum ID : uint32_t {", file=output)| to |print("enum HistogramID : uint32_t {", file=output)| at line 53 of the file |toolkit/components/telemetry/gen-histogram-enum.py|, and then replaced all the textual occurrences of |Telemetry::ID| to |Telemetry::HistogramID| and |ID| to |HistogramID| in 43 other files.
mozilla::TimeStamp is generally superior to PRIntervalTime, and switching lets
us get rid of yet another NSPR dependency.
This patch also:
1. Gets rid of code in nsNSSHttpRequestSession::createFcn() that limits the
max OCSP timeout. This is a relic from when NSS was used for OCSP requests,
and is no longer necessary.
2. Converts all uses of PR_NOT_REACHED() to MFBT asserts while we're nearby.
MozReview-Commit-ID: KvgOWWhP8Km
--HG--
extra : rebase_source : ea832a1acc4423cf6cfc98862af6b1c29a83ce56
Unfortunately, this doesn't cover delegated OCSP responder certificates. While
gathering telemetry on the use of SHA-1, we encountered bug 1183822 (basically,
that the method of gathering telemetry was causing OCSP verification failures
due to delegated responders signed with SHA-1). As a temporary solution, we
changed the verifier to always allow SHA-1 for OCSP certificates when verifying
an OCSP response. Consequently, we now have no idea what the compatibility
impact of disabling SHA-1 in OCSP responder certificates will be, so it's
probably not a good idea to do that right now.
Even if someone does manage to forge an OCSP responder certificate using a SHA-1
collision, they will have about as much power as an active network attacker
blocking OCSP requests or injecting bad stapled OCSP responses, so this isn't a
disaster.
MozReview-Commit-ID: 10r23W1APiR
--HG--
extra : rebase_source : dc003c4812677c40882506b1b6b1e1f68d7e6e92
PR_ASSERT() is an unnecessary dependency on NSPR.
We can use MOZ_ASSERT() instead, which accomplishes the same task but doesn't
depend on NSPR.
MozReview-Commit-ID: 9gyWUkv3KxQ
--HG--
extra : rebase_source : 313ce6c8de3db3ce72635e37f09d28316ae02c51
(Note that content signature verification does not use the unified certificate
verifier and thus will still consult OneCRL.)
MozReview-Commit-ID: 6KvHOngpabT
--HG--
extra : rebase_source : 601f4d8d1c66befb77d0c07a2d84f3f04416f996
The PR_SetError() + PR_GetError() pattern is error prone and unnecessary.
Also fixes Bug 1254403.
MozReview-Commit-ID: DRI69xY4vxC
--HG--
extra : rebase_source : aa07c0dfb5cc2a203e772b415b7a75b27d9bad3c
Cykesiopka
David Keeler
Adam Velebil
David Major
Joel Maher
Jeff Walden
Kai Engert
Jonathan Hao
Wes Kocher
Vedant Sareen
Tom Tromey
Phil Ringnalda
Sergei Chernov
Andrea Marchesini
Ms2ger
Carsten "Tomcat" Book