Modular C implementation of the Lightning Network protocol and node stack.
Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Aug 5 → Feb 61049 seen37 candidatesCompleteFeb 6 → Jun 6579 seen10 candidatesCompleteJun 6 → Jul 678 seen1 candidatesCompleteJul 6 → Aug 5147 seen16 candidatesCompleteMessage quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
Public Git author strings; identities are not independently verified.
Last scanned 49 minutes ago
This commit simply adds a new person's PGP public-key fingerprint to the list of trusted release signers in two documentation files. It does not change any code, fix any bug, or alter any security behavior of the software itself.
41278b4eby jaonoctus+2−02 filesThis is a tiny internal fix to make a bookkeeping migration produce stable event ordering. It changes the timestamp used when creating historical 'deposit' records during a one-time database migration, so the records sort consistently with…
498e5086by daywalker90+2−01 fileThis commit is a documentation-only cleanup of the JSON-RPC command help files. It corrects which numeric error codes are listed for each command so the published schemas match what the software actually returns. No program logic, validati…
d1b6963bby daywalker90+204−1224 filesThis commit fixes a bug where a setting that controls whether unexpected transaction signatures are allowed was not initialized when the channel daemon starts. If a peer sent such signatures before the channel was fully ready, the program …
c09c4520by Erick Cestari+1−01 fileThis commit fixes the project's internal nightly code-coverage CI workflow. It changes how test coverage files are collected, ensures the same LLVM compiler version is used to generate and merge coverage data, and uploads a Codecov-compati…
5685c9a3by cdecker+12−211 fileThis commit is a large cleanup of Core Lightning's API schemas, generated RPC bindings, and related plugin code. The stated goal is to make the documented 'required' fields match what the C code actually always produces or expects. In prac…
ddbd2963by daywalker90+1786−173950 filesThis commit only updates documentation. It adds error code 313 to the documented error lists for several Core Lightning commands (fundpsbt, utxopsbt, txprepare, multiwithdraw, and upgradewallet). The error code already existed in the code …
a34b9758by Peter Neuroth+30−86 filesThis commit fixes a release-script check that verifies the cryptographic signature on a file of checksums. Previously, the script only told GPG to verify the signature file itself. If someone replaced that signature file with an inline-sig…
8e495707by Peter Neuroth+5−21 fileThis commit updates Core Lightning's release documentation to tell users and release managers to run gpg --verify with both the signature file and the manifest file named explicitly. The old one-argument form can silently succeed even if t…
2dee8699by Peter Neuroth+9−62 filesThis commit is a routine update to the Rust dependency lock file (Cargo.lock), bumping many third-party libraries to newer patch or minor versions. The commit message gives no security reason for the update, and no verified references link…
c1551c55by daywalker90+298−2761 fileThis commit fixes a stack-overflow risk in Core Lightning's JSON parser. Before the fix, an attacker could send a valid JSON-RPC message containing thousands of nested brackets or braces. The parser's own helper functions used recursion fo…
83f92e4bby Níckolas Goline+90−22 filesThis commit only fixes typos and comment style. It changes two C-style comments from // to /* */ and corrects a grammar error in a documentation comment ('element' to 'elements'). There are no code behavior changes, no bug fixes, and no se…
273d7f02by w3lld1+3−32 filesThis change fixes a test-infrastructure bug in Core Lightning's Python testing helpers. When running tests against a PostgreSQL database, very long test names could be silently shortened by PostgreSQL, causing different test runs or nodes …
c4fe4cbaby Peter Neuroth+59−12 filesThis fix prevents Core Lightning from trying to use freshly created bitcoins (immature coinbase rewards) as emergency funds for fee-bump transactions. Such a transaction would be invalid under Bitcoin's rules and would be rejected by the n…
34883ff7by cdecker+5−12 filesThis commit fixes a bug in Core Lightning's askrene plugin that could prevent a node from restarting. When a saved routing layer contained a node bias with a description, the plugin accidentally freed the description's memory while using i…
4681177dby Vincenzo Palazzo+2−32 filesThis commit only fixes a test case so it actually exercises the intended code path. It does not change any production code, so it cannot introduce or fix a real-world security vulnerability by itself. The test change is a reproducer for a …
0f3f67a0by Vincenzo Palazzo+3−21 fileThis commit fixes a bug in Core Lightning's experimental dual-funded channel feature. When another node tried to open a channel, Core Lightning was not checking whether the proposed transaction fees were reasonable. A peer could request a …
ba08356fby cdecker+140−04 filesThis commit adds regression tests for three related bugs where wildly wrong Bitcoin transaction feerates could enter Core Lightning. In the worst case, a malicious or broken fee source could make the node think a feerate was zero (due to a…
65bdbc47by cdecker+137−02 filesThis update fixes a crash bug in Core Lightning. When the software tried to list details of a channel opening in progress, it could crash if a stored fee rate was extremely large or zero. The crash happened because the code used an interna…
d67c4936by cdecker+72−227 filesThis commit fixes a bug where Core Lightning nodes could get stuck in a crash loop. If a node had previously stored an extremely high or zero fee rate for an in-progress channel funding operation (a 'splice' or dual-funded channel RBF), a …
f057c692by cdecker+34−01 fileExpand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
75616f6b · Oct 24, 2025 · 23 filesInformational 18common: add new_htable() macro to allocate, initialize and setup memleak coverage for any typed hash table.
You can now simply add per-tal-object helpers for memleak, but our older pattern required
calling memleak functions explicitly during memleak handling. Hash tables in particular need
to be dynamically allocated (we override the allocators using htable_set_allocator and assume
this), so it makes sense to have a helper macro that does all three.
This eliminates a huge amount of code.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a code cleanup change that introduces a helper macro to reduce repeated boilerplate when creating hash tables and registering them with the project's memory-leak detection tooling. It does not fix a known security bug, change protocol behavior, or alter access controls. The patch removes many manual memleak-registration calls and replaces them with a single macro that performs allocation, initialization, and registration together.
fc6bee89 · Oct 13, 2025 · 1 fileLow 35connectd: close connection properly after dev-disconnect `+`.
We need to drain subds too, otherwise if timing is correct we never close.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This patch fixes a bug in Core Lightning's connection handling where a developer testing feature (dev-disconnect '+') could leave a peer connection stuck open instead of closing it cleanly. The fix ensures all sub-connections are drained and freed before shutting down the peer connection. It is a hardening fix for a development/testing path, not a clear remote exploit on its own.
af340a68 · Oct 13, 2025 · 24 filesLow 27ccan: update to latest.
We fix the configure test which was bogus, and breaks on 32-bit gcc with optimization:
```
checking for unaligned access to int... ccan/tools/configurator/configurator: Test for HAVE_UNALIGNED_ACCESS did not compile:
configuratortest.c: In function 'main':
configuratortest.c:8:22: error: array subscript 'int[0]' is partly outside array bounds of 'char[4]' [-Werror=array-bounds]
8 | return *x == *y;
| ^~
configuratortest.c:5:11: note: at offset 1 into object 'pad' of size 4
5 | char pad[sizeof(int *) * 1];
| ^~~
cc1: all warnings being treated as errors
```
And also removes sprintf() calls, which apparently MacOS no longer likes:
Environment: Sequoia 15.6.1 (24G90)
SDK Version: MacOSX15.sdk
```
ccan/ccan/closefrom/closefrom.c:83:2: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
83 | sprintf(dnam, "/proc/%ld/fd", (long) getpid());
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:278:1: note: 'sprintf' has been explicitly marked deprecated here
278 | deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:218:48: note: expanded from macro 'deprecated_msg'
218 | #define deprecated_msg(_msg) attribute((deprecated(_msg)))
| ^
ccan/ccan/closefrom/closefrom.c:162:2: error: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror,-Wdeprecated-declarations]
162 | sprintf(dnam, "/proc/%ld/fd", (long) getpid());
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:278:1: note: 'sprintf' has been explicitly marked deprecated here
278 | deprecated_msg("This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.")
| ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:218:48: note: expanded from macro 'deprecated_msg'
218 | #define deprecated_msg(_msg) attribute((deprecated(_msg)))
| ^
2 errors generated.
make: *** [ccan-closefrom.o] Error 1
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Reported-by: Sangbida
Fixes: https://github.com/ElementsProject/lightning/issues/8581
Reported-by: https://github.com/Raimo33
Fixes: https://github.com/ElementsProject/lightning/issues/8501
Changelog-Fixed: build: we now build on MacOS without errors on the latest Command Line Tools (macOS 15 SDK).
Changelog-Fixes: build: fix build with -O2 on 32 bit arm (armhf)
This is a routine update to an internal code library (CCAN) used by Core Lightning. The main user-visible effect is fixing build failures on newer macOS and on 32-bit ARM when compiling with optimizations. It also replaces several old-style sprintf() calls with safer snprintf() versions. The sprintf() cases shown are generally low risk because the inputs are controlled (process IDs, small integers, fixed format strings), but switching to snprintf() is a defensive hardening improvement. There is no indication this fixes an active, exploitable vulnerability in running software.
b260ec2f · Oct 13, 2025 · 1 fileInformational 15wallet: print progress reports for large account migration.
Show the work we're doing (at debug level) and every 10 seconds print
progress (at INFO level):x
```
lightningd-1 2025-10-08T05:13:07.973Z INFO lightningd: Creating database
lightningd-1 2025-10-08T05:13:10.987Z DEBUG lightningd: Transferring 6166 chain_events
lightningd-1 2025-10-08T05:13:11.780Z DEBUG lightningd: Transferring 1660043 channel_events
```
It's the inserting channel_events which takes a long time, slowing
down exponentially:
```
lightningd-1 2025-10-08T05:13:18.034Z INFO lightningd: Inserted 26690/1660043 channel_events
lightningd-1 2025-10-08T05:13:28.034Z INFO lightningd: Inserted 47086/1660043 channel_events
lightningd-1 2025-10-08T05:13:38.035Z INFO lightningd: Inserted 61699/1660043 channel_events
lightningd-1 2025-10-08T05:13:48.035Z INFO lightningd: Inserted 73743/1660043 channel_events
lightningd-1 2025-10-08T05:13:58.035Z INFO lightningd: Inserted 83244/1660043 channel_events
...
lightningd-1 2025-10-08T05:35:18.286Z INFO lightningd: Inserted 466720/1660043 channel_events
lightningd-1 2025-10-08T05:35:29.074Z INFO lightningd: Inserted 468437/1660043 channel_events
lightningd-1 2025-10-08T05:35:39.079Z INFO lightningd: Inserted 470130/1660043 channel_events
lightningd-1 2025-10-08T05:35:49.081Z INFO lightningd: Inserted 471871/1660043 channel_events
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds progress messages (logging) during a database migration. It does not change how data is moved or stored, and it does not fix or introduce any security issue. It is purely a user-experience improvement so operators can see that a long upgrade is still running.
9f2e6de6 · Oct 13, 2025 · 1 fileInformational 20wallet: fix migration speed for postgres.
Testing a large db shows Postgres slowing down exponentially as
it inserts the channel_events. Rather than updating the index in the
db every time, do it at the end, for spectacular speedup:
```
lightningd-1 2025-10-08T05:39:44.333Z INFO lightningd: Creating database
lightningd-1 2025-10-08T05:39:47.581Z DEBUG lightningd: Transferring 6166 chain_events
lightningd-1 2025-10-08T05:39:48.455Z DEBUG lightningd: Transferring 1660043 channel_events
lightningd-1 2025-10-08T05:39:54.390Z INFO lightningd: Inserted 103100/1660043 channel_events
lightningd-1 2025-10-08T05:40:04.390Z INFO lightningd: Inserted 283280/1660043 channel_events
lightningd-1 2025-10-08T05:40:14.390Z INFO lightningd: Inserted 464065/1660043 channel_events
lightningd-1 2025-10-08T05:40:24.390Z INFO lightningd: Inserted 629559/1660043 channel_events
lightningd-1 2025-10-08T05:40:34.390Z INFO lightningd: Inserted 800659/1660043 channel_events
lightningd-1 2025-10-08T05:40:44.390Z INFO lightningd: Inserted 975433/1660043 channel_events
lightningd-1 2025-10-08T05:40:54.390Z INFO lightningd: Inserted 1134719/1660043 channel_events
lightningd-1 2025-10-08T05:41:04.390Z INFO lightningd: Inserted 1290549/1660043 channel_events
lightningd-1 2025-10-08T05:41:14.390Z INFO lightningd: Inserted 1443304/1660043 channel_events
lightningd-1 2025-10-08T05:41:24.390Z INFO lightningd: Inserted 1590013/1660043 channel_events
lightningd-1 2025-10-08T05:41:29.148Z INFO lightningd: bookkeeper migration complete: migrated 6166 chainmoves, 1660043 channelmoves, 132481 descriptions
```
Now we complete the entire migration in 1 minute 45 seconds.
Thanks to @michael1101 for reporting this.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: db: migration from v25.09 on a reasonable size account database could take almost infinite time.
This commit fixes a database migration performance bug in Core Lightning. When users upgraded from version 25.09, migrating large account databases to Postgres could take an extremely long time because an index was being updated after every single inserted record. The fix batches the index update until the end of the migration, reducing the time from potentially hours to under two minutes. It is a performance and reliability fix, not a security vulnerability.
01e83b76 · Oct 13, 2025 · 2 filesModerate 64lightningd: handle unparsable onion from first hop when using injectonionmessage.
In this case we have a failmsg, so we should use that. Otherwise we can have
both failmsg and failonion NULL in the call to injectonion_fail, which is not
valid.
```
DEBUG 022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59-chan#1: Removing out HTLC 1 state RCVD_REMOVE_ACK_REVOCATION WIRE_INVALID_ONION_HMAC
**BROKEN** lightningd: FATAL SIGNAL 11 (version v25.09-135-g19a3bbc-modded)
**BROKEN** lightningd: backtrace: common/daemon.c:41 (send_backtrace) 0x6220e8fe0080
**BROKEN** lightningd: backtrace: common/daemon.c:78 (crashdump) 0x6220e8fe00cf
**BROKEN** lightningd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x73614bc4532f
**BROKEN** lightningd: backtrace: lightningd/pay.c:1701 (injectonion_fail) 0x6220e8f951c0
**BROKEN** lightningd: backtrace: lightningd/pay.c:330 (tell_waiters_failed) 0x6220e8f943be
**BROKEN** lightningd: backtrace: lightningd/pay.c:656 (payment_failed) 0x6220e8f98db1
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:313 (fail_out_htlc) 0x6220e8fa1d04
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:1988 (remove_htlc_out) 0x6220e8fa271b
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:2086 (update_out_htlc) 0x6220e8fa2904
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:2095 (changed_htlc) 0x6220e8fa2c24
**BROKEN** lightningd: backtrace: lightningd/peer_htlcs.c:2608 (peer_got_revoke) 0x6220e8fa6e5a
**BROKEN** lightningd: backtrace: lightningd/channel_control.c:1555 (channel_msg) 0x6220e8f62725
**BROKEN** lightningd: backtrace: lightningd/subd.c:560 (sd_msg_read) 0x6220e8fb2eed
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:60 (next_plan) 0x6220e90a3335
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:422 (do_plan) 0x6220e90a3806
**BROKEN** lightningd: backtrace: ccan/ccan/io/io.c:439 (io_ready) 0x6220e90a38c3
**BROKEN** lightningd: backtrace: ccan/ccan/io/poll.c:455 (io_loop) 0x6220e90a524f
**BROKEN** lightningd: backtrace: lightningd/io_loop_with_timers.c:22 (io_loop_with_timers) 0x6220e8f7d1c7
**BROKEN** lightningd: backtrace: lightningd/lightningd.c:1496 (main) 0x6220e8f82db2
**BROKEN** lightningd: backtrace: ../sysdeps/nptl/libc_start_call_main.h:58 (__libc_start_call_main) 0x73614bc2a1c9
**BROKEN** lightningd: backtrace: ../csu/libc-start.c:360 (__libc_start_main_impl) 0x73614bc2a28a
**BROKEN** lightningd: backtrace: (null):0 ((null)) 0x6220e8f53b64
**BROKEN** lightningd: backtrace: (null):0 ((null)) 0xffffffffffffffff
```
Reported-by: @michael1011
Changelog-Fixed: lightningd: potential crash when we receive a malformed onion complain from our first peer when using sendonion / injectpaymentonion.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This fix stops Core Lightning from crashing with a fatal signal 11 (segfault) when a payment sent via the low-level `sendonion`/`injectpaymentonion` path fails because the very first peer reports a malformed onion. Before the fix, the code could call an internal failure-handling routine with both the failure message and the failure onion set to NULL, which is not allowed and caused the daemon to crash. The patch reorders the logic so the malformed-onion message is used when available, and adds a safety assertion that the onion is present in the remaining case.
bd1ba164 · Oct 2, 2025 · 2 filesLow 28wallet: don't insert duplicate chain_moves entries after accounts.db migration.
When we migrate from accounts.db, we use the `account_nonchannel_id`
field. But we can replay the block chain and the channel involved is
still open, we will use the `account_channel_id` field, and our duplicate
detection fails.
As a result, we can end up with duplicate entries in the database, which
make accounting incorrect.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `listchainmoves` could contain bogus duplicate entries after 25.09 bookkeeper migration.
This commit fixes a bug in Core Lightning's accounting/bookkeeping system where the same on-chain money movement could be recorded twice in the database after a migration. The bug happens because the code looked for duplicates using one account identifier, but after a migration or replay it could store the same event under a different identifier. The fix makes duplicate detection check both possible identifiers. It is a data-integrity bug, not a security vulnerability that an attacker can exploit.
fb973fea · Oct 2, 2025 · 3 filesLow 27wallet: find and remove any duplicates from the bug we just fixed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a database cleanup routine that removes accidentally duplicated accounting records created by a previous bug. It is a data-integrity fix, not a security patch that stops an active attack. The underlying bug allowed the same on-chain money movement to be recorded twice—once under a live channel reference and once under a non-channel account reference—so users' coin-movement reports could be wrong until the duplicates are removed.
5b06e653 · Oct 2, 2025 · 2 filesInformational 12wallet: unit test the migration dedup code.
This is based on a real database, which values changed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit adds a new automated test for a database cleanup routine called migrate_remove_chain_moves_duplicates. The test builds a small in-memory database, inserts many example records (some deliberately duplicated), runs the cleanup function, and checks that only the duplicates are removed. It does not change the actual cleanup code or any production behavior; it only adds test coverage.
7631ce63 · Oct 2, 2025 · 2 filesInformational 12wallet: unit test for duplicate detection in wallet_save_chain_mvt.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds a new automated test file. It checks that a wallet function called wallet_save_chain_mvt correctly ignores exact duplicate records while still storing records that differ in transaction ID, output point, or movement type. There is no change to production code, no bug fix, and no security patch.
cb2849d0 · Oct 2, 2025 · 5 filesInformational 21wallet: don't delete old htlcs when we forget a channel, do it on startup.
For old channels, this can take a while, and it stops everything. But
we are only doing this to save space; it's not a *functional* necessity.
A quick and dirty test with 50,000 htlcs shows the htlc deletion took
450msec. I tried adding an index, and changing it to set hstate to
HTLC_STATE_INVALID instead of deleting entries, but it still took about 350ms.
Whereas the "COUNT(*)" only took 1.7msec, so it's worth keeping.
Reported-by: @michael1011
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: lightningd: we defer deletion of old htlcs on channel close, to avoid pausing for a long time (we clean them on startup)
Fixes: https://github.com/ElementsProject/lightning/issues/7962
This change moves a database cleanup job from the moment a channel closes to the next time the node starts up. Previously, deleting tens of thousands of old payment records when a channel closed could freeze the node for hundreds of milliseconds. Now the records are counted and reported immediately, but actually deleted later during startup. It is a performance and availability improvement, not a security fix.
aa8d858c · Oct 2, 2025 · 1 fileInformational 12pytest: test that we don't delete htlcs as soon as channel closed, wait for restart.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only adds a new test to the test suite. It checks that old payment records (HTLCs) are not deleted from the database immediately when a channel closes, but are instead cleaned up later when the node restarts. There is no code change that fixes or changes any behavior.
bee54f0e · Oct 2, 2025 · 1 fileInformational 18wallet: don't show htlcs from closed channels in listhtlcs.
This doesn't happen yet, since we delete all HTLCs when we close a channel. But we're
about to change that, so update the wallet_htlcs_first() code to avoid them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a small, forward-looking cleanup change in Core Lightning's wallet code. It adjusts a database query so that the `listhtlcs` command will not return HTLCs (payment forwarding contracts) belonging to channels that have already been closed. The commit explicitly says this situation cannot happen yet because HTLCs are currently deleted when a channel closes, but the code is being prepared for an upcoming change where closed-channel HTLCs may be kept around.
350af1a3 · Oct 1, 2025 · 1 fileInformational 15doc: pretty!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit only reformats a documentation table so the columns line up nicely. No code, no behavior, and no security-related changes are present.
54444e43 · Oct 1, 2025 · 20 filesLow 27BOLT12: Update recurrence to latest spec draft.
Changes:
* Fields renumbered to their draft values + billion.
* offer_recurrence now comes in compulsory or optional (backwards compat) flavors.
* `proportional_amount` is now inside `offer_recurrence_base` not `offer_recurrence_paywindow`.
* New field `invreq_recurrence_cancel`.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-EXPERIMENTAL: Draft specification for recurring offers changed: old recurring offers will no longer work.
This commit updates Core Lightning's implementation of BOLT12 recurring payments to match a newer draft of the specification. It renumbers data fields, splits a setting into compulsory and optional versions, moves a proportional-amount setting into a different field, and adds a new invoice-request cancellation field. The changelog explicitly notes this is an experimental/draft feature change that breaks backward compatibility with old recurring offers. There is no direct evidence in the commit of a security vulnerability.
e7ea57e1 · Oct 1, 2025 · 17 filesInformational 19BOLT12: Remove `start_any_period` from recurrence_base.
Offer_absolute_expiry should be used if you want to require starting at the start.
Changelog-EXPERIMENTAL: Protocol: BOLT 12 recurrence `start_any_period` removed, use expiry if you need to restrict when they can start using the offer.
This commit removes an experimental BOLT12 feature called `start_any_period` from Core Lightning's offer recurrence system. It is a protocol/API cleanup change, not a security patch. The functionality is replaced by the existing `absolute_expiry` mechanism for restricting when offers can be used. There is no direct evidence in the commit of a vulnerability being fixed.
f882b69d · Oct 1, 2025 · 3 filesLow 42gossipd: remove gossmap_fetch_tail.
It only gets called for diagnostics when something goes wrong (and we
were going to exit anyway), and it's only useful with mmap (which we now disable
on error) but it shouldn't crash:
```
**BROKEN** gossipd: Truncated gossmap record @7991501/7991523 (len 0): waiting
**BROKEN** gossipd: FATAL SIGNAL 6 (version v25.09)
**BROKEN** gossipd: backtrace: common/daemon.c:41 (send_backtrace) 0x6506817cc529
**BROKEN** gossipd: backtrace: common/daemon.c:78 (crashdump) 0x6506817cc578
**BROKEN** gossipd: backtrace: ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 ((null)) 0x75e8267a032f
**BROKEN** gossipd: backtrace: ./nptl/pthread_kill.c:44 (__pthread_kill_implementation) 0x75e8267f9b2c
**BROKEN** gossipd: backtrace: ./nptl/pthread_kill.c:78 (__pthread_kill_internal) 0x75e8267f9b2c
**BROKEN** gossipd: backtrace: ./nptl/pthread_kill.c:89 (__GI___pthread_kill) 0x75e8267f9b2c
**BROKEN** gossipd: backtrace: ../sysdeps/posix/raise.c:26 (__GI_raise) 0x75e8267a027d
**BROKEN** gossipd: backtrace: ./stdlib/abort.c:79 (__GI_abort) 0x75e8267838fe
**BROKEN** gossipd: backtrace: ./assert/assert.c:96 (__assert_fail_base) 0x75e82678381a
**BROKEN** gossipd: backtrace: ./assert/assert.c:105 (__assert_fail) 0x75e826796516
**BROKEN** gossipd: backtrace: common/gossmap.c:111 (map_copy) 0x6506817cea77
**BROKEN** gossipd: backtrace: common/gossmap.c:1870 (gossmap_fetch_tail) 0x6506817d1f93
**BROKEN** gossipd: backtrace: gossipd/gossmap_manage.c:1442 (gossmap_manage_get_gossmap) 0x6506817c45fb
**BROKEN** gossipd: backtrace: gossipd/gossmap_manage.c:753 (gossmap_manage_handle_get_txout_reply) 0x6506817c5850
**BROKEN** gossipd: backtrace: gossipd/gossipd.c:574 (recv_req) 0x6506817c172b
```
Reported-by: @grubles
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit removes a rarely-used diagnostic helper called gossmap_fetch_tail that could crash the gossip daemon when it tried to read the tail of a corrupted or truncated gossip map. The crash happened during an internal error path (the daemon was already about to exit), so it is more of a crash-on-failure than an exploitable vulnerability. The fix simply stops calling the helper and reports the remaining file data from the regular file descriptor instead.
0d976310 · Oct 1, 2025 · 14 filesLow 34connectd: simplify logic, and add a "reconnected" message.
One issue we have in CI is reconnection races: if an incoming
connection arrives while an outgoing one is negotiated, we close the
outgoing one and issue a disconnect, which fails any connect attempts.
By sending a "reconnected" message instead of disconnect/connect we
can avoid disturbing in-progress connection attempts which happens in CI
quite a bit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit rewrites how Core Lightning handles peer reconnections. Previously, when a new incoming connection arrived while an outgoing one was still being negotiated, the daemon would tear down the old connection and report a full disconnect followed by a new connect. That sequence often caused in-progress connection attempts to fail, especially in automated CI tests. The patch introduces a single 'reconnected' message that replaces the disconnect/connect pair, so the higher-level code sees a smooth handover instead of a failure. It also refactors the cleanup paths for peer objects and subdaemons. The change is described by the author as a reliability improvement for CI races, not as a security fix, and no independent security advisory is supplied.
7a7a48c3 · Oct 1, 2025 · 16 filesInformational 18chore: Update python dependencies
I got a bit annoyed by all the "your protobuf gencode is too old"
warnings in downstream packages, so I spent a bit of time updating any
stale dependency and now we're back allowing packages up to the latest
release. That should maximize the compatibility, and allow downstream
packages to chose their own versions, as long as they are
compatible (semantic versioning).
This commit is a routine maintenance update for Python package dependencies in Core Lightning's Python tooling. It bumps versions of libraries like protobuf, grpcio, cryptography, pytest, and Flask, raises the minimum Python version from 3.8 to 3.9, and regenerates protobuf Python code. There is no direct evidence in the commit that this fixes a specific security vulnerability. It is best treated as a hygiene update that may indirectly reduce risk by moving to newer, supported dependency versions, but it also widens version ranges which could allow downstream users to pull in untested or vulnerable versions.
cedf2f9d · Sep 22, 2025 · 431 filesInformational 15fuzz-tests: Add a seed corpus for the new test
Add a minimal input set as a seed corpus for the newly introduced
test. This leads to discovery of interesting code paths faster.
This commit only adds test data files (a seed corpus) for a new fuzzing test named fuzz-codex32. It does not change any production code, so it cannot introduce a security vulnerability or fix one. The files are inputs used to exercise the codex32 parsing code during automated testing.
6e16f944 · Sep 22, 2025 · 137 filesInformational 15fuzz-tests: Add coverage-increasing inputs to seed corpora
Change in the fuzzing scheme of fuzz-bech32 led to the
discovery of test inputs that result in greater in code
coverage. Add these inputs to the test's seed corpus.
This commit only adds and removes test input files used for fuzzing the bech32 address parser. It is a routine test-data update with no changes to the actual software code that runs on users' systems. There is no indication of a security fix or vulnerability.
5cc8d0ad · Sep 22, 2025 · 97 filesInformational 15fuzz-tests: Add a seed corpus for the new test
Add a minimal input set as a seed corpus for the newly introduced
test. This leads to discovery of interesting code paths faster.
This commit only adds test data files (a fuzzing seed corpus) for a new fuzz test called fuzz-funder-policy. It does not change any production code, so it cannot directly introduce a security vulnerability or fix one. The files are inputs used by an automated testing tool to exercise the funder policy code more quickly.
490fb0fc · Sep 15, 2025 · 4 filesInformational 21contrib: Added fixed SOURCE_DATE_EPOCH flag for reproducible ubuntu builds
clnrest's `utoipa-swagger-ui` library has an indirect `rust-embed` dependency which by default includes timestamps in build. It results in non-deterministic build for clnrest. Using environment variable `SOURCE_DATE_EPOCH` with fixed value will enforce a consistent timestamp for builds.
Also adding the `--locked` flag to ensure the release build uses exact dependencies from Cargo.lock. The `--locked` flag is particularly important for deterministic builds as it prevents Cargo from updating the lockfile.
Fixes #8288.
Changelog-Fixed: Core lightning builds for Ubuntu Focal, Jammy and Noble are deterministic again.
This change makes Core Lightning's Ubuntu release builds produce identical output every time (reproducible builds). It does not fix a vulnerability in running software; instead, it removes a source of randomness in build timestamps and dependency versions that could make it hard to verify that a published binary truly came from the published source code. Reproducible builds help users and developers detect supply-chain tampering, but the patch itself is a build-hardening improvement, not an exploit fix.
6f4cfede · Sep 15, 2025 · 41 filesInformational 15fuzz-tests: Add coverage-increasing inputs to seed corpora
Change in the fuzzing scheme of `fuzz-close_tx` led to the
discovery of test inputs that result in greater in code
coverage. Add these inputs to the test's seed corpus.
This commit only adds 41 new binary test files to a fuzz-testing seed corpus. Fuzzing seeds are like practice questions used to exercise code during automated testing; they are not part of the live Lightning node software and cannot directly affect real users or funds. There is no code change, no bug fix, and no security patch in this commit.
17cf63ae · Sep 15, 2025 · 124 filesInformational 15fuzz-tests: Add coverage increasing inputs to seed corpora
Improvements in the fuzz-testing scheme of `fuzz-channel_id led
to the discovery of test inputs that result in greater in code
coverage. Add these inputs to the test's seed corpus.
This commit only adds new test input files to a fuzz-testing seed corpus. Fuzz testing is an automated quality-assurance technique that feeds random or unusual inputs to a program to find bugs. These added files are not part of the live Core Lightning software that users run, so the commit does not change any production code or fix any security issue. It is purely a testing-data update.