libsecp256k1

This commit is a performance improvement to the SHA-256 hashing code in libsecp256k1. It makes the code compress multiple 64-byte data blocks directly from the caller's input buffer instead of first copying each block into a small internal buffer. The change is purely an optimization and does not alter the final hash output. New tests confirm that hashing the same data in one large write or many small writes produces identical results.

This commit is a large but purely structural refactor of the libsecp256k1 cryptographic library. It threads a new 'hash context' through every SHA-256, HMAC-SHA-256, and RFC 6979 operation so that a different SHA-256 compression implementation (for example a faster hardware version) can be plugged in later. The commit message explicitly calls it a 'mechanical change with no behavior change,' and the code keeps the existing software compression function as the default everywhere. There is no security bug or vulnerability visible in this patch.

This commit removes a test-only debug printout that displayed a random 16-byte value at the end of the exhaustive test suite. It does not change any cryptographic code, network behavior, or production logic. There is no security relevance.

This commit is a straightforward internal cleanup: it introduces a helper function to set up SHA-256 hash states that have already been partially computed (so-called 'midstates') and replaces repeated manual setup code with calls to that helper. It does not change any cryptographic outputs, add new features, or fix a bug. It is not a security patch.

This is a one-line fix in the project's automated testing configuration. It renames a build option used only by the CI test runner from an old name (ECMULTGENPRECISION) to the current name (ECMULTGENKB). The change does not touch any cryptographic code, does not affect released binaries, and has no security relevance.

This commit removes a temporary workaround in the project's CI Docker build file. The workaround had relaxed a PGP signature policy check so that an older LLVM repository signing key would still be accepted by Debian's package manager during automated testing image builds. Removing the workaround simply restores the normal, stricter policy. There is no direct security vulnerability in the project's own code, and no runtime software is changed.

This commit is a simple code cleanup: it introduces a standard ARRAY_SIZE macro and replaces repeated manual array-size calculations with that macro. It does not change any behavior, fix any bug, or alter any security-sensitive logic. There is no security issue here.

This commit only adds new test cases to verify that the ellswift XDH function correctly rejects invalid secret scalar values (zero, the curve order, and values above the curve order) while accepting a value just below the curve order. It does not change any production code, so it does not introduce or fix a live security vulnerability on its own.

This commit fixes a bug in the ElligatorSwift-based ECDH key exchange function. The function was supposed to reject secret keys that are invalid (zero or greater than or equal to the curve order), but due to a one-character bug it only checked for zero keys and silently accepted too-large keys by reducing them modulo the curve order. The fix makes it reject both invalid cases, matching the behavior of the regular ECDH function. There is no evidence this was exploited or that it caused real-world harm, but it is a genuine cryptographic correctness issue.

This is a small GitHub Actions CI maintenance change. It changes how the workflow picks which Docker image to run, switching from 'use the most recently built image found on the runner' to 'use the exact image ID produced by a specific build step'. This makes the CI pipeline more reliable and predictable, but it is not a security fix and does not change any cryptographic or network-facing code in the secp256k1 library itself.

This change is a minor cleanup to the help text of benchmark programs. It makes the printed usage instructions show the actual program name (for example, how the program was launched) instead of a hardcoded name like './bench'. There is no security issue here.

This commit only adds new unit tests for an existing internal function that checks whether a number has overflowed the secp256k1 group order. It does not change any production code, cryptographic logic, or behavior that could affect users. The change improves test coverage but introduces no security issue.

This is a tiny CI maintenance fix. It forces a shell arithmetic expression to treat a week number as a regular decimal number, preventing a rare misinterpretation if the week number happens to start with a zero. There is no security issue in the code being changed.

This commit changes a GitHub Actions CI setting to stop Docker from printing extra build summary messages. It is a cosmetic/workflow cleanup change with no security relevance.

This commit is a straightforward code cleanup: it removes unnecessary type casts in front of memory allocation calls like malloc. In modern C, casting the result of malloc is not needed and is generally discouraged. The change does not alter program behavior, fix a bug, or address a security issue. It touches mostly test and benchmark code, with only two small changes in production functions that create or clone a cryptographic context.

This commit adds a new compiler warning flag that alerts developers when source code lines begin with spaces instead of tabs. It is a code-style/build-hygiene change only and does not alter any runtime behavior, fix any vulnerability, or change how the library processes cryptographic data.

This commit only adds a new compiler warning flag that flags trailing whitespace in source code. It is a code-quality/build-hygiene change, not a security fix. The only functional code change is a pragma to suppress that warning around a system header (Valgrind's memcheck.h) that may contain trailing whitespace. There is no vulnerability being patched.

This commit only removes invisible trailing spaces at the ends of three lines across three source files. It does not change any program logic, function behavior, or security properties. There is no security relevance.

This commit adds a weekly timer to the project's GitHub Actions CI workflow so tests run automatically every Monday morning. It is purely an infrastructure/maintenance change and does not modify any cryptographic code, build scripts, or user-facing behavior.

This commit changes how Bitcoin Core's libsecp256k1 project manages its automated build cache for Docker images. It makes the cache key include the current week number divided by 4, so the cache is effectively thrown away and rebuilt about once a month. This is a routine maintenance improvement to avoid relying on stale cached build layers forever. It is not a security fix and does not change any cryptographic or network code.

This commit changes a CI Docker build script so that an older SHA-1-based PGP signature from the LLVM apt repository is still accepted. It is a build-infrastructure workaround, not a change to the secp256k1 cryptographic code, and it does not introduce a vulnerability in the library itself.

This commit is a one-line update to the project's internal release-process documentation. It reminds maintainers to add a matching '[Unreleased]' hyperlink at the bottom of the changelog, not just the section header. There is no code change, no cryptographic change, and no security relevance.

This commit is a routine post-release housekeeping change. It bumps the project's version number from 0.7.1 to 0.7.2, marks the current code as an unreleased development snapshot, and updates the changelog accordingly. There are no code behavior changes, no bug fixes, and no security implications.

This commit is purely a release bookkeeping change. It renames the 'Unreleased' section in the changelog to version 0.7.1, adds an ABI compatibility note, and flips a build flag from 'not a release' to 'is a release'. No code behavior changes and no security fix is introduced here.

This commit only updates the project's CHANGELOG.md file in preparation for a release. It documents two prior fixes: one that tries harder to scrub cryptographic secrets from memory, and one that fixes a build configuration issue where strict compiler flags could accidentally disable optimized assembly code. The commit itself does not change any source code, so it cannot introduce or fix a vulnerability directly.