-
Notifications
You must be signed in to change notification settings - Fork 157
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
Should we support a leading v in golang packages? #294
Comments
I think the v is part of the version in Go and needs to be present. golang/go#32945 If purls were written without the v and then Go started doing something different, it would break all purl implementations. |
@TG1999 @matt-phylum go is a mess in this domain. 😈 I'm inclined to accept the versions as they are with their v prefix, but then these are not the semver versions that go moduled promised anymore short of stripping the leading v. So we need to agree on a canonical way (and document this preferred canonical way in the types doc) and also accept that unfortunately tools will have to deal with prefixed and unprefixed versions, and will need to strip the prefix to compare version properly in all cases and alo query some databases. This is done here for instance https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#golang |
The Go section of the spec is in dire need of updates. The version and subpath stuff there implies that it's talking about Go packages and Go modules aren't supported. However, if the version specification were relaxed to a Git reference instead of a commit ID (truncated to an unspecified length), then the v must be included because the v is part of the tag name and is significant to Git. Commit IDs and other Git references are not versions and cannot be compared, but in Go if a tag begins with v and contains a valid version number then it is a comparable version. It looks like since Go started using modules, the examples need to be updated:
Proper examples with versions:
|
Another confusion for go: |
The spec is clear that Go packages have PURL namespaces, even if the concept does not exist in Go. What's missing is that Go packages only sometimes have PURL namespaces because not all Go package IDs contain slashes. |
I guess the problem with Go (and NPM) packages is that even if your PURL implementation is correct, it's up to the application to correctly handle this namespace/name split and join translation, and users are unlikely to read the spec when they have the library to handle that for them. Maybe slashes in the names of Go packages should be forbidden to stop users from unknowingly doing the wrong thing and because of the way the names work it shouldn't be possible for slashes in the name to get some other meaning where they would need to be accepted later. |
@matt-phylum, we should fix the purl spec for go IMHO. Go was the only team with some reservations during the last IETF submission if my memory is correct. |
#204 might be the way to go. Combine the namespace and name into one value at the PURL level, don't encode slashes¹, and leave it up to the package type how to interpret it. Go would change from [0,n-1) of the Go package ID split by NPM would change from the NPM namespace in the PURL namespace and the NPM name in the PURL name to the full package name in the PURL name. NPM does have namespaces, but most of the time you don't need to be aware of them and just use the full package name, and it would be possible to do the same with PURL. Ergonomics are improved because the user no longer needs to split and join. Maven would change from the Maven group ID in the PURL namespace and the Maven artifact ID in the PURL name to "/" in the PURL name. In this case, the ergonomics are worse because the splitting and joining is left up to the user. Maven tools don't typically specify packages this way. Rewriting the spec this way shouldn't change the representation of any packages, so even though it would be a breaking API change for libraries, it wouldn't be a breaking change for the ecosystem and we wouldn't need to migrate everything to an incompatible PURL2 or deal with Go PURLs that are full of ¹ Is this alone okay? For URL, the path segments are tricky. If you use a normal URL parser and ask for the full path of the URL, it needs to give you the path without fully percent decoding it in case |
If we look at go packages like these https://github.com/go-jose/go-jose/archive/refs/tags/v4.0.1.zip https://pkg.go.dev/github.com/go-jose/go-jose/v3?tab=versions, they have a leading v in them. Whereas if we look in osv.dev they are stored without any leading v https://osv.dev/vulnerability/GHSA-c5q2-7r4c-mv6g.
So how should we store this as a purl ?
pkg:golang/github.com/go-jose/go-jose/v4@v4.0.1
orpkg:golang/github.com/go-jose/go-jose/v4@4.0.1
?The text was updated successfully, but these errors were encountered: