Files
felhom.eu/STATUS.md
T
admin 9268d9933b
gates / gates (push) Successful in 29s
R-436 measured on the provider: append-only forced key HOLDS (403 on every delete), but the sub-account password defeats it (R-820); design proposal + ep0 options
Spike, no product change. Venue u629488-sub4 (tester-1, operator ruling); scratch repo removed,
authorized_keys restored byte-identical. Closed R-436 (due-check cleared), R-430. Opened R-820,
R-821, R-822. R-95 and R-342 updated. 07 §D [FACT] block. STATUS: two operator decisions.
Register 326 -> 327.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-10-03 13:40:35 +02:00

6.5 KiB
Raw Blame History

STATUS — what works, what's broken, what's next

Ready for the first real tester (Tester-2): yes. You confirmed the tunnel route and the connect mails (2026-09-30).

Updated 2026-10-03 (off-site backup safety, step 1: measured on Hetzner). Versions unchanged since 2026-10-02 (afternoon). Both demo boxes run controller 0.288.0 and host agent 0.138.0. Hub 0.126.0. New installs get golden 0.288.0 with agent 0.138.0.

Today (2026-10-03, later): off-site backup safety, step 1 — measured, nothing built

  • The "add only" lock works. I tested it on tester-1's storage account (your choice; no box uses it now). New backups go in. Restore works. Every delete is refused. I put the account back exactly as it was.
  • But the lock alone does not protect us yet. A broken-into box can ask the hub for the storage password. With that password it can log in and remove the lock. First the box must stop getting the password.
  • A second trap: with "add only", an attacker can add fake backups dated in the future. The normal clean-up rule then deletes all the real backups. Any clean-up must check for this.
  • The hub keeps every storage password in plain form. Anyone who reads the hub database can delete every household's off-site backups. New row.
  • ep0: Hetzner cannot snapshot the extra disk at all. One of the three old ideas does not exist.
  • Rows: 2 closed, 3 opened. The list went from 326 to 327 rows. The dated check for 6 October is done.

Today (2026-10-03): the to-do list is in order — paperwork only, no machine touched

  • Finished items left the open list. It went from 442 rows to 326. Nothing was deleted; each moved row names where its full text is.
  • Every open row now has one category and one severity (P1 now · P2 before the first paying customer · P3 during the first customers · P4 later). No row is P1. 27 rows are P2.
  • Two new automatic checks refuse a finished row left in the open list, and a new row without a category or a severity.
  • Your four new items are on the roadmap: security updates for the box's own system; legal pages and business papers; "what if the household leaves Felhom"; a second login step for the dashboard. Two of them are also real findings today: a box never receives system security updates, and the website has no privacy notice, terms or imprint.
  • The ranked list and my reasoning: the triage recommendation in the audits folder.

Tester-2 — read only, from the hub. The customer record exists. Tester-2's box has not registered yet.

Today (afternoon): every app checked again

  • No data-loss fault. I checked all 58 apps with the fixed check. It made each app really save something, then looked where the data landed. No app saves data where the backup does not copy it.
  • 40 apps: proven correct. 18 apps: not proven either way. In those 18 the check could not fill every folder (for example an upload folder stays empty because my test saves no upload). Nothing was found outside a backed-up folder. I list them and work on them later.
  • papra was broken for new installs, now fixed. It needs more memory than its limit, so a fresh install crashed in a loop. I measured it and raised the limit. No box runs papra.
  • plant-it's program image is gone from Docker Hub. It is already hidden from new installs. No box runs it.

Removing an app now tells the truth (your choice A)

  • When the household removes an app, its own files (books, videos) stay. The dialog and the result now say so, and name the folder. Proven on the scratch box: the video was still there after the remove.

Before the first paying customer

Everything here must be done before the first customer who pays:

  1. SparkyFitness: written permission from the author (the e-mail draft is ready). If none → hidden from new installs.
  2. Tandoor: written permission from the authors. If none → hidden from new installs.
  3. A lawyer reviews the licence list (Tandoor, SparkyFitness, Emby, n8n, Plex, the paid "enterprise" parts, Redis).
  4. Agent updates: I may sign agent updates only until the first paying customer; after that you sign them.

Your licence decisions are recorded: Emby, Plex and n8n stay. recipe-importer needs nothing unless we share it.

Also today

  • New version 0.288.0 and a new golden (0.288.0).
  • Rows. 7 closed, 6 opened. The list went from 436 to 442 rows.

What needs you

  1. Who may delete old off-site backups, once boxes can only add? (Details: the design in the 2026-10-03 off-site audit folder.)
    • A — the box, in a short weekly window the hub opens (recommended). The backup password stays only on the box, as we promise today. Cost: during the window a broken-into box could delete; the hub checks the count before and after.
    • B — a Felhom machine does it for every box. Cost: that machine must hold every household's backup password, so it could read every household's backups. That changes a promise to the customer, and adds a new always-on machine.
    • If you say nothing: nothing is built. Boxes keep the key that can delete (today's risk stays).
    • Either way, first: the hub installs the box's key, so the box never gets the storage password. 0b. ep0's backup disk has no copy of its own. Which safeguard?
    • A — DooPlex copies it every night (recommended). €0 a month, about 1–2 hours to set up. Protects against losing the disk and losing Hetzner. The copy is encrypted per household, so DooPlex cannot read it. Cost: a new job on DooPlex.
    • B — accept the risk in writing, and copy the disk off by hand before any risky work on ep0.
    • If you say nothing: the disk stays unprotected; a bad day on ep0 loses every household's whole-box off-site copy.
  2. plant-it: keep the hidden template as it is, or remove it entirely (its image no longer exists). If you say nothing: it stays hidden; nothing runs it.
  3. Send the SparkyFitness request, and ask the Tandoor authors (the "Before the first paying customer" list).
  4. Phone test (2 minutes), only if you want it: say so, and I put MeTube back on demo-hp with a family login.

Standing steps

  • Monthly security re-test: last run 2026-10-01, next due ~2026-11-01. (You start it with the standing brief.)
  • Weekly: the golden bake (next around 9 October; today's bake was 0.288.0).
  • Registry clean-up: only when the registry disk fills; "show me" mode first, then a person decides.