Core Lightning

This commit updates a standalone HTML helper tool used to visualize Core Lightning node logs. It adds logic to recognize log formats produced by continuous integration (CI) runs and Python tests, then strips the node-identifying prefix before rendering. There is no change to the actual Core Lightning daemon, wallet, network protocol, or any cryptographic code. It is a developer/debugging utility enhancement with no security relevance.

This commit adds routine logging of network events—successful connections, failed connections, disconnections, and ping latencies—to the node's internal database. It is a bookkeeping/telemetry change, not a fix for a security flaw, and it does not change how the node handles peers or funds.

This commit adds a new 'networkevents' category to the existing 'wait' API, allowing users to subscribe to notifications about peer connection, ping, and disconnect events. It is a straightforward feature addition with no visible security defect.

This commit adds a new read-only data table called 'networkevents' to the experimental SQL plugin. It lets users query network event history using SQL, similar to existing tables. There is no indication of a security bug or vulnerability fix.

This commit adds a new automatic cleanup feature to the Core Lightning 'autoclean' plugin. By default, network event logs (connections, disconnections, pings) older than 30 days will now be deleted automatically. Users can change or disable this with a new configuration option. There is no indication this is a security fix; it is a routine data-retention and housekeeping feature.

This commit adds a new internal telemetry feature: the connection daemon now measures how long ping probe responses take and reports those timings to the main lightningd process. It is a straightforward feature addition with no apparent security implications.

This change improves how Core Lightning reports connection failures. It adds a flag telling the main daemon whether the node actually tried to connect to any address, or couldn't even attempt one (for example, because the peer only offers Tor addresses and this node has no Tor proxy, or only offers IPv6 and this node can't use IPv6). This helps avoid wrongly marking peers as unreachable when the real problem is local network capability. There is no direct security vulnerability being fixed here; it is a reliability and diagnostic improvement.

This commit adds a new administrative JSON-RPC command called `delnetworkevent` that lets a node operator delete a single diagnostic network event from the local database by its index. It is intended for housekeeping (for example, the autoclean plugin) and does not affect live channels or funds. There is no indication in the commit that this fixes a security bug; it appears to be a routine feature addition.

This commit is a routine internal improvement, not a security fix. It makes the connection daemon (connectd) report back why a connection was attempted and how long it took, alongside existing success/failure messages. This is observability and diagnostic data being added to inter-daemon messages; it does not change who can connect, what they can do, or how funds are protected.

This change is a straightforward instrumentation patch: Core Lightning's connection daemon (connectd) now records when a peer connection started and reports how long it lasted when the peer disconnects. The data is passed to the main lightningd process and included in internal peer-disconnect/reconnect messages. There is no evidence in the commit of a security bug being fixed or introduced; it appears to be a metrics/logging improvement.

This commit adds a new read-only RPC command called listnetworkevents to Core Lightning. It lets users query a log of network events such as peer connects, disconnects, failed connects, and pings. The change is purely additive: it exposes existing internal event data through a new API and does not alter how funds, channels, or network connections are handled. There is no indication this fixes a security bug or introduces a vulnerability.

This commit adds database infrastructure to record network events (peer connects, disconnects, failed connects, and pings) in Core Lightning. It creates a new database table, adds functions to save and retrieve those events, and updates test stubs. There is no security fix or vulnerability present in the diff itself; it is a feature/infrastructure change.

This commit changes how the clnrest plugin pulls in two Rust helper libraries (utoipa and utoipa-swagger-ui). Previously they were downloaded directly from a personal GitHub fork; now they come from the official crates.io registry. The change was made to fix broken Docker and release builds, not because of a known security flaw. Using registry versions is generally safer and more reproducible than an unreviewed git fork, but the commit itself does not claim to fix any vulnerability.

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 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 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 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 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 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 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 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.