Deferred bug-hunt findings: harden CI workflows + tooling (pre-1.5) #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/deferred-ci-hardening"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-up to #1 — the deferred findings from the same Opus 4.8 bug hunt, cleared before cutting the
v7.0.10-hardened1.5validation build so that build exercises a complete pipeline. Allvalidate.ymlgates pass, plus targeted tests (tag-regex, redaction, release-id lookup, prune retention) and a run of the realintent-matches-policygate against the live configs.Workflows (
69e45c9)workflow_run(GitHub-only; confirmed against the Forgejo docs), so the post-publish repro gate silently never fired — only the nightly cron ran. Replaced withworkflow_dispatch(cron unchanged).GET /releases/tags/{tag}, which filters DRAFT releases on some Forgejo versions (ours are created as drafts) -> null id -> a valid rebuild fails. Resolve the id from the releases LIST instead (reliably includes drafts for a write-scoped token).REQUIRE_NET_ISOLATION=1(repo variable) hard-fails whenunshare -nis unavailable, instead of silently compiling without network isolation while the signing key is in tmpfs. Default behavior unchanged..0packaging tags (dpkg would sort them above the bare-hardenedN) and leading zeros;X.Y.Zstill allows the0in7.0.10.intent-matches-policyif intent.config parses to zero symbols. The originally-suspected substring false-pass was investigated and does NOT occur (commmatches whole symbols), so no change there.Tools (
cad9619)Authorizationheaders, so a token can't slip into a CI log via an echoed non-line-leading header.<unavailable>instead of a silent blank when a toolchain probe fails, so the gap is visible in the provenance SBOM.After merge: cut
v7.0.10-hardened1.5as the first end-to-end validation of the seed-era pipeline (watch the new hardening-drift step vs the pre-seed baseline; run repro-check viaworkflow_dispatchafter publish).🤖 Generated with Claude Code
- repro-check.yml (A3): drop the `workflow_run` trigger — Forgejo Actions does not support it (GitHub-only), so the post-publish repro gate silently never fired and only the nightly cron ran. Replace with `workflow_dispatch` so an operator can verify a fresh release on demand; the cron still covers everything within 24h. - build-kernel.yml (A4): on a same-tag rebuild the 409/422 fallback did `GET /releases/tags/{tag}`, which has filtered DRAFT releases on some Forgejo versions (ours are created as drafts) -> null id -> a valid rebuild fails. Resolve the id from the releases LIST instead, which reliably includes drafts for a write-scoped token. - build-kernel.yml (B4): add an opt-in `REQUIRE_NET_ISOLATION=1` repo variable that hard-fails when `unshare -n` is unavailable, instead of silently compiling without network isolation while the signing key is in tmpfs. Default behavior unchanged. - build-kernel.yml (B6): tighten the tag regex so hardenedN and the optional .P are [1-9][0-9]* — reject ".0" packaging tags (which dpkg would sort above the bare -hardenedN) and leading zeros. X.Y.Z keeps [0-9]+ so the "0" in 7.0.10 stays valid. - validate.yml (C11): guard intent-matches-policy against a vacuous pass when intent.config parses to zero symbols. (The token comparison is already exact — comm matches whole symbols — so the originally-suspected substring false-pass does not occur; verified.) - publish.yml: note the instance now runs Forgejo 15.0.2 (the release- trigger behavior was verified on 12.10.1). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>