Build gosu with a supported version of GO

[jhawkins1]

Go 1.18.x is deprecated and is not receiving functional or vulnerability fixes. Are there plans to update gosu to be built with a supported version of GO (1.20 and 1.21 are the current supported releases as of the date of this issue). If not, I would like to request via this issue that gosu change to build with a newer GO.

[tianon]

If there is a functional or security change in a newer release of Go that's actually relevant to gosu's tiny code paths, I'd be happy to update, but I haven't seen one yet. 😅

(see also https://github.com/tianon/gosu/blob/master/SECURITY.md)

[jhawkins1]

gosu is being pulled in by our usage of the standard Cassandra Image as part of our SaaS solution.

We have a requirement that End-of-Life Software cannot be used. We are getting flagged by gosu due to its usage of a deprecated (EOLed) version of GO. So, either we work with the gosu project to update; get Cassandra to do a custom build and not pull gosu directly from gosu releases, or we fork Cassandra Image build to do custom build ourselves. I was hoping we could work with you or convince you to do an update of gosu itself to avoid the complexities of the other paths. Others that use gosu in an environment where EOL software is forbidden are going to have this same issue :)

[tianon]

Well, gosu is definitely not EOL. 😅

It's also kind of a huge stretch for any tooling to claim that you're "using" Go 1.18 just because your build of gosu happens to have been compiled against it, especially when compiling it against a newer version does absolutely nothing for any possible supported or unsupported usage of the tool -- effectively it just updates a string inside the binary from the text "1.18" to the text "1.21". 🙈

If I were in your position, I'd be pushing back on that tooling for making such strong and generally unsound/incorrect assumptions about what "EOL" means, especially in the context of the compiler version of pre-built published binaries (this applies to binaries from Debian or Ubuntu or Red Hat every bit as much as binaries downloaded from the releases pages of projects on GitHub). 😇

[erickpeirson]

@jhawkins1 We've encountered the same issues using the official Redis images. For a while we forked gosu and addressed these issues ourselves, but that recently hit the end of viability so we've simply removed gosu from the images entirely.

This may be useful (if less than satisfying) context: #131

[petiepooo]

If I were in your position, I'd be pushing back on that tooling for making such strong and generally unsound/incorrect assumptions about what "EOL" means...

Have you tried pushing back against government security bureaucracies? They're managed by people who can't spell EOL, but are convinced it's bad because it ends with L...

[petiepooo]

Take for example Redmine 5.1.1, the latest version released as of this posting. Going to the docker hub page for the app shows a total of 117 vulnerabilities, including 2 critical and 28 high, all of which are attributed to stdlib 1.18.2, which is pulled in as a dependency because someone wanted what gosu provides.

Is it easier to push back against the dozens of tool makers, research every one of those 30 listed as critical and high, plus 11 of the 16 medium, to definitively prove it isn't applicable (or take your word for it), patch gosu ourselves, possibly forking it and releasing as a more current alternative, and ask dependent projects to use my fork instead of yours, or ask that you please take the half-day it would take you to update your build environment and rebuild using a currently supported version of go?

I know you don't owe us freeloaders anything, but when a high majority of flagged issues can all be traced back to "I haven't seen a real vulnerability yet and I can't be bothered to update my build environment," then yes, this project gets classified as abandonware.

Hence this. If your goal to reduce the number of projects that depend on gosu, it's working quite well.

[AlexanderYastrebov]

effectively it just updates a string inside the binary from the text

This is not true, go compiler and runtime updates incorporate a lot of performance improvements and bug fixes (not necessary vulnerabilities).

Official go policy only supports last two major versions https://go.dev/doc/devel/release#policy and encourages to update it periodically. Go1.18 is therefore not supported anymore. In practice this means that you can not open go issues for the application, the go team will ask to upgrade runtime and then come back if the issue persists.

[AlexanderYastrebov]

Another reason for upgrade is to simplify build process, e.g. golang/go#56426 was fixed in go1.20

gosu/Dockerfile

