## Problem Two of the module's own evidence surfaces have a blind spot, and both of them are the surface an operator goes to when the chain says something is wrong. ### An acknowledgment leaves no trace in the chain it neutralises Every segment lifecycle transition writes a chained attestation — `SegmentLifecycleAction` lists `segment_archived`, `segment_live_purged`, `segment_file_purged`, `segment_transient_purged`, `segment_restored`, `segment_compacted` — precisely so a destructive operator action leaves a record inside the trail. Recording, editing and deleting an acknowledgment write nothing to any chain. `AuditTrailVerifier::acknowledgeChainReset()`, `updateAcknowledgment()` and `deleteAcknowledgment()` touch only `audit_trail_acknowledgment`. What that buys is in the module's own permission text: > It also covers writing acknowledgments, which make a broken range read as verified. So, all reachable by one holder of `administer audit trail`: - an acknowledgment can be **deleted** and nothing anywhere records that it existed, nor that the range it covered once read as broken; - an acknowledgment can be **edited** onto a different range with a different reason and nothing records the content it replaced. `updateAcknowledgment()` deliberately keeps `created` and `uid`, so the row goes on naming whoever recorded the *original* range as the author of the new one; - turning a BROKEN verdict into a verified one is invisible to the verifier and to the entries list, which is where an auditor looks. ### The status report never looks at the signing Key again `SecretRepositoryInterface::MIN_SECRET_BYTES` (32) documents itself as enforced by "two parties": `KeyBackedSecretRepository::setSigningSecret()` at activation, and the secret form at save. Both run once, before anything has been signed. The bytes live in a `drupal/key` Key entity whose own admin form, provider file or environment variable can change afterwards, and nothing looks again: - shortened below the floor: every later row is signed under a secret the module documents as refusing, and `SecretKeyChecker` still reports `Configured (1 secret, signing under #1)` at severity OK. It already checks the degenerate case of the same condition (`getKeyValue() === ''`); - changed to different 32+ byte material: every row, checkpoint and segment already signed under that id recomputes to a different HMAC, so verify reports the range **BROKEN**, which an operator cannot tell from an attack. `SecretUsage::isSignedBy()` exists to answer exactly this and is wired only into the secret add and edit forms, which the Key module's own form bypasses. `SecretKeyChecker` says it best in its own comment: "on a page whose whole job is to report that state accurately". ## Proposed resolution - Chain an attestation per acknowledgment mutation (`acknowledgment_recorded`, `acknowledgment_updated`, `acknowledgment_deleted`), carrying the range, the reason and the anchors permanently, and for an edit or a delete the content being replaced. `verifySegmentEventCrossReference()` only inspects `segment_*` actions, so these need no verifier change, and the chain write lock is already held at each call site so the write takes `acquire_lock: FALSE`. Both ingresses — the admin forms and `drush audit_trail:acknowledge-reset` — reach the verifier, so one emit site covers both. - Keep the acting operator out of the permanent tier. `Chain\ChainPayload` states the contract: actor identity lives in the transient bucket so right-to-erasure stays honorable and archive files stay PII-free. `audit_trail_acknowledgment.uid` broke it in both directions, since the column was signed into the row's HMAC and copied into the archive NDJSON, so it is dropped and the operator is named on the chain event instead. - In `SecretKeyChecker`, report a resolved Key holding fewer than `MIN_SECRET_BYTES`, and report a signing Key that no longer holds the bytes its records were signed with. The byte proof reads the newest row under the signing id (`SecretUsage::isSigningWith()`), because `secret_id` carries no index on `audit_trail` and the status report must not walk the chain. - Access-check the links that cross a permission boundary. The acknowledgments listing and the chains collection are gated on `administer audit trail` and link into the entries listing, which is gated on `view audit trail reports`; neither permission implies the other. The acknowledgment history link also needs an exact `resource` filter, since `acknowledgment:1` is a substring of `acknowledgment:12`. ## Consequences at merge - The acknowledgment signature changed, so acknowledgments recorded before this fail their check and are skipped: the ranges they covered read BROKEN again until an operator records them afresh. Pre-1.0, with no update hooks, reinstalling is the supported move. - The archive envelope changed only by dropping a field, so a file written earlier still imports. ## Remaining tasks - [x] Chain the three acknowledgment mutations - [x] Move the acknowledgment's operator into the transient tier - [x] Re-check the signing Key's bytes on the status report - [x] Access-check the links into the entries listing - [x] Tests pinning each AI-Generated: Yes (Claude Code was used to audit the module, to draft this issue and to write the fix and its tests. I reviewed all of it, and every defect it reports is pinned by a test.)