F45 Change Proposal: Adopt PURL Metadata (system-wide)

[decathorpe (Fabio Valentini)]

Adopt PURL Metadata

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

Summary

Package metadata will be enhanced with standardized identifiers based on the PURL (Package-URL) specification with the goal of simplifying the mapping between upstream projects and Fedora packages.

Owner

• Name: Fabio Valentini
• Email: decathorpe AT gmail DOT com

Detailed Description

The Package-URL (PURL) standard privides a “standardized URL-based syntax that uniquely identifies software packages, independent of their ecosystem or distribution channel” (from the project README).

It is being adopted by many projects across the ecosystem - including the CycloneDX and SPDX SBOM formats, various software vulnerability databases, and the CVE Record Format (added as an optional field in version 5.2.0).

By adding standardized identifiers to Fedora packages, it becomes easier to map upstream projects to packages - for example, to identify which packages are affected by a security vulnerability.

The PURL standard defines this URL scheme:

scheme:type/namespace/name@version?qualifiers#subpath

For many “types” of packages, RPM generators already add virtual “Provides” for packages (for example, crate(libc) = 0.2.186 or rubygem(kramdown) = 2.5.2) - but this is a downstream-specific format.

The RPM generators for package ecosystems that are supported by the PURL specification will be extended to also add metadata in the PURL format (like purl(pkg:cargo/libc@0.2.186) or purl(pkg:gem/kramdown@2.5.2). The next package rebuild after the necessary RPM generator changes land will include this new metadata.

This could then be extended to bundled(...) virtual Provides as well, which are currently even more heterogeneous since there’s no standardized format for them in Fedora, and could potentially replace existing non-standard bundled(...) Provides in many cases.

The initial target of this Change is to start adding virtual Provides in PURL format for packages in the following language ecosystems:

• “cargo” (Rust crates)
• “cpan” (Perl packages)
• “cran” (R packages)
• “gem” (RubyGems)
• “hackage” (Haskell packages)
• “maven” (Java packages)
• “npm” (NodeJS / NPM packages)
• “opam” (OCaml packages)
• “pypi” (Python packages from PyPI)

Currently, the only supported PURL “type” for C/C++ projects appears to be “conan”, which is not useful in this context, but new types are getting added to the spec regularly.

This will likely be an iterative process and the necessary changes might not happen for all language ecosystems in just one release cycle.

Feedback

TBD

Benefit to Fedora

This Change aims at making it easier and more reliable to identify which packages contain code from what projects. This allows for more reliable identification of packages affected by security vulnerabilities. Additionally, this metadata might be interesting for generating SBOMs for content included in (container) images.

Scope

• Proposal owners:

Implement adaptations for RPM generators to emit the new virtual Provides.

• Other developers:

Review and apply changes to RPM generators and other packages, where necessary.

• Release engineering: #13347

This Change requires a mass rebuild for affected packages to get the new metadata.

• Policies and guidelines:

Update Packaging Guidelines to recommend attaching metadata in PURL format to packages, where possible (to be determined if this also applies to bundled(...) Provides).

FPC Ticket: Making sure you're not a bot!

• Trademark approval:

N/A (not needed for this Change)

• Alignment with the Fedora Strategy:

N/A (not needed for this Change)

Upgrade/compatibility impact

This Change only provides additional package metadata and should have no effect on upgrades or backwards compatibility.

Early Testing (Optional)

N/A

Do you require ‘QA Blueprint’ support? N

How To Test

Packages that are rebuilt after these changes land should have additional RPM Provides. This can be verified by running something like dnf --provides perl-Errno and looking for an entry in the purl(...) format.

User Experience

No direct impact to user experience is expected.

However, easier identification of packages that are affected by security vulnerabilities should enable fixes for these issues to happen more reliably (and potentially faster).

Dependencies

Direct dependencies:

• Packages that contain the RPM generator implementations

Indirect dependencies:

• Everything.

Contingency Plan

This is a purely additive and / or metadata-only Change. If the necessary changes are not finished by the mass rebuild date, they can still land at a later point in time, but will only affect a subset of packages. For best results, the changes should land before the Mass Rebuild, but this is not strictly necessary.

• Contingency mechanism:

Changes do not need to be reverted. If changes are not complete before the mass rebuild, it might need to be documented that the Change will only be partially implemented for the targeted Fedora release, and that only the next release will benefit fully.

• Contingency deadline:

Mass rebuild.

• Blocks release?

No.

Documentation

• Package-URL Homepage
• PURL specification
• List of valid package types

Release Notes

Last edited by @amoloney 2026-05-27T09:03:45Z

Last edited by @amoloney 2026-05-27T09:03:45Z

[system]

How do you feel about the proposal as written?

• Strongly in favor
• In favor, with reservations
• Neutral
• Opposed, but could be convinced
• Strongly opposed

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

[kevin (Kevin Fenzi)]

This is great, and I really hope it will help improve security reporting in particular.

[decathorpe (Fabio Valentini)]

One thing that I wasn’t sure about is whether all the characters that can appear in PURLs are OK to appear in virtual Provides.

The RPM docs at https://rpm.org/docs/6.0.x/manual/tags.html say that Provides headers are just of type string - which are nul-terminated byte arrays (within the RPM header length limit) and it doesn’t mention any other restrictions, so this should be fine?

[cssushiman (Sushi Man of Computer Science)]

I’m not a packager, so I have limited knowledge on this subject.

How does this compare and contrast to the current packaging system? I think it is necessary to go more in depth regarding what changes are actually being made, and most importantly, to answer the question:

Is this necessary?

I know I’m being a bit harsh here, but I think it is necessary for a proper debate. Do packagers like @ngompa have a hard time keeping track of security vulnerabilities?

How exactly does this proposal allow for more reliable identification of packages affected by security vulnerabilities? Is there some kind of functional system for that, or is it something that still has to be manually done?

Proposing metadata changes useful for a system, without a functional long-term plan for developing an actual system to be put in place, seems to be a bit of a stretch, in my opinion.

You should propose this packaging system as well. Otherwise, the metadata is useless.

[cssushiman (Sushi Man of Computer Science)]

I’ve read further into the specification, and I’m not even sure if it is finished as of yet. Who suggested this to you?

I also notice this strange “non-goals” language here: purl-spec/docs/decisions/decision_doc-template.md at main · package-url/purl-spec · GitHub

I’m not sure if this should be trusted or not. I would like to know the reasoning behind suggesting a metadata specification that isn’t even formalized as of date.

[cssushiman (Sushi Man of Computer Science)]

I must correct myself here, the PURL standard is in fact ECMA-427, and is very much formalized:

ECMA-427 - Ecma International

So, what system/logic do you plan on utilizing? Metadata is useless without one, after all.

[cssushiman (Sushi Man of Computer Science)]

No answer? How strange, considering everyone appears to be voting this in favor blindly. There are logistics here that are not being considered.

It’s useless to specify the luggage you will carry, if you don’t have a route to carry that luggage on. IMO the ordering of priorities is way off here.

[lecris (Cristian Le)]

The change proposal is much more technically narrow then what you might be assuming. It is not about making any interactions with purl, just to redefine a format inside the spec/rpm metadata (that is mostly a free-form text) to a more standardized format

[cssushiman (Sushi Man of Computer Science)]

If its such a simple change, then why does this proposal have grand language such as:

@decathorpe

Benefit to Fedora

This Change aims at making it easier and more reliable to identify which packages contain code from what projects. This allows for more reliable identification of packages affected by security vulnerabilities. Additionally, this metadata might be interesting for generating SBOMs for content included in (container) images.

I’m confused here. The OP could’ve just stated that they were simply changing the current metadata tagging to a more standardized format. There’s no need for the quoted paragraph above, unless the change is significant.

If what you said is true, the way OP has framed this proposal is confusing, and unnecessary.

It would’ve been sufficient to state something along the lines of:

Proposed change

• Make [SMALL CHANGE X] to current packaging metadata format, so that it may conform to the ECMA-427 standard.

Using confusing and verbose language, doesn’t help the OP’s case. At the very least, if the OP simply said the statement above, than there would be less confusion about what the initiative is trying to accomplish.

In order to use a set of metadata for the purpose of accomplishing more reliable identification of packages, a system that takes in this metadata, and reasons about it, will need to be created.

Do you understand what this change is implying?

[decathorpe (Fabio Valentini)]

The Red Hat team responsible for tracking security vulnerabilities already uses PURL metadata internally. Adopting it as a standardized metadata format across Fedora (where possible) would help with tracking which Fedora packages are affected by which vulnerabilities, and that tooling already exists (at least to some degree, from what I understand).

[cssushiman (Sushi Man of Computer Science)]

You should’ve stated that initially. If RHEL already has a system, than that means Fedora can adopt a similar system later on.

Something along the lines of:

This Change aims at making it easier and more reliable to identify which packages contain code from what projects. Red Hat uses this specification with their own security teams/systems, in order to find packages with security vulnerabilities. Additionally, this metadata might be interesting for generating SBOMs for content included in (container) images.

Likewise, I would’ve also proposed this new system inside of the same proposal with the stated changes. These things increase clarity with the community, so that they understand what’s going on. If you are upfront about what you’re trying to accomplish, you will gain more trust within the community.

[cssushiman (Sushi Man of Computer Science)]

(I should probably add that I don’t expect Fedora to have a new security team/system, that would probably be too much of an ask).

Knowing that this is probably meant to help out the RHEL security team (I’m still not 100% sure that this is the goal), is probably enough for most community members and the council to accept the proposal.

[lecris (Cristian Le)]

Anyway main notes I have on this proposal:

• it should clarify what is to be done with the old formats. If they would be phased out, provided along side, or generated automatically from the purl provides
• how will the version format inside the purl be handled, and how would it play on the provide’s version, and its comparison operations

[kevin (Kevin Fenzi)]

Keep in mind that this is a asynchronous communications medium.
You should not expect people to instantly answer you. Respectfully ask
your questions and folks will answer when they have time/desire.

You may want to consider waiting for answers before asking more
quesitons as well.

[computersavvy (Jeff V)]

I am placing this topic on slow mode.
One user has made as many as 5 different posts in less than an hour and this is inappropriate.
Please make one post that covers all the appropriate details so others have time to read and respond to each discrete post.

[decathorpe (Fabio Valentini)]

@lecris

it should clarify what is to be done with the old formats. If they would be phased out, provided along side, or generated automatically from the purl provides

To quote the Change Proposal:

@decathorpe

The RPM generators for package ecosystems that are supported by the PURL specification will be extended to also add metadata in the PURL format

@decathorpe

This Change only provides additional package metadata

@decathorpe

This is a purely additive and / or metadata-only Change.

Please let me know if this is not sufficiently clear.

(To make it even more explit: This is only about adding metadata. No Changes to existing, generated Provides are being proposed here.)

@lecris

how will the version format inside the purl be handled, and how would it play on the provide’s version, and its comparison operations

This was, to some degree, covered by discussion with the Packaging Committee (which I filed a ticket with as required for Changes that touch the Packaging Guidelines): https://forge.fedoraproject.org/packaging/guidelines/issues/1536#issuecomment-711587

To summarize: I had considered whether moving the “version” component out of the PURL string and into the RPM Provides “version” component, but decided against it, because 1) it mixes concepts of PURL and RPM within one string, and 2) not all upstream versions are representable as RPM “version” strings without doing some sort of (potentially lossy) normalization.

