pipeline 4.5.1
`ci-go` now builds on go1.26.6, closing the five stdlib advisories below.
Consumers pin `ci-go` at a fixed catalog tag rather than `:latest`, so this
tag is what actually delivers the fix — each consumer still has to bump its
pinned ref and re-run `audit` before govulncheck goes quiet. A **patch**: no
template input added, removed, or renamed.
- **`ci-go`: Go toolchain digest bumped past go1.26.5 to close five stdlib
CVEs.** `containers/ci-go.Containerfile`'s `mirror.gcr.io/library/golang:1.26`
digest pin landed on go1.26.6-equivalent content via the routine digest-track
lane (renovate!213, merged 2026-08-15; folded into !219). Fixes, as reported
by `go-audit`'s govulncheck against consumers on the affected toolchain:
- **GO-2026-5972** / CVE-2026-33818 — `encoding/asn1` `Unmarshal` lacked a
recursion limit, allowing stack exhaustion on deeply-nested input.
- **GO-2026-5026** / CVE-2026-39821 — `net/http` (via `golang.org/x/net/idna`)
accepted ASCII-only Punycode labels it should have rejected, a hostname
validation bypass.
- **GO-2026-6218** (`net/url` quadratic complexity), **GO-2026-6090**
(`crypto/tls` post-handshake message limit), **GO-2026-6088**
(`encoding/xml` recursion depth) — same go1.26.6 fix, caught in the same
scan.
The fix reached `origin/main` before this entry did: the `ci-go`
Containerfile is pinned by digest, tracks the upstream `golang:1.26` tag,
and Renovate's digest-update lane (`matchUpdateTypes: [digest, pinDigest]`,
`minimumReleaseAge: null`) auto-merges those on green CI regardless of
cause — it is not the `vulnerabilityAlerts`-specific security lane, which
targets manifest-declared package advisories, not a Containerfile `FROM`
digest. The gap was cadence, not policy: the fixed image published upstream
2026-08-13T20:27Z; the estate's next scheduled Renovate scan didn't run
against it until 2026-08-15T03:00Z, roughly a day and a half later.
This CHANGELOG entry is the only thing this fix needed that automerge
couldn't supply. **Not yet propagated**: consumers pin `ci-go` at a fixed
catalog tag (`bairn@4.4.1`, `tutti@2.1.2`, `qobuz@2.4.0`, all pre-dating
this fix) — none will see it until a new catalog tag ships and each
consumer bumps its pinned ref. The `go-audit` job is `allow_failure: true`,
so none of this blocked anything; it has been failing silently since well
before this CVE pair (bairn's `audit` job has red history back to at least
2026-05-18).