Consider adding PURL

[Foxboron]

Package URL is a SPDX specification for identifying packages and upstream releases. I'm not really sure if it replaces CPE completely, as CPE is capable of generally describing software artifacts. But it would probably be a good idea for package-notes to support PURL.

https://github.com/package-url/purl-spec

[gregkh]

As purl does not support self-hosted projects (i.e. ones that do NOT just release on github or gitlab), how exactly would purl work here?

What exactly would the purl reference be?

Note, I have brought this up many times in the past to the purl developers, without a solid answer, see the open issues on the purl spec for places where this is still not resolved.

[Foxboron]

As purl does not support self-hosted projects (i.e. ones that do NOT just release on github or gitlab), how exactly would purl work here?
What exactly would the purl reference be?

So I think this depends a little bit on the given type? For apk/alpm/deb/rpm, we have the the namespace which denotes the distro.

Example: pkg:alpm/<namespace>/<name>@<version>?<qualifiers>#<subpath>

I think it's completely reasonable to have the namespace be local for self-built packages. But considering this is going to run through distro tooling, it will be set as archlinux for properly built packages.

Generally I think purl can be an optional field as CPE and PURL almost matches in usage. I was looking at this because CVE metadata has started including PURL identifiers in the metadata.

[gregkh]

Sorry, I don't mean for distro packages, I mean for projects that host the source themselves. You don't assign a CVE to a distro package, it is assigned to the project that released the source (perl.org, python.org, libreoffice, kde, kernel.org, gnome.org, etc.)

And yes, CVE metadata can start using purl in the new schema that will be released soon, and for many cases it is better than CPE, but it still does not work properly for all projects as pointed out here, so I don't see how it would be needed for systemd yet as systemd is not a CNA.

[Foxboron]

Sorry, I don't mean for distro packages, I mean for projects that host the source themselves. You don't assign a CVE to a distro package, it is assigned to the project that released the source (perl.org, python.org, libreoffice, kde, kernel.org, gnome.org, etc.)

Right, not self-created software packages, but upstream not tied to an existing ecosystem.

Doesn't this attempt to solve this particular problem? package-url/purl-spec#516

And generally, is the lack of this sort of support really a problem for the package-notes? From what I can tell this is largely being used by package managers so being unable to describe self-built releases doesn't seem super important to me?

[gregkh]

Upstream is what uses PURL in CVE reports, as upstream generates CVEs, that's not done by distros for individual packages.

And yes, that is a proposed solution, but purl has not implemented that yet, so we can't use it.

purl describes the package, not an individual binary, so yes, for package-notes it might make sense, but I can't recommend it being used by anyone until it actually will work for the majority of the programs you are going to use it for :)

[keszybz]

I think we could add purl… No reason really not to, as long as it's an optional field. If it doesn't work for some case, then just omit it.