libsecp256k1

This is a small cleanup in a benchmark test file for the ECDH module. It replaces a dynamically created cryptographic context with a pre-built static one and removes the matching cleanup call. The change is about making the benchmark follow the intended API more cleanly; it does not fix an exploitable vulnerability in production code.

This commit only updates the documentation comments for a function in a header file. It clarifies what the return value of secp256k1_ecdsa_recover means and explains a subtle detail about signature normalization after converting a recoverable signature. No code logic was changed, so there is no security vulnerability or fix here.

This commit is a simple code cleanup: it moves a small helper function that reads the system clock from one internal test/benchmark header file to a new shared test header file. There is no change to the cryptographic library, no change to how Bitcoin transactions or keys are handled, and no security fix or vulnerability introduced.

This commit is a simple cleanup in the test code. It replaces several copies of the same 32-byte secp256k1 curve group-order constant with a single shared constant. There is no change to the actual cryptographic library or to how tests behave; it only removes duplicated code.

This commit is a code-quality and testing-hardening change inside a widely used cryptographic library. It splits one internal memory-wiping helper into two: one that guarantees zeros (used where the code later reads the buffer) and one that intentionally marks memory as undefined in test builds (used where the buffer should never be read again). The only functional change visible in the diff is replacing a plain memset with the guaranteed-zero helper in one MuSig partial-signing path, which makes the code's intent clearer and avoids a potential test-only false positive. There is no direct evidence this fixes an exploitable vulnerability in production.

This change removes a fallback path in an internal ABI-checking shell script. It is a cleanup of build tooling with no effect on the cryptographic library or its security.

This is a one-line documentation update. It clarifies that a specific function should not be called with a special read-only context object named secp256k1_context_static. There is no code change and no security fix.

This commit fixes a small but real security hygiene issue in the Schnorr signature code. A 32-byte buffer that holds the secret signing nonce (the random-like value 'k') was not being wiped from memory after use. The patch renames the buffer to make its sensitive role obvious and adds an explicit clear operation so the nonce does not linger in stack memory after the function returns. If an attacker could read leftover process memory, the un-cleared nonce could help forge signatures for that message/key. The fix is straightforward and aligns the Schnorr code with the existing ECDSA behavior.

This commit fixes a variable type mismatch in the RFC6979 nonce-generation code. The code copies a `size_t` length value into an `int` variable. On platforms where `int` is 32 bits and `size_t` is 64 bits, requesting more than about 2 billion bytes of output would cause the `int` to wrap around to a negative value. That negative value would then be treated as a very large positive number in later comparisons, potentially causing the loop to run far too long or to access memory out of bounds, which could crash or hang the program. In practice, callers inside libsecp256k1 request only 32 bytes, so the bug is unlikely to be reachable from normal use.

This commit only expands the project's automated testing on Windows by adding more clang-cl build configurations to GitHub Actions. It does not change any library code, cryptographic logic, or user-facing behavior. There is no security issue here.

This commit is a large repository import or merge that brings in the entire libsecp256k1 codebase, including build systems, CI configuration, documentation, and source files. The commit title says it only updates Windows build documentation to recommend clang-cl, but the actual diff shows a wholesale addition of 175 files. There is no code change that fixes or introduces a security vulnerability in the cryptographic library itself.

This commit is a test-only cleanup. It moves a helper function that checks SHA256 'tagged hash' setup from one test file to a shared test file, renames it, and updates several test modules to use the shared helper. There are no changes to the actual cryptographic library code that users rely on, and no security bug is fixed or introduced.

This commit only fixes a broken hyperlink in a code comment, replacing an outdated academic paper URL with a working one. No code behavior changes.

This commit only updates developer documentation (CONTRIBUTING.md) to add a command-line flag to code-coverage reporting instructions. It does not change any program code, build scripts, cryptographic logic, or runtime behavior. There is no security relevance.

This commit only updates developer documentation. It adds a command-line option to two example gcovr (code coverage reporting) commands so they work with newer versions of the tool. There is no change to source code, build scripts, tests, or anything users run.

This commit only updates documentation. It changes two example commands in CONTRIBUTING.md so that code-coverage reports exclude additional benchmark-only header files. There is no code change, no security fix, and no change to how the software runs.

This commit only rewords the help text shown when a developer runs ./configure --help. It changes the description of the --enable-coverage option from mentioning 'kcov' to a more generic phrase. There is no code, build logic, or security change.

This commit fixes a spelling mistake in a comment inside a Dockerfile used for automated testing. It changes 'dkpg-dev' to 'dpkg-dev' in an explanatory note only. No actual code, package names, or build behavior is changed.