libwally-core

This is a small internal cleanup in transaction parsing code. The developer removed an unnecessary 'destination' parameter from several helper macros and made them use an existing pointer variable directly. There is no change to security behavior, no bug fix, and no new feature.

This commit only adds new build options and a test harness for fuzzing (automated security testing). It does not change any existing library code that handles PSBTs or other data, so it cannot by itself introduce a security vulnerability or fix one. It is purely an infrastructure addition to help future security testing.

This commit simply updates the version of a build tool (webpack) used during development of the WebAssembly package. It does not change any runtime code that handles keys, transactions, or cryptography. There is no direct security issue visible in the change itself.

This commit fixes a bounds-check bug when reading confidential asset or value commitments in Bitcoin/Elements transactions. Before the fix, the code read the first byte of a commitment to decide its type without first confirming that at least one byte remained in the buffer. A malformed, truncated transaction could therefore read one byte past the end of the input data, potentially causing an out-of-bounds read. The patch adds a one-byte length check before that first read.

This is a tiny code cleanup change. The function previously calculated 'bytes + bytes_len' and assigned it to 'end' before checking whether 'bytes' was NULL. AddressSanitizer (a debugging tool) flags arithmetic on NULL pointers even when the result is never used, which made fuzzing tests falsely report memory leaks. The patch moves that calculation to after the NULL check so the debugging tool stays quiet. There is no user-facing bug or security vulnerability being fixed here.

This commit fixes a memory-management bug in the library's Partially Signed Bitcoin Transaction (PSBT) handling. When the code failed to allocate memory for new transaction inputs or outputs, it could leave behind partially initialized data and might not clean up old input/output records properly. The patch makes sure initialization only happens if memory was actually allocated, and that any old or partially built data is fully freed before returning an error. In practice this is mainly a reliability/hardening fix against out-of-memory conditions rather than a directly exploitable attack path.

This is a routine automated update by Dependabot that bumps the webpack JavaScript build tool from version 5.94.0 to 5.105.0 inside the WebAssembly package directory. It only changes the package-lock.json lockfile and does not alter any of the project's own cryptographic or wallet code. The update is a development dependency, so it only affects how the package is built, not what end users run in production. There is no indication in the commit that this fixes a specific security vulnerability.

This commit is a routine version bump from 1.5.1 to 1.5.2 across build files, documentation, and package metadata. It changes only version numbers and the library compatibility age/current values; no source code logic is modified. There is no security-relevant change in the diff itself.

This commit only updates the project's CHANGES.md release notes file. It documents what was added, changed, and fixed in version 1.5.2, but it does not modify any source code, build scripts, or cryptographic logic. The actual security-relevant fixes were made in earlier commits that are merely summarized here.

This commit fixes a parsing bug in how the library reads Bitcoin-style witness data from a transaction or PSBT. Before the fix, a malformed input could claim there were millions of witnesses while only providing a few bytes. The code would then try to read far beyond the available data, likely causing a crash or memory corruption. The fix adds a simple size check so the parser rejects obviously impossible inputs early.

This commit fixes a bug in how the library reads compact size numbers from PSBT (Partially Signed Bitcoin Transaction) data. Before the fix, the code could read past the end of a short input buffer when checking how many bytes a variable-length integer needs. The fix adds a check that at least one byte is available before asking how long the integer is. This is a memory-safety bug that could cause crashes or undefined behavior when parsing malformed PSBT data.

This commit adds new test data and a test case to check that the library can correctly read and write two special Elements transactions. The transactions involve asset issuance or reissuance token amounts larger than normally allowed. There is no code change to the library itself—only new tests—so this is a defensive test addition rather than a fix for an active vulnerability.

This commit fixes a bug in how a special Bitcoin/Elements signature hash flag (BIP118 ANYPREVOUTANYSCRIPT) is processed. Because of the order of checks, the code was accidentally treating ANYPREVOUTANYSCRIPT as if it also needed to include the previous transaction output in the hash, which it should not. This could cause signatures created or verified with this flag to be incorrect, potentially leading to invalid transactions or, in the worst case, a signature that could be reused in unexpected ways.

This commit replaces a simple length check on Taproot control blocks with a dedicated verification function. The change is likely a hardening or correctness improvement rather than a clear-cut security fix. The old check only ensured the control block had a valid-looking size; the new function may also validate internal structure, such as the parity bit and merkle proof path. Without the implementation of the new verification function, we cannot confirm whether it closes a real vulnerability or just reduces duplicated logic.

This commit adds a new public helper function that checks whether a chunk of taproot-related data (a BIP-341 control block) is well-formed. It is purely a validation/verification addition and does not change existing behavior or fix a bug. There is no indication in the commit that it addresses a security vulnerability.

This commit fixes a validation check in a Bitcoin-related cryptographic library (libwally-core). Specifically, it corrects how the code verifies the length of a 'merkle path' used in Taproot transactions. Before the fix, the code only checked that the path length was a multiple of 32 bytes, but did not enforce the BIP-0341 rule that a Taproot merkle path can have at most 128 such 32-byte elements. The new check also incorrectly tries to limit the length, but contains a bug: it checks `val_len % SHA256_LEN > 128u`, which compares a remainder (always 0 to 31) against 128, so it never triggers. This means the intended 128-element limit is still not actually enforced, making the fix partial or ineffective.

This commit changes a single function call argument so that adding a duplicate merkle path to a map is ignored rather than rejected with an error. The change aligns this function with other similar 'add' functions in the same file. It is best understood as a consistency/robustness fix, but the commit message does not frame it as a security fix and no exploit path is demonstrated.

This commit fixes two small but meaningful memory-handling bugs in a Bitcoin/Elements cryptographic library. One fix changes a memory-clearing call so it actually wipes the intended structure instead of just a pointer variable. The other changes an index variable from a signed to an unsigned type, preventing a subtle type-related bug when handling special transaction issuance flags. The commit message does not describe these as security fixes, but the memory-clearing fix in particular is the kind of issue that can leave secret key material or sensitive data in memory longer than intended.

This commit only adds a new automated build test to the project's continuous integration (CI) configuration. It ensures the software can be compiled with a specific optional feature turned off. There are no code changes that affect how the library behaves, and nothing in the commit suggests a security problem or fix.

This commit fixes compilation errors that occur when libwally-core is built with Elements/Liquid sidechain support disabled (enable-elements-abi=no). It wraps Elements-only code in preprocessor guards and removes an unused variable warning. There is no direct evidence this is a security vulnerability; it is a build-configuration bug fix.

This commit changes how Python tests are run during the build process. Instead of running Python test scripts directly against the built library files, it now creates a temporary Python virtual environment, installs the built 'wallycore' package as a wheel into that environment, and runs the tests from there. This is purely a testing/CI infrastructure change and does not alter any cryptographic or security-sensitive code.

This commit is a routine version bump from 1.5.0 to 1.5.1. It only changes version numbers in build files, documentation, and package metadata. There are no code changes that affect security or functionality.

This commit adds a standard Python packaging configuration file (pyproject.toml) that tells newer versions of pip how to build the project from source. It is a routine build-system change with no apparent security relevance.

This commit is just a changelog update for a new software release. It edits a text file describing what changed in version 1.5.1, including routine fixes like supporting newer Python versions and correcting a Java function's caching behavior. There is no code change here, and nothing in the commit itself indicates a security problem.

This is a routine build-system update. It upgrades the tool used to compile Python wheel packages and adjusts which Python versions and platforms are built. There is no change to the library's actual code, cryptography, or security behavior.