Closed tianon closed 3 months ago
This is really interesting -- I can reproduce, and it's definitely something going wrong (as most obviously evidenced by archive/zip
being in that list, for example -- we don't touch anything from that module in gosu
's codepaths).
Separately, I also clearly need to update the CI here to download the latest release and test that too.
Well this is interesting -- maybe a bug in govulncheck
or me misunderstanding their JSON format:
$ govulncheck -mode=binary ./gosu-amd64
=== 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 40
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details.
(only the one result, as expected)
$ govulncheck -mode=binary -format json ./gosu-amd64 | jq -s 'map(.osv.id // empty) | unique | join("\n")' -r
GO-2021-0067
GO-2021-0069
GO-2021-0142
GO-2021-0154
GO-2021-0159
GO-2021-0160
GO-2021-0163
GO-2021-0172
GO-2021-0178
GO-2021-0223
GO-2021-0224
GO-2021-0226
GO-2021-0234
GO-2021-0235
GO-2021-0239
GO-2021-0240
GO-2021-0241
GO-2021-0242
GO-2021-0243
GO-2021-0245
GO-2021-0263
GO-2021-0264
GO-2021-0317
GO-2021-0319
GO-2021-0347
GO-2022-0166
GO-2022-0171
GO-2022-0187
GO-2022-0191
GO-2022-0211
GO-2022-0212
GO-2022-0213
GO-2022-0217
GO-2022-0220
GO-2022-0229
GO-2022-0236
GO-2022-0273
GO-2022-0288
GO-2022-0289
GO-2022-0433
GO-2022-0434
GO-2022-0435
GO-2022-0477
GO-2022-0493
GO-2022-0515
GO-2022-0520
GO-2022-0521
GO-2022-0522
GO-2022-0523
GO-2022-0524
GO-2022-0525
GO-2022-0526
GO-2022-0527
GO-2022-0531
GO-2022-0532
GO-2022-0533
GO-2022-0535
GO-2022-0536
GO-2022-0537
GO-2022-0761
GO-2022-0969
GO-2022-0988
GO-2022-1037
GO-2022-1038
GO-2022-1039
GO-2022-1095
GO-2022-1143
GO-2022-1144
GO-2023-1568
GO-2023-1569
GO-2023-1570
GO-2023-1571
GO-2023-1621
GO-2023-1702
GO-2023-1703
GO-2023-1704
GO-2023-1705
GO-2023-1751
GO-2023-1752
GO-2023-1753
GO-2023-1840
GO-2023-1878
GO-2023-1987
GO-2023-2041
GO-2023-2043
GO-2023-2044
GO-2023-2045
GO-2023-2102
GO-2023-2185
GO-2023-2186
GO-2023-2375
GO-2023-2382
GO-2024-2598
GO-2024-2599
GO-2024-2600
GO-2024-2609
GO-2024-2610
GO-2024-2687
GO-2024-2824
GO-2024-2887
GO-2024-2888
(whoa baby, what?)
Aha, it looks like -format
has a new openvex
output mode which lists the inverse of the normal output, and I bet the JSON changes are related to that.
As far as I can tell, the JSON output now no longer differentiates between "module used but codepath is not" and "module used and codepath in callstack" which is wild.
At least the sarif
output includes level
which is either note
or error
to help differentiate these. :confused:
https://github.com/golang/vuln/releases/tag/v1.0.2
govulncheck (streaming) JSON now emits an OSV message for each vulnerability associated with user modules and its transitive dependencies, regardless of the module version.
This is great, but needs some sane way to filter. :grimacing:
Ah, that's really helpful context, thank you! :heart:
(I really appreciate your time/eyes on this :bow:)
Hmm, I must still be holding it wrong: :sob: (when I look at finding
s instead, I still get a long list not what -format text
prints out)
$ govulncheck -mode=binary -format json ./gosu-amd64 | jq -s 'map(.finding.osv // empty) | unique | join("\n")' -r
GO-2022-0515
GO-2022-0520
GO-2022-0521
GO-2022-0522
GO-2022-0523
GO-2022-0524
GO-2022-0525
GO-2022-0526
GO-2022-0527
GO-2022-0531
GO-2022-0537
GO-2022-0969
GO-2022-1037
GO-2022-1038
GO-2022-1039
GO-2022-1144
GO-2023-1569
GO-2023-1570
GO-2023-1571
GO-2023-1621
GO-2023-1702
GO-2023-1703
GO-2023-1704
GO-2023-1705
GO-2023-1751
GO-2023-1752
GO-2023-1753
GO-2023-1840
GO-2023-1878
GO-2023-1987
GO-2023-2041
GO-2023-2043
GO-2023-2102
GO-2023-2186
GO-2023-2375
GO-2023-2382
GO-2024-2598
GO-2024-2599
GO-2024-2600
GO-2024-2609
GO-2024-2610
GO-2024-2687
GO-2024-2887
GO-2024-2888
I guess that's this note:
Your code is affected by 1 vulnerability from the Go standard library.
This scan also found 3 vulnerabilities in packages you import and 40
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details.
but I can't figure out how to filter these 40 from the JSON :disappointed:
Oh, I guess checking the trace
for function
/receiver
?
Aha, that is the key, thank you again!! :bow: :heavy_heart_exclamation:
$ govulncheck -mode=binary -format json ./gosu-amd64 | jq -s 'map(select(.finding and .finding.trace and any(.finding.trace[]; has("function"))) | .finding.osv // empty) | unique | join("\n")' -r
GO-2023-1840
I don't have more time to help with this as this is not a bug related to govulncheck. The documentation on Finding contains the necessary information. If you are analyzing source code and want symbol-level findings, you will need to look at Findings whose first trace element has Function != ""
. You can also use internal/sarif
as a reference.
Totally fair, I appreciate it very much!! (and also govulncheck
:heart:)
I am having difficulty understanding the following statement:
I recently downloaded v1.17 and scanned it using your provided govulncheck-with-excludes.sh. Here are the results:
Using your build.sh script, I created a fresh build of the gosu-amd64 binary. When I ran a scan on it, the results were as follows:
Maybe I am misunderstanding it. If that's the case, I apologize – I am not a developer and just trying to make do with the tools available.
Originally posted by @rgarcia89 in https://github.com/tianon/gosu/issues/136#issuecomment-2152209745