v0.7.0-rc.7

Release candidate for testing managed node updates. Use only on disposable, unfunded public Signet nodes.

Updates a node running v0.7.0-rc.6 to Bitcoin Core 29.3, LND 0.21.2-beta and, where installed, Syncthing 2.1.5, and refreshes the LND service unit.

Changes since v0.7.0-rc.5: an installed node keeps working when a later release changes its update record or plan; a node that skipped a release is told which release to install first; Cancel is decided by whether services were touched; the final disk-space check shows its own status. Nodes running v0.7.0-rc.5 or earlier cannot update to this release.

The release executable was reproduced byte for byte from signed tag v0.7.0-rc.7 using Go 1.26.8. This candidate has not yet completed Debian integration testing.

v0.7.0-rc.6

Development prerelease to test managed node updates on disposable, unfunded public Signet nodes running Debian 13 amd64. This replaces RC3 as the fresh installation baseline.

An installed node now keeps working when a later release changes its update record or plan, and a node that skipped a release is told which release to install first. Nodes running v0.7.0-rc.5 or earlier cannot update to this release line; install it fresh.

• Bitcoin Core 29.2
• LND 0.21.1-beta
• Syncthing 2.1.3 (optional)

The release executable was reproduced byte for byte from signed tag v0.7.0-rc.6 using Go 1.26.8. This candidate has not yet completed Debian integration testing.

v0.7.0-rc.5

Release candidate for testing managed node updates. Use only on disposable, unfunded public Signet nodes.

Updates a node running v0.7.0-rc.3 to Bitcoin Core 29.3, LND 0.21.2-beta and, where installed, Syncthing 2.1.5, and refreshes the LND service unit.

Changes since v0.7.0-rc.4:

• Free disk space is now checked before any service is stopped. If there is not enough, the update is refused, services keep running, and the update can be cancelled or retried.
• Downloaded component files are removed after a successful update and after a space refusal.

This candidate has not yet completed Debian integration testing.

v0.7.0-rc.4

Development prerelease to test managed node updates from v0.7.0-rc.3 on disposable, unfunded public Signet nodes running Debian 13 amd64.

RC3 and RC4 replace the earlier RC1 → RC2 test pair. Both include fixes for Syncthing version checks and update errors disappearing during background refresh. RC3 is the corrected fresh installation baseline; RC4 replaces RC2 as the update target.

This candidate updates:

• Bitcoin Core to 29.3
• LND to 0.21.2-beta
• Syncthing to 2.1.5, where already installed

It also refreshes LND’s service unit.

Known issue: the updater can leave services stopped if free space drops below its minimum during preparation. Test with ample free disk space.

The release executable was reproduced byte for byte from signed tag v0.7.0-rc.4 using Go 1.26.8.

v0.7.0-rc.3

Development prerelease to test managed node updates on disposable, unfunded public Signet nodes running Debian 13 amd64.

This replaces RC1 as the fresh installation baseline. It corrects Syncthing version checks and keeps update errors visible during background refresh.

• Bitcoin Core 29.2
• LND 0.21.1-beta
• Syncthing 2.1.3 (optional)

The release executable was reproduced byte for byte from signed tag v0.7.0-rc.3 using Go 1.26.8.

v0.7.0-rc.2

Development prerelease to test managed node updates from v0.7.0-rc.1 on disposable, unfunded public Signet nodes running Debian 13 amd64.

This candidate updates:

• Bitcoin Core to 29.3
• LND to 0.21.2-beta
• Syncthing to 2.1.5, where already installed

It also refreshes LND’s service unit.

Known issue: the updater can leave services stopped if free space drops below its minimum during preparation. Test with ample free disk space.

The release executable was reproduced byte for byte from signed tag v0.7.0-rc.2 using Go 1.26.8.

v0.7.0-rc.1

Development prerelease to test managed node updates on disposable, unfunded public Signet nodes running Debian 13 amd64.

This candidate uses earlier component versions as a fresh installation baseline for testing upgrades in the next candidate:

• Bitcoin Core 29.2
• LND 0.21.1-beta
• Syncthing 2.1.3 (optional)

The release executable was reproduced byte for byte from signed tag v0.7.0-rc.1 using Go 1.26.8.

v0.6.3

Syncthing privacy fix and release pinning

This release fixes a privacy bug in the Syncthing add-on, pins Syncthing to a verified release the same way Bitcoin Core and LND are pinned, and fixes a second bug that weakened the channel backup folder's protection when pairing a device.

If you do not use the Syncthing add-on, just update from System, Self-Update. Nothing else applies to you.

What happened

The Syncthing add-on was supposed to disable global discovery, local discovery, relays, and NAT traversal. It did not. A bug in how the installer edited Syncthing's configuration caused those settings to silently revert to their defaults on every install. Every node with the add-on installed has been announcing its device ID and public IP address to Syncthing's public discovery and relay servers since the add-on shipped.

