CommitWatch RSS
EP
← All projectsElements Project

Core Lightning

Modular C implementation of the Lightning Network protocol and node stack.

BitcoinLightning NetworkNormal
Source repository ↗
Repository coverage

1853 commits in the local evidence base

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.

158security candidates263second-pass queue197AI analyses
146commits · 30 days
225commits · 60 days
803commits · 180 days
1849commits · 365 days
Backfill bands
Aug 5 → Feb 61049 seen37 candidatesComplete
Feb 6 → Jun 6579 seen10 candidatesComplete
Jun 6 → Jul 678 seen1 candidatesComplete
Jul 6 → Aug 5147 seen16 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

70/100 average clarity
430Strong · 80–100
1163Adequate · 60–79
231Thin · 40–59
29Opaque · 0–39
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Rusty Russell9587395072
Sangbida Chaudhuri1463139066
Dusty Daemon771313066
ShahanaFarooqui931010063
daywalker908957062
Níckolas Goline4057076
Lagrang37644069
Christian Decker3645072
Vincenzo Palazzo833080
Chandra Pratap5624082
ekzyis222063
Peter Neuroth9711070
Analysis record

Published AI watches

Last scanned 51 minutes ago

Informational 17 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

lightningd: internal cleanups since all non-command JSON IDs are strings.

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
a70ae963by Rusty Russell+25−378 files
No security note in commit
Open full analysis →Source commit ↗
Informational 23 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

downgrade: we need to remove "impressions" from askrene datastore when downgrading to v26.06.

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
4d926285by Rusty Russell+43−111 file
No security note in commit
Open full analysis →Source commit ↗
Low 31 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

downgrade tool: fix invalid memory bug

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
42995326by Lagrang3+8−81 file
No security note in commit
Open full analysis →Source commit ↗
Informational 16 AI analysisMessage 90 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

add a test for downgrading askrene datastore

This commit adds a regression test for Core Lightning's database downgrade path. It ensures that when a user downgrades from an upcoming v26.09 release to an older version (v26.06), the new 'impressions' data added by the askrene routing s…

Database downgrade path for new askrene schema (impressions table)Regression test only; no production code changeNo input validation, cryptography, network, or authorization changes
1818553eby Lagrang3+156−13 files
No security note in commit
Open full analysis →Source commit ↗
Low 25 AI analysisMessage 65 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

lightning-hsmtool: Fix getsecret does not show mnemonic after typing passphrase

This is a bug fix in a command-line helper tool used by Core Lightning node operators. The `getsecret` command was accidentally refusing to show the wallet recovery words (mnemonic) when the wallet was protected by a passphrase. After the …

Functional bug in secret-recovery pathError path blocked legitimate mnemonic recoveryNo input validation, memory-safety, or cryptographic change
8480f6c2by ekzyis+1−21 file
No security note in commit
Open full analysis →Source commit ↗
Informational 12 AI analysisMessage 60 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: add regression test for hsmtool commands with passphrase

This commit only adds and updates a regression test in the project's test suite. It checks that the hsmtool utility correctly handles both empty and non-empty passphrases when working with BIP39 mnemonic-based wallet secrets. There is no c…

Regression test added for passphrase handling in hsmtoolNo production code changes observedTest-only change to tests/test_wallet.py
8c42be35by ekzyis+47−201 file
No security note in commit
Open full analysis →Source commit ↗
Low 33 AI analysisMessage 76 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wally: update libwally to v1.5.6

This commit updates the bundled libwally library to version 1.5.6. The practical effect is that calling the JSON-RPC `signpsbt` command on a PSBT that is already signed now succeeds as a harmless no-op, instead of returning an error on Bit…

Dependency update to incorporate upstream bug fixBehavior change from error to no-op on re-signing signed PSBTsTaproot keypath handling change in upstream cryptographic library
37526ca4by daywalker90+7−82 files
No security note in commit
Open full analysis →Source commit ↗
Low 31 AI analysisMessage 85 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: make datastore helpers self-wrap a wallet transaction

This change fixes a crash bug in Core Lightning's wallet datastore helpers. Previously, four datastore functions required the caller to already be inside a database transaction, and would fatally crash if called outside one. The patch make…

Fixes fatal assertion/crash in database statement preparationResolves transaction-context mismatch in wallet datastore helperswatchman plugin persistence path was affected
ae1a3347by Sangbida Chaudhuri+23−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 24 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: handle bwatch wallet/utxo spend notifications

This commit adds the missing bookkeeping that runs when Core Lightning's own on-chain wallet spends a UTXO. It makes the node mark the UTXO as spent, record the spending transaction, and log a withdrawal coin movement. It also handles bloc…

Missing spend tracking for wallet-owned UTXOs could lead to stale UTXO state or incorrect coin-movement accountingReorg handling clears spendheight, preventing a spent output from becoming permanently unspendable in the wallet's viewDefensive log_broken calls on unexpected missing UTXO or malformed watch suffix
4ba051caby Sangbida Chaudhuri+149−03 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 54 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: handle reorgs for our_outputs/our_txs by hand

This commit fixes how Core Lightning's wallet records handle blockchain reorganizations (reorgs) for two newer database tables, our_outputs and our_txs. Previously, these tables were not properly updated when blocks were removed or rolled …

