The LLVM apt repository uses legacy SHA1 signatures which are now
rejected by the stricter Sequoia PGP policy.
This change extends the 'sha1.second_preimage_resistance' cutoff date to
9999-01-01 in the default Sequoia config. This effectively whitelists
the legacy signature algorithm, preventing "OpenPGP signature
verification failed" errors during `apt-get update`.
See https://github.com/llvm/llvm-project/issues/153385.
2cb2e312e9 extrakeys: Migrate to bitcoin-core/secp256k1#1518 secp256k1_ec_pubkey_sort (DarkWindman)
7d2591ce12 Add secp256k1_pubkey_sort (Jonas Nick)
Pull request description:
Merge bitcoin-core/secp256k1#1518: Add secp256k1_pubkey_sort
This PR can be recreated with `./contrib/sync-upstream.sh -b master range bb528cf`.
Tip: Use `git show --remerge-diff` to show the changes manually added to the merge commit.
ACKs for top commit:
real-or-random:
ACK 2cb2e312e9
Tree-SHA512: dbdb6c5df2195d2ece9574367e0f684a651ea199806a80232c85b0ffd0ba6b930b108bd97385d9fab656754a85fa6de223a93b945046b043aab20ad7bb3d1bff
96a415b1c0 scalar: Port bitcoin-core/secp256k1#1393 to zkp-specific code (mllwchrry)
Pull request description:
Add the `SECP256K1_SCALAR_VERIFY` macro to the zkp-specific `secp256k1_scalar_set_u64` function.
This was missed when upstream PRs bitcoin-core/secp256k1#1373 and bitcoin-core/secp256k1#1393 were merged.
ACKs for top commit:
real-or-random:
ACK 96a415b1c0
Tree-SHA512: 4c3c6209e4c27bec7afc07398c9fc50aef7d44850fbbf5969ff4b57991279960c9645c8daeee5d78bee54dac7fe85bc3d9a01ba4b9deb761d574ae6221ef41c1
4c341f89ab Add changelog entry for SDMC (Pieter Wuille)
a043940253 Permit COMB_BITS < 256 for exhaustive tests (Pieter Wuille)
39b2f2a321 Add test case for ecmult_gen recoded = {-1,0,1} (Pieter Wuille)
644e86de9a Reintroduce projective blinding (Pieter Wuille)
07810d9abb Reduce side channels from single-bit reads (Peter Dettman)
a0d32b597d Optimization: use Nx32 representation for recoded bits (Peter Dettman)
e03dcc44b5 Make secp256k1_scalar_get_bits support 32-bit reads (Pieter Wuille)
5005abee60 Rename scalar_get_bits -> scalar_get_bits_limb32; return uint32_t (Pieter Wuille)
6247f485b6 Optimization: avoid unnecessary doublings in precomputation (Peter Dettman)
15d0cca2a6 Optimization: first table lookup needs no point addition (Pieter Wuille)
7a33db35cd Optimization: move (2^COMB_BITS-1)/2 term into ctx->scalar_offset (Pieter Wuille)
ed2a056f3d Provide 3 configurations accessible through ./configure (Pieter Wuille)
5f7be9f6a5 Always generate tables for current (blocks,teeth) config (Pieter Wuille)
fde1dfcd8d Signed-digit multi-comb ecmult_gen algorithm (Peter Dettman)
486518b350 Make exhaustive tests's scalar_inverse(&x,&x) work (Pieter Wuille)
ab45c3e089 Initial gej blinding -> final ge blinding (Pieter Wuille)
aa00a6b892 Introduce CEIL_DIV macro and use it (Tim Ruffing)
Pull request description:
[bitcoin-core/secp256k1#1058]: Signed-digit multi-comb ecmult_gen algorithm
This PR can be recreated with `./contrib/sync-upstream.sh -b master range da51507`.
Tip: Use `git show --remerge-diff` to show the changes manually added to the merge commit.
ACKs for top commit:
mllwchrry:
ACK 9a57e3c
real-or-random:
ACK 9a57e3c650
Tree-SHA512: 6de5961697ed1f23ce60a6437b622cdf1289273cf9e22f7abfeced08c1f279e30b1a807148f3405c723ad5d3c712eecf0499f994dfce8a1c687b4521b0ef60dd
db8750de46 sync-upstream: improve help text (Jonas Nick)
Pull request description:
ACKs for top commit:
real-or-random:
utACK db8750de46
Tree-SHA512: 06f28c5ebd74437c3c2ef5ae460bec66ff9f15c4bae3b76c74b1323e2ef24d8ec456b72d58df9d68a3d41fcd44d6dfbefe8115900ccb10b8f028a7b0952b6df1
Switch msg initialization from a string literal to a brace-enclosed
array to avoid -Wunterminated-string-initialization. Upstream removed
the trailing '!' from the message; this change retains it.
The previous code is correct and harmless to initialize an array with a
non-terminated character sequence using a string literal.
However, it requires exactly specifying the array size, which can be
cumbersome.
Also, GCC-15 may issue the -Wunterminated-string-initialization warning.
[1]
Fix both issues by using array initialization. This refactoring commit
does not change behavior.
[1] Example warning:
src/modules/schnorrsig/main_impl.h:48:46: error: initializer-string for array of 'unsigned char' is too long [-Werror=unterminated-string-initialization]
48 | static const unsigned char bip340_algo[13] = "BIP0340/nonce";
| ^~~~~~~~~~~~~~~
(cherry picked from commit fa67b6752d)
Conflicts:
src/testrand_impl.h (kept local name `secp256k1_testrand_seed`)
3a1c39625e rangeproof: add unit test for malleating single-value proofs (Andrew Poelstra)
Pull request description:
I was a bit confused reading `secp256k1_rangeproof_getheader_impl` because in the case of single-value proofs (`has_nz_range == 0`) some bits of the header are unconstrained. At first I thought this was a malleability vector. And I think I've had this same confusion in the past.
But in fact it is not a malleability vector because the whole header gets hashed into the proof.
Add a unit test to confirm this to reduce future confusion.
ACKs for top commit:
real-or-random:
utACK 3a1c39625e
Tree-SHA512: 9670cd04fcc0bb322d89c2c86ef863e13c29e4477dc6fecdda16b9a745e42a84f237a7ec387b3291f334e2a5c5806a8cc7cc00e40246ad5b36366be841195b4b
I was a bit confused reading `secp256k1_rangeproof_getheader_impl`
because in the case of single-value proofs (`has_nz_range == 0`) some
bits of the header are unconstrained. At first I thought this was a
malleability vector. And I think I've had this same confusion in the
past.
But in fact it is not a malleability vector because the whole header
gets hashed into the proof.
Add a unit test to confirm this to reduce future confusion.
f55703ba49 autotools: Delete unneeded compiler test (Hennadii Stepanov)
396e885886 autotools: Align MSan checking code with CMake's implementation (Hennadii Stepanov)
abde59f52d cmake: Report more compiler details in summary (Hennadii Stepanov)
7abf979a43 cmake: Disable `ctime_tests` if build with `-fsanitize=memory` (Hennadii Stepanov)
Pull request description:
Same as https://github.com/bitcoin-core/secp256k1/pull/1517, but for the CMakle build system.
The second commit improves the configure summary (similar to https://github.com/hebasto/bitcoin/pull/189.
ACKs for top commit:
real-or-random:
ACK f55703ba49
Tree-SHA512: 18190c062ae6e27d0ecbe7460cc22c960b25c0d35aa4b94f151d4b1c48f16e99fd5ecdfcb359784f95995292633d30d3d23b75a12be3aca5afffcc1e7e7daf31
ebfb82ee2f ci: Add job with -fsanitize-memory-param-retval (Tim Ruffing)
e1bef0961c configure: Move "experimental" warning to bottom (Tim Ruffing)
55e5d975db autotools: Disable eager MSan in ctime_tests (Tim Ruffing)
Pull request description:
This is the autotools solution for #1516.
Alternatively, we could have a full-blown `--enable-msan` option, but it's more work, and I'm not convinced that it's necessary or at least much better.
hebasto If you're Concept ACK, are you willing to work on an equivalent PR for CMake?
ACKs for top commit:
hebasto:
ACK ebfb82ee2f, tested on Ubuntu 24.04 with different clang versions (from 15 to 18) and different build configurations. CI changes look OK as well.
Tree-SHA512: c083d778fd50bd35c2e29b7fe0d92b98d912ee5ac7809ae73067d050a0d3c42b3483260f1286d0023cdb802a3c3006bf932ecf60ce81b942de1c9824374c0132
Similar to speeding up serialization; in our parsing logic we did a
bunch of expensive stuff then expensively inverted it. Drop everything
except the essential checks and then memcpy.
`secp256k1_pedersen_commit_serialize` would call `_load` (which does a
sqrt to fully decompress the key, then a conditional negation based on
the flag), then check the Jacobian symbol of the resulting y-coordinate,
then re-serialize based on this.
Instead, don't do any of this stuff. Copy the flag directly out of the
internal representation and copy the x-coordinate directly out of the
internal representation.
Checked that none of the other _serialize methods in the modules do
this.
Fixes#293
9554362b15 tests: call secp256k1_ecmult_multi_var with a non-NULL error callback (Nicolas Iooss)
Pull request description:
Hello,
This Pull Request fixes the issue reported in https://github.com/bitcoin-core/secp256k1/issues/1527. Function `secp256k1_ecmult_multi_var` expects to be called with a non-`NULL` `error_callback` parameter. Fix the invocation in `test_ecmult_accumulate` to do this. While at it, wrap the call in a `CHECK` macro to ensure it succeeds.
ACKs for top commit:
real-or-random:
utACK 9554362b15
siv2r:
ACK 9554362, I have also verified that other invocations of `ecmult_multi_var` (in tests) don’t use `NULL` for the error callback function argument.
Tree-SHA512: 6a9f6c10c575794da75f2254d6fbbc195de889c81a371ce35ab38e2e5483aa1e25ec0bcd5aa8d6a32a1493586f73430208a4bd0613e373571d2f04d63dbc4a1c
9f4c8cd730 cmake: Fix `check_arm32_assembly` when using as subproject (Hennadii Stepanov)
Pull request description:
When integrating libsecpk1 in a downstream project like this:
```cmake
set(SECP256K1_ASM arm32 CACHE STRING "" FORCE)
add_subdirectory(src/secp256k1)
```
it fails to configure:
```
CMake Error at /home/hebasto/git/bitcoin/build/check_arm32_assembly/CMakeFiles/CMakeTmp/CMakeLists.txt:21 (target_sources):
Cannot find source file:
/home/hebasto/git/bitcoin/cmake/source_arm32.s
CMake Error at /home/hebasto/git/bitcoin/build/check_arm32_assembly/CMakeFiles/CMakeTmp/CMakeLists.txt:20 (add_executable):
No SOURCES given to target: cmTC_d0f0b
CMake Error at src/secp256k1/cmake/CheckArm32Assembly.cmake:2 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
src/secp256k1/CMakeLists.txt:127 (check_arm32_assembly)
```
This PR fixes this issue, which was overlooked in https://github.com/bitcoin-core/secp256k1/pull/1304.
ACKs for top commit:
real-or-random:
utACK 9f4c8cd730
theuni:
utACK 9f4c8cd730
Tree-SHA512: 47d97ad0fb2e3779523c2111ea75906671a0fb3f50646e29dee195f53106ace69af5e4abc92c765f0eee6973528ce9195b94377d0157209230c958894d4049fb
Function secp256k1_ecmult_multi_var expects to be called with a non-NULL
error_callback parameter. Fix the invocation in test_ecmult_accumulate
to do this.
While at it, wrap the call in a CHECK macro to ensure it succeeds.
Fixes: https://github.com/bitcoin-core/secp256k1/issues/1527
