## Problem A chain that reports BROKEN reports VERIFIED once the broken range has been archived and live-purged. Nothing is repaired: the verdict changes because the evidence moves somewhere the verdict does not look. Neither retention stage checks that the rows it is about to archive and delete actually link. `assertNoUnexplainedErasure()` refuses a range whose transient columns were NULLed with no stamp accounting for it, and its docblock gives the reason in general terms: > Archiving it anyway stamps `archived_at`, and `archived_at` is one of the two > stamps the verifier accepts as accounting for an emptied bucket. So the stage > would take an erasure the verifier had just flagged and sign it into a > legitimate one, under the live secret, with no forgery involved. Refusing is > the archive stage's half of verify-before-destroying: an archive is evidence, > and evidence is not written over a discrepancy. That reasoning applies to a broken hash chain exactly as it applies to an emptied bucket, and the broken hash chain is not checked. After the purge, `findArchiveBridging()` reconnects the walk across the gap using the segment's signed `anchor_before` and `anchor_after`. Those are separate columns from the row content, so an edit inside the range leaves both intact: the bridge matches and the walk resumes as if nothing had happened. The evidence is not destroyed. The tampered row is in the NDJSON, and `audit_trail:archive-verify` still catches it, because `walkRowChain()` checks linkage inside the file. But `audit_trail:verify` is what cron runs and what the status report summarises, and it goes green. So the module converts a loud failure into a silent one that only a different command, pointed at the right file, will find. The attack needs no privilege beyond the database write the threat model already assumes: edit a row, wait for the retention window, and the finding disappears on its own. ## Steps to reproduce Confirmed with a kernel probe: 1. Chain six rows on `webdav`. 2. Tamper row 3, strictly inside the range that will be archived: `UPDATE audit_trail SET action = 'tampered' WHERE id = 3`. 3. `verifyChain('webdav')` reports `Chain "webdav" broken at id 3: public hash mismatch (payload or hash column tampered).` 4. Declare a bare segment over `[2, 4]` and archive it. **Accepted.** 5. Live-purge it. **Accepted.** 6. `verifyChain('webdav')` reports `Chain "webdav" verified: 5 entries intact. Bridged purged ranges via 1 WORM archive covering rows 2-4.` The anchors are what make step 6 work: `anchor_before` is row 2's `previous_hash` and `anchor_after` is row 4's `hash`, and tampering row 3's payload changes neither. ## Proposed resolution Retention must not stall. The archive window is a legal deadline and the data has to leave on time, so refusing to archive an unverified range until somebody attends to it is not available: it would trade a retention obligation for an integrity one, and only the retention obligation has a date on it. The laundering is not caused by archiving a broken range. It is caused by the verdict going green **afterwards**. So mark the range instead of blocking it. **At archive time**, verify the rows. If they do not link and no acknowledgment covers them, archive anyway and say so, loudly, everywhere an operator looks. Archiving takes nothing away: the rows are still live, so the break is still fixable and still acknowledgeable. **At live-purge**, check again. This is the moment the evidence goes, and the moment the verdict would start lying. If the range still does not verify and still has nothing covering it, purge on schedule and record that it was purged over a break nobody had explained. Recorded twice, in the split #3620349 has just established one layer down: - **The record is the chain event.** `segment_live_purged` is already emitted at that moment, already linked and signed, and the verifier already cross-references it through `live_purged_event_id`. Its permanent bucket carries the fact, the failure and the row ids. Nobody removes it without breaking the chain. - **The flag on the segment row is the index**, so `findArchiveBridging()` can decide not to bridge without decoding a chain event for every gap it crosses. If a flag rides on the row it has to be signed into the LIFECYCLE envelope, not the identity or archive-content ones: those are sealed at segment creation and at the archive op respectively, both before this is decided, while the lifecycle HMAC is re-signed at every transition and already carries `live_purged_at` itself. A flag there has exactly the standing of the purge stamp beside it. Which is also why the event matters more than the column: someone holding the signing secret could re-sign the lifecycle envelope with the flag cleared, as they could with any other lifecycle stamp. They cannot do that to a linked chain row. **At verify time**, `findArchiveBridging()` reads that mark. A marked segment does not bridge silently: the walk reports the range as purged-and-unexplained and the chain does not read as verified. The finding outlives the rows, which is the whole point, and it costs nothing to keep, because it is one flag on a row that already exists. So the rows leave on schedule and the break is still reported, every run, forever, until an operator explains it. **The operator's window is already configured.** Acknowledging resolves the range's anchors from the live rows, so it works right up until the live-purge deletes them, and archiving does not close it. Verified: ``` archived, rows still live: OK, ack #10 after live-purge: REFUSED - "Cannot anchor acknowledgment: chain webdav has no row with id 4" ``` So the gap between `archive_after` and `live_purge_after` IS the grace period, it needs no new setting, and on a real site it is months rather than hours. Detecting at archive and marking at purge uses that interval as it stands. Once the rows are gone the break becomes permanently unexplainable, which is why the mark has to be applied at the purge: after that there is nothing left to acknowledge and nothing but the mark to carry the finding. ## Saying so, and making it actionable A mark that only reaches the log is worse than useless. It has to be where an operator looks. **Where the verdict comes from.** `AuditTrailCronVerifyHooks` already stores a per-chain result in State (`audit_trail.auto_verify.results`) with the run timestamps beside it. Read that. A live walk per page render is not affordable, and the stored verdict is the same one the status report already summarises. Show when it was last checked: a stale green is worse than no green. **The status report** gains an entry at Error severity naming the chain and the broken range, in the same shape as the lock-contention and acknowledgment-index entries it already carries. It says whether the rows are still there, because that is what decides whether the operator can still do anything about it. **The module's own admin pages** carry the same warning, because an operator reading the trail is doing it in order to rely on it, and a broken chain is exactly what they must not read past. Through `#theme: status_messages` with `#status_headings`, never hand-built `messages` markup: without the headings the region has no label and no heading, and the ARIA role changed in core 12, so this has to go through core's own rendering rather than reproduce it. **The action.** Both link to the acknowledgment form with the range already filled in: ``` /admin/config/system/audit-trail/acknowledgments/add?chain=<chain>&from=<from_id>&to=<to_id> ``` `AuditTrailAcknowledgmentForm` already reads `chain`, `from` and `to` from the query string, so this needs no new form work: the operator lands on a form that knows which rows are broken and has to supply one thing. That one thing is the reason, and it stays empty and required. Prefilling it would be an automatic acknowledgment in another costume: the point of the mechanism is that a person says, in their own words, why this break is explainable, and puts their name on it. ## Explaining a marked segment afterwards The mark is permanent and is not clearable. "This range was purged while it did not verify" is a fact about what happened, and a fact an operator can delete is worth nothing. What an acknowledgment changes is not the fact but the verdict: an acknowledgment has never repaired a break, it explains one, and the verifier goes on saying the range failed while reporting who explained it and why. > before: rows 2-4 were purged and did not verify, unexplained > after: rows 2-4 were purged and did not verify, explained by uid 7: > "secret lost in the 2026 migration" **Anchoring it without the rows.** Recording an acknowledgment reads two hashes off the live rows, and for a purged range they are gone, which is why `acknowledgeChainReset()` answers `Cannot anchor acknowledgment: chain "webdav" has no row with id 4` today. The segment holds the same two values and has since it was created: | | the acknowledgment reads | the segment already stores | | --- | --- | --- | | `anchor_before` | `hash` of row `from_id - 1` | `previous_hash` of row `from_id` | | `anchor_after` | `hash` of row `to_id` | `hash` of row `to_id` | Row N's `previous_hash` IS row N-1's `hash`, so these are the same pair, and the segment's copy is signed into its identity HMAC while a live row's is not. So the fallback is to take them from the segment: better provenance, not worse. If that segment is later restored the rows come back carrying those same values, so `hasValidAnchors()` keeps working with no change. The two differ only where the chain is broken at the boundary, which is possible for exactly these ranges. The segment's pair is the right one, because the segment's pair is what the bridge compares against. **One acknowledgment per segment, covering the whole of it.** The granularity degrades with time, and that is the correct incentive rather than a defect: - before the purge the rows are there, so the operator names exactly the rows that are broken, one in a thousand if that is what it is; - after it, the finest anchor available is the segment's own, so excusing one bad row means excusing the whole archived range, and the verdict says so. `assertNoSegmentBisection()` already forces that shape, verified: ``` exactly one segment [2,4]: ALLOWED inside one segment [3,4]: ALLOWED spanning both [2,7]: REFUSED one segment plus a live row [2,5]: REFUSED wholly outside [8,9]: ALLOWED ``` An acknowledgment is contained in a single segment or clear of all of them; it can never span two. So a break crossing a segment boundary takes one acknowledgment per segment, which matches the marking: each segment is marked separately and each is explained separately. **What it takes.** No new table and no new concept: - `acknowledgeChainReset()` falls back to the segment's signed anchors when the range's rows are gone, instead of refusing; - `findArchiveBridging()` consults acknowledgments when it meets a marked segment, the way the row walk already does for a live break. **Aside, found while checking the above.** `assertNoSegmentBisection()` reports "would bisect segment #N" for an acknowledgment that CONTAINS the segment entirely, which is not bisecting it. The refusal is right; the sentence describes a different shape than the one the operator typed. ## Related #3620307 built the transient-column half of verify-before-destroying and named itself after the whole thing. #3620349 makes acknowledgments verifiable against the chain rather than against a signature on the index row, which is what would let the archive stage trust "an acknowledgment covers this break" as a reason to proceed. --- AI-Generated: Yes (Claude Code was used to find this, build the reproduction and draft the summary. The design question it raises is the maintainer's to answer; there is no code on this issue.)