Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This change only edits the project's automated continuous-integration (CI) configuration file. It turns on all optional cryptographic modules by default in CI and adds test runs that disable each module one at a time. There is no change to…
No source-code changesNo build-system logic changesCI-only workflow refactor
This commit is a code cleanup (refactor) that splits one internal public-key parsing helper into three clearly named versions. It does not change what keys the public API accepts or rejects, and it adds more tests. There is no security vul…
Refactor only: no change to accepted public-key formats or validation rulesPublic API behavior preserved: 33-byte compressed and 65-byte uncompressed/hybrid still acceptedInternal fixed-size callers now use size-specific parser, reducing risk of accidental hybrid acceptance in future code
This commit only adds new test code to check that a specific Schnorr signing function behaves in a constant-time manner under Valgrind. It does not change any production cryptographic code, so it cannot introduce or fix a security vulnerab…
Only test file src/ctime_tests.c changedNo production cryptographic code modifiedAdds constant-time (CHECKMEM/Valgrind) coverage for schnorrsig_sign_custom
This commit is a code-quality and defensive-programming change. It restructures internal elliptic-curve helper functions so that runtime consistency checks (VERIFY macros) wrap the real implementation and cannot be skipped by an early 'ret…
Defensive restructuring of assertion wrappersAdds missing VERIFY post-conditions on group element outputsNo functional cryptographic change
This commit only adds new test code to check that a specific function behaves correctly when given a buffer of exactly the right size. It does not change any production code, fix a bug, or introduce a vulnerability. It is a routine improve…
This commit only adds a new test case. It checks that a DER signature can be written into a buffer that is exactly the right size, and that writing into a buffer one byte too small fails correctly. There is no change to the actual library …
This commit only adds new test cases to the libsecp256k1 test suite. It does not change any production cryptographic code. The new tests check that the DER signature parser correctly handles an unusual but valid length-encoding format (the…
Adds test coverage for DER long-form length encoding acceptance and rejectionTargets secp256k1_der_read_len boundary conditionsNo changes to src/ecdsa_impl.h or any production parsing logic
This commit only adds new test cases to the project's test suite. It does not change any production parsing code. The tests verify that the existing DER signature parser correctly accepts valid long-form length encodings and rejects invali…
This commit is a straightforward code cleanup: it removes a small internal helper function named secp256k1_get_hash_context() and replaces every call with direct access to the context's hash_ctx field. The behavior is identical; no securit…
This is a routine internal code cleanup: it moves helper functions that convert between group elements and byte strings from one internal file to another, and renames a couple of private-key tweak helpers from 'privkey' to 'seckey'. The pu…
This commit is a simple renaming of internal function names from 'privkey' to 'seckey' to match current project terminology. No behavior of the code changes, and there is no security fix or vulnerability introduced.
This is a small internal cleanup in Bitcoin Core's secp256k1 cryptography library. It replaces a manual secret-key validity check (overflow plus zero) with an existing helper function that does the same thing. The behavior is intended to b…
No security-relevant behavioral change is described or evidentRefactoring only: equivalent overflow-and-zero check via existing helperReturn value logic preserved with added parentheses for warning avoidance
This is a pure code cleanup change: it renames a function parameter from 'ctx' to 'ecmult_gen_ctx' in several internal files and moves the asterisk in pointer declarations for style consistency. No behavior, logic, or security properties o…
This commit fixes an integer overflow bug in the library's internal scratch-space memory allocator. If a caller requested a scratch space with a size near the maximum possible value, adding the allocator's own bookkeeping header could wrap…
This commit is a pure code cleanup: it renames a function parameter from 'ctx' to 'ecmult_gen_ctx' in several related files and moves the asterisk in pointer declarations from the left side to the right side (e.g., 'type* arg' to 'type *ar…
This commit fixes a low-level arithmetic overflow check in a special internal memory-pool helper called 'scratch space'. Because the scratch API is no longer exposed to users, the bug cannot be triggered by normal callers today. The change…
Integer overflow in size calculationPotential heap buffer under-allocationDefensive hardening of internal allocator helper
This commit fixes test-suite bugs, not the cryptographic library itself. Several test cases were using outputs from functions without first checking whether those functions succeeded. In rare cases a failed setup step could leave a value t…
Test-only hardeningMissing return-value checks in test codePotential false-positive test passes on setup failure
This commit is a straightforward code cleanup: it removes a tiny internal helper function called secp256k1_get_hash_context() and replaces every call with direct access to the context's hash_ctx field. The behavior is identical; no securit…
This commit is a routine post-release bookkeeping change. It bumps the project's version number from 0.8.0 to 0.8.1, marks the current code as an unreleased development snapshot, and updates the changelog accordingly. There are no code, cr…
This commit is a routine post-release bookkeeping change. It bumps the project's version number from 0.8.0 to 0.8.1, marks the current code as an unreleased development snapshot, and updates the changelog accordingly. There are no code, cr…
de02108c51ca052245c7ba154b02a890e6815fdb tests: cover compressed pubkey parsing/serialization in `_ec_pubkey_parse` test (Sebastian Falbesoner) 31b1b300e812038e5b52f534370f7bd0cae01a79 refactor: split `ge_parse` helper into explicit variants (Sebastian Falbesoner)
Pull request description:
This PR is a follow-up to #1915, see the suggestion https://github.com/bitcoin-core/secp256k1/pull/1915#pullrequestreview-4962713401.
Splits the `ge_parse` function into three explicit variants for parsing from: - compressed public keys (33-bytes, prefixes 0x02 or 0x03) - uncompressed public keys (65-bytes, prefix 0x04) - uncompressed and hybrid public keys (65-bytes, prefixes 0x04, 0x06 or 0x07)
The first two are the counter-parts for the existing serialization functions `ge_serialize{33,65}`. The latter one is only needed for legacy reasons and likely not needed in the future. Having it named explicitly helps to avoid accepting hybrid pubkeys unintentionally. `ge_parse65` is currently unused outside of tests, but one potential use-case would be the serialization of the prevouts_summary in the silentpayments light-client API PR #1912 (see commit https://github.com/bitcoin-core/secp256k1/pull/1912/changes/82b95fde6fe2c75ec940ade339013939b8ecc5ea), unless we want to define a custom serialization there (where we e.g. remove the constant prefix byte).
ACKs for top commit: fjahr: Code review ACK de02108c51ca052245c7ba154b02a890e6815fdb real-or-random: utACK de02108c51ca052245c7ba154b02a890e6815fdb
This commit is a code cleanup (refactor) that splits one internal public-key parsing helper into three clearly named versions. It does not change what keys the public API accepts or rejects, and it adds more tests. There is no security vulnerability being fixed here.
`src/ctime_tests.c` covers `secp256k1_schnorrsig_sign32` and `secp256k1_schnorrsig_sign_custom` entry points under Valgrind/CHECKMEM.
`secp256k1_schnorrsig_sign_custom` accepts optional `extraparams`, including a custom nonce function, before calling the shared internal signer. Functional tests cover this API, but previously it was not exercised under the constant-time CHECKMEM harness.
This PR adds coverage for:
- `secp256k1_schnorrsig_sign_custom(..., NULL)` using the default nonce path with NULL extraparams. - The default BIP340 nonce function with non-NULL `extraparams.ndata`. - The custom nonce callback dispatch path via a distinct `nonce_function_custom` callback that delegates to `secp256k1_nonce_function_bip340`. - Secret key material and keypair state under CHECKMEM for these signing paths.
Message and auxiliary data are not treated as secret inputs in these tests.
### Coverage gap
The existing constant-time test suite exercised `secp256k1_schnorrsig_sign32`, but did not exercise the public `secp256k1_schnorrsig_sign_custom` entry point and its custom nonce callback dispatch path under CHECKMEM.
Local synthetic mutations were used during development to verify that the added coverage reaches these paths. These mutations are not included in this branch.
This is a test-coverage improvement. No production cryptographic code is modified, and this PR does not claim a production vulnerability in unmodified libsecp256k1.
### Change
- `src/ctime_tests.c` only - No production code changes - No new dependencies
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
explicit security languagesecret or key materialsigning boundaryconstant-time or timing behaviormerge-commit duplicate discount
AI analysis · Informational 15/100
This commit only adds new test code to check that a specific Schnorr signing function behaves in a constant-time manner under Valgrind. It does not change any production cryptographic code, so it cannot introduce or fix a security vulnerability in the library itself. It is a test-coverage improvement.
c36269ef95da99498b3b62736f09dc42ffe5d094 group/refactor: Use constant expression for readability (Tim Ruffing) 031dbae6591664cf321bd9b09dd12535a5087533 group: Export secp256k1_ge_set_ge(j)_zinv properly in group.h (Tim Ruffing) 4f3bd158d5edd69cc66f39f20c42c72c776fa2d4 group: Cover all input/output ge/gej/fe with VERIFY calls (Tim Ruffing) 0711443e6da39cc98660fbeef3f989935443caa6 group: Add missing FE_VERIFY checks on rzr outputs (Tim Ruffing) 1bd7492181aca5967bbc690a4b81560101b1408b group: Remove redundant SECP256K1_GEJ_VERIFY (Tim Ruffing) cddd125f72f6156b360edb760d4ae089c3ae7a0f group: Split functions into pre/post VERIFY and _impl (Tim Ruffing)
Pull request description:
This PR splits the functions in group_impl.h in a wrapper that only performs VERIFY and an `_impl` function that has the actual code. This ensures that the post VERIFY calls are not skipped in case of early returns.
Also, this PR adds VERIFY calls wherever they were missing (inside group_impl.h)
The new structure is similar to field_impl.h but a bit simpler because we don't need to deal with two different implementations. A real difference is that, in non-VERIFY mode, field_impl.h delegates via #defines (ensure there's no overhead due to a function call) and here I decided to delegate via function calls. It keeps the code a bit simpler to read (and maybe also simpler to parser for tools such as language servers). The _impl functions all have SECP256K1_INLINE. I think every sane compiler will inline the function calls in non-VERIFY mode (even without SECP256K1_INLINE) because the body of the wrapper is really just a single function call then with the same signature.
Follow-up PR can cover modifications of ges and fes outside the group and field modules, e.g., ecmult modifies ges/gejs directly. Maybe it will be good that it does this only through group functions but we'll need to see; in C++ this module could legitimately be considered a "friend" of group.
ACKs for top commit: theStack: ACK c36269ef95da99498b3b62736f09dc42ffe5d094
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarymerge-commit duplicate discount
AI analysis · Informational 14/100
This commit is a code-quality and defensive-programming change. It restructures internal elliptic-curve helper functions so that runtime consistency checks (VERIFY macros) wrap the real implementation and cannot be skipped by an early 'return' statement. It also adds a few missing checks. These VERIFY macros are debug/test-only assertions; they are disabled in production builds, so the change does not alter normal behavior and is not a security fix for a live vulnerability.
Merge bitcoin-core/secp256k1#1928: tests: add coverage for exact-size DER signature serialization
500ccb60f70550332adf6b6f894ce84659cd6831 tests: add coverage for exact-size DER signature serialization (Bruno Garcia)
Pull request description:
The existing tests only serialize into oversized buffers or one that is far too small, so the boundary case where the output buffer is exactly the required size was untested. Check that this succeeds with identical output, and that one byte less fails while reporting the required size.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarymerge-commit duplicate discount
AI analysis · Informational 15/100
This commit only adds new test code to check that a specific function behaves correctly when given a buffer of exactly the right size. It does not change any production code, fix a bug, or introduce a vulnerability. It is a routine improvement to the test suite.
Security candidatetests: add coverage for exact-size DER signature serializationby Bruno Garcia · 500ccb60 · Sep 3, 2026 · 1 fileMessage 88 · StrongInformational 13Details
Commit message · Bruno Garcia
tests: add coverage for exact-size DER signature serialization
The existing tests only serialize into oversized buffers or one that is far too small, so the boundary case where the output buffer is exactly the required size was untested. Check that this succeeds with identical output, and that one byte less fails while reporting the required size.
88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 13/100
This commit only adds a new test case. It checks that a DER signature can be written into a buffer that is exactly the right size, and that writing into a buffer one byte too small fails correctly. There is no change to the actual library code that handles signatures, so this does not fix or introduce a security issue by itself.
Security candidateMerge bitcoin-core/secp256k1#1924: tests: add coverage for the DER long form length encodingby merge-script · a9a61831 · Aug 30, 2026 · 1 fileMessage 96 · StrongInformational 19Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1924: tests: add coverage for the DER long form length encoding
ddb1dfa77038442dff86ba90e6d0a30adfddef17 tests: add coverage for the DER long form length encoding (Bruno Garcia)
Pull request description:
random_ber_signature only emits long form lengths in signatures it marks as certainly_not_der, so run_ecdsa_der_parse asserts that such inputs are rejected but never that a well-formed long form length is accepted. As a result, inverting any of the four conditions in secp256k1_der_read_len that govern the long form goes unnoticed by the test suite.
Add the accepting cases, together with the two rejecting ones that share their boundaries: a length below 128, which must use the short form, and length octets with a leading zero. Since DER permits the long form only for lengths of at least 128, which a signature with two in-range scalars never reaches, the R integers in the accepting cases necessarily overflow to zero; the test checks the parsed values so this stays pinned down.
I noticed this lack in the tests while working on mutation testing for the ecdsa impl. So these tests kill the following mutants: https://secp256k1.space/src/ecdsa_impl.h#863, https://secp256k1.space/src/ecdsa_impl.h#878 and https://secp256k1.space/src/ecdsa_impl.h#896
ACKs for top commit: real-or-random: utACK ddb1dfa77038442dff86ba90e6d0a30adfddef17 theStack: ACK ddb1dfa77038442dff86ba90e6d0a30adfddef17
This commit only adds new test cases to the libsecp256k1 test suite. It does not change any production cryptographic code. The new tests check that the DER signature parser correctly handles an unusual but valid length-encoding format (the 'long form'), and that it rejects certain invalid variants. It is a hardening of test coverage, not a fix for a known bug or vulnerability.
Security candidatetests: add coverage for the DER long form length encodingby Bruno Garcia · ddb1dfa7 · Aug 26, 2026 · 1 fileMessage 88 · StrongInformational 15Details
Commit message · Bruno Garcia
tests: add coverage for the DER long form length encoding
random_ber_signature only emits long form lengths in signatures it marks as certainly_not_der, so run_ecdsa_der_parse asserts that such inputs are rejected but never that a well-formed long form length is accepted. As a result, inverting any of the four conditions in secp256k1_der_read_len that govern the long form goes unnoticed by the test suite.
Add the accepting cases, together with the two rejecting ones that share their boundaries: a length below 128, which must use the short form, and length octets with a leading zero. Since DER permits the long form only for lengths of at least 128, which a signature with two in-range scalars never reaches, the R integers in the accepting cases are longer than 32 bytes and are therefore parsed as zero; the test checks the parsed values so this stays pinned down.
88/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 15/100
This commit only adds new test cases to the project's test suite. It does not change any production parsing code. The tests verify that the existing DER signature parser correctly accepts valid long-form length encodings and rejects invalid ones. There is no security vulnerability being fixed here.
Security candidateMerge bitcoin-core/secp256k1#1908: refactor: replace `_get_hash_context` with direct `->hash_ctx` accessby merge-script · bae6b89a · Aug 24, 2026 · 16 filesMessage 96 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1908: refactor: replace `_get_hash_context` with direct `->hash_ctx` access
c8745f6b3ad88a8e2b0ee2953ed3cc099dc9e15c refactor: replace `_get_hash_context` with direct `->hash_ctx` access (Sebastian Falbesoner)
Pull request description:
See issue #1835: https://github.com/bitcoin-core/secp256k1/issues/1835#issue-4046371933.
ACKs for top commit: apoelstra: ACK c8745f6b3ad88a8e2b0ee2953ed3cc099dc9e15c; successfully ran local tests real-or-random: utACK c8745f6b3ad88a8e2b0ee2953ed3cc099dc9e15c
This commit is a straightforward code cleanup: it removes a small internal helper function named secp256k1_get_hash_context() and replaces every call with direct access to the context's hash_ctx field. The behavior is identical; no security bug is fixed or introduced.
Security candidateMerge bitcoin-core/secp256k1#1915: refactor: Move (de)ser helpers from musig and eckey to groupby merge-script · 86c7cbaf · Aug 19, 2026 · 10 filesMessage 98 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1915: refactor: Move (de)ser helpers from musig and eckey to group
bfd40bd0ce0e7cac4f6bb395ccfe90eaf625feb1 refactor: Rename privkey to seckey in eckey helpers (Fabian Jahr) d8ee6e6cf6706c00562a584715cb2b8c41df7cb2 refactor: Move parsing helpers from musig to group (Fabian Jahr) 2577fb1888c021752dc6edbfa6df3216daa9ccb1 refactor: Move pubkey parsing and serialization from eckey to group (Fabian Jahr)
Pull request description:
These two helpers, `secp256k1_musig_ge_serialize_ext` and `secp256k1_musig_ge_parse_ext`, aren't really musig-specific. They (de)serialize a group element that can also be the point at infinity. This moves them to `eckey` as `secp256k1_eckey_serialize_ext` and `secp256k1_eckey_parse_ext`. They can't move further down to group.h because they depend on other `eckey` functions internally. There should be no functional change here.
I stumbled upon this while working on #1754 where I would want to reuse these helpers in that module, so it is split out of that. But the change seems to make sense on its own as well, so I wouldn't consider this prep work alone.
ACKs for top commit: theStack: ACK bfd40bd0ce0e7cac4f6bb395ccfe90eaf625feb1 real-or-random: utACK bfd40bd0ce0e7cac4f6bb395ccfe90eaf625feb1
This is a routine internal code cleanup: it moves helper functions that convert between group elements and byte strings from one internal file to another, and renames a couple of private-key tweak helpers from 'privkey' to 'seckey'. The public behavior of the library is unchanged, and the commit message explicitly states there should be no functional change.
Security candidaterefactor: Rename privkey to seckey in eckey helpersby Fabian Jahr · bfd40bd0 · Aug 17, 2026 · 3 filesMessage 62 · AdequateInformational 15Details
Commit message · Fabian Jahr
refactor: Rename privkey to seckey in eckey helpers
62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100
This commit is a simple renaming of internal function names from 'privkey' to 'seckey' to match current project terminology. No behavior of the code changes, and there is no security fix or vulnerability introduced.
Merge bitcoin-core/secp256k1#1916: ecdh/ellswift: simplify seckey loading with `_scalar_set_b32_seckey`
c00dc8181054fb31a0149ce03ef8413300a3a8bf ecdh/ellswift: simplify seckey loading with `_scalar_set_b32_seckey` (Sebastian Falbesoner)
Pull request description:
Instead of checking for overflow and zero manually, use the existing `_scalar_set_b32_seckey` helper which does both and returns zero if either of these two conditions apply. This can be seen as a very late follow-up to PR #701, commit 3fec9826086aa45ebbac1ff6fc3bb7b25ca78b1d, where the helper has been introduced and applied to the functions `_ecdsa_sign`, `_pubkey_create` and `_seckey_verify`. The variable name `is_sec_valid` has been chosen as it is currently also used in [`secp256k1_ecdsa_sign_inner`](https://github.com/bitcoin-core/secp256k1/blob/439278a649d3099d62dde966a76dc04aaca7ccb3/src/secp256k1.c#L555).
Note that introducing parantheses around `!!ret` was necessary to avoid warnings in the following form: ``` /home/thestack/secp256k1_master/src/modules/ecdh/main_impl.h: In function ‘secp256k1_ecdh’: /home/thestack/secp256k1_master/src/modules/ecdh/main_impl.h:74:12: warning: suggest parentheses around operand of ‘!’ or change ‘&’ to ‘&&’ or ‘ !’ to ‘~’ [-Wparentheses] 74 | return !!ret & is_sec_valid; | ^~~~~ ```
ACKs for top commit: real-or-random: utACK c00dc8181054fb31a0149ce03ef8413300a3a8bf
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
memory safetymerge-commit duplicate discount
AI analysis · Informational 18/100
This is a small internal cleanup in Bitcoin Core's secp256k1 cryptography library. It replaces a manual secret-key validity check (overflow plus zero) with an existing helper function that does the same thing. The behavior is intended to be identical; no security vulnerability is described or visible in the code change.
Security candidateMerge bitcoin-core/secp256k1#1911: refactor: rename `ctx` param to `ecmult_gen_ctx` where applicableby merge-script · 3d69f4ce · Aug 17, 2026 · 4 filesMessage 86 · StrongInformational 15Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1911: refactor: rename `ctx` param to `ecmult_gen_ctx` where applicable
81a5a7567d10b358e6e41ef6085adf2ab2abc879 refactor: rename `ctx` param to `ecmult_gen_ctx` where applicable (Sebastian Falbesoner)
Pull request description:
To be more consistent and avoid confusion with regular `secp256k1_context` instances, rename the `ctx` parameter to `ecmult_gen_ctx` in all functions that take `secp256k1_ecmult_gen_context` pointers (see discussion https://github.com/bitcoin-core/secp256k1/issues/1835#issuecomment-4057203336 ff.).
While at it, move the * in pointer declarations of the touched functions to the right side for consistency across the code base, see PR #1252.
ACKs for top commit: real-or-random: utACK 81a5a7567d10b358e6e41ef6085adf2ab2abc879
This is a pure code cleanup change: it renames a function parameter from 'ctx' to 'ecmult_gen_ctx' in several internal files and moves the asterisk in pointer declarations for style consistency. No behavior, logic, or security properties of the code are changed.
Security candidateMerge bitcoin-core/secp256k1#1910: scratch: reject sizes that overflow when added to headerby merge-script · 439278a6 · Aug 16, 2026 · 2 filesMessage 86 · StrongLow 27Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1910: scratch: reject sizes that overflow when added to header
3d4340d17325a6732108423f9d3e54de99539a60 scratch: reject sizes that overflow when added to header (Sebastian Falbesoner)
Pull request description:
We only use scratch space internally, so this is not an issue for the user (scratch API functions have been removed since 0.6.0, see #1620), but fixing this might still make sense to prepare for the unlikely case that we expose the scratch API again in the future. An alternative could be to simply delete the scratch space functionality already, as e.g. done in PR #1789.
Reported by [Project Loupe](https://github.com/project-loupe)
ACKs for top commit: apoelstra: utACK 3d4340d17325a6732108423f9d3e54de99539a60 real-or-random: utACK 3d4340d17325a6732108423f9d3e54de99539a60
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
memory safetymerge-commit duplicate discount
AI analysis · Low 27/100
This commit fixes an integer overflow bug in the library's internal scratch-space memory allocator. If a caller requested a scratch space with a size near the maximum possible value, adding the allocator's own bookkeeping header could wrap around to a tiny total size. That tiny allocation would then be used as if it were huge, potentially causing memory corruption. However, the scratch-space API is no longer exposed to users, so normal applications cannot trigger this.
Security candidaterefactor: rename `ctx` param to `ecmult_gen_ctx` where applicableby Sebastian Falbesoner · 81a5a756 · Aug 7, 2026 · 4 filesMessage 93 · StrongInformational 15Details
Commit message · Sebastian Falbesoner
refactor: rename `ctx` param to `ecmult_gen_ctx` where applicable
To be more consistent and avoid confusion with regular `_context` instances, rename the `ctx` parameter to `ecmult_gen_ctx` in all functions that take `_ecmult_gen_context` pointers.
While at it, move the * in pointer declarations of the touched functions to the right side for consistency across the code base, see PR #1252.
93/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100
This commit is a pure code cleanup: it renames a function parameter from 'ctx' to 'ecmult_gen_ctx' in several related files and moves the asterisk in pointer declarations from the left side to the right side (e.g., 'type* arg' to 'type *arg'). No behavior changes, no bug fixes, and no security fixes are present.
Security candidatescratch: reject sizes that overflow when added to headerby Sebastian Falbesoner · 3d4340d1 · Aug 5, 2026 · 2 filesMessage 86 · StrongInformational 23Details
Commit message · Sebastian Falbesoner
scratch: reject sizes that overflow when added to header
We only use scratch space internally, so this is not an issue for the user (scratch API functions have been removed since 0.6.0), but fixing this might still make sense to prepare for the unlikely case that we expose the scratch API again in the future. An alternative could be to simply delete the scratch space functionality already, as e.g. done in PR #1789.
86/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Informational 23/100
This commit fixes a low-level arithmetic overflow check in a special internal memory-pool helper called 'scratch space'. Because the scratch API is no longer exposed to users, the bug cannot be triggered by normal callers today. The change adds a guard so that an impossibly large requested size does not silently wrap around and produce a smaller memory allocation than intended.
Security candidateMerge bitcoin-core/secp256k1#1897: tests: check results before using outputsby merge-script · 687155df · Aug 4, 2026 · 8 filesMessage 96 · StrongInformational 20Details
Commit message · merge-script
Merge bitcoin-core/secp256k1#1897: tests: check results before using outputs
a2ad68cd81787ba70b2caff0a57998ae8a5b4834 ec: check pubkey sort test results (Lőrinc) 93280c22917c018f4e99d76e4398e66405c887bd silentpayments: check test serialization (Lőrinc) b8de1bc30f917c0ab9f05aeaeb494834e81513e2 musig: check infinity test setup (Lőrinc) 0618af81317307466e9968592880a54229885edc extrakeys: check test pubkey loads (Lőrinc) 1d3f72d3fa8e476cdc3344dbb5aebeaf7a6efe89 recovery: check exhaustive API results (Lőrinc) 564afb0b06e6124092fd6fa1239b1b397f742e41 ellswift: check test operation results (Lőrinc) 658c7edc24832592969ccbd1bdbc5c59e1ccc5d5 tests: check exhaustive ecmult success (Lőrinc)
Pull request description:
**Problem:** Several tests inspect outputs from deterministic operations without checking the result. The later output comparisons usually still exercise behavior, but a failed setup call can leave an output that accidentally satisfies a later assertion. In `pubnonce_summing_to_inf`, `secp256k1_musig_sum_pubnonces` initializes both sums to infinity before a pubnonce load can fail, so the test could pass without constructing a valid opposing-nonce pair.
**Fix:** Check the result of each deterministic operation before reading its output in the affected exhaustive, EllSwift, recovery, extrakeys, MuSig, silent-payments, and public-key sort tests. Leave deliberately ignored results alone when the test permits either result or validates a mutated value rather than an auxiliary carry, overflow, or sign flag.
ACKs for top commit: 151henry151: Tested ACK a2ad68cd81787ba70b2caff0a57998ae8a5b4834 real-or-random: utACK a2ad68cd81787ba70b2caff0a57998ae8a5b4834 theStack: ACK a2ad68cd81787ba70b2caff0a57998ae8a5b4834
This commit fixes test-suite bugs, not the cryptographic library itself. Several test cases were using outputs from functions without first checking whether those functions succeeded. In rare cases a failed setup step could leave a value that accidentally passed a later check, making the test look successful when it shouldn't. The patch adds result checks so tests fail loudly if a setup step fails. There is no direct security risk to users of the library.
Security candidaterefactor: replace `_get_hash_context` with direct `->hash_ctx` accessby Sebastian Falbesoner · c8745f6b · Aug 4, 2026 · 16 filesMessage 85 · StrongInformational 15Details
Commit message · Sebastian Falbesoner
refactor: replace `_get_hash_context` with direct `->hash_ctx` access
See issue #1835 ("Follow-ups to #1777").
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100
This commit is a straightforward code cleanup: it removes a tiny internal helper function called secp256k1_get_hash_context() and replaces every call with direct access to the context's hash_ctx field. The behavior is identical; no security bug is fixed or introduced.
sha256: cross-check caller supplied compression function
The existing selftest hashes one 63 byte string against a known digest. Which catches a compression function that is wrong everywhere, but not one that is wrong on multi-block calls, unaligned input, or a state that is not the IV.
This introduces secp256k1_sha256_smoke_test, which hashes messages of various lengths and starting offsets with both the supplied function and the built-in one, and fails if the digest differs.
The check runs once during startup, so a faulty compression function is caught early rather than silently producing incorrect output later.
Measured locally, this takes 1.5ms, which should be negligible for any application.
See the introduced test for a clear view of the bugs this catches.
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
cryptography-sensitive path
AI analysis · Low 26/100
This commit strengthens the library's startup self-test for SHA-256 compression functions that users can plug in. It adds a more thorough 'smoke test' that compares the user-supplied function against the built-in one across many message lengths and memory alignments. The goal is to catch buggy or incompatible custom SHA-256 code early, before it silently produces wrong hashes. It is a defensive hardening change, not a fix for an active security hole.
✓ Descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
signing boundarydocumentation-only discount
AI analysis · Informational 15/100
This commit updates the project's release instructions to add a new step: creating a GPG-signed source-code tarball when making a release. It is a documentation-only change that improves release integrity and does not modify any code or fix a security bug.
Security candidateheader: Add note on SHA256 override and aux functionsby Tim Ruffing · 4147f8bd · Jul 29, 2026 · 1 fileMessage 58 · ThinInformational 15Details
Commit message · Tim Ruffing
header: Add note on SHA256 override and aux functions
Resolves one item in #1835.
58/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Informational 15/100
This commit only adds a documentation note to a public header file. It explains that certain auxiliary functions, when called directly by user code, will not use a user-installed SHA256 override callback because they do not receive a library context object. There is no code change, no behavior change, and no security fix.
Security candidateecdsa/ecdh: Use SHA256 override if known noncefp/hashfp is passedby Tim Ruffing · ed091bc4 · Jul 29, 2026 · 2 filesMessage 50 · ThinLow 32Details
Commit message · Tim Ruffing
ecdsa/ecdh: Use SHA256 override if known noncefp/hashfp is passed
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Low 32/100
This small change makes Bitcoin's cryptographic library treat two built-in functions (the default ECDSA nonce generator and the default ECDH hash function) as 'default' choices even when a caller explicitly passes them. The practical effect is that these built-in functions now receive the library context's hash function, which matters when the library is compiled with a custom hash implementation. Without this fix, a caller passing the same built-in function by name could accidentally bypass the context's hash function and use a different code path. There is no direct evidence in the commit of an exploitable vulnerability; it looks like a consistency/correctness fix.
This context pointer has been deprecated since the rename to `_context_static` more than three and a half years ago (see PR #1126, commit 53796d2b24e813750feae73e85c0a6eee40dc391), for the first official release 0.2.0. Removing it should be fine by now.
71/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive path
AI analysis · Informational 21/100
This commit removes an old, renamed pointer called secp256k1_context_no_precomp from the secp256k1 cryptographic library. It had been marked as deprecated for over three years and was only an alias for the newer secp256k1_context_static. The change is a routine API cleanup, not a security fix, but any external code still using the old name will fail to compile or link after updating.
Remove deprecated `secp256k1_schnorrsig_sign` alias
This function has been deprecated since the rename to `_schnorrsig_sign32` more than three and a half years ago (see PR #1089, commit 99e6568fc6), before the first official release 0.2.0. Removing it should be fine by now.
71/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
cryptography-sensitive path
AI analysis · Informational 19/100
This commit removes an old, renamed function called secp256k1_schnorrsig_sign from the libsecp256k1 cryptographic library. It had been marked as deprecated for over three years and was simply an alias pointing to the newer secp256k1_schnorrsig_sign32. Any software still using the old name will fail to compile or link after this change, but the actual signing behavior is unchanged. There is no security vulnerability introduced by this cleanup.
The exhaustive recovery tests decoded and verified signatures without requiring recoverable signing or conversion to succeed. Check those documented success results before consuming the outputs, matching the ordinary exhaustive signing test.
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundary
AI analysis · Informational 17/100
This commit tightens a test suite for the secp256k1 cryptographic library. It adds checks to ensure that recoverable signing and signature conversion succeed before using their outputs. It does not change the library's actual signing or verification code, so it does not fix a live security bug in production software. It is a defensive improvement to testing.
The EllSwift tests inspected outputs without requiring encoding, decoding, or public-key loading to succeed. They also discarded the field parser result despite relying on its no-overflow precondition. Check each deterministic success result before inspecting its output.
83/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
memory safety
AI analysis · Informational 17/100
This commit fixes test code for the EllSwift module so that it actually checks whether encoding, decoding, and public-key loading operations succeed before using their outputs. Previously the tests silently ignored failure return values, which could hide bugs during testing but does not change the production library behavior or introduce a direct vulnerability in running software.
