Skip to content

v26.06.7 Quantum-Resistant Lightning Channel VII

Latest
Latest

Choose a tag to compare

View all tags
@nGoline nGoline released this 28 Aug 16:08
· 295 commits to master since this release
v26.06.7
This tag was signed with the committer’s verified signature.
nGoline Níckolas Goline
GPG key ID: 578CAC08472545C5
Verified
Learn about vigilant mode.
8684c68

This point release includes fixes for vulnerabilities responsibly reported by a number of sources. It also comes at a time when increasingly capable AI models are being used to identify potential vulnerabilities in open-source code, significantly increasing the volume and pace of security reports.

The potential impact and associated risks are front of mind for everyone involved, not least the remediation team who have worked tirelessly to triage, resolve, and compile this release.

This embargo period will last for two weeks. The source code will not be published until 14 days have passed. During this time, we strongly encourage everyone to upgrade. At the end of this two-week period, the full release details will be made available.

This delay is designed to reduce the chances of prospective attackers reverse-engineering the fixes and exploiting them before the network can update.

The embargo has ended. The source for this release was published on 2026-09-11T11:42Z. The v26.06.7 tag now points at the commit these binaries were built from, and the source archive clightning-v26.06.7.zip is attached below.

Upgrading

Download the tarball for your platform below, verify it (see next section), then unpack it over your existing installation:

sudo tar -xvf <release>.tar.xz -C /usr/local --strip-components=2

Restart lightningd afterwards. No database migration steps are required beyond the automatic ones applied at startup.

Docker users

Docker images for this release are published and correct.

Tag Digest
v26.06.7, latest sha256:0421a5f0d1b2e1ad639edfa17d777816040e3850d91bae7f2d32186d9c1e6da4
v26.06.7-vls, latest-vls sha256:6a5e05c13a65613f8c0fe3830c60248a6724e7206c1c23dd26ac2e98a3e72c1f

Platforms: linux/amd64, linux/arm64, linux/arm/v7.

If you pulled v26.06.7, latest, v26.06.7-vls or latest-vls before reading this, check the digest and re-pull if it does not match the table above.

Between 28 August 16:04 UTC and 1 September, those tags served images that reported v26.06.7 on startup but did not contain the fixes in this release. They were published automatically by CI from a placeholder tag. They have been replaced, and the incorrect manifests are no longer referenced by any tag.

Check what you are running:

docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7

If the digest does not match the table above, re-pull:

docker pull elementsproject/lightningd:v26.06.7
docker pull elementsproject/lightningd:latest

Users pinned to v26.06.6 or earlier were never affected.

VLS users

v26.06.7-vls carries the same signer as v26.06.6-vls, VLS v0.14.0, unchanged by this release.

The signer requires VLS_CLN_VERSION to match the node it talks to. Update it from v26.06.6 to v26.06.7 when you upgrade, or remote_hsmd_socket will refuse to start.

Notes on these images

  • They are assembled from the signed release tarballs above rather than compiled from source, so the binaries in the container are the ones covered by the signed manifests.
  • linux/arm/v7 has no release tarball. Its binaries are cross-compiled separately and are not covered by a signed manifest.
  • The images carry no provenance or SBOM attestations.
  • CLN now installs to /usr/bin and /usr/libexec/c-lightning; previous images used /usr/local. Symlinks from the old locations are included, so hardcoded paths keep working.

Verifying your download

Every binary is covered by a signed manifest. Check the checksums first:

sha256sum -c SHA256SUMS-v26.06.7 --ignore-missing

Then the signatures:

gpg --verify SHA256SUMS-v26.06.7.asc SHA256SUMS-v26.06.7

SHA256SUMS-v26.06.7 covers the amd64 tarballs and is signed by maintainers. SHA256SUMS-v26.06.7-arm64 covers the arm64 tarballs and has its own signature file. Signing keys:

Signer Fingerprint
nGoline 4E4A 142F 8BD3 C38A 56B3 62ED 578C AC08 4725 45C5
Christian Decker B731 AAC5 21B0 1385 9313 F674 A26D 6D9F E088 ED58
Peter Neuroth 653B 19F3 3DF7 EFF3 E9D1 C94C C3F2 1EE3 87FF 4CD2
daywalker90 8A07 9421 A871 D0B1 0835 1193 7AB4 802E D5A6 39F3

Fetch them with gpg --recv-keys <fingerprint>, or from the contrib/keys/ directory of the repository once the source is published.
Fetch these keys from a keyserver, for example gpg --recv-keys <fingerprint>. Two of the four, Christian Decker's and Peter Neuroth's, are also in the contrib/keys/ directory of the source. The other two were added on master; the tree at this tag cannot change, since these artifacts are built from it.

A signature may report a fingerprint that differs from the one listed above. Signers use signing subkeys, and the reported fingerprint is the subkey of the listed primary. That is expected and is not a verification failure. gpg --verify resolves it for you once the primary key is imported.

Reproducing these binaries

The source for this release is now published: the v26.06.7 tag points at the tree these artifacts were built from.

These tarballs were not built with the repository's default optimisation level. configure defaults to -Og, and the release binaries were built at -O3. Checking out the tag and running the normal reproducible build will produce binaries that do not match the checksums above. COPTFLAGS=-O3 has to be passed explicitly.

tools/build-release.sh cannot pass it through, because it forwards only FORCE_MTIME, FORCE_VERSION and MAKEPAR into the build containers. The containers have to be invoked directly.

Start from a clean checkout of the tag with submodules initialised:

