libwally-core

This is a tiny build-maintenance change: it replaces the deprecated Python `distutils.sysconfig` module with the newer `sysconfig` module in the package setup script. There is no security vulnerability visible in the diff, no change to cryptographic code, and no disclosed incident. It is a routine compatibility cleanup.

This is an automated Dependabot update that bumps the JavaScript development dependency fast-uri from version 3.1.0 to 3.1.2 inside the WebAssembly (WASM) packaging directory. The change only updates a package-lock.json file. There is no direct evidence in the commit that this fixes a security issue, but version bumps of URI-parsing libraries can sometimes address security bugs. Because it is a devDependency used during build/packaging, any risk is likely limited to the build environment rather than end users of the compiled library.

This commit only adds new test cases for Elements/Liquid confidential wallet policies. It does not change any library code, only test files. There is no security fix or vulnerability introduced here.

This commit only changes test code. It makes the key maps used in descriptor tests explicit by adding an index field to each test case, instead of the test runner guessing which map to use based on counting '@' characters. The commit message says 'No functional changes' and the diff supports that: no library code is modified.

This commit adds support in libwally-core for a new Elements/Liquid confidential-wallet policy format. It lets wallet policies include a special '@B' blinding key placeholder, kept separate from ordinary derivation keys. The change is a feature addition with embedded validation rules; it does not appear to fix a known vulnerability, but it does touch sensitive descriptor-parsing code that handles cryptographic keys. There is no vendor statement that this is a security fix, and no independent researcher is credited.

This is a tiny one-line fix that changes the error code returned when memory allocation fails inside a Bitcoin descriptor policy-map validation function. Previously the code incorrectly reported a generic invalid-parameter error (WALLY_EINVAL) instead of an out-of-memory error (WALLY_ENOMEM). It does not fix a memory leak, crash, or code-execution bug; it only makes the reported error more accurate so callers can distinguish OOM from bad input.

This commit tightens the rules for numbers used in Bitcoin-style output descriptors, specifically for policy key placeholders like @0, @1, etc. It now rejects numbers with leading zeros (for example @00 or @01) and negative numbers with leading zeros. Such lax parsing can, in some contexts, allow two different-looking strings to refer to the same numeric key or trick downstream code that compares keys as text. The change is defensive and reduces the chance of descriptor ambiguity or canonicalization bugs.

This commit only changes the shared library version numbers in the build file (Makefile.am) in preparation for a new release. It does not change any actual program code, cryptographic functions, or user-facing behavior. The commit message mentions that earlier AES-related changes were technically an ABI change, but this commit itself is purely a build/versioning adjustment.

This commit only updates a JavaScript test file for AES encryption in the WebAssembly package. It changes how empty plaintext or ciphertext test vectors are handled (treating zero-length buffers as null) and adds a debug console.log statement. There is no change to the actual cryptographic library code, only to test expectations.

This commit updates the JavaScript/WebAssembly wrapper for libwally-core so that functions expecting a raw byte input (like a cryptographic key or transaction data) can now accept `null` in addition to a buffer. Previously, passing `null` would likely throw a type error. The change is small and appears intended to support C functions that treat a NULL pointer plus zero length as a valid 'no data' input. There is no direct evidence in the commit that this fixes a security vulnerability, but it could prevent application crashes or incorrect behavior when callers intentionally pass no data.

This commit only updates the TypeScript type-declaration file for the JavaScript/WebAssembly wrapper. It widens many function parameters from 'Buffer|Uint8Array' to 'Buffer|Uint8Array|null', meaning callers are now allowed to pass null. The change is purely in type definitions; the actual C/WASM implementation is not modified here. It makes the API more permissive on paper, which could hide programming mistakes, but it does not by itself create a runtime vulnerability.

This commit is a routine version bump from 1.5.2 to 1.5.3 across build files, documentation, and package metadata. No code logic, cryptographic functions, or security behavior changed.

This commit is only a changelog update for libwally-core version 1.5.3. It does not change any source code, cryptographic logic, or build configuration. The diff adds release notes describing new features and bug fixes that were made in earlier commits. Because no code is modified, this commit itself cannot introduce or fix a security vulnerability.

