## Problem Three routes end in the same place: the operator is told an intact audit trail was tampered with. For a tamper-evidence module that is the worst possible failure, because it destroys trust in the tool itself and there is no way for the operator to tell it from a real attack. The root cause is that a secret's identity is a small integer that gets recycled. `getNextSecretId()` is `max(existing) + 1` over the **entities**, so an id freed by a deletion is handed to the next secret created, now pointing at entirely different key bytes. ## What happens Deleting a `key.key.*` entity at `/admin/config/system/keys` cascade-deletes the `audit_trail_secret` that referenced it, through the ordinary config-dependency graph. That bypasses the delete form's `isUsed()` guard entirely, while the secret entity's own docblock claims Drupal "refuses" this. Create the next secret and it takes the freed id. Every row signed under the old id now recomputes to a different HMAC, and the verifier reports the range **BROKEN**, not "secret unavailable", which is the verdict that would be true. The subtler route needs no deletion: repoint a *used* secret's `key_id` on the edit form. No validation runs on an edit and no confirmation appears, and the verifier then reports "payload HMAC mismatch (row inserted without the signing secret, or hmac column tampered)". The status report cannot help, because `SecretKeyChecker`'s OK entry is discarded by its only caller, so a healthy secret is never positively confirmed. ## Findings in this issue - **H21** `src/Entity/AuditTrailSecret.php`: the freed `secret_id` is reused after a Key cascade-delete, so untouched rows verify as TAMPERED. - **H15** `src/Form`: the secret edit form repoints `key_id` on a used secret with no check, no validation and no confirmation, producing a false tamper verdict. - **H16** `src/Entity/AuditTrailSecret.php`: `isUsed()` probes live tables only, so a secret whose only consumers are archives is deletable. - finding `src/Entity/AuditTrailSecret.php`: deleting a `key.key.*` entity cascade-deletes the referencing secret via `ConfigEntityBase::preDelete()`, bypassing the delete form's guard, while the docblock claims Drupal refuses it. - finding `src/Entity/AuditTrailSecret.php`: the 32-byte floor is enforced only in `activate()`, so a short key reaches a pending secret. - finding `src/Plugin/AuditTrailStatusCheck/SecretKeyChecker.php`: the OK entry is discarded by its only caller, so a healthy secret is never positively confirmed; its notion of "active" is the lowest id, not the active one. ## Proposed fix 1. **Never reissue an id.** Track the high-water mark in state rather than deriving it from the surviving entities, so a freed id is retired permanently. 2. **Make the key relationship non-cascading**, or enforce the guard where the cascade runs. A `key.key` entity that a used secret depends on must not be silently deletable, and the docblock must describe whichever behaviour is chosen. 3. **Refuse to repoint `key_id` on a used secret**, with the check in `validateForm()` so the operator sees the error. 4. **Teach `isUsed()` about archives**, so a secret referenced only by a segment footer counts as in use. 5. Enforce the 32-byte floor on save, not only on activation. 6. Report the OK entry from `SecretKeyChecker`, and make its "active" the active one. Pre-1.0 there are no update hooks to write and renames are free, so this is the moment to fix the identity model rather than to work around it. --- 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. I reviewed it before posting; there is no merge request on this issue yet.)