Various strings, like nsISupports, appear many times in XPT data. This
patch adds a cache so we don't write the same string multiple times.
MozReview-Commit-ID: 6buBrXwHqQz
--HG--
extra : rebase_source : 54dea83a9134710c5600828ab68ef3f935f46afd
The name of this class is wrong, but my next patch will make it
actually cache. This patch should not change the behavior.
MozReview-Commit-ID: CMf6Chkeex1
--HG--
extra : rebase_source : a6d5688124b75aef8ed35f811003cf49b8b4e136
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : 592d13349a8c4627c7ce3146ec592f577b39f3cc
This adds the 4 digicert CAs to our whitelist as specified in Google's details
on the Chromium version of this plan [1].
[1] c022914eb2/net/data/ssl/symantec/README.md
MozReview-Commit-ID: BR7t1UheKeS
--HG--
rename : security/certverifier/TrustOverride-AppleGoogleData.inc => security/certverifier/TrustOverride-AppleGoogleDigiCertData.inc
extra : rebase_source : 328a3b03a2c40fdf77497430481aa01df6f0059d
Because of the DigiCert-controlled sub-CAs and managed-CAs identified as also
needing to be whitelisted [1], and that those CAs are using an increasing number
of certificates all with different Subjects (but identical public keys) [2][3],
we will have to whitelist on SPKI rather than subject DN.
This makes the security/manager/ssl/tests/unit/test_symantec_apple_google.js
integration test different, as it now uses a real Google certificate that is
in the whitelist with only a cert verification rather than a full connection
test.
This patch does not add the DigiCert SPKIs to the list; I will do that in its
own patch.
[1] https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md
[2] https://chromium-review.googlesource.com/c/chromium/src/+/916730
[3] https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee
MozReview-Commit-ID: 4qVeogDbSb
--HG--
extra : rebase_source : 6912963abe7d05bf2a944fae1209512650763032
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 browser console test for imminent distrust relies upon certs inserted
into build/pgo/certs/cert8.db and key3.db [1], and seemed angry when adding new
certs with certutil bumping those to cert9 and key4 formats. Since time is
getting to be of-the-essence with Bug 1434300, I've filed Bug 1439378 to re-
enable this test post-landing.
[1] https://hg.mozilla.org/mozilla-central/rev/98b1272e170c
MozReview-Commit-ID: I4SIiqc5AqH
--HG--
extra : rebase_source : 06295cbed14f2a793162073e707e14026ea69625
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
In Javascript, we re-clamp timers to ensure they stay the same. Because of double imprecision
sometimes they don't stay the same, and are clamped downwards. If that happens we detect it,
and if we were originally off by an epsilon from a clamped value, we accept the value in the
name of double imprecision.
However, the epsilons were originally chosen somewhat arbitrarily. They worked for small
numbers, where imprecision from doubles were very small. But large doubles have much less
precise fractional parts. So the epsilons were too small for large numbers where the
imprecision was larger.
In Bug 1435296 we stopped reducing the precision of CSS Animations by default, and changed
the test to throw an error if they WERE rounded. After we increased the epsilon in this
patch, we began to see false positives - we were getting values that were not rounded, but
happened to be within the epsilon window and thus appeared rounded. We change the check so
instead of seeing if an Animation is not rounded, and erroring if it is, to accepting any
value.
MozReview-Commit-ID: HnYYo4cuv96
--HG--
extra : rebase_source : 19993a4684a19a646dff43147149e9fc52f2cd0b
This adds the 4 digicert CAs to our whitelist as specified in Google's details
on the Chromium version of this plan [1].
[1] c022914eb2/net/data/ssl/symantec/README.md
MozReview-Commit-ID: BR7t1UheKeS
--HG--
rename : security/certverifier/TrustOverride-AppleGoogleData.inc => security/certverifier/TrustOverride-AppleGoogleDigiCertData.inc
extra : rebase_source : 406e42e805b3778ccce7ee85b18d5dea93e32b95
Because of the DigiCert-controlled sub-CAs and managed-CAs identified as also
needing to be whitelisted [1], and that those CAs are using an increasing number
of certificates all with different Subjects (but identical public keys) [2][3],
we will have to whitelist on SPKI rather than subject DN.
This makes the security/manager/ssl/tests/unit/test_symantec_apple_google.js
integration test different, as it now uses a real Google certificate that is
in the whitelist with only a cert verification rather than a full connection
test.
This patch does not add the DigiCert SPKIs to the list; I will do that in its
own patch.
[1] https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md
[2] https://chromium-review.googlesource.com/c/chromium/src/+/916730
[3] https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee
MozReview-Commit-ID: 4qVeogDbSb
--HG--
extra : rebase_source : abbdd432b190d059a3b2ceeccf89b85a12c214dd
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 : 9ae4999ceea2d4092119fe81b787c4d66a5e17b1
The browser console test for imminent distrust relies upon certs inserted
into build/pgo/certs/cert8.db and key3.db [1], and seemed angry when adding new
certs with certutil bumping those to cert9 and key4 formats. Since time is
getting to be of-the-essence with Bug 1434300, I've filed Bug 1439378 to re-
enable this test post-landing.
[1] https://hg.mozilla.org/mozilla-central/rev/98b1272e170c
MozReview-Commit-ID: I4SIiqc5AqH
--HG--
extra : rebase_source : 6cac70e494c284314bf62d2e0c856a0d9a98831e
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 : f1c6d00e16682f9303b8b2bfdf1fe5773c515ac5
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 : 3955e3dcd9a21421105d97bd65d3965041de9b8c
Use the current principal to get the origin, so things work under e10s.
Also reorganize some of the code in checkIdentity.
MozReview-Commit-ID: 2heqVMQ7vam
--HG--
extra : rebase_source : 7e67d223aaf366115ac2b3e35bfcb56fba9766f2
The second notification is needless and can cause deadlocks. The code
previously tried to ensure it wasn't sent, but didn't account for
the possibility of a call to hidePopup() causing the 'popuphidden'
event to be handled synchronously.
MozReview-Commit-ID: BiMOFMMudIH
--HG--
extra : rebase_source : 060319da29f313d30b380dcecd6fc73ff5a807e8
Track connection status at various points during Browser Toolbox startup. If
connecting takes a long time or triggers an error, the status panel is revealed
with the most recent message displayed.
MozReview-Commit-ID: H8240rv3KRe
--HG--
extra : rebase_source : 7c2c10c710095ede7d1b9c1ac87ca21bd3deb969
Previously, in IsInRanges, aIntervalIndex could have values between -1..length-1.
After the change, the values are in range 0..length, which makes it possible to use unsigned ints and avoid UB.
MozReview-Commit-ID: 39SIzXRHv91
--HG--
extra : rebase_source : d0efebb4bc13694eb7d2048cd2eae2d6386238cf
This was oversight when landing Bug 1419581, coupled with dedicated
testing by Grisha. We don't expose all CONFIG values as DEFINES by
default, and I forgot to add the relevant value to the exposure list.
MozReview-Commit-ID: GUYNWampBAJ
--HG--
extra : rebase_source : f946f2630f2e9120d03b05a4677815e73ab6851a
The output formatters provided by mozlog are well-documented in the
online help guide, but this information is not available to users in the
CLI. The `add_logging_group` method extends the consuming project's
command-line interface without referencing mozlog itself. This means
consumers may not have a means to discover the additional information,
and even in cases where they can infer this connection, there is no
indication of the stability of the behavior.
Extend the description of the built-in output formatters to explain
their origin and reference the relevant documentation.
--HG--
extra : rebase_source : 5e7420f8d1589dccc335b0a48c8967d4928f959f
Andrew McCreight
Jared Wein
Gijs Kruitbosch
Valentin Gosu
nbeleuzu@mozilla.com
J.C. Jones
Michael Ratcliffe
Kit Cambridge
Nico Grunbaum
Thom Chiovoloni
Tom Ritter
shindli
Mark Banner
Jim Chen
Martin Stransky
Botond Ballo
Ursula Sarracini
J. Ryan Stinnett
Csoregi Natalia
Manish Goregaokar
Rob Wood
Adrian Wielgosik
Ethan Glasser-Camp
Nick Alexander
Connor Masini
Ciure Andrei
Mike Pennisi
Milan Knežević