"Shaka, when the walls fell."
>There's even a generic type as a catch-all for things that don't fit an existing ecosystem (for example, a proprietary or legacy component) or for ecosystems that build custom distributions, such as yocto or buildroot. We should note, however, that SBOM and software composition analysis tools vary widely in their ability to understand generic PURLs, so we do recommend you talk to your current (or prospective) vendor if this is an important feature for you.
[0]: https://github.com/package-url/purl-spec/blob/main/PURL-SPEC...
[1]: https://github.com/package-url/purl-spec/blob/main/PURL-TYPE...
such as approximately everything in golang, which very often matches e.g. "github.com/*" as a package name?
Do would PURL suggest that "github.com/foobar/go-whatnot" should be parsed as namespace="github.com" (odd) and package name "foobar/go-whatnot" (since there aren't any more slashes in the blessed separators)?
The distinction doesn't really seem to matter much between namespace and name in all honestly.
https://en.wikipedia.org/wiki/Percent-encoding#:~:text=accor...
pkg:github.com%2Ffoobar/go-whatnotIt could be instead:
pkg:golang/github.com%2Ffoobar%2Fgo-whatnotWe 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.
- in most cases, no guesses needed - you can use it in Cyclone, SPDX, and CSAF and still talk about the same package even if the format varies - CVE.org is considering it as an addition on the same footing as CPE - there a good bunch of databases that "speak" PURL, like Google OSV, Sonatype OSS Index, Deps.dev, and AboutCode's PurlDB and VulnerableCode (disclosure: I am a lead maintainer for AboutCode FOSS projects) - most scanners speak PURL too.
Note that same scanners and tools speak not exactly PURL but some "PURLish" dialect and we have a project to help streamline that and lift up the whole ecosystem of PURL users with https://nlnet.nl/project/purlvalidator/
For libraries that are hosted on `github`, there's at least the github type.
But there is no official `gitlab` or `git` type, and i've read comments that even the `github` type is considered a mistake.
One example of such a library could be a Qt or KDE / Plasma library.
They are hosted on their own forges, https://code.qt.io/ and https://invent.kde.org respectively.
So to the more knowledgeable people out there, what is the PURL way of identifying a C++ library like that?
Is `generic` type + vcs_url qualifier really the only way?
Right now it seems impossible to track vulnerabilities for such libraries with OSS / open tools, because none of the open tools or databases support a custom type or registry or ecosystem.
For example none of services here support some custom C++ ecosystem (putting aside conan):
https://docs.dependencytrack.org/analysis-types/known-vulner...
gitlab and github do provide package-like discoverability. Do you have a pointer that says a github package is a mistake?
> So to the more knowledgeable people out there, what is the PURL way of identifying a C++ library like that?
That's a blind spot. This is a real problem for every as you rightfully explained.
So I have been thinking a lot about how to track C/C++ native libraries, and I have been working on a plan to deal with this.
You can read a summary there (that I just posted to supply this discussion!) - https://github.com/aboutcode-org/www.aboutcode.org/issues/30
And this comment links to more detailed work-in-progress planning doc: - https://github.com/aboutcode-org/www.aboutcode.org/issues/30...
If you want to chip in and help, this would be awesome.
And IMHO, aligned with your thinking this should not be tied to a build system or a for-profit operation like conan.io, or a linux distro, or for that matter a specific build tool or approach as they are so many, and be self-hosted, easy to sync, and simple to store in a git repo.
https://cps-org.github.io/cps/overview.html
I’m not sure how I can help, but I’m open for discussion, because the company i work for is also interested in how to handle this well for our products.
For Java and interpreted language packages the "build" configuration is less important or non-existent. For compiled packages the build environment is important.
It seems the only way is to use a custom namespace and abuse the qualifiers but then you've got a non-canonical PURL and its utility in things like SBOMs is limited.
Say I rebuild a Debian package with some new build options.
Is this a the same or a new package? I'd say a new one.
Is this the same name? I'd say a new one.
Is this distributed by Debian? Nope, so this comes from another repo and pool, right?
The idea with PURL is to have simple and short PURLs for the common case, and make it possible to handle less common cases. Rebuilding a package and sharing it on another repo would be a less common case to me? WDYT?
What’s the point of com.something.other? Why are we using dot notation when everything else is kebab case?
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
$ mpm install pkg:npm/left-pad@1.2.3
Other commands allows you to export the SBOM of all packages installed on your machine. More info at: https://github.com/kdeldycke/meta-package-manager
like if I'm scanning an arbitrary linux system, and I see `libssl.so.1` but I don't see it in the local package manager, I don't really have an option other than to call it generic.
I do agree that "generic" seems to be WAY overused though. Maybe tools that report on SBOMs, like FOSSA or whatever, should emit warnings to users about "generic" PURLs.
This then gives tooling a path to prompt users to provide missing context needed to fully qualify the PURL
Can you tell a bit more? Not sure I get what you meant
That's the problem: there is no metadata with or in libssl.so.1 that I can reliably use to tell what this is
Eventually I can see a solution made of
1. create the metadata, say a simple YAMl or deb822 key-valud pair file that can then be included upstream or as an overlay 2. define a simple spec for binary formats to include a PURL (say in an ELF section or a WinPE string or sorts, where many of these are already stored) 3. create content-based tools like we have in PurlDB to match code, but may be more like a bunch of generated yara rules that would match symbols and strings from source to binaries and can recognize that libssl.so.1 is from OpenSSL 1.1.1g.
Eventually, let's fix this first for C/C++:
https://github.com/aboutcode-org/www.aboutcode.org/issues/30
And based on that approach we can either: 1. create new, sensible types as needed 2. and/or maintain a last resort open registry of generic types at least so we get some sanity in the process.
- The cryptographic hash is not included. (They do mention security, a hash and/or public keys would be helpful for security. It would also be helpful for identification if names are reused for unrelated reasons.)
- There is not a distinction between interfaces and implementations (which in some cases you might care about, although not always).
- They do not mention examples of what qualifiers are possible for some package types.
- an optional(?) hash parameter
- a way to say you depend on a thing for which there are multiple implementations and not specify which implementation
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.
emddudley•23h ago
https://purl.archive.org/
CaliforniaKarl•23h ago
layer8•22h ago
I wonder if Yarn will support PURLs. ;)
01HNNWZ0MV43FF•22h ago
pombreda•22h ago
And the new thing, working towards making it a real standard with Ecma https://tc54.org/purl/ ... :)
ttepasse•22h ago
pombreda•21h ago