Files
felhom.eu/documentation/tests/golden-0.218.0-2026-08-22/README.md
T
admin 877fcd2a38
gates / gates (push) Successful in 16s
R-354 + R-355 CLOSED, proven live; golden 0.218.0 baked; R-367 filed
Both of the drill's HIGH findings are fixed in controller v0.218.0 and confirmed on demo-hp with
a negative control first — the same planted, hash-recorded fixture run through the same steps on
both builds.

R-355: paperless-ngx's PostgreSQL was dumped into a directory for a stack that does not exist, so
it never entered the recovery unit, the off-site copy or the restore; and because the same wrong
name reached writeSafetyDump, a destructive restore took no undo copy and the fail-closed refusal
was never reached. Fixed by reading the compose project label. Sweep proven able to convict
before its count was trusted: one affected app of 53.

R-354: the off-site restore had no named-volume leg. Now it replays them from the scratch unit,
before the database and inside the stopped window, and VolumesReplayed reaches the sentence.
The half-false comment beside the skip is corrected and the half that still holds is named.

Golden 0.218.0 baked and published, sha 8e427869d13eafb71562b77d1535eef6c7f32b4db24f659b988ec6d7db8f478b,
verified by round trip on the downloaded bytes. NOT vouched and the floor NOT raised — both are
the operator's decision, and raising the floor is what puts this on demo-felhom, which is still
on 0.217.0 and still has both defects.

R-367 filed: the dumps already written under the wrong name are stranded. Nothing deletes them
(an existing guard), they are adoptable by hand, and doing it automatically would be a migration.

Ceiling R-366 -> R-367.
2026-08-22 10:11:46 +02:00

45 lines
2.0 KiB
Markdown

# 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.