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?

[szh]

I'm experiencing this with Trivy scanning an image based on postgres:15-alpine. You can actually see it on the DockerHub page here

Is there any workaround, other than going in and removing the gosu binary from the image (and hoping that doesn't break anything)?
To clarify, I understand it's a false positive, but Trivy and other scanners are catching it, and it seems like the easiest path forward is to recompile it or remove it.

[AlexanderYastrebov]

I'm experiencing this with Trivy

This ticket aquasecurity/trivy#2845 claims that govuln was integrated into Trivy.

I also checked postgres:15-alpine and it looks like there is indeed one issue reported:

$ ID=$(docker create postgres:15-alpine)
$ docker cp $ID:/usr/local/bin/gosu /tmp/postgres-gosu
Successfully copied 2.36MB to /tmp/postgres-gosu
$ go version -m /tmp/postgres-gosu 
/tmp/postgres-gosu: go1.18.2
        path    github.com/tianon/gosu
        mod     github.com/tianon/gosu  (devel)
        dep     github.com/moby/sys/user        v0.1.0  h1:WmZ93f5Ux6het5iituh9x2zAG7NFY9Aqi49jjE1PaQg=
        dep     golang.org/x/sys        v0.13.0 h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE=
        build   -compiler=gc
        build   -ldflags="-d -w"
        build   CGO_ENABLED=0
        build   GOARCH=amd64
        build   GOOS=linux
        build   GOAMD64=v1
$ govulncheck -mode=binary /tmp/postgres-gosu 
=== Symbol Results ===

Vulnerability #1: GO-2023-1840
    Unsafe behavior in setuid/setgid binaries in runtime
  More info: https://pkg.go.dev/vuln/GO-2023-1840
  Standard library
    Found in: runtime@go1.18.2
    Fixed in: runtime@go1.19.10
    Vulnerable symbols found:
      #1: runtime.Caller
      #2: runtime.CallersFrames
      #3: runtime.Frames.Next
      #4: runtime.Func.Entry
      #5: runtime.Func.Name
      Use '-show traces' to see the other 20 found symbols

Your code is affected by 1 vulnerability from the Go standard library.
This scan also found 3 vulnerabilities in packages you import and 44
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details.

Verbose mode output

$ govulncheck -mode=binary -show=verbose /tmp/postgres-gosu 
Scanning your binary for known vulnerabilities...

Fetching vulnerabilities from the database...

Checking the binary against the vulnerabilities...

=== Symbol Results ===

Vulnerability #1: GO-2023-1840
    Unsafe behavior in setuid/setgid binaries in runtime
  More info: https://pkg.go.dev/vuln/GO-2023-1840
  Standard library
    Found in: runtime@go1.18.2
    Fixed in: runtime@go1.19.10
    Vulnerable symbols found:
      #1: runtime.Caller
      #2: runtime.CallersFrames
      #3: runtime.Frames.Next
      #4: runtime.Func.Entry
      #5: runtime.Func.Name
      Use '-show traces' to see the other 20 found symbols

=== Package Results ===

Vulnerability #1: GO-2023-2186
    Incorrect detection of reserved device names on Windows in path/filepath
  More info: https://pkg.go.dev/vuln/GO-2023-2186
  Standard library
    Found in: path/filepath@go1.18.2
    Fixed in: path/filepath@go1.20.11

Vulnerability #2: GO-2022-0527
    Stack exhaustion in Glob on certain paths in io/fs
  More info: https://pkg.go.dev/vuln/GO-2022-0527
  Standard library
    Found in: io/fs@go1.18.2
    Fixed in: io/fs@go1.18.4

Vulnerability #3: GO-2022-0522
    Stack exhaustion on crafted paths in path/filepath
  More info: https://pkg.go.dev/vuln/GO-2022-0522
  Standard library
    Found in: path/filepath@go1.18.2
    Fixed in: path/filepath@go1.18.4

=== Module Results ===

Vulnerability #1: GO-2024-3107
    Stack exhaustion in Parse in go/build/constraint
  More info: https://pkg.go.dev/vuln/GO-2024-3107
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.22.7

Vulnerability #2: GO-2024-3106
    Stack exhaustion in Decoder.Decode in encoding/gob
  More info: https://pkg.go.dev/vuln/GO-2024-3106
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.22.7

Vulnerability #3: GO-2024-3105
    Stack exhaustion in all Parse functions in go/parser
  More info: https://pkg.go.dev/vuln/GO-2024-3105
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.22.7

Vulnerability #4: GO-2024-2963
    Denial of service due to improper 100-continue handling in net/http
  More info: https://pkg.go.dev/vuln/GO-2024-2963
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.21.12

Vulnerability #5: GO-2024-2888
    Mishandling of corrupt central directory record in archive/zip
  More info: https://pkg.go.dev/vuln/GO-2024-2888
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.21.11

Vulnerability #6: GO-2024-2887
    Unexpected behavior from Is methods for IPv4-mapped IPv6 addresses in
    net/netip
  More info: https://pkg.go.dev/vuln/GO-2024-2887
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.21.11

Vulnerability #7: GO-2024-2687
    HTTP/2 CONTINUATION flood in net/http
  More info: https://pkg.go.dev/vuln/GO-2024-2687
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.21.9

Vulnerability #8: GO-2024-2610
    Errors returned from JSON marshaling may break template escaping in
    html/template
  More info: https://pkg.go.dev/vuln/GO-2024-2610
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.21.8

Vulnerability #9: GO-2024-2609
    Comments in display names are incorrectly handled in net/mail
  More info: https://pkg.go.dev/vuln/GO-2024-2609
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.21.8

Vulnerability #10: GO-2024-2600
    Incorrect forwarding of sensitive headers and cookies on HTTP redirect in
    net/http
  More info: https://pkg.go.dev/vuln/GO-2024-2600
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.21.8

Vulnerability #11: GO-2024-2599
    Memory exhaustion in multipart form parsing in net/textproto and net/http
  More info: https://pkg.go.dev/vuln/GO-2024-2599
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.21.8

Vulnerability #12: GO-2024-2598
    Verify panics on certificates with an unknown public key algorithm in
    crypto/x509
  More info: https://pkg.go.dev/vuln/GO-2024-2598
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.21.8

Vulnerability #13: GO-2023-2382
    Denial of service via chunk extensions in net/http
  More info: https://pkg.go.dev/vuln/GO-2023-2382
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.20.12

Vulnerability #14: GO-2023-2375
    Before Go 1.20, the RSA based key exchange methods in crypto/tls may exhibit
    a timing side channel
  More info: https://pkg.go.dev/vuln/GO-2023-2375
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.20

Vulnerability #15: GO-2023-2102
    HTTP/2 rapid reset can cause excessive work in net/http
  More info: https://pkg.go.dev/vuln/GO-2023-2102
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.20.10

Vulnerability #16: GO-2023-2043
    Improper handling of special tags within script contexts in html/template
  More info: https://pkg.go.dev/vuln/GO-2023-2043
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.20.8

Vulnerability #17: GO-2023-2041
    Improper handling of HTML-like comments in script contexts in html/template
  More info: https://pkg.go.dev/vuln/GO-2023-2041
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.20.8

Vulnerability #18: GO-2023-1987
    Large RSA keys can cause high CPU usage in crypto/tls
  More info: https://pkg.go.dev/vuln/GO-2023-1987
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.12

Vulnerability #19: GO-2023-1878
    Insufficient sanitization of Host header in net/http
  More info: https://pkg.go.dev/vuln/GO-2023-1878
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.11

Vulnerability #20: GO-2023-1753
    Improper handling of empty HTML attributes in html/template
  More info: https://pkg.go.dev/vuln/GO-2023-1753
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.9

Vulnerability #21: GO-2023-1752
    Improper handling of JavaScript whitespace in html/template
  More info: https://pkg.go.dev/vuln/GO-2023-1752
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.9

Vulnerability #22: GO-2023-1751
    Improper sanitization of CSS values in html/template
  More info: https://pkg.go.dev/vuln/GO-2023-1751
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.9

Vulnerability #23: GO-2023-1705
    Excessive resource consumption in net/http, net/textproto and mime/multipart
  More info: https://pkg.go.dev/vuln/GO-2023-1705
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.8

Vulnerability #24: GO-2023-1704
    Excessive memory allocation in net/http and net/textproto
  More info: https://pkg.go.dev/vuln/GO-2023-1704
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.8

Vulnerability #25: GO-2023-1703
    Backticks not treated as string delimiters in html/template
  More info: https://pkg.go.dev/vuln/GO-2023-1703
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.8

Vulnerability #26: GO-2023-1702
    Infinite loop in parsing in go/scanner
  More info: https://pkg.go.dev/vuln/GO-2023-1702
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.8

Vulnerability #27: GO-2023-1621
    Incorrect calculation on P256 curves in crypto/internal/nistec
  More info: https://pkg.go.dev/vuln/GO-2023-1621
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.7

Vulnerability #28: GO-2023-1571
    Denial of service via crafted HTTP/2 stream in net/http and golang.org/x/net
  More info: https://pkg.go.dev/vuln/GO-2023-1571
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.6

Vulnerability #29: GO-2023-1570
    Panic on large handshake records in crypto/tls
  More info: https://pkg.go.dev/vuln/GO-2023-1570
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.6

Vulnerability #30: GO-2023-1569
    Excessive resource consumption in mime/multipart
  More info: https://pkg.go.dev/vuln/GO-2023-1569
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.19.6

Vulnerability #31: GO-2022-1144
    Excessive memory growth in net/http and golang.org/x/net/http2
  More info: https://pkg.go.dev/vuln/GO-2022-1144
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.9

Vulnerability #32: GO-2022-1039
    Memory exhaustion when compiling regular expressions in regexp/syntax
  More info: https://pkg.go.dev/vuln/GO-2022-1039
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.7

Vulnerability #33: GO-2022-1038
    Incorrect sanitization of forwarded query parameters in net/http/httputil
  More info: https://pkg.go.dev/vuln/GO-2022-1038
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.7

Vulnerability #34: GO-2022-1037
    Unbounded memory consumption when reading headers in archive/tar
  More info: https://pkg.go.dev/vuln/GO-2022-1037
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.7

Vulnerability #35: GO-2022-0969
    Denial of service in net/http and golang.org/x/net/http2
  More info: https://pkg.go.dev/vuln/GO-2022-0969
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.6

Vulnerability #36: GO-2022-0537
    Panic when decoding Float and Rat types in math/big
  More info: https://pkg.go.dev/vuln/GO-2022-0537
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.5

Vulnerability #37: GO-2022-0531
    Session tickets lack random ticket_age_add in crypto/tls
  More info: https://pkg.go.dev/vuln/GO-2022-0531
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.3

Vulnerability #38: GO-2022-0526
    Stack exhaustion when decoding certain messages in encoding/gob
  More info: https://pkg.go.dev/vuln/GO-2022-0526
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.4

Vulnerability #39: GO-2022-0525
    Improper sanitization of Transfer-Encoding headers in net/http
  More info: https://pkg.go.dev/vuln/GO-2022-0525
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.4

Vulnerability #40: GO-2022-0524
    Stack exhaustion when reading certain archives in compress/gzip
  More info: https://pkg.go.dev/vuln/GO-2022-0524
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.4

Vulnerability #41: GO-2022-0523
    Stack exhaustion when unmarshaling certain documents in encoding/xml
  More info: https://pkg.go.dev/vuln/GO-2022-0523
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.4

Vulnerability #42: GO-2022-0521
    Stack exhaustion from deeply nested XML documents in encoding/xml
  More info: https://pkg.go.dev/vuln/GO-2022-0521
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.4

Vulnerability #43: GO-2022-0520
    Exposure of client IP addresses in net/http
  More info: https://pkg.go.dev/vuln/GO-2022-0520
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.4

Vulnerability #44: GO-2022-0515
    Stack exhaustion due to deeply nested types in go/parser
  More info: https://pkg.go.dev/vuln/GO-2022-0515
  Standard library
    Found in: stdlib@go1.18.2
    Fixed in: stdlib@go1.18.4

Your code is affected by 1 vulnerability from the Go standard library.
This scan also found 3 vulnerabilities in packages you import and 44
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.

[tianon]

https://github.com/tianon/gosu/blob/4233b796eeb3ba76c8597a46d89eab1f116188e2/SECURITY.md

Our govulncheck wrapper script (govulncheck-with-excludes.sh) may include a small set of vulnerabilities that will be reported by govulncheck which do not apply (due to other mitigations or otherwise). See comments in that script for details.

gosu/govulncheck-with-excludes.sh

Lines 9 to 13 in 4233b79

	# fixed in Go 1.20.5+
	# https://pkg.go.dev/vuln/GO-2023-1840
	# we already mitigate setuid in our code
	"GO-2023-1840", "CVE-2023-29403",
	# (https://github.com/tianon/gosu/issues/128#issuecomment-1607803883)

[AlexanderYastrebov]

Our govulncheck wrapper script (govulncheck-with-excludes.sh) may include a small set of vulnerabilities that will be reported by govulncheck which do not apply (due to other mitigations or otherwise). See comments in that script for details.

FWIW govulncheck reports none for gosu built with latest golang.
I think this is due to https://go-review.googlesource.com/c/go/+/501223 that mitigates GO-2023-1840

[szh]

I thought maybe we could use Copa to remove the vulnerability automatically but it only deals with OS packages so it had no effect here.

[tianon]

That, and the "vulnerable code" doesn't even exist inside the binary, so there's nothing to remove.

[shusaan]

I have verified that there is no vulnerable code, and govulncheck-with-excludes.sh did not find any vulnerabilities. However, after researching tools like Trivy and Grype, I found that they perform extensive scans and have identified vulnerabilities in the gosu binary. These vulnerabilities are due to the build environment being old version and some modules being outdated. For details on the build environment and modules, please refer to this PR.

[tianon]

I would say "more naive" instead of "more extensive" -- they identify the version numbers involved and assume the software is vulnerable whether it involves the vulnerable code paths or not (that's what makes govulncheck different; it actually knows which code paths are vulnerable and checks for those directly, which means a lot fewer false positives).