What this exposed: the fact that your server runs Syncthing, its device ID, and its public IP, published to public directory infrastructure. What this did not expose: your channel backup data (protected by Syncthing's mutual TLS, only devices you approved could ever connect), your keys, or your funds. The README's claim that discovery and relays were disabled was false on every deployment before this release. We are sorry for that.

What changed

Syncthing is now pinned to a specific verified release (v2.1.1), downloaded over Tor and verified against the Syncthing release signing key's known fingerprint, exactly like Bitcoin Core and LND. The apt repository is no longer used, and the binary's self-update is switched off. The version only changes when a release deliberately changes it, after review.

With the version fixed, the installer now writes Syncthing's entire configuration itself before the daemon ever starts, then verifies every privacy setting and refuses to start (and disables) Syncthing if anything does not check out. The privacy settings were verified live on fresh installs: packet capture, socket sampling, daemon logs, and the running daemon's reported configuration all showed zero discovery, relay, or NAT traversal traffic, from the daemon's very first start.

Honest scope: this defends every currently known discovery and announce mechanism, verified before the daemon starts. It cannot anticipate settings a future Syncthing version might add. Pinning is the control for that: the version cannot change without a deliberate review, and the installer hard-fails if it ever finds a version it has not been reviewed against.

Also fixed: pairing a backup device quietly switched the backup folder from "send only" to "send and receive", letting a paired device change or delete the node's copy of the channel backup. LND's own files were never at risk: the node copies the channel backup out of LND's data directory into the synced folder, and nothing copies back. Folder updates now preserve the folder type, and paired devices no longer get permission to auto-share folders to the node. The Syncthing install is also about 30 seconds faster (a readiness probe was checking an endpoint that always refused it).

If you already use the Syncthing add-on: migration

Existing installs have the apt-era Syncthing and the misconfigured settings. Five steps move you to the pinned setup. Your channel backup stays safe throughout: LND's own backup file is never touched, and your local device keeps its copy the whole time.

1. Update to v0.6.3 from the dashboard: System, Self-Update.

2. Press ctrl+c to drop to the shell, then paste this block:

sudo systemctl stop syncthing && sudo systemctl disable syncthing
sudo apt-get purge -y syncthing
sudo rm -f /etc/apt/sources.list.d/syncthing.list /etc/apt/keyrings/syncthing-archive-keyring.gpg /etc/systemd/system/syncthing.service
sudo systemctl daemon-reload
sudo rm -rf /etc/syncthing /var/lib/syncthing
sudo python3 - <<'EOF'
import json
p = "/etc/rlvpn/config.json"
c = json.load(open(p))
c["syncthing_installed"] = False
c.pop("syncthing_password", None)
c["syncthing_devices"] = []
json.dump(c, open(p, "w"), indent=2)
EOF

Confirm the reset took (it should print "syncthing_installed": false):

grep -o '"syncthing_installed": [a-z]*' /etc/rlvpn/config.json

3. Type rlvpn to relaunch the dashboard, open Add-On, and install Syncthing. This installs the pinned, verified release.

4. On your local device: remove the old node entry in your Syncthing (the node has a new identity), then pair again from the dashboard. Enter the node's address manually as tcp://YOUR-NODE-IP:22000 (discovery is off by design, so automatic address resolution will not find the node). The first connection can take a couple of minutes.

5. Accept the backup folder share on your device and set it to Receive Only. Your channel backup syncs over within seconds.

These steps were verified end to end on a production deployment, including the self-update, before this release was published.

Everything in this release

• Syncthing pinned to a verified release binary (v2.1.1), GPG-verified over Tor, apt repository removed, self-update disabled
• Syncthing configuration written in full by the installer and verified before first start; the install fails loudly and leaves the daemon disabled if any privacy setting does not verify
• Discovery (global and local), relays, NAT traversal, usage reporting, and crash reporting confirmed off on the running daemon
• Device pairing no longer reverts the backup folder to two-way sync; paired devices cannot auto-share folders to the node
• Syncthing install completes about 30 seconds faster
• README corrections to match the above

Full Changelog: v0.6.2...v0.6.3

v0.6.2

Atomic Privileged File Writes

Privileged files were written with cp then chmod, a two-step sequence that left a brief window where the file existed with incorrect permissions. For wallet_password, the LND unlock secret was momentarily readable by other users on the system during first creation, and a crash between the two steps could leave the file with the wrong permissions. This release hardens all 20 root-owned write operations and the wallet_password auto-unlock path.

• Every privileged write now stages content via install -m to a same-directory temporary file with correct permissions already applied, then atomically renames it into place via rename(2). The live file only ever holds old content or finished new content, never a partial or widened state
• wallet_password is now written via install -m 0400 -o bitcoin -g bitcoin so ownership is set at staging time rather than as a separate step. A failed ownership change now halts the operation instead of being silently ignored
• Write failures are logged to /var/log/rlvpn.log with the target path and OS error only, no secrets. Failed writes clean up their staging file and never touch the live file

What's Changed

• fix: write privileged files atomically to close a permissions gap by @ripsline in #88
• release: v0.6.2 by @ripsline in #89

Full Changelog: v0.6.1...v0.6.2

v0.6.1

Signature Verification Hardening

The previous verification code downloaded the correct signing keys and GPG did verify signatures against them, so installed software was genuine. But the verification logic had two gaps: signatures were accepted from any key in the shared keyring (not just the intended signer), and the fingerprint checks only confirmed the key was downloaded, not that it was used to sign the release. This release closes both gaps.

• All three verification paths (self-update, Bitcoin Core, LND) now use a shared helper with ephemeral GPG keyrings, VALIDSIG primary-fingerprint matching, and distinct-signer counting
• The GPG exit code is no longer trusted on any path
• 5 signing-key fingerprints corrected to primary-key values
• Download pipelines use random working directories instead of fixed /tmp paths
• 6-case test suite covering pinned-key acceptance, tampered file rejection, unpinned-key rejection, duplicate-signer deduplication, multi-signer threshold, and subkey-to-primary resolution

What's Changed

• fix: verification keyring binding by @ripsline in #86
• release: bump v0.6.1 by @ripsline in #87

Full Changelog: v0.6.0...v0.6.1