libsecp256k1

This commit improves error handling in the benchmark programs only. It makes the benchmark tools reject invalid or non-positive values for the SECP256K1_BENCH_ITERS environment variable instead of silently using a bad value. This is a hardening/robustness fix for developer tooling, not a security fix for the cryptographic library itself.

This commit only changes the wording of an error/help message in a test program. It tells users how to run a test under valgrind for both CMake and Autotools builds. There is no security issue here.

This commit only adds descriptive labels to test cases in the project's CMake build configuration. It does not change any cryptographic code, runtime behavior, or security-sensitive logic. There is no security issue here.

This commit is a routine build-system cleanup. It changes how CMake names and discovers test cases, switching from underscores to dots in test names and using a helper module to automatically find individual tests inside test executables. There is no change to the cryptographic code, no bug fix, and no security relevance.

This commit adds mathematical self-checks (assertions) to a SageMath script used to generate internal constants for Bitcoin's secp256k1 library. It does not change any runtime code, cryptographic operations, or user-facing behavior. It only verifies that precomputed GLV constants correctly relate to a known algebraic factorization involving Eisenstein integers. There is no security vulnerability or fix here.

This commit adds a new CMake helper file used to automatically find and register test cases during the build process. It does not change any cryptographic code, wallet handling, network logic, or user-facing behavior. It is purely a build/test infrastructure addition.

This commit is a straightforward cleanup of the project's build instructions. It replaces two nearly identical blocks of CMake code with a single reusable function that creates test programs. There is no change to the actual cryptographic code, no change to what tests are run, and no indication of any security issue being fixed.

This commit only updates the help text and a printed message in a benchmark program. It does not change any cryptographic code, library behavior, or security-sensitive logic. There is no security issue here.

This commit changes several loop counters and a macro from signed 'int' or 'long' types to unsigned 'size_t' when indexing into precomputed elliptic-curve multiplication tables. The main practical effect is to avoid undefined behavior or incorrect results on platforms where the table size calculation could overflow a signed type, and to make the code's intent clearer. There is no direct evidence in the commit that this fixes an exploitable vulnerability in normal Bitcoin Core usage, but it is a defensive correctness improvement in low-level cryptographic code.

This commit changes two variable types from signed integers (int) to unsigned size types (size_t) inside a low-level elliptic-curve multiplication helper. It is a code-quality/correctness cleanup with no observable security effect: the values are always non-negative and small, and the change does not fix a bug that could be triggered by an attacker.

This is a one-line documentation update in a header file comment. It adds the CMake equivalent of an existing Autotools build option so developers know how to enable external default callbacks when building with CMake. No code behavior changes.

This commit is a pure test-code refactoring. It takes one large ElligatorSwift test function and splits it into eight smaller, independent test functions so the test runner can execute them in parallel. The commit message explicitly says 'No behavior changes,' and the diff only moves existing loops and checks into separate functions without altering the test logic, constants, or production code. There is no security issue here.

This commit adds safety checks and documentation to ensure that 'flag' values used in secret-handling code are exactly 0 or 1, not just any 'true' value. These flags control constant-time selection and memory wiping. If a caller passed a different non-zero value, the masking math could behave incorrectly and potentially leak secret information through timing or produce wrong results. The new checks only fire in special VERIFY builds, so they are a defensive hardening measure rather than a fix for an active bug.

This is a tiny internal code cleanup in a Bitcoin cryptography library. It removes an unnecessary intermediate variable and replaces it with direct 'return 1' and 'return 0' statements. The function's behavior is unchanged, and there is no security issue.

This commit only adds new test cases to the project's test suite. It checks that several public-key and signature functions correctly reject arrays that contain a NULL pointer. There are no changes to the actual library code, so this does not fix or introduce a security issue by itself. It is a hardening of the test coverage for existing API behavior.

This commit adds safety checks to several Bitcoin libsecp256k1 functions that accept arrays of pointers. Previously, if a caller passed an array containing a NULL (empty) pointer, the code might read from or process an invalid memory location, potentially causing a crash or unpredictable behavior. The new checks reject such inputs cleanly before any processing begins. It is a defensive hardening fix rather than a confirmed exploitable vulnerability.

This commit only changes the text of error messages in the benchmark program. It replaces specific outdated build instructions (referencing the old Autotools ./configure command) with a generic pointer to README.md, because the project now uses CMake. There is no change to cryptographic code, no security fix, and no vulnerability.

This commit only updates the `.gitignore` file, which tells Git which files and folders to ignore. It broadens the pattern for CMake build directories so more variations (like `build`, `build-release`, etc.) are ignored. There is no code change and no security impact.

This commit simply renames the Autotools helper directory from 'build-aux' to 'autotools-aux' and updates the related references in build files and .gitignore. It is a build-system housekeeping change with no effect on the cryptographic code or runtime security.

This commit removes an unused internal helper function for serializing public keys and updates the test code to use two newer, more specific helper functions instead. There is no indication of a security bug being fixed; it appears to be a routine code cleanup.

This commit is a small internal cleanup in the Bitcoin Core secp256k1 cryptography library. It replaces several verbose public-key serialization calls with simpler, purpose-built helper functions that always produce 33-byte compressed public keys. There is no indication this fixes a security bug; it appears to be a code-quality refactor that removes redundant error checks and boilerplate.

This is a small internal code cleanup in the Bitcoin Core secp256k1 library. It changes how public keys are converted to bytes in one public function, replacing a single flexible helper with two fixed-size helpers. There is no indication of a security bug being fixed.

This commit adds two new internal helper functions for converting elliptic-curve points into the standard 33-byte compressed and 65-byte uncompressed public-key formats. It is a straightforward code-organization change with no visible security relevance.

This change is a routine cleanup of the project's automated macOS testing configuration. It makes the 'symbol check' step use a Python virtual environment consistently across two similar jobs and removes a duplicate copy of the same script. There is no security-relevant change to the actual Bitcoin/libsecp256k1 code, no fix for a vulnerability, and no indication of a security issue.

This commit is a code-cleanup change in Bitcoin Core's libsecp256k1 cryptographic library. It replaces direct reads and writes of an internal 'infinity' flag on elliptic-curve points with calls to dedicated helper functions. The stated goal is to hide the internal field from other modules, making future mistakes less likely. There is no direct evidence in the commit that this fixes an exploitable vulnerability, but it is a defensive hardening change in security-critical code.