DRILL: the retained key works, and the customer cannot reach it
gates / gates (push) Successful in 23s

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.
This commit is contained in:
2026-08-12 17:41:56 +02:00
parent fbe1155fbb
commit 1d5f2b8bb6
12 changed files with 2445 additions and 90 deletions
+25
View File
@@ -1,3 +1,28 @@
## PUBLISHED — `installer-v1.27.0` (2026-08-12)
**v1.26.0 (R-297) and v1.27.0 (R-300) were both written, pushed and deliberately left unpublished
until their faults had been watched happening. Both were watched on `drill-r50` on 2026-08-12
(`documentation/audits/DRILL-retained-key-2026-08-12.md`), so the tag is now cut and both `--ref`s in
`manifests/webpage.yaml` moved to it** — the sidecar and the init container. No `installer-v1.26.0`
tag exists or is needed: 1.27.0's tree carries both fixes.
**What was observed before publishing, from a `virgin` machine each time:**
- R-300 — pre-fix uninstall left dnsmasq `enabled`/`active` on `0.0.0.0:53`; the next byo install
refused, exit 1. Fixed path: recorded `not present before Felhom``stopping + disabling it`
`:53 FREE` → preflight PASS. The owner's side was proven too (record `yes` → left running).
- R-297 — a stale `golden-0.98.3.tar.zst` planted as the newest-by-filename archive; v1.25.0 took it
with no comparison and **the box came up on controller 0.98.3** against a vouched 0.213.0 — below
the update floor and below v0.206.0 where the off-site recovery screen exists. Fixed path: the
auto-discovered archive was rejected and the vouched one re-fetched and sha-verified (landed
0.213.0); an operator-named stale archive was **refused**, exit 1.
**Known limit of the R-300 fix, filed as R-305:** it fires only on a machine that never had Felhom.
The package is never purged, so every later install records `dnsmasq_preexisting=yes` and the
leftover returns on the second reinstall — proven on cycle 2/3 the same day.
---
## felhom-host-install.sh v1.27.0 — our removal no longer blocks our reinstall (2026-08-12, R-300)
**Felhom's own uninstall left the thing that makes Felhom's own next install refuse.** `--uninstall`