hub v0.103.0 — a host can read the packages we kept for it (R-311)

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.
2026-08-12 18:56:44 +02:00
parent 6362bb6cb6
commit 8b188bea68
5 changed files with 511 additions and 69 deletions
@@ -0,0 +1,45 @@
+# 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**.