## Problem/Motivation Found in the fifth release audit of 1.x at `c5fb4ea`. ### Security 1. **The full verification ignores a forged checkpoint.** `AuditTrailVerifier::verifyChain()` reads the latest checkpoint to catch a chain whose end was deleted, but it drops the "the checkpoint's signature does not verify" outcome. Only the incremental walk reports it ("WARNING: previous checkpoint signature was invalid"), and the status report only sees it from there. The full walk is what an operator runs when they suspect something. Forging the latest checkpoint is how a deletion from the end of a chain escapes the deleted-tail verdict, and the forged checkpoint is then the only trace left. 2. **An imported archive chooses the directory it is written to.** `SegmentRestorer::importFromFile()` takes the chain id from the file's footer and builds the archive directory and path from it. The footer is only authenticated when its secret resolves; with *Allow import without secret* (form) or `--allow-missing-secret` (Drush) it is taken as found. A footer naming the chain `../../x` creates directories and copies the archive outside the archive directory, and records a segment and a chain entry under a name no chain can have. Only an administrator can import. ### False texts 3. Activating a secret is two saves, activate then retire, and `KeyBackedSecretRepository` documents why. The secret form and the `STATUS_PENDING`/`STATUS_ACTIVE` documentation say the previous secret is retired "in the same transaction", and `SecretRepositoryInterface::setSigningSecret()` says "in the same save". The secret delete form says a used secret "has already signed audit-trail rows or checkpoints", leaving out segments, which it also counts. The TSA provider texts say the previous provider is deactivated "in the same save"; it is two saves in one transaction. 10. The incremental verdict drops what its walk found. On a clean walk it replaces the whole message with its opening, so an acknowledged or WORM-bridged range goes unsaid, unlike the full walk. On a broken walk it leaves out the forged and stale checkpoint warnings, so a forged checkpoint over tampered rows is reported as tampered rows only. Its stale note blames archive and purge for a row that is still there with another hash. ### Duplication and dead code 4. `EffectiveDelays::THRESHOLD_KEYS` restates four of the five keys of `RetentionThresholds::STAGE_KEYS`. 5. The broken-chain message and its acknowledge link are built three times: in the status report, in the broken-chain warning shown on the admin pages, and in the message after an on-demand verify. The copies have drifted. The link texts differ, and only the warning checks access to the acknowledgment form, so the status report (readable with *administer site configuration*) and the verify message (shown with *run audit trail verification*) can offer a link that answers 403. 6. The live delay preview is wired twice, in the chain form and in the settings form: the same Ajax settings, the same loop over the fields that refresh it, the same refresh callback and the same element around the table. 7. `audit_trail_entity` computes "this module's configuration is excluded from export" in its settings form and in its entity hooks. 8. `audit_trail_entity_paragraphs_uninstall()` removes the paragraph ancestry contributor from the entity chain. The chain already depends on the module providing each of its plugins and drops the plugin when that module is uninstalled, so the hook has nothing left to do. Its install hook also restates the default depth cap. 9. The TSA Drush commands redefine the "cannot run" exit code that `AuditTrailCommands` exports. ## Proposed resolution 1. The full verification reports a checkpoint whose signature does not verify, with the same warning as the incremental walk, and returns it as `checkpoint_forged` so the status report sees it as well. 2. An import whose footer names a chain id that is not a machine name is refused before anything is written. The archive directory helpers refuse such an id too. 3. The texts say what happens. 4. to 9. One definition of each, the dead hook removed. 10. The incremental verdict keeps the walk's summaries, gives the checkpoint warnings whatever the walk found, with the same forged-checkpoint warning as the full walk, and says the stale case as it is. Tests: - A full verification of a chain whose latest checkpoint is forged names the forgery. - Importing a file whose footer names the chain `../escape` is refused, and nothing is written outside the archive directory. - The status report offers the acknowledge link only to a user who can open the acknowledgment form. - A change to a retention field refreshes the delay preview, on the chain form and on the settings form. - Uninstalling the paragraphs submodule leaves the entity chain without its contributor. - The incremental verdict names an acknowledged range, a forged checkpoint over a tampered row, and a stale checkpoint whose row changed hash. ## Remaining tasks None. ## User interface changes - The full verification can now say that the latest checkpoint's signature did not verify. - The status report's acknowledge link has the same text as the one on the admin pages, and is shown only to users who can use it. - The incremental verdict's message names acknowledged and bridged ranges, and its checkpoint warnings. ## API changes - `AuditTrailVerifier::verifyChain()` returns `checkpoint_forged`. AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it.)