Core Lightning

This commit simply deletes an unused GitHub Actions workflow file that automated version bumps for Rust crates. There is no change to the actual Core Lightning software, no security fix, and no vulnerability introduced.

This commit is a routine Rust project maintenance change. It sets the minimum required Rust compiler version to 1.85 across all workspace crates, upgrades the Cargo dependency resolver to version 3, and refreshes the Cargo.lock file with newer patch versions of libraries. There is no indication this fixes or introduces a security vulnerability.

This commit adds a new automated CI (Continuous Integration) workflow that checks whether Rust code changes still compile with the project's declared Minimum Supported Rust Version (MSRV). It does not change any application code, network behavior, cryptography, or user-facing functionality. There is no security vulnerability here.

This commit updates several Rust crates from the 2021 edition of the Rust programming language to the 2024 edition. The only code changes are mechanical adjustments required by the new edition: marking environment-variable writes as unsafe with safety comments, reformatting some chained function calls, and converting some if-let constructs to match statements. There is no security fix or vulnerability being patched.

This commit is purely a code-formatting cleanup. It runs `cargo fmt --all` to apply the Rust 2024 edition style rules across many Rust source files. The changes only reorder imports, re-wrap long lines, add trailing commas, and adjust indentation. No program logic, security checks, or behavior were changed.

This is a version-bump point release (v26.04.1) for Core Lightning. The changelog says it fixes two issues: a build failure caused by a wrong printf format, and a Lightning gossip protocol problem where malformed channel announcements could stress the gossip store. The actual code changes for those fixes are not present in this commit; it only updates version strings and the changelog. So this commit itself is mostly administrative, but it signals that security-relevant fixes were released.

This is a one-character code change fixing a compiler warning. It changes a log message format from %lu to %zu so the code compiles cleanly on platforms where a particular data type size differs. It does not change program behavior or fix any security issue.

This update fixes a bug in Core Lightning's gossip daemon, which handles network routing announcements. The daemon was accepting malformed channel announcements where the two node IDs were in the wrong order. Such messages are invalid per the Lightning protocol and can cause errors for any node that later reads them from its stored gossip data. The fix makes the node reject these invalid announcements, preventing downstream error cascades.

This commit simply raises the minimum required Python version from 3.9 to 3.10 across the project's Python packages and updates the generated lock file accordingly. It is a routine maintenance change because Python 3.9 has reached end-of-life. There are no code changes that fix or introduce a security vulnerability.

This commit is a routine version bump from release candidate 3 (v26.04rc3) to the final release (v26.04). It only changes version strings in packaging files, the changelog, and a lock file. There are no code logic changes and no security fixes or new features introduced.

This commit adds a new command-line/config option `--message-padding` that lets users turn off a recently added privacy feature. By default, Core Lightning now pads peer messages to the same length to hide which type of message is being sent. Some other Lightning implementations (LND variants and Eclair) reportedly reject or mis-handle those padding bytes, so this switch lets operators disable padding entirely if they run into compatibility problems. It is a workaround/configurability change, not a fix for a code vulnerability.

This commit is a routine version bump from v26.04rc2 to v26.04rc3 for Core Lightning. It updates version strings in packaging files, a changelog, and a lock file. There are no code changes that fix or introduce any security-relevant behavior.

This commit adds a new bookkeeping report command (bkpr-report) to Core Lightning's gRPC and RPC interfaces. It is a routine feature addition that exposes an existing internal RPC method through the generated gRPC bindings, protocol definitions, and Python test helpers. There is no indication of a security vulnerability in the changes.

This commit is a routine feature addition to Core Lightning's code-generation tooling. It exposes two new RPC methods, 'splicein' and 'spliceout', through the gRPC and Python bindings. There is no indication in the commit message or diff that this fixes a security bug; it appears to be normal API surface expansion.

This commit only adds a missing changelog entry describing an earlier bug fix. It does not change any code, configuration, or behavior. The actual fix (changing keysend's assumed final CLTV from 22 to 42 blocks for compatibility with LDK nodes) was made in a separate pull request referenced in the changelog. There is no security-relevant change in this commit itself.

This change fixes a compatibility issue in the `keysend` payment feature. Core Lightning was assuming a lower safety margin (22 blocks) for the final recipient's deadline than LDK/Rust-Lightning actually requires (42 blocks). When sending spontaneous payments to LDK nodes, this mismatch could cause the payment to be rejected or fail. The patch simply raises the assumed value to match LDK, improving interoperability. It is not a vulnerability that lets an attacker steal funds, but it is a reliability/security-adjacent fix for payment routing.

This is a minor build-system fix in the Makefile. It stops automatically generated source files from being treated as temporary files that get deleted after use. Previously, deleting them caused `make install` to regenerate them and unnecessarily rebuild other files. There is no security issue here.

This is a test-only change that makes a flaky test more tolerant. It does not change any production code, so it has no direct security impact on users of Core Lightning.

This commit removes an experimental developer-only feature called 'uniform padding' that was intended to make network traffic between Lightning nodes look more uniform as a defense against traffic analysis. It is a clean revert of three earlier commits and does not introduce any security vulnerability or fix one. The feature was gated behind a hidden developer flag and was never active in normal operation.

This is a small internal code cleanup in Core Lightning's connection handling. It moves a copy of the peer's feature list into the peer structure so it can be used later. There is no security fix or vulnerability visible in this change.

This commit is a small internal code cleanup in Core Lightning's connection handling. It replaces two direct checks of a developer-only padding flag with a helper function named `use_uniform_writes()`. There is no change to behavior, no fix for a bug, and no indication of a security issue.

This change adjusts when Core Lightning pads its network messages to a constant size. Previously padding was controlled by a developer/testing flag. Now it is enabled only when the connected peer advertises support for 'onion messages' (a newer Lightning feature). The commit message says this works around a bug in LND (another Lightning implementation) where LND would disconnect if it received certain padded 'ping' messages. The fix uses onion-message support as a signal that the remote LND version is new enough to tolerate the padding. There is no direct evidence in the diff of a security vulnerability; it reads as a compatibility/interoperability fix that incidentally preserves a privacy feature (uniform packet sizes).

This commit adjusts when Core Lightning pads ping messages to keep packet sizes uniform. It now skips padding when talking to Eclair nodes that advertise feature bit 154, because Eclair had a similar bug where it did not reply to certain padded pings, which could cause connection problems. The change is a compatibility workaround, not a direct fix for a vulnerability in Core Lightning itself.

This commit only reorders existing text entries in the project's CHANGELOG.md file. It does not change any code, configuration defaults, or documentation content. There is no security relevance.

This commit is a routine cleanup of the project's CHANGELOG.md file. It reformats entries for consistency, combines related bullet points, removes one non-user-visible build-system entry, and adds a missing changelog note that splicing is now enabled by default. No program code was changed, so it cannot directly affect security or introduce vulnerabilities.