(Backed out changeset 6bbf8dc0b86e (which was a backout of changeset 0a5795108e0a))
MozReview-Commit-ID: EZFn7dLBcdh
--HG--
extra : rebase_source : 8fac1e33a7f108a248ecde35779b2c63ce7d9172
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
Unfortunately we have a number of add-on installation tests that rely on
unpacked addons verifying as signed. The test infrastructure achieves this by
monkey-patching nsIX509CertDB.verifySignedDirectoryAsync to always succeed.
These tests are, in general, not actually testing the successful verification of
signed unpacked add-ons but rather other aspects of add-on installation,
updating, etc.. Some of these tests are certainly no longer relevant now that
legacy add-ons aren't supported, but we don't have the time to go through all of
them at the moment (this blocks updating add-on signature verification to use
COSE signatures, which we need to ship in 59 or we're probably not shipping at
all).
MozReview-Commit-ID: 3TVPK703mUy
--HG--
extra : rebase_source : 5bf0b72a4d7c8ade702334345fdc3bf6a8761b15
As a result of this patch, the hash algorithm used in add-on signature
verification will come from the PKCS#7 signature. If SHA-256 is present, it will
be used. SHA-1 is used as a fallback. Otherwise, the signature is invalid.
This means that, for example, if the PKCS#7 signature only has SHA-1 but there
are SHA-256 hashes in the signature file and/or manifest file, only the SHA-1
hashes in the signature file and manifest file will be used, if they are present
(and verification will fail if they are not present). Similarly, if the PKCS#7
signature has SHA-256, there must be SHA-256 hashes in the signature file and
manifest file (even if SHA-1 is also present in the PKCS#7 signature).
MozReview-Commit-ID: K3OQEpIrnUW
--HG--
extra : rebase_source : 704a2a18e166bfaf3e3d944d13918054bd012000
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: H9I6vNDMdIr
--HG--
extra : rebase_source : cf537a1f65af003c6c4f8919b925b0f305c1dd4d
extra : source : 13b89ce4e6a66c840f82a335c71f5a12938aba22
(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
-Wextra implies -Wmissing-field-initializers, but since the latter warning seems
to warn about mostly uninteresting instances (XPCOM module definitions etc), we
disable it for now.
(Note that -Wall is already enabled by default for all directories for gcc and
clang.)
MozReview-Commit-ID: 8RdF51sLPC8
--HG--
extra : rebase_source : 003c1c04e090ec215d058f5adf4c9e72558bbae3
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
verifySignedManifestAsync() was added in Bug 1059216 to support Trusted Hosted
Apps.
However, Bug 1196988 removed THA and no add-ons use this method, so there's no
point in keeping it around.
MozReview-Commit-ID: 6xBRxvRZfjh
--HG--
extra : rebase_source : 5b8cf9c5863187b55325a8f9929bbe52c6478ec5
THA was removed in Bug 1196988.
After Bug 1235869 and Bug 1238079, Firefox Marketplace apps are at most
supported by B2G, and B2G only code doesn't need to be in m-c anymore.
MozReview-Commit-ID: DAx5lRdYQo0
--HG--
extra : rebase_source : e7fc32195def3acda2d53a6e3cb969f1e8a9a9a1
The PR_SetError() + PR_GetError() pattern is error prone and unnecessary.
Also fixes Bug 1254403.
MozReview-Commit-ID: DRI69xY4vxC
--HG--
extra : rebase_source : aa07c0dfb5cc2a203e772b415b7a75b27d9bad3c
The functions aren't necessary now that we have BitwiseCast.
MozReview-Commit-ID: 2nzOuwAop4Y
--HG--
extra : rebase_source : 0cb2c16f484a81b2e77384564973b58ac2d10fb9
The functions aren't necessary now that we have BitwiseCast.
MozReview-Commit-ID: 2nzOuwAop4Y
--HG--
extra : rebase_source : 196449249eec75b8eb10e59662231c3f4e83c268
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
mozilla::BitwiseCast does the same thing, but provides static asserts that
mitigate some of the risk of using reinterpret_cast.
MozReview-Commit-ID: ENQ8QC6Nl9o
--HG--
extra : rebase_source : c1725c8363c0f7f9877601de5ab5f152ef4d0439
These reinterpret_casts can be static_casts or const_casts instead.
MozReview-Commit-ID: 1KQDWHO9CGS
--HG--
extra : rebase_source : a629d91577bdcb6d7fd94416e61ad46ca43f945d
ScopedPK11Context is based on Scoped.h, which is deprecated in favour of the
standardised UniquePtr.
MozReview-Commit-ID: HE8UY1hOuph
--HG--
extra : transplant_source : 4%BF%81M%09Q-%2A%E6%04%86i%18%1B%3CL%90%88%04%C7
ScopedCERTCertList is based on Scoped.h, which is deprecated in favour of the
standardised UniquePtr.
Also changes CERTCertList parameters of various functions to make ownership more
explicit.
MozReview-Commit-ID: EXqxTK6inqy
--HG--
extra : transplant_source : %9B%A9a%94%D1%7E%2BTa%9E%9Fu%9F%02%B3%1AT%1B%F1%F6
This patch does the following:
- Implements nsNSSShutDownObject.
- Replaces more raw pointers with smart pointers.
- Fixes other misc issues.
MozReview-Commit-ID: HulWdonEbP8
--HG--
extra : transplant_source : %DC%27%14%AE%28%A2F%80%1F%2C%83L%D3h%A2%C7k%F0%1C%2B
Also converts the longer |UniquePtr<char, void(&)(void*)> foo(..., PORT_Free)|
to the shorter and equivalent |UniquePORTString foo(...)|.
MozReview-Commit-ID: LlrTNUYBP4V
--HG--
extra : transplant_source : afU%FB%0EC%3E%E0pm%A3-%0E%C8%83%CF%0A%B1%9E%ED