The PR_SetError() + PR_GetError() pattern currently used is error prone and
unnecessary. The functions involved can instead return mozilla::pkix::Result,
which is equally expressive and more robust.
MozReview-Commit-ID: Hkd39eqTvds
--HG--
extra : rebase_source : f09e37c6a3a930c30cce003139df86bc84d771ee
strnlen() is available on all the platforms we care about, so we should use that
instead.
MozReview-Commit-ID: H3ac5AHiRJk
--HG--
extra : rebase_source : 911f292e97facf5807a1bc1654bdbc1fab87c8bc
extra : histedit_source : 17ff8322acc90bb88efd428aab1e0e0fc785ed61
Deleting certs via the cert manager results in a confirmation dialog popping up.
This dialog contains a list of certs that were selected for deletion.
Currently, only the Common Name of each cert is used to represent it in the list.
This is a problem for certs that don't have a CN. More jarringly, the cert
manager itself falls back to various other attributes, so for example selecting
a cert that is represented by its OU ends up popping up a dialog where an empty
list is shown.
MozReview-Commit-ID: 3z4BebW8Ucd
--HG--
extra : rebase_source : 468eb3de470e3ec42471c80183a9c48ebfb130c9
extra : histedit_source : 90e1d2fc73aaba4ded68d933b6ea3a6092d60636
The existing code in head.js is moved out because it doesn't need to be there
now, and probably not in the near future.
MozReview-Commit-ID: GWUW9wT3fzF
--HG--
extra : rebase_source : b7ba2a621df205bda8bdb0cbd493a22ce49a705f
extra : histedit_source : e9094261bc717ffd0a320b180fba4aab21122fa4
This may save us some memory and reduce the number of static constructors.
MozReview-Commit-ID: FNIkiFtRjfK
--HG--
extra : rebase_source : d2781f11db7a1f8370c0e6c6c8e6f0fb52122614
The code is used in comm-central, but is unused in mozilla-central. It will be
imported into comm-central in Bug 1297368.
MozReview-Commit-ID: BEY9BR0YRiD
--HG--
extra : rebase_source : 6d34c1e82cd749a009f26be50fde0537373f2f9e
This is mostly a preliminary review request, although I think everything that
should be done in this bug is present. This intentionally does not include
support for decoding extensions or subject public keys.
MozReview-Commit-ID: 4ewu66Xx411
--HG--
extra : rebase_source : 6105cf16e46d5d2cc9355cf38f8d0098a8a40462
This adds the following locations:
HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates
HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates
to the location that was already being searched, which is:
HKLM\SOFTWARE\Microsoft\SystemCertificates
MozReview-Commit-ID: LGOT4YNEqLV
--HG--
extra : rebase_source : 735230f03b4e9b94f350cdbd3930b68975824458
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
Haik Aftandilian
Gian-Carlo Pascutto
Cykesiopka
Carsten "Tomcat" Book
Sergei Chernov
Phil Ringnalda
ffxbld
Franziskus Kiefer
Bob Owen
Wes Kocher
Tom Schuster
David Keeler
Ryan VanderMeulen
Sebastian Hengst
Mark Goodwin
Martin Thomson
David Parks