b9ebee1490 fix a couple things to make Elements 22's linter happy (Andrew Poelstra)
Pull request description:
In Elements 22 the linter looks for executable files that don't have a properly-formed shebang. For some reason it wants `/usr/bin/env bash` rather than `/bin/bash`, and also one of our source files was erroneously 755.
ACKs for top commit:
real-or-random:
ACK b9ebee1490
Tree-SHA512: 00da8fefd67c1882c6cec39dc81ce67ae3f52f902ddf72545e902b8f5bc7cd7c1249bf71027c530245c403a99c86ffbb61a89bc18c27c5ec975f6f653200766c
72713872a8 Add missing static to secp256k1_schnorrsig_sign_internal (Elichai Turkel)
adec5a1638 Add missing null check for ctx and input keys in the public API (Elichai Turkel)
f4edfc7581 Improve consistency for NULL arguments in the public interface (Elichai Turkel)
20abd52c2e Add tests for pre_g tables. (Russell O'Connor)
6815761cf5 Remove ecmult_context. (Russell O'Connor)
f20dcbbad1 Correct typo. (Russell O'Connor)
16a3cc07e8 Generate ecmult_static_pre_g.h (Russell O'Connor)
8de2d86a06 Bump memory limits in advance of making the ecmult context static. (Russell O'Connor)
5d5c74a057 tests: Rewrite code to circument potential bug in clang (Tim Ruffing)
3d2f492ceb ci: Install libasan6 (instead of 5) after Debian upgrade (Tim Ruffing)
Pull request description:
[bitcoin-core/secp256k1#969]: ci: Fixes after Debian release
[bitcoin-core/secp256k1#956]: Replace ecmult_context with a generated static array.
[bitcoin-core/secp256k1#783]: Make the public API docs more consistent and explicit
[bitcoin-core/secp256k1#976]: `secp256k1_schnorrsig_sign_internal` should be static
This PR can be recreated with `./sync-upstream.sh range 2a3a97c665475bc00d5d60f2f04830202983a631`.
ACKs for top commit:
real-or-random:
ACK 938725c1c9 inspected the diff between the pure output of running the sync script and this PR
Tree-SHA512: 6dd5964563497ced6afe533e4deaa82df76c071b5146a9eb7a5a998187210b5fbf19195d34320b7b2193f6b40d778cf258ad22033d7bc33479e0dc4791aceff9
189f6bcfef Fix unused parameter warnings when building without VERIFY (Jonas Nick)
Pull request description:
This commit makes `./configure --enable-coverage && make check` free of warnings.
ACKs for top commit:
practicalswift:
cr ACK 189f6bcfef
elichai:
utACK 189f6bcfef
siv2r:
Tested ACK 189f6bc
Tree-SHA512: 727fe0e40ff61f404780b32dfa4102a58bed9d922e61bd17ddaaf1243b0c06edd9697ff4763b5e92d033e7db3778193bee07d85cfa3b9c46d45e5fec3f568009
d43993724d tests: remove `secp256k1_fe_verify` from tests.c and modify `secp256k1_fe_from_storage` to call `secp256k1_fe_verify` (siv2r)
Pull request description:
ACKs for top commit:
roconnor-blockstream:
utACK d439937 diff looks correct, I also didn't run the tests locally.
real-or-random:
utACK d43993724d diff looks correct, I didn't run the tests locally
jonasnick:
ACK d43993724d ran tests with `--enable-coverage`
Tree-SHA512: c3c9ecf8e9b7dfdcd1144ddcf8bcc637996c699dbd0fc6223e6186d082908728468fa276b09c6f344e036ca05f54432dde6366a83eb39f915a334164faadd556
1. secp256k1_fe_verify is removed from tests since, it throws an error if VERIFY is not defined during compilation.
(Ex: ./configure --enable-coverage)
2. `secp256k1_fe_from_storage` calls `secp256k1_fe_verify` in the VERIFY build to check for invalid field element.
72713872a8 Add missing static to secp256k1_schnorrsig_sign_internal (Elichai Turkel)
Pull request description:
This function isn't used outside of this module so it should be declared static
ACKs for top commit:
real-or-random:
ACK 72713872a8
jonasnick:
ACK 72713872a8
Tree-SHA512: 6107a2c84c3e11ffd68de22a5288d989a3c71c2ec1ee4827c88f6165fc27ef8339d0f6740928540e8ccd03aff49a2a96149bf698ccebe6d6d8ad6e23e38e8838
adec5a1638 Add missing null check for ctx and input keys in the public API (Elichai Turkel)
f4edfc7581 Improve consistency for NULL arguments in the public interface (Elichai Turkel)
Pull request description:
I went over the public API and added missing explanations on when a pointer can be null and when it cannot,
and added some missing checks for null ctx and null pubkey pointers.
Open questions IMHO:
1. Can `secp256k1_context_create` return NULL? right now it could return null if you replaced the callbacks at compile time to ones that do return(unlike the default ones which never return).
2. Related to the first, should we document that the callbacks should never return? (in the tests we use returning callbacks but we can violate our own API) right now we say the following:
> After this callback returns, anything may happen, including crashing.
Is this enough to document answer `no` for the first question and just saying that if the callback returned then you violated the API so `secp256k1_context_create` can return NULL even though it is promised not to?
Right now we AFAICT we never check if it returns null
Another nit I'm not sure about is wording `(does nothing if NULL)`/`(ignored if NULL)`/`(can be NULL)`
More missing docs:
1. Documenting the `data` argument to the default nonce functions
ACKs for top commit:
ariard:
ACK adec5a16
jonasnick:
ACK adec5a1638
Tree-SHA512: 6fe785776b7e451e9e8cae944987f927b1eb2e2d404dfcb1b0ceb0a30bda4ce16469708920269417e5ada09739723a430e270dea1868fe7d12ccd5699dde5976
This header contains a static array that replaces the ecmult_context pre_g and pre_g_128 tables.
The gen_ecmult_static_pre_g program generates this header file.
clang 7 to 11 (and maybe earlier versions) warn about recid being
potentially unitiliazed in "CHECK(recid >= 0 [...]", which was mitigated
in commit 3d2cf6c5bd by initializing recid
to make clang happy but VG_UNDEF'ing the variable after initializiation
in order to ensure valgrind's memcheck analysis will still be sound and
complain if recid is not actually written to when creating a signature.
However, it turns out that at least for binaries produced by clang 11
(but not clang 7), valgrind complains about a branch on unitialized data
in the recid variable in that line before *and* after the aforementioned
commit. While the complaint after the commit could be spurious (clang
knows that recid is initialized, so it's fine to access it even though
the access is stupid), the complaint before the commit indicates a real
problem: it might be the case that clang is performing a wrong
optimization that leads to a situation where recid is really not
guaranteed to be initialized when it's accessed. As a result, clang
warns about this and generates code that just accesses the variable.
I'm not going to bother with this further because this is fixed in
clang 12 and the problem is just in our test code, not in the tested
code.
This commit rewrites the code in a way that groups the signing together
with the CHECK such that it's very easy to figure out for clang that
recid will be initialized properly. This seems to circument the issue.
8f093be374 musig: use tagged hash for the list of pubkeys to aggregate (Jonas Nick)
a6a768a4bf musig: make key agg test vector more precise (Jonas Nick)
Pull request description:
Top commit has no ACKs.
Tree-SHA512: 5369dc5b4039dd4cda2c50282db2882c088b96e1daa5801240f92be1832ed8f29317fdbfc3cab211707155c284a68dc593967f3141703e2544f6b8dc1553e44d
