This modifies crtshToDNStruct.py to be able to produce SPKI or DN-based lists,
and adds a SPKI-search method to TrustOverrideUtils.h.
This also regenerates the TrustOverride files to use the new script.
MozReview-Commit-ID: BhMoJbYXs7Y
--HG--
rename : security/manager/tools/crtshToDNStruct/crtshToDNStruct.py => security/manager/tools/crtshToIdentifyingStruct/crtshToIdentifyingStruct.py
rename : security/manager/tools/crtshToDNStruct/requirements.txt => security/manager/tools/crtshToIdentifyingStruct/requirements.txt
extra : rebase_source : 335d7fc05fa35fbb54ee7ee518b9f4e0c7a00159
The algorithm from https://hg.mozilla.org/mozilla-central/rev/595e27212723
(Bug 1409259) is adapted in this patch from nsNSSCallbacks into the TrustDomain
decisions.
This patch does not change the algorithm to use SPKI matching, nor add the
additional whitelisted intermediates from DigiCert; that will be done in a
separate commit.
This patch also does not update the pre-existing browser chrome test.
MozReview-Commit-ID: 1PdCAqo71bI
--HG--
extra : rebase_source : bc0b1b419dc340a033008d9e9e3b443a2751d5d1
This patch does a few things:
1) It adds a permament test mechanism for the "imminent distrust" trust status
in nsNSSCallbacks: a simple xpcshell test to exercise a clause in the imminent
distrust logic in nsNSSCallbacks' IsCertificateDistrustImminent method.
2) This test removes test_symantec_apple_google_unaffected.js as its
functionality is rolled into the new test_imminent_distrust.js.
3) It updates the Symantec imminent distrust warning algorithm to remove the
validity date exception; this warns of the upcoming distrust for those affected
certs in Firefox 63.
This patch does not attempt to edit the browser chrome test that checks the
console; that is a subsequent patch.
MozReview-Commit-ID: 1HyVLfmEOP7
--HG--
extra : rebase_source : 48c9caae2d26a7e36102b4770c4044101acf0712
This warning is triggered by the use of alignas() in js/public/RootingAPI.h.
Now that GeckoProfiler.h includes RootingAPI.h, this warning is encountered
when building security/certverifier because GeckoProfiler.h is already being
included transitively, through this inclusion path:
CertVerifier.cpp -> CertVerifier.h -> Telemetry.h -> StartupTimeline.h -> GeckoProfiler.h
However, this explanation is not entirely satisfactory, because there seems to
be an existing inclusion path for RootingAPI.h already:
CertVerifier.cpp -> CertVerifier.h -> BasePrincipal.h -> OriginAttributes.h
-> ChromeUtils.h -> ChromeUtilsBinding.h -> RootingAPI.h
So I'm not quite sure why this problem is only starting to happen now.
MozReview-Commit-ID: AFuXpTjdPsi
--HG--
extra : rebase_source : 60f74c8655d15fbc6acbf0ce8a2f208e198e231e
This commit reworks PublicKeyPinningService::ChainHasValidPins and
PublicKeyPinningService::EvalChain to use nsNSSCertList directly. It also
updates nsSiteSecurityService::ProcessPKPHeader. This will be made more
efficient in Bug 1406854, where the call to VerifySSLServerCert gets replaced
with one to GetSucceededCertChain. (Such a change is premeature now because
before Bug 731478 lands this would lead to a session resumption regression
causing pins to not be set properly, which is triggered repeatedly in the
xpcshell tests.)
MozReview-Commit-ID: 1l186n1lXLH
--HG--
extra : rebase_source : 88e40bbf41b324ece762abfa84a758380102e199
extra : histedit_source : addcddf253c2901a25b29f65046908f52df61345
This change is to use the higher-level structure nsNSSCertList when checking
IsChainValid so that we can use the more powerful (and tested) methods of that
object instead of the ad-hoc iterators.
This will also permit the Symantec Distrust code in Bug 1434300 to use these
methods, which keeps the code the same from the earlier Bug 1409259.
MozReview-Commit-ID: B5KmDa1JLE
--HG--
extra : rebase_source : 397d3ef7189eb6f81a1ceaf920464d9e842a8981
extra : histedit_source : 26b22257cb5fcc3389630dd0a1aba24095c46158
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
Also regenerate the test_signed_app.js testcases.
MozReview-Commit-ID: 483uNQT0wuG
--HG--
extra : rebase_source : 4dfddf89d151dceb970a1a9139a5c90e6b578f8c
MOZPSM_NSSDBDIR_OVERRIDE was added in bug 462919 for integration with xulrunner
applications. Upcoming changes we're aiming to make with how PSM handles NSS and
the certificate/key databases (e.g. making the sqlite-backed implementation
mandatory) mean we have to take this feature into account. xulrunner isn't
supported any longer. Searching the web for "MOZPSM_NSSDBDIR_OVERRIDE" yields
two kinds of results: mozilla-central source code and a man page for nss-gui,
which it seems is the only project that ever made use of
MOZPSM_NSSDBDIR_OVERRIDE (and hasn't been updated since 2013, from what I can
tell). I think it's fair to conclude that this isn't a widely-used (let alone
known) feature. To make development easier, we should remove it.
MozReview-Commit-ID: 56vcTYSzDPq
--HG--
extra : rebase_source : 683a65bcd79182c04524562bc26ed5925f5d902b
This is the list of affected Symantec roots and the Apple and Google carved out
sub-CAs being whitelisted. These lists are created using the crtshToDNStruct
tool.
These sub-CAs are to be explicitly whitelisted in the distrust logic being
applied to Symantec root CAs.
Sources:
https://groups.google.com/d/msg/mozilla.dev.security.policy/FLHRT79e3XE/riCrpXsfAgAJhttps://groups.google.com/d/msg/mozilla.dev.security.policy/FLHRT79e3XE/90qkf8jsAQAJ
MozReview-Commit-ID: 3atUGcjG6GD
* * *
[mq]: crtsh_linting
MozReview-Commit-ID: 5gGq5DZXEIi
* * *
[mq]: fix_crtsh_script
MozReview-Commit-ID: JRgkD6OODnO
* * *
[mq]: fix_crtsh_also
MozReview-Commit-ID: Gza1HnYic2I
--HG--
extra : rebase_source : 8ca642964d3ce0308b8081fc52713d9f0104024d
Since we'll need the same structs and mechanisms to work with the Symantec roots,
this patch makes the matching function generic and moves it into a new header,
"TrustOverrides.h".
This also moves the GlobalSignData out into "TrustOverride-GlobalSignData.inc"
and the WoSign/StartCom to "TrustOverride-StartComAndWoSignData.inc".
MozReview-Commit-ID: 2yWcvrngKwr
--HG--
rename : security/certverifier/StartComAndWoSignData.inc => security/certverifier/TrustOverride-StartComAndWoSignData.inc
extra : rebase_source : 26d86765277563ddafd5bbf0f4372ccdb280d062
Modified from bug 1248818 comment 11:
Before this patch, if a user had a smart card (PKCS#11 device) with removable
slots, Firefox would launch a thread for each module and loop, calling
SECMOD_WaitForAnyTokenEvent to be alerted to any insertions/removals. At
shutdown, we would call SECMOD_CancelWait, which would cancel any waiting
threads. However, since that involved calling 3rd party code, we really had no
idea if these modules were behaving correctly (and, indeed, they often weren't,
judging by the shutdown crashes we were getting).
The real solution is to stop relying on PKCS#11, but since that's unlikely in
the near future, the next best thing would be to load these modules in a child
process. That way, misbehaving modules don't cause Firefox to hang/crash/etc.
That's a lot of engineering work, though, so what this patch does is avoids the
issue by never calling SECMOD_WaitForAnyTokenEvent (and thus we never have to
call SECMOD_CancelWait, etc.). Instead, every time Firefox performs an operation
that may be affected by a newly added or removed smart card, it first has NSS
refresh its view of any removable slots. This is similar to how we ensure the
loadable roots module has been loaded (see bug 1372656).
MozReview-Commit-ID: JpmLdV7Vvor
--HG--
extra : rebase_source : d3503d19fa9297106d661a017a38c30969fa39b4
NSS command-line utilities may add a built-in root certificate module with the
name "Root Certs" if run on a profile that has a copy of the module file (which
is an unexpected configuration in general for Firefox). This can cause breakage.
To work around this, PSM now simply deletes any module named "Root Certs" at
startup. In an effort to prevent PSM from deleting unrelated modules
coincidentally named "Root Certs", we also prevent the user from using the
Firefox UI to name modules "Root Certs".
MozReview-Commit-ID: ABja3wpShO9
--HG--
extra : rebase_source : cfc62fb3fabf491a72f009601f3ec6973244642e
Per the root program's request, this patch removes EV treatment for four WoSign
roots:
Common Name: CA 沃通根证书
SHA-256 Fingerprint: D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54
Common Name: Certification Authority of WoSign
SHA-256 Fingerprint: 4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08
Common Name: Certification Authority of WoSign G2
SHA-256 Fingerprint: D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16
Common Name: CA WoSign ECC Root
SHA-256 Fingerprint: 8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02
MozReview-Commit-ID: Bxp9LgvxCsp
--HG--
extra : rebase_source : 065d98cc654d3fb22c17ea185253ce917b48e270
Incidentally, this means we can remove certificateUsageVerifyCA and
certificateUsageStatusResponder from CertVerifier, since we no longer use them.
MozReview-Commit-ID: Bbqn8fShfTm
--HG--
extra : rebase_source : 012cb08dcbe33fe889c9f6824959b1a02cd0bdc7
Bug 1364159 introduced an optimization that attempted to avoid reading from the
user's cached certificate database as much as possible when building a verified
certificate chain. Unfortunately this had the side-effect of not preferring root
certificates in path building, which can result in unnecessarily long chains
(which rather defeats the purpose, since it means more signature verifications).
This patch reverts the functionality changes from that bug but keeps the test
that was added (the test didn't directly test the functionality changes - it's
more of a check that path building will query the cached certificate db when
necessary).
MozReview-Commit-ID: I56THTLUytH
--HG--
extra : rebase_source : 7db9597e25b98942450840519d707046cc660781
In the future, bug 1377940 will make the sqlite-backed databases the default,
but until we're sure this will stick we want to be able to control this with a
Firefox-only change. The use of a preference to configure which format to use
will hopefully allow us to restore the old behavior quickly and relatively
safely if necessary. Note that doing this should be done with care; any changes
made in the sqlite databases after upgrade migration will not be reflected if
we need to go back to the old database format. Thus, user data (imported CAs,
client certificates, and keys) can be lost.
MozReview-Commit-ID: tkovdiCU9v
--HG--
extra : rebase_source : e74358bd65afb5844fa8fc5b729eba2bbc5bb2db
Also adds a mozilla/ResultExtensions.h header to define the appropriate
conversion functions for nsresult and PRResult. This is in a separate header
since those types are not available in Spidermonkey, and this is the pattern
other *Extensions.h headers follow.
Also removes equivalent NS_TRY macros and WrapNSResult inlines that served the
same purpose in existing code, and are no longer necessary.
MozReview-Commit-ID: A85PCAeyWhx
--HG--
extra : rebase_source : a5988ff770888f901dd0798e7717bcf6254460cd
The sqlite-backed NSS database implementation requires explicitly setting some
kind of pin (password, really). To maintain behavior compatibility with the old
database implementation, we set the pin to the empty string as necessary.
Previously this would only happen on Android (NSS_DISABLE_DBM builds), but
because we're moving towards using the sqlite-backed implementation on all
platforms, we should enable this code everywhere and move it to a more central
location.
This also fixes some now-unnecessary test behavior.
MozReview-Commit-ID: KKtxmvOZt78
--HG--
extra : rebase_source : 0de061928bf63b62386a4e244b326610d32cd122
In a profile, loading the loadable roots PKCS#11 module (i.e. the built-in root
CA module) accounted for about 60% of the time to initialize PSM/NSS. Since we
only need the roots module loaded when we're actually looking for an issuing
certificate or querying a certificate's trust, we can do the load
asynchronously (where it hopefully finishes before we actually need it, because
otherwise we'll have to wait anyway).
MozReview-Commit-ID: JyY6NtpQAUj
--HG--
extra : rebase_source : f63a697b18a409dd042289afa2b727b09f81f19f
As a result of CNNIC issuing an unconstrained intermediate certificate that
misissued an end-entity certificate for google.com (see bug 1146026 and
bug 1177209), we implemented a system that would in theory enable Firefox to
continue to trust certificates that were valid at the time but not newly issued
certificates. This consisted of a whitelist added in bug 1151512. The CNNIC
roots have since been removed from NSS in bug 1380868. We can now remove the
whitelist in Firefox.
MozReview-Commit-ID: 7VXOuvwzbct
--HG--
extra : rebase_source : 20e6e39c40417a9b7f2962e06cf9de85e3e08ee8
Disable EV treatment in preparation for removing the CNNIC root certificates
from NSS.
MozReview-Commit-ID: Anz1vXqABUM
--HG--
extra : rebase_source : 694d8321b9f5994fe57e81cb3169681c5e491910
The CA, Comodo, has requested that we remove the UTN-USERFirst-Hardware
root certificate from NSS. First remove EV treatment.
MozReview-Commit-ID: 8OTsevYOuKq
--HG--
extra : rebase_source : aabb219bcbee1c667bae29df618449df4b50d548
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
GetHostNameRaw() returns a char* string, which is less safe and ergonomic
compared to the Mozilla string classes. GetHostName() can be used instead.
MozReview-Commit-ID: GYvTnISNN35
--HG--
extra : rebase_source : da257f5fba2c26cd92d932c3d1d363458b84a65b
The "Swisscom Root EV CA 2" root is no longer in use and will be removed from
the built-in root CA list. However, we have to remove its EV treatment first.
MozReview-Commit-ID: 2TZRt5px7bl
--HG--
extra : rebase_source : 68902555ffe62a973cfaac3af531e96aa288a339
CERT_CreateSubjectCertList is not an inexpensive function call, since it
enumerates the certificate database (i.e. reads from disk a lot). If we're
verifying for a TLS handshake, however, we should already have in memory a
certificate chain sent by the peer (there are some cases where we won't, such as
session resumption (see bug 731478)). If we can, we should use those
certificates before falling back to calling CERT_CreateSubjectCertList.
MozReview-Commit-ID: ASjVGsELb1O
--HG--
extra : rebase_source : 1efc635d4a98079c87f77ef3794e4b2f20eec59f
In general, the changes here attempt to:
1. Fix up the style to match modern PSM style.
2. Shorten unnecessarily long code.
3. Reduce global scope pollution.
MozReview-Commit-ID: GFyqFgV0RLD
--HG--
extra : source : 8cb5ee464e42ff07324922abeffef00c7cb1fb1b
MSVC 2017 headers aren't warning free at the -Wall level.
Since PSM enables -Wall in some moz.build files, this breaks
--enable-warnings-as-errors builds.
As a temporary measure, disable enough warnings to get working builds.
MozReview-Commit-ID: G0oUsAYYct2
--HG--
extra : rebase_source : dc37783c89e66a54510c9940f9eaa5a4340ef43e
MozReview-Commit-ID: Gay4bliuiDc
This modifies getCTKnownLogs.py to inject 3 debug-only Certificate Transparency
log keys and 2 organizations ("Mozilla Test Org 1" and "2") for use with
integration tests. Also updates CTKnownLogs.h as generated by the python script.
The debug logs use the "default", "secp256r1", and "alternate" keys that are
already present in our testing infrastructure (see pykey.py).
--HG--
extra : rebase_source : 3d4fc736f840cd080fab6b8c6c5b53cc9361abf2
Firefox essentially does not support running NSS in FIPS mode any longer. This
has always been the case on Android from what I can tell and it has been the
case on OS X since at least version 34 (see bug 1047584). It became the case on
Windows as of version 53 (see bug 1295937). Unfortunately, before this patch,
if a user attempted to run an affected version of Firefox using a profile
directory containing an NSS database collection that had FIPS enabled, NSS
initialization would fail and fall back to running in no DB mode, which had the
side-effect of making any saved passwords and certificates unavailable. This
patch attempts to detect and work around this failure mode by moving the
PKCS#11 module DB (which is where the FIPS bit is set) to a backup location and
basically running with a fresh, non-FIPS module DB. This allows Firefox to
initialize NSS with the preexisting key and certificate databases available.
MozReview-Commit-ID: 1E4u1ngZyRv
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting.js => security/manager/ssl/tests/unit/test_broken_fips.js
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key3.db => security/manager/ssl/tests/unit/test_broken_fips/key3.db
extra : rebase_source : 887f457e998d6e57c6536573fbe3cb10547fe154
Calling VFY_VerifyDigestDirect causes the provided SECKEYPublicKey to be
reimported to the softoken regardless of if it already exists on it. EC keys
must be verified upon import (to see if the point is on the curve to avoid some
small subgroup attacks), and so repeatedly doing this with a static key (say,
for example, a key corresponding to a built-in certificate transparency log) is
inefficient. This patch alters the certificate transparency implementation to
import these keys each once and then use PK11_Verify for ECDSA signature
verification, which doesn't have the same drawback.
Since this change causes CertVerifier to hold an NSS resource (via its
MultiLogCTVerifier having a list of CTLogVerifier, each of which now has a
SECKEYPublicKey), nsNSSComponent has to make sure it goes away before shutting
down NSS. This patch ensures this happens in nsNSSComponent::ShutdownNSS().
MozReview-Commit-ID: 6VSmz7S53y2
--HG--
extra : rebase_source : 4994db9de80a6c1aec3d7e322ff30d040140ce92
The default OCSP timeout for soft-fail DV is still 2 seconds. This patch makes
it configurable on the interval (0, 5] seconds.
The default OCSP timeout for EV and hard-fail DV is still 10 seconds. This patch
makes it configurable on the interval (0, 20] seconds.
MozReview-Commit-ID: CPd8pwYrJhj
--HG--
extra : rebase_source : 45bd7d06ea013f0a776ea18be9408dedb18271d8
(adapted from bug 1349762 comment 0)
Google Trust Services (GTS) recently purchased two roots from GlobalSign that
are both enabled for EV treatment: "GlobalSign Root CA - R2" and "GlobalSign ECC
Root CA - R4".
However, GTS does not have an EV audit, so we are going to turn off EV treatment
for both of those root certificates.
But "GlobalSign Root CA - R2" has intermediate cert "GlobalSign Extended
Validation CA - SHA256 - G2" that continues to be controlled by GlobalSign, to
be used to migrate their customers off dependence on that root.
This patch removes EV treatment for "GlobalSign ECC Root CA - R4". It also
removes EV treatment for all chains rooted in "GlobalSign Root CA - R2" unless
the "GlobalSign Extended Validation CA - SHA256 - G2" intermediate is in the
chain.
MozReview-Commit-ID: Ej9L9zTwoPN
--HG--
extra : rebase_source : 575f1a48646cf728d879d0cf53c888654e4a32ad
The NSS Base64 functions are less safe and convenient to use than the XPCOM ones.
They're also an unnecessary dependency on NSS.
The NSS Base64 functions behave slightly differently than the XPCOM ones:
1. ATOB_ConvertAsciiToItem() / NSSBase64_DecodeBuffer() silently ignore invalid
characters like CRLF, space and so on. Base64Decode() will return an error
if these characters are encountered.
2. BTOA_DataToAscii() will produce output that has CRLF inserted every 64
characters. Base64Encode() doesn't do this.
For the reasons listed below, no unexpected compatibility issues should arise:
1. AppSignatureVerification.cpp already filters out CRLF and spaces for Manifest
and Signature values before decoding.
2. ExtendedValidation.cpp is only given what should be valid hard-coded input to
decode.
3. ContentSignatureVerifier.cpp already splits on CRLF for when it needs to
decode PEM certs. Spaces shouldn't be likely.
For Content-Signature header verification, examination of real input to a
running instance of Firefox suggests CRLF and spaces will not be present in
the header to decode.
4. nsCryptoHash.cpp encode is affected, but we actually don't want the CRLF
behaviour.
5. nsDataSignatureVerifier.cpp decode is affected, but we add whitespace
stripping to maintain backwards compatibility.
6. nsKeygenHandler.cpp encode is affected, but the previous CRLF behaviour was
arguably a bug, since neither WHATWG or W3C specs specified this.
MozReview-Commit-ID: IWMFxqVZMeX
--HG--
extra : rebase_source : 4863b2e5eabef0555e8e1ebe39216d0d9393f3e9
The only unhandled call updates nsHTTPListener::mHttpResponseContentType, but
nothing actually uses the value of mHttpResponseContentType.
MozReview-Commit-ID: FQXESvoO2ZN
--HG--
extra : rebase_source : 547158311de136054acff2539ea6a8bdbfb8227b
Changed |print("enum ID : uint32_t {", file=output)| to |print("enum HistogramID : uint32_t {", file=output)| at line 53 of the file |toolkit/components/telemetry/gen-histogram-enum.py|, and then replaced all the textual occurrences of |Telemetry::ID| to |Telemetry::HistogramID| and |ID| to |HistogramID| in 43 other files.
mozilla::TimeStamp is generally superior to PRIntervalTime, and switching lets
us get rid of yet another NSPR dependency.
This patch also:
1. Gets rid of code in nsNSSHttpRequestSession::createFcn() that limits the
max OCSP timeout. This is a relic from when NSS was used for OCSP requests,
and is no longer necessary.
2. Converts all uses of PR_NOT_REACHED() to MFBT asserts while we're nearby.
MozReview-Commit-ID: KvgOWWhP8Km
--HG--
extra : rebase_source : ea832a1acc4423cf6cfc98862af6b1c29a83ce56
Unfortunately, this doesn't cover delegated OCSP responder certificates. While
gathering telemetry on the use of SHA-1, we encountered bug 1183822 (basically,
that the method of gathering telemetry was causing OCSP verification failures
due to delegated responders signed with SHA-1). As a temporary solution, we
changed the verifier to always allow SHA-1 for OCSP certificates when verifying
an OCSP response. Consequently, we now have no idea what the compatibility
impact of disabling SHA-1 in OCSP responder certificates will be, so it's
probably not a good idea to do that right now.
Even if someone does manage to forge an OCSP responder certificate using a SHA-1
collision, they will have about as much power as an active network attacker
blocking OCSP requests or injecting bad stapled OCSP responses, so this isn't a
disaster.
MozReview-Commit-ID: 10r23W1APiR
--HG--
extra : rebase_source : dc003c4812677c40882506b1b6b1e1f68d7e6e92
PR_ASSERT() is an unnecessary dependency on NSPR.
We can use MOZ_ASSERT() instead, which accomplishes the same task but doesn't
depend on NSPR.
MozReview-Commit-ID: 9gyWUkv3KxQ
--HG--
extra : rebase_source : 313ce6c8de3db3ce72635e37f09d28316ae02c51
(Note that content signature verification does not use the unified certificate
verifier and thus will still consult OneCRL.)
MozReview-Commit-ID: 6KvHOngpabT
--HG--
extra : rebase_source : 601f4d8d1c66befb77d0c07a2d84f3f04416f996
The PR_SetError() + PR_GetError() pattern is error prone and unnecessary.
Also fixes Bug 1254403.
MozReview-Commit-ID: DRI69xY4vxC
--HG--
extra : rebase_source : aa07c0dfb5cc2a203e772b415b7a75b27d9bad3c
Crash reports indicate LoadExtendedValidationInfo is failing. This adds
annotated crashes that should point us at exactly what is failing. (Note that
because Nightly builds aren't built with DEBUG defined, the majority of
LoadExtendedValidationInfo isn't even run, so we can ignore that code.)
--HG--
extra : amend_source : 0940efc65bb706b572f0699ab5c66b82d6591d30
Previously PSM would load EV information on-demand (i.e. just before verifying a
certificate). This simplifies this operation, removes a dubious optimization
(loading the EV information on another thread while opening a network
connection), and relocates the loading operation to when we are likely to have
good disk locality (i.e. when we've just loaded the built-in roots module).
This also removes the now-unused MOZ_NO_EV_CERTS build flag.
MozReview-Commit-ID: 8Rnl4ozF95V
--HG--
extra : rebase_source : 5b2e76079c256f7e3c55b1d4ec0d9f654fec44f6
Previously PSM would load EV information on-demand (i.e. just before verifying a
certificate). This simplifies this operation, removes a dubious optimization
(loading the EV information on another thread while opening a network
connection), and relocates the loading operation to when we are likely to have
good disk locality (i.e. when we've just loaded the built-in roots module).
This also removes the now-unused MOZ_NO_EV_CERTS build flag.
MozReview-Commit-ID: 8Rnl4ozF95V
--HG--
extra : rebase_source : 344b68c81af1ed3fb038e4e96c3c50e939d32c3d
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
This may save us some memory and reduce the number of static constructors.
MozReview-Commit-ID: FNIkiFtRjfK
--HG--
extra : rebase_source : d2781f11db7a1f8370c0e6c6c8e6f0fb52122614
The functions aren't necessary now that we have BitwiseCast.
MozReview-Commit-ID: 2nzOuwAop4Y
--HG--
extra : rebase_source : 0cb2c16f484a81b2e77384564973b58ac2d10fb9
The functions aren't necessary now that we have BitwiseCast.
MozReview-Commit-ID: 2nzOuwAop4Y
--HG--
extra : rebase_source : 196449249eec75b8eb10e59662231c3f4e83c268
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Previously this implementation would use the expected names of the built-in
module and slot to get a handle on them. This doesn't work on distributions that
use other names. The new implementation searches through the slots from the
default module list for one where PK11_HasRootCerts returns true (which
indicates that NSS considers that slot to contain the default built-in root
list).
MozReview-Commit-ID: LmX27hQfFJU
--HG--
extra : rebase_source : 50383dcc77257fe08ce2c7d908e95cda7c4bbe9d
Scoped.h is deprecated in favour of the standardised UniquePtr.
This patch removes use of Scoped.h everywhere in PSM except ScopedNSSTypes.h,
which is exported. Other consumers of ScopedNSSTypes.h can move off Scoped.h
at their own pace.
This patch also changes parameters and return types of various functions to make
ownership more explicit.
MozReview-Commit-ID: BFbtCDjENzy
--HG--
extra : transplant_source : %0B%C7%9F%40%FA9%A4%F2%5E%0D%92%1C%A6%A49%94%C3%7E%1Cz
The function basically duplicates existing Mozilla string class functionality.
MozReview-Commit-ID: 9IFEXuT9cW1
--HG--
extra : rebase_source : 0d0c4492a63f7a168b6092fdb2e1bf8ec09d5308
mozilla::BitwiseCast does the same thing, but provides static asserts that
mitigate some of the risk of using reinterpret_cast.
MozReview-Commit-ID: ENQ8QC6Nl9o
--HG--
extra : rebase_source : c1725c8363c0f7f9877601de5ab5f152ef4d0439
These uses of reinterpret_cast are either pointless, or can be removed via
refactoring.
MozReview-Commit-ID: Aw2rlJfrT6J
--HG--
extra : rebase_source : 243d6c38eedc086c59d47c93d4a57cb6a922910a
ScopedPK11Context is based on Scoped.h, which is deprecated in favour of the
standardised UniquePtr.
MozReview-Commit-ID: HE8UY1hOuph
--HG--
extra : transplant_source : 4%BF%81M%09Q-%2A%E6%04%86i%18%1B%3CL%90%88%04%C7
The (more) modern Mozilla string classes can be used instead, which at the very
least provide built in automatic memory management and performance improvements.
MozReview-Commit-ID: 4l2Er5rkeI0
--HG--
extra : transplant_source : %A1%16%AB%02m%CA%25HfW%40%96Mq%0D%F0%91%9C%99%29
ScopedPK11SlotInfo is based on Scoped.h, which is deprecated in favour of the
standardised UniquePtr.
Also changes PK11SlotInfo parameters of various functions to make ownership more
explicit, and replaces some manual management of PK11SlotInfo pointers.
MozReview-Commit-ID: JtNH2lJsjwx
--HG--
extra : rebase_source : 9d764e0dd3a1f2df14c16f8f14a3c5392770c9a1
ScopedCERTCertList is based on Scoped.h, which is deprecated in favour of the
standardised UniquePtr.
Also changes CERTCertList parameters of various functions to make ownership more
explicit.
MozReview-Commit-ID: EXqxTK6inqy
--HG--
extra : transplant_source : %9B%A9a%94%D1%7E%2BTa%9E%9Fu%9F%02%B3%1AT%1B%F1%F6
Also converts the longer |UniquePtr<char, void(&)(void*)> foo(..., PORT_Free)|
to the shorter and equivalent |UniquePORTString foo(...)|.
MozReview-Commit-ID: LlrTNUYBP4V
--HG--
extra : transplant_source : afU%FB%0EC%3E%E0pm%A3-%0E%C8%83%CF%0A%B1%9E%ED
Before this patch, the default policy for the use of SHA1 in certificate
signatures was "allow all" due to compatibility concerns.
After gathering telemetry, we are confident that we can enforce the policy of
"allow for locally-installed roots" (or certificates valid before 2016) without
too much breakage.
MozReview-Commit-ID: 8GxtgdbaS3P
--HG--
extra : rebase_source : d1bed911f2d5d40229ea06556fee0848668e98b6
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
someone fixes the underlying problem someday. However, there are tons
of ignored warnings in security/certverifier, so I guess the workaround
in this patch is par for the course.
MozReview-Commit-ID: 7GZ9RpkxnwT
--HG--
extra : rebase_source : 023a438b6458fb4859018cde421d51072f0f0490
When a built-in root certificate has its trust changed from the default value,
the platform has to essentially create a copy of it in the read/write
certificate database with the new trust settings. At that point, the desired
behavior is that the platform still considers that certificate a built-in root.
Before this patch, this would indeed happen for the duration of that run of the
platform, but as soon as it restarted, the certificate in question would only
appear to be from the read/write database, and thus was not considered a
built-in root. This patch changes the test of built-in-ness to explicitly
search the built-in certificate slot for the certificate in question. If found,
it is considered a built-in root.
MozReview-Commit-ID: HCtZpPQVEGZ
--HG--
extra : rebase_source : 759e9c5a7bb14f14a77e62eae2ba40c085f04ccd