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

Activity

1. tianon commented on Nov 25, 2024

   

   tianon

   on Nov 25, 2024

   Member

   More actions

   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).

   👍React with 👍2Reacted by yosifkit and Augustin C.

   👎React with 👎2Reacted by dogruis and Aidan Russell
2. tianon

   closed this as completedon Nov 25, 2024
3. dogruis commented on Dec 2, 2024

   

   dogruis

   on Dec 2, 2024

   Author

   More actions

   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.
4. tianon commented on Dec 2, 2024

   

   tianon

   on Dec 2, 2024

   Member

   More actions

   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.
5. frankyjquintero commented on Mar 17, 2025

   

   frankyjquintero

   on Mar 17, 2025

   Last edited by frankyjquintero

   More actions

   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)

   
6. tianon commented on Mar 17, 2025

   

   tianon

   on Mar 17, 2025

   Member

   More actions

   That is correct, yes.