felhom.eu/documentation/audits/night-burndown-2026-10-06/design-R-32.md

R-32 — RESET leaves the household's off-site ciphertext behind — design proposal (burn-down night 2026-10-06, no code)

Baselines read: felhom.eu 8e2dc204 (hub v0.140.0), felhom-controller 5e7522e023 (v0.301.0). Architecture: 07-backup-architecture.md §246 (off-site deletion custody, decisions 68–69); 06-offsite-connectivity.md; the row's own three-part ruling from the 2026-07-21 rehearsal.

1. The problem

RESET is meant to destroy a household's off-site copy. On the shared pool box it deletes the Hetzner SUB-ACCOUNT. A sub-account is a login, not the data: its home directory stays. Re-enabling off-site for the same customer creates a sub-account with the SAME home (felhom-<customer id>) over the old ciphertext, whose key that RESET destroyed. Measured on the pool box the night of 2026-07-21: 49 MB attributed (2 snapshots, 48.7 MiB) against 1.4 GB + 3.0 MB unattributed in two .orphaned-* folders (restic-and-pool.txt, R-32). The orphan card then appeared — the rehearsal's S7 had said in advance that it would be a finding.

2. What the code does today (read in source)

• RESET's off-site leg calls s.offsite.Deprovision (hub/internal/web/customer_reset.go:217-225) and journals hetzner: ok, logging "repo data destroyed" (:225).
• Deprovision, shared tier: DeleteSubaccount per labelled sub-account, nothing else (hub/internal/offsite/offsite.go:303-326). Its doc comment says "The offsite repo DATA dies with the sub-account/box" (:276-280) — true for the dedicated tier (the box is deleted, :283-300), false for the shared one. A comment that asserts an invariant the code does not provide.
• The home directory is fixed per customer: HomeDirectory: "felhom-" + customerID (offsite.go:349). So a new lifecycle lands on the old folder.
• The hub already deletes off-site data in ONE place, through the sub-account's own password login (port 23): Registrar.DeleteSetAside (hub/internal/offsitekeys/offsitekeys.go:424-445) — rm -rf of a <repo>.orphaned-… folder only, refusing anything else (IsSetAsidePath, :448-459), after the household's 7-day abandonment delay (decision 74, service.go „Decision 74").
• The move-aside for a reinstall WITHOUT RESET: the box asks the hub to rename the old repo to <repo>.orphaned-<date> (felhom-controller/controller/internal/backup/offbox.go:329-345). The ruling keeps this — custody survives there.
• The operator's Restic tab shows the pool box's totals from the provider API and, per customer, the usage the BOX reports (hub/internal/web/offsite_box.go:121-185). Bytes that no box reports (an .orphaned-* folder, an old lifecycle) are visible only in the pool total, not per customer.

3. Options

A. Purge through the sub-account, then delete it. In Deprovision (shared), before DeleteSubaccount: log in with the hub's stored password for that sub-account (it already does this for authorized_keys and DeleteSetAside), remove the live repo and every <repo>.orphaned-*, check the home holds no repository left, then delete the sub-account. A purge that fails stops the leg (hetzner: failed, re-run resumes) — the sub-account is NOT deleted, because after that only the main account can reach the folder.

• Costs: hub only, small; one new registrar method (PurgeRepos) beside DeleteSetAside, same refusals style.
• No new credential: the main-account password the ruling named is not needed.
• Can go wrong: the stored password no longer works (rotated, or the hub DB restored from an older copy) → the leg fails loudly and the operator must decide (main-account clean-up by hand). Deletes household data — that is RESET's purpose, and the existing RESET ack covers it per the ruling; still the operator's word on the route.

B. Purge with the pool box's MAIN account (the ruling's words). The hub gets the main-account SFTP password.

• Costs: a new credential that reaches every household's folder on the pool box. A hub compromise then deletes every household's history in one step. Bigger blast radius than A for the same result.
• Only advantage: also reaches folders of sub-accounts deleted BEFORE this fix (old lifecycles).

C. A new home folder per lifecycle (felhom-<id>-<n>), no purge. The new sub-account never sees old ciphertext, so the orphan card cannot lie.

• Costs: small. But nothing is ever deleted: the ruling's part (1) is not met, and dead ciphertext fills the pool box for ever, unseen unless part (3) is built.

Part (3), the byte view, for every option: per customer, the bytes in its folder (all repos, set-aside copies included) beside the bytes its box attributes. Needs a per-folder size from the provider. Not measured: whether the password login on port 23 answers du -s (the shell has rm, mv, dd — memory storagebox-subaccount-shell…). So not buildable tonight: it rests on a mechanism nobody has measured, and tonight's fence forbids touching the Storage Box.

4. The pick — PROPOSAL for the operator, not a decision

A, with part (3) after one read-only measurement. It meets the ruling's part (1) with no new credential, keeps the move-aside guard for reinstall-without-RESET (part 2 — untouched), and makes the journal's "repo data destroyed" true. Old lifecycles' folders (if any are left on the pool box) are a one-time clean-up by hand — the operator's (question 2).

5. First slice and its proof

• Build (hub): offsitekeys.Registrar.PurgeRepos(ctx, t, pw) — removes t.RepoPath and every IsSetAsidePath match, nothing else; then lists and refuses success if any remains. offsite.Provisioner.Deprovision (shared) calls it through a seam BEFORE DeleteSubaccount. Fix the doc comment at offsite.go:276-280.
• Red test first (must FAIL today): a fake provider API and a fake shell; RESET's Deprovision for a shared customer. Assert the shell saw rm -rf <repo> before the API saw DeleteSubaccount. Today it fails: no shell call at all.
• Second red test: the purge fails → Deprovision returns an error and DeleteSubaccount was NOT called (else the folder becomes unreachable).
• Keep green: DeleteSetAside's refusals; the dedicated tier unchanged; RESET's journal re-run.
• Live proof on a SCRATCH customer only (never a household): enable off-site, one run from scratch box 9202, RESET, re-enable. Positive observable: the new sub-account's home lists no restic/.orphaned-* folder, and no orphan card appears. Control from a different channel: the provider's pool-box stats size before and after (coarse, API). Evidence off the machine before teardown.

6. Open questions for the operator

1. RESET deletes the household's off-site folder through the sub-account's own login before removing it (option A), instead of through the pool box's main account — agree? If you do nothing: RESET keeps leaving the ciphertext; a re-enabled customer sees an orphan card again.
2. Folders left by RESETs done before this fix (the 2026-07-21 measurement found 1.4 GB): clean them up once by hand with the main account, or leave them? If you do nothing: they stay and use pool-box space; nothing reads them.