From Fedora Project Wiki

Adopt PURL Metadata

Summary

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

Owner

Current status



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 virtual Provides for these 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.

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: https://forge.fedoraproject.org/packaging/guidelines/issues/1536

  • 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

Release Notes