Loading enterprise roots could potentially take a while, so we certainly
shouldn't do it on the main thread at startup. Note that this doesn't address
the case where a user enables the feature while Firefox is running. This isn't
great but since it's an about:config preference rather than a first-class
preference exposed in about:preferences, we can probably get away with it for
now.
Differential Revision: https://phabricator.services.mozilla.com/D4708
--HG--
extra : moz-landing-system : lando
It turns out nsSecureBrowserUIImpl is considerably more complicated than it
needs to be. This patch reimplements it in terms of OnLocationChange only, which
is all it needs to produce the same behavior as before.
Differential Revision: https://phabricator.services.mozilla.com/D3548
--HG--
extra : moz-landing-system : lando
In bug 1279479 and bug 1316300 we hid some ciphersuites from TLS 1.3
handshakes, assuming we would fall back to TLS 1.2 if the peer needed them.
However, as of bug 1479501, we don't fall back by default, so this just means
we can't negotiate these ciphersuites. This patch un-hides these ciphersuites
from the TLS 1.3 handshake.
Differential Revision: https://phabricator.services.mozilla.com/D4725
--HG--
extra : moz-landing-system : lando
This does not change the outward behavior of LossyUTF8ToUTF16(). Both
ToNewUnicode() and CopyASCIItoUTF16() convert from Latin1 to UTF-16.
MozReview-Commit-ID: 8SDgvoGaN4A
Differential Revision: https://phabricator.services.mozilla.com/D4639
--HG--
extra : moz-landing-system : lando
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
As initially implemented, nsITLSServerSocket by default enabled the use of the
TLS session cache provided by NSS. However, no consumers of nsITLSServerSocket
actually used it. Because it was an option, though, PSM had to jump through some
hoops to a) make it work in the first place and b) not have NSS panic on
shutdown. Furthermore, it meant increased memory usage for every user of Firefox
(and again, nothing actually used the feature, so this was for naught).
In bug 1479918, we discovered that if PSM shut down before Necko, NSS could
attempt to acquire a lock on the session cache that had been deleted, causing a
shutdown hang. We probably should make it less easy to make this mistake in NSS,
but in the meantime bug 1479918 needs uplifting and this workaround is the
safest, most straight-forward way to achieve this.
Differential Revision: https://phabricator.services.mozilla.com/D3919
--HG--
extra : moz-landing-system : lando
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
In order to allow JS callers to use nsISimpleEnumerator instances with the JS
iteration protocol, we'll need to additional methods to every instance. Since
we currently have a large number of unrelated implementations, it would be
best if they could share the same implementation for the JS portion of the
protocol.
This patch adds a stub nsSimpleEnumerator base class, and updates all existing
implementations to inherit from it. A follow-up will add a new base interface
to this class, and implement the additional functionality required for JS
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D3725
--HG--
extra : rebase_source : ad66d7b266856d5a750c772e4710679fab9434b1
extra : histedit_source : a83ebffbf2f0b191ba7de9007f73def6b9a955b8
- Remove the viewCert method from nsICertificateDialogs
- Remove all associated C++ code
- Directly invoke UI window where it was previous called.
- Update tests
MozReview-Commit-ID: 9b62Go0DjE9
Differential Revision: https://phabricator.services.mozilla.com/D3358
--HG--
extra : moz-landing-system : lando
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
When the HSTS preload script was reworked to use async/await in bug 1436369,
`fetchstatus` would create an asynchronous xml http request and then attempt to
access a response header from it. However, there was nothing to ensure that the
request had completed before this code ran. This patch ensures that the request
has completed before the response header is used.
This patch also replaces a lingering instance of `Ci.nsISSLStatusProvider` that
should have been changed to `Ci.nsITransportSecurityInfo` in bug 1475647.
Finally, this patch removes the old, redundant getHSTSPreloadList.js in
security/manager/tools as well as the unused nsSTSPreloadList.errors file in
security/manager/ssl.
Differential Revision: https://phabricator.services.mozilla.com/D2807
--HG--
extra : moz-landing-system : lando
This patch implements the Symantec distrust plan on Nightly only for now.
Differential Revision: https://phabricator.services.mozilla.com/D2959
--HG--
extra : moz-landing-system : lando
- enhance nsIX509CertDB.importPKCS12File to accept a password and return error code.
- enhance nsIX509CertDB.exportPKCS12File to accept a password and return error code.
- remove password and error prompts being invoked in C++ layer to Javascript layer.
- update unit tests
- add unit test for importing certs with empty string password and no passwords.
- remove unused code
MozReview-Commit-ID: 23ypAzBarOp
--HG--
extra : rebase_source : df608a240c6fa7ce4278145861e57882f0803e02
Summary:
The plan is to also expose perfecthash.py from this module on the python path.
This also allows us to stop using explicit module loading to load make_dafsa.py.
make_dafsa.py was moved into tools/ to avoid any extra python files from
accidentally ending up on the python path.
Reviewers: froydnj!
Tags: #secure-revision
Bug #: 1479484
Differential Revision: https://phabricator.services.mozilla.com/D2614
--HG--
rename : xpcom/ds/make_dafsa.py => xpcom/ds/tools/make_dafsa.py
In some cases, nsNSSComponent functions were acquiring nsNSSComponent's mMutex
to check mNSSInitialized to see if it had been initialized. It turns out this is
unnecessary in some cases because those functions are only callable if
nsNSSComponent has been initialized. This fixes those instances and renames
'mNSSInitialized' to 'mNonIdempotentCleanupMustHappen' to make it clear exactly
what that boolean represents.
Differential Revision: https://phabricator.services.mozilla.com/D2577
--HG--
extra : moz-landing-system : lando
OS key-store adapter for Windows Credential Manager.
It looks like Windows doesn't allow locking the credential manager without locking the desktop. So `lock` and `unlock` are no-ops here.
Depends on D2487.
Differential Revision: https://phabricator.services.mozilla.com/D2550
--HG--
extra : moz-landing-system : lando
OS key-store adapter for Windows Credential Manager.
It looks like Windows doesn't allow locking the credential manager without locking the desktop. So `lock` and `unlock` are no-ops here.
Depends on D2487.
Differential Revision: https://phabricator.services.mozilla.com/D2550
--HG--
extra : moz-landing-system : lando
This implements support for OS-backed storage of secrets using the OS X keychain
APIs.
Differential Revision: https://phabricator.services.mozilla.com/D2487
--HG--
extra : moz-landing-system : lando
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
We can't use memcmp to compare PODs, largely because of undefined
padding. The rest of the Pod* functions are fine though, since we're
replicating or zeroing PODs.
MozReview-Commit-ID: LSspAi8qCWw
This adds a test with an extension signed by autorgraph with cose and pk7.
Differential Revision: https://phabricator.services.mozilla.com/D1855
--HG--
extra : moz-landing-system : lando
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : 9c400bed3c9d29a186fc987c9bd0ffceb37bfd94
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : fbfbcf7608efbfb35c9be4018ff0f4e70b2768d2
This implements an API in `nsIOSKeyStore.idl` and `OSKeyStore.cpp` to encrypt and decrypt bytes with a key that is stored in the OS key store.
There are two OS adapters in this patch.
Libsecret is used on Linux if available.
The NSS key store is used as fallback if no OS specific key store is implemented.
Differential Revision: https://phabricator.services.mozilla.com/D1858
--HG--
extra : rebase_source : 99d7d646968a46a13ffa61885bb246f6d3e443e4
If the preference security.enterprise_roots.enabled is set to true, the platform will import trusted TLS certificates from the OS X keystore.
Differential Revision: https://phabricator.services.mozilla.com/D2169
--HG--
extra : moz-landing-system : lando
Apparently a prehistoric server implementation would send a
certificate_authorities field that didn't include the outer DER SEQUENCE tag, so
PSM attempted to detect this and work around it. Telemetry indicates this is
unnecessary now: https://mzl.la/2Lbi1Lz
--HG--
extra : rebase_source : 6669586d657efb243070a4ceb231583b40823543
extra : amend_source : e87f7c84c6c1a51637914bde5950268409b70571
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
By separating the platform-specific code that finds enterprise roots to load
into its own file, we can make it easier to both add support for other
platforms and maintain the implementations going forward.
Differential Revision: https://phabricator.services.mozilla.com/D2103
--HG--
extra : moz-landing-system : lando
This introduces a helper class that provides one thread all DataStorage
instances can use to do background work. This thread should have a light
workload which mainly consists of reading some files at startup, periodically
writing to these files, and writing them again at shutdown. One thread should be
able to handle this and in any case having multiple threads trying to perform
i/o at the same time would probably be less efficient than merely performing the
work sequentially.
Differential Revision: https://phabricator.services.mozilla.com/D1890
--HG--
extra : moz-landing-system : lando
ChangeCertTrustWithPossibleAuthentication should never be called while holding
nsNSSComponent::mMutex, because doing so can result in showing the master
password dialog, which spins the event loop, which can cause other code to run
that may attempt to acquire the same lock (e.g. speculative connect checking
nsNSSComponent to see if the user has smart cards or client certificates).
Differential Revision: https://phabricator.services.mozilla.com/D2011
--HG--
extra : moz-landing-system : lando
Summary: Coverity found this issue. We shouldn't continue if n is null because CERT_LIST_NEXT dereferences n.
Differential Revision: https://phabricator.services.mozilla.com/D1876
--HG--
extra : rebase_source : 8023a38425194099f334c6624ce2bd5f2e50cb95
extra : amend_source : 27947d33f9dbb0afa9ae5927dde874957eb4017c
Defining nsINSSComponent in idl rather than manually in a header file allows us
to make full use of the machinery that already exists to process and generate
the correct definitions. Furthermore, it enables us to define JS-accessible APIs
on nsINSSComponent, which enables us to build frontend features that can work
directly with the data and functionality the underlying implementation has
access to.
MozReview-Commit-ID: JFI9s12wmRE
--HG--
extra : rebase_source : 16b660e37db681c8823cbb6b7ff59dd0d35f7e73
When doing TLS session resumption, Firefox currently does not have enough
information to trivially reconstitute the original connection's security
information. Consequently, we have to rebuild the certificate chain in the
handshake callback. Before this patch, we determined the EV and CT status of the
connection but did not set the succeeded cert chain unless the certificate was
EV. This was insufficient. In this patch, we set the succeeded cert chain
regardless of if the certificate is EV or not (provided we found a valid chain).
MozReview-Commit-ID: AuKrlBwX1Qh
--HG--
extra : rebase_source : 357ec38ce8c768ac5218d05ccaea5d1b45af8dfd
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
When doing TLS session resumption, Firefox currently does not have enough
information to trivially reconstitute the original connection's security
information. Consequently, we have to rebuild the certificate chain in the
handshake callback. Before this patch, we determined the EV and CT status of the
connection but did not set the succeeded cert chain unless the certificate was
EV. This was insufficient. In this patch, we set the succeeded cert chain
regardless of if the certificate is EV or not (provided we found a valid chain).
MozReview-Commit-ID: AuKrlBwX1Qh
--HG--
extra : rebase_source : cafb17548666f6330038012e36fa23ef382f361a
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
Bug 1372694 added a firefox-appdir line to PSM's xpcshell.ini. It turns out this
breaks running these tests locally because utilities like BadCertServer can't be
found. I looks like the change isn't necessary, so the simplest thing to do
would be to just remove the addition.
MozReview-Commit-ID: 8fg8ujPWxRe
--HG--
extra : rebase_source : ffef9b067dacb94c4bd554f97556ab95f58efd2b
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
(This also fixes Bug 879740 and Bug 1204543.)
build/pgo/certs contains an NSS database set that has a bunch of hand-generated
certificates, and many of these hand-generated certificates are specifically
depended upon for a variety of unit tests. This patch changes all of these to
use the "pycert.py" and "pykey.py" utilities that produce deterministic keys
and certificates.
The naming convention here is new, and defined in the README. It is based on
the mochitest runtest.py naming convention that imports .ca and .client
PEM-encoded certificates.
Unfortunately, the updates to build/pgo/genpgocert.py to generate these files
depends on OpenSSL in order to produce PKCS12 archives for pk11tool to import
into NSS. This could be done with pure-NSS tooling, but it'd require some new
command line functionality, which is out-of-scope for this change.
Note that build/pgo/genpgocert.py no longer takes arguments when run. It's not
run automatically anywhere that I can see, but could (reasonably) be, now.
Differential Revision: https://phabricator.services.mozilla.com/D971
--HG--
extra : amend_source : bc389b9b0a807a4889feb14db439daa28635dfe9
These functions cause main-thread certificate verifications, which is bad for
performance. In general, nsIX509CertDB.asyncVerifyCertAtTime should be used
instead.
MozReview-Commit-ID: 9nkUDmyFY0k
--HG--
extra : rebase_source : d3e8a02e2d21e5507e71681b88f0360edf64b790
This patch goes through and changes a bunch of places in our tree which mention
this bug to use the new feature, making the methods more strongly typed.
There are probably more places in tree which could be changed, but I didn't try
to find them.
nsIX509CertDB.findCertByEmailAddress performs multiple certificate verifications
on the main thread, which is bad because it blocks the main thread and can cause
nested event loop spinning. Firefox doesn't even use this function. Other
products that use this function will either have to re-implement it locally or
find some other workaround.
MozReview-Commit-ID: HShl0H8cgxs
--HG--
extra : rebase_source : 63ee16b600ca7c2867352ee1ad791eb79b82a77c
These functions perform certificate verification on the main thread, which is
already a bad idea. They can also cause OCSP requests to be made from the main
thread, which will cause nested event loop spinning, which is an even worse
idea. Luckily this really only affects tests.
MozReview-Commit-ID: LqDAgDmlyER
--HG--
extra : rebase_source : c86414db0b6d6e7e83b5e3f371506b773813cdbf
window.sizeToContent() apparently interacts poorly with windows that have a
persisted size (see bug 90276, which is a 5-digit bug that hasn't been touched
in over a decade). As a workaround, don't persist the certificate exception
dialog's size. This means we have to call window.sizeToContent() more often and
unfortunately results in the window growing and shrinking again on Windows, but
at least it will always be the "right size" for its content.
MozReview-Commit-ID: 9UT3X8IEqZg
--HG--
extra : rebase_source : 9d968748bd77328eea4ae11e1ae746de9401fb4d
This patch moves all TLS error string handling to the frontend.
Dev-tools doesn't show the same error code as the page does anymore but only the error code as string.
All logging of these error messages has been removed.
Bug #: 1415279
Differential Revision: https://phabricator.services.mozilla.com/D607
--HG--
extra : rebase_source : 61e2d94cb21ef4c02b81448531609205c85a9707
