Core Lightning

This commit hardens three GitHub Actions workflow files by moving user-controlled inputs into environment variables before they are used in shell scripts. Previously, values like platform lists, Docker Hub owner names, and PyPI distribution locations were inserted directly into shell commands. If someone with workflow trigger access supplied specially crafted input, they could potentially inject shell commands. The change follows GitHub's recommended practice of binding inputs to environment variables first, which reduces that risk.

This commit fixes a crash in Core Lightning that could occur when starting a plugin with startup parameters after a previously-configured plugin option had disabled itself. The crash happened because the code tried to use a plugin option that no longer existed (a 'stale configvar'). The fix skips these stale entries instead of crashing. It is a denial-of-service-style bug triggered by plugin configuration changes, not a remote exploit for stealing funds.

This commit re-adds an old-style 'x' prefix to a string comparison in a test helper script. It is a test-only change with no effect on the actual Core Lightning node software, user funds, network behavior, or security. The change simply restores a defensive shell-coding idiom to avoid a rare edge case in ancient shells.

This commit is a simple documentation revert. It undoes a previous change that told macOS users to install GNU make and GNU patch from Homebrew and to put those tools first in their command path. The reverted instructions now omit gpatch and point PATH to a non-existent-looking '/opt/homebrew/opt/' directory, which is likely a mistake or incomplete edit. There is no code change and no direct security issue in the diff itself.

This commit only updates macOS installation instructions in the documentation. It tells macOS users to install newer GNU versions of 'make' and 'patch' from Homebrew because Apple's built-in tools are too old for building and running source checks. No code, no security fix, no vulnerability.

This commit is a trivial shell script cleanup. It removes an old-fashioned 'x' prefix from a string comparison in a test helper script so that a newer version of the Shellcheck linter stops warning about it. The change does not alter program behavior and has no security relevance.

This commit only adds a new pytest test file. It does not change any production code. The test describes desired future behavior for the askrene routing module's error messages when a payment source or destination lacks enough channel capacity. Because no actual code behavior is modified, this commit cannot introduce or fix a security vulnerability on its own.

This commit is a routine code cleanup: it moves a small string-hashing helper function into a shared header file so it can be reused without being copied and pasted. There is no change to behavior, no bug fix, and no security relevance.

This commit fixes a bookkeeping bug in Core Lightning's xpay plugin. Previously, when a payment succeeded, xpay did not tell the askrene routing-helper that the route worked. As a result, askrene kept stale or overly pessimistic ideas about which channels could carry payments, which could make future payments fail unnecessarily or take worse routes. The patch adds the missing 'payment succeeded' notification for every non-local hop. It is a reliability/performance fix, not a direct theft-of-funds vulnerability.

This commit fixes a bug in Core Lightning's routing helper (askrene) where two kinds of channel information—hard limits called 'constraints' and usage estimates called 'impressions'—were being applied in the wrong order. Because impressions are time-relative, applying them out of order could make the router think a channel has more or less available capacity than it really does. The patch merges the two data structures and keeps them sorted by timestamp so they are applied in the correct sequence. The included test demonstrates that the wrong ordering could cause a payment route to be accepted when it should be rejected, or vice versa.

This commit fixes a memory leak in the askrene plugin of Core Lightning. When individual channel intelligence entries were deleted, the code removed the entry from its array but forgot to free two internal pointers (impression and constraint). Over time, this could cause the node process to consume more memory than necessary. The fix explicitly hands those pointers to a temporary context so they are cleaned up when the operation finishes.

This change tightens the lifetime of recurring invoices priced in foreign currencies (like USD) to 10 minutes by default, and refreshes them with current exchange rates when they expire. Previously, such invoices could remain valid for the full recurrence period, meaning a merchant or payer could be locked into an outdated exchange rate for a long time. The patch also improves error messages so users can tell the difference between a cancelled invoice and one that simply expired.

This commit tightens the expiration time on invoices created from BOLT12 offers. Previously, all such invoices defaulted to a 2-hour payment window. Now, if the offer has an absolute expiry, the invoice expires when the offer expires; and if the offer uses a foreign currency, the invoice expires in 10 minutes (or a developer-tunable value). This reduces the window in which an attacker can exploit stale exchange rates or expired offers.

This commit removes local timing checks in Core Lightning's fetchinvoice plugin for recurring payments. Instead of the plugin refusing too-early or too-late invoice requests, it now lets the remote node decide and report back. The change is described by the author as a simplification, moving responsibility to a separate plugin and the user. It is not presented as a security fix, and the tests are updated to expect remote error messages rather than local ones.

This commit removes a local sanity check in Core Lightning's experimental 'createinvoicerequest' command. Previously, when creating a recurring invoice request, the code looked up past payments by label to verify the previous recurrence was paid and to copy timing data. Now it skips that lookup and lets the remote node decide. The change also renames the 'recurrence_label' parameter to the simpler 'label'. It is described by the author as a cleanup of an undocumented interface, not as a security fix.

This commit fixes how the fetchinvoice plugin handles user-supplied labels that contain special characters such as backslashes, quotes, tabs, and newlines. Previously these labels were passed as raw strings, which could cause JSON encoding problems when the plugin forwarded the label to other parts of the lightning node. The change now parses the label through a JSON-aware escaping helper and writes it back out as a safely escaped JSON string. The included test demonstrates that weird labels now work correctly for recurring invoices and cancellations.

This commit only adds a new automated test file that checks how a helper function (str_to_u64) converts text strings to unsigned 64-bit integers. It does not change any production code, so it cannot by itself introduce a security vulnerability or fix one. The tests verify that the function correctly handles normal numbers, overflow, invalid characters, and leading zeros.

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 subsystem is cleanly removed while other askrene data survives. The code change itself is purely a test and a marker comment in the migration list; it does not fix an active security vulnerability.