This commit tightens input validation in libwally-core's AES encryption helpers. It makes sure callers pass a valid output buffer and length, and it centralizes the checks so all AES functions behave consistently. The change also adds tests for bad inputs such as missing keys, missing IVs, and NULL output buffers. It appears to fix a bug where a caller could pass an invalid output buffer and not get a clear error.

This commit fixes a bug in a key-value map used by the libwally-core crypto library. When a caller removed a byte-keyed entry and then reinserted a new integer-keyed entry into the same slot, the code could mistakenly free or overwrite memory that was no longer valid. The fix ensures integer keys are explicitly set to 'no bytes' and null values are handled cleanly, preventing memory corruption.

This commit fixes a small but real bug in a Bitcoin/Elements transaction library. When creating a new transaction input fails, the code was trying to securely wipe memory using the wrong size: it used the size of a transaction output instead of the size of a transaction input. On most systems this means the clearing is ineffective or incomplete, so secret data (like scripts or witness data) could remain in memory longer than intended. It is a memory-clearing bug, not a direct remote exploit, but it weakens a security safeguard.

This commit fixes a small cleanup bug in the confidential address encoding function. Previously, if the final blech32 encoding step failed, the function returned an error immediately without jumping to the shared cleanup code. That meant temporary buffers holding sensitive data (like the public key and hash) might not be securely wiped from memory. The change makes sure cleanup always runs, even on failure, so secrets are cleared properly.

This commit fixes a simple but real bug in a transaction helper function. Before the fix, if a caller accidentally passed a null pointer as the output parameter, the library would crash by writing to address zero. The fix adds a standard null check and returns an error instead. It is a defensive hardening change rather than an active remote exploit, but it removes a reliable local crash path.

This commit fixes a bug in how Bitcoin taproot-style transaction signatures (BIP341) are computed. Under a special signature mode called SIGHASH_SINGLE, the code previously did not check whether the requested transaction output actually exists. BIP341 says such signatures must be rejected. Without this check, a wallet or signer could produce an invalid or ambiguous signature that other software might accept differently, potentially leading to unexpected transaction behavior or security issues in multi-party signing.

This commit only updates the project's security documentation. It removes a long embedded PGP public key block and replaces it with a link to the same key hosted on GitHub. There are no code changes and no security vulnerability is introduced or fixed.

This is an automated dependency update that removes an old JavaScript helper package called serialize-javascript and upgrades a build tool called terser-webpack-plugin. The change only affects the build-time tooling for the WebAssembly package, not the core cryptographic library. It is a routine maintenance patch with no direct evidence of an active security flaw being fixed in the project's own code.

This commit adds a safety check when loading BIP32 extended keys. Before, the code accepted any 33-byte public key bytes without verifying they form a valid public key. Now it calls a public-key validation function and rejects invalid keys. The change is defensive: it prevents malformed or attacker-chosen public keys from being treated as legitimate BIP32 keys later. The commit also adds test vectors for many other invalid key types, though only the public-key validation is newly enforced in this patch.

This change fixes a performance problem when reading Bitcoin-style transactions that contain an unusually large number of 'witness' data pieces. Previously the code started with a small buffer and repeatedly grew it, which made processing time balloon (a 'quadratic' slowdown). The patch pre-allocates the exact needed size during deserialization, so large-but-valid transactions no longer cause severe delays. It is a denial-of-service/performance fix rather than a memory-corruption bug.

This commit only adds new software testing tools (fuzzing harnesses) for parsing Bitcoin-style transactions and PSBTs. It does not change the actual transaction/PSBT parsing library code, so it cannot by itself introduce a security vulnerability or fix one. It is a test-infrastructure change.

This commit changes the build configuration so that when the Undefined Behavior Sanitizer (UBSan) is enabled, the project pretends the CPU cannot do unaligned memory reads/writes. This is done to silence UBSan warnings that are technically false alarms on x86 CPUs. It is a build/test-hygiene change, not a fix for an exploitable bug.