Bump release Go toolchain to fix stale stdlib CVEs - #326
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
Unable to sign CLA... Creating a new Google Account requires a email verification (no problem) and a phone number, for this it says "This phone number can't receive calls or SMS from Google" (it is a normal working phone number) and requires a QR code verification with your phone, after completing phone says "You're now verified. Thanks for taking this step to help keep Google services safe", but on the web page it refuses to continue with "Please try again with a phone that is connected to a phone number or SIM". Update: Managed to sign CLA. |
braydonk
left a comment
There was a problem hiding this comment.
Thanks for the PR, I have one suggestion.
| uses: actions/setup-go@v5 | ||
| with: | ||
| go-version: 1.24 | ||
| go-version-file: go.mod |
There was a problem hiding this comment.
I would rather not rely on the toolchain directive in go.mod... Would you be willing to add a .go-version file and refer to it here? The action docs seem to indicate this is an option. If it's swapped to this, I might be able to set up renovate on this repo to automatically bump the version of Go I use anytime a new Go version comes out.
There was a problem hiding this comment.
Done, makes sense. I opened a PR to add Renovate #327.
go-version: 1.24 in release.yaml fell out of Go's security-backport window, so release binaries stopped getting stdlib patches. Track a .go-version instead and bump toolchain to go1.27.1.
1485c87 to
d9146bc
Compare
|
Ignoring the zizmor warnings for this PR I'll follow up on those later |
Summary
.github/workflows/release.yamlpinned Go builds togo-version: 1.24, which is now past Go'ssecurity-backport window (only the two newest majors get stdlib patches) — release binaries stopped picking up
stdlib fixes for crypto/tls, net/url, archive/tar, html/template, etc.
go-version-file: go.mod(keepscheck-latest: true) so the release build always tracks the sameGo version as the rest of the project, instead of drifting on its own again.
go.mod'stoolchaindirective fromgo1.24.8togo1.27.1.Downstream consumers maintain a Trivy suppression list for CVEs baked into prebuilt
dockerfmtbinaries (e.g. https://github.com/gw0/docker-claude-code/blob/main/.trivyignore.yaml). This fixes the root cause upstream instead of relying on per-consumer suppressions.Test plan
go mod tidy— clean, nogo.sumchangesgo vet(matchingmake vet) — cleango test ./...— all packages passmake integrationtest— passestrivy rootfs, gobinary analyzer):go1.24.8(before): 36 vulnerabilities (1 CRITICAL, 21 HIGH, 13 MEDIUM, 1 LOW)go1.27.1(after): 0 vulnerabilities