The Mozilla string classes don't require manual memory management and
automatically keep track of length, making them a safer choice than raw C
strings.
MozReview-Commit-ID: EwCiiP9EhDr
--HG--
extra : transplant_source : %05%D4%B6s%C1%DBye%2C3%C3%85%DB%22%91h%B4%27%E1l
1. encrypt() and decrypt() are C++ only.
The only callers are in SecretDecoderRing.cpp, and binary add-ons aren't
supported anymore. So, there is no need for these methods to be defined in the
IDL, and they should be treated as private to the nsISecretDecoderRing
implementation.
2. nsISecretDecoderRingConfig has never been implemented.
The interface and implementation are currently just bloat. If there is a need
for specifying the window for prompts in the future, a better way can be devised
then.
MozReview-Commit-ID: 1wXCDTIBJA2
--HG--
extra : transplant_source : %D7%27%5E3%BF%E9%16%0E%A3%8B%E1%8E%ADj%3F%25%B3i%9Al
The interfaces defined within have basically nothing to do with Necko.
MozReview-Commit-ID: 5J4D3w61Yry
--HG--
rename : netwerk/base/nsISecretDecoderRing.idl => security/manager/ssl/nsISecretDecoderRing.idl
extra : transplant_source : %AAP%26%5D%DE%ED%F6Q%C4%5Eia%F1%84T%8D%A7E%8Aw
There are currently two ways of naming files containing the implementation of
interface nsIFoo:
1. nsFoo.(cpp|h) (previous convention)
2. Foo.(cpp|h) (new convention)
nsSDR.(cpp|h) matches neither of these. Renaming the files to follow convention
makes it easier to discover what the files implement, and increases codebase
consistency.
MozReview-Commit-ID: 3ThPxPouiie
--HG--
rename : security/manager/ssl/nsSDR.cpp => security/manager/ssl/SecretDecoderRing.cpp
rename : security/manager/ssl/nsSDR.h => security/manager/ssl/SecretDecoderRing.h
extra : transplant_source : %7D%FC%AD%9C%E8%AD%CFz%FE%F2%D6%1E%A0%0A%06sk%3D%AD%AC
This makes a lot of code more compact, and also avoids some redundant nsresult
checks.
The patch also removes a handful of redundant checks on infallible setters.
--HG--
extra : rebase_source : f82426e7584d0d5cddf7c2524356f0f318fbea7d
This patch adds tests for the core aspects of the client authentication code,
mainly to ensure the client auth process even works.
MozReview-Commit-ID: DzV4BuwlrDE
--HG--
extra : rebase_source : 43224d3159964f02b175e8c54491b2cabba2cb8a
Update the prior patch to use MOZ_RELEASE_ASSERT so that we cleanly crash
if there's still an error somewhere in this logic, instead of deadlocking
on beta (but crashing on aurora).
MozReview-Commit-ID: InttEcC55Dn
--HG--
extra : rebase_source : c79726acbaf1eb8374500f43cd3c7d33362466ad
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
This fixes two issues:
1. nsNSSShutDownList::evaporateAllNSSResources could deadlock by acquiring
sListLock and then the singleton's mNSSActivityStateLock in
nsNSSActivityState::restrictActivityToCurrentThread.
2. Calling UnloadLoadableRoots before
nsNSSShutDownList::evaporateAllNSSResources could result in removing modules
that were still in use, causing assertion failures and potential crashes.
MozReview-Commit-ID: 8ZgZTVw7sWh
--HG--
extra : rebase_source : 43452add4612b3d12c2b877c3a38169c9676f445
It appears the wallet code was not included during the initial 2007 import of
code from CVS to Mercurial, so anything referencing wallet has been dead code
ever since.
MozReview-Commit-ID: BRTd1M0DsT0
--HG--
extra : transplant_source : %BC%FC%05%AE%B5%8C%DC%21J%DC%B4%B17M%19%AA%F3%B9%05L
ScopedAutoSECItem is useful for:
1. Removing manual memory management.
2. Getting rid of this pattern:
> UniqueSECItem item(SECITEM_AllocItem(nullptr, nullptr, 0));
While this pattern works, ScopedAutoSECItem is slightly superior in that it
doesn't unnecessarily cause a SECItem to be allocated from the heap.
MozReview-Commit-ID: 8DPD9gtzeru
--HG--
extra : transplant_source : %10l%27C%12%3E%08%85q%06%1A%FC%FB%DE%F9%A3%99%0AN%A1
chooseCertificate() currently uses a concatenation of the Common Name of the
server cert and the port of the server to allow the user to identify the server
requesting client authentication. Unfortunately, this approach is flawed, since
it doesn't take into account things like SAN entries, which might be very
different from the CN.
Using the hostname instead avoids this problem.
MozReview-Commit-ID: 6XjGCknWNi9
--HG--
extra : transplant_source : k%10N%7B%E8%A4%9B%C9%9A%23Q%D1%99%D2%A3%C0.%2B%7F%A5
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
(r=ckerschb,r=mayhemer,r=jld,r=smaug,r=dkeeler,r=jmaher,p=ally)
The WebRTC implementation inherits cipher suite preferences from PSM and then
enables a few mandatory ones and disables a number of undesirable ones. If PSM
makes a change to a cipher suite preference that isn't in WebRTC's whitelist or
blacklist, compatibility issues can arise. See bug 1288246 for an example.
--HG--
rename : security/manager/ssl/tests/unit/test_fallback_cipher.js => security/manager/ssl/tests/unit/test_weak_crypto.js
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
Bug 1084025 added this telemetry to measure the impact of bumping the fallback limit.
But we already bumped the fallback limit to TLS 1.2 long before. We will not need this kind of telemetry until we bump the fallback limit to TLS 1.3 that will not happen in the near future. So let's just remove wasting resource for now.
MozReview-Commit-ID: 22o8FirlYql
--HG--
extra : rebase_source : c04b6a7aa7bf8970b22c24dcb1d8f0184330cb43
Wes Kocher
Cykesiopka
Robert Strong
Sebastian Hengst
Dragana Damjanovic
Nicholas Nethercote
Igor
J.C. Jones
David Cook
David Keeler
Tom Schuster
Thomas Wisniewski
Makoto Kato
Iris Hsiao
Kate McKinley
Carsten "Tomcat" Book
Franziskus Kiefer
Tom Tromey
Chris Peterson
Thomas Zimmermann
Masatoshi Kimura