restorable

Verification page

Trust artifacts.

The cryptographic identities behind every Restorable release and every signed receipt. Cross-check what you received against what is listed here, through at least two of the independent channels in each section.

For the conceptual picture of what receipts prove and where the trust boundaries lie, read the trust model.

minisign release key raw binaries · version manifest
short id
70631FFF403CC6D7
public key
RWTXxjxA/x9jcGpnMX7I1A27jvHNjlwCx4SePW+uQ/VxUG+v3kncGRDX
published
verify 
curl -O https://get.restorable.app/pub/restorable-release.pub
minisign -V -p restorable-release.pub \
  -m restorable-linux-amd64 \
  -x restorable-linux-amd64.minisig
version manifest
The same key signs the channel manifest at get.restorable.app/versions/manifest.json (signature at .minisig). It carries manifest_version, issued_at, expires_at, and per-version EOL plus download URLs.
verify manifest 
curl -O https://get.restorable.app/versions/manifest.json
curl -O https://get.restorable.app/versions/manifest.json.minisig
minisign -V -p restorable-release.pub \
  -m manifest.json \
  -x manifest.json.minisig
gpg release key .deb · .rpm · apt + dnf repo metadata
fingerprint
B0AB C5E6 8D8D 0852 6763 6294 18EE 942B E09A D38F
primary key id
18EE942BE09AD38F
signing subkey
8D8D5E3586E374B5
user id
Restorable Release Signing <release@restorable.app>
published
verify 
curl -O https://get.restorable.app/pub/restorable-release.gpg
gpg --show-keys restorable-release.gpg | head -2
# fingerprint should equal the one above
receipt signing dsse · per organization
scheme
Every receipt is signed by an Ed25519 keypair the customer's agent generates on first run. The private half stays on the customer's host. The public half registers with the orchestrator and is the cryptographic root for every receipt attributed to that agent.
key
Ed25519, generated locally by the agent
storage
private half: customer host only · public half: orchestrator + receipt header
verify 
restorable-verify --pubkey customer-key.pub receipt.intoto.json
further
The auditor flow lives at verifying a receipt.

Reproducible builds

Rebuilding the agent and verifier from the published source at the same tag, with the pinned toolchain, must produce the same binary hashes that the minisign signature attests to. Each release runs this verification end-to-end in CI before publish; if the rebuild diverges, the release aborts before any artefact reaches get.restorable.app.

rebuild recipe go 1.25.9 · goreleaser v2.15.4
step 1
Fetch the published checksums and verify the minisign signature. A CDN compromise can serve different bytes; the signature can only be made by the offline release key.
verify checksums 
VERSION=v0.4.6
curl -fsSLO "https://get.restorable.app/${VERSION}/checksums.txt"
curl -fsSLO "https://get.restorable.app/${VERSION}/checksums.txt.minisig"
curl -fsSLO "https://get.restorable.app/pub/restorable-release.pub"
minisign -V -p restorable-release.pub \
  -m checksums.txt -x checksums.txt.minisig
step 2
Clone the source at the matching tag and rebuild with the pinned goreleaser version. CGO_ENABLED=0 + -trimpath + mod_timestamp are pinned in the repo's .goreleaser.yaml.
rebuild 
git clone https://codeberg.org/restorable/restorable.git rebuild
cd rebuild && git checkout "$VERSION"
GORELEASER_VERSION=v2.15.4
curl -fsSL \
  "https://github.com/goreleaser/goreleaser/releases/download/${GORELEASER_VERSION}/goreleaser_Linux_x86_64.tar.gz" \
  | tar -xz goreleaser
GORELEASER_CURRENT_TAG="$VERSION" ./goreleaser build --clean
step 3
Compare hashes. The four Linux binaries (restorable and restorable-verify, amd64 and arm64) must match the published checksums.txt byte for byte. .deb and .rpm archives are intentionally not byte-stable; their integrity is anchored by the GPG package signature instead.
compare 
cd dist
for b in restorable-linux-{amd64,arm64} \
         restorable-verify-linux-{amd64,arm64}; do
  rebuilt="$(find . -name "$b" -type f | head -1)"
  printf '%s  %s\n' \
    "$(sha256sum "$rebuilt" | awk '{print $1}')" "$b"
done | diff - <(grep ' restorable\(-verify\)\?-linux-' \
    ../checksums.txt) && echo "OK: rebuild matches"

The full long-form recipe lives in the source tree at docs/reproducible-builds.md, including failure modes and what is and isn't reproducible. Receipts produced by restorable carry an agent_build_sha256 field that lets an auditor cross-reference the running binary against the published rebuild.

Backup immutability

Customer backups are structurally undeletable for their retention period. This is not a policy or a promise. It is enforced by two independent mechanisms that would both need to fail simultaneously for a backup to be removed early.

immutability layers
layer 1
Least-privilege credentials. The orchestrator's runtime credentials have read and write permission only. No delete permission exists on the running service. Even a full compromise of the orchestrator process cannot issue a DeleteObject call.
layer 2
Object Lock, Compliance mode. Every backup blob receives S3 Object Lock retention at registration time. In Compliance mode, no principal (including the storage account root) can delete or overwrite the object before retention expires. The retention period matches the customer's tier: 30 days (Starter), 90 days (Pro), 365 days (Team).
enforcement
If the retention call fails during backup registration, the registration is rejected. The agent retries on the next scheduled run. No backup is ever recorded without immutability confirmed.
retention
Starter 30d · Pro 90d · Team 365d
mode
S3 Object Lock, Compliance (WORM)
delete path
Scheduled expiry only. No manual override.

The architectural decision is recorded as D034. GDPR Article 17 erasure requests are handled through a documented multi-party procedure; they do not bypass the technical controls described above.

Key rotations

No rotations to date. Each rotation will be logged here with the date, new fingerprint, and the channels through which the new key was announced. Customers running apt upgrade or dnf upgrade migrate automatically; raw-binary installs re-import the new minisign pubkey on the next install.