Core Lightning

This commit adds extra information — the identity of the peer that sent an HTLC — to a plugin hook called htlc_accepted. It is a straightforward feature enhancement for plugin developers and does not change how payments are validated, accepted, or rejected. There is no security issue visible in the change itself.

This is a one-line build-system fix for macOS. Previously, the configure script replaced the user's PKG_CONFIG_PATH environment variable with a single hardcoded path. Now it appends the hardcoded path to any existing value. This prevents build failures when users rely on custom or Homebrew-provided pkg-config paths, but it does not fix a runtime security vulnerability in the lightning node itself.

This commit only updates the macOS installation instructions in the documentation. It splits the guide into separate Apple Silicon and Intel Mac sections and adds tips for avoiding the wrong Homebrew version. There are no code changes and no security issue is being fixed or introduced.

This commit only changes test infrastructure. It makes integration tests work when run from very deeply nested directories by shortening the file paths used for internal Unix sockets. There is no change to the actual Core Lightning node software that users run, and no security issue is being fixed or introduced.

This commit fixes a build failure in the fuzz testing code by adding two missing header file includes. It does not change any runtime behavior or fix a security vulnerability.

This is a minor cleanup change to a fuzz test file. It replaces hard-coded numbers with named constants and swaps a generic memory-free call for a dedicated key-discard function. There is no security vulnerability here.

This commit only adds two new test input files to a fuzz-testing seed corpus. Fuzzing seed corpora are collections of example inputs used to automatically exercise code during testing. The change does not modify any production code, configuration, or cryptographic logic. There is no indication of a security vulnerability being fixed or introduced.

This commit only reorders #include header lines in two test fuzzing source files so they follow the project's required alphabetical/system ordering. It does not change any executable code, fix a bug, or alter runtime behavior.

This commit adds a new automated fuzz test for Core Lightning's channel state machine. It is purely a test/instrumentation addition: it creates no new production code, changes no protocol behavior, and does not fix any bug. The change is defensive in nature, intended to help find future bugs in HTLC handling.

This commit only adds test data files (a seed corpus) for a fuzz-testing harness. It does not change any production code, configuration, or documentation. There is no direct security relevance to running Core Lightning nodes.

This commit only adds test data files (a seed corpus) for a fuzz-testing harness that exercises the onion-message handling code. It does not change any production code, configuration, or runtime behavior, so it cannot introduce a security vulnerability or fix one on its own.

This commit only adds a new fuzz test for an existing function that handles incoming onion messages. It does not change the actual message-handling code, so it cannot introduce a security vulnerability by itself. It is a testing improvement.

This commit is a routine version bump and changelog update for Core Lightning release 25.09.3. It only changes version strings in packaging files and adds release notes; it does not modify any executable code, cryptographic logic, network handling, or fix any vulnerability directly. The changelog mentions prior fixes in release 25.09.2, but those changes are not part of this diff.

This commit adds a new plugin hook capability that lets a plugin override the expected invoice amount when a Lightning payment arrives. It is a deliberate feature, not a bug fix, and the commit message and documentation describe it as useful for accepting smaller payments than originally invoiced. There is no direct evidence this change introduces a vulnerability, but any hook that can override financial validation could be misused if a malicious or buggy plugin is installed.

This commit adds a new optional override to the internal invoice payment-checking function. It lets the node accept a payment whose amount differs from what the invoice originally stated. The change is purely internal infrastructure: all existing callers pass NULL, so the override is not yet used. There is no direct security bug visible in the diff, but it changes the assumptions around invoice amounts, which could matter for future callers.

This commit fixes a packaging bug in Core Lightning's official Docker image. A recent Docker refactoring accidentally left out the SQLite database library (libsqlite3-0) from the final runtime image. Without it, the container likely fails to start or cannot use the default SQLite wallet backend. The patch simply adds the missing library back to the list of packages installed in the final Docker stage. There is no evidence in the commit of a security vulnerability, exploit, or malicious change.

This commit updates the project's Docker build file to install two missing software libraries (lowdown and libsodium) and set related environment variables so the container can compile and run correctly. It is a build-fix change, not a patch for an active security vulnerability. There is no evidence in the commit or supplied references that this fixes a known exploit or was disclosed as a security issue.

This commit changes how Docker builds install packages for cross-compilation. It splits one package-installation step into two: first installing a Python development package that works on any CPU architecture, then installing libraries specific to the target CPU architecture. This is a build-system cleanup and does not appear to be a security fix.

This commit changes how the build system finds two software libraries (OpenSSL and SQLite) on Apple Silicon Macs. Previously, the Makefile used fixed paths like /opt/homebrew/opt/openssl@3. Now it asks Homebrew where those libraries actually live. This is a build-portability fix, not a security patch for a vulnerability. It does not change any runtime code that handles money, network messages, or cryptography.

This commit is a routine version bump for an internal Rust crate called cln-grpc-plugin, changing its declared version from 0.4.0 to 0.5.0. It also fixes a minor whitespace issue in a dependency line. There is no functional code change and no indication of a security fix or vulnerability.

This change makes the Bitcoin Taproot address format (p2tr) the new default when users call the `newaddr` command, instead of the older bech32 format. The old bech32 default is kept as a deprecated option for one release cycle so existing integrations don't break immediately. This is a routine modernization, not a security fix.

This commit only changes test code. It updates how tests request Bitcoin addresses so they explicitly ask for the address type they want (bech32 or taproot/p2tr) instead of relying on a default. There is no change to production wallet or node code, and no security vulnerability is present in the diff.

This change is a performance optimization for the Core Lightning SQL plugin. It delays creating database indexes until after a table's data has been loaded for the first time, rather than creating indexes before loading. This makes initial data imports much faster (for example, one large table now loads in 17 seconds instead of 82 seconds). There is no security issue here.

This commit is a performance improvement, not a security fix. It changes the bookkeeper plugin so that when it processes a very large number of channel movements at once, it only writes detailed debug logs for the first and last one instead of every single one. This reduces log flooding and speeds up the first bookkeeper command after an upgrade. There is no indication this change addresses a vulnerability or security flaw.

This commit only adds a new automated test to the project's test suite. It does not change any production code, so by itself it cannot introduce or fix a live security issue. The test checks that a specific payment function reports a failure correctly when a peer connection drops at a particular moment.