Incorrect state persistence across blockchain reorgsMissing reorg handling for wallet tables without foreign-key cascadePotential stale spend/confirmation metadata in our_outputs/our_txs
bcdea215by Sangbida Chaudhuri+40−01 file
No security note in commit
Open full analysis →Source commit ↗
Low 34 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: read UTXO state from our_outputs

This commit switches Core Lightning's wallet code to read UTXO (unspent transaction output) data from a new database table called our_outputs instead of the older outputs table. It also deletes several old helper functions and updates test…

Large internal data-model migration with reader/writer split between old and new tablesDual-write mirroring to legacy outputs table for downgrade compatibilityDeletion of legacy UTXO reading helpers
0a10e74eby Sangbida Chaudhuri+433−5772 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: rename b32script to scriptpubkey in PSBT change paths

This commit is a simple variable rename inside a Bitcoin/Lightning wallet file. The old name 'b32script' suggested all change addresses were bech32 format, but the project now uses a newer address type (p2tr) by default. The developer rena…

b8a60579by Sangbida Chaudhuri+12−141 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 83 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: update test_wallet.py raw-SQL queries for our_outputs

This commit only updates internal test code to query a new database table (our_outputs) instead of an old one (outputs). It does not change the actual wallet or node software that users run, so it cannot directly affect security.

d14ee378by Sangbida Chaudhuri+31−281 file
No security note in commit
Open full analysis →Source commit ↗
Low 44 AI analysisMessage 78 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: register scriptpubkey watches at startup

This change makes Core Lightning register long-lasting 'watches' for all wallet deposit addresses when the node starts up, so the new bwatch plugin can spot incoming payments from the first block it scans. It also removes a now-redundant p…

Change is part of an experimental chain-watcher (bwatch) featureAdds startup registration of scriptPubKey watches for all derived wallet keysRemoves a redundant unconfirmed-change watch, relying on the new blanket coverage
4a951d65by Sangbida Chaudhuri+89−114 files
No security note in commit
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: dual-write chaintopology UTXO changes into our_outputs

This is a database refactoring commit in Core Lightning. It makes the wallet write UTXO (unspent transaction output) state to a new table called our_outputs in addition to the legacy outputs table, while reads still use the old table. The …

Database schema migration with dual-write mirror patternNo security claim in commit title or messageNo CVE, advisory, or researcher attribution in commit metadata
824e8195by Sangbida Chaudhuri+118−162 files
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: record bwatch-discovered wallet outputs

This commit adds new wallet bookkeeping code for Core Lightning. It records Bitcoin deposits found by a new chain-watcher ('bwatch') into database tables and handles blockchain reorganizations by demoting transactions back to unconfirmed r…

New database write paths for wallet UTXOs and transactionsReorg revert logic demotes rather than deletes rows to preserve metadataOwner-string constructors added to avoid silent unwatch failures from format mismatches
bc021011by Sangbida Chaudhuri+543−07 files
No security note in commit
Open full analysis →Source commit ↗
Low 32 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: route transaction reads/writes through our_txs

This commit changes how Core Lightning stores and reads wallet-related transactions. It moves most reads to a new table called our_txs while still keeping the old transactions table updated for compatibility. The main concern is that the c…

Dual-write consistency risk between our_txs and legacy transactions tableNew anti-downgrade logic for confirmed transactions in our_txsRemoval of legacy NULL handling for unconfirmed transactions
2c1ab4d0by Sangbida Chaudhuri+89−642 files
No security note in commit
Open full analysis →Source commit ↗
Informational 18 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: add our_outputs + our_txs schema migrations

This commit only adds two new empty database tables (our_outputs and our_txs) to Core Lightning's wallet. It is a preparatory schema change for a future feature; no code reads from or writes to these tables yet, and no existing behavior is…

Schema-only migration with no runtime codeNew tables are not yet populated or queried by any code pathDesign note: sentinel 0 replaces NULL for blockheight/txindex/reserved_til, which could reduce NULL-handling bugs in future code
ea4d1fcaby Sangbida Chaudhuri+38−01 file
No security note in commit
Open full analysis →Source commit ↗
Low 28 AI analysisMessage 70 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: add migrate_backfill_bwatch_tables

This commit adds a database migration that copies existing wallet data into new tables used by an upcoming 'bwatch' wallet component. It is a data backfill, not a code fix for an active vulnerability. The main risk is that if the migration…

Database migration touching wallet UTXO and transaction tablesPotential for data inconsistency if mapping logic is wrongON CONFLICT DO NOTHING prevents overwrite but could hide duplicate-key anomalies
2e23893bby Sangbida Chaudhuri+513−04 files
No security note in commit
Open full analysis →Source commit ↗
Low 27 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: mirror bwatch writes into legacy outputs table

This change is a behind-the-scenes bookkeeping patch for Core Lightning's wallet database. The project is moving to a new table (`our_outputs`) for tracking spendable coins, but older versions of the software still read from the old table …

Race-condition guard for foreign-key-backed confirmation_height and spend_height when bwatch is ahead of chaintopologyTemporary mirroring to keep legacy outputs table consistent with new our_outputs tableON CONFLICT DO NOTHING used for legacy insert to avoid duplicate-key failures
bba68e0aby Sangbida Chaudhuri+101−62 files
No security note in commit
Open full analysis →Source commit ↗
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Security candidatecommon: remove tal_check() call on libwally allocations.by Rusty Russell · 48c3df91 · Nov 3, 2025 · 1 fileMessage 83 · StrongInformational 19Details
Commit message · Rusty Russell

