Golden bake — 0.218.0 (2026-08-22)
Baked in the drill VM on DooPlex per documentation/runbooks/RUNBOOK-manual-build.md §4.0/§4.1,
carrying controller v0.218.0 (R-354 + R-355).
GOLDEN_VERSION |
0.218.0 |
GOLDEN_SHA256 |
8e427869d13eafb71562b77d1535eef6c7f32b4db24f659b988ec6d7db8f478b |
| package | https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.218.0/golden.tar.zst |
| size | 657 026 013 B (archive 626 MB) |
| controller image | gitea.dooplex.hu/admin/felhom-controller:0.218.0 |
| template | debian-13-standard_13.6-1_amd64.tar.zst (listed fresh, not assumed) |
MinAgent |
0.129.0 (from the controller CHANGELOG header — unchanged) |
Pass markers — each checked, with the negative controls
docker OK (overlay2 : 1 -> " docker OK (overlay2; data-root /var/lib/docker)"
including mount point : 2 -> rootfs ('/') and mp0 ('/var/lib/felhom') [there is no mp1]
upload OK (HTTP 201) : 1 -> pre-delete returned HTTP 404 (404/204 expected)
excluding : 0 <- negative control
FATAL : 0 <- negative control
Token hygiene
The Gitea token was copied file → file (scp) and read by a runner script inside the VM, so it
never crossed a shell or a unit property. Verified: systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)" → 0.
The leak grep on this committed log was itself proven before its zero was believed: the token was appended to a throwaway copy, grepped (1), the copy shredded, and only then was the committed log's 0 accepted.
Teardown
pct destroy 9100 --purge; token, runner, build script and in-VM log shred -u'd after this log
was copied out; VM powered off; qemu exited; qemu-img snapshot -a virgin restored.
NOT vouched
The hub's Day-0 artifact manifest was not changed and the floor was not raised — both are the
operator's decision. See REPORT.md §12.