BIGNIGHT phase 3: immich + vaultwarden seeded; R-512 filed (vaultwarden open signup, read-only control)

documentation/audits/evidence-bignight-2026-09-14/journal.md

@@ -321,3 +321,14 @@ Household use: a child deletes foto-007 (204 → 404); trashbin lists it; restor
 Admin used 343 161 297 B. Nextcloud 34.0.1.
 
 **immich** 18:22:57 deploy → +116 s `degraded` → +126 s `starting` … (continues below).
+
+**immich** running after 146 s (degraded 116 s on the way). Seed through its API: admin sign-up (201), **200 JPEG
+uploads, 200 × 201 in 16 s**; stats photos 200, 275 682 444 B; ML queues draining (faceDetection / smartSearch / ocr).
+
+**vaultwarden** 18:25:37 → running **15 s**. Seed with the Bitwarden client crypto (PBKDF2 600 000, AES-CBC + HMAC):
+register (200), token (200), **10 login entries** (200 × 10), `/api/sync` → 10 items, **all names decrypt to the
+originals**. Attachment: the v2 slot's returned `url` is `/ciphers/<id>/attachment/<id>` — posting it to the web root
+404s, under `/api` 200 (a client detail, the harness's first try left one empty attachment slot on „Ügyfélkapu+").
+The retried attachment downloads 200 with its recorded size; byte-equality not proven (harness lost the key).
+**Finding R-512 (P2):** registration stays open and the page's instruction to close it points at a read-only
+field; a stranger registered with no invite (200).

documentation/audits/evidence-bignight-2026-09-14/phase3/deploy-paperless-ngx.txt

@@ -0,0 +1,9 @@
+  select HDD_PATH: options=['Adatlemez — 92.1 GB szabad (alapértelmezett)'] -> /mnt/felhom-drives/hdd_1
+  select PAPERLESS_OCR_LANGUAGE: options=['Magyar', 'Angol', 'Magyar + Angol', 'Német + Angol'] -> hun
+paperless-ngx: fields ['DB_PASSWORD', 'HDD_PATH', 'PAPERLESS_ADMIN_PASSWORD', 'PAPERLESS_ADMIN_USER', 'PAPERLESS_OCR_LANGUAGE', 'PAPERLESS_SECRET_KEY', 'SUBDOMAIN']; secrets in /tmp/claude-1000/-mnt-5-hdd-felhom-eu-git/a23ddbf6-6c9b-4b80-8fa9-69a2a962eeb6/scratchpad/apps/paperless-ngx.json: ['DB_PASSWORD', 'PAPERLESS_SECRET_KEY', 'PAPERLESS_ADMIN_PASSWORD']
+POST 18:26:12
+  -> {"ok":true,"message":"Telepítés elindítva – az állapot a kártyán követhető"}
+
+  +5s not_deployed
+  +10s deploying
+  +81s starting

documentation/audits/evidence-bignight-2026-09-14/phase3/deploy-vaultwarden.txt

@@ -0,0 +1,8 @@
+  select SIGNUPS_ALLOWED: options=['Igen – regisztráció engedélyezve', 'Nem – regisztráció lezárva'] -> true
+vaultwarden: fields ['ADMIN_TOKEN', 'SIGNUPS_ALLOWED', 'SUBDOMAIN']; secrets in /tmp/claude-1000/-mnt-5-hdd-felhom-eu-git/a23ddbf6-6c9b-4b80-8fa9-69a2a962eeb6/scratchpad/apps/vaultwarden.json: ['ADMIN_TOKEN']
+POST 18:25:37
+  -> {"ok":true,"message":"Telepítés elindítva – az állapot a kártyán követhető"}
+
+  +5s starting
+  +15s running
+vaultwarden: final running after 15s

documentation/audits/evidence-bignight-2026-09-14/phase3/seed-immich.txt

@@ -0,0 +1,9 @@
+18:25:52 ping 200 {"res":"pong"}
+18:25:52 admin sign-up 201 {"id":"92edabde-2331-4d62-808b-6b183f35c0c8","email":"csalad@enkicsifelhom.hu","name":"Kovács Anna","profileImagePath":"
+18:25:52 login 201
+18:26:09 uploaded 200 in 16s codes {201: 200}
+18:26:09 stats 200 {"photos":200,"videos":0,"usage":275682444,"usagePhotos":275682444,"usageVideos":0,"usageByUser":[{"userId":"92edabde-2331-4d62-808b-6b183f35c0c8","userName":"Kovács Anna","photos":200,"videos":0,"usa
+18:26:09 jobs pending {'thumbnailGeneration': (3, 129), 'metadataExtraction': (5, 6), 'faceDetection': (2, 55), 'smartSearch': (2, 55), 'storageTemplateMigration': (1, 0), 'ocr': (1, 56)}
+18:26:39 jobs pending {'faceDetection': (2, 194), 'smartSearch': (2, 181), 'ocr': (1, 197)}
+18:27:09 jobs pending {'faceDetection': (2, 188), 'smartSearch': (2, 163), 'ocr': (1, 193)}
+18:27:39 jobs pending {'faceDetection': (2, 182), 'smartSearch': (2, 144), 'ocr': (1, 189)}

documentation/audits/evidence-bignight-2026-09-14/phase3/seed-vaultwarden.txt

@@ -0,0 +1,25 @@
+18:26:11 register /identity/accounts/register 200 {"captchaBypassToken":"","object":"register"}
+18:26:12 token 200 {"AccountKeys":null,"ForcePasswordReset":false,"Kdf":0,"KdfIterations":600000,"KdfMemory":null,"KdfParallelism":null,"Ke
+18:26:12 cipher 200
+18:26:12 cipher 200
+18:26:12 cipher 200
+18:26:12 cipher 200
+18:26:12 cipher 200
+18:26:12 cipher 200
+18:26:12 cipher 200
+18:26:12 cipher 200
+18:26:12 cipher 200
+18:26:12 cipher 200
+18:26:12 attachment slot 200 {"attachmentId":"5090ce0842ccb25ae6fa","cipherResponse":{"archivedDate":null,"attachments":[{"fileNa
+18:26:12 attachment upload 404 <!DOCTYPE html>
+<html lang="en">
+<head>
+    <meta http-equiv="content-type" cont
+18:26:12 sync 200 items 10 decrypted names match True
+slot 200 url shape /ciphers/<id>/attachment/<id>
+upload try /ciphers/<id>/attachment/<id> 404
+upload try /api/ciphers/<id>/attachment/<id> 200
+attachment 404 1834 (an earlier empty slot or a different key)
+attachment 200 115922 (an earlier empty slot or a different key)
+attachment ugyfelkapu-helyreallito-kod.bin size field 64065 meta 200 download 404 1834
+attachment ugyfelkapu-helyreallito-kod.bin size field 115922 meta 200 download 200 115922

documentation/audits/evidence-bignight-2026-09-14/phase3/vaultwarden-stranger-signup.txt

@@ -0,0 +1,2 @@
+18:27:20 SIGNUPS_ALLOWED deployed value: true
+a stranger (no invite, no login) registers idegen.probe@example.com -> 200 {"captchaBypassToken":"","object":"register"}

documentation/backlog/OPEN-ITEMS.md

@@ -715,6 +715,7 @@ class (an image `VOLUME` at an unmounted path) is still live — `immich-server`
 | **R-509** | **[P1-HIGH] A box installed for an EXISTING customer never gets the self-bind e-mail the console tells the volunteer to open.** MEASURED 2026-09-14 (BIGNIGHT, VM 333, ISO 1.27.1): customer `tester-1` now has `tester1@felhom.eu` registered; the box registered as appliance 28 at 17:44:53Z and its console says „Nyisd meg az e-mailben kapott linket"; **ten minutes later the mailbox (read through the Gmail connector) held 0 messages to that address.** Cause, from source: the hub auto-sends the link only at customer creation (`hub/internal/web/configs.go:725`) and at RESET completion (`customer_reset.go:162`); a customer whose e-mail was added later, or whose previous box was destroyed, never receives one unless the operator presses „Send self-bind link". The volunteer guide's operator prerequisites do not list that press. Intervention **I1** of the big night (the operator's button pressed). **Fix shape (for the operator to choose):** send the link when an unclaimed appliance registers and a customer with no host is waiting, or add the press to the guide's operator prerequisites (day-0 A.2). | **READY — rank P1-HIGH; owner: CC (hub fix) · operator (which fix shape)** |
 | **R-510** | **[P1-HIGH] `tester-1`'s tunnel now has its route, and still gives a fresh box 502: the route sends traffic to `https://traefik` WITH certificate checking, and traefik answers the name `traefik` with its default certificate.** MEASURED 2026-09-14 (BIGNIGHT, VM 333, ISO 1.27.1, controller 0.242.0), after the operator's R-505 fix: from DooPlex `https://felhom.enkicsifelhom.hu` → **502 ×3** (18:07:48Z, `server: cloudflare`). The box's `cloudflared` logs `Request failed … tls: failed to verify certificate: x509: certificate is valid for 544346c4….traefik.default, not traefik … ingressRule=0 originService=https://traefik`. Traefik itself holds a valid Let's Encrypt `CN=*.enkicsifelhom.hu` (openssl on 127.0.0.1:443 with SNI). **Control:** demo-hp's working tunnel config reads `{"hostname":"*.enkisfelhom.hu", "originRequest":{"noTLSVerify":true}, "service":"https://traefik"}` — the same route WITH `noTLSVerify`. So the Cloudflare-side public hostname for `*.enkicsifelhom.hu` lacks „No TLS Verify" (or an origin server name). The Cloudflare side is not visible to the session; the inference rests on the log line and the control. Intervention **I2** of the big night: the claim and every dashboard request go to the guest's LAN address with the name forced. **Fix:** operator ticks „No TLS Verify" on that public hostname, then day-0 A.1 names the setting beside the route. | **WAITING-ON-OPERATOR — rank P1-HIGH; owner: operator (Cloudflare route), CC (day-0 A.1 wording after)** |
 | **R-511** | **[P2-MEDIUM] A customer whose box is rebuilt keeps its ep0 PBS token, and then the DR tier can be neither provisioned nor re-issued: the hub's error advises the one action that refuses.** MEASURED 2026-09-14 (BIGNIGHT, VM 333, `tester-1`, DR tier ticked): on the new box's WireGuard registration the hub logged `[ERROR] pbsdr auto-provision for tester-1 (WG-registration hook): the endpoint already holds a PBS token for tester-1 but the hub has no descriptor — use the explicit "Re-issue PBS credentials" action — save the customer config to retry`. The operator's `POST /configs/tester-1/pbsdr-reissue` → **400 `No provisioned PBS DR tier for this customer`** (`hub/internal/web/pbsdr.go` ~411). The token was left by the doorstep walk's host delete (a host delete does not deprovision tenancy; only RESET does, which also removes the tunnel). So a box rebuilt for an existing customer — the reinstall journey — has no whole-guest off-site tier and no button that restores it. **Fix shape:** let re-issue adopt an existing endpoint token when the descriptor is absent (the message already assumes it does), or have host delete offer to drop the PBS token. | **READY — rank P2-MEDIUM; owner: CC (hub)** |
+| **R-512** | **[P2-MEDIUM] Vaultwarden is installed with open registration, and the one control the page tells the customer to use to close it is read-only.** MEASURED 2026-09-14 (BIGNIGHT, VM 333, controller 0.242.0, catalog vaultwarden 1.36.0-alpine): the deploy form sends `SIGNUPS_ALLOWED=true` (catalog default); after install, „Vaultwarden — Beállítások" says „Ez az alkalmazás már telepítve van. **Az alábbi beállítások csak olvashatók.**" and, below it, „Regisztráció engedélyezése — Igen / Nem — Új fiókok regisztrálásának engedélyezése. **Az első fiók létrehozása után állítsd 'Nem'-re.**" At 18:27:20Z a stranger with no invite and no login registered `idegen.probe@example.com` → **200** (`phase3/vaultwarden-stranger-signup.txt`). Once the dashboard is reachable through the tunnel, anyone who guesses `vault.<domain>` can open an account on the household's password server. A route does exist (the Vaultwarden admin panel's own setting, token under „Megjelenítés"), and no screen names it. **Fix shape:** default `SIGNUPS_ALLOWED=false` with an invite-first first step, or make that one field editable after install; the page must not instruct an act it forbids. | **READY — rank P2-MEDIUM; owner: CC (catalog + controller)** |
 
 <!-- DUE-CHECKS-BEGIN — machine-readable. Parsed by scripts/due_checks_gate.py.
      One row per dated check. The R-number must have a row above. Dates are UTC.