From: Martin von Willebrand <martin.vonwillebrand@doubleopen.io>
To: openembedded-core@lists.openembedded.org
Subject: [RFC] Adding PURL identifiers to SPDX 3.0.1 install package elements
Date: Wed, 8 Apr 2026 16:19:20 +0300 [thread overview]
Message-ID: <e615740d-eff9-4125-a6e6-e6b58ee29225@doubleopen.io> (raw)
Hi all,
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.
Thanks,
Martin von Willebrand
Double Open
--
Double Open Oy
c/o HH Partners, Attorneys-at-law
Eteläesplanadi 22 A
00130 Helsinki, Finland
Registered Office: Helsinki
Trade Register: Finnish Trade Register (PRH)
Business ID: FI33824962
Managing Director: Martin von Willebrand
next reply other threads:[~2026-04-08 13:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 13:19 Martin von Willebrand [this message]
2026-04-08 21:23 ` [OE-core] [RFC] Adding PURL identifiers to SPDX 3.0.1 install package elements Richard Purdie
2026-04-09 8:55 ` Martin von Willebrand
2026-04-09 13:21 ` Joshua Watt
2026-04-10 7:46 ` Martin von Willebrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e615740d-eff9-4125-a6e6-e6b58ee29225@doubleopen.io \
--to=martin.vonwillebrand@doubleopen.io \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox