Open hyangah opened 1 week ago
Similar Issues
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Putting the false positive discussion aside, note that these are not duplicate traces. Although they do start from the same entry point, in this case main
, they lead to a different vulnerable symbol.
The true vulnerable symbol in this specific case is an internal symbol, but unfortunately it affects most symbols in the http2 package. If the internal symbol could be used as the final vulnerable symbol, the text summary of each trace would look identical.
On the other hand, given the nature of this false positive, I am afraid the number of displayed traces won't shrink with the suggested heuristic. There will be many different entries that use fmt
. :-(
I agree, this is just a misfortunate false positive. If the vulnerability was indeed reachable, govulncheck would report only exported symbols and then I think we'd see much less traces because the user would likely use just a few of the net/http APIs.
govulncheck version
Go: devel go1.23-9d33956503 Thu Jun 20 17:46:05 2024 +0000 Scanner: govulncheck@v1.1.2 DB: https://vuln.go.dev DB updated: 2024-06-20 18:18:26 +0000 UTC
Does this issue reproduce at the latest version of golang.org/x/vuln?
yes.
Output of
go env
in your module/workspace:What did you do?
git clone https://github.com/golang/vscode-go git checkout 540e146da cd extension govulncheck ./tools/...
What did you see happen?
several similar traces with the same entry points (tools/generate.go).
govulncheck -show=traces
shows vulnerable types implementingStringer
will appear.What did you expect to see?
Ideally no report unless the types are really used. However, I guess this is a type of false positives hard for the current govulncheck hard to handle.
We think we can still reduce the volume of text and make it less overwhelming, by enhancing the deduping mechanism.
From @ianthehat