admin
4f875174fe
gates / gates (push) Successful in 17s
golden_currency_gate.py had been CONVICTED four times today across three controller releases. One bake covers all three, and the gate went red -> green on the same command, which is its proof that it measures something real. THE THREE DECLARED BYPASSES ARE NOW HISTORICAL RATHER THAN STANDING. GOLDEN_VERSION 0.226.1 GOLDEN_SHA256 70ed8e9377dec22a9b493e55f222b0e25a49d7f3caec8c506e0412fd6baefe69 size 657 197 592 B baked gitea.dooplex.hu/admin/felhom-controller:0.226.1 MinAgent 0.129.0 (read from the controller CHANGELOG header, not assumed) THE EVIDENCE IS THE ROUND TRIP, NOT THE BUILD LOG. The published bytes were downloaded back -- size and sha256 both identical to what the bake reported -- and ./etc/felhom-controller-image was read OUT of the downloaded archive: `felhom-controller:0.226.1`. That is the delivered artifact naming the controller it will start, from the bytes a customer's box would actually fetch. Acceptance markers counted, not eyeballed, each string captured from this run's own log rather than paraphrased from the runbook (two of the three the runbook named until R-233 could not match anything the script prints): docker OK (overlay2 = 1, including mount point rootfs = 1, mp0 = 1, upload OK (HTTP 201) = 1; excluding = 0, FATAL = 0, mp1 = 0. The 404 pre-gate passed before the run, so nothing was overwritten. THE VOUCH IS A THREE-FIELD CHANGE AND ALL THREE WERE CHECKED: agent_version 0.130.0 >= min_agent 0.129.0, so NOT the R-216 shape; wrapper_sha256 carried through explicitly because the handler clears it when omitted. Verified by RE-READING the manifest rather than trusting the flash -- golden option 0.226.1 SELECTED, all four shas matching. THE FLOOR IS PROVEN ACTING, NOT MERELY SET. demo-felhom self-updated within 30 seconds: "[selfupdate] Post-update startup: update successful (0.225.0 -> 0.226.1)". Both demo machines now run 0.226.1 and only one of them was deployed to by hand. Token hygiene: copied file->file, read inside the VM by a runner script, never on a command line (systemctl show ... | grep -c -F token = 0). THE LEAK GREP ON THE COMMITTED LOG WAS PROVEN TO WORK BEFORE ITS 0 WAS BELIEVED -- a throwaway copy with the token appended grepped 1, was shredded, and only then was the real log's 0 taken as evidence. Teardown: build guest 9100 destroyed --purge, secrets shredded AFTER the log was copied out (standing rule 5), VM powered off, disk reverted to virgin. R-242's OTHER half is untouched and still open: nothing gates the VOUCH itself.
82 lines
3.4 KiB
Markdown
82 lines
3.4 KiB
Markdown
# Golden bake 0.226.1 — 2026-08-30
|
|
|
|
Baked to close `golden_currency_gate.py`, which had been CONVICTED across **three** controller
|
|
releases (0.224.0 R-330, 0.225.0 R-331, 0.226.0/0.226.1 R-353/357/358/360). One bake covers all three.
|
|
|
|
## What was produced
|
|
|
|
| | |
|
|
|---|---|
|
|
| `GOLDEN_VERSION` | **0.226.1** |
|
|
| `GOLDEN_SHA256` | `70ed8e9377dec22a9b493e55f222b0e25a49d7f3caec8c506e0412fd6baefe69` |
|
|
| size | **657 197 592 B** |
|
|
| package URL | `https://gitea.dooplex.hu/api/packages/admin/generic/felhom-golden/0.226.1/golden.tar.zst` |
|
|
| baked controller | `gitea.dooplex.hu/admin/felhom-controller:0.226.1` |
|
|
| `MinAgent` | **0.129.0** (read from the controller `CHANGELOG.md` header, not assumed) |
|
|
| script | `build-golden.sh v3.0.0` |
|
|
| venue | the drill VM on DooPlex, reverted to `virgin` and **cold-booted** first |
|
|
| template | `debian-13-standard_13.6-1_amd64.tar.zst` — after `pveam update`, because the virgin snapshot's INDEX is stale too and the failure reads as a bogus `400 no such template` |
|
|
|
|
## Acceptance markers — counted, not eyeballed
|
|
|
|
Each string was captured from this run's own log rather than paraphrased from the runbook (two of the
|
|
three markers the runbook named until 2026-08-06 could not match anything the script prints — R-233):
|
|
|
|
```
|
|
docker OK (overlay2 : 1 ← " docker OK (overlay2; data-root /var/lib/docker)"
|
|
including mount point rootfs : 1
|
|
including mount point mp0 : 1
|
|
upload OK (HTTP 201) : 1
|
|
--- must be ZERO ---
|
|
excluding : 0
|
|
FATAL : 0
|
|
mount point mp1 : 0 ← mp1 stopped existing in build-golden.sh v3.0.0 (R-165)
|
|
```
|
|
|
|
**404 pre-gate before the run:** `HTTP 404` on the package URL, so nothing was overwritten.
|
|
**The script's own pre-delete** then reported `HTTP 404 (404/204 expected)`.
|
|
|
|
## The evidence is the ROUND TRIP, not the build log
|
|
|
|
The published bytes were downloaded back and compared to what the bake reported:
|
|
|
|
```
|
|
downloaded size : 657197592 bake reported : 657197592
|
|
downloaded sha : 70ed8e93…baefe69 bake reported : 70ed8e93…baefe69
|
|
```
|
|
|
|
**And the delivered artifact was asked what it will start** — `./etc/felhom-controller-image` read
|
|
*out of the downloaded archive*:
|
|
|
|
```
|
|
gitea.dooplex.hu/admin/felhom-controller:0.226.1
|
|
```
|
|
|
|
That is the golden naming the controller it will run, read from the bytes a customer's box would
|
|
actually fetch — not from the build host, and not from the local file.
|
|
|
|
## Token hygiene
|
|
|
|
The Gitea token was copied **file → file** (`scp`), never crossing a shell on either side, and the
|
|
bake ran through a runner script inside the VM that reads it itself — so it never reached a command
|
|
line or a transient unit's properties:
|
|
|
|
```
|
|
systemctl show golden-bake -p Environment -p ExecStart | grep -c -F "$(cat /root/.gitea-token)" → 0
|
|
```
|
|
|
|
**The leak grep on the committed log was PROVEN TO WORK before its `0` was believed.** A throwaway
|
|
copy had the token appended, was grepped (**1**), and was `shred -u`'d; only then was the real log's
|
|
**0** taken as evidence. A `0` from an untested grep is not a measurement.
|
|
|
|
```
|
|
POSITIVE CONTROL (token appended) : 1
|
|
THE COMMITTED bake.log : 0
|
|
```
|
|
|
|
## Teardown
|
|
|
|
Build guest `9100` destroyed `--purge`; token, runner and log `shred -u`'d **after** this log was
|
|
copied out (standing rule 5: evidence leaves at the end of the phase that produced it, not at the end
|
|
of the session); VM powered off and the disk reverted to `virgin`.
|