build: run govulncheck with go version from build image

[hairyhum]

Change Overview

Patch Go version from cache might contain vulnerabilities, but we specify minor version only in go.mod file.

Pull request type

Please check the type of change your PR introduces:

• 🚧 Work in Progress
• 🌈 Refactoring (no functional changes, no api changes)
• 🐹 Trivial/Minor
• 🐛 Bugfix
• 🌻 Feature
• 🗺️ Documentation
• 🤖 Test
• 🏗️ Build

Issues

• fixes https://github.com/kanisterio/kanister/actions/runs/9441370518/job/26002009362#step:3:29

Test Plan

Run the workflow from this branch

• 💪 Manual
• ⚡ Unit test
• 💚 E2E

[hairyhum]

https://github.com/kanisterio/kanister/actions/runs/9455370624

[psilva-veeam]

Well the Go version in vulncheck should be the same as used. It's also possible to define a Go version explicitly in the yaml file, so that they a synchronous

[psilva-veeam]

So instead go-version-input should be set https://github.com/golang/govulncheck-action/blob/dd0578b371c987f96d1185abb54344b44352bd58/action.yml#L4. Another option is setting go-version-file https://github.com/golang/govulncheck-action/blob/master/action.yml#L4 i.e. the synchronization is always there and only go.mod would have to be adapted during new Go releases

[psilva-veeam]

Patch Go version from cache might contain vulnerabilities, but we specify minor version only in go.mod file.

Actually recent Go releases automatically also specify the patch version in go.mod. I've seen this e.g. recently when using go mod tidy

[hairyhum]

Actually recent Go releases automatically also specify the patch version in go.mod. I've seen this e.g. recently when using go mod tidy

When I run go mod tidy in kanister with 1.22.4 it doesn't do that.

Well the Go version in vulncheck should be the same as used. It's also possible to define a Go version explicitly in the yaml file, so that they a synchronous

"Used" version is whatever we have in the build image https://github.com/kanisterio/kanister/blob/master/docker/build/Dockerfile#L1
The reason we specify the minor version is because we don't want to bump the patch version in the code all the time. At the same time we don't rebuild the build image that often, so maybe having patch version in the go.mod is a good idea.

Alternatively we might consider using github workflow tools instead of the build image, maybe.

[psilva-veeam]

Actually recent Go releases automatically also specify the patch version in go.mod. I've seen this e.g. recently when using go mod tidy

When I run go mod tidy in kanister with 1.22.4 it doesn't do that.

Well the Go version in vulncheck should be the same as used. It's also possible to define a Go version explicitly in the yaml file, so that they a synchronous

"Used" version is whatever we have in the build image https://github.com/kanisterio/kanister/blob/master/docker/build/Dockerfile#L1 The reason we specify the minor version is because we don't want to bump the patch version in the code all the time. At the same time we don't rebuild the build image that often, so maybe having patch version in the go.mod is a good idea.

Wouldn't it be easier at this point to install and run govulncheck directly instead of using the Github Action? E.g.:

go install golang.org/x/vuln/cmd/govulncheck@3740f5cb12a3f93b18dbe200c4bcb6256f8586e2
govulncheck ./...

This way it's guaranteed that the check against the Go standard library version is always the same as in the build image. That's especially useful for minor version upgrades that need to be postponed. Another advantage is that this would allow for version pinning. This would create fully reproducible results and is also a security recommendation. [1] (The govulncheck action always pulls latest [2])

[1] OpenSSF Scorecard / Check Documentation / Pinned-Dependencies
[2] https://github.com/golang/govulncheck-action/blob/master/action.yml

Alternatively we might consider using github workflow tools instead of the build image, maybe.

Ah ok, what would be the difference for that option?

[psilva-veeam]

(Arguably checking a commit from a year ago with latest might be more useful than checking with known vulnerabilities from a year ago. I guess there's no strict right or wrong. On the other hand I still wonder what happens when a newer Go version needs to be held back while govulncheck blindly assumes the patched version is used

So maybe

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

might provide the best trade-offs)

[hairyhum]

Wouldn't it be easier at this point to install and run govulncheck directly instead of using the Github Action?

That also makes sense. Then we will need to bump the go version in the build image if we have vulnerability report. That streamlines the process a bit.

[julio-lopez]

@psilva-veeam IIUC, the line above (25) makes it so the Go version used to run govulncheck matches the one used to build the code up to the minor version, but maybe not the patch version since it is not (currently) specified in the go.mod file.

