Core Lightning

This commit updates Docker build files to add two missing software dependencies (libsodium development files and the lowdown document converter) that were accidentally left out after an earlier cleanup. It is a build-system maintenance fix with no apparent security relevance.

This commit changes the build system so that fuzz tests are skipped when OpenSSL is older than version 3.0. It is a test/build compatibility tweak, not a fix for a vulnerability in the running software. There is no indication it addresses an active security flaw.

This commit only adds a pytest command-line option that prints how long each slow test took. It does not change any application code, security settings, or test behavior. There is no security relevance.

This commit switches a software dependency (the 'utoipa' Rust library, used by Core Lightning's REST plugin) from the official published version to a personal GitHub branch maintained by the project's own Rusty Russell. The reason given is to include another contributor's fix that makes release builds deterministic again—meaning builds from the same source code produce identical output. There is no direct evidence in the commit of a security vulnerability; the concern is that relying on an unofficial, personal fork instead of a released crate introduces supply-chain and maintenance risks.

This commit removes the bundled copy of the libsodium encryption library that Core Lightning previously shipped. Instead of building its own copy, the project now requires the operating system to provide libsodium version 1.0.4 or newer. This is a routine build-system cleanup, not a security fix or vulnerability.

This commit removes the bundled copy of the lowdown documentation tool from the Core Lightning repository. It is a build-system and dependency change, not a code change that affects how the Lightning node runs or handles funds. Lowdown is now treated as a required external package instead of being built from a bundled submodule.

This commit removes support for Litecoin from the Core Lightning software. It deletes Litecoin-specific configuration data, Docker build steps, command-line help text, and a network option from developer tools. There is no security fix or vulnerability being patched; it is a cleanup change because the feature was untested and likely unused.

This is a tiny code cleanup change in a helper function that reads a line of text. It replaces a manual check for a trailing newline with a utility function called strends(), and adjusts how the string length is tracked. There is no security-relevant change: the behavior is equivalent and no bug is being fixed.

This commit is a small cleanup patch in Core Lightning's HSM (hardware security module) secret handling code. It removes an unused error code, makes some pointer types const, fixes an assertion comment, and reorders a developer-only debug command. There is no indication of a security vulnerability being fixed.

This commit adds a new helper function, tal_wally_discard(), to safely clean up temporary memory used by the libwally library. Previously, code used a different cleanup function that assumed libwally had not made any long-lived allocations. The new function explicitly checks that assumption and will crash the program if it is wrong, turning a potential silent memory bug into an obvious failure. It is a defensive hardening change, not a fix for an actively exploitable vulnerability.

This commit refactors how Core Lightning stores the wallet's master secret so the code can cleanly handle both old 32-byte seeds and new 64-byte mnemonic-based seeds. It removes a legacy fixed-size 'secret' field from the in-memory structure and makes callers use a length-aware 'secret_data' pointer instead. The change itself is a structural cleanup, not an obvious security bug, but it touches sensitive key-handling code and changes how memory is locked against swapping to disk. There is no vendor statement that this fixes a vulnerability.

This is a routine code cleanup commit. It removes a small helper function called grab_file_contents and replaces its uses with a newer, equivalent helper called grab_file_raw. The behavior is intended to be the same: reading a file's bytes without including a trailing NUL terminator. There is no indication of a security bug being fixed.

This commit is a code cleanup that replaces several scattered copies of a memory-locking pattern with one shared helper function. It does not add new security features, but it reduces the chance that future code forgets to unlock sensitive memory when it is freed. The change also makes memory locking mandatory (the program aborts if locking fails) in more places, which is a small hardening improvement.

This commit is a routine cleanup of API documentation and test code. It removes an experimental 'bip86' address type option from the newaddr command and updates tests to use taproot (p2tr) addresses instead of older bech32 addresses. There is no security vulnerability here.

This commit changes how Core Lightning's main daemon (lightningd) sends an HSM passphrase to the separate HSM daemon (hsmd). Previously, lightningd derived an encryption key from the passphrase locally and sent that derived key to hsmd. Now it sends the raw passphrase inside a new optional protocol field (a TLV extension), and lets hsmd derive the key itself. The change is framed as preparation for BIP-39 mnemonic support. It is a protocol and internal API change, not a clear-cut security fix, but it does alter where the passphrase is handled and how it travels between processes.

This commit adds support for deriving Bitcoin BIP86-style keys inside Core Lightning's Hardware Security Module (HSM) daemon. It introduces two new wire messages that let authorized clients ask the HSM to derive a BIP86 base key and to check whether a public key matches the HSM's own derivation. The commit also adds a new permission bit controlling access to these messages. There is no direct evidence in the commit that this fixes an active vulnerability; it reads as feature work to support a new wallet/key derivation path, with a sanity-check helper to catch accidental derivation mismatches.

This commit refactors how Core Lightning generates wallet addresses. Instead of keeping two separate address types (legacy BIP32 and mnemonic-based BIP86), it now picks the derivation method based on the wallet's HSM secret type. The change removes the special 'bip86' address type from RPCs and unifies address generation. It also fixes a memory leak by freeing a temporary TLV structure. There is no direct evidence in the commit of a security vulnerability being patched, but the change touches key-derivation logic and could affect fund recoverability if implemented incorrectly.

This commit adds a small metadata field to the internal HSM (Hardware Security Module) initialization message so that lightningd can tell whether the wallet seed was created from a mnemonic phrase or from an older legacy secret. It is a protocol plumbing change, not a fix for a known vulnerability, and does not by itself change how secrets are generated, stored, or protected.

This commit adds experimental support for deriving Bitcoin public keys using the BIP86 standard inside Core Lightning. It stores a new base key locally in the main daemon and adds a command-line option to turn the feature on. The change also removes a dedicated HSM permission flag for BIP86 derivation, folding it into existing capability checks. There is no clear security bug in the diff, but the commit message says much of the code may not survive review, so it looks like unfinished work-in-progress.

This commit fixes a wallet-recovery bug in Core Lightning. When a user restored a wallet that used BIP86 (a modern Bitcoin address type), the node failed to scan the blockchain for those addresses, so previously received funds would appear missing until the user manually generated an address. The patch makes the rescan process look for both BIP32 and BIP86 addresses.

This commit only updates the user manual documentation for the Core Lightning node software. It renames the documented configuration option from 'encrypted-hsm' to 'hsm-passphrase' and explains how passphrases now work with both old-style encrypted secrets and new BIP39 mnemonic-based seeds. No program code was changed, so this cannot introduce or fix a security vulnerability by itself.

This commit adds a new feature to the Core Lightning 'exposesecret' plugin. It allows users who have set up their node with a BIP39 mnemonic (a human-readable seed phrase) to retrieve that mnemonic through the plugin's API. The change also includes some internal cleanup for how mnemonic secrets are handled and converted into cryptographic seeds. There is no indication in the commit that this fixes a security vulnerability; it is a feature addition.

This commit is a code refactor in Core Lightning's wallet secret handling. It changes how the HSM (Hardware Security Module-like) secret is stored internally so it can hold either the traditional 32-byte secret or a full 64-byte seed derived from a BIP39 mnemonic. It keeps the old 32-byte field for backward compatibility and adds helper functions to read the secret. There is no security fix or vulnerability being patched here.

This is a preparatory code change for Core Lightning's HSM (the component that holds private keys). It changes an internal function so it can accept either a 32-byte or 64-byte root secret, keeping the existing 32-byte behavior intact. The commit itself does not change how keys are actually derived or fix any known vulnerability; it is plumbing for a future feature (BIP86 wallet addresses).

This commit fixes a bug in Core Lightning's HSM (Hardware Security Module daemon) where the wrong private key could be derived when spending a taproot (P2TR) UTXO. Previously, the code always used the older BIP32-style derivation for taproot UTXOs. After the change, it checks whether the UTXO was actually created using the newer BIP86 derivation path (used with mnemonic-based wallets) and, if so, derives the correct key. If the wrong key is used, the node would be unable to sign a transaction spending that UTXO, effectively locking the funds until the bug is fixed. There is no direct evidence in the commit or supplied references that this was a security vulnerability exploitable by an attacker; it appears to be a correctness/functional bug.