purl-spec

Oh no, this is already the second "purl" Name collision... https://github.com/package-url/purl-spec https://en.wikipedia.org/wiki/Persistent_uniform_resource_lo... These things are always a massive source of confusion...

For "generic" interface-based dependencies, that's tougher. This is a problem with a few ecosystems. OTH rpms, debs and Java OSGI... and may be a few more. We need to survey these to find if we can solve that and if this is a PURL problem at all. Can I rope you in and interest you in filing an issue in the spec so we can move the discussion there? :P This would be great. https://github.com/package-url/purl-spec/issues/

We have a standard checksum "qualifier" at https://github.com/package-url/purl-spec/blob/main/PURL-SPEC... ... that would be the "hash" ... would this work?

I believe i was thinking of the comments at https://github.com/package-url/purl-spec/issues/59 but I see you've already replied there.

Yeah, the CPE idea of a vendor for an open source package does not compute too well! FWIW, PURL came about as I could NOT put my mind around CPEs when I was scanning for package and deps with scancode and could not find any easy way to go from that to looking up a vulnerability/CVE in the NVD, as it was all guesswork and manual. So we started instead to put the vuln data in our own db, keyed by something that would be easy to relate from the scans. This eventually became PURL This is all tracked in these places: - The original issue: https://github.com/aboutcode-org/scancode-toolkit/issues/805 - The initial pull request with many comments: https://github.com/package-url/purl-spec/pull/1

Note that there should be a gitlab type as it is planned for: https://github.com/package-url/purl-spec/blob/a90ee02679afc3... gitlab and github do provide package-like discoverability. Do you have a pointer that says a github package is a mistake?

We maintain the spec at https://github.com/package-url/purl-spec And the new thing, working towards making it a real standard with Ecma https://tc54.org/purl/ ... :)

Encode the slash as explained in the clarified spec https://github.com/package-url/purl-spec/pull/453 :) We are working on further clarifying Golang which a bit problematic: there is really no name or namespace in Go, just a path, and it is not possible at scale to tell when a Go module stops and when a Go package starts just by looking at the path... this is going to be clarified after the merge of the PR 453.

The standard supports a repository_url "qualifier" (query parameter)[0], which can be used to override whatever the default registry is (which, for Docker, is hub.docker.com[1]). [0]: https://github.com/package-url/purl-spec/blob/main/PURL-SPEC... [1]: https://github.com/package-url/purl-spec/blob/main/PURL-TYPE...

Another name conflict is with https://github.com/package-url/purl-spec - which is used for software identification (e.g., see the https://www.cisa.gov/sites/default/files/2023-10/Software-Id... report).

This is good take on the topic focusing on intrinsic identifiers. Guix has their own approach but the article also mentions SWHID[1] and OmniBOR[2] which are both contenders to fill that space. SWHID is on its way to become an ISO standard[3]. OmniBOR is quite new but a highly interesting approach. Because it does not directly solve any problems for Guix, it's fair enough that they do not talk about much about extrinsic identifiers except to rightfully dismiss CPE as "showing its limits", which is put mildly. I think there is need for an extrinsic identifier standard beyond CPEs (in addition to intrinsic identifiers). While intrinsic identifiers allow us to pinpoint artifacts exactly sometimes this is not what we want. Sometimes we deliberately want to talk about sets of artifacts together, like variants or versions of an artifact. One co