Verify the audit chain

tovio audit verify

Walks the chain and checks every entry's signature and every hash link. A pass means no entry has been removed, reordered, or forged since it was written.

Why it is worth running

An audit log you have never verified is a text file. The chain's value is that tampering is detectable, and detection requires someone to check.

Run it on a schedule, after restoring a backup, before archiving, and before relying on the log for anything consequential.

What it needs and what it reports

It needs a repository identity to verify against — a repository with no identity has nothing to check the signatures with. A repository with no entries yet reports that plainly rather than claiming a verified chain.

Once you have archived, the count it reports is two numbers: the entries still held live, and the entries authenticated by a signed archive checkpoint. Both are verified; the archived ones are authenticated through the checkpoint rather than walked directly.

It crosses key rotations

An identity rotation does not break the chain. Verification follows the rotation boundaries using the repository's verified rotation journal, so a chain written under an older key still verifies after you rotate. With no rotations this is simply a single-segment walk.

If verification fails

Treat it as a security incident, not a corrupt file.

1. Do not "repair" it. Preserve the current state, including the checkpoint and archive directories.
2. Note when it last verified cleanly.
3. Report it privately to security@tovio.dev — never on a public board, and never through the feedback portal.

A verified bypass of the audit chain's tamper-evidence is explicitly in scope as a security defect.

Two different failures

A broken link or an invalid signature in the live chain is a cryptographic verification failure. A checkpoint, archive digest, or retained-chain boundary that cannot be authenticated is a retention failure and carries its own code — see the archiving article, because the remedy is different: nothing further is published or removed after the failing step, and the archive directories are the evidence.

Related

tovio fscktovio fsck --strict

Checks object-store integrity — re-hashes every object, verifies references and the audit chain, and scans for leaked key material. Suspected private-key material is an advisory warning that still exits 0; --strict promotes warnings to failures, which is what you want in a CI gate.