Remove gosu based CVE by building gosu with current golang image

[nathanlaceyraft]

gosu security policy https://github.com/tianon/gosu/blob/master/SECURITY.md says they don't update golang for CVE's
So gosu is build with a unsupported version of go (1.20)
The two supported go versions that have the most CVE's resolved are 1.23.6 and 1.24.0
I felt using 1.23.6 was a safer upgrade.

Your own documents talk about gosu, and I believe gosu has a fundamental misunderstanding about what a vulnerability free govulncheck means. I understand it to mean that you don't have any external dependencies with vulnerabilities, not that you shouldn't update compiler versions. They are 2 different things.

This PR removes the CVE caused by gosu by doing a custom build of gosu with a currently supported go version.
And copies it into the final image.

trivy image --scanners vuln
shows that we'll get rid of the following CVE's

usr/local/bin/gosu (gobinary)

Total: 58 (UNKNOWN: 0, LOW: 1, MEDIUM: 23, HIGH: 31, CRITICAL: 3)

Thanks for your consideration

[yosifkit]

does not rebuild/release to "fix" CVEs which do not apply

- https://github.com/tianon/gosu/blob/e157efb749be5ce1f32e07aa9849abe3fd953b1c/SECURITY.md (emphasis added)

While the list of CVEs is annoying for users, @tianon is correct and the problem lies in security scanners. They should not blindly attribute a CVE for including a library when go has tooling that they can use to do better and know which functions of the library were included in the binary. They should only attribute the CVE if the vulnerable code path is included and useable in the binary.

[nathanlaceyraft]

Lets pretend we are living in a better world where the vulnerability scanners are better and don't report any false CVE's.

You still have a problem of docker postgres including a binary that was created with a compiler that is a year past End Of Life!

The 2 golang compilers that aren't EOL are 1.23.x and 1.24.x
gosu was compiled with 1.20.x,
1.20.x went EOF Feb 2024 when 1.22 was released

[tianon]

Is there a concrete problem caused by using an "end of life" compiler? Because if so, the Linux distributions would probably like to know about it. As far as I know, there is no meaningful change caused to the gosu binary by recompiling it with a newer compiler except some strings in the binary have a slightly higher number (and the binaries compile slightly differently due to different changes in the compiler). There aren't any active bugs I'm aware of in the versions of the compiler used that actually affect the gosu binary in any way. If there were, I'd be happy to update (just like a normal Linux distro would/does for their precompiled binary builds).

[nathanlaceyraft]

The point about not using EOL software, is that no one is maintaining it any longer, no one is fixing newly discovered problems with it.
It has got to be less work to just keep compilers updated, than it make every 'customer' of your product (downloader of you image) read through every one of the un-needed 58 CVE's caused by gosu and say, 'This is fine'

[bgehman]

The point about not using EOL software, is that no one is maintaining it any longer, no one is fixing newly discovered problems with it.

I would add that security researchers are focused on up-to-date supported software versions: that's where they are looking and where CVEs are discovered, and only afterwards are any related older versions called out. Researches are not hacking on old EOL versions of compilers and libraries. This entire debate is akin to someone claiming their Win-95 server is secure because nobody has reported a CVE against Win-95 in the past 20-odd years. 🤦

I would like to see Golang owners chime in here, and confirm or deny this "best practice" of refusing to upgrade dependencies off of EOL.