No bug, Automated HSTS preload list update from task PFJDsn1_RJyPxtwQXtin8A
No bug, Automated HPKP preload list update from task PFJDsn1_RJyPxtwQXtin8A
No bug, Automated blocklist update from task PFJDsn1_RJyPxtwQXtin8A
No bug, Automated remote settings update from task PFJDsn1_RJyPxtwQXtin8A
Differential Revision: https://phabricator.services.mozilla.com/D1580
Before this patch, nsNSSComponent initialization would call PK11_ConfigurePKCS11
with some localized strings, which contributed to startup time. Also,
PK11_UnconfigurePKCS11 was never called, so the memory allocated to these
strings would stick around forever. This patch addresses both of these problems
by not calling PK11_ConfigurePKCS11. This means that some properties of NSS'
internal "PKCS#11 slots/tokens" have to be localized when displaying them to the
user.
MozReview-Commit-ID: BbAgbgpFfFG
--HG--
extra : rebase_source : b633da8fea683675d0c0514a378954332afeb024
There is one actual behavior change here, in the webidl version of
TreeBoxObject::GetCellAt. I believe this change fixes a leak of the
nsTreeColumn, but could use careful review.
I tried to avoid changes not needed to get this compiling. There will be a lot
more cleanup in the next few changesets.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Also removes displayUnknownCertErrorAlert, which was declared but never used.
Also removes some unnecessary ns(I)CertOverrideService OID stuff.
MozReview-Commit-ID: 4o7c1TkKeKJ
--HG--
extra : rebase_source : a8069b76fc847e6b4d158e4b30a75bde3e290ed9
Before this patch, we exposed a few interfaces that revolved around mapping a
name to a specific PKCS#11 module, slot, or token. These APIs were all either
problematic and/or unnecessary. In theory there could be two tokens in different
modules with the same name, so nsIPK11TokenDB.findTokenByName wasn't guaranteed
to return what the consumer expected it to. In general, these APIs were used by
front-end code to go from a handle on the specific object in question to a
string identifier and then back to a handle on the object. This was unnecessary
- we can just retain the original handle.
MozReview-Commit-ID: IbqLbV4wceA
--HG--
extra : rebase_source : 05d39afd6bed0aa5e7694e1c79baf836edc03214
The patch for bug 1456489 included a workaround for the issue that origin
attributes weren't honored on channels that didn't have a load group set (bug
1456742). Now that that's fixed, we don't need the workaround.
MozReview-Commit-ID: I4ExIqt6dYo
--HG--
extra : rebase_source : d323c0860989985b72933dcffd62743b9d73644d
nsNSSComponent::PIPBundleFormatStringFromName and ::GetNSSBundleString are now
unused. They can be removed (which means that nsNSSComponent::mNSSErrorsBundle
can be removed as well).
MozReview-Commit-ID: GAaGawSDL2n
--HG--
extra : rebase_source : 3f683a902e292c6b0cf736773e71fb893074c32b
nsNSSComponent startup and shutdown would be simpler if there were no direct
dependencies on localized strings. This patch removes a dependency on the
localized name of the builtin roots module by hard-coding the name internally
and then mapping it to/from the localized version as appropriate.
MozReview-Commit-ID: 30kbpWFYbzm
--HG--
extra : rebase_source : 3d384af5a9fa45d5ac1f78e1fcb0dd9e4b94267d
Before this patch, if nsNSSComponent initialization failed after allocating the
XPCOM object for the component but before dispatching the load loadable roots
task, BlockUntilLoadableRootsLoaded would block indefinitely in ShutdownNSS
(called from ~nsNSSComponent).
This patch re-arranges some things so that nsNSSComponent cleanup won't block on
the load loadable roots task if it never fired. It also splits the cleanup into
idempotent operations and operations that can only be run once.
Unfortunately if nsNSSComponent initialization fails, Firefox is likely to exit
or fail promptly anyway (since it is essential to so many other components).
However, quitting outright is probably a better experience than hanging
indefinitely.
MozReview-Commit-ID: RWmBUV2pEU
--HG--
extra : rebase_source : e2d06178ecc8ca8681eef18cb3af0a9ac8f83d1c
In debug builds, we assert if any UTF8-to-UTF16 conversion fails. If we have
invalid UTF8 in a certificate, we don't want to assert. So, we now lossily
convert invalid UTF8 in certificates for any display purposes.
This also handles fields that are supposed to be ASCII in a similar way.
MozReview-Commit-ID: 6TdVPDTmNlh
--HG--
extra : rebase_source : 17000bd0671551bbdae534a4eaf4946c1b0beb83
At this point, all uses of GetPIPNSSBundleString *should* be on the main thread,
so we can just remove the nsINSSComponent version and rely on the
nsNSSCertHelper instance.
MozReview-Commit-ID: Lt7AgokGKRH
--HG--
extra : rebase_source : 95d3cf6e011468e2aa9df9bb69372ac4d3430286
Summary:
Change the security.pki.name_matching_mode pref to 3 for Enforce on Nightly.
BR_9_2_1_SUBJECT_ALT_NAMES show that ~99.98% of encountered certificates have
an acceptable SAN, so our compatibility risk is about 0.02%.
BR_9_2_2_SUBJECT_COMMON_NAME also shows, 99.89% of certificate common names are
present in a subject alternative name extension, giving a worst-case of 0.11%
risk, though BR_9_2_1_SUBJECT_ALT_NAMES is more what we're affecting here.
Test Plan: none
Reviewers: keeler
Tags: #secure-revision
Bug #: 1461373
Differential Revision: https://phabricator.services.mozilla.com/D1277
--HG--
extra : transplant_source : %BF%7D%DEi%C7%9BhE%D0%C2d%9D0%AC%F8%9EM%E0%60U
Per Bug 1437754 comment 10, the pref security.pki.distrust_ca_policy makes more
sense as a bitmask than a state. To permit future nuance, let's go ahead and do
that before people start implementing atop Bug 1456112.
This does permit both 0b10 and 0b11 to enable the functionality for Firefox 63.
--HG--
extra : transplant_source : %84%AF%89%E0%89dT%01%10%84%A0%3B%A5%28%2A%D3%E1%B0%0D%E7
If a user has set a master password on their NSS DB(s), when we try to change
the trust of a certificate, we may have to authenticate to the DB. This involves
bringing up a dialog box, executing javascript, spinning the event loop, etc.
In some cases (particularly when antivirus software has injected code into
Firefox), this can cause the nsNSSComponent to be initialized if it hasn't
already been. So, it's a really, really bad idea to attempt to change the trust
of a certificate while we're initializing nsNSSComponent, because this results
in a recursive component dependency and everything breaks. To get around this,
if we need to load 3rd party roots (e.g. enterprise roots or the family safety
root), we defer any trust changes to a later event loop tick. In theory this
could cause verification failures early in startup. We'll have to see if this
is an issue in practice.
MozReview-Commit-ID: FvjHP5dTmpP
--HG--
extra : rebase_source : 73d39788ce39adcbe01c89867061f64d05a3876b
If a user has set a master password on their NSS DB(s), when we try to change
the trust of a certificate, we may have to authenticate to the DB. This involves
bringing up a dialog box, executing javascript, spinning the event loop, etc.
In some cases (particularly when antivirus software has injected code into
Firefox), this can cause the nsNSSComponent to be initialized if it hasn't
already been. So, it's a really, really bad idea to attempt to change the trust
of a certificate while we're initializing nsNSSComponent, because this results
in a recursive component dependency and everything breaks. To get around this,
if we need to load 3rd party roots (e.g. enterprise roots or the family safety
root), we defer any trust changes to a later event loop tick. In theory this
could cause verification failures early in startup. We'll have to see if this
is an issue in practice.
MozReview-Commit-ID: FvjHP5dTmpP
--HG--
extra : rebase_source : ad0fb83a0de3632e3a967e91aec3d8070b22dedc
Summary:
No bug, Automated HPKP preload list update from task XSqPd8faStCdsylVmzvQ6w
No bug, Automated blocklist update from task XSqPd8faStCdsylVmzvQ6w
Reviewers: sfraser, aki
Reviewed By: sfraser
Differential Revision: https://phabricator.services.mozilla.com/D1256
--HG--
extra : rebase_source : 855e19990c75e2613bd311976297fb6513e02b94
Bug 1456489 cleaned up our OCSP request implementation a bit. One simplification
it made was to not cancel the timeout timer. It turns out that if we don't, the
OCSPRequest that constitutes the timeout callback's closure might not be valid
if the request has completed (because the timer doesn't own a strong reference
to it). The fix is simple: cancel the timer when the request completes. Note
that we don't have to do the reverse because necko has a strong reference to the
request.
MozReview-Commit-ID: 2WHFLAcGBAw
--HG--
extra : rebase_source : c4216f6792c1d62cbd046b1b3802226c51fbe8af
(Backed out changeset 6bbf8dc0b86e (which was a backout of changeset 0a5795108e0a))
MozReview-Commit-ID: EZFn7dLBcdh
--HG--
extra : rebase_source : 8fac1e33a7f108a248ecde35779b2c63ce7d9172
Also fixes existing code which fails the rule.
MozReview-Commit-ID: CkLFgsspGMU
--HG--
extra : rebase_source : 86a43837659aa2ad83a87eab53b7aa8d39ccf55b
OCSP requests cannot be performed on the main thread. If we were to wait for a
response from the network, we would be blocking the main thread for an
unnaceptably long time. If we were to spin the event loop while waiting (which
is what we do currently), other parts of the code that assume this will never
happen (which is essentially all of them) can break.
As of bug 867473, no certificate verification happens on the main thread, so no
OCSP requests happen on the main thread. Given this, we can go ahead and
prohibit such requests.
Incidentally, this gives us an opportunity to improve the current OCSP
implementation, which has a few drawbacks (the largest of which is that it's
unclear that its ownership model is implemented correctly).
This also removes OCSP GET support. Due to recent OCSP server implementations
(namely, the ability to cache OCSP POST request responses), OCSP GET is not a
compelling technology to pursue. Furthermore, continued support presents a
maintenance burden.
MozReview-Commit-ID: 4ACDY09nCBA
--HG--
extra : rebase_source : 072564adf1836720e147b8250afca7cebe4dbf62
This adds another preference (DistrustSymantecRootsRegardlessOfDate == 2) that
stops permitting certificates issued after 1 June 2016, and updates the test to
check it.
--HG--
extra : transplant_source : %F1%DE%16m%F2%DD%A8Ei%EF%B4%CAo%BF%8D%A6%A6%5E%D4%89