Skip to content

Bump golang.org/x/net to v0.55.0 and align Go directive to 1.26 (OCP 4.19 CVE cleanup) - #69

Merged
baijum merged 5 commits into
release-3.20from
bump-xnet-0.55.0-release-3.20
Jul 29, 2026
Merged

Bump golang.org/x/net to v0.55.0 and align Go directive to 1.26 (OCP 4.19 CVE cleanup)#69
baijum merged 5 commits into
release-3.20from
bump-xnet-0.55.0-release-3.20

Conversation

@baijum

@baijum baijum commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator

Summary

Fixes CVE-2026-27136 and CVE-2026-39821 for OCP Tools 4.19 by bumping golang.org/x/net from v0.48.0 to v0.55.0. Also aligns the go.mod go directive to the 1.26 line, matching the identical treatment applied to the release-3.15/release-3.17/release-3.19 branches for the other OCP Tools streams.

  • golang.org/x/net/html XSS via HTML parsing bypass (CVE-2026-27136)
  • golang.org/x/net/idna privilege escalation via incorrect Punycode label processing (CVE-2026-39821)

As an unavoidable side effect of Go's minimum-version-selection, bumping x/net to v0.55.0 also raised several other golang.org/x/* modules to newer minimums declared by x/net's own go.mod (crypto, mod, sync, sys, term, text, tools). All are official Go modules; this is expected fallout, not an unrelated change.

Once this ships, and a RelEng buildroot tag-add lands (see linked ticket), it also clears the way to close CVE-2026-33811, CVE-2026-39820, and CVE-2026-42504 for this stream via the Go 1.26.4 toolchain.

Tracking: HELM-821

Test plan

  • go build ./... succeeds
  • Makefile's build target (CGO_ENABLED=0, -tags no_openssl) succeeds; built binary runs and reports v3.20.2
  • CI build/test suite (pending, this PR)

baijum added 2 commits July 29, 2026 13:38
golang.org/x/net/html has an XSS vulnerability via HTML parsing bypass
(CVE-2026-27136) and golang.org/x/net/idna has a privilege escalation
via incorrect Punycode label processing (CVE-2026-39821). Both are
fixed in x/net >= v0.55.0. This stream was previously on an older,
vulnerable version.

Ref: HELM-814, HELM-818
The x/net bump in the previous commit raised the go.mod "go" directive
to 1.25.0 as an incidental side effect of satisfying x/net v0.55.0's
own module requirements. Aligning explicitly to the 1.26 line instead,
since Red Hat now has newer Go 1.26.x builds available for this
platform than what's currently tagged into this stream's Brew
buildroot override (golang-1.26.4-1.el9_8, dbenoit-built, already
shipped as RHSA-2026:29981 for other products) -- tagging it into
this stream's override would also satisfy the Go >= 1.26.3 fix
threshold for CVE-2026-33811 and CVE-2026-39820.

Ref: HELM-816, HELM-817
@openshift-ci

openshift-ci Bot commented Jul 29, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: baijum

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci
openshift-ci Bot requested a review from martinszuc July 29, 2026 08:27
@baijum

baijum commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator Author

Build verification correction

go build ./... and the native make build target (CGO_ENABLED=0, -tags no_openssl) both succeed against this change, and the resulting binary runs correctly.

make build-cross could not be verified locally in this environment. It panics immediately, before compiling anything:

panic: fips140: unknown GODEBUG setting fips140=auto
goroutine 1 [running]:
crypto/internal/fips140.init.0()
	crypto/internal/fips140/fips140.go:27 +0x12c
make: *** [build-cross] Error 2

build-cross sets GODEBUG=fips140=auto, a Red Hat-patched Go (golang-fips/go) feature not recognized by vanilla upstream Go — the go tool itself panics at its own init when that env var is set, regardless of target GOOS/GOARCH.

Confirmed this is pre-existing and unrelated to this change: the identical panic occurs on a completely unmodified release-3.20 checkout with none of this PR's changes applied. Verifying build-cross requires the RH FIPS-patched Go toolchain, which isn't installed in this dev environment — CI/Brew (which uses the correct toolchain) is the right place to confirm cross-compilation still works.

baijum added 3 commits July 29, 2026 14:05
The previous commit aligned go.mod's "go" directive to 1.26, but
.github/env (shared by the golangci-lint, build-test, govulncheck,
and release workflows) still pinned GOLANG_VERSION=1.25. golangci-lint
v2.5.0 refuses to lint a module whose declared Go version exceeds the
toolchain it was built with, failing CI with:

  "the Go language version (go1.25) used to build golangci-lint is
   lower than the targeted Go version (1.26)"

Bumping the shared CI Go version keeps it in sync with go.mod across
all four workflows that reference it.

Ref: HELM-821
v2.5.0 (the previously pinned version, from the golangci-lint-action's
"binary" install mode) was built with go1.25 and refuses to lint a
module declaring "go 1.26" in go.mod: "the Go language version
(go1.25) used to build golangci-lint is lower than the targeted Go
version (1.26)". Bumping GOLANG_VERSION alone (previous commit) does
not fix this, since install-mode: binary downloads golangci-lint's own
pre-built release binary rather than compiling it from source with
our chosen toolchain.

Checked release binaries directly (`golangci-lint version`) to find
the actual transition point rather than jumping straight to latest:
v2.8.0 was still built with go1.25.5, v2.9.0 is the first release
built with go1.26.0. Picking the minimal version bump (v2.5.0 ->
v2.9.0) rather than the latest (v2.12.2) to limit the chance of
unrelated new lint rules from later releases surfacing in this PR.

Ref: HELM-821
The golangci-lint v2.9.0 upgrade (previous commit) brought in a newer
revive with an additional var-naming sub-check that flags package
names shadowing Go stdlib package names. It flags three long-standing,
intentional package names in this codebase that predate this PR and
are unrelated to the x/net/Go-version bump: `fs`
(internal/third_party/dep/fs), `driver` (pkg/storage/driver), and
`version` (internal/version). Excluding by the same pattern already
used for revive's redefines-builtin-id exclusions above, rather than
renaming stable, widely-referenced packages to satisfy a newly-enabled
check.

Ref: HELM-821
@baijum
baijum merged commit 7fe2cc2 into release-3.20 Jul 29, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant