Release verification

Verify a release without trusting us

Check the corpus bytes, the maintainer's signature and the two timestamp proofs at the release you intend to cite. The commands below select the published v0.17.7 release.

git clone https://github.com/probityai/agent-evidence-vectors && cd agent-evidence-vectors
git checkout v0.17.7

# 1. the digest list is what the vector files on disk hash to, recomputed
python3 scripts/release-digests.py --check

# 2. the maintainer signed exactly those bytes
cosign verify-blob --key release/cosign.pub \
  --signature release/CORPUS-DIGESTS.txt.sig \
  --insecure-ignore-tlog=true release/CORPUS-DIGESTS.txt

# 3. an RFC 3161 authority saw that signature at a stated time
openssl ts -verify -in release/CORPUS-DIGESTS.txt.sig.tsr \
  -digest "$(base64 -d release/CORPUS-DIGESTS.txt.sig | sha256sum | cut -d' ' -f1)" \
  -CAfile spec/tsa-roots.pem

# 4. so did a public calendar nobody here controls
ots verify -d "$(base64 -d release/CORPUS-DIGESTS.txt.sig | sha256sum | cut -d' ' -f1)" \
  release/CORPUS-DIGESTS.txt.sig.ots

Check	What it establishes
`release-digests.py --check`	Recomputed corpus bytes match the generated digest list, including each manifest, count and revision
`cosign verify-blob`	The committed public key verifies the signature over that digest list
`openssl ts -verify`	The RFC 3161 authority timestamp covers the raw signature bytes and chains to the pinned TSA root
`ots verify`	The proof binds the same signature bytes to a Bitcoin block verified through the configured Bitcoin node

The signature was not submitted to a transparency log; --insecure-ignore-tlog selects offline signature verification. A verified timestamp dates the signature's commitment to the corpus. A key stored beside the corpus must still be selected through the consumer's own trust process.

Timestamp status

An OpenTimestamps proof can remain pending until Bitcoin confirmation. The weekly ots-upgrade workflow fetches updated calendar proofs. A successful upgrade does not establish Bitcoin chain verification.

The release gate checks digests and signatures on each tag. Its optional --with-timestamps path verifies the RFC 3161 token and OpenTimestamps signature binding offline, then reports the separate chain state. RFC 3161 verification uses spec/tsa-roots.pem. A proof that covers the wrong signature fails offline.

OpenTimestamps may contact a calendar for an incomplete proof. Full verification also needs a Bitcoin Core node. An offline binding pass does not establish chain verification. Record the reported chain state when the calendar or Bitcoin node cannot be reached.

Signing

The Ed25519 key is generated by cosign. The maintainer signs locally at tag time; the private key is absent from this repository and CI secrets. CI can verify releases but cannot sign them.

Signing precedent records the compared projects, the commands used to inspect them and a positive control.