common: remove tal_check() call on libwally allocations.

We call it once at the end, but calling on each allocation is
excessive, and it shows when dealing with large PSBTS. Testing a
700-input PSBT was unusably slow without this: after this the entire
test ran in 9 seconds.

Changelog-Fixed: JSON-RPC: Dealing with giant PSBTs (700 inputs!) is now much faster.
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
Why it was queued
signing boundary
AI analysis · Informational 19/100

This change removes a repeated internal sanity check that was making very large Bitcoin transaction templates (PSBTs with hundreds of inputs) extremely slow to process. It is a performance fix, not a security fix. The remaining single check at the end still catches the same class of problems, just less frequently.

Security candidatehsmd/libhsmd: add BIP86 base-keyby Sangbida Chaudhuri · 63001745 · Oct 26, 2025 · 4 filesMessage 68 · AdequateLow 33Details
Commit message · Sangbida Chaudhuri

hsmd/libhsmd: add BIP86 base-key

BIP86 wants the full 64-byte BIP32 seed (from BIP39). This wires up BIP86
support so the HSM derives the hardened base m/86'/0'/0' inside the box,
and exposes helpers:
• derive_bip86_base_key() // m/86'/0'/0'
• bip86_key(index) // m/86'/0'/0'/0/index

Spoiler: derive_bip86_base_key() and bip86_key() now live in libhsmd.c as they will later be used to check the derived wallet address against hsmd's derivation, this is just to sanity check that we haven't had an accidental bit flip while we have generated this address.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key materialdefensive validation
AI analysis · Low 33/100

This commit adds support for deriving Bitcoin BIP86-style keys inside Core Lightning's Hardware Security Module (HSM) daemon. It introduces two new wire messages that let authorized clients ask the HSM to derive a BIP86 base key and to check whether a public key matches the HSM's own derivation. The commit also adds a new permission bit controlling access to these messages. There is no direct evidence in the commit that this fixes an active vulnerability; it reads as feature work to support a new wallet/key derivation path, with a sanity-check helper to catch accidental derivation mismatches.

Security candidatewallet: update wallet address generation logic to use unified BIP86/BIP32 approachby Sangbida Chaudhuri · 620eb080 · Oct 26, 2025 · 6 filesMessage 73 · AdequateLow 33Details
Commit message · Sangbida Chaudhuri

wallet: update wallet address generation logic to use unified BIP86/BIP32 approach

Simplify wallet address generation by using a unified approach where
the derivation method (BIP86 vs BIP32) is determined by the wallet's
HSM secret type rather than having separate address types.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key materialsigning or wallet path
AI analysis · Low 33/100

This commit refactors how Core Lightning generates wallet addresses. Instead of keeping two separate address types (legacy BIP32 and mnemonic-based BIP86), it now picks the derivation method based on the wallet's HSM secret type. The change removes the special 'bip86' address type from RPCs and unifies address generation. It also fixes a memory leak by freeing a temporary TLV structure. There is no direct evidence in the commit of a security vulnerability being patched, but the change touches key-derivation logic and could affect fund recoverability if implemented incorrectly.

Security candidatehsmd_wire: add HSM wire protocol support for secret type detectionby Sangbida Chaudhuri · 266b8082 · Oct 26, 2025 · 8 filesMessage 73 · AdequateInformational 19Details
Commit message · Sangbida Chaudhuri

hsmd_wire: add HSM wire protocol support for secret type detection

Add TLV field to hsmd_init_reply_v4 to communicate the HSM secret type
(mnemonic vs legacy) from HSM to lightningd. This allows lightningd to
automatically determine whether to use BIP86 or BIP32 derivation without
needing separate address types.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key materialsigning or wallet path
AI analysis · Informational 19/100

This commit adds a small metadata field to the internal HSM (Hardware Security Module) initialization message so that lightningd can tell whether the wallet seed was created from a mnemonic phrase or from an older legacy secret. It is a protocol plumbing change, not a fix for a known vulnerability, and does not by itself change how secrets are generated, stored, or protected.

Security candidatetest: Add a psbt test and an index boundary testby Sangbida Chaudhuri · c7f36951 · Oct 26, 2025 · 1 fileMessage 67 · AdequateInformational 15Details
Commit message · Sangbida Chaudhuri

test: Add a psbt test and an index boundary test

67/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit only adds two new automated tests to the project's test suite. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The tests verify that BIP86 (a type of Bitcoin taproot wallet address) behaves correctly when generating many addresses and when used in transaction signing workflows.

Security candidatehsmd: find correct P2TR key for utxoby Sangbida Chaudhuri · 1b3e881d · Oct 26, 2025 · 4 filesMessage 68 · AdequateLow 42Details
Commit message · Sangbida Chaudhuri

hsmd: find correct P2TR key for utxo

In the case where we receive a taproot utxo we want to be able to tell if it was derived using a BIP32 seed or a BIP86 seed. Considering we will only be supporting BI86 type wallet addresses for mnemonics we can check if the out secret is 64 bytes long and if it is we can use our BIP86 for the withdrawal.

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key material
AI analysis · Low 42/100

