libwally-core

This commit changes a library function so that it now returns an error when a PSBT/PSET input amount is missing, instead of silently returning zero. It also adds a new 'has_input_amount' check so callers can ask whether the value exists before reading it. The change is an intentional fix to prevent callers from accidentally treating a missing amount as zero. It also cleans up some old, non-existent function names in the Java wrapper.

This commit changes a library function so that it returns an error when asked for an output amount that is not actually present, instead of silently returning zero. This prevents callers from accidentally treating a missing amount as a real zero-value output, which could lead to incorrect transaction handling in Bitcoin/Elements PSBT workflows.

This commit tightens how the library reads PSBT (Partially Signed Bitcoin Transaction) data. It adds a new parsing flag that requires the parser to consume the entire input, and turns that flag on automatically when reading base64-encoded PSBTs. Previously, extra bytes tacked onto the end of a PSBT could be silently ignored. The change is defensive: it helps prevent malformed or intentionally padded PSBTs from being accepted as valid.

This commit fixes a missing safety check in libwally-core's AES encryption/decryption function. Previously, callers could pass an output buffer smaller than the input data, which could lead to writing past the end of the buffer (a buffer overflow). The patch now rejects such calls and adds tests for many invalid input combinations. The issue was reported by an outside security researcher.

This commit fixes a Java language binding bug where a function that reads a Bitcoin transaction output amount was incorrectly declared to return a 'size' type (a memory/length value) instead of an unsigned 64-bit integer. Output amounts in Bitcoin are 64-bit integers, so the wrong return type could cause the returned value to be truncated, misinterpreted, or trigger type-conversion errors in Java applications using libwally-core. The fix is a one-line change in the SWIG interface file used to generate Java wrappers.

This commit adds a new public-key compression function to a cryptographic library and updates the existing decompression function so both can accept already-compressed or already-uncompressed keys as input. It also adds tests and language bindings. There is no security vulnerability here; it is a normal feature addition with defensive input validation.

This commit tightens signature validation in a cryptographic library. It now rejects malformed DER-encoded signatures that are longer than allowed, or where one of the signature numbers (R or S) is zero. Previously, the underlying secp256k1 library would accept these invalid forms silently, which could lead to later failures or unexpected behavior when the signatures are used in Bitcoin/Elements transactions.

This commit adds a new public API to libwally-core that lets users derive BIP32 keys directly from a parsed Bitcoin/Elements descriptor. It also fixes two consistency bugs in how descriptor keys are looked up: it now correctly routes requests for the special 'blinding key' index, and it correctly marks SLIP77 blinding key nodes so callers can tell what kind of key they are getting. There is no direct evidence in the commit that these changes fix an exploitable vulnerability; they appear to be correctness and API-completeness improvements.

This commit fixes a potential information leak in a cryptocurrency wallet library. When the library is built as a shared library on x86/x86_64 systems, optimized memory-copy functions can leave secret data (private keys, seed phrases, chain codes) inside special CPU registers (SSE/AVX). If the program then makes a call through the dynamic linker before those registers are reused, the CPU spills the register contents onto the stack, where they may remain uncleared. The patch replaces many ordinary memory copies with a simple, unoptimized byte-by-byte copy function for sensitive data, preventing the data from being left in those registers. The commit message explicitly calls this an 'info leak' and thanks an external contributor for finding the cause and suggesting the fix.

This commit is described as updating a bundled cryptographic library (secp256k1) to a newer version, but the actual code changes are not available for review. Without the diff, we cannot determine whether the update fixes security bugs, introduces new ones, or is purely routine maintenance.

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 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 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 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 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 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 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 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 is a small Java language-binding change that lets callers pass Java null for one specific type of object (a non-const wally_map) instead of requiring a real object. It is used to skip an internal caching map when computing a Bitcoin/Elements transaction signature hash. The change is a convenience/API improvement, not a fix for a memory corruption or cryptographic bug.

This commit only adds a new Java test file that checks a transaction signature hash function works correctly for Elements/Liquid taproot transactions. It does not change any library code, fix any bug, or alter behavior. There is no security issue here.