GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
nsNSSCertList/nsIX509CertList are redundant, and also contructing
them are expensive. so it is replaced by Array<nsIX509Cert>
Differential Revision: https://phabricator.services.mozilla.com/D44245
--HG--
extra : moz-landing-system : lando
Bug 1593141 adds a parameter to mozilla::pkix::TrustDomain::CheckRevocation.
This patch updates all TrustDomain implementations in mozilla-central to
reflect this.
Differential Revision: https://phabricator.services.mozilla.com/D52066
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
nsIX509CertDB::PrivilegedPackageRoot was added in bug 1178518 to support privileged packaged apps for Firefox OS. However, we no longer need to support this use-case.
Differential Revision: https://phabricator.services.mozilla.com/D38655
--HG--
extra : moz-landing-system : lando
CryptoTask is a helper class that makes it easier to implement code that runs on
a background thread and then notifies completion on the main thread (this is
useful for not blocking the main thread with long-running cryptography or I/O).
Before this patch, each CryptoTask would create a new thread each time it ran,
which was inefficient. This patch updates CryptoTask to use the stream transport
service (which is essentially a pool of threads for doing exactly these kinds of
things and notably is not to be confused with the socket transport service) to
run each task. Additionally, there were a few places in PSM where we
unnecessarily created new threads to perform similar tasks. These now use the
stream transport service as well.
Differential Revision: https://phabricator.services.mozilla.com/D33534
--HG--
extra : moz-landing-system : lando
SECItem uses an unsigned int to indicate its length. We need to cast a size_t
down to the appropriate size. This is safe because what we're casting will
always fit in an unsigned int on the platforms we're using (it's just the size
of the intermediate certificate we added).
Differential Revision: https://phabricator.services.mozilla.com/D30144
--HG--
extra : source : 24bb6566385fc566f1a6b98ea24cad7d0af7e3a3
Summary:
Our previous approach to making this intermediate available relied on being able
to add it to the user's NSS cert DB. This does work in the majority of cases,
but there are some situations where it doesn't work (e.g. if the user's DB is
set to read only, if they've configured Firefox to run in "nocertdb" mode, if
they have a master password but forgot it, and so on). This patch compiles the
intermediate in to Firefox in the same way we incorporate the root, so it should
always be available.
At the same time, this patch reverts the changes from
023dd959512e2cfa685187616560f91efa91183c and
1d35f8d88bdd007e01d42c4ff76c6d10d7c01a98 (the patches that implemented the
original approach) because they should no longer be necessary.
Reviewers: jcj!, kmag!
Tags: #secure-revision
Bug #: 1549249
Differential Revision: https://phabricator.services.mozilla.com/D30090
--HG--
extra : amend_source : dd475918be3f263a4a363c66a60edc708d3bdcca
extra : histedit_source : b6861a1d7c7ddbe07d5df73d76734d9a48ee3164%2C54cbc4b0446ff1ee3dc860bb2d3798ba8f662566
(Backed out changeset 6bbf8dc0b86e (which was a backout of changeset 0a5795108e0a))
MozReview-Commit-ID: EZFn7dLBcdh
--HG--
extra : rebase_source : 8fac1e33a7f108a248ecde35779b2c63ce7d9172
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
Unfortunately we have a number of add-on installation tests that rely on
unpacked addons verifying as signed. The test infrastructure achieves this by
monkey-patching nsIX509CertDB.verifySignedDirectoryAsync to always succeed.
These tests are, in general, not actually testing the successful verification of
signed unpacked add-ons but rather other aspects of add-on installation,
updating, etc.. Some of these tests are certainly no longer relevant now that
legacy add-ons aren't supported, but we don't have the time to go through all of
them at the moment (this blocks updating add-on signature verification to use
COSE signatures, which we need to ship in 59 or we're probably not shipping at
all).
MozReview-Commit-ID: 3TVPK703mUy
--HG--
extra : rebase_source : 5bf0b72a4d7c8ade702334345fdc3bf6a8761b15
As a result of this patch, the hash algorithm used in add-on signature
verification will come from the PKCS#7 signature. If SHA-256 is present, it will
be used. SHA-1 is used as a fallback. Otherwise, the signature is invalid.
This means that, for example, if the PKCS#7 signature only has SHA-1 but there
are SHA-256 hashes in the signature file and/or manifest file, only the SHA-1
hashes in the signature file and manifest file will be used, if they are present
(and verification will fail if they are not present). Similarly, if the PKCS#7
signature has SHA-256, there must be SHA-256 hashes in the signature file and
manifest file (even if SHA-1 is also present in the PKCS#7 signature).
MozReview-Commit-ID: K3OQEpIrnUW
--HG--
extra : rebase_source : 704a2a18e166bfaf3e3d944d13918054bd012000
The NS_LITERAL_STRING macro creates a temporary nsLiteralString to encapsulate the char16_t string literal and its length, but AssignLiteral() can determine the char16_t string literal's length at compile-time without nsLiteralString.
MozReview-Commit-ID: H9I6vNDMdIr
--HG--
extra : rebase_source : cf537a1f65af003c6c4f8919b925b0f305c1dd4d
extra : source : 13b89ce4e6a66c840f82a335c71f5a12938aba22
(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
-Wextra implies -Wmissing-field-initializers, but since the latter warning seems
to warn about mostly uninteresting instances (XPCOM module definitions etc), we
disable it for now.
(Note that -Wall is already enabled by default for all directories for gcc and
clang.)
MozReview-Commit-ID: 8RdF51sLPC8
--HG--
extra : rebase_source : 003c1c04e090ec215d058f5adf4c9e72558bbae3
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
verifySignedManifestAsync() was added in Bug 1059216 to support Trusted Hosted
Apps.
However, Bug 1196988 removed THA and no add-ons use this method, so there's no
point in keeping it around.
MozReview-Commit-ID: 6xBRxvRZfjh
--HG--
extra : rebase_source : 5b8cf9c5863187b55325a8f9929bbe52c6478ec5
Mike Shal
Cosmin Sabou
Brindusan Cristian
Gabriele Svelto
Sean Feng
Dana Keeler
Ricky Stewart
Daniel Varga
Barret Rennie
Dorel Luca
Oana Pop Rus
Moritz Birghan
Sylvestre Ledru
Franziskus Kiefer
Kris Maglione
Chris Peterson
Nicholas Nethercote
Bevis Tseng
Cykesiopka
Joel Maher