## Problem/Motivation Found by a second external review of 1.x at `c0a2c1c`, each confirmed by a kernel test. ### Security 1. **A forged acknowledgment inside an acknowledged range hides tampering.** The acknowledgment replay took every `acknowledgment_*` event row at its word. A walk skips the rows a genuine acknowledgment covers, so a row inside that range is never checked. Somebody with database write access tampers with an earlier row, rewrites a row inside the genuine range into an acknowledgment covering the tampered one, and adds its index row. A strict full verification then reads `Chain "webdav" verified: 21 entries intact.`, authenticated. 2. **A private file downloaded over POST is never recorded.** The shipped `audit_trail_file` chain recorded downloads and refusals for `GET` alone, on the premise that GET is the method that serves the bytes. Core serves a private file to any method, so a POST read the file and left no row, and a refused POST left none either. 3. **A typed login name is stored whole.** A failed login, a flood block and a password reset probe recorded the typed name as submitted. The form refuses a long value, but the value stays on the form state, so one anonymous request with a two-million-character name wrote a two-megabyte row. ### False texts 4. `docs/threat-model.md` said the entries controller escapes with `htmlspecialchars()` before building `#markup`; it renders through an `inline_template`. The entity snapshot contributor said it passes two keys and listed four. ## Proposed resolution 1. The replay checks an event's own signature when the event lies inside a range some event claims: every other event row is one the walk verifies itself. A registered secret whose Key is unavailable is taken as read, so a walk on a host without signing material still honours acknowledgments; an id no secret has is refused. 2. A download is recorded when the response carries the file (`BinaryFileResponse` or `StreamedResponse`), and never for HEAD. The shipped filter keeps only the methods WebDAV sends (`HEAD`, `OPTIONS`, `PROPFIND`, `PROPPATCH`, `MKCOL`, `COPY`, `MOVE`, `LOCK`, `UNLOCK`, `PUT`) out of `file_download_denied`: a refused `PUT` is a refused upload on a WebDAV site, while a served one is still recorded as the download it was. 3. The typed name is cut to `Email::EMAIL_MAX_LENGTH`, the longer of a username and an email address. 4. The texts say what the code does. Tests (each fails on 1.x): - A row rewritten into an acknowledgment inside an acknowledged range excuses nothing. - A download over POST is recorded, served or refused; a WebDAV listing is not a download. - A two-million-character typed name is stored at 254 characters. Performance: replaying 300 acknowledgment events takes 1.13 ms instead of 0.99 ms (range merge and lookup; signatures are only checked inside claimed ranges). Nothing else on a hot path changes. ## Remaining tasks - Recording failed logins through the JSON login route needs a response listener on `user.login.http`, which is a separate decision. ## User interface changes None. ## API changes - `ChainRange::mergeRanges()`, `ChainRange::isCovered()`. ## Data model changes The shipped `audit_trail_file` chain's `request_method` filter changes; an existing site edits its chain to match. AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it.)