No vulnerabilities found for Go packages / Percent-Encoding in purl

[wkl3nk]

Hello,

I use ORT 34.0.0 in combination with VulnerableCode.
The GoMod ORT package analzyer returned a dependency:

id: "Go::github.com/quic-go/quic-go:0.40.0"
purl: "pkg:golang/github.com%2Fquic-go%2Fquic-go@0.40.0"

On first sight, the purl looks strange, because it has both the slash character "/" and the percent-encoded equivalent of the "/" which is "%2F".

I think ORT is correct in the purl, because the purl specification states:

• namespace: Each namespace segment must be a percent-encoded string
• name: A name must be a percent-encoded string

I think we don't have a namespace here (See the id: "Go::gith..."
And the name is github.com%2Fquic-go%2Fquic-go
So name is completely percent-encoded. Correct???

The problem: When I do a bulk-search using the VulnerableCode API, I get no vulnerability records reported, although this component definitely has vulnerability records.

Can you please make a statement about usage of percent-encoding in purls and if this is supported in the API?
What advice are you giving me?
Will you fix it on your side?

Reference to ORT issue: oss-review-toolkit/ort#9298

[sschuberth]

FYI, the golang examples also have no encoded slashes, and there generally seems to be some confusion about what is right.

[keshav-space]

@wkl3nk at the moment we don't encode the paths in the golang PURL. If you instead search for pkg:golang/github.com/quic-go/quic-go@0.40.0, you will get the vulnerabilities here https://public.vulnerablecode.io/packages/search.

VulnerableCode is using https://github.com/package-url/packageurl-python for handling PURLs and with respect to golang it treats the last segment as the name and the rest as the namespace. So, for pkg:golang/github.com/quic-go/quic-go@0.40.0, packageurl-python interprets:

• namespace: github.com/quic-go
• name: quic-go

Another example pkg:golang/github.com/go-jose/go-jose/v3@3.1.0 in this case:

• namespace: github.com/go-jose/go-jose
• name: v3

FYI, the golang examples also have no encoded slashes, and there generally seems to be some confusion about what is right.

Yes, there is some confusion regarding the handling of golang PURLs. We need to add proper guidelines on handling golang PURLs here https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#golang.

[johnmhoran]

@wkl3nk @keshav-space I've added a comment re my interpretation of encoding slashes and in particular the go PURL pkg:golang/github.com%2Fquic-go%2Fquic-go@0.40.0 to one of the open PRs in the purl-spec repo -- see package-url/purl-spec#176 (comment)

[johnmhoran]

Update: other members of the community have promptly expressed disagreement with my interpretation --

• add an example with / in namespace to README and SPEC package-url/purl-spec#176 (comment)
• add an example with / in namespace to README and SPEC package-url/purl-spec#176 (comment)

[johnmhoran]

These comments also assert that Go PURLs correctly interpret the entire encoded block as the name and note that Go does not have the concept of a namespace.

[sschuberth]

@wkl3nk I believe we should close this issue here. VulnerableCode does the correct thing WRT the current version of the purl spec, which does treat a Go package as if it had a namespace although it doesn't.

So if at all, this needs to be fixed in the purl spec and test suite, plus all implementations for the various programming languages. But now that we already have so much data with "wrongly" encoded purls, I guess it's easier to just clearly document that purl treats Go as if it had namespaces.