feat: update to Go-1.23 #219
Conversation
|
niemeyer
left a comment
niemeyer
left a comment
There was a problem hiding this comment.
Seems mostly okay, but the Spread test changes are unexpected as detailed below.
spread.yaml
Outdated
| prepare: | | ||
| apt install -y golang git | ||
| apt install -y golang-1.23 git | ||
| ln -s /usr/lib/go-1.23/bin/go /usr/local/bin/go |
There was a problem hiding this comment.
This is surprising. It means we're now testing Chisel with a non-standard build from the distribution, and we don't know if it even compiles normally in the system that we're using in the backends right above.
Why are we doing this, and how can we avoid it? Please keep in mind that this is the latest LTS we have.
There was a problem hiding this comment.
I didn't think it was a problem for several reasons:
- We are shipping the
gosnap that can run Go 1.23 and Go 1.24. We are not using it here because it is simpler to avoid installing snapd in spread. - This is only required to build Chisel as the resulting binary is statically linked and does not need the toolchain to be present. I think we could expect devs to upgrade their tools and not stick to the default version shipped.
- Lastly, if the package
golangshipped in Ubuntu is stuck in Go 1.22, there is no way we can update to Go 1.23 at all because it will never build. This will be worse for every version released as more vulnerabilities will be reported by trivy.
There was a problem hiding this comment.
What actual version do we depend on Chisel for? What feature makes it worthwhile to live so close to the edge in a way that we need to ask people running the LTS to do manual actions on their setup, such as linking stuff in /usr/local/?
Maybe that's okay, but do you see how it's weird that we're shipping some software that we cannot even build on last year's LTS? Why?
There was a problem hiding this comment.
I totally agree with you but to me the problem is that Ubuntu 24.04 should update it's version of Go much more often because:
Each major Go release is supported until there are two newer major releases. For example, Go 1.5 was supported until the Go 1.7 release, and Go 1.6 was supported until the Go 1.8 release.
I think the only reason we want to upgrade right now is so that we can publish images will Chisel that are not marked as vulnerable in Dockerhub because trivy finds vulnerabilities. For example the ones listed in the PR (see x/crypto).
With that said we are not affected by any of the vulnerabilities, but I think it would be good to upgrade more often than Ubuntu does, just to avoid an ever growing list of issues even if not applicable.
There was a problem hiding this comment.
I think the only reason we want to upgrade right now is so that we can publish images will Chisel that are not marked as vulnerable
You mean the LTS is vulnerable?
There was a problem hiding this comment.
Let's take a step back because maybe I am missing something. If Ubuntu 24.04 ships go version 1.22.2 (https://launchpad.net/ubuntu/noble/amd64/golang-go) and golang.org/x/crypto/ has a vulnerability until version 0.35.0 (https://pkg.go.dev/golang.org/x/crypto?tab=versions) which requires Go 1.23 (https://cs.opensource.google/go/x/crypto/+/refs/tags/v0.35.0:go.mod), then the version shipped with the LTS version of Ubuntu will have a vulnerability when using https://pkg.go.dev/golang.org/x/crypto, in this example.
There was a problem hiding this comment.
@niemeyer I checked to see if there is a more official stance on the support story and I think that it is what I quoted in previous messages. In more detail:
According to the official webpage on golang.org/x/ packages:
They are developed under looser compatibility requirements than the Go core. In general, they will support the previous two releases and tip.
Anecdotally I was reading a few github issues where people were asking about compatibility and backporting and the general sentiment transmitted by the Go developers was:
Each major Go release is supported until there are two newer major releases. For example, Go 1.5 was supported until the Go 1.7 release, and Go 1.6 was supported until the Go 1.8 release.
which is cited on the main website under "Release Policy" (source).
There was a problem hiding this comment.
That's fine, but we're somewhat speaking across each other here. We develop with Go in the distribution itself, and the distribution is maintained far beyond what upstream might offer. As the particular release gets old, it's less convenient to keep things working and secure. But the case here is a bit remarkable because we're saying that the main LTS, released last year, cannot use a fixed x/crypto. That cannot be true, even if it is the Canonical team itself fixing x/crypto. Either way, you are right that at least for Chisel, this may be less of an issue, so let's move on. I'll just see if we can get tests to pass without having to create manual content into /usr/local.
niemeyer
left a comment
niemeyer
left a comment
There was a problem hiding this comment.
Please see comments in the thread above.
I'm going ahead and merging this.
2 participants
Update to Go-1.23 to avoid trivy reporting vulnerabilities even though we are not affected. Previous output from
trivy rootfs:After this PR there are no vulnerabilities reported.