Define PURL types for software that is not covered by a package manager

[mjherzog]

This is a summary issue for discussion of multiple approaches to defining PURL types for software that is not covered/distributed by a package manager system like npm or PyPI or by a Linux distro like Debian or Red Hat. From discussions to-date there seem to be two major areas of interest:

FOSS where the software is public
In this case the challenge is to define structures that emulate a package manager. The most commonly discussed example is C/C++ projects that do not use a package manager like Chocolatey or Conan because those package manager effectively require that you also use their build systems. There is currently a 'generic' PURL type as a backstop but it depends on qualifiers" like 'download_url' or 'vcs_url to provide specific information.

There is a new purl-registry project that proposes "a public, shared, open registry of Package-URLs for packages that do not live in a structured ecosystem and therefore may not have a PURL." This project is in a very early pilot phase, but it does offer some examples of YAML files for kitware, linux, openssl and zlib. See the OVERVIEW for an explanation of the proposed approach. The project goals are:

1. Design and propose a PURL type for C/C++ packages using PURL, as part of the PURL specification.
2. Create an open reference catalog of C/C++ packages, keyed by the cpp PURL type, focusing on common packages.
3. Enable content-based discovery and identification of C/C++ packages, supported by the PURL catalog.
4. Extend the ABOUT file data format as the “missing” metadata manifest for C/C++ packages.
5. Create an open mapping between CVEs and C/C++ PURLs to enable known vulnerability lookups using C/C++ PURLs in the vulnerability database.

Proprietary software where the software is not public
In this case the challenges are to define structures that emulate a package manager and doing so in a way that enable proprietary software suppliers or internal IT organizations to create a PURL registry without making their product packages public. The primary proposal for this use case is:

• New PURL type for non-packaged software #516

The proposed approach introduce aa new PURL type: 'scid' as an acronym for Software Component Identification, pronounced /skɪd/.

This PURL type is intended to cover:

• Commercial and proprietary software (e.g., Acme Database Server)
• Standalone open source projects (e.g., the Linux Kernel)
• Internally developed applications that do not belong to a recognized package ecosystem
• Binary-only or installable software where no manifest-based or registry-driven packaging exists

The purl-registry project (above) provides a different potential solution for "Standalone open source projects", but it is not intended to cover the other use cases.

[oej]

I think there has to be a separation between C/C++ libraries and "products". Instead of a registry, the PURL should be based on a domain name for those that have a domain. For those that haven't a shared DNS domain could be used and package names could be reserved as subdomains if needed. This needs further thinking.

[mjherzog]

The use of domain names is a key point for the SCID proposal. My concern is that domain names are not immutable over time particularly for smaller organizations/projects. I suppose the domain name approach "outsources" the registration to the Internet but I am not convinced that is ultimately simpler or better.

[oej]

You will make life much better by using another organisations name space, with conflict resolution and much more. We may want to support organisations with no domain or an unstable domain, but in that case the name we assign should be a random identifier to avoid getting into that mess. Or a very clear and rock hard policy with first come, first serve policy. I would say something like identifier.purlregistry.org in that case.

[oej]

Hmm. What if a project that have an assigned identifier in a purl registry forks - who decides whom that will "own" the existing identifier... Just a thought.

[msymons]

It's not mentioned above, but would not one benefit of a registry approach be similar to one benefit claimed for the CBOM registry introduced in CycloneDX 1.7? ie making it possible to update the registry independent of the purl spec itself?

https://cyclonedx.org/registry/cryptography/

[mjherzog]

@msymons Yes

[mjherzog]

@msymons A registry would be independent from the purl-spec itself and the model of the CBOM CDX registry could be a good model.

[mjherzog]

This article from Andrew Nesbitt does a good job of ttps://nesbitt.io/2026/02/14/package-management-namespaces.html provides very good background on the challenges of using namespace and also domain names. No solution but a good summary of the challenges for us to mind.