Installing restorable-verify

This page is for auditors and compliance teams who received a receipt file and a public key from their client. You do not need a Restorable account, an API key, or network access to any Restorable service. Everything runs offline.

What you need

1. A receipt file (.intoto.json). Your client forwards this from the weekly evidence email or exports it from their dashboard.
2. The customer's Ed25519 public key. Your client exports it from their dashboard (Agents → [agent] → Public key). Save it as a file (e.g. customer.pub). The key is stable across receipts; you only need it once per agent.
3. The restorable-verify binary for your platform.

Download the binary

Pre-built binaries are published at get.restorable.app for every release. Each binary is signed with the Restorable minisign release key.

Linux (amd64)

VERSION=v0.4.6
curl -fsSLO "https://get.restorable.app/${VERSION}/restorable-verify-linux-amd64"
curl -fsSLO "https://get.restorable.app/${VERSION}/restorable-verify-linux-amd64.minisig"
chmod +x restorable-verify-linux-amd64

macOS (Apple Silicon)

VERSION=v0.4.6
curl -fsSLO "https://get.restorable.app/${VERSION}/restorable-verify-darwin-arm64"
curl -fsSLO "https://get.restorable.app/${VERSION}/restorable-verify-darwin-arm64.minisig"
chmod +x restorable-verify-darwin-arm64

Build from source

If your security policy requires building from source, clone the repo and build with Go 1.25+:

git clone https://codeberg.org/restorable/restorable.git
cd restorable
make build
# binary at ./bin/restorable-verify

Verify the download (recommended)

The minisign signature proves the binary was published by Restorable and has not been modified in transit. You need minisign installed.

# Fetch the release public key
curl -fsSLO "https://get.restorable.app/pub/restorable-release.pub"

# Verify (Linux example; substitute the platform-appropriate filename)
minisign -V -p restorable-release.pub \
  -m restorable-verify-linux-amd64 \
  -x restorable-verify-linux-amd64.minisig

Cross-check the public key against the one published on the trust page and in DNS (TXT _minisign.restorable.app). Two independent channels confirming the same key.

Verify a receipt

With the binary, the receipt file, and the customer's public key in hand:

restorable-verify --pubkey @customer.pub receipt.intoto.json

The --pubkey flag accepts either a file path prefixed with @ (e.g. @customer.pub) or an inline key string (ed25519:AAAA...).

On a valid receipt, the command prints the parsed payload and exits 0:

✓ Receipt rcpt_01hz... verified
  Schema:       v1, restore_receipt
  Org / Agent:  org_abc / agent_xyz
  Source:       prod-db
  Backup:       bkp_01hz...
  Result:       pass (2 checks)
    • recent-orders: pass
    • schema-sanity: pass
  Attestation:  none (self-hosted; trust root is the agent binary)
  Issued:       2026-04-14T02:07:00Z

On an invalid receipt (broken signature, schema violation, or tampered payload), the command exits non-zero with a diagnostic:

✗ Verification FAILED
  signature verification failed

Batch verification

The weekly evidence email may contain multiple receipts. Verify all at once:

restorable-verify --pubkey @customer.pub ./receipts/*.intoto.json

Exit is 0 only if every receipt verifies.

JSON output

For scripted workflows or integration into your audit tooling:

restorable-verify --pubkey @customer.pub --json receipt.intoto.json

What a successful verification proves

• The receipt was signed by the Ed25519 private key corresponding to the public key you supplied.
• The payload has not been modified since signing. A single flipped bit invalidates the signature.
• The restore test occurred at the time stated in the receipt, on the backup identified by its ciphertext hash, with the check results recorded individually.
• No access to Restorable's infrastructure is required. The verification is entirely offline: you, the binary, the key, the receipt.

What it does not prove

The receipt binds a public key to a payload. It does not prove that the key belongs to the entity claiming it. That is an out-of-band trust decision: your client tells you "this is our agent's public key," and you decide whether you believe them based on the channel through which you received it (dashboard export, direct handoff, published on their security page).

For the full scope of what a receipt does and does not prove, including the limits of application-level checks and the point-in-time nature of the evidence, see What a receipt proves.

Next steps

• Verifying a receipt covers chain verification, common failure patterns, and the full verification flow in detail.
• The trust page publishes all Restorable signing keys and the reproducible build recipe.
• The control mapping page shows how receipts map to NIS2, ISO 27001, SOC 2, DORA, and BSI C5 controls.