gosu: CVEs that do not apply to gosu

NOTE: this list is no longer actively maintained; see https://github.com/tianon/gosu/issues/104#issuecomment-1358424738:

With https://github.com/tianon/gosu/releases/tag/1.15, I’ve now got https://github.com/tianon/gosu/blob/master/SECURITY.md which makes it clear how to determine whether vulnerabilities apply to a released version/build of gosu (TLDR, the answer is now govulncheck, which checks for invocations of the actual vulnerable functionality).

CVEs that do not apply to builds of gosu:

If you use (or maintain) a security scanner which reports any of these against gosu, please report them to the security vendor as false positives.

(See also https://snarky.ca/the-social-contract-of-open-source/)

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 25 (10 by maintainers)

Commits related to this issue

Most upvoted comments

I try to keep the main development branch up-to-date with newer package versions, but I have no plans to make a new release of gosu unless there is a compelling reason to do so (changes to/CVEs in the actual codepaths gosu invokes, changes to gosu itself, etc).

Let me get this straight. You’d rather maintain this growing list of false-positive CVEs and respond to continuing bug reports and requests rather than releasing a new incremental version that would clear most if not all of these reports?

Consumers of tools like this generally don’t build it from source. They consume released artifacts. The last release doesn’t include changes you’ve merged into master in the last 15 months. Those changes include dependency updates and even a new Go version. You’ve merged the changes why not release them?

I see your argument elsewhere that until there are “functional changes” you won’t release a new version. I can see that reasoning. Following that reasoning the update to Go 1.19 should justify a new release. There have been a number of changes to Go compiler and runtime since gosu 1.14 was built and released. While the gosu code hasn’t changed the build outputs and runtime behavior have. Based on your own comments that should be sufficient reason for a new release.

+6
liam-verta on Nov 10, 2022

Can I just ask if there is something about updating to a new version of golang that poses more effort than updating all of these vulnerability tools? I understand that this project doesn’t use the parts of the code that have the CVE at the moment, but I can’t help but wonder if it is less effort to just update the go version than it is to ask all of the tools to ignore the warnings for this tool.

+2
daniel-brenot on Nov 7, 2023

Thanks.

FYI:

# /gosu --version1.16 (go1.18.2 on linux/amd64; gc)
# govulncheck /gosu
govulncheck is an experimental tool. 
Share feedback at https://go.dev/s/govulncheck-feedback.
Scanning for dependencies with known vulnerabilities...
No vulnerabilities found.

# /gosu14 --version1.14 (go1.16.7 on linux/amd64; gc)
# govulncheck /gosu14
govulncheck is an experimental tool. 
Share feedback at https://go.dev/s/govulncheck-feedback.
Scanning for dependencies with known vulnerabilities...
govulncheck: vulncheck.Binary: binary built using unsupported Go Version: go1.16.7 

All fine - we will use redis 7.0.8 with gosu 1.16. (1.14 where where we had the CVEs), but we will upgrade to be sure.

+1
ThomasKroghMortensen on Jan 30, 2023

similar to many of the CVEs that are listed, “does not use math/big” / “does not use net/http”

+1
tianon on Sep 15, 2022
  • CVE-2022-30635: does not use encoding/gob
+1
tianon on Aug 25, 2022
Read more comments on GitHub
← fastlane-plugin-flutter_version: Syntax Error: There is this problem while running the fastlane LANE command
only_train_once: oto.compress failed with "xs.append(param.data.view(cc.num_groups, -1))" in graphy.py →