Lines 12 to 15 in b73cc93

	# https://github.com/golang/go/issues/56426
	RUN set -eux; \
	wget -O /tmp/go-mips.patch 'https://github.com/golang/go/commit/2c7c98c3ad719aa9d6d2594827a6894ff9950042.patch'; \
	patch --strip=1 --directory=/usr/local/go --input=/tmp/go-mips.patch

[dev-nulled]

@tianon Thank you. The update is huge and much appreciated.

[DrJJ]

@tianon any idea when 1.18 with go 1.20.5 will be released?

The Infosec team from one of our large customers is freaking out about the official redis image being flagged critical by Google GKE Security Posture. The redis image is using gosu 1.17.

I understand that this Critical is a false positive, but try to explain that to a large Enterprise, that they do not have to worry about that docker image being flagged Critical by Google.

[tianon]

The latest version includes 51 fixable vulnerabilities of which 3 are critical.

The latest version is not vulnerable. Please read https://github.com/tianon/gosu/blob/master/SECURITY.md

One of the biggest things that bothers me here is that we (as an industry) aren't applying this same rigor to things compiled with GCC, for example. This is a case of "we have the metadata in the binary, so we're going to apply it incorrectly" and we don't apply similar logic to other ecosystems. Would the world/vulnerability problem be better if we stripped Go version information from these binaries to avoid this misdetection? I don't think it would! However, that would put these binaries on parity with the C binaries (setpriv, etc) that folks are switching to, even though builds of them are maintained in exactly the same way I'm maintaining builds of gosu -- that is to say, they're only rebuilt if a vulnerability in GCC or their libraries actually applies to them / would change the binary in some meaningful way.

The difference with Go is that we have rich metadata that tells us which version of Go the binary was built against that makes naive tools report that it's "vulnerable" -- even though we now have a canonical tool provided and maintained by Go upstream which parses and interprets that metadata correctly instead! (govulncheck) The maintainers of that tool have written it very much in part so that other tools can use and incorporate their work, and at this point, any security scanner which is reporting "vulnerabilities" in Go binaries but not incorporating the work of that team/tool is doing the entire industry an enormous disservice.

In other words, I'm being obstinate here because I think the current state of the "vulnerability scanning ecosystem" with regards to Go is in an absolutely embarrassing state and I actively want it to be better, but if all anyone ever does is blindly accept the status quo, it will not get better.

[shubhamrajvanshi]

It's been 10 month since the last release and since then there's been new commits added to the repo. Are there any plans for a new release now since now there has been new changes/commits added, @tianon ?

[tianon]

The reduction in code, binary size, and use of Go's stdlib from the changes to main.go (tianon:0d18474...tianon:052c5c2) is probably worth a release, yeah -- however, note that if I do a new release, my builds will be from Go 1.20.5, so may not accomplish your goals for me doing a new release (in the interest of full disclosure).

[shubhamrajvanshi]

Thanks, that would be helpful but while you are at it can we at least stick to the latest minor release version i.e. 1.20.14 at a minimum?

Alternatively, I would like to point out that 1.23 was released 2 days back which makes 1.20 out of support according to the Golang release policy It would be worth it to bump the go version before the release.

[tianon]

If there is a functional or security change in a newer release of Go that's actually relevant to gosu's tiny code paths, I'd be happy to update, but I haven't seen one yet. 😅

(see also https://github.com/tianon/gosu/blob/master/SECURITY.md)

[CRCinAU]

@tianon - I'm kinda curious about your mindset on spending so much of your time and effort pushing back on just updating things and maintaining your own project.

I don't even see your point in claiming that an EOL Go version is 'just fine' because it gets to a point where people don't even accept bug reports against EOL versions of tools - meaning even if there is a security problem, you'll never know about it because it'll be rejected as against an EOL version.

What it does do is to completely expose anyone who uses your project to anything you don't know about. Is this theoretical? Sure. Just as your proposition is that there aren't any issues staying on an EOL version. It's perfectly ok - up until it isn't - and you end up poisoning the entire supply chain.

Considering the resources utilised to keep having this argument again, and again, and again, and again - and the countless hours outside of your own effort by everyone else who has to deal with it, wouldn't it be a much smaller wasted human effort to just adhere to accepted best practices for just about everyone else?