Files
felhom.eu/STATUS.md
T
admin 1d5f2b8bb6
gates / gates (push) Successful in 23s
DRILL: the retained key works, and the customer cannot reach it
Three verdicts, kept separate because collapsing them is how this assumption
survived a week.

(a) The material IS retained. host_escrow_superseded id 11 is the first retained
row in fleet history to carry identity_blob (572 B), byte-identical to the
pre-supersession row (sha256 a10032341c8584ed...).

(b) The retained material DOES open the old store. Unsealed with the old recovery
code it yielded a password byte-identical to the pre-change one, and restored
three planted files byte-identical from a store the box itself could no longer
open - including a Hungarian accented filename verified as raw bytes. Negative
control ran first and failed closed.

(c) The customer has NO route, and is misinformed. ListSupersededEscrow has zero
production callers; the recovery path selects FROM host_escrow. Asked with the
code that had just worked by hand, the product answered "the recovery code did
not open the sealed bundle". A valid code for retained history is reported as a
bad code - the R-224 class again. R-304, rank 1.

Both installer faults were watched happening first, so installer-v1.27.0 is now
published (tag + both webpage.yaml refs). Pre-fix: the box came up on controller
0.98.3 against a vouched 0.213.0, below the floor and below the version carrying
the recovery screen; and our own uninstall left dnsmasq on 0.0.0.0:53 so our own
next install refused. R-297 and R-300 CLOSED.

Also filed R-305 (the dnsmasq fix fires once per machine - the leftover returns
on the second reinstall, proven), R-306 (--preflight-only writes state it says it
does not), R-307 (a live abandon countdown on demo-felhom, firing 2026-08-24 -
operator decision), R-308 (stored controller password stale), R-309 (the day-0
runbook's publication claim has been false since R-110), R-310 (two edges).

Ceiling R-303 -> R-310. Capability map moved: the retention claim is now marked
operator-only. Phase A logs did not survive the intermediate revert; recorded.
2026-08-12 17:41:56 +02:00

4.6 KiB

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

Updated 2026-08-12 (late evening — retained-key drill).

A view, not a source. documentation/backlog/OPEN-ITEMS.md is the authority; this page restates part of it in plain words, and nothing may exist only here. Items, not paragraphs. One screen. If it does not fit, it belongs in the register instead.

Waiting on you

(The golden-vouch and floor-raise asks that stood here are done — the hub reads golden 0.213.0, floor 0.213.0, agent 0.128.0. Checked live, not assumed.)

  • R-307 — a countdown is already running on demo-felhom, started 10 Aug, firing 24 August, after which that set-aside off-site copy is deleted for good. Today's drill did not start it and deliberately did not cancel it. Cancel it (copy kept, costs storage) or let it run (copy deleted). Doing nothing chooses deletion.
  • R-304 — decide what we promise about old backups. The retention works, but only an operator can use it; the customer is told their correct code is wrong. Either build the door, or stop promising.
  • R-303 — one coherence decision, ranked low: a box can still raise the "we cannot open your new backups" card while counting down to deleting the old ones. The two no longer contradict each other, but the state is odd and the wrong fix would hide a real second fault.

What works

Both demo machines are home, healthy and reporting on the approved pair. Off-site is credentialed on demo-hp and its repository still opens with the machine's own key. drill-r50 is blocked, as intended.

Shipped

  • The drive can be re-attached after a reinstall (R-280). The restore page said "this is two clicks" over an empty list; it was zero clicks and needed an internal path no customer could produce.
  • The orphan card stops promising that set-aside off-site copies can be reopened — twice over (R-294, then R-299, which was the same claim in the plural, in the always-visible half, missed because the guard matched one inflection of a Hungarian verb).
  • The countdown banner stops promising retrieval it cannot see is still true (R-302). The promise is now conditional on the hub still holding the package it held when the customer decided — pinned then, compared now. A sweep found the same claim in five places; a fourth was fixed with it and a fifth deliberately left, because it is true where it renders.
  • One name per secret, box side (R-295): the dashboard code is „Beállító kód" everywhere; „Visszaállító kód" is retired. It collided with the escrow „Helyreállítási kód" and cost a real code.
  • Both installer fixes are now PUBLISHED as installer-v1.27.0 (R-297 + R-300). Each fault was watched happening first, on a machine reset to factory state: the old installer really did build a machine on a base image from July, and our own uninstall really did block our own next install.

Broken, or knowingly incomplete

  • The tester's machine has no recovery route at all — see the PETI row. Its host record was deleted on 15 July; there is no key, no off-site copy and no local backup. If that drive fails, everything on it is lost. First act of the visit: copy the ~3.6 GB off before anything is reinstalled — it is currently the only copy in existence. Whether it stays parked is your call and is deliberately left open.
  • Kept backups can be opened — but not by the customer (R-304). We now know for certain the old key is kept and does open the old backups: three planted files came back byte-for-byte from a store the machine itself could no longer read. But nothing in the product reads a kept key, so it takes an operator with a shell. Worse, a customer who types their correct old code is told it "did not open the sealed bundle". The keeping is real; the promise that they can use it is not.
  • The dnsmasq fix helps a machine once (R-305). On a machine that never had Felhom it works. On the second reinstall the leftover comes back, because the package is never removed — so the machine looks, to our own installer, as if the household had installed it. Watched happening the same afternoon.
  • The hub half of the naming is undone (R-295 PARTIAL): the emails still use the retired name and send people to a page a rebuilt machine does not show.
  • The storage page has its own separate reason for showing an empty list (R-298), untouched.

Working on next

Your two decisions above (R-307's deadline is the hard one); then R-304's shape; then the hub naming; then the 2026-08-09 batch (R-279 … R-292), still untriaged against everything since.