x/vuln: govulncheck expects a go binary

[einsibjarni]

govulncheck version

I'm working on a port for govulncheck for FreeBSD ports.
One thing I've had problems with, is that govulncheck expects a go binary to exist on the machine, and calls it often.

In FreeBSD ports, there is a meta-port, lang/go, which installs the current default go version 1.21 and links go to go121. Unfortunately, the Go team in FreeBSD is having second thoughts about how that is done, and until they have a new solution in place, they've stopped letting maintainers put a runtime dependency on the metaport lang/go.
When writing a FreeBSD port that uses go, you can add the following to the Makefile:

USES= go:modules,run

The syntax of that can be found at https://github.com/freebsd/freebsd-ports/blob/main/Mk/Uses/go.mk

adding run to the USES line signals that this port needs go installed at runtime, as well as for building, but it only creates a dependency on the current default go version port, i.e. go121, not the go metaport. This means there is no go binary.

For the govulncheck port, I've added patches to replace "go" with $GO_CMD, which the ports framework will resolve to the current default go binary. Before the port gets accepted we wanted to know if it is possible to modify govulncheck so that a) it can discover the default go binary or b) make the go binary configurable?

The issue for adding govulncheck to freebsd ports is here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285627

Does this issue reproduce at the latest version of golang.org/x/vuln?

yes

Output of go env in your module/workspace:

AR='ar'
CC='cc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='clang++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/einar/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/einar/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2689206229=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='freebsd'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/home/einar/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='freebsd'
GOPATH='/home/einar/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go124'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/einar/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go124/pkg/tool/freebsd_amd64'
GOVCS=''
GOVERSION='go1.24.3'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

Ran govulncheck ./...

What did you see happen?

govulncheck: no go.mod file

govulncheck only works with Go modules. Try navigating to your module directory.
Otherwise, run go mod init to make your project a module.

See https://go.dev/doc/modules/managing-dependencies for more information.

What did you expect to see?

No vulnerabilities found.

[gabyhelp]

Related Issues

• x/vuln: Binary mode not compatible with golang 1.21.0 #61936 (closed)
• x/vuln: use govulncheck in bazel #61494
• I can't install go on freebsd 12.2 #50022 (closed)
• x/vuln/cmd/govulncheck: v1.1.0: Fatal error when used in a workspace #66863 (closed)
• x/vuln/cmd/govulncheck: incorrect error message #57013 (closed)
• x/tools/gopls: broken build with x/vuln@latest #59837 (closed)
• x/vuln/internal/vulncheck: various tests fail with "binary built using unsupported Go version" when using go1.21rc3 (but not tip nor go1.20.6) #61424 (closed)
• x/vuln: outdated govulncheck documentation #61152 (closed)
• x/vuln/cmd/govulncheck: outdated go version requirements in doc.go #68256 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[cherrymui]

cc @golang/vulndb

Perhaps the command can have a flag to specify the path of the Go command?

[ianthehat]

govulncheck uses go/packages which uses go list
Specifying what go binary go/packages should use has been discussed many times, and the conclusion has always been that adding something called go to your path is the only thing that actually works for all cases.
See #28043 for the most relevant and longest of these discussions.
I don't think anything new has come up or been suggested, so I think it highly unlikely the go team will change their position on this.