REPORT: v0.333.0 is the floor (R-1155, R-1161)
gates / gates (push) Successful in 44s

This commit is contained in:
2026-10-19 12:16:57 +02:00
parent a6fa3c01d2
commit e1a2abf1e3
+24 -15
View File
@@ -1,17 +1,26 @@
# REPORT — controller v0.332.0 (2026-10-19, day brief)
# REPORT — controller v0.333.0 (2026-10-19, second day brief)
**Shipped and the floor for every box** (03:24 UTC, MinAgent 0.158.1, after Tester 1, demo-hp and demo-felhom took it by the
normal update path and the box walk was green on all three).
**Shipped and the floor for every box** (10:16 UTC, MinAgent 0.158.1), after Tester 1, demo-hp and demo-felhom took it by
the normal update path (per-box floors 09:59 UTC; all three on 0.333.0 within about a minute, demo-hp from rc.2 at its
next report) and the box walk was green on all three. Image `0.333.0` digest
`sha256:f150a8d8cd329f5cde9e34249e34edc59b6b5db29db1e3200900f3869a0de11b`, built from `a6fa3c0`. rc.1 and rc.2 ran on
demo-hp 9201 only.
- **One sign-in for the file manager (R-1100, operator D16).** „Fájlok ↗" goes through the dashboard's one-time pass to a
host-only files cookie; traefik's forwardAuth then sets the box's secret header naming FileBrowser user
`felhom-household`. FileBrowser opens at the folder with no login; a dashboard sign-out asks again; forged headers are
refused through traefik and from an app container (only the box's secret name, the control, gets in). Fixed before the
release: a relative redirect in the forwardAuth answer (traefik pointed it at the controller), a cross-site pass and
dot-segments in `to` (a security review).
- **The typed-back escrow confirm (R-1151):** the wizard sends the two words to the agent (≥ 0.160.0), which stores the new
package only then; an older agent needs no confirm.
Tests and red-proofs: `CHANGELOG.md` v0.332.0. Live evidence: felhom.eu `documentation/audits/day-2026-10-19/` P1 (escrow),
P2 (one sign-in), P4 (release). Fixtures changed (named): `escrow_first`, `escrow_receremony`. Full report: felhom.eu
`REPORT-day-2026-10-19.md`.
- **R-1155 — FileBrowser's own token ends with the dashboard session.** Measured first on demo-hp: the household user's
FileBrowser token (HS256; claims `belongsTo`, `Permissions`, `iat`, `exp` = 2 h, `iss`) opened `/api/users?id=self` (200)
after the dashboard sign-out, as a cookie and as a Bearer header. Now the forwardAuth answer refuses a request with no
valid files cookie that carries a non-admin FileBrowser token, in every place FileBrowser 1.5.6 reads one (cookie,
`?auth=`, Bearer, Basic password). Live on rc.2 (demo-hp) and on 0.333.0 (Tester 1): with the files cookie 200; the token
alone 401 in all four forms, before and after the sign-out; FileBrowser's sign-in page 200.
**Security review:** the first version (`c809dd3`) missed Basic auth — FileBrowser takes a Basic-auth password as the
token. Fixed in `a6fa3c0` before any release; red-proved (Basic → 200 without the branch).
- **R-1161 — the recovery-code page:** the reveal now says the code becomes live after the two words come back, and that
closing the page keeps the old code; the old sentence shows only for an agent before 0.160.0. Live on demo-hp: the new
text shown, the old one hidden, the switch present, a negative control absent. Fixtures re-captured:
`escrow_first`, `escrow_receremony`; all others byte-identical.
- **The Chrome „Install" chip: NOT-A-FINDING** — FileBrowser 1.5.6 has no setting that stops its web manifest
(`disablePWAInstall`, already set, is the only PWA key).
- Box walk (felhom.eu `documentation/audits/day-2026-10-19b/P6/`): 0 unhealthy, 0 allow-list refusals, catalog in sync on
all three; https-only 28 OK, 0 failures; „Fájlok ↗" with no second login on demo-hp and Tester 1, sign-out asks again.
- Residual: `admin`'s password login on FileBrowser is pinned by a unit test (admin's token passes) and the sign-in page
answers 200 live; a full admin sign-in was not walked live (CC holds no FileBrowser admin password).