There are a few places where we can use the safer functionality provided by the
Mozilla string classes instead.
Also fixes Bug 1268657 (remove vestigial
TransportSecurityInfo::SetShortSecurityDescription declaration).
MozReview-Commit-ID: Cxv5B4bsDua
--HG--
extra : rebase_source : 074a154c9000807d6dd466f23e92289e0d4c76d8
Some of our tests currently assume that certain real domains are HSTS preloaded.
While most of the time these domains are in fact preloaded, this may change
during periods of maintenance or other events.
To avoid this, the changes here perform the following renames:
bugzilla.mozilla.org -> includesubdomains.preloaded.test
login.persona.org -> includesubdomains2.preloaded.test
www.torproject.org -> noincludesubdomains.preloaded.test
In addition, some tests that refer to mozilla.com (but don't depend on it being
preloaded) are made to refer to example.com instead to avoid referring to real
domains in tests.
MozReview-Commit-ID: 3987moJnKGk
--HG--
extra : rebase_source : 0ec49c9a410ba891f11668e7e11c48b7547e1825
Periodic updates on m-c are currently broken due to Bug 1350619, so this change
inserts the test domains into the preload list semi-manually.
MozReview-Commit-ID: EBOiQcKDSHr
--HG--
extra : rebase_source : bc5880af95dc9934132d0e9251d9060ad9c6871a
This lets us migrate off depending on real preloaded domains and onto
domains that are guaranteed to have the correct characteristics.
MozReview-Commit-ID: 4TyOfdIA9I7
--HG--
extra : rebase_source : f49109de9292dec31b72d87819dd52b5a6b659ed
nsIX509Cert.getAllTokenNames() is only used (improperly) to determine if a
certificate is a built-in. nsIX509Cert.isBuiltInRoot should be used instead.
MozReview-Commit-ID: LBwI8nTc05C
--HG--
extra : rebase_source : 9494cd1243395b0d293022e981f64be560a54dec
When determining if a certificate error override is allowed for a host, we
consult nsISiteSecurityService::IsSecureURI to see if the host is HSTS/HPKP.
This API takes an nsIURI, but the calling code only has a hostname as an
nsCString. Calling NS_NewURI works in all situations we will encounter except
when the hostname is an IPv6 address. Since IP addresses are never HSTS/HPKP
anyway, we can skip the NS_NewURI / IsSecureURI calls in those cases as a
workaround.
MozReview-Commit-ID: JXa8cGvqqTA
--HG--
extra : rebase_source : b8dcd2cb4211af230f867ce3954d5333b7a49684
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
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
