Govulncheck reports known vulnerabilities that affect Go code. It uses static analysis of source code or a binary's symbol table to narrow down reports to only those that could affect the application.
Created attachment 258974 [details] Add govulncheck to ports
portlint OK, built with poudriere on amd64
Had to add RUN_DEPENDS on lang/go. USES= go:run wasn't enough, because govulnhceck looks for `go` in PATH to reflect version of go.
GO_BUILDFLAGS= -C cmd/govulncheck Does this means GO_TARGET= ./cmd/govulncheck ?
(In reply to Einar Bjarni Halldórsson from comment #3) # run Indicates that Go is needed at run time and adds it to # RUN_DEPENDS. Maybe cc golang team is a good idea.
(In reply to Nuno Teixeira from comment #4) > Does this means GO_TARGET= ./cmd/govulncheck ? You're right :) (In reply to Nuno Teixeira from comment #5) > # run Indicates that Go is needed at run time and adds it to > # RUN_DEPENDS. > > Maybe cc golang team is a good idea. `run` only adds a dependency on default go port, not the go metaport. `govulncheck` needs `go` binary on PATH to deduce default go version. Adding go@freebsd.org for input on cleaner way to declare dependency which pulls in go metaport
We don’t have a clean way right now, but that will most likely change very soon. I’m planning on removing old go versions and the go metaport, meaning go will install the ‘go’ binary out of the box. I don’t have a timeline yet. The correct approach today is to sub in the correct binary name; see Uses/go.mk for how to get that name.
(In reply to Adam Weinberger from comment #7) > The correct approach today is to sub in the correct binary name; see Uses/go.mk for how to get that name. So patch the upstream code to replace `go` with `GO_CMD`?
(In reply to Einar Bjarni Halldórsson from comment #8) Without having actually looked at it at all, that's the general idea. If you hit any snags with the implementation, speak up.
(In reply to Adam Weinberger from comment #9) I haven't found a way to do it. The code that calls `go` is here https://github.com/golang/vuln/blob/e4f767ca72215eb48121cb47a8678a97b63558c0/internal/scan/util.go#L53 I thought I could use SUB_LIST and patch the file with %%GO_CMD%% but doesn't seem to work (or I'm doing it wrong)
(In reply to Einar Bjarni Halldórsson from comment #10) cp target to .orig and patch target, make makepatch: cp ./work/golang.org/x/vuln@v1.1.4/internal/scan/util.go \ cp ./work/golang.org/x/vuln@v1.1.4/internal/scan/util.go.orig replace 'go' with %%GO_CMD%% and use sed to replace %%GO_CMD%% with ${GO_CMD}. This is way to do it.
(In reply to Nuno Teixeira from comment #11) I mean: > cp ./work/golang.org/x/vuln@v1.1.4/internal/scan/util.go \ > ./work/golang.org/x/vuln@v1.1.4/internal/scan/util.go.orig
(In reply to Nuno Teixeira from comment #11) > replace 'go' with %%GO_CMD%% > and use sed to replace %%GO_CMD%% with ${GO_CMD}. Ah... I got it to work, but then I got another (more descriptive error): govulncheck: loading packages: err: go command required, not found: exec: "go": executable file not found in $PATH: stderr: Looking through the code, it and included libraries are invoking `go` all over the place. Also, now I can't build with RUN_DEPENDS on lang/go anymore: Error: lang/go should not be depended upon. Instead, use USES=go.
(In reply to Einar Bjarni Halldórsson from comment #13) For test purposes I would replace all 'go' occurences. I'm fan of brute force :) Hum, BINARY_ALIAS?
(In reply to Nuno Teixeira from comment #14) > For test purposes I would replace all 'go' occurences. I'm fan of brute force :) I'll take another look at it in the morning. > Hum, BINARY_ALIAS? I belive BINARY_ALIAS only functions during the build stage, but the errors come during runtime.
Created attachment 260260 [details] New port, security/govulncheck without runtime dependency on lang/go
New patch, replaces all instances of running `go` with $GO_CMD. Builds in poudriere on 14.2-RELEASE on amd64 and tested to work
(In reply to Einar Bjarni Halldórsson from comment #17) Nice that it works. Wandering if 'cmd' in exec could be improved for better portability by upstream instead of using just a plain cmd: 'go', but I don't have skills to check that. See also: https://pkg.go.dev/os/exec
(In reply to Nuno Teixeira from comment #18) I've opened an issue: https://github.com/golang/go/issues/73634 I'm not too optimistic that it will be addressed, so maybe if Adam gives an ok on my patches, we can get this committed and then I'll remove the patches when the Go team makes the changes that removes the metaport and installs the `go` binary
(In reply to Einar Bjarni Halldórsson from comment #19) Also, you will have to raise go dep version in port USES=go: >=1.22,... because of: https://go.googlesource.com/vuln/+/refs/tags/v1.1.4/go.mod ``` module golang.org/x/vuln go 1.22.0 <snip> ``` this way we avoid extra go building.
(In reply to Nuno Teixeira from comment #20) I've got go124 as the default in my env, so I didn't notice. What I did notice after building govulncheck with go122 is: $ govulncheck ./... govulncheck: loading packages: There are errors with the provided package patterns: /home/einar/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.9.freebsd-amd64/src/slices/iter.go:50:17: cannot range over seq (variable of type iter.Seq[E]) /home/einar/go/pkg/mod/golang.org/x/text@v0.25.0/internal/tag/tag.go:6:1: package requires newer Go version go1.23 /home/einar/go/pkg/mod/golang.org/x/text@v0.25.0/internal/language/common.go:3:1: package requires newer Go version go1.23 /home/einar/go/pkg/mod/golang.org/x/text@v0.25.0/internal/language/compact/compact.go:14:1: package requires newer Go version go1.23 /home/einar/go/pkg/mod/golang.org/x/text@v0.25.0/language/coverage.go:5:1: package requires newer Go version go1.23 /home/einar/workspace/vuln-tutorial/main.go:1:1: package requires newer Go version go1.23 For details on package patterns, see https://pkg.go.dev/cmd/go#hdr-Package_lists_and_patterns. If we build with go122, we can't scan projects that use newer versions of Go, including imported modules. Therefor I want to set the dependency on go124 and to try to maintain it always on the latest go version.
(In reply to Einar Bjarni Halldórsson from comment #21) Exactly, the port must know that: - USES= go:modules,run + USES= go:1.24,modules,run
Created attachment 260282 [details] New port, security/govulncheck, now depends on latest Go version, 1.24
Created attachment 260283 [details] New port, security/govulncheck, now depends on latest Go version, 1.24 Sent the wrong patch last time