Offline verification of signed receipts

What to bring

The receipt carries the recorded information and its signature. A verifier also needs approved public keys and, to compare hashes, the corresponding files. A key attached by the sender is not automatically trusted.

Prepare those materials before moving into an isolated environment. If RFC 3161 timestamping is used, the trust material required to verify it must also be available.

Choose the check

To check a receipt using a local trust store:

attest verify --trust-store /path/to/trust receipt.yaml

To recompute hashes from the corresponding workspace:

attest verify --recompute receipt.yaml

For an evidence archive prepared for offline verification:

attest verify --archive bundle.attest.tar.zst --offline

These commands address different needs. Recomputing depends on the expected files and configuration in the workspace. Consult the CLI reference and read which checks actually ran in the result.

Interpret the result

The CLI returns exit code 0 for success, 1 for verification failure and 2 for an operational error. A missing required file is not a successful comparison.

A valid signature protects the signed statement. A matching digest confirms correspondence within the verified scope. Neither demonstrates that software is free of vulnerabilities.

Prepare trust

A local trust store does not automatically receive revocations recorded elsewhere. Its preparation and freshness matter in connected and isolated environments alike. Independent verification still relies on explicit trust assumptions.

Read The software is delivered. Its evidence should be too., then the receipt format to prepare a verifiable set of materials.