Security & signing

How to verify the Tunnelbyte binary and apt repository, and what we sign with.

Apt repository signing key

The apt.tunnelbyte.dev repository is signed with a long-lived ed25519 key. Before adding the key to your apt keyring, verify the fingerprint matches what’s published here.

Fingerprint: 1DB4 AD58 0221 6E35 6A9C D18D 8C4E C630 575A FA52

Manual verification

curl -fsSL https://apt.tunnelbyte.dev/tunnelbyte.asc -o /tmp/tunnelbyte.asc
gpg --show-keys /tmp/tunnelbyte.asc

The output’s Key fingerprint line should match the value above byte-for-byte. If it doesn’t, do not install - email [e-mail] and we’ll investigate.

Release artefacts

Every GitHub release at github.com/tunnelbyte/tunnelbyte/releases ships a checksums.txt file. The one-line installer (install.sh) verifies SHA256 against this file before running anything. The Homebrew formula pins SHA256 per arch at formula-publish time.

If you download a tarball directly:

shasum -a 256 -c checksums.txt --ignore-missing

What we sign

Artefact	Signature	Verified by
Apt repo Release file	GPG (ed25519, our key)	apt update automatically
.deb package	Repo-level, not package-level	apt install (via Release)
GitHub release tarballs	SHA256 in checksums.txt	install.sh, Homebrew formula
macOS binary (notarization)	Not yet - see quickstart Gatekeeper note	-

What we don’t sign yet

A macOS notarization certificate is on the roadmap but not yet in place. Until then, the macOS quarantine attribute is stripped automatically by the installer and Homebrew formula; on first direct download you’ll see a Gatekeeper warning.

Operational safeguards

These aren’t user-facing surfaces but they shape what a worst-case incident actually exposes.

• End-to-end encrypted backups. Nightly Postgres dumps are streamed through age (X25519 + ChaCha20-Poly1305) before they hit our R2 bucket. The recipient pubkey lives in the env file on the control plane; the private key is offline. A leaked R2 access key alone cannot decrypt a backup.
• WG node egress allowlist. Every WireGuard exit node ships an iptables chain installed at first boot (tb-wg-filter.sh) that REJECTs outbound SMTP (25 / 465 / 587 / 2525) and IRC (6660-6669, 6697), pins DNS to a single resolver, and drops any packet on wg0 whose source isn’t inside the assigned peer subnet (anti-spoof).
• Webhook idempotency. Inbound Stripe webhook deliveries are deduplicated against a journal table keyed on event_id. A redelivered or replayed event cannot flip account state twice.
• Two-step magic-link confirm. Verify pages render a confirm button on GET; only the POST consumes the one-shot token. This defeats Slack / iMessage / Outlook Safe Links preview crawlers that would otherwise burn the link before you click it.
• Loopback-trusted proxy parsing. X-Forwarded-For is only honoured when the direct TCP peer is loopback (Caddy in front of the control plane). Client-supplied XFF from a public peer is ignored, so per-IP rate limits and per-ASN abuse caps can’t be bypassed by spoofing the header.

Reporting security issues

[e-mail] - PGP key forthcoming. Please include a clear reproduction; do not file public GitHub issues for security reports.