Repository navigation
build: rebuild on Go 1.26.10 and x/net v0.60.0 (CVE-2026-78667, -78669, -97031) - #160
Conversation
…9, -97031) The 3.8.2 binaries were built by a floating `go-version: '1.26'`, which resolved to 1.26.8 and shipped three HIGH denial-of-service advisories in the standard library -- CVE-2026-78667 (net/http, crafted Range headers), CVE-2026-78669 (net/http2, excessive HTTP/2 SETTINGS frames) and CVE-2026-97031 (crypto/tls, multiple ECH outer extension references) -- plus CVE-2026-78669 a second time in x/net v0.58.0's own HTTP/2. cbox-init serves HTTP on the metrics, readiness and management ports, so none of these were dead code, and the downstream image scan refused to promote any tag. No behaviour change. The toolchain is pinned to 1.26.10 and x/net to v0.60.0 (which carries x/sys v0.48.0 and x/text v0.42.0 with it), and every `go-version` in CI and in the release workflow is pinned to the same patch, so a release is built by the toolchain that was scanned rather than whatever the runner resolves that day. Verified: `trivy rootfs --severity CRITICAL,HIGH --ignore-unfixed` on the linux/amd64 binary reports 0 findings, against 4 on the same source built with 1.26.8 and x/net v0.58.0; `go version -m` on the binary records go1.26.10 and golang.org/x/net v0.60.0.
`make sbom-check` failed in CI on a document that passed locally. sbomnorm normalises the root component's version to 0.0.0 in the `version` field unconditionally, but rewrote the version inside the root purl and bom-ref by replacing the literal `name@oldVersion` -- and returned early when oldVersion was empty. cyclonedx-gomod cannot resolve a version for the main module in every checkout: inside a git worktree it warns "failed to determine version of main module" and emits a version-less purl. Regenerating there therefore wrote `pkg:golang/github.com/cboxdk/init?type=module` where a normal checkout writes `...@0.0.0`, and the result passed `sbom-check` locally (both sides of its diff were generated the same way) while failing it in CI. The purl and bom-ref are now pinned to 0.0.0 whether or not a version was resolved, matching the `version` field that was already being set. A shallow clone and a git worktree now produce byte-identical SBOMs. sbom.json is regenerated: the only change against 3.8.2's committed document is the three dependency bumps from the previous commit, with the root module's identity back to what it has always been. Tests cover both paths, the already-normalised input, and that neither a dependency nor a longer module path sharing the root's prefix is rewritten.
e91c6bd to
d342ebf
Compare
|
Pushed The
So the generator version did not move; The fix pins the purl and bom-ref to Worth knowing independently of this PR: Also moved Full local gate green on the committed tree: fmt, vet, lint (0 issues), tests with race, coverage 82.0% vs the 78.0% floor, govulncheck clean, |
Same code as 3.8.2, rebuilt on a patched toolchain. No behaviour change.
The v3.8.2 binaries were built by a floating
go-version: '1.26', which resolved to 1.26.8 and shipped four HIGH denial-of-service findings thatphp-baseimages' pre-promotion Trivy gate rejects — so no php-base / php-fpm / php-cli / php-fpm-nginx tag has been published since 2026-10-08.net/http(craftedRangeheaders)net/http2(excessive HTTP/2 SETTINGS frames)crypto/tls(multiple ECH outer extension references)golang.org/x/netHTTP/2cbox-init serves HTTP on the metrics (
:9090), readiness (:9091, bound0.0.0.0) and management API ports, so none of these were dead code.Changes
go.mod:toolchain go1.26.6→go1.26.10(stays on the 1.26 line). The language directivego 1.26.0is untouched. The existing comment about the supply-chain gate is kept and updated to name the current pin.go.mod:golang.org/x/netv0.58.0 → v0.60.0, still indirect. It carriesx/sysv0.47.0 → v0.48.0 andx/textv0.41.0 → v0.42.0 with it; nothing pullsx/netback down.sbom.jsonregenerated — the three version bumps above and nothing else.go-versioninci.yml(matrix, supply-chain, lint, config-examples, build) and inrelease.ymlis pinned to1.26.10. The floating'1.26'inrelease.ymlis how v3.8.2 ended up on 1.26.8; a release toolchain is now deterministic and auditable.Verification
The artifact actually moved —
go version -mon the linux/amd64 binary:```
cbox-init: go1.26.10
dep golang.org/x/net v0.60.0
dep golang.org/x/sys v0.48.0
dep golang.org/x/text v0.42.0
```
Scanned the way the downstream gate scans,
trivy rootfs --severity CRITICAL,HIGH --ignore-unfixed:The before/after rules out a scan that simply does not know these CVEs.
Local
make checkequivalent, all green:fmt-check,vet,lint(0 issues),test(24 packages, race + coverage),cover-check(81.8% vs 78.0% floor),govulncheck(no vulnerabilities),sbom-check,license-check(68 deps, all permissive),check-configs(16/16),go test -race -short ./..., andgo mod tidyis a no-op on the committed tree.Follow-up, not in this PR
Dockerfile:2is stillFROM golang:1.27-alpine— floating, the same hole that caused this, and on a different Go line thango.mod. It resolves to a patched 1.27.3 today so it is not a finding, and it builds the ghcr image rather than the three release artifactsphp-baseimagesconsumes. Worth pinning deliberately, but not inside a security patch release.