zode verify asks the API what a host reports about itself, then checks that report on your machine. The API only relays the report; the CLI does not trust the API’s own verdict. Background: Attestation.
What it checks
For a sandbox, the CLI checks the host it runs on. For a region such aseu-central, it checks every active host in it. A name that is not one of your sandboxes is tried as a region.
The CLI sends a fresh random nonce, then checks, in order:
- The release manifest matches the digest the host reports.
- The manifest is signed by the Zode release key built into the CLI.
- The signature is in the Rekor transparency log, with an inclusion proof against a signed checkpoint. The Sigstore trusted root is also built into the CLI.
- The files the host measured match the files the release lists.
- On a host with a TPM: a TPM quote over the boot measurements, made with your nonce, so it cannot be replayed.
signed_image: the files match, but the host itself reports them. A host whose TPM quote also checks out, with an enrolled TPM key, is tpm_quoted. TPM key enrollment has not shipped, so the best class today is signed_image. A host that fails any step is none.
Output today
Failure messages leave out file paths on the host; they only say what failed.
|
log | The Rekor entry on https://search.sigstore.dev/?logIndex=N. |
A verified host’s heading reads <region> <host>: verified, signed_image, release <release>.
JSON
verdict fields: ok, class (what was proven), claimed (what the host said), release, manifest_digest, log (log, log_url, log_index, tree_size, root_hash, integrated_time, set), checks, limits and problem. Empty optional fields are left out, and checks is null when no step passed.
Check a release offline
To audit a release without a host, pass the manifest and its Sigstore bundle:Exit codes
ZODE_RELEASE_KEY names a PEM file of release keys to use instead of the built-in key, for testing a staging release. The CLI prints a warning on stderr when it is set.