update: bump Go version #4176
update: bump Go version #4176
Conversation
It'd appear 1.20.10 is triggering some scanner alerts. Though these are not critical, it costs us very little effort to bump the runtime one minor version higher. Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
|
Do we need Windows compatibility in any code? Because the security fix in 1.20.11 had a regression; fix for that should hopefully go out on Tuesday; golang/go#64028 (comment) |
|
Tbh, I dont know if anyone runs registry on Windows but we shouldnt rule that out. If there is a patch release coming out soon then I reckon it's better to wait. Happy to close this and wait for the patch. I've opened this on a prompt by some people via Slack whose image scanners are moaning. |
|
Yeah, same; I've been nudging the Go team for a while now (hey, security fixes are all fun and stuff, but if they introduce a regression...). Both docker an containerd are not able to update Go version because of that which, erm, means a significant part of the industry, and 😡 Go maintainers don't give a 💩 every time. |
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
|
I think it's fine to keep this one open (or in draft) and update once the next patch release arrives (it's another security update, so let's see what that brings this time) |
|
Marking as draft until the new Go patch release is out |
|
I feel like its late enough in the go release cycle now we could just bump to 1.21 as well. |
|
Yeah not a bad shout. However 1.21 patch is also to be released, so let's wait and bump it when it's out |
|
Agree on moving the default to 1.21 (we can keep 1.20 in the CI test-matrix, and always test "latest" and "latest-1" per Go recommendations) |
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
|
PTAL @thaJeztah @Jamstah I've bumped the runtime in the docker image to the latest |
|
Why not go 1.21 for the CI tasks? Approved, but would be happy to bump those too. |
So my thinking was: if folks don't have the latest tooling on their machines we should strive to "mirror" CI on their laptops...we already do E2E for both minor versions. I'm happy to change it if we want to. |
|
I think that for Mac/Windows, you install golang separately to the OS, so they can use 1.21 easily. For linux distributions, it tends to be when the package manager updates it. Maybe we need a policy for when we bump it? Or, we could define a vscode dev container or something too. Let use this one to bump to the latest patch for the security issues, and open a new one for 1.21 for go.mod etc. |
Updating the version in |
|
I guess that means projects used as libraries need to stay low :/
Do we consider ourselves to be a project used as a library? Most of those uses were for reference which is now moved out. |
|
Well, not just as library; if we test on go1.20, we cannot update go.mod to go1.21 (it will fail to compile) Also if we add the go1.21 line, we probably also want to add a |
This is why I didn't want to bump the I reckon once As for the library point: some projects use some storage driver code from this project, at least |
It'd appear Go
1.20.10is triggering some scanner alerts due to CVE-2023-45283.Though these are not critical, it costs us very little effort to bump the runtime one minor version higher.
Go
1.20.11milestone can be found here.