[computersavvy (Jeff V)]

@cssushiman

No answer? How strange, considering everyone appears to be voting this in favor blindly. There are logistics here that are not being considered.

Everyone who is on this forum does so voluntarily. Expecting users to answer multiple different posts in a very short time period is inappropriate.

Assuming what other users are considering and how they feel on a topic is also inappropriate.

Please control your posts and discuss facts. Do not make accusations such as the above. Consider this a friendly warning and continued aggressive posts may lead to further moderator action.

[cssushiman (Sushi Man of Computer Science)]

@computersavvy

@cssushiman

No answer? How strange, considering everyone appears to be voting this in favor blindly. There are logistics here that are not being considered.

Everyone who is on this forum does so voluntarily. Expecting users to answer multiple different posts in a very short time period is inappropriate.

Assuming what other users are considering and how they feel on a topic is also inappropriate.

Please control your posts and discuss facts. Do not make accusations such as the above. Consider this a friendly warning and continued aggressive posts may lead to further moderator action.

I apologize for over posting, I didn’t intend to spam the forum. I know it may be somewhat unbecoming of me to use the tone that I have, so let me explain myself.

The implicitly accusatory language was a strategy I imposed. I’m not sure if it worked – it may very well have. Making a discussion somewhat more heated, will likely increase the “velocity” of the discussion, so to speak. If the discussion is heated, people are also more likely to seek answers to any concerns that they may have, and actually post them on the forum.

Since I wasn’t actually accusing anyone of anything, I don’t believe this strategy goes fully against the guidelines. Feel free to disagree, and please take moderation action, if you believe I was acting in bad faith.

[computersavvy (Jeff V)]

@cssushiman

I wasn’t actually accusing anyone of anything, I don’t believe this strategy goes fully against the guidelines

There are logistics here that are not being considered is an accusation that others are not considering everything necessary and is inappropriate.
Similarly everyone appears to be voting this in favor blindly does the same.

Since you are not part of the council nor fesco, and in fact only recently joined this forum, it is inappropriate to make such broad and accusatory statements without facts to back up your opinions.

While I rejected the flag on the post I quoted above, this is the second flag you have received for inappropriate comments in this specific topic.

I ask that you temper your discussion and discuss only facts and not impugn others actions with assumptions. You have been given several links related to the topic yet seem to not be willing to accept that others are operating in good faith and with consensus for actions taken.