This commit fixes a bug in Core Lightning's HSM (Hardware Security Module daemon) where the wrong private key could be derived when spending a taproot (P2TR) UTXO. Previously, the code always used the older BIP32-style derivation for taproot UTXOs. After the change, it checks whether the UTXO was actually created using the newer BIP86 derivation path (used with mnemonic-based wallets) and, if so, derives the correct key. If the wrong key is used, the node would be unable to sign a transaction spending that UTXO, effectively locking the funds until the bug is fixed. There is no direct evidence in the commit or supplied references that this was a security vulnerability exploitable by an attacker; it appears to be a correctness/functional bug.

Security candidatedoc: change encrypted-hsm to hsm-passphraseby Sangbida Chaudhuri · 5f67e7dd · Oct 26, 2025 · 1 fileMessage 45 · ThinInformational 15Details
Commit message · Sangbida Chaudhuri

doc: change encrypted-hsm to hsm-passphrase

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
access controldocumentation-only discount
AI analysis · Informational 15/100

This commit only updates the user manual documentation for the Core Lightning node software. It renames the documented configuration option from 'encrypted-hsm' to 'hsm-passphrase' and explains how passphrases now work with both old-style encrypted secrets and new BIP39 mnemonic-based seeds. No program code was changed, so this cannot introduce or fix a security vulnerability by itself.

Security candidatelightningd: store base and derive pubkeys locallyby Sangbida Chaudhuri · 16656652 · Oct 26, 2025 · 7 filesMessage 80 · StrongInformational 11Details
Commit message · Sangbida Chaudhuri

lightningd: store base and derive pubkeys locally

RIP to this commit there's a good chance a lot of this code doesn't even make this into the final PR. Pour one out for the fallen lines of code.

This commit is doing the rest of the derivation. There was a significant overlap between the bip32_pubkey derivation and the bip86_pubkey derivation so that has been refactored in one place.

80/100 · StrongMessage clarity
✓ 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 · Informational 11/100

This commit adds experimental support for deriving Bitcoin public keys using the BIP86 standard inside Core Lightning. It stores a new base key locally in the main daemon and adds a command-line option to turn the feature on. The change also removes a dedicated HSM permission flag for BIP86 derivation, folding it into existing capability checks. There is no clear security bug in the diff, but the commit message says much of the code may not survive review, so it looks like unfinished work-in-progress.

Security candidatecommon: add unified HSM secret handling moduleby Sangbida Chaudhuri · 9977b72e · Oct 26, 2025 · 3 filesMessage 68 · AdequateInformational 11Details
Commit message · Sangbida Chaudhuri

common: add unified HSM secret handling module

This is a newer API to replace hsm_encryption.c and hsm_encryption.c, this tidies up the API to be used and also cleans things up to support our new formats. Our hsm_secret formats now include:
- Legacy 32-byte plain format
- Legacy 73-byte encrypted format
- New mnemonic format without passphrase (32 zero bytes + mnemonic)
- New mnemonic format with passphrase (32-byte hash + mnemonic)

This commit includes support to detect the format based on the file size and content structure. The hsm will store mnemonics in the hsm_secret file as:

