admin
8b188bea68
ListSupersededEscrow had zero production callers for nineteen days. It is the only reader of a retained identity_blob, so the retention shipped in v0.93.0 was material the product could not reach - proven on the fixture 2026-08-12, where a code that opens a retained package was answered as a code that opened nothing. New GET /api/v1/hosts/<id>/escrow/retained: self-scoped exactly as the current-row GET, same recovery-mode gate, same audit event written BEFORE the bytes leave, capped at 16. Rows with a NULL identity_blob are WITHHELD and returned as unopenable_count - they retain the PBS key, not the repository password, so they can never open what the caller is asking about, and serving them would let the screen claim an earlier package is openable on exactly the boxes the original defect hurt. The count is returned because their existence is load-bearing and underivable by the caller. The trade, stated rather than waved through: the hub still cannot read any of it - sealed bytes in, sealed bytes out, no decrypt path, no recovery code ever held. What widens is volume, bounded by self-scope, the recovery-mode gate and the cap. The response is a NAMED TYPE, not a map, so the wire-contract gate can resolve it; the wire is declared as a fourth ROOT and the gate now checks 182 tags rather than 174. A positive control shows that check is name-presence, not decodability - filed as R-315 rather than reported as coverage. Also: golden 0.214.0 baked, published and round-trip verified; the countdown on demo-felhom cancelled on the operator's ruling (R-307); the spike that halted Part 3 recorded as R-312; the set-aside store found unrecoverable as R-313. Six hub tests through the real endpoint; four red-proofs asserted applied.
1.9 KiB
Golden bake 0.214.0 — 2026-08-12
Per RUNBOOK-manual-build.md §4.0/§4.1. Drill VM reverted to virgin before and after; guest 9100
destroyed --purge; /root residue shredded.
GOLDEN_VERSION |
0.214.0 |
GOLDEN_SHA256 |
3a40379cb00d98c6f9550815b2b024783f153e9eef9be2b3252253d24d8d2c4d |
| controller baked | gitea.dooplex.hu/admin/felhom-controller:0.214.0 |
MinAgent (CHANGELOG header) |
0.129.0 |
| published | 656 392 524 B, upload OK (HTTP 201) |
Acceptance markers (grep -F, quoted loop variable)
docker OK (overlay2 1 · including mount point rootfs 1 · including mount point mp0 1 ·
upload OK (HTTP 201) 1 · FATAL 0 · excluding 0
Fetchability — the SERVED bytes
downloaded: 656392524 bytes
sha256: 3a40379cb00d98c6f9550815b2b024783f153e9eef9be2b3252253d24d8d2c4d
Identical to GOLDEN_SHA256.
The template index was STALE, and it would have baked the wrong base
pveam available on the freshly reverted virgin listed only debian-13-standard_13.1-2 — the point
release our own memory records as 404-ing since 2026-07-15. pveam update first, and the real
current one is debian-13-standard_13.6-1_amd64.tar.zst. The runbook says the point release rots; what
it does not say is that the VM's cached index rots too, and reading it without refreshing produces a
confident answer that is a fortnight out of date.
Secret handling
Token file→file, read inside the VM by a runner script, never on a command line.
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F <token> = 0. Leak grep on the
committed log = 0, believable because a planted-token control on a copy grepped 1. All in-VM
artefacts shred -u'd.
NOT DONE
The Day-0 vouch — the operator's, and deliberately so. Three fields, each already verified downloadable and selectable: golden 0.214.0, agent 0.129.0, min agent 0.129.0.