Only sanitizer builds require a native llvm-symbolizer executable.
Ideally, we'd build llvm-symbolizer from scratch, which would be faster,
but for now, let's go the easy route and just extract it from the
corresponding native clang builds.
We don't actually do anything with the llvm-symbolizer executable on
android builds, so we don't install it in $FINAL_TARGET, avoilding
the dependency on android builds (plus, we actually don't have an
android-native llvm-symbolizer, so even if it were already shipped, it
would be the wrong file).
Differential Revision: https://phabricator.services.mozilla.com/D101076
Passing `-flto=thin` worked previously but the value passed was just ignored
and full lto was performed. On newer versions of gcc passing an unknown value
causes failure. So this commit checks if `-flto=thin` is passed and fails with
an error message if so, else full lto is enabled if any other value is passed.
Differential Revision: https://phabricator.services.mozilla.com/D100953
Only sanitizer builds require a native llvm-symbolizer executable.
Ideally, we'd build llvm-symbolizer from scratch, which would be faster,
but for now, let's go the easy route and just extract it from the
corresponding native clang builds.
We don't actually do anything with the llvm-symbolizer executable on
android builds, so we don't install it in $FINAL_TARGET, avoilding
the dependency on android builds (plus, we actually don't have an
android-native llvm-symbolizer, so even if it were already shipped, it
would be the wrong file).
Differential Revision: https://phabricator.services.mozilla.com/D101076
In addition to the usual dot-release type of fixes, this also lets us drop a good amount of code that we had patched into our clang 11.
Differential Revision: https://phabricator.services.mozilla.com/D100959
Some distros include flags when they specify the location of a binary,
such as: `XARGS=xargs -r`.
This was confusing in `configure`, since:
* We require that environment variables contain only path
overrides (without flags).
* The error message thrown when configure chokes was unclear: "why
would `$ xargs -r` fail?"
This patch should make our "path-only" requirement more clear.
Differential Revision: https://phabricator.services.mozilla.com/D100044
Old clang shakes its fist when `auto&& item : range` is used with a
range
that returns values instead of references.
Modern `clang` doesn't warn for this scenario, so we disable the
warning.
Also removes pragmas that manually disable this warning.
Differential Revision: https://phabricator.services.mozilla.com/D100155
I was waiting for a better reason to do this, because the cbindgen
changes from 0.15.0 to 0.16.0 don't break trunk builds. But since
downstream has updated (see bug 1684180) and there's no reason not to,
let's do this to avoid future churn.
Differential Revision: https://phabricator.services.mozilla.com/D100499
2020-12-11 Kevin Jacobs <kjacobs@mozilla.com>
* automation/abi-check/expected-report-libssl3.so.txt, automation/abi-
check/previous-nss-release, lib/nss/nss.h, lib/softoken/softkver.h,
lib/util/nssutil.h:
Set version numbers to 3.61 Beta
[f277d2674c80]
* gtests/<...>
Bug 1677207 - Update Google Test to release-1.10.0 r=bbeurdouche
./gtests/google_test/update.sh release-1.10.0 && hg remove -A && hg
add gtests/google_test/*
[89141382df45]
* gtests/<...>
Bug 1677207 - Replace references to TestCase, which is deprecated,
with TestSuite r=bbeurdouche
grep -rl --exclude-dir=google_test INSTANTIATE_TEST_CASE_P gtests |
xargs sed -i '' s/INSTANTIATE_TEST_CASE_P/INSTANTIATE_TEST_SUITE_P/g
grep -rl --exclude-dir=google_test SetUpTestCase gtests | xargs sed
-i '' s/SetUpTestCase/SetUpTestSuite/g
[e15b78be87fa]
* gtests/ssl_gtest/ssl_ciphersuite_unittest.cc,
gtests/ssl_gtest/ssl_debug_env_unittest.cc,
gtests/ssl_gtest/ssl_extension_unittest.cc,
gtests/ssl_gtest/ssl_loopback_unittest.cc,
gtests/ssl_gtest/ssl_renegotiation_unittest.cc,
gtests/ssl_gtest/ssl_resumption_unittest.cc,
gtests/ssl_gtest/ssl_version_unittest.cc,
gtests/ssl_gtest/tls_ech_unittest.cc:
Bug 1677207 - Use GTEST_SKIP in ssl_gtests. r=bbeurdouche
[0772f1bf5fd6]
2020-12-17 Robert Relyea <rrelyea@redhat.com>
* gtests/common/testvectors/ike-aesxcbc-vectors.h,
gtests/common/testvectors/ike-sha1-vectors.h,
gtests/common/testvectors/ike-sha256-vectors.h,
gtests/common/testvectors/ike-sha384-vectors.h,
gtests/common/testvectors/ike-sha512-vectors.h,
gtests/common/testvectors_base/test-structs.h,
gtests/pk11_gtest/manifest.mn, gtests/pk11_gtest/pk11_gtest.gyp,
gtests/pk11_gtest/pk11_ike_unittest.cc, lib/softoken/sftkike.c:
Bug 1682071 IKE Quick mode IPSEC give you incorrect keys if you are
asking for keys smaller than the hash size.
IKE Appendix B fixes.
This patch fixes 2 problems.
If you run either ike v1 App B or quick mode asking for a key with
length
mod macsize = 0, you will generate an extra block that's not used
and overwrites the end of the buffer.
If you use quick mode, the function incorrectly subsets the
existing key
rather than generating a new key. This is correct behavior for
Appendix B, where appendix B is trying to take a generated key and
create a new longer key (with no diversification, just transform the
key into something that's longer), so if you ask for a key less than
or equal to, then you want to just subset the original key. In quick
mode you are taking a base key and creating a set of new keys based
on additional data, so you want to subset the generated data. This
patch only subsets the original key if you aren't doing quickmode.
Full test vectors have now been added for all ike modes in this
patch as well (previously we depended on the FIPS CAVS tests to test
ike, which covers basic IKEv1, IKEv1_psk, and IKEv2 but not IKEv1
App B and IKE v1 Quick mode).
[f4995c9fa185]
2020-12-18 Robert Relyea <rrelyea@redhat.com>
* gtests/common/testvectors/rsa_pkcs1_2048_test-vectors.h,
gtests/common/testvectors/rsa_pkcs1_3072_test-vectors.h,
gtests/common/testvectors/rsa_pkcs1_4096_test-vectors.h,
gtests/freebl_gtest/Makefile, gtests/freebl_gtest/manifest.mn,
gtests/freebl_gtest/rsa_unittest.cc, gtests/manifest.mn,
gtests/pk11_gtest/pk11_rsaencrypt_unittest.cc,
gtests/pk11_gtest/pk11_rsaoaep_unittest.cc, lib/freebl/alghmac.c,
lib/freebl/alghmac.h, lib/freebl/rsapkcs.c:
Bug 1651411 New tlsfuzzer code can still detect timing issues in RSA
operations.
This patch defeats Bleichenbacher by not trying to hide the size of
the decrypted text, but to hide if the text succeeded for failed.
This is done by generating a fake returned text that's based on the
key and the cipher text, so the fake data is always the same for the
same key and cipher text. Both the length and the plain text are
generated with a prf.
Here's the proposed spec the patch codes to:
1. Use SHA-256 to hash the private exponent encoded as a big-
endian integer to a string the same length as the public modulus.
Keep this value secret. (this is just an optimisation so that the
implementation doesn't have to serialise the key over and over
again) 2. Check the length of input according to step one of
https://tools.ietf.org/html/rfc8017#section-7.2.2 3. When provided
with a ciphertext, use SHA-256 HMAC(key=hash_from_step1,
text=ciphertext) to generate the key derivation key 4. Use SHA-256
HMAC with key derivation key as the key and a two-byte big- endian
iterator concatenated with byte string "length" with the big- endian
representation of 2048 (0x0800) as the bit length of the generated
string.
- Iterate this PRF 8 times to generate a 256 byte string 5. initialise
the length of synthetic message to 0 6. split the PRF output into 2
byte strings, convert into big-endian integers, zero- out high-order
bits so that they have the same bit length as the octet length of
the maximum acceptable message size (k-11), select the last integer
that is no larger than (k-11) or remain at 0 if no integer is
smaller than (k-11); this selection needs to be performed using a
side-channel free operators 7. Use SHA-256 HMAC with key derivation
key as the key and a two-byte big-endian iterator concatenated with
byte string "message" with the big-endian representation of k*8
- use this PRF to generate k bytes of output (right-truncate last HMAC
call if the number of generated bytes is not a multiple of SHA-256
output size) 8. perform the RSA decryption as described in step 2 of
section 7.2.2 of rfc8017 9. Verify the EM message padding as
described in step 3 of section 7.2.2 of rfc8017, but instead of
outputting "decryption error", return the last l bytes of the
"message" PRF, when l is the selected synthetic message length using
the "length" PRF, make this decision and copy using side-channel
free operation
[fc05574c7399]
2020-12-22 Robert Relyea <rrelyea@redhat.com>
* gtests/freebl_gtest/rsa_unittest.cc,
gtests/pk11_gtest/pk11_rsaoaep_unittest.cc, lib/freebl/alghmac.c,
lib/freebl/rsapkcs.c:
Restore lost portion of the bleichenbacher timing batch that
addressed review comments. All the review comments pertained to
actual code comments, so this patch only affects the comments.
[fcebe146314e]
2020-12-22 Kevin Jacobs <kjacobs@mozilla.com>
* lib/dev/devslot.c:
Bug 1682863 - Revert nssSlot_IsTokenPresent to 3.58 after ongoing Fx
hangs with slow PKCS11 devices. r=bbeurdouche
This patch reverts the `nssSlot_IsTokenPresent` changes made in bug
1663661 and bug 1679290, restoring the version used in NSS 3.58 and
earlier. It's not an actual `hg backout` because the comment in
lib/dev/devt.h is worth keeping. While removing the nested locking
did resolve the hang for some (most?) third-party modules, problems
remain with some slower tokens after an even further relaxation of
the locking, which defeats the purpose of addressing the races in
the first place.
The crash addressed by these patches was caused by the Intermediate
Preloading Healer in Firefox, which has been disabled. We clearly
have insufficient test coverage for third-party modules, and now
that osclientcerts is enabled in Fx Nightly, any problems caused by
these and similar changes is unlikely to be reported until Fx Beta,
well after NSS RTM. I think the best option at this point is to
simply revert NSS.
[97ef009f7a78] [tip]
Differential Revision: https://phabricator.services.mozilla.com/D100401
Since bug 1632542 we have a new major clang version, several new versions worth of rustc, new pass manager during LTO, and of course eight months worth of code change. Time for a refresh. Same process as the earlier bug.
Differential Revision: https://phabricator.services.mozilla.com/D99243
At the moment installing Python packages with native code is done by calling
`pip install <package>` and does not enforce any SHA hash for installed
dependencies, nor does it enforce a specific version to be installed.
This commit adds `requirements.in` and `requirements.txt` files for native
packages and changes these packages to be installed by running `pip install`
and passing the requirements file for the package. This allows us to pin the
SHA of the various dependencies. The `.txt` files are generated using
`pip-compile`.
We also add the new requirements files to the sparse profile for `mach`.
Differential Revision: https://phabricator.services.mozilla.com/D99912
In clang 11, the contents of `ast_type_traits` were moved to the `clang` namespace, but forwarders were kept to give a grace period for downstreams.
In this week's clang 12, the forwarders have been removed, and our builds will break.
Thanks to upstream kindly allowed this transition period, we can simply do the rename now to prepare for clang 12, and existing clang 11 builds still work.
Differential Revision: https://phabricator.services.mozilla.com/D99817
At this point it's pretty clear that we won't be reverting to clang-9.
This doesn't remove everything with clang-9 in the name. I did a mark-and-sweep GC by hand so this only removes unused entries. Some are still active, e.g. linux64-clang-9 is used to build a number of misc helper tools.
Differential Revision: https://phabricator.services.mozilla.com/D99721
Covers adding the new JS global `GleanPings` for JS, the new structs for C++ at
mozilla::glean_pings, ping-id and string-table-index codegen, the usual
boilerplate for JS and C++ stuff, and tests.
Unresolved:
* What happens if we call this on a non-parent process?
(This isn't a supported mode of operation)
Differential Revision: https://phabricator.services.mozilla.com/D98671
