libsecp256k1

This is a tiny test-only change. It makes one unit test compare the full 66-byte MuSig aggregate nonce output instead of only the first 33 bytes. It does not change any production code, cryptographic behavior, or library API.

This commit only fixes wording in the API documentation comments. It changes the description of a function output parameter from 'pointer to an array' to 'pointer to a signature object' in two header files. No actual code behavior changed, so there is no security impact.

This is a small defensive cleanup in Bitcoin Core's libsecp256k1 MuSig code. The function that generates a cryptographic nonce could, in rare error cases, leave a temporary copy of the user's secret key in memory instead of wiping it. The patch makes sure the secret key buffer is always cleared, even when the internal function fails. The actual failure path can only be reached if the API is misused (bad keypair or cache), so this is best-practice hardening rather than an active exploit.

This commit simply updates the version number of an experimental GCC compiler snapshot used in automated testing, from version 16 to version 17. It is a routine CI/infrastructure maintenance change with no security relevance.

This change updates the project's automated testing setup for Windows builds. It stops using a third-party GitHub Action called `ilammy/msvc-dev-cmd` to prepare the Microsoft C++ compiler, and instead runs a built-in Microsoft batch file directly. The commit message says the third-party tool is considered abandoned and unsafe, so this is a preventive security hygiene change rather than a fix for an active vulnerability in the project's own code.

This commit tightens internal safety checks in the code that extracts bit chunks from large secret numbers (scalars) used in elliptic-curve cryptography. The changes make the library more defensive against accidental misuse, but the added checks are only active in special test/verification builds, not in normal production builds. There is no direct evidence this fixes an exploitable vulnerability in released software.

This commit simply updates several GitHub Actions workflow dependencies to newer major versions because the older versions rely on a Node.js runtime that GitHub is deprecating. It does not change any cryptographic code, build logic, or project behavior. There is no security vulnerability being fixed here.

This is a small code-quality change in Bitcoin Core's secp256k1 cryptographic library. It adds an explicit safety check confirming that a value converted from one internal format to another stays within the expected range, and it silences a compiler warning about an unused return value. The commit message frames this as avoiding a compiler warning, not fixing a security bug.

This is a minor test-code change that rewrites how two hash functions are selected inside a loop so the code complies with the older C89 standard. It does not change what the tests actually do, and it is not a security fix.

This commit only adds a documentation comment and extra test cases for an already-supported calling convention of an internal elliptic-curve multiplication function. It does not change any behavior or fix any bug.

This is a one-line internal code cleanup in Bitcoin's secp256k1 cryptographic library. It changes how a public-key tweaking function passes a zero value to the elliptic-curve multiplication routine, switching from an explicit zero scalar to a special NULL pointer that the same routine already understands. The commit message gives no security rationale, and the diff alone does not show a fix for an exploitable bug. It is best treated as a defensive correctness or performance simplification rather than a security patch.

This commit adds a new public API that lets users of the libsecp256k1 cryptography library swap out the internal SHA-256 compression function at runtime, typically to use a faster hardware-accelerated version. The library checks that the replacement behaves like the real SHA-256 step before accepting it. The change itself is a feature addition, not a bug fix, and there is no evidence in the commit or supplied references that it addresses a known security vulnerability.

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.