do-audit-verify is the auditor's tool — it takes a daily signed manifest and answers two questions:
Answer "yes" to both and the day's evidence is good. Answer "no" to either and do-audit-verify says exactly what's wrong.
Importantly, do-audit-verify works offline. It doesn't need to contact the device, the support endpoint, or any cloud service. The Defend-O-Tron's signing-key ring travels inside every evidence pack (manifest.pubring.json), so an auditor with a copy of the ZIP and a Python interpreter has everything they need.
Where to run it: Most often by an auditor on their own machine, against an extracted evidence ZIP. The tool also works directly on the device — open the Cockpit admin interface and click Tools → Terminal, or SSH in. It's bundled with the audit-deb package.
do-audit-verify <manifest> [--pubring PATH] [--skip-files]
MANIFEST-YYYY-MM-DD.json file (typically extracted from an evidence ZIP's manifests/ directory).--pubring to point at the ring bundled inside the ZIP.| Flag | Required? | Default | Effect |
|---|---|---|---|
<manifest> |
Yes | — | Path to a MANIFEST-YYYY-MM-DD.json file. |
--pubring PATH |
No | /opt/data/auditor/keys/manifest.pubring.json |
Alternate pubring (use the one shipped inside the evidence ZIP if you're verifying off-device). |
--skip-files |
No | off | Verify only the manifest signature; skip re-hashing the listed files. Faster — useful for spot checks when you only want to know "is the signature valid?" |
$ do-audit-verify manifests/MANIFEST-2026-04-15.json
signature OK (Y8nM3R9k7p2QwA1xL4)
files: 142 listed, 0 mismatched, 0 missing
That's the green-light state. Manifest signature checks against the pubring entry whose key_id is embedded in the signature block; every file listed in the manifest still exists at the expected path and still hashes to the value the manifest recorded.
A bad signature means the manifest's content has been altered since it was signed. The signature still references a known key (otherwise we'd see "unknown key_id"), but the cryptographic check failed.
$ do-audit-verify manifests/MANIFEST-2026-04-15.json
BAD signature on manifests/MANIFEST-2026-04-15.json (key Y8nM3R9k7p2QwA1xL4)
Exit code: 4.
Signature OK, but the manifest's file list includes one or more entries whose on-disk content no longer matches what was hashed at signing time. Common in two scenarios:
$ do-audit-verify manifests/MANIFEST-2026-04-15.json
signature OK (Y8nM3R9k7p2QwA1xL4)
MISMATCH /var/log/suricata/eve-ids-2026-04-15.json
files: 142 listed, 1 mismatched, 0 missing
Exit code: 5. The standard-error output (one MISMATCH line per offending path) makes it easy to identify which file is suspect.
Signature OK, file listed but not present on disk. Common after rotation/cleanup if you're verifying long-after-the-fact on the device itself (the audit subsystem will have rotated old log files out). Not the same as a mismatch — the manifest hash for that file simply couldn't be checked.
$ do-audit-verify manifests/MANIFEST-2026-04-15.json
signature OK (Y8nM3R9k7p2QwA1xL4)
files: 142 listed, 0 mismatched, 14 missing
Exit code: 0 (signature is valid, just incomplete file inventory). The missing count is informational.
The signature references a key the pubring doesn't have. Usually means you're verifying against the wrong pubring — common if you forgot to pass --pubring and you're sitting on a machine that doesn't have the same device's key history.
$ do-audit-verify manifests/MANIFEST-2024-08-01.json
unknown key_id in manifest: T2hQ9p1L3kRwA8mN5Z
Exit code: 3. Re-run with --pubring path/to/evidence/manifest.pubring.json.
If you only want to confirm the signature is valid and don't care about re-hashing files (faster, useful for a spot check), pass --skip-files:
$ do-audit-verify --skip-files manifests/MANIFEST-2026-04-15.json
signature OK (Y8nM3R9k7p2QwA1xL4)
| Exit code | Meaning |
|---|---|
0 |
Signature valid; if files were checked, none mismatched. |
2 |
No signature block in the manifest (malformed input). |
3 |
Unknown signing key — the pubring doesn't include the key the manifest was signed with. |
4 |
Signature failed cryptographic verification. |
5 |
Signature valid but at least one listed file mismatched. |
Suitable for scripted verification — do-audit-verify --skip-files <manifest> && echo "good" works exactly as you'd expect.
An auditor working from a q2-evidence.zip produced by do-audit-report typically does this:
unzip q2-evidence.zip -d q2/
cd q2/
# Spot-check the chain-of-custody manifest first
do-audit-verify chain-of-custody.json --pubring manifest.pubring.json
# Then verify each daily manifest
for m in manifests/MANIFEST-*.json; do
do-audit-verify "$m" --pubring manifest.pubring.json
done
Any non-zero exit on any of those is a finding worth investigating.
The signing key ring keeps every key the device has ever used, each marked with valid_from and retired_at timestamps. Verifying a manifest looks up the key that was active when the manifest was signed — not the key active today. So manifests signed before a compromise still verify cleanly after the compromise, as long as a copy of the pubring from before the incident is available.
In practice, every evidence ZIP you've ever produced contains a pubring snapshot from its production date — making prior-evidence verification possible indefinitely.