Core Lightning

This commit adds a new helper function that lets plugin code send a pre-built JSON response directly, instead of building it piece by piece. It is a straightforward internal code refactor with no obvious security relevance.

This commit is a straightforward code reorganization: it moves the route_query data structure and two helper functions from the main askrene.c/askrene.h files into a new child/route_query.c and child/route_query.h. The actual logic is copied verbatim, and the build system is updated to compile the new file. There is no functional change and no security relevance.

This commit only changes test code. It rewrites two slow pytest test functions to submit RPC calls in parallel using a thread executor, which makes one test run faster and exercises Core Lightning's askrene parallel-routing code path. There is no change to production code, no bug fix, and no security relevance visible in the diff or commit message.

This commit simply moves a helper function that formats debug logging text from one source file to another within the same plugin. There is no change to what the code does, no bug fix, and no security relevance.

This commit is a straightforward code reorganization: it moves the definition of a hash table type called additional_cost_htable from a private source file into a new public header file so that a child process can use it. There is no change to program behavior, no bug fix, and no security-related change.

This is a routine code cleanup in Core Lightning's routing plugin. It makes two internal functions private (static) and removes one unused helper function. There is no security-relevant change: no bug is fixed, no behavior is altered, and no externally reachable interface is changed.

This commit is a straightforward code reorganization: it moves the function that creates a child process (fork_router_child) and related helper code from the main askrene.c file into a new child/entry.c file. No security-sensitive logic was changed; the same fork(), pipe, and routing behavior is preserved. The change makes the build layout cleaner by having only one file shared between the parent and child process.

This change rewrites part of a Lightning routing plugin so that the heavy route-finding work is done in a separate child process. The parent process prepares the request, forks a child, the child runs the algorithm and writes a JSON answer (or an error string) back through a pipe, and the parent forwards that answer. The commit notes that child logging is currently lost and that the parent still waits for the child, so it is not a performance improvement yet. There is no claim that this fixes a security bug; it appears to be an architectural isolation change.

This is a routine internal code cleanup in Core Lightning's routing plugin (askrene). It moves the creation of a 'route_query' data structure from the parent process into the child process, and changes the function that forks the router child to accept individual fields instead of a pre-built structure. There is no indication this fixes or introduces a security vulnerability.

This commit is a straightforward internal cleanup in the Core Lightning 'askrene' routing plugin. It removes a temporary 'hack' where child processes used the parent logging function, and instead makes them use their own dedicated child_log() function. There is no security-relevant change visible in the diff.

This change adds a limit to how many routing calculations the askrene plugin can run at the same time. Previously, there was no cap, and the code even had a note saying 'FIXME: limit parallelism!' The new default is 4 concurrent routing requests, with extra requests queued and processed later. The commit also explicitly queues requests before fetching local channel information, so waiting requests don't use outdated channel data when they finally run. This is a hardening improvement rather than a fix for a known active attack.

This commit is a pure code reorganization: it moves several routing-related source files into a new 'child/' subdirectory within the askrene plugin. There are no functional changes, no bug fixes, and no security patches visible in the diff. The code is simply relocated to make it clearer which routines run in the child process versus the parent process.

This change is a hardening fix in a Core Lightning plugin called askrene. When askrene spawns a child process to do heavy route-finding work, the child previously inherited all of the parent's open file descriptors (network sockets, pipes, files). If the child had a bug, it could accidentally write to or close those inherited descriptors, disrupting the plugin's connection to the main lightningd daemon. The patch makes the child close most inherited file descriptors (keeping only standard error) so a buggy child cannot interfere with the parent's communication channels.

This commit adds a new internal helper function that runs the bitcoin-cli command synchronously (waiting for it to finish before continuing). It is marked UNNEEDED, meaning it is not currently used anywhere. The change appears to be a pure code-structure refactor with no active security behavior introduced.

This is a routine code cleanup in Core Lightning's bitcoin-cli plugin. It pulls out duplicated code for running bitcoin-cli into a single shared helper function, with no intended behavior change. There is no indication this fixes or introduces a security vulnerability.

This commit changes how Core Lightning submits raw Bitcoin transactions to the local bitcoin node. Previously it was done in the background (asynchronous); now it is done inline (synchronous) and returns the result directly. The change is a refactor that makes error handling more explicit and helps functional tests observe failures. There is no direct evidence in the commit that this fixes an exploitable security bug.

This commit only adds new automated tests to the Core Lightning project. It does not change any production code, so it cannot introduce a security vulnerability by itself. The tests exercise an existing retry mechanism in the bitcoin backend plugin (bcli) when a pruned Bitcoin node temporarily cannot return a block. One test documents that Core Lightning will shut down (fatal error) if the retry path runs out of time. That behavior is already present in the code; the test merely records it.

This commit is mostly a cleanup: it removes old asynchronous code from the bitcoin-cli plugin after it was converted to run commands one at a time (synchronously). The only functional bug fix is adding a missing `close(from)` call, which stops a file descriptor leak when running bitcoin-cli. There is no obvious new security vulnerability introduced by the change.

This commit refactors how Core Lightning handles replies from its internal Bitcoin plugin (bcli). Previously, if the plugin reported an error, the main daemon might try to read a non-existent 'result' field and produce a confusing 'bad result' message. The new helper explicitly checks for an 'error' field first and extracts the real error message. It also makes several callbacks parse the 'result' object directly instead of expecting it to be wrapped in a top-level '{result:{...}}' structure. This is primarily a robustness/logging improvement; it does not by itself fix a known exploitable vulnerability, but it removes a class of error-handling gaps that could hide or misreport plugin failures.

This commit is a simple code cleanup: it replaces three hard-coded numbers in the bitcoin-cli plugin with named constants. The actual behavior of the program does not change at all. There is no security fix here.

This change rewrites how Core Lightning asks Bitcoin for fee estimates, switching from an asynchronous (multi-step callback) style to a simpler synchronous style. It also adds a shared helper for reporting bad JSON responses from bitcoin-cli and fixes a typo in a log message ('32 bites' to '32 bits'). The rewrite does not obviously add or remove a vulnerability, but it changes timing and error-handling behavior in a security-sensitive area (fee estimation), so it warrants careful review.

This commit changes how a Core Lightning plugin asks its connected Bitcoin node about transaction outputs. It switches one internal call from asynchronous to synchronous execution and adds more detailed error messages. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a code-quality and robustness improvement.

This commit changes how the bitcoin-cli plugin answers the 'getchaininfo' request. Previously it started an asynchronous background job and later returned the result. Now it calls bitcoin-cli directly and waits for the answer before responding. The change removes the 'UNNEEDED' marker from the synchronous helper functions, because they are now used, and marks the old asynchronous result handler as no longer needed. On its own this is a routine internal refactor; it does not obviously fix a security bug, but it does remove one asynchronous path where race conditions or state confusion could occur.

This commit rewrites one internal plugin function so it calls the Bitcoin backend in a straightforward, step-by-step (synchronous) style instead of a chain of callbacks. It also renames an internal error helper so it can print 'command failed' when the backend returns a non-zero exit code, not only 'bad JSON'. The change is mostly a refactor; it does not obviously fix or introduce a security vulnerability on its own.

This commit only changes test files. It updates pytest test cases to match new behavior after a code refactor made the lightning node crash instead of retry when it gets invalid responses from the connected Bitcoin node. There is no change to production code, so it does not introduce or fix a security vulnerability by itself.