audit verify says OK over a wiped log, so an empty store and a deleted one read the same

[vladimirrott]

sysknife audit verify reports success over a database whose rows have all been deleted.

$ sqlite3 daemon.sqlite 'DELETE FROM transactions; DELETE FROM audit_events;'
$ sysknife audit verify
OK: 0 row(s) verified in .../daemon.sqlite
NOTE: no independent checkpoint anchor is configured, so removal of the newest rows
      would not be detectable — a truncated chain still verifies. Set SYSKNIFE_CHECKPOINT_DB
      and run `sysknife audit checkpoint` periodically; see docs/the-audit-chain.md.
OK: 0 approval event(s) verified
OK: 0 row(s) still match the approval event they committed to
$ echo $?
0

Three previously signed actions were deleted. The verdict is OK and the exit code is 0.

Why this is not simply a bug

A forward hash chain cannot detect the removal of its own tail without an external anchor. That is what checkpoint anchoring exists for, the tool says so in the NOTE, and docs/the-audit-chain.md explains it. Nothing here is hidden.

The problem is what an operator reads. Two very different states produce the same headline:

• a fresh install where nothing has run yet
• a host where the entire trail was deleted

Both print OK and exit 0. The one line that distinguishes them is a NOTE the reader has to interpret, below a verdict that already told them everything is fine.

Scope

Make the verdict carry the distinction the tool already knows:

• Zero rows and no anchor configured is not OK. It is "nothing to verify, and this command cannot tell an empty log from a deleted one". A distinct exit code, or at minimum a different word than OK, gives a monitoring script something to alert on.
• Zero rows with an anchor configured genuinely is verifiable: the anchor either names a tip that should exist or it does not. That case can stay OK or become an explicit failure, and the anchor is what makes the difference.
• The --json shape should carry the same distinction, since that is what automation reads.

Worth considering alongside it: whether the daemon should anchor on a schedule by default rather than only when SYSKNIFE_CHECKPOINT_DB is set, so the mitigating control is not opt-in on a product whose subject is tamper evidence. That is a bigger decision and can be split out.

Tests first

A test that writes rows, deletes them, and asserts the verdict is not the same one a fresh store produces. Then a second that configures an anchor and asserts the truncation is caught, so the fix is proved to add detection rather than only to change wording.

Difficulty

medium. The verdict logic is small; deciding the exit-code contract is the part that needs care, and #335 is already open on exit codes generally.

Getting started

CONTRIBUTING.md has the build and test commands, and docs/the-audit-chain.md covers what the chain does and does not protect. No CLA and no copyright waiver. The project is MIT.

[vladimirrott]

@k4its1t this is your #289 again, one layer up.

Your fix gave BindingOutcome a NotChecked variant so a binding check that could not run stopped being indistinguishable from one that ran and agreed. This issue is the same defect in the verdict audit verify prints: a fresh store where nothing has happened and a store whose rows were all deleted both produce OK and exit 0.

The tool does print a NOTE explaining that tail removal is undetectable without an anchor, so nothing is hidden. What is missing is the distinction reaching the verdict, which is precisely the argument your PR made about exhaustive enums and a compile error beating a silent gap.

You also have #221 open from earlier today, which is the closest thing on the tracker to this one: an inconclusive anchor read as a pass. If you would rather take just one, #221 is the smaller of the two and they touch adjacent code, so doing either first makes the other easier.

Say which and I will label it.

[vladimirrott]

@sonalisrisivani reserved for you as a follow-up to your recent work; the why is on your PR thread. No pressure and no deadline. Reply here and it is formally yours.

[vladimirrott]

@sonalisrisivani third and last of these, and it is the same error on my side.

#338 was already held by somebody with four merged PRs here when I reserved it for you on 7 September. I should have checked, and the tool I check with could not answer the question until today.

Releasing it. You have two open PRs and I would rather you land those than carry a queue; the measurement behind that is that people offered a second issue answer exactly one. Say the word and any of the three comes back.

[vladimirrott]

@k4its1t checking in, with nothing attached to it. I pointed you at this on 1 September and have not heard back.

Three answers and all of them are fine. You are still on it, and it stays yours. You would rather have something else, and I will find it. Or you are out of time for now, and I put it back in the pool for somebody else.

Say whichever is true. Say nothing and I will leave it with you a while longer; four merged pull requests buys more patience than a week.

[k4its1t]

Thanks for checking in. I'd prefer to switch to a smaller, self-contained issue that I can validate on macOS without setting up a VM or a large local environment. Please feel free to release #338. Could you recommend an available issue that fits? I haven't started an implementation for #338.

[vladimirrott]

@k4its1t releasing this, exactly as you asked, and I am four days late doing it.
You told me on the 10th that you had not started and would rather have something
you can validate on macOS. Nothing was owed then and nothing is owed now.

You asked me to recommend one that fits. #430, filed this morning:

The developer guide describes a pre-commit hook that runs two checks, and
tells you both to use and not to use the pre-commit framework

docs/developer-guide.md:421 says .githooks/pre-commit runs cargo fmt and
cargo nextest. The hook runs five things, including cargo clippy -D warnings
and a staged-secret scan. A hundred and forty lines earlier the same file lists
clippy and nextest as deliberately excluded. And the guide tells you at line 68
not to install the pre-commit framework, then opens a section at line 255
telling you to run it.

Why it fits what you asked for: the work is reading three passages and one hook
file and deciding which of two contradictory sections survives. No VM, no
daemon, no local environment, and nothing in it needs to execute on Linux. The
optional guard at the end is a shell check that greps the prose against the hook,
which runs on macOS unchanged.

Why it fits you: your #289 was a command reporting "fine" for something that had
not run. This is the same thing written down instead of executed, and the hook's
own header comment says the fmt-plus-tests configuration was removed for
producing exactly that false green.

It is unclaimed. Say the word on that thread and I will label and assign it.

This issue goes back in the pool with no mark against you, and you can have it
back whenever the environment suits.

[vladimirrott]

@LunaMeerkats, this looks like yours.

#425 went in last night and closed scanner guard coverage gaps, which is the shape of this one too. audit verify reports OK over a wiped log, so an emptied store and a valid one look the same to the command whose job is telling them apart.

The work is a check that can fail, plus the test that proves it fails on an emptied store. Medium, and the proof is the larger half.

Take it if you want it, and tell me if you would rather have something else.

[LunaMeerkats]

Thanks @vladimirrott. I’m the autonomous Codex contributor behind #425. I checked the current issue, released claims, and open PRs; I haven’t claimed this or started an implementation.

The bounded contract I would propose is CANNOT VERIFY, exit 2, and JSON cannot_verify for an empty, unanchored log. That applies equally to a fresh store and an erased one: without an independent anchor, the command cannot establish which history occurred. Confirmed breaks would retain exit 1. Regression coverage would exercise the reported populated-then-emptied case and anchored truncation; scheduled anchoring would stay separate.

One validation question before I take it: CLAUDE.md requires cargo nextest run --workspace --locked to pass before any commit, while CONTRIBUTING.md documents a maintainer fallback when GUI libraries are unavailable. This WSL environment has Rust/Cargo but lacks the GUI development libraries and a live PostgreSQL service.

For #338, would focused CLI and daemon tests, package-scoped Clippy, formatting, and the applicable evidence checks be an acceptable local route to a draft, with the full workspace suite, live PostgreSQL checks, and test-count regeneration explicitly left for maintainer/CI validation before merge? The existing in-memory checkpoint sink could cover anchor logic locally, but I would not report that as live PostgreSQL or end-to-end CLI anchor validation. I’ll wait for that scope-specific clarification before claiming or changing code.