PURLS not following spec

[gitgitwhat]

Describe the bug
I reported on PURL issues a few years ago (#1234) and it was 'Closed as not planned.' OSV still has PURL issues and this directly impacts the usability and viability of OSV.

Here's just one example vuln report that shows a bigger issue.

https://api.osv.dev/v1/vulns/GO-2024-3321

  "affected": [
    {
      "package": {
        "name": "golang.org/x/crypto",
        "ecosystem": "Go",
        "purl": "pkg:golang/golang.org/x/crypto"

The PURL is not formatted properly because according to the spec (https://github.com/package-url/purl-spec/blob/main/PURL-SPECIFICATION.rst) A name must be a percent-encoded string

So the valid PURL in this case is pkg:golang/golang.org/x%2fcrypto

Not sure what the point of having a spec is if it is not followed because it's going to break tools that do.

To Reproduce

Expected behaviour
Follow the spec.

Screenshots
N/A

Additional context
None

[cuixq]

I think for Go module golang.org/x/crypto, crypto is the name in the PURL so no encoding is needed for it.

[gitgitwhat]

I think for Go module golang.org/x/crypto, crypto is the name in the PURL so no encoding is needed for it.

Please then go back to the spec to see why that is still wrong (bold emphasis mine):

namespace:

    The optional namespace contains zero or more segments, separated by slash '/'
    Leading and trailing slashes '/' are not significant and should be stripped in the canonical form. They are not part of the namespace
    Each namespace segment must be a percent-encoded string
    When percent-decoded, a segment:
        **must not contain a '/'**
        must not be empty
    A URL host or Authority must NOT be used as a namespace. Use instead a repository_url qualifier. Note however that for some types, the namespace may look like a host.

[cuixq]

In the Golang specific PURL type definition, there are examples that slashes are not encoded.

pkg:golang/github.com/gorilla/context@234fd47e07d1004f0aed9c#api

[gitgitwhat]

In the Golang specific PURL type definition, there are examples that slashes are not encoded.

pkg:golang/github.com/gorilla/context@234fd47e07d1004f0aed9c#api

Doesn't mean its right.

I added a bug report for them too (package-url/purl-spec#476).

[ppkarwasz]

In the example you gave::

• The encoded namespace is github.com/gorilla.
• Splitting on / yields two segments: github.com and gorilla.
• After percent-decoding, these segments remain github.com and gorilla, neither containing a /.

This structure adheres to the specification because each segment, when decoded, does not include a /.

In contrast, the following PURL is invalid:

pkg:golang/github.com%2Fgorilla/context@234fd47e07d1004f0aed9c#api

In this case:

• The encoded namespace is github.com%2Fgorilla, which is a single segment.
• Upon percent-decoding, it becomes github.com/gorilla, which contains a /.

This violates the specification, as a decoded namespace segment must not contain a /.

[oliverchang]

This appears to be a problem with the spec.

There's upstream purl discussions around the various issues of encoding Go purls. package-url/purl-spec#338 is an attempt at fixing them by introducing a new type (and it links to relevant issues that motivated it).

Of particular relevance is this comment here: package-url/purl-spec#338 (comment)

Say you have a module with the path host.com/maybeuser/module.
With the current type definition, both pkg:golang/host.com/maybeuser/module and pkg:golang/host.com/maybeuser%2Fmodule, could represent that module.

The reason both are valid here is because namespace itself could have multiple path segments, and it's not well defined for go. Quoting the relevant sections from the PURL spec:

From https://github.com/package-url/purl-spec/blob/main/PURL-SPECIFICATION.rst

namespace:
The optional namespace contains zero or more segments, separated by slash '/'

From https://github.com/package-url/purl-spec/blob/main/PURL-TYPES.rst#golang

The namespace and name must be lowercased.

Which really doesn't specify much around which one is correct (and the lowercasing requirement itself is wrong also).

Since it's probably better to discuss these spec issues in the PURL repo, I'm going to close this issue.