Merge pull request #792 from craigk5n/feat/audit-line-endings-note feat: the audit says when a file differs only in line endings

Merge pull request #791 from craigk5n/fix/788-zone-tab-crlf fix: zone.tab shipped with CRLF, so the audit called it modified (#788)

feat: the audit says when a file differs only in line endings A file whose content matches MANIFEST.sha256 once CRLF and LF are normalised is now annotated, and the advice changes from “restore from release zip” to saying the content is otherwise identical and no action is needed. It is still reported. The file does differ from the bytes that were signed, and suppressing it would be the wrong trade for a page whose job is to notice that. What changes is that the page says which kind of difference it found. The prompt was #788: includes/zone.tab shipped with CRLF, an extraction converted it to LF, and establishing that took two hashes and a size comparison by hand. An unexplained “modified file” on an installation where nothing was touched is how administrators learn to ignore the page, and this will recur with any deployment pipeline that normalises text. Both directions are detected, because the conversion goes both ways: an extraction in text mode strips the CRs from a file shipped with CRLF, and an editor or checkout on Windows adds them to one shipped with LF. The manifest stores a hash rather than content, so the only way to ask is to convert the local copy and hash each candidate. Not softened anywhere it matters. Severity stays WARN and the kind stays MODIFIED. Content with a NUL byte is excluded, so a tampered GIF that happens to contain \r is never described as a line-ending difference. A change that alters content *and* line endings is not annotated. The check is capped at 8MB against the 1.5MB largest file in a release. Six mutations, each asserted written to disk before the verdict was believed: never annotate, always annotate, drop the binary guard, handle only one direction, stop branching in the hint, and have the table call the kind-only hint. All six caught — including “always annotate”, which is the one that would describe a webshell as harmless. The hint test lifts action_hint_for_file() out of security_audit.php and runs it with translate() stubbed, rather than asserting against its source. The first draft did match the source, which is the mistake behind the seven hollow guards repaired in v1.9.24 — a test satisfied by the prose in the function it is checking. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

fix: zone.tab shipped with CRLF, so the audit called it modified (#788) includes/zone.tab was committed with CRLF on all 407 lines. It was the only text file in the release doing so; .editorconfig has said end_of_line = lf for years, and the five other \r-bearing shipped files are binaries — a favicon, three GIFs and a TrueType font. Nothing read the file wrongly. display_tz_selection() does trim() then preg_split(‘/[\s,]+/’), so CRLF and LF produce the same 383 timezones; verified by parsing both forms and diffing the lists. The cost was to the signed manifest. MANIFEST.sha256 records the bytes that ship, so any deployment pipeline that normalises line endings — an extraction in text mode, a packaging step, an editor — leaves that one file disagreeing with its own manifest, and Reports > Security Audit reports it modified forever on an installation where nothing was modified. Diagnosed from the reporter’s two hashes rather than guessed: 2892d401… manifest, ZIP, v1.9.24 tag, v1.9.23 tag, working tree c20d18d3… the reporter’s file — exactly ours with the CRs stripped A substituted system zone.tab would differ in content, not solely in line endings, so the conversion is certain. Size alone shows it too: 17927 bytes shipped against 17520 converted, the 407 CRs. Reading straight out of the archive with `unzip -p` gives the manifest’s value, which is why extraction is the suspect rather than the build. Converting to LF makes the file hash c20d18d3… — the value the reporter already measured — so their installation will match the next release’s manifest. tests/ShippedLineEndingsTest.php fails the build when any file listed in release-files contains CRLF, treating a file as binary when it contains a NUL byte, the same heuristic git uses. All five shipped binaries contain NUL and no text file in the tree does. Four mutations, each asserted written to disk before the verdict: CRLF everywhere, a single CRLF line, one bare CR, and CRLF in a different shipped file. All four caught. This does not help existing v1.9.24 installations, whose manifest correctly describes CRLF bytes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Merge pull request #787 from craigk5n/fix/release-skill-accuracy docs(release): correct an unverified outage claim, and the reverse case