Core Lightning

This commit fixes a bookkeeping bug in Core Lightning's payment handling. When a developer/admin command called `injectpaymentonion` failed to actually send the payment (for example, because the peer's channel daemon wasn't reachable), the software had already marked the payment as 'pending' in its records. The fix moves the registration step to after the actual HTLC (payment packet) is successfully created, so failed attempts no longer show up as stuck pending payments in `listsendpays` or `listpays`.

This commit fixes a bug in Core Lightning's bitcoin-cli plugin (bcli) where very large transactions could make the plugin crash with an 'Argument list too long' error. The fix passes large arguments through standard input instead of the command line, which avoids operating system limits on command-line length. It is a reliability fix rather than a security vulnerability that can be exploited by an attacker.

This commit adds a test that checks whether Core Lightning's bitcoin backend plugin (bcli) crashes when handling very large transactions. The test is marked as expected to fail for now, meaning the underlying crash bug is known but not yet fixed. It does not itself change production code.

This change removes a repeated internal sanity check that was making very large Bitcoin transaction templates (PSBTs with hundreds of inputs) extremely slow to process. It is a performance fix, not a security fix. The remaining single check at the end still catches the same class of problems, just less frequently.

This commit fixes a crash in Core Lightning's bookkeeper plugin. Under parallel queries, a bookkeeping record could arrive out of order, triggering an internal 'assertion' that immediately killed the plugin. The fix replaces the fatal assertion with a safe early return when an out-of-order race occurs, and removes the 'expected failure' marker from the related test so it now passes.

This commit only adds a new test case for the bookkeeper plugin. The test runs two list-income queries at the same time and is currently marked as expected to fail (xfail), meaning the underlying crash or assertion failure it checks for has not been fixed yet. The commit itself does not change any production code, so it cannot directly fix a vulnerability.

This commit adds a new test case that demonstrates an apparent bug in Core Lightning's routing plugin (cln-askrene). When asked to find payment routes with a limit of two parts (maxparts=2), the plugin can enter an infinite loop instead of cleanly failing. The test is marked as expected to fail for now, meaning the underlying bug is not fixed by this commit—it is only being documented/reproduced.

This commit fixes a bug in Core Lightning's `askrene` routing plugin where the program could get stuck in an infinite loop while trying to find payment routes. The loop happened when the route-finder kept finding a path, the path was then reduced because one channel couldn't handle the amount, and the reduced path was discarded because it was the only one found and the user had limited how many route pieces (maxparts) could be used. The fix marks the problematic channel as disabled so the algorithm makes forward progress instead of repeating the same dead-end path forever. It is a denial-of-service/availability issue rather than a loss-of-funds or code-execution vulnerability.

This commit adds a 10-second safety cutoff to the routing plugin (askrene) that calculates payment paths in the Core Lightning node. Previously, the routing algorithm could keep looping or running for a long time while trying to find a way to send a payment. The change makes it stop and report failure if it exceeds the configured time limit, with a default of 10 seconds. It also exposes a new node option, askrene-timeout, so operators can adjust or disable it. This is a defensive hardening change rather than a fix for a specific remote exploit.

This commit only adds a new test case to the project's test suite. It does not change any production code. The test is currently marked as expected to fail (xfail), meaning it documents a known bug where the bookkeeper plugin does not preserve certain block-height records after a node restart. By itself, this commit does not fix or introduce any security issue.

This commit fixes a bookkeeping bug in Core Lightning's bookkeeper plugin. On restart, the plugin was reading the wrong part of a stored data key when trying to restore transaction block heights, causing it to log a 'BROKEN' error and set block heights to 0. The fix is a one-line change correcting an array index offset. It is a data-integrity/functional bug, not an exploitable security vulnerability.

This commit removes two leftover git submodule references (libsodium and lowdown) from the repository index. The submodules had already been removed from the project's configuration file, but their entries were still stuck in git's internal records, causing 'recursive clone' operations to fail with an error. The change only fixes a source-code checkout/build problem and does not alter any running code, cryptography, or network behavior.

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 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 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 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 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 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 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 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.