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 1 hour, 2 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.
41278b4e · Sep 21, 2026 · 2 filesInformational 15contrib: add jaonoctus's signing key
Add jaonoctus's PGP fingerprint to the "Signatures For Releases" table
in both SECURITY.md and the security-policy doc, which are kept in sync.
Changelog-None
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.
e4a30698 · Sep 17, 2026 · 1 fileTriage 0tests: fix test_blinded_forward_policy flake
l1 isn't part of the l2-l3 funding, so join_nodes([l2, l3]) can leave it
a block behind. The final CLTV only just meets l3's cltv-final, so l3
then rejects with "Expiry cltv too soon" and l1 reports the opaque
"Malformed error reply". Sync all nodes before reading the blockheight.
Changelog-None
498e5086 · Sep 17, 2026 · 1 fileInformational 15wallet: fixed timestamps for invented bookkeeper deposits
migrate_setup_coinmoves() stamped wallet deposits with wall-clock time
via coinmvt_current_time(), so a slow migration could place the deposit
after the channel journal entry in bkpr-listaccountevents, flaking
test_migration_no_bkpr.
Use base_timestamp + 1, like the channel moves, so the order is stable.
Changelog-None
This 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 channel records instead of using the real-time clock. There is no security issue here.
8cfd1fc9 · Sep 17, 2026 · 1 fileTriage 0tests: wait for peer disconnect in test_blindedpath_noaddr
l2.rpc.disconnect() returns before l3 notices the socket close, so l3
could still see l2 as connected and add a route hint, flaking the check
that a disconnected peer is not used as a blinded path entry.
Changelog-None
946f700c · Sep 15, 2026 · 1 fileTriage 0tests: fix flake in test_dataloss_protection
l2 detects the data loss and sends l1 an "Awaiting unilateral close"
error (after the channeld's 1 second delay), which l1 must receive to
drop to chain. But l1's channeld normally sends a warning and exits
first; if l2's error arrives before l1's connectd has torn that subd
down it is routed to the dying channeld and lost, so l1 never sees it
and we time out waiting for:
l1.daemon.wait_for_log("They sent ERROR.*Awaiting unilateral close")
Reconnect if we don't see it: channel->error is resent when the peer
reconnects, so l1 gets the error and drops to chain. We may already be
disconnected, in which case disconnect() fails with "Peer not
connected": that's fine, connect() is what matters.
This restores the workaround the test had before 6fdaec313 replaced it
with the channeld sleep.
Changelog-None
b6841e4c · Sep 15, 2026 · 2 filesTriage 0sendpay: idempotent success on replay of completed self-payments
According to the documentation of sendpay:
Calls to sendpay with the same payment_hash,
amount_msat, and destination as a previous
successful payment (even if a different route
or partid) will return immediately with success.
A self payment is a special case, but the destination being
always ourselves should follow the same rule.
Changelog-Fixed: sendpay: immediate success when replaying a completed self payment.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
3e950097 · Sep 14, 2026 · 2 filesTriage 0renepay: free pending routes when the payment finishes
A payment can complete while some of its routes are still in flight.
This happens with MPP, or when a retry succeeds before all the parts of
a previous attempt have resolved. payment_collect_results() only frees
the routes that reached a final state, so the still-in-flight routes
stay in the global pay_plugin->pending_routes map forever.
The serialized onion of such a route is only reachable through the tal
tree (struct route does not keep a pointer to it), so memleak reports
it at shutdown:
**BROKEN** plugin-cln-renepay: MEMLEAK: 0x55c92426bfc8
**BROKEN** plugin-cln-renepay: label=u8[]
**BROKEN** plugin-cln-renepay: alloc:
**BROKEN** plugin-cln-renepay: common/sphinx.c:183 (serialize_onionpacket)
**BROKEN** plugin-cln-renepay: plugins/renepay/routetracker.c:353 (create_onion)
**BROKEN** plugin-cln-renepay: plugins/renepay/routetracker.c:410 (route_sendpay_request)
**BROKEN** plugin-cln-renepay: parents:
**BROKEN** plugin-cln-renepay: struct route
**BROKEN** plugin-cln-renepay: struct pay_plugin
Implement the routetracker_cleanup() hook, which was a TODO: when the
payment finishes, collect the routes that are still pending for it and
free them, which removes them from the pending routes map through the
existing destructor.
Changelog-Fixed: renepay: fix a memory leak of routes that were still in flight when the payment completed.
43acdddd · Sep 14, 2026 · 1 fileTriage 0tests: fix test_htlc_sig_persistence flake
Changelog-None
72fa1a60 · Sep 14, 2026 · 1 fileTriage 0tests: fix test_rbf_non_last_mined flake
```
# The funding transaction gets mined (should be the 2nd inflight)
bitcoind.generate_block(6, wait_for_mempool=1)
# l2 comes back up
l2.start()
# everybody's got the right things now
l1.daemon.wait_for_log(r'to CHANNELD_NORMAL')
l2.daemon.wait_for_log(r'to CHANNELD_NORMAL')
channel = only_one(l1.rpc.listpeerchannels()['channels'])
> assert channel['funding_txid'] == inflights[1]['funding_txid']
E AssertionError: assert '12f2577bf10d40dd85e2de4ea867b59145fdcad541e861cf5993fbc5428b3aa7' == '1b8c5be4b21f8b741202cc2fcb1eb4ee0d529196870cfdeea03b1e69f88b436d'
E
E - 1b8c5be4b21f8b741202cc2fcb1eb4ee0d529196870cfdeea03b1e69f88b436d
E + 12f2577bf10d40dd85e2de4ea867b59145fdcad541e861cf5993fbc5428b3aa7
tests/test_opening.py:1448: AssertionError
```
Changelog-None
d1b6963b · Sep 11, 2026 · 24 filesInformational 21docs: document missing and fix erroneous JSON-RPC error codes
Audit the `errors` sections of the RPC schemas against the error codes
the handlers actually raise, and fix the discrepancies.
FUNDING_STILL_SYNCING_BITCOIN (304) is only raised by `fundpsbt` and
`utxopsbt` (wallet/reservation.c), and is forwarded verbatim by every
other command which can return it. Document it on `fundpsbt`,
`utxopsbt`, `txprepare`, `withdraw`, `multiwithdraw`, `upgradewallet`,
`fundchannel` and `multifundchannel`. Conversely, `fundchannel_start`
and `openchannel_init` do not call either: when the node is not synced
they delay via topology_add_sync_waiter() and retry, so drop their
stale 304.
Also fix the remaining discrepancies:
- `delpay` documented 211 for a status mismatch, but that path returns
208 (PAY_NO_SUCH_PAYMENT); 211 is never raised by `delpay`, so replace
it;
- document missing codes: `createinvoice` 907 (INVOICE_OFFER_INACTIVE),
`enableoffer` 1007 (OFFER_USED_SINGLE_USE), `getroutes` 217
(PAY_USER_ERROR) and `addpsbtoutput` 302/309;
- add `errors` sections to `splice_init`, `splice_update` and
`splice_signed` (351-356), `disableoffer` and `disableinvoicerequest`
(1001), `preapproveinvoice` (213), `preapprovekeysend` (214) and
`recover` (1600).
The splice commands can also fail asynchronously, after the command has
gone pending, through the channeld message handlers in channel_control.c
which resolve the pending command via splice_command_for_chan().
Document those codes too: 350 (SPLICE_BROADCAST_FAIL) on `splice_signed`;
357/359/360 (SPLICE_FUNDING_LOW/SPLICE_LOW_FEE/SPLICE_HIGH_FEE) on
`splice_update`; and 358/362/363 (SPLICE_STATE_ERROR/SPLICE_ABORT/
SPLICE_CHANNEL_ERROR) on all three.
Changelog-None
This 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, validation, or behavior was changed, so it cannot be exploited or cause runtime failures. It mainly helps developers and automated tools build correct clients.
78f4cd72 · Sep 9, 2026 · 4 filesTriage 0docs: remove old references to pay, use xpay
Changelog-None.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
8c8fdf4e · Sep 8, 2026 · 1 fileTriage 0dualopend: initialize state->reconnected on startup
state->reconnected was only set to true after do_reconnect_dance(),
so a fresh dualopend never wrote it. A commitment_signed arriving
out of turn in the main loop made handle_commit_signed() read an
uninitialized bool, which UBSan flags as a load of an invalid bool
value.
Default it to false, so an out-of-turn commitment_signed is always
rejected unless we really reconnected.
Changelog-None
Signed-off-by: Erick Cestari <erickcestari03@gmail.com>
c09c4520 · Sep 8, 2026 · 1 fileLow 46channeld: initialize tx_sigs_allowed on startup
peer->tx_sigs_allowed was only set in peer_reconnect() and when we
receive channel_ready, so on a fresh channeld start a stray
tx_signatures arriving before the peer's channel_ready made
handle_unexpected_tx_sigs() read an uninitialized bool. UBSan flags
this as a load of an invalid bool value, and in normal builds the
"warn and disconnect" branch was effectively taken at random.
Default it to false: we only allow an unexpected tx_signatures when
reconnecting.
Changelog-None
This 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 would read an uninitialized value. In practice this usually caused a random, harmless disconnection, but under undefined-behavior detection it was flagged as a serious bug. The fix simply sets the value to false at startup.
5685c9a3 · Sep 8, 2026 · 1 fileInformational 15ci: fix the coverage nightly's profile handling
Three things stand between the restored scripts and a nightly that
finishes:
pyln-testing sets CLN_TEST_NAME for every test, so the profiles land in
$CLN_COVERAGE_DIR/<test-name>/ and never directly in $CLN_COVERAGE_DIR.
The coverage-raw/*.profraw upload glob therefore matches nothing, under
if-no-files-found: error. A local three-test run produced 515 profiles,
all of them in subdirectories. Both jobs now hand the directory to
collect-coverage.sh, which walks it and drops what crashed tests left
half-written; that also retires the flattening cp, which could collide
on <pid>-<signature>.profraw between matrix cells.
The build uses the runner's default clang while the report job installed
LLVM 18 and symlinked llvm-profdata to it. There are no compatibility
guarantees for the raw profile format across LLVM releases, so the two
have to come from the same one.
Codecov cannot read a .profdata; it gets the lcov export instead.
Changelog-None
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HGKo3ccLpkH2xFeEXUzEBK
This 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-compatible lcov report instead of an unreadable .profdata file. There is no security issue here—just build-script maintenance.
f78f900f · Sep 8, 2026 · 1 fileTriage 0coverage: export lcov beside the HTML report
llvm-cov can emit lcov from the profile and binary list the script has
already assembled, so this costs one more invocation and gives the
report a machine-readable form. The nightly needs it: it currently hands
Codecov coverage/merged.profdata, which Codecov cannot parse. It is also
what GitLab's coverage visualization wants, via lcov_cobertura.
Paths are rewritten relative to the repository root, since both
consumers match the report against the repository tree.
Changelog-None
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HGKo3ccLpkH2xFeEXUzEBK
662e338f · Sep 8, 2026 · 6 filesTriage 0coverage: restore the scripts every caller already references
None of these are new: 4b9cffe183 wrote the documentation and the callers
for them, but .gitignore swallowed the directory itself, so master ships
a coverage feature whose every entry point is a missing file.
- Makefile's coverage-clang-collect and coverage-clang-report call
collect-coverage.sh and generate-coverage-report.sh
- .github/workflows/coverage-nightly.yaml calls the same two, and has
failed at "Merge coverage data" every night since
- doc/COVERAGE.md documents those two plus per-test-coverage.sh,
per-test-coverage-html.sh and cleanup-corrupt-profraw.sh
- doc/contribute-to-core-lightning/contributor-workflow.md points at
clang-coverage-report.sh, which the same commit deleted from
contrib/ after re-pointing the doc at contrib/coverage/
The files are restored unmodified; clang-coverage-report.sh is
byte-identical to the one removed from contrib/.
Changelog-None
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HGKo3ccLpkH2xFeEXUzEBK
35110bd8 · Sep 8, 2026 · 1 fileTriage 0gitignore: anchor the coverage entry to the repository root
The entry is unanchored, so it matches contrib/coverage/ as well as the
coverage/ build output directory it was meant for. That is how 4b9cffe183
came to add the coverage documentation, the Makefile targets, the
pyln-testing plumbing and the nightly workflow while silently leaving the
scripts they all call out of the commit.
Changelog-None
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HGKo3ccLpkH2xFeEXUzEBK
9ddd2274 · Sep 7, 2026 · 3 filesTriage 0askrene: cut-off arcs with very low probability
Arcs with very low probability of success are pruned early.
This only applies to the single path solver because the MPP code
uses arc linearization and already the low probability tail is removed.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
ddbd2963 · Sep 3, 2026 · 50 filesLow 37schemas: make required fields match the code
Fields added to `required` (source where unconditionally added):
- askrene-create-layer/layers[]. & askrene-listlayers/layers[]:
`biases`, `node_biases` - plugins/askrene/layer.c:1512,1519
- bkpr-channelsapy/channels[]: `fees_in_msat` - plugins/bkpr/channelsapy.c:292
- bkpr-report: `format` (request) - plugins/bkpr/bookkeeper.c:520;
`format-hint` - plugins/bkpr/report.c:499
- datastore & deldatastore: `generation`, `hex` - lightningd/datastore.c:19,20
- decode/offer_recurrence[]: `compulsory_field` - plugins/offers.c:880
- delpay/payments[]: `groupid` - lightningd/pay.c:144
- feerates/onchain_fee_estimates: `unilateral_close_nonanchor_satoshis`
- lightningd/chaintopology.c:788
- fundchannel_start: `channel_type` - lightningd/opening_control.c:321
- help: `format-hint` - lightningd/jsonrpc.c:496
- hook/onion_message_recv & _secret: `unknown_fields`,
`reply_blindedpath.{first_path_key,hops}` - lightningd/onion_message.c:30,31,66
- listchannels/channels[]: `htlc_maximum_msat` - plugins/topology.c:263
- listclosedchannels/closedchannels[]: `channel_type`
- lightningd/closed_channel.c:43
- listconfigs: `configs` - lightningd/configs.c:275
- listpays/pays[]: `amount_sent_msat` - plugins/xpay/listpays.c:183
- listpeerchannels/channels[]: `channel_type` - lightningd/peer_control.c:959,
lightningd/dual_open_control.c:128, lightningd/opening_control.c:48
- listpeers/peers[]: `features` - lightningd/peer_control.c:2619
- multifundchannel: `failed` - plugins/spender/multifundchannel.c:501
- notification/coin_movement: `extra_tags` - lightningd/coin_mvts.c:169
- offer: `force_paths` - lightningd/offer.c:24
- openchannel_init & openchannel_bump: `requires_confirmed_inputs`
- lightningd/dual_open_control.c:3478
- parsefeerate: `perkw` - lightningd/chaintopology.c:823
- pay: `destination` - plugins/xpay/xpay.c:473, plugins/libplugin-pay.c:2144
- reckless (request): `target/subcommand` - plugins/recklessrpc.c:280
- renepay & renepaystatus/paystatus[]: `groupid`, `destination`
- plugins/renepay/json.c:269,278,279
- sendonion: `groupid` - lightningd/pay.c:144; pending branch `message` - :299
- sendpay & waitsendpay: `groupid` - lightningd/pay.c:144
- splice_signed: `outnum` - lightningd/channel_control.c:548
- splicein & spliceout: `psbt`, `txid` - plugins/spender/splice.c:1763,1764
Fields removed from `required` (conditional in code):
- bkpr-editdescriptionbypaymentid/items[]: `description`
- plugins/bkpr/chain_event.c:33-34, plugins/bkpr/channel_event.c:53-54
- createinvoice & sendinvoice: `description` - lightningd/invoice.c:64-65
- hook/invoice_payment: `result` - lightningd/invoice.c:237 (optional);
`failure_message` only used when `result` is absent, now required there
via if/then/else
- invoicerequest (request): `description` - plugins/offers_offer.c:693 (p_opt)
- splice_signed (request): `channel_id` - lightningd/channel_control.c:2511
(p_opt)
Note: bkpr-editdescriptionbyoutpoint keeps `description` required: the
SQL refetch filters credit_msat > 0 (recorder.c:376-382) and the desc was
just stored keyed by outpoint (bookkeeper.c:853).
Adjust plugins and tests to the now-required fields:
- lsps-plugin: peer.features is non-optional (listpeers)
- wss-proxy-plugin: listconfigs' configs object is non-optional
- cln-rpc/src/test.rs
Changelog-None
This 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 practice it mostly removes 'optional' markers from fields that were already unconditionally emitted, and makes a few truly conditional fields optional. It also changes one plugin hook response schema so that a plugin can reject a payment by returning only a custom failure_message, without a result field. The changes are broad but are described by the project as a schema consistency fix, not a security fix. There is no direct evidence in the commit of an exploitable vulnerability.
a34b9758 · Sep 2, 2026 · 6 filesInformational 15doc: document error 313 on every command which can return it
FUND_CANNOT_AFFORD_WITH_EMERGENCY is raised in exactly two places,
`fundpsbt` and `utxopsbt` (wallet/reservation.c), when the node has an
anchor channel and the transaction would not leave `min-emergency-msat`
behind. Note that this does not require `opening_anchor_channel`: any
existing anchor channel is enough.
Every other command which can return it does so by forwarding one of
those two errors verbatim, but only `withdraw`, `fundchannel` and
`multifundchannel` documented it. Add it to the rest:
- `fundpsbt` and `utxopsbt`, which raise it directly;
- `txprepare` and `multiwithdraw`, which call them;
- `upgradewallet`, which calls `utxopsbt` via txprepare_continue() and
had no `errors` section at all, so document -1 and 301 there too.
Changelog-None
This 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 and was already documented for some commands; this change makes the documentation complete and consistent. No code behavior changes.
d7d1e78c · Sep 2, 2026 · 4 filesTriage 0doc: fix wording of the min-emergency-msat error description
The three schemas which documented error 313 all read "The
`min-emergency-msat` reserve not be preserved", which is missing a verb.
Changelog-None
23f7e3f3 · Sep 2, 2026 · 2 filesTriage 0askrene: fix set zero bias on persistent layers
Changelog-Fixed: askrene: setting an absolute bias value to zero on a persistent layer doesn't result on a NULL pointer dereference.
Reported-by: @whkim0 and @Ahmadsm2005
Suggested-fix: @Andezion
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
8e495707 · Sep 2, 2026 · 1 fileLow 25tools/build-release.sh: name the checksum file when verifying the signature
The --verify path called `gpg --verify ../SHA256SUMS-$VERSION.asc` and
let gpg work out the rest. For a proper detached signature it does find
the sibling file, so this happened to work, but an inline signed .asc
would verify its own embedded payload and exit 0 without ever looking at
the checksums we just compared. Since the exit status is what decides
whether we print "Verified Successfully!", that is not a distinction we
want to leave to gpg.
Changelog-None: docs and release tooling only, nothing user-facing.
This 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-signed message containing its own text, GPG would still report success without ever checking the actual checksum file. The fix explicitly names the checksum file so GPG verifies the signature against the intended manifest. This is a hardening change in internal release tooling, not a fix for an active vulnerability in the Lightning node software users run.
2dee8699 · Sep 2, 2026 · 2 filesLow 42doc: pass the manifest explicitly to gpg --verify
We told people to drop SHA256SUMS and SHA256SUMS.asc into the same
directory and run `gpg --verify SHA256SUMS.asc`. That relies on gpg
guessing what to check, and the guess only happens for a real detached
signature. If the .asc turns out to be an inline signed message, gpg
verifies the payload embedded in the .asc itself, never touches
SHA256SUMS, and exits 0. It does warn on stderr, but that is easy to
scroll past and worthless to anything checking the exit code.
Spell out both filenames instead, and explain why. Also drop the
"gpg: assuming signed data in 'SHA256SUMS'" line from the sample
output, since gpg has nothing left to assume once we name the file.
This 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 the .asc file is not a proper detached signature over the manifest, because gpg may verify only a message embedded inside the .asc file and never check SHA256SUMS. The change prevents a subtle but real verification bypass in the release process, though it is a documentation-only fix and does not change any code or tooling.
d421449f · Aug 31, 2026 · 1 fileTriage 0doc: document CLN_PLUGIN_LOG in the cln-plugin crate
The cln-plugin crate has no crate-level documentation, and CLN_PLUGIN_LOG
is not mentioned anywhere in the crate. Add a crate-level doc block
describing the variable, its accepted values, and the behaviour when it
is unset.
Fixes #6927