`passphraseHash`mnemonic`

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
access control
AI analysis · Informational 11/100

This commit adds a new internal module for handling the secret key file used by Core Lightning's hardware security module (HSM). It introduces support for reading the existing plain and encrypted formats, plus new formats based on BIP39 word lists (mnemonics) with optional passphrases. The code uses modern password hashing (Argon2) and authenticated encryption (libsodium secretstream). There is no direct evidence in the commit that this fixes a known security vulnerability; it appears to be a feature/refactoring change to support new wallet backup formats.

Security candidatehsmd/libhsmd: change hsmd_init to have secret_data and secret_lenby Sangbida Chaudhuri · fc981f4d · Oct 26, 2025 · 3 filesMessage 73 · AdequateInformational 18Details
Commit message · Sangbida Chaudhuri

hsmd/libhsmd: change hsmd_init to have secret_data and secret_len

hsmd: plumb length-aware secret into hsmd_init; keep 32B mirror

BIP86 (from BIP39) wants the full 64-byte BIP32 seed. This commit plumbs a variable-length (32/64B) secret into hsmd and uses the accessors from the previous commit. We keep the old 32B hsm_secret mirror and, for now, only use the first 32 bytes so legacy paths keep working.

Spoiler: HKDFs will keep using the 32B seed; only wallet address derivation
will switch to the full 64B in a follow-up.

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 · Informational 18/100

This is a preparatory code change for Core Lightning's HSM (the component that holds private keys). It changes an internal function so it can accept either a 32-byte or 64-byte root secret, keeping the existing 32-byte behavior intact. The commit itself does not change how keys are actually derived or fix any known vulnerability; it is plumbing for a future feature (BIP86 wallet addresses).

Security candidatecommon: refactor hsm_secret to {secret_data,len,type}by Sangbida Chaudhuri · 0192b82e · Oct 26, 2025 · 2 filesMessage 73 · AdequateInformational 12Details
Commit message · Sangbida Chaudhuri

common: refactor hsm_secret to {secret_data,len,type}

BIP86 derivation requires the full 64-byte seed that comes from the BIP39 mnemonic. The first 32 bytes goes towards to master seed material and the nest 32 bytes go towards the chaincode, so we need the entire 64 bytes for deterministic derivations. I've kept the old secret struct in for now for backwards compatibility and also added some accessors which will eventually die in this branch's git multiverse but that's a spoiler, they're on the ride for the next few commits at least to help us migrate to this length aware API throughout the rest of the code without making a lot of breaking changes.

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 · Informational 12/100

This commit is a code refactor in Core Lightning's wallet secret handling. It changes how the HSM (Hardware Security Module-like) secret is stored internally so it can hold either the traditional 32-byte secret or a full 64-byte seed derived from a BIP39 mnemonic. It keeps the old 32-byte field for backward compatibility and adds helper functions to read the secret. There is no security fix or vulnerability being patched here.

Security candidateexposesecret: Add support for mnemonic-based HSM secretsby Sangbida Chaudhuri · de9c6305 · Oct 26, 2025 · 13 filesMessage 73 · AdequateInformational 15Details
Commit message · Sangbida Chaudhuri

exposesecret: Add support for mnemonic-based HSM secrets

Update the exposesecret plugin to work with the new unified HSM secret
format that supports BIP39 mnemonics.

Changelog-Added - exposesecret now has a mnemonic field

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 · Informational 15/100

This commit adds a new feature to the Core Lightning 'exposesecret' plugin. It allows users who have set up their node with a BIP39 mnemonic (a human-readable seed phrase) to retrieve that mnemonic through the plugin's API. The change also includes some internal cleanup for how mnemonic secrets are handled and converted into cryptographic seeds. There is no indication in the commit that this fixes a security vulnerability; it is a feature addition.

Security candidatehsmd: add BIP86 wire scaffolding (derive/check), no behavior yetby Sangbida Chaudhuri · 121fcfc9 · Oct 26, 2025 · 3 filesMessage 73 · AdequateInformational 15Details
Commit message · Sangbida Chaudhuri

hsmd: add BIP86 wire scaffolding (derive/check), no behavior yet

Here's some *foreshadowing* for what's to come. Here's what we're aiming for with our derivation flow:

Derivation split (hardened vs unhardened)
========================================

┌───────────────┐
│ HSM │ (secrets live here)
│ │
│ BIP39 → seed (64B)
│ ↓
│ m/86'/0'/0' ← derive hardened base (private)
│ ↓ (neuter)
│ BIP86 base xpub ← public-only + chain code
│ ↓
│ [send once over wire]
└───────────────┘
│
▼
┌───────────────────────┐
│ lightningd / wallet │
│ │
│ local (unhardened) derivations:
│ /0/i → external
│ /1/i → change
│ │
│ P2TR(BIP86) from pubkey_i
│ (optionally: CHECK with HSM)
└───────────────────────┘

We want to do part of the derivation inside hsmd and then send this base "pubkey" over the wire so our wallet can do the remaining derivation based on the address type and index. This lays the foundation for the base key wire message.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
secret or key materialdefensive validation
AI analysis · Informational 15/100

This commit only adds placeholder message types and stubs for a future BIP86 key-derivation feature. The new wire messages return an explicit 'not implemented yet' error and perform no actual key derivation, signing, or secret handling. There is no active security issue in this patch itself.

Security candidatehsmd: take the passphrase raw, not the derived secret.by Sangbida Chaudhuri · e3fe739f · Oct 26, 2025 · 7 filesMessage 73 · AdequateLow 35Details
Commit message · Sangbida Chaudhuri

hsmd: take the passphrase raw, not the derived secret.

In preparation for BIP-39, we need to hand the passphrase (if any) to HSMD.

So we extend the hsmd wire protocol to allow that.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
access controlsigning or wallet path
AI analysis · Low 35/100

This commit changes how Core Lightning's main daemon (lightningd) sends an HSM passphrase to the separate HSM daemon (hsmd). Previously, lightningd derived an encryption key from the passphrase locally and sent that derived key to hsmd. Now it sends the raw passphrase inside a new optional protocol field (a TLV extension), and lets hsmd derive the key itself. The change is framed as preparation for BIP-39 mnemonic support. It is a protocol and internal API change, not a clear-cut security fix, but it does alter where the passphrase is handled and how it travels between processes.

Security candidatelightningd: scan outputs for BIP86 addressesby Sangbida Chaudhuri · 249fa036 · Oct 26, 2025 · 4 filesMessage 80 · StrongLow 42Details
Commit message · Sangbida Chaudhuri

lightningd: scan outputs for BIP86 addresses

This commit fixes an issue where BIP86 addresses were not being
discovered during wallet recovery/rescan operations.

The root cause was that init_txfilter() only populated the transaction
filter with BIP32-derived keys, preventing lightningd from recognizing
BIP86 UTXOs during blockchain scans. Now both BIP32 and BIP86 derived
scripts are included in the filter when BIP86 derivation is enabled.

This ensures that wallets restored from BIP39 mnemonics can properly
discover and display previously funded BIP86 addresses without requiring
manual address generation first.

[ We also move the slightly-lost comment about libbacktrace so it is
where we actually include <backtrace.h> --RR ]

80/100 · StrongMessage clarity
✓ 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 42/100

This commit fixes a wallet-recovery bug in Core Lightning. When a user restored a wallet that used BIP86 (a modern Bitcoin address type), the node failed to scan the blockchain for those addresses, so previously received funds would appear missing until the user manually generated an address. The patch makes the rescan process look for both BIP32 and BIP86 addresses.

Security candidatehsmd: use the new mnemonic-compatible hsm_secret routines.by Sangbida Chaudhuri · 218dc2fe · Oct 26, 2025 · 11 filesMessage 73 · AdequateLow 33Details
Commit message · Sangbida Chaudhuri

hsmd: use the new mnemonic-compatible hsm_secret routines.

Changelog-Changed: hsmd: New nodes will now be created with a BIP-39 12-word phrase as their root secret.
Changelog-Deprecated: config: `encrypted-hsm` to require a passphrase (use `hsm-passphrase`).
Changelog-Added: config: `hsm-passphrase` indicates we should use a manual passphrase with the hsm secret.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Why it was queued
access controlsigning or wallet path
AI analysis · Low 33/100

This commit changes how Core Lightning's Hardware Security Module daemon (hsmd) creates and stores the master secret for new nodes. Instead of a raw 32-byte random secret (optionally encrypted with a password-derived key), new nodes now get a 12-word BIP-39 mnemonic phrase as their root secret, with an optional passphrase. The old --encrypted-hsm option is deprecated in favor of --hsm-passphrase. The change is a feature redesign of key storage, not a fix for a known exploitable bug, but it touches critical cryptographic material and removes legacy encrypted-secret handling.

Security candidatewallet: make sure to watch all txids in transactions table.by Rusty Russell · 478a0d57 · Oct 24, 2025 · 5 filesMessage 85 · StrongInformational 24Details
Commit message · Rusty Russell

wallet: make sure to watch all txids in transactions table.

We watch if they are to do with a channel, or have outputs going to us, but otherwise
we didn't, so we never updated the blockheight in the db.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: JSON-RPC: `listtransactions` now correctly updates `blockheight` for txs created by `sendpsbt` which have no change outputs.

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
signing boundarysigning or wallet path
AI analysis · Informational 24/100

This commit fixes a bookkeeping bug in Core Lightning's wallet. When a user broadcast a transaction created with `sendpsbt` that had no change output coming back to the node, the node did not track the transaction's confirmation status. As a result, `listtransactions` would never show the correct `blockheight` for that transaction. The fix makes the node explicitly watch all unconfirmed transactions in its database so their confirmation height gets updated. There is no direct security exploit here; it is a data-correctness and user-experience issue.

Security candidatepytest: add test that we notice height change of sendpsbt with no change.by Rusty Russell · 2591ac48 · Oct 24, 2025 · 1 fileMessage 75 · AdequateInformational 12Details
Commit message · Rusty Russell

pytest: add test that we notice height change of sendpsbt with no change.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 12/100

This commit only adds a new automated test to the project's test suite. It does not change any production code, so it cannot directly fix or introduce a security vulnerability. The test checks that a wallet transaction created via sendpsbt is correctly tracked from unconfirmed to confirmed status, including after a node restart. It is currently marked as expected to fail (xfail), meaning the underlying behavior may not yet work as intended.

Security candidateplugins: fix %*.s typo.by Rusty Russell · 8f6d3d87 · Oct 24, 2025 · 5 filesMessage 64 · AdequateModerate 68Details
Commit message · Rusty Russell

plugins: fix %*.s typo.

And add a check for new uses creeping in, since it got cut & paste
everywhere.

This means "this is a valid string, but truncate it to this many characters"
vs "%.*s" which means "only read this many characters of string":

```
['lightningd-3 2025-10-23T02:31:40.890Z **BROKEN** plugin-funder: Plugin marked as important, shutting down lightningd!']
--------------------------- Captured stderr teardown ---------------------------
#0 0x557da58ad1dc in printf_common(void*, char const*, __va_list_tag*) asan_interceptors.cpp.o
#1 0x557da5aff814 in json_out_addv /home/runner/work/lightning/lightning/ccan/ccan/json_out/json_out.c:239:11
#2 0x557da59740ce in plugin_logv /home/runner/work/lightning/lightning/plugins/libplugin.c:1777:2
#3 0x557da5969b6f in plugin_log /home/runner/work/lightning/lightning/plugins/libplugin.c:1934:2
#4 0x557da595c4f6 in datastore_del_success /home/runner/work/lightning/lightning/plugins/funder.c:161:2
#5 0x557da598b837 in handle_rpc_reply /home/runner/work/lightning/lightning/plugins/libplugin.c:1072:10
#6 0x557da598a4b0 in rpc_conn_read_response /home/runner/work/lightning/lightning/plugins/libplugin.c:1361:3
#7 0x557da5adbea5 in next_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:60:9
#8 0x557da5ae06ff in do_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:422:8
#9 0x557da5adfb58 in io_ready /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:439:10
#10 0x557da5aec2ce in io_loop /home/runner/work/lightning/lightning/ccan/ccan/io/poll.c:455:5
#11 0x557da59757ac in plugin_main /home/runner/work/lightning/lightning/plugins/libplugin.c:2409:3
#12 0x557da594fe23 in main /home/runner/work/lightning/lightning/plugins/funder.c:1723:2
#13 0x7f6572229d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#14 0x7f6572229e3f in __libc_start_main csu/../csu/libc-start.c:392:3
#15 0x557da588b584 in _start (/home/runner/work/lightning/lightning/plugins/funder+0x10d584) (BuildId: 71ba63ab577fc6fa60573d3e8555f6db7d5c584d)

