Bring the response document onto the wiki with the rest It was the only security write-up still living in the repository, at docs/security-review-2026-08.md — which is why the link Ed sent the reporter had /blob/ in it. There was never a round-one wiki page; the wiki's whole history only ever held the round-two and round-three pages. Two things in it had rotted since it was sent, and both are now fixed here and flagged in place rather than silently corrected: - it linked to security/findings-2026-08, a branch since merged and deleted - all eight commit ids in its table were pre-rebase and are orphaned; the table now carries the ids that exist on main, with a note that F5 sits out of sequence because it reached main as a cherry-pick The page opens by saying what it is — a record of what was said at the time, not a live document — and points at the round pages for the current position, because its own Outstanding section is now historical and mostly closed. Linked from Security.md, the round-two developer guide and the sidebar.
Document round three of the security work Two new pages for the nine findings deferred when round two merged, following the same pair as before: plain English for an operator, and a developer guide that gives each finding its risk, a reproducible proof of concept, the mitigation and why that mitigation actually closes it. The existing round-two pages now say what has been superseded and what has not, rather than leaving a reader to work out that their outstanding sections are partly historical. Security.md carries both new links, and the sidebar lists all four. Care taken to keep the same framing Erlend asked for: the outstanding sections lead, they name CSRF and lms/content as open in main today, and the round-three guide records where a mitigation is conditional rather than absolute — the CSP layer on the branding directory is skipped entirely without mod_headers, which was measured on a stock WAMP rather than assumed.
Mark the security work merged, and keep the open findings visible Erlend signed the branch off on 2026-08-12 and it has fast-forwarded into main at 86f8d257, so the "awaiting sign-off" and "not yet merged" banners on both hardening pages were wrong. His one substantive request was about framing rather than code: the deferred items must not read as closed. S2 is four live cross-tenant bugs reachable in main today, not a hardening backlog. Both pages now say that plainly, and the Security page — which described none of this and was the page an evaluator would actually land on — now carries the disclosure history and points at the outstanding list. Also corrects the default-admin bullet on Security: the published password is still admin/freeitsm, but since S5 the account is seeded with must_change_password so it cannot survive first sign-in, and Database Verification flags older installs still using it.
Security hardening 2026-08: add a troubleshooting section The page explained what changed and why, which is not the same as being able to fix a regression it caused. Five of these changes can now REFUSE something that previously worked, and in every case the symptom names the wrong culprit -- S3 in particular turns a database fault into what looks like a permissions problem. Adds: a symptom-to-cause table for the five tightening changes, the exact log strings to grep (all verified present in the code), the one genuinely new failure mode -- a secret that will not decrypt now reads as EMPTY rather than as visible ciphertext, so "the token is blank" means a key mismatch and not an unset setting -- and per-change revert notes. Two of them need care rather than a plain revert: reverting S5 does not clear a must_change_password already set, and reverting R3 restarts the media quarantining that was the whole complaint. S3 should not be reverted at all; if it is denying, the database fault it reports is the thing to fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Security hardening 2026-08: a user page and a developer guide The second round of the August security work -- the nine items Erlend Volden raised when he re-reviewed our fixes to his original report, plus four bugs in our own first-round code. Two pages, deliberately, because they have different readers: Security-Hardening-2026-08 answers four questions per item in ordinary language -- what was wrong, how it could have been used against you, what changed, and why that fixes it. Each item is labelled as a security flaw or as a feature we broke while fixing one, since both happened and the difference matters. Security-Hardening-2026-08-Developer-Guide is the same nine items with the code: file table, the before/after shapes, why the isMultiTenant() short-circuit in S1 is load-bearing, and what is deliberately still outstanding. Both carry a "not yet merged" notice, because the branch is still awaiting the reporter's sign-off and neither page describes current main. Every file path and wiki link in both pages was checked to resolve. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>