Firefox sometimes caches intermediate certificates from verified connections in
case they are useful in the future. This operation involves modifying the NSS
cert database, and so should only be done on the socket thread (ideally when it
is idle).
Differential Revision: https://phabricator.services.mozilla.com/D106230
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
Otherwise the OCSP channel that tries to check the certificate for the DoH
server will also try to use TRR leading to DNS failures.
Differential Revision: https://phabricator.services.mozilla.com/D106884
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
When osclientcerts obtains or uses an OS handle on a private key, the
underlying implementation may display some sort of authentication or pin
prompt. In some cases, caching this handle rather than obtaining it multiple
times can prevent multiple prompts. So, this is what this patch does.
Differential Revision: https://phabricator.services.mozilla.com/D106222
2021-02-19 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* lib/nss/nss.h, lib/softoken/softkver.h, lib/util/nssutil.h:
Set version numbers to 3.62 final
[a8e045a9fff6] [NSS_3_62_RTM] <NSS_3_62_BRANCH>
2021-02-15 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* .hgtags:
Added tag NSS_3_62_BETA1 for changeset a5c857139b37
[145c269c82d6] <NSS_3_62_BRANCH>
Differential Revision: https://phabricator.services.mozilla.com/D105739
This is only used for CORS preflight requests. It is controlled by a pref.
Connections that server such request will be isolated from other anonymous connections.
Differential Revision: https://phabricator.services.mozilla.com/D96775
```
2021-02-05 Danh <congdanhqx@gmail.com>
* gtests/manifest.mn:
Bug 1688374 - Fix parallel build NSS-3.61 with make. r=kjacobs
[a5c857139b37] [NSS_3_62_BETA1]
2021-02-05 Robert Relyea <rrelyea@redhat.com>
* lib/libpkix/pkix/util/pkix_tools.c:
Bug 1682044 pkix_Build_GatherCerts() + pkix_CacheCert_Add() can
corrupt "cachedCertTable"
Patch by Andrew Cagney Preliminary Review by Ryan Sleevie Tested
against all.sh rrelyea. r=kjacobs
(this bug is old)
pkix_Build_GatherCerts() has two code paths for creating the list
"certsFound":
pkix_CacheCert_Lookup() this sets "certsFound" to a new list
"certsFound" and "cachedCertTable" share items but not the list
pkix_CacheCert_Add(pkix_pl_Pk11CertStore_CertQuery()) this sets
"certsFound" to a new list; and then adds the list to
"cachedCertTable" "certsFound" and "cachedCertTable" share a linked
list
Because the latter doesn't create a separate list, deleting list
elements from "certsFound" can also delete list elements from within
"cacheCertTable". And if this happens while pkix_CacheCert_Lookup()
is trying to update the same element's reference, a core dump can
result.
In detail (note that reference counts may occasionally seem off by
1, its because data is being captured before function local
variables release their reference):
pkix_Build_GatherCerts() calls pkix_pl_Pk11CertStore_CertQuery()
(via a pointer) to sets "certsFound":
PKIX_CHECK(getCerts (certStore, state->certSel, state->verifyNode,
&nbioContext, &certsFound, plContext), PKIX_GETCERTSFAILED);
it then calls:
PKIX_CHECK(pkix_CacheCert_Add (certStore, certSelParams,
certsFound, plContext), PKIX_CACHECERTADDFAILED);
[dafda4eee75c]
```
Differential Revision: https://phabricator.services.mozilla.com/D105209
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
Bug 1583610 modified the cipher suite ordering on ARM devices to prefer
ChaCha20/Poly1305 with the assumption that hardware support for AES wouldn't be
available. However, because there are ARM devices with hardware support for
AES, this patch makes this only happen when that support isn't available.
Differential Revision: https://phabricator.services.mozilla.com/D104897
Loading an accumulated set of crlite stashes can take some time. To address
this, this patch dispatches an asynchronous background task to read the
accumulated set of crlite stashes in a way that doesn't block certificate
verification. Of course, this means that the stash information won't
necessarily be available for the first few verifications. This shouldn't be a
security concern as long as the crlite filter is no more than 10 days out of
date (the maximum lifespan of an OCSP response, which is what Firefox relies on
currently in release). Note that currently crlite filters as published by
remote settings regularly end up being more than 10 days old, which will be
addressed in https://github.com/mozilla/crlite/issues/153. Note further that
crlite is currently not being enforced by default on any channel, so making
this change now is not a security concern.
Differential Revision: https://phabricator.services.mozilla.com/D104447