Core Lightning

This commit is a straightforward code cleanup: it introduces two new helper functions, amount_msat_deduct and amount_msat_deduct_sat, which are shorthand for 'subtract this amount from itself' (like a -= b). It then replaces many existing calls of the longer form amount_msat_sub(&x, x, y) with the shorter amount_msat_deduct(&x, y). There is no change in behavior, no bug fix, and no security relevance in the diff itself.

This commit fixes a rare programming bug in Core Lightning's 'askrene' routing plugin. If a specific internal function failed due to an overflow, the code would free a memory context and then try to use it again on the error-handling path, which is a use-after-free. The patch changes the function to use a longer-lived memory context so the error path is safe. The failure condition is described as only possible on overflow, making real-world exploitation unlikely.

This commit fixes a use-after-free bug: when the bitcoin plugin (bcli) was freed during shutdown, the gossip subsystem could still try to send it a request, reading from freed memory. The patch simply stops new plugin requests once the daemon is shutting down. It is a stability/crash bug rather than an obvious remote exploit, and the commit does not describe it as a security vulnerability.

This commit fixes a small memory leak inside a fuzz test, which is an automated testing helper program, not part of the live Lightning node software. It does not affect real users, wallets, or network operations.

This commit only adds a new fuzz test for an existing function and makes a small constant-definition cleanup. It does not change any production code, fix a bug, or alter behavior of the Core Lightning node. There is no security issue here.

This commit only adds new test input files to a fuzz-testing seed corpus. It does not change any production code, configuration, or runtime behavior. The added files are used only during automated fuzz testing to exercise more code paths. There is no direct security impact on users running Core Lightning.

This commit changes the release build script so that Fedora tarballs use a fixed timestamp when files are packed. This makes the resulting archive byte-for-byte identical every time it is built, which is a reproducible-build improvement. There is no security vulnerability here.

This commit only updates Git ignore lists to exclude automatically generated build artifacts from version control. It does not change any executable code, configuration defaults, or security behavior.

This commit only adds test data files (a fuzzing seed corpus) for a new fuzz test called fuzz-wireaddr. It does not change any production code, so it cannot introduce a runtime security vulnerability on its own. The corpus contains many malformed and unusual network address strings used to exercise the parser during automated testing.

This commit fixes a formatting bug in Core Lightning where DNS-type network addresses were printed as plain text strings without using their known length. The old code passed a pointer to DNS address bytes directly to a string formatter, which could read past the intended data if the bytes were not null-terminated, potentially leaking nearby memory or crashing the program. The fix prints only the exact number of bytes that make up the DNS address.

This commit adds a new automated fuzz test file for network address parsing and serialization functions. It does not change any production code, fix a bug, or alter behavior. It is purely a test addition intended to improve code coverage and catch future bugs.

This commit only changes the fuzz testing helper code used by developers. It lets developers pass a -v flag and pick specific test corpus files when running fuzz targets as ordinary unit tests. There is no change to production wallet, networking, or consensus code, and nothing here affects real users or live funds.

This commit only adds a set of test input files (a seed corpus) for a fuzz-testing harness named fuzz-init_received. Fuzz testing feeds random or semi-random data to a program to find crashes or bugs, but the commit itself does not change any production code, fix any vulnerability, or introduce any new functionality. It is purely a testing-data addition.

This commit only adds a new fuzz test file. It does not change any production code, fix a bug, or patch a vulnerability. Fuzz tests feed random or crafted inputs to a function to help find future bugs, but adding the test itself is a defensive quality-assurance change, not a security fix.

This commit is a routine housekeeping change for a Rust-based software project. It moves version numbers for internal components into one central configuration file (the workspace root) and updates each component to reference that shared definition. There is no change to program logic, no bug fix, and no security patch visible in the diff.

This commit adds a new GitHub Actions workflow that automates the creation of pull requests to bump the version numbers of Rust crates in the Core Lightning project. It is a routine development and release automation change with no direct security relevance.

This commit adds a testing-only feature called 'canned blocks' to the Core Lightning Python test framework. It lets developers replay pre-recorded Bitcoin blocks during tests instead of generating new ones, and fixes an off-by-one bug when saving blocks. There is no change to production code or to how real users' funds or nodes are secured.

This commit swaps wall-clock timestamps for monotonic timestamps when measuring durations and timeouts in several parts of Core Lightning. Monotonic time only moves forward at a steady rate and is not affected by system clock changes or developer time overrides. The change makes timeout logic more reliable and prevents accidental misbehavior during testing, but it is a hardening/refactoring patch rather than a fix for an active, exploitable vulnerability.

This change makes a Lightning node return a single, predictable incoming channel when running in deterministic mode (used for reproducible testing and invoice route hints). Previously, multiple candidate channels could be returned in a non-deterministic order, which could cause the same invoice to produce different route hints across runs. The patch selects the highest-capacity channel as the one and only candidate. This is primarily a reliability/consistency fix; it does not appear to be a direct security vulnerability, but non-deterministic route hints could theoretically leak extra topology information or cause payment routing inconsistencies.

This commit adds a hidden developer-only command-line flag called --dev-ignore-ibd to Core Lightning's Bitcoin backend plugin. When enabled, it tells the plugin to lie to the main lightning daemon and claim that Bitcoin is not in 'initial block download' mode, even if it actually is. This is intended only for developer testing scenarios (for example, when using canned/fake blocks) and is not exposed as a normal user option. There is no indication in the commit that this is a security fix or that it addresses a reported vulnerability.

This commit changes how Core Lightning generates 'pseudo-random' numbers when running in deterministic mode (used mainly for reproducible testing). It gives each separate piece of code that asks for a random number its own private counter, so the order in which different callers happen to ask no longer changes the random values they receive. The change is aimed at making tests more stable and easier to reproduce, not at fixing a security vulnerability in live operation.

This commit swaps most uses of the real-time clock function `time_now()` for a new internal helper called `clock_time()`. The change is infrastructure, not a fix for a known attack. It makes the node’s view of time easier to override for testing and reproducibility, and it reduces the risk that a backward clock jump confuses timers, logs, or payment expiry checks. Tracing is deliberately left on real time. There is no direct security bug being patched here, but the change touches many time-sensitive parts of a payment system, so it has broad defensive value.

This commit fixes a developer-only edge case. When running Core Lightning with a special developer mode flag (CLN_DEV_ENTROPY_SEED) that forces the same randomness seed for testing, multiple channel-opening sub-processes could accidentally pick the same internal IDs. That could cause a PSBT (transaction-building data structure) collision when combining contributions. The fix tweaks the seed slightly for each new sub-process so IDs differ, then restores the original seed afterward. It is not a normal user security bug and does not expose funds or keys.

This change is a straightforward internal cleanup: it replaces direct calls to the cryptographic library's random-byte function (randombytes_buf from libsodium) with a project-specific wrapper called randbytes(). The wrapper currently does the same thing, but having it in one place makes it easier to swap in a deterministic (predictable) random source for testing in the future. There is no direct security bug introduced by this commit itself, and no evidence it weakens real-world randomness.

This change only affects Core Lightning when a special developer-only environment variable (CLN_DEV_ENTROPY_SEED) is set. It makes the order in which the wallet picks coins deterministic instead of random, which helps developers reproduce tests. In normal operation the wallet still picks coins randomly, so this commit does not introduce a security vulnerability for regular users.