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.
MozReview-Commit-ID: ES1JruCtDdX
--HG--
extra : rebase_source : 2ac6c93c49f2862fc0b9e595eb0598cd1ea4bedf
This also reverts the Bug 1287426 Part 8 patch that turned the USER_NON_ADMIN loken into a restricted token.
MozReview-Commit-ID: 9fNeyhAHw55
--HG--
extra : rebase_source : adbe59260d512b5d17b6e3ea6c1fe484c06eb555
Passes the profile dir to the content process as a -profile CLI
option so that the correct profile dir can be used in the OS X content
sandbox rules. Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected
from the content process (apart from a few profile subdirectories) even
when they don't reside in ~/Library.
xpcshell tests invoke the content process without providing a
profile directory. In that case, we don't need to add filesystem
profile dir. read/write exclusion rules to the sandbox.
This patch adds two new macros to the content sandbox rule set:
|profileDir| holds the path to the profile or the emptry string;
|hasProfileDir| is a boolean (1 or 0) that indicates whether or
not the profile directory rules should be added. If |hasProfileDir|
is 0, profile directory exclusion rules don't need to be added
and |profileDir| is not used.
MozReview-Commit-ID: rrTcQwTNdT
--HG--
extra : rebase_source : 3d5b612c8eb3a1d0da028eba277cd9d6f0c9ac00
Visual Studio 2015 Update 3 has been out for a few months. It appears
stable. So let's start using it.
As part of this, we also update the Windows SDK to the version
corresponding with the Windows 10 Anniversary Update (10.14393.0).
MozReview-Commit-ID: C36sRlKqa8t
--HG--
extra : rebase_source : 2fd46d6053d3eaf62dd8b2b291881c5172cc6056
The functions aren't necessary now that we have BitwiseCast.
MozReview-Commit-ID: 2nzOuwAop4Y
--HG--
extra : rebase_source : 196449249eec75b8eb10e59662231c3f4e83c268
The functions aren't necessary now that we have BitwiseCast.
MozReview-Commit-ID: 2nzOuwAop4Y
--HG--
extra : rebase_source : 0cb2c16f484a81b2e77384564973b58ac2d10fb9
As of bug 1284946, nothing uses nsPSMBackgroundThread, so it's just dead code
that is removed by this patch.
MozReview-Commit-ID: 24HWFHIeCX9
--HG--
extra : rebase_source : 0cdf572fa2b742d9a78b6f099d8a2cf465813ccb
The root with the nickname "Equifax Secure CA" was removed from NSS in bug
1296689 (confusingly, "Equifax Secure CA" doesn't appear in the subject DN of
that certificate, which is "OU=Equifax Secure Certificate
Authority,O=Equifax,C=US"). This removes the dependency on that root as well as
fixes dumpGoogleRoots.js to automatically handle this sort of thing in the
future.
MozReview-Commit-ID: KIEPBnliufX
--HG--
extra : rebase_source : 819b0168e28d73c66f2e23d19f513cce214bcc78
This is to work around an issue where the call to CoInitializeSecurity in MainThreadRuntime::InitializeSecurity causes the impersonation token, used to give the pre-lockdown permissions, to be replaced with one with no rights.
This only seems to happen when the lockdown token is USER_NON_ADMIN, which is not a restricted token.
MozReview-Commit-ID: 6HFuDFmWLTf
