## Problem Four surfaces render an integrity verdict: the entry-detail page, the segments list, the status report, and the Drush exit code. None of them owns it. Each recomputes some subset of the verifier's checks and phrases the result in its own words, so they disagree. The entry-detail page is the sharpest example: it says "Row #N verifies fully" while running **2 of the verifier's 4** per-row checks. It does not check `previous_hash` at all, even though the predecessor's hash is already selected in the same query. ## What happens An operator investigating a suspected tamper reads a page that asserts a row is fully verified on the strength of half the checks. If they then run the verifier they get a different answer, with no indication of which to believe. The segments status conflates a missing signing secret with a signature mismatch, and mislabels both, so "unavailable" and "tampered", the two verdicts an operator most needs to tell apart, render the same way. ## Findings in this issue - **H12** `src/Controller`: the entry-detail page says "Row #N verifies fully" while running 2 of the verifier's 4 per-row checks, and skips `previous_hash` although the predecessor's hash is already selected. - **H14** `src/Plugin/AuditTrailStatusCheck`: the status report asserts clean over acknowledged breaks. - finding `src/Archive/AuditTrailSegmentListBuilder.php`: the segments status conflates a missing secret with a signature mismatch, and mislabels both. - finding `src/`: three CSS hook classes are emitted with no rules behind them anywhere in the module. - finding `src/Controller`: verify links are rendered with no access check in two files, and permission descriptions understate their scope. - finding `src/Hook/AuditTrailRequirementsHooks.php`: `SecretKeyChecker`'s OK entry is discarded by its only caller, which reads the entry's severity and returns the map only when it is an Error. A working secret therefore has no line on the status report, and an operator cannot tell "checked, fine" from "never checked". - finding `src/Requirements/SecretKeyChecker.php`: the id that entry names is the LOWEST active secret, not the one signing. Two actives is a real state (`activate()` promotes before it retires, so a crash leaves two), and rows written in that window are signed under the newest. Both found while fixing #3620309 and folded in here, as the fourth surface rendering a verdict of its own. - finding `src/Form/AuditTrailSecretForm.php`: carried over from #3620315, whose byte-length check on the secret form runs on every submit and so judges a key the operator did not choose. A secret already in service cannot be pointed at different bytes either, so both answers are refused and the form has no way out, not even to fix the label. Reachable without anyone activating a short key: a truncated file, a reset environment variable, or a configuration import. Fixed here because #3620315 merged first and this MR touches the same form. ## Proposed fix Give the verifier one public method that returns the per-row verdict, and have all four surfaces render **that**, with no surface recomputing a subset and none phrasing its own verdict. Then: - distinguish "secret unavailable" from "signature mismatch" in the returned verdict, and render them differently everywhere; - run the access check where the verify links are built; - correct the permission descriptions to match what the permissions actually allow; - add rules for the three CSS hook classes, or stop emitting them; - return the healthy secret entry rather than only the failing ones, and take the id it names from `SecretRepositoryInterface::getCurrentSecretId()` rather than answering the question a second time. Note: an earlier pass on this area also claimed the audit pages leak a cached integrity verdict through missing cache metadata. That claim was withdrawn. `_admin_route: TRUE` means `DenyAdminRoutes` stops Dynamic Page Cache storing anything, Internal Page Cache is anonymous-only, and there are no `#cache['keys']`, so nothing is stored. Declaring the metadata is still correct, but it is a one-line correctness fix and not a security matter. --- 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, and to write the fix and its test cases in the merge request. I reviewed both; each new test was confirmed to fail without its fix and to pass with it.)