git clone https://github.com/ElementsProject/lightning && cd lightning
git checkout v26.06.7
git submodule update --init --recursive

This covers the amd64 tarballs. See the arm64 note below.

Build the base images once (contrib/cl-repro.sh, or docker build from contrib/reprobuild/Dockerfile.<dist>), then:

mkdir -p release
for d in jammy noble resolute; do
  docker run --rm -v "$(pwd)":/repo \
    -e FORCE_MTIME=2026-08-26 -e FORCE_VERSION=v26.06.7 -e MAKEPAR=8 \
    -e COPTFLAGS=-O3 cl-repro-$d
done

For Fedora:

DOCKERFILE=contrib/docker/Dockerfile.builder.fedora
FV=$(grep -oP '^FROM fedora:\K[0-9]+' $DOCKERFILE)
docker build --no-cache -f $DOCKERFILE -t fedora --load .
docker run --rm -v "$(pwd)":/src:ro -v "$(pwd)/release":/release \
  -e COPTFLAGS=-O3 fedora \
  /src/tools/build-release.sh --inside-docker v26.06.7 Fedora $FV amd64 8

Confirm the flag actually reached the compiler. The build log must contain:

Setting COPTFLAGS... -O3 -ffunction-sections

Do not infer it from tarball size. You can also check a finished binary:

strings -a usr/bin/lightningd | grep 'GNU C11'
# expect: GNU C11 ... -g -O3 -std=gnu11 ... -ffunction-sections

Then compare against the signed manifest:

sha256sum -c SHA256SUMS-v26.06.7 --ignore-missing

The arm64 tarballs cannot be reproduced from this tag

SHA256SUMS-v26.06.7-arm64 covers the three arm64 tarballs, and those signatures verify normally. Rebuilding them does not work from this source, because the tooling that produced them is not in this tree: the arm64 build script, the arm64 signing script, and the arm64 support in the contrib/reprobuild/ Dockerfiles are not part of the v26.06.7 source. That work is being upstreamed separately and is not included here.

Until it lands, the arm64 tarballs are verifiable by signature but not independently reproducible. The amd64 tarballs and the source archive are both.

Known caveats

  • Fedora may not reproduce. build-release.sh rebuilds the Fedora builder image with --no-cache, and that image is FROM fedora:40 with a live dnf update and a wget of Bitcoin Core. Two people building days apart can pick up different toolchains. If every Ubuntu target matches and only Fedora differs, this is why. It predates this release.
  • linux/arm/v7 has no release tarball. The Docker image for that platform is cross-compiled separately and is not covered by any manifest.
  • Only linux/amd64 is reproducible from this source, per the arm64 note above.
  • -O3 is a one-off for this release. It is deliberately not committed to the tree, so it cannot silently become permanent tooling. Future releases build at the default.

Verifying the source itself

Reproducing the binaries takes hours. Verifying that the source now published is the source that was signed in August takes minutes and needs no compiler.

SHA256SUMS-v26.06.7 has always contained a line for clightning-v26.06.7.zip, the complete source archive including submodules. That manifest was signed on 28 August, before the source was public, so the signature is a commitment made in advance to exactly the bytes published now.

git clone https://github.com/ElementsProject/lightning && cd lightning
git checkout v26.06.7
git submodule update --init --recursive
tools/build-release.sh --force-version=v26.06.7 --force-mtime=2026-08-26
sha256sum release/clightning-v26.06.7.zip
# b313d207e53f1e2dbf9fbac79d5af48c352e874a653390bddb81b52795a153dc

No extra flags are needed: the archive is source only, so -O3 does not apply, the file order comes from git ls-files, and permissions and timestamps are normalised by the script. It requires GNU coreutils, so it will not run on stock macOS.

Do not use GitHub's automatically generated "Source code (zip/tar.gz)" links for this. They are not signed, they are not covered by any manifest, they omit submodule contents, and their bytes depend on the tag object rather than only on the source. Use the clightning-v26.06.7.zip asset attached to this release.

Reports Received from (No Particular Order)

The Most Thoughtful Remediation Team

Notes

The "Source code (zip)" and "Source code (tar.gz)" links that GitHub attaches to this release are not the v26.06.7 source. They are generated automatically and cannot be removed. The v26.06.7 source will be published when the embargo ends, 14 days from this release. Do not build from those archives expecting to get these binaries.
Use the attached clightning-v26.06.7.zip, not the "Source code (zip)" and "Source code (tar.gz)" links GitHub generates. Those are now generated from the correct tag, but they omit submodule contents, they are not covered by any signed manifest, and their bytes depend on the tag object rather than only on the source. The attached zip is the archive the signed manifest commits to.

A commitment to the source has been published in advance. SHA256SUMS-v26.06.7 includeshas always included an entry for clightning-v26.06.7.zip, the source archive, even though that file is not attached to this releasewhich is now attached to this release. Because the manifest iswas signed and published todayon 28 August, before the source was public, anyone can confirm when the source appears that it is the same source these binaries were built fromthat the source published now is the same source these binaries were built from, and that nothing was altered during the embargo.

Reproducing the binaries. Full build instructions will accompany the source release. This release was not built with the default optimisation settings, so a standard build will not reproduce these checksums; the exact parameters will be published alongside the source. Build instructions are in the "Reproducing these binaries" section above. This release was not built with the default optimisation settings, so a standard build will not reproduce these checksums; COPTFLAGS=-O3 must be passed explicitly.

Assets 14
Loading