Re: [OE-core] [RFC] Adding PURL identifiers to SPDX 3.0.1 install package elements

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2026-04-08 at 16:19 +0300, Martin von Willebrand via lists.openembedded.org wrote:
> While working with ORT (OSS Review Toolkit) to analyse Yocto-generated 
> SPDX 3.0.1 documents for ongoing vulnerability management and 
> monitoring, I noticed that install package elements 
> (`software_primaryPurpose: install`) carry only a wildcard CPE 
> identifier, e.g.:
> 
> cpe:2.3:*:*:busybox:1.36.1:*:*:*:*:*:*:*
> 
> ORT recently released an SPDX analyzer (since ORT 83.0) targeting Yocto 
> 5.0 generated SPDX 3.0.1 documents, which makes this gap more visible: 
> the analyzer can consume the package graph, but the identifiers 
> available are not sufficient to drive post-release CVE monitoring 
> against external vulnerability databases such as NVD or VulnerableCode, 
> since wildcard CPEs cannot be used directly as query keys.
> 
> If I understand correctly, sbom-cve-check faces the same underlying 
> limitation. In our understanding it would benefit from this change too, 
> though the two approaches are complementary rather than overlapping.
> 
> The upstream download URL for tarball-based packages is available at 
> build time and is already derived from SRC_URI via `fetch_data_to_uri()` 
> in `spdx30_tasks.py`. A PURL constructed from that URL and placed 
> directly as an `externalIdentifier` on the install package element would 
> give downstream consumers a durable, canonical identifier for 
> post-release vulnerability monitoring.
> 
> Before drafting a patch I wanted to ask:
> 
> 1. Is there a specific reason PURL is not currently emitted on install 
> package elements — policy, technical constraint, or simply not yet done?
> 2. Would a contribution adding PURL for example as an 
> `externalIdentifier` on install packages (derived from SRC_URI fetch 
> data) be welcome in OE-Core master?
> 
> Happy to hear comments, and discuss scope and approach before writing code.

I'm not sure this is as simple as it first appears. We support the
notion of "premirrors" and "mirrors", which are searched before and
after the primary SRC_URI. We validate a checksum of the resulting
download to verify we did get what we expected but it doesn't always
come from that SRC_URI but can be cached. I guess we assume you use the
unmodified original SRC_URI?

What happens if there are two items in SRC_URI? If we patch the tarball
with other entries in SRC_URI, is the PURL still valid?

What happens in the cases where the recipe uses git to fetch the
sources instead of a tarball?

Can the external tooling not look at the url data already in the SPDX
output and work out the purls itself if it wants to?

I guess what I'm saying is we're trying to avoid too much "processing"
of the data we put into the SPDX so I'm cautious about duplicating
info. If the purl is always derived from the SRC_URI and we include
that, should we be adding the extra data?

I'm not trying to be negative, I'm just worried about where this might
lead and the corner cases that may be involved.

Coping Joshua who I suspect also may have thoughts on this.

Cheers,

Richard