0x624000009d28 is located 0 bytes to the right of 7208-byte region [0x624000008100,0x624000009d28)
allocated by thread T0 here:
#0 0x557da590e7f6 in __interceptor_realloc (/home/runner/work/lightning/lightning/plugins/funder+0x1907f6) (BuildId: 71ba63ab577fc6fa60573d3e8555f6db7d5c584d)
#1 0x557da5b2149b in tal_resize_ /home/runner/work/lightning/lightning/ccan/ccan/tal/tal.c:755:13
#2 0x557da59f2032 in membuf_tal_resize /home/runner/work/lightning/lightning/common/utils.c:203:2
#3 0x557da5b03934 in membuf_prepare_space_ /home/runner/work/lightning/lightning/ccan/ccan/membuf/membuf.c:45:12
#4 0x557da59d4289 in jsonrpc_io_read_ /home/runner/work/lightning/lightning/common/jsonrpc_io.c:127:2
#5 0x557da598a635 in rpc_conn_read_response /home/runner/work/lightning/lightning/plugins/libplugin.c:1366:9
#6 0x557da5adbea5 in next_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:60:9
#7 0x557da5ae06ff in do_plan /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:422:8
#8 0x557da5adfb58 in io_ready /home/runner/work/lightning/lightning/ccan/ccan/io/io.c:439:10
#9 0x557da5aec2ce in io_loop /home/runner/work/lightning/lightning/ccan/ccan/io/poll.c:455:5
#10 0x557da59757ac in plugin_main /home/runner/work/lightning/lightning/plugins/libplugin.c:2409:3
#11 0x557da594fe23 in main /home/runner/work/lightning/lightning/plugins/funder.c:1723:2
#12 0x7f6572229d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16

