Changes the semantics of the security.sandbox.content.level pref on OS X with
respect to file access to the user's home directory. With the fix, Nightly
defaults to 2 while other releases will default to 1. The level values now
have the following meaning.
*) security.sandbox.content.level=0 disables content process sandboxing.
No change here.
*) security.sandbox.content.level=1 blocks write access to the majority of the
home directory.
*) security.sandbox.content.level=2 includes the write access blocking in
level 1, but also blocks both read and write access to ~/Library and $PROFILE
excluding the extensions and weave subdirectories.
Prior to this fix, Nightly defaulted to a value of 1 while all other releases
used 0. The value of 1 meant that read/write access to ~/Library and the
$PROFILE dir (excluding $PROFILE/{extensions,weave}) was prevented.
The strength of a level=1 sandbox is reduced by this with fix,
but level=1 becomes the first ride-the-trains content sandbox candidate,
Nightly changes to level=2, and higher levels still indicate a more
restrictive sandbox.
MozReview-Commit-ID: 7NJAe24T4pU
--HG--
extra : rebase_source : 8cb5ea82004ad631fe688bafffa9dc9979568679
We have an unused "telemetry" variable. Use this variable and move
the telemetry assignment to immediately after the operation it is
recording.
While I was here, I also cleaned up the timing variables. I eliminated
the end time variable and moved the declaration of the start time
variable so its scope is shorter.
MozReview-Commit-ID: IbGOK5pPkcR
--HG--
extra : rebase_source : a5ff906452cca9764eb52e1b54a83d26efa52e94
extra : source : d4c60188e82c85d8d324706961ecc56b09838b4b
We have an unused "telemetry" variable. Use this variable and move
the telemetry assignment to immediately after the operation it is
recording.
While I was here, I also cleaned up the timing variables. I eliminated
the end time variable and moved the declaration of the start time
variable so its scope is shorter.
MozReview-Commit-ID: IbGOK5pPkcR
--HG--
extra : rebase_source : 7ab28e2ebeaf5ac8a9af8e9f79a58aebb61e1793
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
Disabling the Adobe CDM but leaving it visible means that we won't download it
and if a site tries to use it we will prompt the user to enable DRM and only
then download it.
MozReview-Commit-ID: LtEr0NJMiQM
--HG--
extra : rebase_source : b7c6f005fb6173c41af6a583c22473066a47a5eb
Changes the semantics of the security.sandbox.content.level pref on OS X with
respect to file access to the user's home directory. With the fix, Nightly
defaults to 2 while other releases will default to 1. The level values now
have the following meaning.
*) security.sandbox.content.level=0 disables content process sandboxing.
No change here.
*) security.sandbox.content.level=1 blocks write access to the majority of the
home directory.
*) security.sandbox.content.level=2 includes the write access blocking in
level 1, but also blocks both read and write access to ~/Library and $PROFILE
excluding the extensions and weave subdirectories.
Prior to this fix, Nightly defaulted to a value of 1 while all other releases
used 0. The value of 1 meant that read/write access to ~/Library and the
$PROFILE dir (excluding $PROFILE/{extensions,weave}) was prevented.
The strength of a level=1 sandbox is reduced by this with fix,
but level=1 becomes the first ride-the-trains content sandbox candidate,
Nightly changes to level=2, and higher levels still indicate a more
restrictive sandbox.
MozReview-Commit-ID: 7NJAe24T4pU
--HG--
extra : rebase_source : 6e678cc6d23c604d8ed0888d6ceeeb4bf797cb1f
Move to a late beta of 1.12 to work around the llvm-dsymutil
crashes from running `./mach buildsymbols` with the rustc 1.11
output on current m-c. See bug 1301751 for details.
MozReview-Commit-ID: 1gbAGLOxkaO
--HG--
extra : rebase_source : 14ce15d9890a9e052f67bb795de209220179d70e