A previous patch in this bug made the incorrect assumption that we had disabled
the family safety root detection/importing feature by default. In reality, we
enabled it by default in bug 1282871.
In bug 1487258 we moved enterprise root loading to a background thread so as to
not block the main thread. This patch does the same with the family safety
feature.
Differential Revision: https://phabricator.services.mozilla.com/D5484
--HG--
extra : moz-landing-system : lando
I also changed security/certverifier/moz.build a bit while I am here:
* Using '-Xclang' to pass through '-Wall' on clang-cl.
* Now clang-cl will take clang/gcc path because most '-wd****' options have no
effect on clang-cl. '-wd4010' will have an effect, but we already have the
corresponding clang/gcc option ('-Wno-unused-parameter').
--HG--
extra : source : df566a1bd9087cc0bfc03fe19fd9d21bf58f5d9c
nsIAssociatedContentSecurity and nsISecurityInfoProvider are unused as of
bug 832834, so this patch removes them.
Differential Revision: https://phabricator.services.mozilla.com/D5693
--HG--
extra : moz-landing-system : lando
Each instance of CERTCertList creates a PLArena with a chunk size of 2048 bytes,
but only needs space for 3 pointers per certificate in the list. The majority of
the time Gecko uses CERTCertList, we'll store ~3 certificates (although in some
cases we do store a few hundred, such as in tests or the certificate manager).
This is fairly inefficient. This patch starts the process of avoiding using
CERTCertList in Gecko by converting nsNSSCertList (i.e. nsIX509CertList) (as
well as nsNSSCertListEnumerator) to use a more efficient data structure to hold
references to certificates long-term. Future follow-up patches could (and
should) update certificate verification APIs in PSM to avoid CERTCertList as
well.
Depends on D5096
Differential Revision: https://phabricator.services.mozilla.com/D5097
--HG--
extra : moz-landing-system : lando
nsIX509CertList.getRawCertList is only used once and doesn't provide
particularly unique functionality (its one use can easily be re-worked in terms
of other APIs). Removing this API will ease refactoring work to avoid holding
long-lived references to CERTCertList instances in nsNSSCertList.
Differential Revision: https://phabricator.services.mozilla.com/D5096
--HG--
extra : moz-landing-system : lando
Background here is that we are disabling a piece of the downgrade protection in TLS 1.3 and we want to turn it on. We don't know if that is safe, so a pref (and an associated experiment) seems prudent. This is that pref.
Differential Revision: https://phabricator.services.mozilla.com/D4629
--HG--
extra : moz-landing-system : lando
Several source files use DLL_PREFIX/DLL_SUFFIX defines, and they all set
them in moz.build using `DEFINES`. This is problematic for the WSL
build because the quoting gets lost somewhere between bash and cl.exe.
We cannot simply set them globally in moz.configure because their
stringified definitions would conflict with the `set_config` of
DLL_PREFIX/DLL_SUFFIX. Therefore, we globally define
MOZ_DLL_PREFIX/MOZ_DLL_SUFFIX and change all define-related uses of
DLL_PREFIX/DLL_SUFFIX to use their MOZ-equivalents instead.
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
As of bug 1346297, we don't collect telemetry for the family safety root
feature. At this point, it makes the most sense to disable the entire feature by
default.
Differential Revision: https://phabricator.services.mozilla.com/D4994
--HG--
extra : moz-landing-system : lando
As of bug 1346297, we don't collect telemetry for the family safety root
feature. At this point, it makes the most sense to disable the entire feature by
default.
Differential Revision: https://phabricator.services.mozilla.com/D4994
--HG--
extra : moz-landing-system : lando
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
There is a late-breaking EV compatibility concern with cross signatures for EV
certificates:
Firefox's EV handling code always validates EV using the first EV policy OID
expressed in a certificate. For compatibility certificates issued under a cross-
signed root, if the first EV policy OID matches the original Symantec EV policy
OID, then Firefox will attempt to verify that the root CA matches the original
Symantec EV CA -- which it won't, as the root will be one of DigiCert's. Without
a patch, EV treatment will break.
This patch removes all EV policy OIDs for roots mentioned in TrustOverride-
SymantecData.inc, letting the moz::pkix algorithm pick other EV policy OIDs to
validate. I verified that I removed all affected OIDs using the BASH shell
commands:
$ cd security/certverifier
$ grep "CN=" TrustOverride-SymantecData.inc | sed -e 's/.*\(CN=.*\).*/\1/' |
sort | uniq | while read r; do
echo $r; grep "$r" ExtendedValidation.cpp;
done
Reviewers should help me ensure that I did not remove any unexpected EV policy
OIDs.
Differential Revision: https://phabricator.services.mozilla.com/D4709
--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
