MozReview-Commit-ID: 5bUTLz6mGKC
In general, it is possible to create a new nsNSSShutDownObject after
nsNSSShutDownList::shutdown() had been called. Before this patch, at that point,
isAlreadyShutDown() would incorrectly return false, which could lead to code
calling NSS functions, which would probably lead to a crash (because NSS could
be uninitialized at that point). This change merges
nsNSSShutDownList::shutdown() with evaporateAllNSSResources() into
evaporateAllNSSResourcesAndShutDown() for simplicity and makes it so
isAlreadyShutDown() returns true if called after that point.
--HG--
extra : rebase_source : badab89a9e197f18fcd943f16cc77c6aa6664f0d
Removed the probe in Histogram.json and the code related to it in nsKeygenHandler.cpp
MozReview-Commit-ID: E8lGbx19e2C
--HG--
extra : rebase_source : ef958749e6ad2e2b617fd1efdd09cdd3185bef18
pkixocsp_VerifyEncodedResponse_GetCertTrust has a field trustDomain that
deliberately shadows the field it inherits from so that code doesn't use it by
accident.
MozReview-Commit-ID: 1Y4W6sA7lHD
--HG--
extra : rebase_source : d2d3180e6c65ea49255545216230525b96af010d
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
There's an antipattern where nsLiteralString is used as an unnecessary intermediary in converting from CharT* to CharT*,
e.g. CallAFunctionThatTakesACharPointer(NS_LITERAL_CSTRING("foo").get());
or
NS_NAMED_LITERAL_STRING(foo, "abc");
CallAFunctionThatTakesACharPointer(foo.get());
This patch rewrites the callsites that can be trivially changed to use char*/char16_t*.
I'd somewhat like to remove nsTLiteralString::get() altogether, but in code that's less straightforward than these examples, get() is useful enough to keep.
MozReview-Commit-ID: Kh1rUziVllo
--HG--
extra : rebase_source : c21a65694d6e1c42fd88f73632f7ac8f38d005ae
