Typically, the interfaces involved don't need to use raw char/char16_t strings,
and hence can benefit from the additional safety of using the Mozilla string
classes.
In some places, this patch also changes some UTF-16 APIs to UTF-8 where the
implementations can never actually support UTF-16. This reduces the amount of
code and runtime conversion.
MozReview-Commit-ID: y8o5wLBohe
--HG--
extra : rebase_source : 130c8b77a98d21d5b9a0efeccae8861d89fa8f02
Bug 1275841 switched some IDL types from "string" to "AUTF8String".
This had the unintentional effect of breaking decryption of previously saved
passwords that contained special characters.
In particular, the AUTF8String type means XPConnect may convert any strings
using that type to UTF-16 when crossing XPConnect boundaries.
However, crypto-SDR.js (responsible for encrypting and decrypting for the
password manager) expects to do conversions between UTF-16 and UTF-8 itself.
What ends up happening is crypto-SDR.js decrypts a saved password and tries to
convert from UTF-8 to UTF-16, but fails because the decrypted text is already
UTF-16.
The solution is to use ACString instead of AUTF8String. ACString does not result
in automatic encoding changes, so the expectations of crypto-SDR.js are met
again, and lets SecretDecoderRing.cpp keep the benefit of working with smart
string types.
This change probably breaks passwords saved after Bug 1275841 landed and before
this patch landed, but the number of passwords this patch breaks is probably
much lower than the number of passwords that would be broken if this patch did
not land.
MozReview-Commit-ID: 6Z01zfwJ6t7
--HG--
extra : rebase_source : 514e78f2e1c2cef3b3692656b20daf3b068a4fee
Before this patch, nsPKCS12Blob::digest_read used size_forward to perform a size
check on a buffer. However, the entire set of {digest_open, digest_close,
digest_read, digest_write} was unnecessary because NSS provides this
functionality by default when using SEC_PKCS12DecoderStart. This patch
simplifies things by removing the extraneous implementations.
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
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
Phil Ringnalda
ffxbld
Cykesiopka
David Keeler
Carsten "Tomcat" Book
Franziskus Kiefer
Martin Thomson
Haik Aftandilian
David Parks
Kate McKinley
Jed Davis
Masatoshi Kimura
Sergei Chernov
EKR
Kai Engert
Sebastian Hengst
Wes Kocher
Joseph Yeh
Bob Owen
Gregory Szorc
Igor