Repository navigation
SOPS is released using Go version 1.23.0, which has vulnerabilities #1835
Description
The release workflow contains the following step for setting up Go:
- name: Setup Go
uses: actions/setup-go@0aaccfd150d50ccaeb58ebd88d36e91967a5f35b # v4.0.1
with:
go-version-file: go.mod
cache: false
and go.mod is currently restricting language version to 1.23.0, which consequently is used as the Go compiler version in the workflow step.
I am wondering if not the Go compiler version should be explicitly set in the release workflow, similar to the CLI workflow, for example:
- name: Setup Go
uses: actions/setup-go@0aaccfd150d50ccaeb58ebd88d36e91967a5f35b # v4.0.1
with:
go-version: '1.24' # or 'stable'
Vulnerabilities in Go 1.23.0 include (severity HIGH reported by Sysdig and Trivy):
Reacted by Rene Leonhardt
Activity
[-]SOPS is being built and released using Go version 1.23.0, which has vulnerabilities[/-][+]SOPS is released using Go version 1.23.0, which has vulnerabilities[/+]felixfontein commentedon Apr 12, 2025
There was an explicit value in there, which was replaced in e0f33e6 to avoid it being forgotten to be updated (see #1615 which contains that commit).
Originally the value in
go.modwas 1.22, and it was changed to 1.23.0 in cbec030. The value 1.22 caused 1.22.10 to be used for 3.9.4 (https://github.com/getsops/sops/actions/runs/12967350893/job/36170087447), while 1.23.0 forces 1.23.0 instead of the latest 1.23.x version in use. @hiddeco was there a specific reason you set the value to 1.23.0 instead of 1.23 in #1819? I think setting it to 1.23 would be better, sincego.modis referenced from the release workflow.jorn-ola-birkeland commentedon Apr 13, 2025
Yes, 1.23, implicitly 1.23.8 currently, will resolve all the mentioned vulnerabilities
hiddeco commentedon Apr 13, 2025
I forgot our release workflow actively makes use of the version defined in our Go Modules file. There are some nuances to fixing this, however.
The
goline declares the minimum version of Go that the module requires (ref). Since Go1.21, if you do not define an exact version here you pull in atoolchaindirective that I have yet to learn to love (and which does not work in combination with the Go action).I think because of this, the quick fix is to step away from deriving the version information from the Go Modules file and instead explicitly define it in the release workflow.