public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
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



             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