ci: pin govulncheck by commit SHA to avoid x/tools generics panic#558
Open
Benehiko wants to merge 2 commits into
Open
ci: pin govulncheck by commit SHA to avoid x/tools generics panic#558Benehiko wants to merge 2 commits into
Benehiko wants to merge 2 commits into
Conversation
govulncheck v1.4.0 (pulled by @latest) panics with "ForEachElement called on type containing *types.TypeParam" when scanning the repo's generic code, which fails the "known vulnerabilities" check. v1.3.0 is the last release before the regression and scans the modules cleanly (the remaining advisories are all package/module-level with 0 call-reachable symbols, so the gate passes). Pin via a GOVULNCHECK_VERSION build arg, mirroring the GOMODGUARD_VERSION pattern, so it is easy to bump once a fix ships upstream. See golang/go#80059 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![docker-agent[bot]](https://avatars.githubusercontent.com/in/2787757?s=60&v=4){kind=small}
There was a problem hiding this comment.
Assessment: 🟢 APPROVE
No bugs found in the changed code. The GOVULNCHECK_VERSION build arg is correctly scoped to the govulncheck stage, the default value v1.3.0 is properly referenced in the go install command, and the approach mirrors the existing GOMODGUARD_VERSION pattern. The comment clearly documents the reason for the pin and links to the upstream issue.
…cause Switch the govulncheck pin from the v1.3.0 tag to its immutable commit SHA (golang/vuln 0782b76014f15f24e22a438f30f308df42899ba1; Go resolves it back to v1.3.0). Root cause of the v1.4.0 failure: v1.4.0 bumped golang.org/x/tools v0.44.0 -> v0.46.0. v0.46.0 added generic-method support to go/ssa, but its RuntimeTypes guard is incomplete. A closure defined inside a method of a generic type inherits the parent's typeparams but NOT its recvtypeparams, so go/ssa/emit.go's hasTypeParams() guard returns false and a still-parameterized MakeInterface operand (e.g. *box[N]) is recorded in makeInterfaceTypes. cha.CallGraph -> ssautil.AllFunctions -> Program.RuntimeTypes -> typesinternal.ForEachElement then panics on the bare *types.TypeParam. v1.3.0 uses x/tools v0.44.0 (pre-generic-methods) and never reaches that path. No fix has shipped yet: golang/vuln master == the broken v1.4.0 tag, and x/tools master element.go is unchanged from v0.46.0. Tracking: golang/go#80055 (x/tools root cause, Go1.27 milestone, fix CL go.dev/cl/792260) and golang/go#80059 (govulncheck report). Bump once the fix lands and golang/vuln picks it up. Verified locally: do-govulncheck (linux/arm64) resolves the SHA to govulncheck@v1.3.0, scans all modules with no panic, exit 0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Benehiko
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The "Check for known vulnerabilities that affect Go code" CI job fails because govulncheck panics:
Why (root cause)
It is not a real vulnerability and not a govulncheck-code bug — it is a transitive
golang.org/x/toolsregression exposed by the unpinned@latest:@latestnow resolves to govulncheck v1.4.0, which bumpedgolang.org/x/toolsv0.44.0 → v0.46.0.go/ssa, but itsRuntimeTypesguard is incomplete. Ingo/ssa/emit.go,hasTypeParams()=recvtypeparams + typeparams > 0. A closure defined inside a method of a generic type inherits the parent'stypeparamsbut not itsrecvtypeparams(where the method's type parameter lives), sohasTypeParams()returns false.func() any { return &box[N]{} }) records the still-uninstantiated*box[N]inmakeInterfaceTypes.cha.CallGraph → ssautil.AllFunctions → Program.RuntimeTypes → typesinternal.ForEachElementthen reaches the bare*types.TypeParamand panics — that function's contract forbids parameterized types.This repo uses generics heavily, so the scan hits the path. v1.3.0 uses x/tools v0.44.0 (pre-generic-methods) and never reaches it.
Tracking: golang/go#80055 (x/tools root cause, open, Go1.27 milestone, fix CL go.dev/cl/792260) and golang/go#80059 (govulncheck-facing report).
The advisories govulncheck does report (e.g.
GO-2026-4503infilippo.io/edwards25519) are all package/module-level with 0 call-reachable symbols, so they do not fail the gate — no dependency bump is needed.Fix
Pin govulncheck to the golang/vuln v1.3.0 commit SHA (
0782b76014f15f24e22a438f30f308df42899ba1) — the last release before the regression — via aGOVULNCHECK_VERSIONbuild arg, mirroring the existingGOMODGUARD_VERSIONpattern.Pinned by commit SHA rather than the mutable tag for immutability; Go resolves
@<sha>back tov1.3.0. No fix exists to pin forward to: golang/vulnmaster== the broken v1.4.0 tag, and x/toolsmasterelement.gois unchanged from v0.46.0. Bump once x/tools ships the fix and golang/vuln picks it up.Verification
Ran the
do-govulnchecktarget locally (linux/arm64) with the pin:go install @<sha>resolves togovulncheck@v1.3.0.🤖 Generated with Claude Code