Is this your understanding as well? Is that sufficient or is there a need to run with the specific patch version?

Also, the go.mod file specifies the toolchain with a patch version, perhaps that needs to be updated?
The go version used by govulncheck is whatever the actions/setup-go action downloads. It is not clear whether or not it uses the toolchain entry from the go.mod file. I didn't see it described in the documentation, but that is easy to test.

@hairyhum How does check-latest: interact or change the behavior of go-version-file: go.mod ?

https://github.com/actions/setup-go?tab=readme-ov-file#check-latest-version

[psilva-veeam]

@julio-lopez I think so, this is also my understanding. So I've been running quite a few tests with govulncheck when it was added. What I noticed is that the difference in patch versions produces occasional warnings. Especially in net and net/http, e.g. the HTTP/2 bug that was fixed in go1.21.9 and 1.22.1

[julio-lopez]

OK. I think I have a better understanding now. These warning are specific to vulnerabilities detected in the standard library.

Does this comment describe the risk?
#2931 (comment)

[hairyhum]

Also, the go.mod file specifies the toolchain with a patch version, perhaps that needs to be updated?

Yes, updating the toolchain setting to 1.22.4 makes the govulnchech pass.

But I'm not 100% sure that's the right way to go, because if we build the binaries with make build-controller or make goreleaser we get them built with the go version from the build image (which is 1.22.2 currently)

So I feel like we better either keep go version in go.mod in sync with the build image or use the build image to run govulncheck instead of govulncheck action.

[julio-lopez]

Also, the go.mod file specifies the toolchain with a patch version, perhaps that needs to be updated?

Yes, updating the toolchain setting to 1.22.4 makes the govulnchech pass.

But I'm not 100% sure that's the right way to go, because if we build the binaries with make build-controller or make goreleaser we get them built with the go version from the build image (which is 1.22.2 currently)

My understanding, (and please verify because I could be wrong) is that the Go toolchain will attempt to use the newer toolchain when the version of the currently running toolchain does not match.

From the "Go Toolchains" documentation:

The choice of Go toolchain being used depends on the GOTOOLCHAIN environment setting and the go and toolchain lines in the main module’s go.mod file or the current workspace’s go.work file.
...
In the standard configuration, the go command uses its own bundled toolchain when that toolchain is at least as new as the go or toolchain lines in the main module or workspace. For example, when using the go command bundled with Go 1.21.3 in a main module that says go 1.21.0, the go command uses Go 1.21.3.

When the go or toolchain line is newer than the bundled toolchain, the go command runs the newer toolchain instead. For example, when using the go command bundled with Go 1.21.3 in a main module that says go 1.21.9, the go command finds and runs Go 1.21.9 instead.

Having said that, if this ends up downloading the new toolchain every time, we might as well upgrade the local version of Go.

It appears that there is a risk in not upgrading Go.

[julio-lopez]

@hairyhum

So I feel like we better either keep go version in go.mod in sync with the build image or use the build image to run govulncheck instead of govulncheck action.

IIUC, the risk would be to incorrectly deem a build as non-vulnerable when there is an actual vulnerability. Is that the concern?

The scenario would be:

• Run govulncheck with the most recent Go toolchain, which would cause the check to "incorrectly" succeed.
• And then build the rest of the code with an outdated Go toolchain that has known vulnerabilities (for example, in the standard library).

[julio-lopez]

This would address the most recent vulnerabilities flagged by govulncheck.

Does it does address the risk described in this comment?

[hairyhum]

My understanding, (and please verify because I could be wrong) is that the Go toolchain will attempt to use the newer toolchain when the version of the currently running toolchain does not match.

Not unless there's a GOTOOLCHAIN variable set in the environment. And it is set in the golang:1.22-bullseye which we base the build image from.
This makes sense for the build image for predictability reasons. You don't want the build image to auto-detect and download a new golang version.

Unfortunately it doesn't fail or warn us the the toolchain is set to later version than the local and just builds with whatever it currently has.

If we set go 1.22.4 in go.mod file, it would fail then. So I would suggest that we do that and keep our build image up to date.

[hairyhum]

REWORK

The PR now gets go version from the build image.

[julio-lopez]

nit: add a comment that makes it explicit that this is used in the next step to specify the Go version to use. It is easy to miss the connection (via ${{ steps.go_version.outputs.go_version }}) when going through the workflow.