⊢ verify · offline · nothing leaves this page

Check an audit seal without trusting us.

re audit --seal writes audit.seal.json: the audit JSON, the commit it measured and the method version, signed with the repository's Ed25519 issuer key as a Crovia Seal. Drop that file here. Your browser recomputes both hashes and checks the signature with WebCrypto; this page makes no network request. The same check on the command line: re seal verify audit.seal.json.

No seal at hand?

The sample is the seal of this repository's own audit at a fixed commit, embedded in this page. The second button raises one surviving-lines count by one inside the sealed JSON.

What will appear here

The verdict first, in words. Then the issuer, the commit and the method version the seal is bound to, the audit numbers as a table, and every check as a step — so when a seal fails you see which step caught it.

  1. Verdict: valid, invalid, or unreadable
  2. Issuer key, chain position, commit, method
  3. The sealed numbers
  4. Every check, in order

—

    What a valid audit seal proves

    That the key shown as issuer signed exactly this audit JSON for exactly this commit, produced with this method version, and that not one byte of the numbers changed since. The seal is a crovia.seal.v1 like any other: the audit JSON is its subject.output, the audited git state (commit, method, options) its subject.input, both committed by SHA-256 and length. It does not prove that the numbers are true, and it does not say who controls the issuer key. Anyone can rerun re audit on the commit and compare the bytes; the method is public.

    re audit --seal                  # signed, bound to the commit
re seal verify audit.seal.json   # the same checks, offline

    What fails, and how

    Verification is fail-closed. A bundle with a field the signer did not sign, an audit JSON whose hash or length differs from the seal, a commit or method that disagrees between the input, the signed parameters and the audit JSON, a wrong signature, a chain with a gap or a broken link: each is rejected at the step that catches it, and the steps are listed so you can see which one. "Unreadable" means the text is not a seal at all (not JSON, or JSON with a duplicate key); "invalid" means it is a seal that does not verify.

    re seal verify audit.seal.json; echo $?
# 0 valid · 1 invalid · 2 unreadable