2 Commits

Include renames

Author	SHA1	Message	Date
mrambossekandClaude Opus 5	7a5004f293	server: a non-admin account can manage its own uploads ... Signing in and being allowed to administer the server were the same question: the OIDC callback refused a session outright to anyone outside the admin group. A legitimate user could authenticate, be told what they could not do, and be left with no way to see or delete the data their own devices had uploaded. They are separate questions now. Everyone who authenticates gets a session; the admin flag rides inside the MAC'd payload, so promoting yourself means forging a signature rather than editing a cookie, and a role that does not parse fails closed to "user". Pages scope themselves through visibleDevices/mayTouchRun rather than filtering individually — per-page scoping is what the next page added will be missing, and that failure is silent, since a listing that leaks other people's uploads looks exactly like one that does not. Someone else's run answers 404, not 403: a distinguishable refusal would confirm the run exists. Revoking devices and minting enrolment tokens affect the whole server and stay behind adminOnly at the route table, where someone looking for who-may-do-what will actually find it. Ownership is re-read per request instead of captured at sign-in, so unlinking an account takes effect immediately rather than at session expiry. Tests cover that, plus the degenerate case of an empty subject, which must own nothing rather than everything with an empty account id. Also: attribute the ICMPv6 finding per network. It compared "is IPv6 configured anywhere on this device" against "did any network answer", which on a phone reports IPv6-is-broken about a network where IPv6 was never configured. network_ref is null on every test, so the probe now records per-network outcomes structurally rather than as prose a finding would have to parse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 21:10:38 +02:00
mrambossekandClaude Fable 5	89a5ff9139	adminauth: a break-glass local admin alongside OIDC ... If the IdP is misconfigured, unreachable, or the admin group is a typo, the operator is locked out of their own server with no way back short of editing JSON on disk. A fallback that only matters when everything else is broken is exactly the thing you cannot add later - by then you cannot get in to add it. Stored as PBKDF2-HMAC-SHA256 from the standard library (Go 1.24+ has it, so no dependency), 600k iterations, per-credential salt. A password rather than a bearer token on purpose: a break-glass credential is the one most likely to end up in a backup or a config-management repo, and a hash survives that where a token does not. There is no email reset flow and should not be - --set-admin-password on the host is the reset, and whoever can run it already has the machine. The password is read from stdin, never a flag, so it stays out of shell history and the process list; piping still works for automation. Details the tests pin, each for a reason: - the username is compared in constant time too, or a fast rejection is a timing oracle for which usernames exist; - the *stored* iteration count is used, so raising the constant later does not lock out existing passwords; - the throttle grows with consecutive failures but stays bounded and forgives after a quiet minute - a break-glass credential an attacker can lock out is a denial of service against the one person who needs it; - sessions are MAC-checked before anything in them is read, and rotating the secret invalidates every one at once, which is how they are revoked. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 17:12:54 +02:00