## Problem A config dependency is not a protection. It declares that the dependent is *affected* when the config it names goes away, and Drupal resolves "affected" as **deletion** unless the dependent says otherwise: `ConfigEntityBase::preDelete()` deletes every dependent whose `onDependencyRemoval()` does not keep it. `AuditTrailSecret::calculateDependencies()` declares the `key.key.*` entity holding the signing bytes. So deleting a Key deleted the `audit_trail_secret` that named it. That is the one entity the module refuses to remove by its own door. `AuditTrailSecretDeleteForm` says why: *"Only unused secrets can be deleted. If this secret has signed any chain row, checkpoint, segment or acknowledgment, retire it instead. Historical verification depends on the entity remaining resolvable."* The Key route reached the same entity and was not refused. What the cascade cost is the mapping. The entity is the only record on the site of which Key signed which `secret_id`: ``` Key deleted, entity kept: Chain "webdav" ... audit_trail secret #1 references Key entity "x", but no such Key exists. -> restore the Key from backup, verification returns Key deleted, entity gone: Chain "webdav" ... audit_trail HMAC secret #1 has no audit_trail_secret entity. Either the secret is retired and was deleted, or the row carries a forged secret_id. -> nothing on the site still says which Key it was ``` So a routine-looking key hygiene action turned a recoverable state into an unrecoverable one, silently. `audit_trail_tsa_provider` had the same shape. A `tsa_timestamp` row names its provider by a bare `tsa_id`, and `Tsa\ChainTimestamper::verifyRow()` resolves the provider by that id to get the certificate chain it checks the stored RFC 3161 response against, so the provider is what those timestamps are verified through. A Key carrying only the transport credential could take it. Three surfaces described the cascade as a *protection against* the deletion: `docs/threat-model.md` listed it among the mitigations in force as a handler that "refuses to delete a Key", `AuditTrailTsaProvider::calculateDependencies()` claimed the same in its docblock, and `docs/security.md` told operators not to delete a Key while giving only the janitorial reason. ## Fix A Key an `audit_trail_secret` or an `audit_trail_tsa_provider` references cannot be deleted. The refusal reaches the admin UI, `drush`, update functions and every other caller, because it is taken at the storage handler rather than on a form. It is split across two methods, and the split is the point. `onDependencyRemoval()` marks the departing Key and returns TRUE; `preSave()` throws `AuditTrailSecretKeyInUseException`. Throwing from `onDependencyRemoval()` alone does not work. The Key's own delete form calls it as a **dry run**, through `ConfigDependencyDeleteFormTrait`, to list what a deletion would affect, so a throw there white-screens the page an operator opens precisely to find out. A real deletion is the one that goes on to **save** the dependent, and `ConfigEntityBase::preDelete()` does that before it deletes anything and before it removes the Key, so the refusal lands with nothing yet gone. Two other mechanisms were tried and do not work, which is worth recording: - `hook_key_predelete()` is too late. `EntityStorageBase::delete()` runs `$entity_class::preDelete()`, which performs the cascade, *before* `invokeHook('predelete')`. - `hook_key_access()` is never consulted. `key.routing.yml` guards the delete form with `_permission: 'administer keys'`, not `_entity_access`. The dependency declaration stays. It is what the relationship is, and config export ordering, config diffs and the Key's delete form all read it. It is simply no longer what does the protecting. The Key's delete form now answers before the confirmation: the submit button is removed and the description names the secrets, in the shape `AuditTrailSecretDeleteForm` already uses on the other door into the same entity. ## The one route that still removes a Key `ConfigEntityBase::preDelete()` skips dependency resolution entirely for an entity that is syncing or being uninstalled, so a **config import** that does not carry the Key still removes it, and uninstalling still uninstalls. Blocking those would break deployment, so they are left alone. In that state the secret survives still naming the Key, the verdict names it, and restoring the Key from backup restores verification. That exemption is also what the test suite needs: it simulated "secret lost in migration" by deleting a Key, which is now refused, so those fixtures go through `AuditTrailSecretTestTrait::deleteAuditTrailKeyAsConfigSync()`. ## Test coverage `SecretKeyDependencyTest` walks the routes a deletion actually arrives by, each failing against the unfixed code: - `testDeletingTheKeyIsRefused`: the entity method. - `testDeletingThroughTheStorageHandlerIsRefused`: the storage handler, singly and in bulk, which is what `drush`, hooks and update functions reach it through. - `testTheRefusedDeletionChangesNothing`: the Key, the secret, its declared dependency and the chain verdict are all exactly as they were. - `testTheKeyDeleteFormRefusesBeforeConfirming`: no submit button, and the reason in the description, so the exception is never the interface. - `testTheSecretIdIsNeverReused`: unchanged, and pinned because it is what keeps a retired secret's rows honest. `AuditTrailTsaProviderEntityTest::testDeletingTheKeyIsRefused` pins the submodule. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the fix and its tests. I reviewed both, and each test was confirmed to fail against the unfixed code and to pass with the change.)