SUMMARY: AddressSanitizer: heap-buffer-overflow asan_interceptors.cpp.o in printf_common(void*, char const*, __va_list_tag*)
Shadow bytes around the buggy address:
0x0c487fff9350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c487fff9390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c487fff93a0: 00 00 00 00 00[fa]fa fa fa fa fa fa fa fa fa fa
0x0c487fff93b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c487fff93f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==26122==ABORTING
```

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

64/100 · AdequateMessage clarity
✓ Subject identifies a change✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
memory safetydefensive validation
AI analysis · Moderate 68/100

This commit fixes a typo in several Core Lightning plugins where the wrong printf format string was used. The buggy '%*.s' tells the program to treat a string pointer as a width and then read an unlimited number of bytes from another pointer, which can read past the end of a buffer and crash or leak memory. The fix changes it to '%.*s', which correctly limits how many bytes are read from the string. The commit also adds a build-time check to stop the typo from being reintroduced.

Security candidateglobal: remove unnecessary includes from C files.by Rusty Russell · 6e5cb299 · Oct 22, 2025 · 177 filesMessage 68 · AdequateInformational 15Details
Commit message · Rusty Russell

global: remove unnecessary includes from C files.

Basically, `devtools/reduce-includes.sh */*.c`.

Build time from make clean (RUST=0) (includes building external libs):

Before:
real 0m38.944000-40.416000(40.1131+/-0.4)s
user 3m6.790000-17.159000(15.0571+/-2.8)s
sys 0m35.304000-37.336000(36.8942+/-0.57)s
After:
real 0m37.872000-39.974000(39.5466+/-0.59)s
user 3m1.211000-14.968000(12.4556+/-3.9)s
sys 0m35.008000-36.830000(36.4143+/-0.5)s

Build time after touch config.vars (RUST=0):

Before:
real 0m19.831000-21.862000(21.5528+/-0.58)s
user 2m15.361000-30.731000(28.4798+/-4.4)s
sys 0m21.056000-22.339000(22.0346+/-0.35)s

After:
real 0m18.384000-21.307000(20.8605+/-0.92)s
user 2m5.585000-26.843000(23.6017+/-6.7)s
sys 0m19.650000-22.003000(21.4943+/-0.69)s

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
Why it was queued
signing or wallet pathauthentication pathparser or protocol path
AI analysis · Informational 15/100

This commit is a routine code cleanup: it removes unused C-language #include directives from many source files and adds a few that were needed but previously inherited indirectly. The stated goal is faster build times, and the diff shows no functional code changes. There is no security-relevant behavior change.

Security candidatetests/fuzz: fix include order.by Rusty Russell · d8ee3a5e · Oct 22, 2025 · 7 filesMessage 70 · AdequateInformational 15Details
Commit message · Rusty Russell

tests/fuzz: fix include order.

Nobody ever runs `make check-includes` with fuzzing enabled.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidencecryptography-sensitive pathparser or protocol path
AI analysis · Informational 15/100

This commit only reorders #include lines in fuzz-test source files and adds minor indentation to two direct .c file includes. It is a coding-style/build-hygiene fix with no functional code changes and no security relevance.

Security candidateMakefile: create a library containing common, wire and bitcoin objects.by Rusty Russell · e120f870 · Oct 22, 2025 · 83 filesMessage 95 · StrongInformational 15Details
Commit message · Rusty Russell

Makefile: create a library containing common, wire and bitcoin objects.

This means we don't have to manually choose what to link against,
which is much of the complexity of our Makefiles: the compiler will
automatically use any object files it needs to link.

We already do this for ccan as libccan.a, now we have libcommon.a.

We don't link against it for *everything*, as some tests require their own
versions.

Notes:
1. I get rid of the weird plugins/test/Makefile2 (accidental commit?)
2. Many tests change due to update-mocks.
3. In some places I added the missing dependency on the Makefile itself, though most are in the next
patch.

Before:
Total program size: 221366528
Total tests size: 364243856

After:
Total program size: 190733656
Total tests size: 337880888

Build time from make clean (RUST=0) (includes building external libs):

Before:
real 0m38.227000-44.245000(41.8222+/-1.6)s
user 3m2.105000-33.696000(23.1442+/-8.4)s
sys 0m35.054000-42.269000(39.7231+/-2)s
After:
real 0m38.944000-40.416000(40.1131+/-0.4)s
user 3m6.790000-17.159000(15.0571+/-2.8)s
sys 0m35.304000-37.336000(36.8942+/-0.57)s

Build time after touch config.vars (RUST=0):

Before:
real 0m18.928000-22.776000(21.5084+/-1.1)s
user 2m8.613000-36.567000(27.7281+/-7.7)s
sys 0m20.458000-23.436000(22.3963+/-0.77)s

After:
real 0m19.831000-21.862000(21.5528+/-0.58)s
user 2m15.361000-30.731000(28.4798+/-4.4)s
sys 0m21.056000-22.339000(22.0346+/-0.35)s

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

rusty@rusty-Framework:~/devel/cvs/lightni

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
Why it was queued
signing or wallet pathboot or update path
AI analysis · Informational 15/100

This commit is a build-system cleanup. It creates a new static library (libcommon.a) containing common, wire, and bitcoin object files so that Makefiles no longer need to list individual object files by hand. It also removes many auto-generated mock function stubs from unit tests because those functions are now provided by the library. There is no runtime behavior change to Core Lightning itself, and no security issue is introduced or fixed.

Security candidateMakefile: run fuzzing corpora as normal unit tests in non-fuzzing mode.by Rusty Russell · 2adfdfd0 · Oct 22, 2025 · 15 filesMessage 83 · StrongInformational 15Details
Commit message · Rusty Russell

Makefile: run fuzzing corpora as normal unit tests in non-fuzzing mode.

This means we can make sure the compile and run in normal builds.

Side note: various tests call common_setup(), which means we called it
twice in unit testing mode, so we conditionalize those.

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
Why it was queued
fuzzing or regression evidencecryptography-sensitive pathparser or protocol path
AI analysis · Informational 15/100

This commit changes the build system so that existing fuzz tests can also run as ordinary unit tests in normal (non-fuzzing) builds. It does not fix a bug, change runtime behavior of Core Lightning in production, or introduce any user-facing feature. It is purely a testing/CI infrastructure improvement.

Security candidateglobal: remove unnecessary includes from headers.by Rusty Russell · f6a4e794 · Oct 22, 2025 · 212 filesMessage 68 · AdequateInformational 15Details
Commit message · Rusty Russell

global: remove unnecessary includes from headers.

Each header should only include the other headers it needs to compile;
`devtools/reduce-includes.sh */*.h` does this. The C files then need
additional includes if they don't compile.

And remove the entirely useless wire/onion_wire.h, which only serves to include wire/onion_wiregen.h.

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
Why it was queued
cryptography-sensitive pathsigning or wallet pathparser or protocol path
AI analysis · Informational 15/100

This is a large but purely mechanical cleanup of C header file #include directives across the Core Lightning codebase. The goal is to make each header include only what it actually needs, and to add missing includes to the .c source files that now need them. It also deletes a tiny wrapper header that did nothing but include another generated header. There is no change to program logic, data handling, or security behavior.

Security candidatemakefile: fix glob expansion for macOSby Sangbida Chaudhuri · ad0c7318 · Oct 22, 2025 · 1 fileMessage 73 · AdequateInformational 15Details
Commit message · Sangbida Chaudhuri

makefile: fix glob expansion for macOS

when bash expands bitcoin/*.h, it returns the files in lexicographically sorted order by default this is not necessarily the case for macOS so it has be explicitly sorted. I get a fairly uninformative error like this:

make: *** [check-bitcoin-makefile] Error 1

The error is now more informative and does not error on a clean branch on macOS:

BITCOIN_HEADERS missing: bitcoin/signature.h bitcoin/tx_parts.h bitcoin/tx.h bitcoin/varint.h
make: *** [check-bitcoin-makefile] Error 1

73/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit fixes a build script check that was too strict on macOS. The Makefile check compares a manually maintained list of Bitcoin header files against files found on disk. On Linux, the shell lists files in sorted order, but macOS does not, causing the check to fail even when nothing is wrong. The patch makes the comparison order-independent and prints clearer error messages. It is a build tooling fix with no security relevance.