Core Lightning

This commit only adds new test input files (seed corpus) for an existing fuzz test that exercises BOLT11 invoice parsing. It does not change any production code, configuration, or behavior of the Core Lightning node. The added files are malformed or unusual invoice strings intended to improve test coverage. There is no indication this commit fixes or introduces a security issue.

This commit only adds test data files (a fuzzing seed corpus) for a new fuzz test. It does not change any production code, configuration, or runtime behavior, so it has no direct security impact on users of Core Lightning.

This commit only adds and removes test input files used by an automated fuzz-testing harness for a bigsize parser. It is purely a test-data update and does not change any production code, configuration, or behavior of the Core Lightning node software.

This commit only adds new test input files to a fuzz-testing seed corpus. It does not change any production code, configuration, or documentation. There is no indication of a security fix or vulnerability being addressed.

This commit only adds test data files (a seed corpus) for a fuzzing test. Fuzzing is an automated testing technique that feeds random or crafted inputs to a program to find bugs. These files are not part of the production Core Lightning software that users run, so they cannot directly cause a security issue in a live node. There is no indication in the commit that any vulnerability was found or fixed.

This commit only adds test data files (a fuzzing seed corpus) for a new fuzz test named fuzz-wire-closing_complete. It does not change any production code, configuration, or runtime behavior. There is no indication of a security fix or vulnerability being addressed.

This commit fixes file descriptor leaks in the project's test suite. It replaces patterns like open(...).read() with context managers or helper methods that automatically close files. These changes only affect test code and test infrastructure, not the actual Core Lightning node software that users run. The leak could cause tests to run out of file handles during long test runs, but it is not a security vulnerability in production software.

This commit fixes Docker build problems after the project switched its Python tooling from Poetry to uv. The main change replaces a Rust dependency that was pinned to a specific orphaned Git commit with a published crate version, because GitHub no longer advertises unreachable commits. It also cleans up Dockerfile commands and environment variables so builds work again. There is no direct evidence this fixes an exploitable security vulnerability; it appears to be a build/maintenance fix.

This commit fixes a database migration crash in Core Lightning. When upgrading, the migration code could hit a NULL currency field and abort with a 'BROKEN' error. The patch lets the migration tolerate NULL currencies and also skips any records that use an unexpected foreign currency, logging a warning instead of crashing. It is a robustness fix for an unusual upgrade path, not a typical remote attack vector.

This commit fixes a crash during database migration. Previously, if the migration code encountered an unknown 'tag' value in the old account database, it would call abort() and terminate the program abruptly with no explanation. Now it calls db_fatal(), which prints a clear error message about the unknown tag before stopping. This is a robustness improvement that helps diagnose migration failures but does not by itself prevent them or create a security vulnerability.

This commit fixes a database migration bug where Core Lightning could crash with a 'BROKEN' error when reading old bookkeeping records that had a missing 'ignored' value. The fix treats a missing value as 'false' instead of causing a fatal null-column access. It is a stability fix for an internal migration path, not an externally exploitable security vulnerability.

This commit only updates the project's CHANGELOG.md file to rename the release candidate version from 25.09rc2 to 25.09rc3 and add two new changelog entries describing other changes. The commit itself does not modify any source code, cryptographic logic, network protocol handling, or configuration defaults. There is no direct security-relevant change in this diff.

This commit fixes a crash bug in Core Lightning (CLN) that occurs when a peer adds more than one HTLC (a payment channel transaction) in a single commitment round. The root cause was a memory-management mistake: the generated wire-deserialization code treated an array of 'added_htlc' records as if each element were an independently allocated memory object, but only the array's head was. When the second element was processed, the code tried to allocate child objects against a non-TAL pointer, triggering an assertion/crash. The fix changes 'added_htlc' to a varsize pointer type so each record is allocated separately. The commit message and a test name indicate this could be hit in normal operation and caused a FATAL SIGNAL 6 (abort).

This commit fixes the automatically generated TLS certificates used by three Core Lightning plugins (grpc-plugin, rest-plugin, and wss-proxy-plugin). Recent versions of the urllib3 library started rejecting these certificates because they were missing two standard fields: the Authority Key Identifier and Key Usage extensions. Without these fields, Python-based clients connecting to the plugins could fail TLS verification and refuse to connect. The patch adds the missing certificate extensions so verification succeeds again.

This is a tiny one-line fix that stops Core Lightning from crashing on startup for users who already ran a newer development version. It is not a security vulnerability and cannot be exploited by an attacker. The change simply recognizes database version 18 as valid so the normal upgrade process can continue.

This commit only updates the project's CHANGELOG.md file to add release notes for version 25.09rc1. It contains no code changes, configuration changes, or executable modifications. The diff is purely documentation summarizing features, changes, deprecations, removals, fixes, and experimental items for an upcoming release candidate.

This change updates Core Lightning's internal accounting records when a payment channel closes. Previously, records in the `chain_moves` and `channel_moves` database tables kept pointing to the closed channel's internal database ID. After this patch, they are rewritten to reference a stable text identifier (the channel ID) instead. The commit message says this avoids dangling references to closed channels and makes future cleanup easier. There is no direct evidence in the commit of an exploitable security vulnerability; it looks like a data-integrity and maintainability fix.

This change makes Core Lightning save every on-chain and channel coin movement to its internal database before sending out a notification. Previously, some coin movements were only notified and not persisted. It is an accounting/audit-logging improvement rather than a fix for an exploitable security flaw.

This commit hardens how Core Lightning records coin-movement tags in its database. It locks the numeric values of an internal enum so future code changes cannot silently reorder them, adds a translation helper to ensure the stored database values stay stable, and validates tag sets before writing them. There is no direct exploit here; it is a defensive fix to prevent data corruption or accounting mismatches if the enum were ever changed.

This commit adds read-only helper functions to pull coin-movement records out of the wallet database. It does not change how funds are handled, does not fix any bug, and does not introduce any obvious security issue. It is a straightforward data-access addition.

This commit is a performance optimization, not a security fix. It replaces a slow loop that searched through every peer and channel to find a channel by its database ID with a fast hash table lookup. The change makes the listcoinmoves command respond faster on large nodes but does not address any vulnerability.

This commit adds a new 'create' flag to Core Lightning's database-opening code. When create is false, the code tries to open an existing database but refuses to create a new one if it is missing, returning an error instead of crashing. This is a defensive change that makes the wallet startup behavior safer in some situations, but it does not by itself fix a known exploitable bug.

This commit adds three new database tables to Core Lightning's wallet module: one for account names and two for recording on-chain and off-chain fund movements. It is a straightforward schema migration with no logic changes, no bug fixes, and no security-sensitive operations visible in the diff.

This commit adds new bookkeeping routines that record money movements into two database tables, one for on-chain transactions and one for channel (off-chain) transactions. It also adds a database index to speed up duplicate-checking for on-chain records. There is no indication this fixes a security bug; it appears to be a normal feature addition for accounting/audit logging.

This commit moves the bookkeeper accounting data from a separate plugin database into the main lightningd database at startup. It adds a one-time migration that reads the old accounts.sqlite3 file and copies its records into new internal tables. The change is mostly a refactor of where data lives, but it touches startup code, database migrations, and option handling. There is no direct evidence in the commit that this fixes an active security vulnerability; it appears to be architectural cleanup.