-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Package vs module for go advisories #2224
Comments
This is indeed an issue. Any comment from maintainers/github forthcoming? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I noticed that for some go vulnerabilities, the vulnerability references a go package,
and not a go module.
For example, GHSA-pmw9-567p-68pc references the package
github.com/cloudflare/cfrpki/cmd/octorpki
, while the associated go module isgithub.com/cloudflare/cfrpki
.Note that some advisories reference both package and module, such as GHSA-74fp-r6jw-h4mp.
This is a bit troublesome, as
go.mod
files reference modules, so we need to find the module that contains a packagein order to know if a module is vulnerable.
Moreover, if a vulnerability references a package (inside a module), it is possible for the package to be later shadowed
by a module of the same name. In this case, the vulnerability would reference the wrong module.
From basic queries on the
proxy.golang.org
, it seems that about 20% of go packages referenced in (reviewed) advisories reference a non-existing module (which is most likely a package inside a module). This concerns 1010 advisories in total.Do you think this is an issue that should be acted upon ?
The text was updated successfully, but these errors were encountered: