About purl namespace and version fields for rpm

[WhyJee]

Description

I hit this question when analyzing reports from several tools and comparing the PURL computed by each.
This is more a question rather than an issue.

So for a given image I get the following identification being made on a RedHat UBI based image:

Tool	Package	version	PURL
Syft	openssl-libs	1:1.1.1k-7.el8_6	pkg:rpm/rhel/[email protected]_6
Trivy	openssl-libs	1:1.1.1k-7.el8_6	pkg:rpm/redhat/openssl-libs@1:1.1.1k-7.el8_6
other1	OpenSSL	1.1.1k	pkg:rpm/redhat/[email protected]_6?arch=x86_64&epoch=1
other2	openssl-libs	1.1.1k	pkg:rpm/centos/[email protected]

Other tools (commercial) are just for example. Yes one references a centos in a RedHat Distro.
I'll follow only with Syft as comparison as they are my main tools.

As can be seen between Syft and Trivy the differences are :

• the namespace
• the version

What did you expect to happen?

All tools shall report the same PURL for the same package.

What happened instead?

Trivy is reporting different PURL than Syft (note: the "small" difference has low if no impact on the vulnerability analysis, it is more a SBOM concern).

Output of run with -debug:

(paste your output here)

Output of trivy -v:

using docker image (aquasec/trivy)

Version: 0.35.0

Additional details (base image name, container registry info...):

Namespace question

Comparing rpm to other packager (maven, ...) there isn't really an entity describing the "namespace".
Thus finding the right namespace is left to the SBOM producer... Leaving a decision open leads to inconsistent results.
I initially tought that Trivy naming was better as I would rather have the provider (or packager) being the namespace: hence redhat sounds more appropriate.

I made a rapid study of the information provided by various OS and the computed purl for the same package.
Results are in the below table (purl for both tools, then some info extracted from the packages rpm -qi, and information for /etc/os-release file).

Syft	Trivy	Name	Epoch	Version	Release	Architecture:	Packager	CPE_NAME	ID	NAME
pkg:rpm/almalinux/[email protected]_0?arch=x86_64&epoch=1&upstream=openssl-3.0.1-43.el9_0.src.rpm&distro=almalinux-9.1	pkg:rpm/alma/openssl-libs@1:3.0.1-43.el9_0?arch=x86_64&distro=alma-9.1	openssl-libs	1	3.0.1	43.el9_0	x86_64	AlmaLinux Packaging Team	cpe:/o:almalinux:almalinux:9::baseos	almalinux	AlmaLinux
pkg:rpm/fedora/[email protected]?arch=x86_64&epoch=1&upstream=openssl-3.0.5-3.fc37.src.rpm&distro=fedora-37	pkg:rpm/fedora/openssl-libs@1:3.0.5-3.fc37?arch=x86_64&distro=fedora-37	openssl-libs	1	3.0.5	3.fc37	x86_64	Fedora Project	cpe:/o:fedoraproject:fedora:37	fedora	Fedora Linux
pkg:rpm/rhel/[email protected]_0?arch=x86_64&epoch=1&upstream=openssl-3.0.1-43.el9_0.src.rpm&distro=rhel-9.1	pkg:rpm/redhat/openssl-libs@1:3.0.1-43.el9_0?arch=x86_64&distro=redhat-9.1	openssl-libs	1	3.0.1	43.el9_0	x86_64	Red Hat, Inc.	cpe:/o:redhat:enterprise_linux:9::baseos	rhel	Red Hat Enterprise Linux
pkg:rpm/rocky/[email protected]_0?arch=x86_64&epoch=1&upstream=openssl-3.0.1-43.el9_0.src.rpm&distro=rocky-9.1	pkg:rpm/rocky/openssl-libs@1:3.0.1-43.el9_0?arch=x86_64&distro=rocky-9.1	openssl-libs	1	3.0.1	43.el9_0	x86_64	Rocky Linux Build System (Peridot)	cpe:/o:rocky:rocky:9::baseos	rocky	Rocky Linux
pkg:deb/debian/[email protected]+deb11u3?arch=amd64&upstream=openssl&distro=debian-11	pkg:deb/debian/[email protected]+deb11u3?distro=debian-11.6	libssl1.1		1.1.1n-0+deb11u3			Debian OpenSSL Team		debian	Debian GNU/Linux
pkg:deb/ubuntu/[email protected]?arch=amd64&upstream=openssl&distro=ubuntu-22.04	pkg:deb/ubuntu/[email protected]?distro=ubuntu-22.04	libssl3		3.0.2-0ubuntu1.7		amd64	Ubuntu Developers		ubuntu	Ubuntu

This raises indeed a question :

• my assumption is that Syft relies indeed on os-release ID variable only
• some OS do also provide a CPE_NAME and probably so does Trivy -- though I am not sure as there is something wrong in the namespace for Almalinux (don't know where alma is coming from).

1. Should CPE_NAME have precedence and be used as source if provided ?
2. Shall the SBOM tools (Trivy/Syft and other) raise a warning in case both ID and CPE_NAME are provided and are inconsistent ? Only RedHat UBI is in this case for the moment.

The 1st question is more a global agreement (let say) on which information is expected in order to create the "most" reliable SBOM.

The 2nd one is more for the user of such tool to be alerted when something is detected. It could help greatly to understand the differences we may have in the end.

Version question

This question indeed relates to package-url/purl-spec#69
Again I thought initially that handling Epoch as part of version was better. But reading the thread led me also to the opposite.

So for this part it is more a bug of Trivy (to me now -- thinking differently previously) which shall probably fix and put the epoch as a qualifier and not part of the version number.

[github-actions]

This issue is stale because it has been labeled with inactivity.

[knqyf263]

This question indeed relates to package-url/purl-spec#69

Hmm. I still prefer embedding epochs into versions as it is how to show versions in Red Hat-based distributions. But we can change it if they agree on that.
@DmitriyLewen Could you work on that? Note that it affects both marshaling and unmarshaling.

[knqyf263]

We changed it, but in the document, deb embeds epoch into the version... it is confusing.
package-url/purl-spec#151