Core Lightning

This commit only adds and removes test input files used by an automated fuzz-testing harness for a bigsize parser. It is purely a test-data update and does not change any production code, configuration, or behavior of the Core Lightning node software.

This commit adds safety checks to two internal functions that multiply cryptocurrency amounts by a scaling factor. Previously, if the scaling factor was a malformed 'not-a-number' value or a negative number, the function could produce undefined or nonsensical results. Now the functions reject those inputs outright. The commit message says the factor can come from network data, so this is a hardening fix against bad or malicious input.

This commit only adds new test input files to a fuzz-testing seed corpus. It does not change any production code, configuration, or documentation. There is no indication of a security fix or vulnerability being addressed.

This commit adds a new check inside an existing automated test (a fuzz test) for Core Lightning. It makes sure that when the software converts a Bitcoin script into a human-readable address and then converts that address back, the result matches the original script. It does not change any production code, user-facing behavior, or network handling. It is purely a stronger test case.

This commit only adds test data files (a seed corpus) for a fuzzing test. Fuzzing is an automated testing technique that feeds random or crafted inputs to a program to find bugs. These files are not part of the production Core Lightning software that users run, so they cannot directly cause a security issue in a live node. There is no indication in the commit that any vulnerability was found or fixed.

This commit adds a new automated fuzz test for a Lightning network channel-closing message called 'closing_sig'. It only adds test code and does not change any production code, so it cannot introduce a runtime security vulnerability by itself. It is a defensive testing improvement.

This commit only adds test data files (a fuzzing seed corpus) for a new fuzz test named fuzz-wire-closing_complete. It does not change any production code, configuration, or runtime behavior. There is no indication of a security fix or vulnerability being addressed.

This commit adds a new automated fuzz test for a Lightning network channel-closing message called 'closing_complete'. It does not change any production code, network behavior, or security logic. It only adds a test file that checks whether the message can be encoded and decoded correctly.

This commit fixes file descriptor leaks in the project's test suite. It replaces patterns like open(...).read() with context managers or helper methods that automatically close files. These changes only affect test code and test infrastructure, not the actual Core Lightning node software that users run. The leak could cause tests to run out of file handles during long test runs, but it is not a security vulnerability in production software.

This is a small cleanup change in the Python testing helper for Core Lightning. It makes sure log files are closed when test nodes are torn down, preventing file descriptor leaks during automated tests. There is no security relevance in the commit itself.

This commit fixes a minor resource leak in a Python testing utility. The original code opened a small configuration file but never explicitly closed it. The fix uses Python's 'with' statement to ensure the file is closed automatically after reading. This is a code-quality improvement with no practical security impact.

This commit fixes a file descriptor leak in the Python client library used to talk to Core Lightning. When connecting to a Unix socket whose path was too long, the code opened a temporary directory file descriptor but never closed it. Over time this could exhaust the process's allowance of open files, causing test failures or potentially disrupting normal operation. The fix wraps the socket connection in a try/finally block so the temporary descriptor is always closed.

This is a small cleanup in a Python testing helper that makes sure a gossip-store file is closed when the object is destroyed or reopened. It fixes a file-descriptor leak in test infrastructure, not in the actual Core Lightning node software. There is no direct security impact on live Lightning nodes or user funds.

This is a small testing-framework fix that stops passing a developer-only option ('dev-save-plugin-io') to older versions of Core Lightning. The option only exists in newer code, so without the version check, tests against older CLN releases would fail to start. It is not a security patch for production software.

This commit is a documentation and release-script hardening change. It ensures that version numbers used during Core Lightning releases always start with the letter 'v' (for example, v23.05 instead of 23.05). It updates the release checklist instructions and adds a safety check in the build-release.sh script that exits with an error if the version is missing the 'v' prefix. There is no security vulnerability being fixed here.

This commit is a routine release-process improvement. It changes the filename of the release checksum file from SHA256SUMS to SHA256SUMS-v25.09 (with the version number appended) so that multiple releases in the same folder do not overwrite or confuse each other. The documentation and GitHub release workflow are updated to match the new filename. There is no security vulnerability here.

This commit simply removes references to a community platform called BuildOnL2 from documentation files. It replaces those references with Telegram in a few release announcement instructions. There is no code change and no security impact.

This commit only changes the order of steps in a release checklist document. It moves the local build-and-sign steps before pushing the release tag to GitHub, so a broken release is caught before a public tag is created. There is no code change and no security vulnerability is being fixed.

This commit is a build-script hardening change, not a fix for an exploitable vulnerability. It makes the release-zip build process fail early if the 'lowdown' tool is missing, so that different developers or CI environments don't accidentally produce release zip files with different contents. That reproducibility problem could in theory allow someone to ship a tampered release by claiming it was built without lowdown, but the commit itself does not describe any such attack and there is no direct evidence of one.

This commit simply edits an internal project document (the release checklist) to remove a suggestion that developers wait one week after a release before deciding whether a point release is needed. It is purely a process/documentation change and has no effect on the software's code, behavior, or security.

This commit only adjusts whitespace (tabs to spaces) in two build helper scripts. There is no change to program logic, no new behavior, and no security relevance.

This change simply speeds up the project's release build scripts by allowing them to compile multiple parts at once (parallel make). It does not fix or introduce any security issue.

This commit only updates the project's internal release checklist documentation. It changes several example commands to include 'uv run' in front of 'make' so they work with the project's Python tooling setup. There is no code change, no bug fix, and no security relevance.

This commit only updates the project's internal documentation for how release managers run the release checklist. It changes wording and step ordering in a markdown file, telling maintainers which CI workflow triggers automatically and how to compare and sign checksum files. No software code, build scripts, CI definitions, or cryptographic handling were modified.

This change updates the release build script so that it no longer hardcodes 'sudo' before every Docker command. Instead, a new '--sudo' flag lets the release manager opt in to using sudo only when their system requires it. The accompanying documentation is updated to mention the new flag and to adjust supported Ubuntu versions. This is a minor developer-experience and hardening improvement, not a fix for an active security vulnerability.