Gosu is bringing many cves that won't be taken care of

[dogruis]

The last release of Gosu is one year old and the owner of the codebase is not planning on updating the go version.

postgres/17/bullseye/Dockerfile

Line 31 in 0b87a9b

ENV GOSU_VERSION 1.17

redis/docker-library-redis#424
tianon/gosu#136

[tianon]

Duplicate of #1271

See especially #1271 (comment), https://github.com/tianon/gosu/blob/4233b796eeb3ba76c8597a46d89eab1f116188e2/SECURITY.md, and https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves

To be explicitly clear, there are no "vulnerabilities" in gosu -- there are a collection of naive "security scanners" which posit that there could be, based on the version numbers of libraries the actual built binary does not even include. The purpose of the Go-upstream maintained govulncheck tool is to provide these tools (and end users) with the accurate information about which CVEs which could apply actually apply (which for gosu it currently as of my re-testing just now only reports GO-2023-1840, and per https://github.com/tianon/gosu/blob/052c5c2b186b84c4d9a41ed4f327490ef8d746fe/govulncheck-with-excludes.sh#L9-L13 this is already mitigated in gosu itself so is a true false positive as gosu is not "vulnerable" to it).

[dogruis]

Well your project shouldn't be included in that image of postgres. Even if there is only one real CVE you should fix it.
I don't understand this mindest of pushing back on maintaining things. You spent more time fighting people online than actually maintaining your own library.

[tianon]

To the contrary, I'm not pushing back on "maintaining" anything -- I'm pushing back on the idea that naive tools should "rule" all our workflows, especially when there's trivially available information that they could be consuming to fix their reports. The way I'm maintaining my builds of gosu is exactly how all major Linux distributions maintain their binaries/builds, it's just hidden behind a lot more layers of complexity.

[frankyjquintero]

To the contrary, I'm not pushing back on "maintaining" anything -- I'm pushing back on the idea that naive tools should "rule" all our workflows, especially when there's trivially available information that they could be consuming to fix their reports. The way I'm maintaining my builds of gosu is exactly how all major Linux distributions maintain their binaries/builds, it's just hidden behind a lot more layers of complexity.

@tianon @cdupuis
Following up on the thread, as I understand it, this should be reported to scanners like Docker Scout and others as a false positive that they need to handle directly, rather than the Gosu library addressing it?.

redis/docker-library-redis#424 (comment)

[tianon]

That is correct, yes.