## Problem A chain whose most recent rows are `DELETE`d verifies **clean**, and all three operator surfaces report success. This is the exact attacker the threat model addresses (DB write access, no signing secret), and it is the case the documentation says is detected at the next verification. The checkpoint is what defeats it. After the tail is deleted the checkpoint points at a row that no longer exists, `getRowHash()` returns NULL, and the verifier classifies the checkpoint as *stale*, discards it, and walks the surviving prefix from genesis. The prefix is internally consistent, so the verdict is `ok = TRUE`. ## What happens The verdict is annotated with a note blaming "a row dropped by archive+purge", an explanation that is no longer even reachable, because live-purge now deletes the checkpoints inside its own range. So the one message that could prompt a human to look explains the gap away. `/admin/reports/status` classifies on `ok` alone and renders "All chains pass HMAC verification". `drush audit_trail:verify` reads only `ok` and exits 0, so the `drush audit_trail:verify || mail` crontab that `docs/verification.md` recommends sends nothing. The only remaining signal is a human noticing that the highest `id` moved. ## Findings in this issue - **H10** `src/AuditTrailVerifier.php`: a deleted chain tail verifies clean: a checkpoint inside the deleted range is classified stale, discarded, and the prefix walked from genesis. Verified by reading. - **H11** `src/AuditTrailVerifier.php`: the archive bridge requires no live-purge attestation, so any archive whose anchors span a gap bridges it, so deleted rows chain across as intact. Verified by reading. - **H14** `src/Plugin/AuditTrailStatusCheck`: the status report asserts "All chains pass HMAC verification" over acknowledged breaks, classifying on `ok` alone. - finding `src/AuditTrailVerifier.php`: `verifyAll()` enumerates chains from `SELECT DISTINCT chain FROM audit_trail`, the table under attack, so a chain whose rows are *all* deleted is silently absent from the results and the count simply reads one lower. - finding `src/AuditTrailVerifier.php`: `checkpoint_forged` and `checkpoint_stale` are computed and read by nobody, and a broken range is not closed at an acknowledged row. - finding `src/AuditTrailVerifier.php`: `verifyChainPublic()` has no archive bridge at all, so it reports broken forever after the first *legitimate* purge. It is the mirror-image defect in the same file. ## Proposed fix A missing row is only excusable when something signed says it was removed on purpose. Concretely: 1. **A stale checkpoint is evidence, not noise.** When the checkpoint's row is gone and no signed segment covers the range, the verdict is `ok = FALSE` with a distinct reason (`tail_deleted`), not a discard. 2. **Bridge only on attestation.** `findArchiveBridging()` should require a segment whose `live_purged_at` is stamped *and* whose signature validates (see the sibling issue on lifecycle signatures) before it will chain across a gap. 3. **Enumerate chains from configuration**, not from the audited table, so a fully deleted chain reads as broken rather than absent. 4. **Give `verifyChainPublic()` the same bridge** as the authenticated walk, so the two cannot disagree. 5. Consume `checkpoint_forged` / `checkpoint_stale`, or delete them. A test must be seen to fail without the fix: delete the last N rows of a chained fixture and assert `ok === FALSE`, then assert the Drush exit code and the status-report verdict agree. The archive-bridge half of this depends on segment signatures actually being validated, which is its own issue. The two should land in that order. ## What merge request !44 does Against the numbered proposal above: 1. **Done.** A checkpoint naming a row that is gone, with no segment carrying a stamped and validly signed `live_purged_at` covering it, is reported as a deleted tail. The verdict deliberately does not walk, because a walk of the surviving prefix is the thing that verified, and the checkpoint is left in place rather than discarded, because it is the evidence the missing rows existed. 2. **Done.** `findArchiveBridging()` requires `live_purged_at` and a valid lifecycle signature. An archive says what a range *contained*; only a live-purge says the live rows were removed on purpose, which is exactly what the gap is made of. 3. **Done, but not from configuration.** Enumerating from the chain config entities would miss a chain written under an entity that has since been deleted, and would put an entity-system dependency in the repository. `listChains()` unions `audit_trail` with `audit_trail_checkpoint` and `audit_trail_segment`, the module's own signed records that a chain existed and how far it reached, neither of which deleting entries touches. `deleteChain()` already drops all three, so retiring a chain still removes it from the list. 4. **Not done, because it cannot be done as written.** `findArchiveBridging()` resolves both signing secrets and validates both HMACs before it will chain across a gap, which is requirement 2 of this same issue. `verifyChainPublic()` is the walk that deliberately touches none of that, so an auditor can run it without the operator's secrets. Giving it the bridge means either handing it the secrets, which removes the reason it exists, or bridging on anchors nothing has validated, which is H11. The two walks disagreeing after a legitimate purge is real, and the answer is a clearer public verdict rather than an unattested bridge. 5. **Done.** `checkpoint_forged` is consumed by the status report, which raises a warning naming any chain whose checkpoint did not validate. Nothing read it before, so a checkpoint written by someone without the signing secret produced a clean status report and no signal anywhere else, because the walk falls back to genesis and that walk succeeds. `checkpoint_stale` is consumed by the verifier itself: it is what the deleted-tail decision turns on, and it is documented as carrying that meaning. Four further defects were found while implementing it and are fixed in the same branch: - **The full walk did not read the checkpoint at all**, so a truncated chain verified clean under `--full` while the incremental walk reported it broken. That is the wrong way round: `--full` is what an operator runs when they suspect something, and `verify_full_interval_days` makes cron re-walk everything weekly precisely to defend against checkpoint-level tampering. - **The deleted-tail verdict named its broken range with keys nothing else uses**, so `/admin/reports/status` announced `Chain X broken at id ?` on the one finding that most needs a row number. - **The status report called two states a clean run.** It classified on `ok` alone and said "All chains pass HMAC verification" over a chain that verifies only because an acknowledgment covers a break in it (H14), and over a chain whose checkpoint signature did not validate. - **Both operator surfaces offered an "Acknowledge break" link for it.** That offer is false: an acknowledgment is anchored to stored row hashes and must end at or before the head, so the module refuses one over rows that are gone. Broken ranges now carry whether they can be acknowledged, and the surfaces gate the link on it. ## Still open after !44 - **Item 4**, the public walk's disagreement with the authenticated one after a legitimate purge, which needs a clearer public verdict rather than a bridge. It is the one finding here that cannot be met as written, so it wants its own issue rather than a line in this one. Giving the entry page, the segments page and the status report a single owner for the per-row verdict remains #3620311. **H14** is fixed here, because the status report was stating something the walk had not established, which is a defect in its own right and not part of that refactor. --- Found by a full-tree audit of `1.x` pinned at `7bae553` (tag `1.0.0-alpha9`), reading all 271 tracked files. Every claim above was checked against the source, and where a claim could only be settled by running something, the issue says so. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on merge request !44. I reviewed and ran the work myself before posting it.)