## Problem Two of these are live on a default install, and one writes credential material into the tier the module promises never to purge. **Password hashes.** `EntitySnapshot::NOISE_FIELDS` lists nine fields to drop from a snapshot (`changed`, `revision_timestamp`, `revision_log`, `revision_log_message`, `revision_user`, `revision_default`, `revision_translation_affected`, `default_langcode`, `content_translation_outdated`). `pass` is **not** among them. So enabling `user` auditing writes every user's bcrypt password hash into `audit_trail`, into `context_permanent`, the tier that is by design never purged. The only mention of passwords anywhere in the submodule's `src/` is a comment. **Public archives.** The archive-directory guard added in #3620118 compares the stream wrapper scheme case-**sensitively**. PHP resolves wrapper schemes case-**insensitively**. So `PUBLIC://audit_trail` passes the guard and the archives are created in the served files tree. Confirmed by registering a wrapper and watching both `is_dir()` and `mkdir()` dispatch the uppercase URI, and by reading core's `FileSystem::mkdir()`. ## What happens Every NDJSON in a public archive directory, holding actor uid, client IP, request URI and full before/after entity snapshots, is fetchable over HTTP at a deterministic, enumerable path, by anyone. The password-hash exposure is worse than an ordinary leak because of where it lands: the permanent tier exists precisely so that its contents survive every retention stage. There is no purge path that removes them, and a hash captured today is still there after every threshold has fired. ## Findings in this issue - **H30** `modules/audit_trail_entity/src/Snapshot/EntitySnapshot.php:74-84`: `NOISE_FIELDS` omits `pass`, so enabling `user` auditing writes every bcrypt password hash into the permanent tier. Corroborated independently by a second pass over the same file. - **H3** `src/Archive/DirectoryChecker.php`: `PUBLIC://audit_trail` passes the web-accessible guard because the scheme comparison is case-sensitive while PHP's wrapper resolution is not. **Proven by execution.** - **H7** `src/Logger`: `chain_only` does not suppress dblog on the PSR-3 path, the path it is documented for, because `LoggerChannel` has already fanned out by the time the module sees the record. A chain marked privacy-sensitive is duplicated into watchdog, readable with `access site reports` and living on dblog's row cap rather than the chain's retention. - finding `src/Archive/DirectoryChecker.php`: the same guard resolves the docroot with `realpath()` and the candidate lexically, so an atomic-release symlink deployment passes an in-docroot path. - finding `src/Form`: the generated key value is submitted in the POST body and echoed back on a validation error; archive files are written under the ambient umask. - finding `src/`: no parameter anywhere carries `#[\SensitiveParameter]`, so the signing secret can reach watchdog inside a `getTraceAsString()` frame. - finding `modules/audit_trail_entity/src`: contributor exception text, deliberately kept out of the permanent bucket for stated GDPR reasons, is logged to dblog anyway. ## Proposed fix 1. **Add `pass` to `NOISE_FIELDS`**, and take the opportunity to make the list a deny-by-type rule rather than a field-name list. Any field whose type is `password` should never be snapshotted, so the next credential-bearing field is excluded by construction rather than by someone remembering. 2. **Compare the scheme case-insensitively** in `DirectoryChecker`, and resolve both sides of the docroot comparison with `realpath()`. 3. **Apply `chain_only` where it can work.** Either suppress at the channel level or document that the PSR-3 path cannot honour it. The current documentation promises the behaviour on exactly the path that cannot deliver it. 4. `#[\SensitiveParameter]` on every parameter that carries key material. 5. Set an explicit mode on archive files rather than inheriting the umask. Related: #3620118 added the web-accessible guard this issue reports as incomplete, and #3594328 covers unsanitized `request_uri` capture in the same forensic envelope. --- 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.)