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.
Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
This commit is a simple documentation revert. It undoes a previous change that told macOS users to install GNU make and GNU patch from Homebrew and to put those tools first in their command path. The reverted instructions now omit gpatch a…
This commit re-adds an old-style 'x' prefix to a string comparison in a test helper script. It is a test-only change with no effect on the actual Core Lightning node software, user funds, network behavior, or security. The change simply re…
This commit only updates macOS installation instructions in the documentation. It tells macOS users to install newer GNU versions of 'make' and 'patch' from Homebrew because Apple's built-in tools are too old for building and running sourc…
This commit is a trivial shell script cleanup. It removes an old-fashioned 'x' prefix from a string comparison in a test helper script so that a newer version of the Shellcheck linter stops warning about it. The change does not alter progr…
This commit moves existing code that parses payment amounts (Bitcoin millisatoshis, 'any' amount, or fiat currency amounts) from one plugin file into a shared library so it can be reused by a future feature. It is a code refactoring with n…
Refactoring of amount-parsing code into a shared helperAddition of explicit u64 overflow guards (mul_overflows_u64, add_overflows_u64) in the new common codeNo change to wire protocol or RPC interface semantics
This is a routine internal cleanup commit in Core Lightning. It removes an unused helper function and simplifies how JSON-RPC request IDs are stored and formatted, since the project now always uses string IDs for non-command JSON traffic. …
No security-relevant keywords in commit title or messageNo CVE, advisory, or bug reference presentChanges are refactor/cleanup in nature
This commit is a routine code cleanup: it moves a small string-hashing helper function into a shared header file so it can be reused without being copied and pasted. There is no change to behavior, no bug fix, and no security relevance.
This is a database downgrade helper fix, not a live network vulnerability. Core Lightning's downgrade tool previously failed to strip out new 'channel impression' records when rolling a database back to version v26.06. The patch teaches th…
Database downgrade path could leave incompatible records in older schemaOffline tool only; no remote or on-chain triggerFix prevents potential node startup failure after version rollback
This commit fixes a typo in a database downgrade helper tool. The bug caused the tool to pass a negative number (turned into a huge positive size) when copying data, which led to an out-of-memory (OOM) error. The fix swaps two variable nam…
Integer underflow / negative-to-size_t wrap leading to excessive allocationOut-of-memory crash in maintenance toolMemory corruption potential if allocation somehow succeeded
This commit fixes a bookkeeping bug in Core Lightning's xpay plugin. Previously, when a payment succeeded, xpay did not tell the askrene routing-helper that the route worked. As a result, askrene kept stale or overly pessimistic ideas abou…
Missing success feedback to routing layer can degrade payment reliabilityStale negative impressions may bias future path selection toward worse or failing routesNo direct funds-loss primitive is introduced or fixed
This commit fixes a bug in Core Lightning's routing helper (askrene) where two kinds of channel information—hard limits called 'constraints' and usage estimates called 'impressions'—were being applied in the wrong order. Because impression…
Routing decision bug caused by incorrect ordering of time-relative channel statePotential payment failure or acceptance of an over-capacity routeRegression test added demonstrating incorrect route acceptance before fix
This commit fixes a memory leak in the askrene plugin of Core Lightning. When individual channel intelligence entries were deleted, the code removed the entry from its array but forgot to free two internal pointers (impression and constrai…
Memory leak in plugin data structure cleanupMissing deallocation of nested pointers before array removalFix located in routing/intelligence plugin (askrene)
This commit only updates test files so that automated checks expect slightly different error wording from the xpay payment command. It does not change any production code, so it cannot introduce a security vulnerability or fix one on its o…
This change tightens the lifetime of recurring invoices priced in foreign currencies (like USD) to 10 minutes by default, and refreshes them with current exchange rates when they expire. Previously, such invoices could remain valid for the…
Fixes stale exchange-rate exposure for currency-denominated recurring invoicesAdds configurable expiry cap for recurring currency invoicesDistinguishes user-cancellation (0s expiry) from natural expiry to avoid misleading errors
This commit tightens the expiration time on invoices created from BOLT12 offers. Previously, all such invoices defaulted to a 2-hour payment window. Now, if the offer has an absolute expiry, the invoice expires when the offer expires; and …
BOLT12 invoice expiry now bounded by offer absolute expiryCurrency-converted invoices use short expiry to limit exchange-rate exposureNew regression test added for expiry behavior
This commit removes local timing checks in Core Lightning's fetchinvoice plugin for recurring payments. Instead of the plugin refusing too-early or too-late invoice requests, it now lets the remote node decide and report back. The change i…
Removal of local input-validation checks for recurring invoice requestsReliance on remote-party enforcement for recurrence period limits and pay windowsTest expectations changed from local rejection to remote failure messages
This commit removes a local sanity check in Core Lightning's experimental 'createinvoicerequest' command. Previously, when creating a recurring invoice request, the code looked up past payments by label to verify the previous recurrence wa…
Removal of local payment-state validation for recurring invoice requestsParameter rename from recurrence_label to label in internal RPC callsTest expectations changed from local 'previous invoice has not been paid' errors to remote failure messages
This commit fixes how the fetchinvoice plugin handles user-supplied labels that contain special characters such as backslashes, quotes, tabs, and newlines. Previously these labels were passed as raw strings, which could cause JSON encoding…
JSON injection / improper escaping of user-controlled input passed between RPC componentsPotential mismatch between label parsing and label serialization leading to functional failures or unexpected behaviorFix is narrowly scoped to a single plugin and parameter
This commit only adds a new automated test file that checks how a helper function (str_to_u64) converts text strings to unsigned 64-bit integers. It does not change any production code, so it cannot by itself introduce a security vulnerabi…
This commit only adds a new pytest test file. It does not change any production code. The test describes desired future behavior for the askrene routing module's error messages when a payment source or destination lacks enough channel capa…
Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
Lower-prioritydocker: Added fixed SOURCE_DATE_EPOCH flag for reproducible Fedora buildby ShahanaFarooqui · ec7d247f · Jan 16, 2026 · 2 filesMessage 81 · StrongInformational 15Details
Commit message · ShahanaFarooqui
docker: Added fixed SOURCE_DATE_EPOCH flag for reproducible Fedora build
- Using environment variable `SOURCE_DATE_EPOCH` with fixed value will enforce a consistent timestamp for Fedora build. . Similar to Ubuntu fix in commit https://github.com/ElementsProject/lightning/commit/490fb0fc3b55284d47f8d391a7301c857e425b68 - Locked cargo version - Add `no-cache` to Fedora build
Changelog-Fixed: Core lightning builds for Fedora on all systems are deterministic.
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
AI analysis · Informational 15/100
This commit is a build-hardening change, not a security fix for a vulnerability. It makes Fedora release builds reproducible by pinning timestamps, locking the Rust compiler version, disabling a binary identifier that can vary between builds, and avoiding stale Docker cache. There is no indication it patches an exploitable flaw.
Lower-prioritycontrib: ignore cache when rebuilding docker builder imagesby Alex Myers · 9e490942 · Jan 16, 2026 · 1 fileMessage 65 · AdequateInformational 15Details
Commit message · Alex Myers
contrib: ignore cache when rebuilding docker builder images
This caused issues when dependencies were updated do to cached images continuing to be used.
Changelog-None
65/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
AI analysis · Informational 15/100
This change adds a Docker command-line flag that forces builder images to be rebuilt from scratch instead of reusing cached layers. It is a build-hygiene fix to avoid stale cached images after dependency updates. There is no security vulnerability here.
Lower-prioritydoc: Update installation instruction on Fedoraby ShahanaFarooqui · ae0e1087 · Jan 16, 2026 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · ShahanaFarooqui
doc: Update installation instruction on Fedora
45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit only updates the user documentation for installing Core Lightning on Fedora. It changes the recommended Fedora version from 27 to 39 and adds a few required build dependencies and tools (Rust, lowdown, PostgreSQL development files, etc.). There is no code change and no security issue in the commit itself.
Lower-prioritydocker: Update Fedora base image to 40by ShahanaFarooqui · 3f7565a3 · Jan 16, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · ShahanaFarooqui
docker: Update Fedora base image to 40
- Upgraded Fedora base image from 35 to 40. The existing Cargo failures were caused by the outdated Rust toolchain in Fedora 35. Cargo lockfile format v4 was introduced in Cargo 1.84 (December 2024), while Fedora 35 provides a Rust/Cargo version from roughly 2021–2022. As a result, the system Cargo could not parse modern Cargo.lock files, making it incompatible with current Rust projects.
- Added missing build dependencies to the Dockerfile, most notably the protobuf compiler (protoc).
Changelog-None: Upgraded Fedora version to 40 for reproducible build.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This commit updates a Fedora-based Docker builder image used for compiling Core Lightning. It moves from an old Fedora release (35) to a current one (40), adds missing build tools such as the protobuf compiler, and switches to a modern Rust toolchain via rustup so the build can understand newer Cargo lockfiles. There is no security flaw being fixed here; it is routine build-environment maintenance.
A bech32 address can be generated from a bip86 base so we should add both script types (p2wpkh, p2tr) to the txfilter for bip86 bases.
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Low 46/100
This change fixes a bug where Core Lightning's wallet scanner only watched for Taproot-style transactions for BIP86-derived keys, but missed ordinary SegWit v0 (P2WPKH) transactions. Because BIP86 keys can produce both address types, funds sent to a P2WPKH address derived from the same key would not be detected or credited. This is a correctness/loss-of-funds bug rather than an active theft vulnerability.
Security candidatehsmd: fix derivation for non-taproot addresses in modern mnemonic (25.12+) nodes.by Rusty Russell · 9b85ce7b · Jan 14, 2026 · 1 fileMessage 91 · StrongModerate 62Details
Commit message · Rusty Russell
hsmd: fix derivation for non-taproot addresses in modern mnemonic (25.12+) nodes.
This is a fix from https://github.com/rauaap who correctly diagnosed the problem:
``` Error broadcasting transaction: error code: -26\nerror message\nmempool-script-verify-flag-failed (Script failed an OP_EQUALVERIFY operation), input 0 of ... ```
The decision to use the changed derivation for all addresses, not just taproot, came up during review. Unfortunately, the signing code (here) was not changed to match the address generation code (in the wallet).
Reported-by: https://github.com/postanissue Fixes: https://github.com/ElementsProject/lightning/issues/8804 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: lightningd: we now correctly sign for non-taproot addresses given by nodes created by v25.12 or newer.
91/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundary
AI analysis · Moderate 62/100
This commit fixes a bug where Core Lightning nodes created with a modern mnemonic (version 25.12 or newer) could not correctly sign transactions that spend from non-Taproot on-chain addresses. The address generation code was updated to use a new key derivation method for all address types, but the signing code still only used that method for Taproot addresses. As a result, the private key used to sign did not match the public key in the address, causing transaction broadcast failures with an OP_EQUALVERIFY script error. The fix makes the signing code use the new derivation for all address types when the node uses the modern mnemonic format.
Security candidatelightningd: use BIP86 derivation for P2TR in HTLC rebroadcast change outputsby Sangbida Chaudhuri · 4b1f2a07 · Jan 14, 2026 · 1 fileMessage 50 · ThinLow 42Details
Commit message · Sangbida Chaudhuri
lightningd: use BIP86 derivation for P2TR in HTLC rebroadcast change outputs
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundary
AI analysis · Low 42/100
This change fixes how Core Lightning derives the public key used for 'change' outputs when rebroadcasting on-chain HTLC (Hashed Time-Locked Contract) transactions that pay to a Taproot (P2TR) address. Previously, the code always used the older BIP32 derivation even when the wallet was configured for the newer BIP86 Taproot-specific derivation. Using the wrong derivation path could produce a change output that the wallet does not recognize or cannot spend later, potentially locking up funds. The patch checks whether BIP86 is available and uses it for P2TR change outputs, falling back to BIP32 otherwise.
Lower-prioritylightningd: use BIP86 derivation in p2wpkh_for_keyidx when availableby Sangbida Chaudhuri · c1759037 · Jan 14, 2026 · 1 fileMessage 85 · StrongLow 31Details
Commit message · Sangbida Chaudhuri
lightningd: use BIP86 derivation in p2wpkh_for_keyidx when available
When a peer doesn't support OPT_SHUTDOWN_ANYSEGWIT, we fall back to P2WPKH for the shutdown script. For BIP86 wallets, we need to use bip86_pubkey for derivation (matching p2tr_for_keyidx), otherwise the resulting script won't be recognized after restart.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
AI analysis · Low 31/100
This change fixes a wallet bug in Core Lightning. When closing a payment channel with a peer that only supports older Bitcoin address formats, the software was deriving the refund address using the wrong key path for modern BIP86 wallets. After a restart, the wallet might not recognize those funds because it looks for keys at the BIP86 path. The patch makes the fallback address use the same derivation method as modern Taproot addresses, so the wallet can always find the funds.
Security candidatelightningd: use bip86 derivation for anchor spend change outputsby Sangbida Chaudhuri · fa96b601 · Jan 14, 2026 · 1 fileMessage 50 · ThinInformational 23Details
Commit message · Sangbida Chaudhuri
lightningd: use bip86 derivation for anchor spend change outputs
50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundary
AI analysis · Informational 23/100
This small change updates how Core Lightning creates the 'change' output when spending an anchor output in a Lightning channel. It now uses a newer, Taproot-specific key derivation method (BIP86) when available, instead of the older BIP32 method. The change itself is a correctness/hardening improvement for Taproot key handling, not a fix for an active exploit or a clearly disclosed vulnerability.
AI review queuedwallet: change dev_listaddrs to also list bip86 addressesby Sangbida Chaudhuri · e19fd5d6 · Jan 14, 2026 · 1 fileMessage 83 · StrongInformational 17Details
Commit message · Sangbida Chaudhuri
wallet: change dev_listaddrs to also list bip86 addresses
listaddrs is dev only and used in tests so it's okay if we change the API here, the usage is by positional arguments in tests so we're okay. Also changing est_option_upfront_shutdown_script to handle both old hsmsecret and the newer mnemonic one.
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 17/100
This is a small developer-only change to a wallet debugging command. It makes the internal `dev_listaddrs` tool also work with newer BIP86-style wallets (mnemonic/seed-based), instead of only older BIP32-style wallets. There is no direct evidence this fixes an exploitable security bug; it appears to be a compatibility/API improvement for tests.
AI review queuedwallet: use correct derivation for elements when using mnemonic hsm_secret.by Rusty Russell · 29465f52 · Jan 14, 2026 · 1 fileMessage 73 · AdequateModerate 57Details
Commit message · Rusty Russell
wallet: use correct derivation for elements when using mnemonic hsm_secret.
Even though we don't do taproot addresses on elements yet, use the same scheme for simplicity and for future when we *do* do taproot.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Moderate 57/100
This change fixes how Core Lightning derives Bitcoin/Elements addresses when creating change outputs or PSBT outputs from a wallet seed phrase (mnemonic). Previously, on Elements sidechains, the code derived the public key one way and then built a SegWit address from it directly. Now it uses a dedicated helper that follows the same derivation path used elsewhere (including the future Taproot path). The practical risk is that change outputs could have been sent to addresses the wallet did not fully recognize or could not later spend from, which can lock up funds.
AI review queuedlightning-hsmtool: fix dumponchaindescriptors for mnemonic hsm_secrets.by Rusty Russell · d2123a94 · Jan 14, 2026 · 2 filesMessage 73 · AdequateLow 29Details
Commit message · Rusty Russell
lightning-hsmtool: fix dumponchaindescriptors for mnemonic hsm_secrets.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: `lightning-hsmtool`: handle mnemonic hsm_secret files (nodes created >= v25.12).
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 29/100
This commit fixes a bug in the lightning-hsmtool utility's 'dumponchaindescriptors' command. For newer Core Lightning nodes created with a mnemonic seed (version 25.12 and later), the tool was deriving the wrong Bitcoin wallet descriptors, which would not match the actual on-chain addresses the node uses. The fix makes the tool follow the correct key derivation path for mnemonic-based secrets. It is a correctness/reliability bug rather than a remote-exploitable vulnerability, but it could cause users to generate incorrect backup descriptors and fail to recover or monitor funds.
lightningd: Fix penalty tx output derivation for BIP86 wallets
When using the new BIP39 mnemonic HSM secret format, the wallet uses BIP86 derivation for taproot addresses. However, onchaind_tx_unsigned() was always using bip32_pubkey() to derive the final key for penalty transaction outputs.
73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key material
AI analysis · Moderate 54/100
This fix corrects how Core Lightning derives wallet addresses used in penalty transactions when a newer BIP39-style secret is in use. Previously, the code always used the older BIP32 derivation even when the wallet was configured for BIP86 (taproot) addresses. That mismatch could cause penalty transaction outputs to be sent to addresses the wallet does not recognize or cannot spend, potentially making recovered funds inaccessible after a channel breach.
The recover command checks if a node has already issued bitcoin addresses before allowing recovery. This check only looked at bip32_max_index, but with BIP86 wallets, newaddr() increments bip86_max_index instead.
Also, the recover test asserted on hex but now it's asserting on codex32 instead. We should probably go in and fix the end point. @rustyrussell what do you think?
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
secret or key material
AI analysis · Low 34/100
This commit fixes the 'recover' command in Core Lightning so it correctly detects whether a wallet has already generated Bitcoin addresses. Previously, the check only looked at one counter used by older wallets, but a newer type of wallet (BIP86) uses a separate counter. As a result, a BIP86 wallet that had already issued addresses could wrongly be allowed to run recovery, which could overwrite or confuse wallet state. The fix adds the missing check.
wallet/hsmd: fix signmessagewithkey for BIP86 wallets
The signmessagewithkey RPC was failing for BIP86 (mnemonic-based) wallets because:
1. The wallet RPC was iterating through BIP32-derived addresses only, so it couldn't find BIP86-derived addresses.
2. The HSM's handle_bip137_sign_message always used bitcoin_key() (BIP32 derivation) regardless of wallet type.
85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
Why it was queued
secret or key materialsigning or wallet path
AI analysis · Low 28/100
This commit fixes a bug where the `signmessagewithkey` RPC command did not work for newer BIP86-style wallets. Previously, the wallet RPC only searched through older BIP32-derived addresses, and the HSM signing code always used BIP32 key derivation. The fix makes both the wallet lookup and the HSM signing aware of BIP86 derivation, so users can sign messages with keys from BIP86 wallets. This is a functionality bug, not a clear security vulnerability, but it could have caused user confusion or application failures.
AI review queuedaskrene: don't crash if refining flow which has capacity greaater than max it should have.by Rusty Russell · 35e703bf · Jan 14, 2026 · 1 fileMessage 81 · StrongLow 42Details
Commit message · Rusty Russell
askrene: don't crash if refining flow which has capacity greaater than max it should have.
Fixes: #8823 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: plugins: `askrene` can crash on a corner case in increase_flows.
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI analysis · Low 42/100
This patch fixes a crash in the `askrene` routing plugin for Core Lightning. In rare cases, the plugin's route-refinement logic could produce a payment flow that exceeded the estimated capacity of a path. The old code then called `abort()`, crashing the plugin. The fix replaces the crash with a warning log and a safe skip, so the node keeps running.
AI review queuedplugins/pay: don't crash if erring index is past route array end.by Rusty Russell · 9c6430c0 · Jan 14, 2026 · 1 fileMessage 81 · StrongModerate 60Details
Commit message · Rusty Russell
plugins/pay: don't crash if erring index is past route array end.
Reported-by: michael1011 Fixes: https://github.com/ElementsProject/lightning/issues/8828 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: plugins: `pay` can crash on errors returned from deep inside routehints.
81/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI analysis · Moderate 60/100
This commit fixes a crash in Core Lightning's `pay` plugin. When processing a payment failure, the plugin assumed that the reported error location was always within the known payment route. In some cases—likely involving multi-hop route hints—the reported index could be larger than the route array, causing an assertion failure that killed the plugin and, because the plugin is marked as important, shut down the entire `lightningd` node. The fix replaces the crash with a safe early return.
Security candidatepytest: don't record IO when we kill nodesby Rusty Russell · c10c54ff · Jan 14, 2026 · 2 filesMessage 78 · AdequateInformational 15Details
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
78/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundary
AI analysis · Informational 15/100
This change only adjusts two test cases so they no longer save plugin input/output logs before deliberately crashing a test node. It fixes flaky test failures where reading a partially-written JSON file produced a decode error. It does not change any production code or affect real users.
Lower-prioritypytest: fix flake in test_gossip_query_channel_rangeby Rusty Russell · b0f8077e · Jan 14, 2026 · 1 fileMessage 83 · StrongInformational 15Details
Commit message · Rusty Russell
pytest: fix flake in test_gossip_query_channel_range
If l4 sends a WIRE_QUERY_SHORT_CHANNEL_IDS at the wrong time, we will get that and be upset the response is wrong:
``` 2026-01-13T14:45:55.9059786Z E AssertionError: assert ['010806226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f00000000000f42400100110000006800000100000000690000010000', '010506226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f001100000068000001000000006900000100000103000402'] in (['010806226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f00000000000f42400100110000006800000100000000690000010000'], ['010806226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f00000000000f42400100110000006900000100000000680000010000']) 2026-01-13T14:45:55.9063357Z 2026-01-13T14:45:55.9063527Z tests/test_gossip.py:762: AssertionError ```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
AI analysis · Informational 15/100
This commit fixes a flaky test in Core Lightning's test suite. A test about gossip protocol messages sometimes failed because another node would send an unexpected extra message type during the test. The fix adds that message type to the list of messages the test should ignore, making the test more reliable. There is no security issue in the actual Lightning node software.
Lower-prioritylightningd: fix bogus memleak report.by Rusty Russell · fd64bb11 · Jan 14, 2026 · 2 filesMessage 76 · AdequateInformational 19Details
Commit message · Rusty Russell
lightningd: fix bogus memleak report.
We do our own leak detection on a reply from a subd, but the reply code set subd->conn to NULL (saving it temporarily, in case the subd is freed), resulting in it being seen as a leak:
The workaround is to do our own leak detection on a timer (making the conn notleak() would leave us open to a real leak in future!).
We also move the `struct leak_detect` definition inside the C file where it belongs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
76/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
AI analysis · Informational 19/100
This commit fixes a false alarm in Core Lightning's internal memory-leak checker. When the node asked a sub-process to report its memory usage, the reply handling briefly set aside a connection pointer, making the leak detector wrongly report that connection as leaked. The fix delays the final leak check until after the reply handling is finished, so the temporary pointer state is no longer visible. It is a diagnostic/robustness fix, not a security vulnerability fix, and does not create a way for an attacker to exploit the node.
Lower-prioritypytest: fix reconnect flake in test_route_by_old_scidby Rusty Russell · 8d807be6 · Jan 14, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · Rusty Russell
pytest: fix reconnect flake in test_route_by_old_scid
We restart l2, then try to connect to l1. But l1 will be trying to reconnect (and it can, since it was initially given l2's address), so it can race us and we end up disconnecting because of simultaneous connect:
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
AI analysis · Informational 15/100
This is a one-line change to a test file that fixes an occasional test failure (a 'flake'). It swaps which test node initiates a connection after a restart to avoid a race where both nodes try to connect to each other at the same time. It does not change any production code or fix a security bug.
Lower-prioritypytest: disable autoreconnect on test_sql to avoid reconnect race.by Rusty Russell · 84afe579 · Jan 14, 2026 · 3 filesMessage 95 · StrongInformational 13Details
Commit message · Rusty Russell
pytest: disable autoreconnect on test_sql to avoid reconnect race.
Because l1 and l3 allow localhost as a broadcastable address, they can try to reconnect. Disable reconnections, so we don't race:
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
AI analysis · Informational 13/100
This commit is a test-only fix. It changes three test files to make automated tests more reliable: it disables automatic reconnections in one test to avoid a timing race, fixes a typo in a log message another test waits for, and adds a short sleep in a third test. There is no change to the actual Core Lightning node software that users run, so it does not affect real network security.
Lower-prioritypytest: don't rely on sleep to ensure wait commands have been submitted.by Rusty Russell · 3be25d48 · Jan 14, 2026 · 6 filesMessage 95 · StrongInformational 15Details
Commit message · Rusty Russell
pytest: don't rely on sleep to ensure wait commands have been submitted.
Seems like sleep(1) isn't always enough. Give in and put a log message there, and use that:
waitres = waitfut.result(TIMEOUT) > assert waitres == {'subsystem': 'forwards', 'deleted': 1, 'forwards': {'in_channel': scid12, 'in_htlc_id': 1, 'status': 'failed'}} E AssertionError: assert {'subsystem': 'forwards', 'deleted': 1} == {'subsystem': 'forwards', 'deleted': 1, 'forwards': {'in_channel': '103x2x0', 'in_htlc_id': 1, 'status': 'failed'}} E E Common items: E {'deleted': 1, 'subsystem': 'forwards'} E Right contains 1 more item: E {'forwards': {'in_channel': '103x2x0', 'in_htlc_id': 1, 'status': 'failed'}} E E Full diff: E { E 'deleted': 1, E - 'forwards': { E - 'in_channel': '103x2x0', E - 'in_htlc_id': 1, E - 'status': 'failed', E - }, E 'subsystem': 'forwards', E }
tests/test_misc.py:3599: AssertionError ```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
AI analysis · Informational 15/100
This commit fixes flaky automated tests, not the Core Lightning server itself. The tests were using a one-second sleep to guess that a background 'wait' command had been submitted, but sometimes the command wasn't ready in time and the test would fail. The patch adds a log line when a wait command is registered and changes the tests to wait for that log line instead of sleeping. There is no security fix here.
Lower-prioritypytest: another flake in test_important_plugin.by Rusty Russell · c0c88549 · Jan 14, 2026 · 1 fileMessage 68 · AdequateInformational 15Details
Commit message · Rusty Russell
pytest: another flake in test_important_plugin.
There's one more complaint we can see when plugins get upset:
``` lightningd-1 2026-01-12T06:10:49.317Z **BROKEN** plugin-cln-xpay: askrene-create-layer failed with {"code":-4, "message":"Plugin terminated before replying to RPC call."} ```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
AI analysis · Informational 15/100
This commit is a one-line change to a test file. It adds another expected log message to a test that already tolerates several 'broken' log lines when a node is deliberately started with a missing important plugin. There is no change to production code, no security fix, and no vulnerability.
Lower-prioritydoc: Update docs to reflect new hsm secret formatby Sangbida Chaudhuri · b219214a · Jan 14, 2026 · 2 filesMessage 60 · AdequateInformational 15Details
Commit message · Sangbida Chaudhuri
doc: Update docs to reflect new hsm secret format
Changelog-Changed - Updated backup and hsm secret docs to reflect mnemonic based hsm secret
60/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body
Why it was queued
documentation-only discount
AI analysis · Informational 15/100
This commit only updates user documentation to describe a new mnemonic-based backup format for Core Lightning's wallet secret. It does not change any code, commands, or security behavior. There is no security vulnerability here.
