3c15130709da26a6d2f25a483aa45e14bf1e4feb Improve CC_FOR_BUILD detection (Tim Ruffing)
47802a476246b67360bc24df78fe5fad6b93c296 Restructure and tidy configure.ac (Tim Ruffing)
252c19dfc654dbb10a35579fa36edb3466904758 Ask brew for valgrind include path (Tim Ruffing)
Pull request description:
See individual commit messages. These are improvements in preparation of the switch to Cirrus CI. (Maybe I'll just open a PR on top of this one.)
The first commit made the difference between successful build https://cirrus-ci.com/task/6740575057608704 and unsuccessful build https://cirrus-ci.com/task/4909571074424832.
I've tested the second commit without cross-compilation and with cross-compilation for android (https://github.com/bitcoin-core/secp256k1/issues/621#issuecomment-495703399)
When working on the autoconf stuff, I noticed two things that I just want to write down here:
- At some point we should update [build-aux/m4/ax_prog_cc_for_build.m4](https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html). This is outdated, and [there have been a lot of fixes](https://github.com/autoconf-archive/autoconf-archive/pull/207) But the latest version is [broken](https://lists.gnu.org/archive/html/autoconf-archive-maintainers/2020-06/msg00002.html), so now is probably not the time.
- The latest autoconf 2.70 deprecates `AC_PROG_CC_C89`. It's not needed anymore because `AC_PROG_CC` cares about testing for version support. This makes autoconf 2.70 output a warning that we should probably just ignore. We don't want to force users onto 2.70...
ACKs for top commit:
sipa:
utACK 3c15130709da26a6d2f25a483aa45e14bf1e4feb
jonasnick:
utACK 3c15130 makes sense (with my very basic understanding of autoconf)
Tree-SHA512: 595b9de316374c2213f1340cddaa22eb3190b01fa99aa6ae26e77804df41e7ecf96a09e03c28e8f8b9fd04e211e4ee2f78f1e5a7995143c84f99d2e16d4f0260
33cb3c2b1fc3f3fe46c6d0eab118248ea86c1f06 Add secret key extraction from keypair to constant time tests (Elichai Turkel)
36d9dc1e8e6e3b15d805f04c973a8784a78880f6 Add seckey extraction from keypair to the extrakeys tests (Elichai Turkel)
fc96aa73f5c7f62452847a31821890ff1f72a5a4 Add a function to extract the secretkey from a keypair (Elichai Turkel)
Pull request description:
With schnorrsig if you need to tweak the secret key (for BIP32) you must use the keypair API to get compatible secret/public keys which you do by calling `secp256k1_keypair_xonly_tweak_add()`, but after that there's no currently a way to extract the secret key back for storage.
so I added a `secp256k1_keypair_seckey` function to extract the key
ACKs for top commit:
jonasnick:
ACK 33cb3c2b1fc3f3fe46c6d0eab118248ea86c1f06
real-or-random:
ACK 33cb3c2b1fc3f3fe46c6d0eab118248ea86c1f06 code inspection, tests pass
Tree-SHA512: 11212db38c8b87a87e2dc35c4d6993716867b45215b94b20522b1b3164ca63d4c6bf5192a6bff0e9267b333779cc8164844c56669a94e9be72df9ef025ffcfd4
This commits simply uses CC as CC_FOR_BUILD and the same for
corresponding flags if we're not cross-compiling. This has a number of
benefits in this common case:
- It avoids strange cases where very old compilers are used (#768).
- Flags are consistently set for CC and CC_FOR_BUILD.
- ./configure is faster.
- You get compiler x consistently if you set CC=x; we got this wrong
in CI in the past.
./configure warns if a _FOR_BUILD variable is set but ignored because
we're not cross-compiling.
The change exposed that //-style comments are used in gen_context.c,
which is also fixed by this commit.
This commit also reorganizes code in configure.ac to have a cleaner
separation of sections.
1f4dd0383807bfb7fef884601357b4c629dfb566 Typedef (u)int128_t only when they're not provided by the compiler (Tim Ruffing)
e89278f211a526062745c391d48a7baf782b4b2b Don't use reserved identifiers memczero and benchmark_verify_t (Tim Ruffing)
Pull request description:
As identified in #829 and #833. Fixes#829.
Since we touch this anyway, this commit additionally makes the
identifiers in the benchmark files a little bit more consistent.
This is necessary before we can merge #833. I preferred a separate PR because it makes it easier to see the results of Travis in #833.
ACKs for top commit:
sipa:
utACK 1f4dd0383807bfb7fef884601357b4c629dfb566
jonasnick:
ACK 1f4dd0383807bfb7fef884601357b4c629dfb566
Tree-SHA512: c0ec92798f3c94f3ef6ac69b3f0f39a39257a32be9d9a068832cece1ebe64c89848b70e44652fc397004b8b240883ac4bc0c8f95abbe4ba4b028de120e6734bf
29a299e373d5f0e326be74c514c7c70ddf50cce1 Run the undefined behaviour sanitizer on Travis (Fabien)
7506e064d791e529d2e57bb52c156deb33b897ef Prevent arithmetic on NULL pointer if the scratch space is too small (Fabien)
Pull request description:
ACKs for top commit:
sipa:
ACK 29a299e373d5f0e326be74c514c7c70ddf50cce1. Reviewed the code changes and verified that building with these sanitizer flags catches the existing error, as well as a signed integer overflow if introduced.
real-or-random:
ACK 29a299e373d5f0e326be74c514c7c70ddf50cce1 code inspection
jonasnick:
utACK 29a299e373d5f0e326be74c514c7c70ddf50cce1
Tree-SHA512: 4d788f12f3d7b48018e884910adb9b530a05d88f504de83dadeab8a22d75da83c05a1518f7317de5f536c4dd243ea7b347b1eaddb2ca1d804c663e41b85db69d
If the user passes invalid flags to _context_create, and the default
illegal callback does not abort the program (which is possible), then we
work with the result of malloc(0), which may be undefined behavior. This
violates the promise that a library function won't crash after the
illegal callback has been called.
This commit fixes this issue by returning NULL early in _context_create
in that case.
If the scratch space is too small when calling
`secp256k1_ecmult_strauss_batch()`, the `state.pre_a` allocation will
fail and the pointer will be `NULL`. This causes `state.pre_a_lam` to be
computed from the `NULL` pointer.
It is also possible that the first allocation to fail is for `state.ps`,
which will cause the failure to occur when in
`secp256k1_ecmult_strauss_wnaf()`.
The issue has been detected by UBSAN using Clang 10:
```
CC=clang \
CFLAGS="-fsanitize=undefined -fno-omit-frame-pointer" \
LDFLAGS="-fsanitize=undefined -fno-omit-frame-pointer" \
../configure
UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1 make check
```
As identified in #829 and #833. Fixes#829.
Since we touch this anyway, this commit additionally makes the
identifiers in the benchmark files a little bit more consistent.
The VERIFY macro turns on various paranoid consistency checks, but
the complete functionality should still be tested without it.
This also adds a couple of static test points for extremely small
split inputs/outputs. The existing bounds vectors already check
extremely large outputs.
This allows us to shift by 256+128 = 384 bits, which is a multiple of the limb size of
the scalar representation. This also happens to be the most precision possible for g2
that still fits into a 256-bit value.
a45c1fa63cb3020225d72049ef9c1cf300014795 Rename testrand functions to have test in name (Pieter Wuille)
Pull request description:
Suggested here: https://github.com/bitcoin-core/secp256k1/pull/808#discussion_r488871913
ACKs for top commit:
real-or-random:
ACK a45c1fa63cb3020225d72049ef9c1cf300014795 diff looks good
elichai:
utACK a45c1fa63cb3020225d72049ef9c1cf300014795
Tree-SHA512: a15c29b88877e0f1a099acab90cbfa1e70420527e07348a69c8a5b539319a3131b771b86852e772a669a1eb3475d508d0f7e10f37eec363dc6640d4eaf967536
c0041b5cfca5efb160aa9a5616350069c89a8c29 Add static assertion that uint32_t is unsigned int or wider (Tim Ruffing)
Pull request description:
Solves one item in #792 .
ACKs for top commit:
sipa:
utACK c0041b5cfca5efb160aa9a5616350069c89a8c29
elichai:
ACK c0041b5cfca5efb160aa9a5616350069c89a8c29
Tree-SHA512: 9f700e89be39e15983260da94642593d16b9c437171e10377837ac73731ca7ba5dd7e328b3d93d0a24d143fb9e73abd11c578f6b58e2f94c82b783e977173b0c
8b7dcdd955a4f57174f478e36bdae5b84784fb9c Add exhaustive test for extrakeys and schnorrsig (Pieter Wuille)
08d7d89299a6492bf9388b4662b709d268c8ea29 Make pubkey parsing test whether points are in the correct subgroup (Pieter Wuille)
87af00b511f2938b6b4799f94d446a005730515e Abstract out challenge computation in schnorrsig (Pieter Wuille)
63e1b2aa7d396209aa5e26aa540d9593ede312a6 Disable output buffering in tests_exhaustive.c (Pieter Wuille)
39f67dd072fc44c7c0d27b95610ba8912de56db5 Support splitting exhaustive tests across cores (Pieter Wuille)
e99b26fcd54cb4096515ba80cf0f79d147b2683c Give exhaustive_tests count and seed cmdline inputs (Pieter Wuille)
49e6630bca5f6628bd1fd92d70d465273d4d873f refactor: move RNG seeding to testrand (Pieter Wuille)
b110c106fa9704e30f6b0c2ffa6a2697031e89a8 Change exhaustive test groups so they have a point with X=1 (Pieter Wuille)
cec7b18a34e68adb04f31a71a2eb4c5fc97674ce Select exhaustive lambda in function of order (Pieter Wuille)
78f6cdfaae9866694dcb0eee966332688753a8c3 Make the curve B constant a secp256k1_fe (Pieter Wuille)
d7f39ae4b67ea1ac6f085e6262a5f53afc0c5a25 Delete gej_is_valid_var: unused outside tests (Pieter Wuille)
8bcd78cd791fd9209d72d6bce455c8d3cf2c0249 Make secp256k1_scalar_b32 detect overflow in scalar_low (Pieter Wuille)
c498366e5b2d9c60e2e677949cf7373dbe877515 Move exhaustive tests for recovery to module (Pieter Wuille)
be317915436909573733afe3972a9abdee9357f7 Make group order purely compile-time in exhaustive tests (Pieter Wuille)
Pull request description:
A few miscellaneous improvements:
* Just use EXHAUSTIVE_TEST_ORDER as order everywhere, rather than a variable
* Move exhaustive tests for recovery module to the recovery module directory
* Make `secp256k1_scalar_set_b32` detect overflow correctly for scalar_low (a comment in the recovery exhaustive test indicated why this was the case, but this looks incorrect).
* Change the small test groups so that they include a point with X coordinate 1.
* Initialize the RNG seed, allowing configurating from the cmdline, and report it.
* Permit changing the number of iterations (re-randomizing for each).
* Support splitting the work across cores from the cmdline.
And a big one:
* Add exhaustive tests for schnorrsig module (and limited ones for extrakeys).
ACKs for top commit:
real-or-random:
ACK 8b7dcdd955a4f57174f478e36bdae5b84784fb9c
jonasnick:
ACK 8b7dcdd955a4f57174f478e36bdae5b84784fb9c
Tree-SHA512: 18d7f362402085238faaced164c0ca34079717a477001fc0b13448b3529ea2ad705793a13b7a36f34bf12e9231fee11070f88cc51bfc2a83ca82aa13f7aaae71
This enables testing overflow is correctly encoded in the recid, and
likely triggers more edge cases.
Also introduce a Sage script to generate the parameters.