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
CERT_AddTempCertToPerm and CERT_ImportCerts (when called with keepCerts=true)
internally use PK11_GetInternalKeySlot. The current plan for making NSS always
available involves initializing it in memory-only mode and later opening the
user's certificate and key databases. Doing so means that
PK11_GetInternalKeySlot will not return the right token, so we can't rely on
functions that make use of it internally. For now we'll simply use equivalent
functions that take an explicit PK11SlotInfo argument and pass in the current
internal token. A later patch will change all places where PSM and Gecko use the
internal token to use the correct token.
MozReview-Commit-ID: CpSo5dIkyVW
--HG--
extra : rebase_source : 4f6e1707b34cb8dcf5e89cf3620c2d76fea39c82