Remove reading of "~/Library/Caches/TemporaryItems" from level 3 and update
sandboxing filesystem test to check ~/Library/Caches/TemporaryItems readability.
MozReview-Commit-ID: 6EMzH7brSnp
--HG--
extra : rebase_source : f97b5625da2abda73decc969fc581c2bf858183f
For signing, pykey.py delegates to 3rd party libraries. One of these libraries
expects hash algorithms to be specified in the form "SHA-256" whereas the other
expects "sha256". Consumers of pykey shouldn't need to be aware of this detail.
This patch introduces constants HASH_SHA1, HASH_SHA256, etc. and changes pykey
to determine which string literals to use itself.
MozReview-Commit-ID: 27laM2uXMwJ
--HG--
extra : rebase_source : 9b74f486f7535671fd26c59e3e9cc3b4459f15e0
MozReview-Commit-ID: 9Htv04PfRzb
This introduces pyct.py with the capability of generating Signed Certificate
Timestamps for our test certificates. Also introduces a simple testcase that
should validate correctly under current CT requirements as well as one that does
not validate due to an insufficient number of SCTs.
(Note that "validate" in this case does not refer to the overall TLS handshake
result, because CT is not currently required. It more or less refers to the
value of certificateTransparencyStatus of the SSLStatus of the connection's
securityInfo - see nsISSLStatus.idl.)
--HG--
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.key => security/manager/ssl/tests/unit/test_ct/default-ee.key
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.key.keyspec => security/manager/ssl/tests/unit/test_ct/default-ee.key.keyspec
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.pem => security/manager/ssl/tests/unit/test_ct/default-ee.pem
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.pem.certspec => security/manager/ssl/tests/unit/test_ct/default-ee.pem.certspec
rename : security/manager/ssl/tests/unit/bad_certs/test-ca.pem => security/manager/ssl/tests/unit/test_ct/test-ca.pem
rename : security/manager/ssl/tests/unit/bad_certs/test-ca.pem.certspec => security/manager/ssl/tests/unit/test_ct/test-ca.pem.certspec
extra : rebase_source : 66c5a5e16eeb47c97972248d61a4f1cbadf59a49
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
As requested by James Burton<jb@0.me.uk> and vouched for (via email) by
Lucas Garron <lgarron@google.com>.
MozReview-Commit-ID: HD9laXzJpRg
--HG--
extra : rebase_source : 7c632c6772509a3c4c03cf971ee0f62ad5225275
nsCertOverrideService uses a ReentrantMonitor to protect its inner
state. However, there's no way for nsCertOverrideService's methods to
be re-entered when calling outside code. The use of ReentrantMonitor
appears to be compensating for an unclear division of locking
responsibilities, by enabling every method to simply lock the
ReentrantMonitor upon entrance without care for who might have locked it
beforehand.
Using Mutex is cheaper than ReentrantMonitor, and also forces us to
make explicit who's required to do locking, and who needs to do work
with the lock held.
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
