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 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
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
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
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.
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
The functions aren't necessary now that we have BitwiseCast.
MozReview-Commit-ID: 2nzOuwAop4Y
--HG--
extra : rebase_source : 0cb2c16f484a81b2e77384564973b58ac2d10fb9
Cykesiopka
Carsten "Tomcat" Book
Sergei Chernov
Phil Ringnalda
ffxbld
Ryan VanderMeulen
David Keeler
Sebastian Hengst
Mark Goodwin
Martin Thomson
Kate McKinley
Masatoshi Kimura
EKR
Joseph Yeh
Wes Kocher