Update the prior patch to use MOZ_RELEASE_ASSERT so that we cleanly crash
if there's still an error somewhere in this logic, instead of deadlocking
on beta (but crashing on aurora).
MozReview-Commit-ID: InttEcC55Dn
--HG--
extra : rebase_source : c79726acbaf1eb8374500f43cd3c7d33362466ad
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
This fixes two issues:
1. nsNSSShutDownList::evaporateAllNSSResources could deadlock by acquiring
sListLock and then the singleton's mNSSActivityStateLock in
nsNSSActivityState::restrictActivityToCurrentThread.
2. Calling UnloadLoadableRoots before
nsNSSShutDownList::evaporateAllNSSResources could result in removing modules
that were still in use, causing assertion failures and potential crashes.
MozReview-Commit-ID: 8ZgZTVw7sWh
--HG--
extra : rebase_source : 43452add4612b3d12c2b877c3a38169c9676f445
It appears the wallet code was not included during the initial 2007 import of
code from CVS to Mercurial, so anything referencing wallet has been dead code
ever since.
MozReview-Commit-ID: BRTd1M0DsT0
--HG--
extra : transplant_source : %BC%FC%05%AE%B5%8C%DC%21J%DC%B4%B17M%19%AA%F3%B9%05L
ScopedAutoSECItem is useful for:
1. Removing manual memory management.
2. Getting rid of this pattern:
> UniqueSECItem item(SECITEM_AllocItem(nullptr, nullptr, 0));
While this pattern works, ScopedAutoSECItem is slightly superior in that it
doesn't unnecessarily cause a SECItem to be allocated from the heap.
MozReview-Commit-ID: 8DPD9gtzeru
--HG--
extra : transplant_source : %10l%27C%12%3E%08%85q%06%1A%FC%FB%DE%F9%A3%99%0AN%A1
Adds content sandbox metadata to parent and child crash reports:
Includes the value of pref security.sandbox.content.level,
whether or not the system is capable of sandboxing, if the
sandbox was successfully turned on, and (on Linux systems)
the sandbox capabilities flags.
New crash report keys:
"ContentSandboxLevel" in parent and content
"ContentSandboxCapable" in parent
"ContentSandboxEnabled" in content
"ContentSandboxCapabilities" in content on Linux
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
chooseCertificate() currently uses a concatenation of the Common Name of the
server cert and the port of the server to allow the user to identify the server
requesting client authentication. Unfortunately, this approach is flawed, since
it doesn't take into account things like SAN entries, which might be very
different from the CN.
Using the hostname instead avoids this problem.
MozReview-Commit-ID: 6XjGCknWNi9
--HG--
extra : transplant_source : k%10N%7B%E8%A4%9B%C9%9A%23Q%D1%99%D2%A3%C0.%2B%7F%A5
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
Callers should use a UniquePtr to hold the platform handle.
MozReview-Commit-ID: 6BWnyAf4b3a
--HG--
extra : transplant_source : %26%CA%0D%28%08%9BT%97Z%A1%3Dq%CD%21%A1_%EFE%83%0E
extra : histedit_source : 77f8ed3d0fdec6cce0c95469130ade0fb547bb91
The WebRTC implementation inherits cipher suite preferences from PSM and then
enables a few mandatory ones and disables a number of undesirable ones. If PSM
makes a change to a cipher suite preference that isn't in WebRTC's whitelist or
blacklist, compatibility issues can arise. See bug 1288246 for an example.
--HG--
rename : security/manager/ssl/tests/unit/test_fallback_cipher.js => security/manager/ssl/tests/unit/test_weak_crypto.js