A plan for a C/C++ registry of package infos and vulns, keyed by PURL

[pombredanne]

The whole internet and most devices run on C/C++ code. There are many build and packaging systems for C/C++ but no common registry making it difficult to discover, catalog and identify C/C++ packages used in products, devices and apps.

Hence the idea of a C/C++ package metadata registry to help resolve this problem:

• Use Package-URL (PURL) to create an open and distributed registry of C/C++ packages keyed by PURL, with associated metadata, but neutral towards any build system.

• Maintain open source tools to discover and detect C/C++ code commonly vendored and patched in software codebases

• Establish a database of known security vulnerabilities that affect these C/C++ packages, also keyed by these PURL

A C/C++ Package Registry would enable C/C++ software teams to more efficiently and reliably manage and automate their C/C++ software supply chain and vulnerability management operations.

This would help with security operations and vulnerability using open data and open code.

[pombredanne]

See a planning document for more details
https://docs.google.com/document/d/112Jbpoc-yXMmsYUOSFyAgqglcTYjKS7F/edit?usp=sharing&ouid=106671785665329282775&rtpof=true&sd=true

[alcroito]

Hi!

I think your proposal is great, and would help other tooling and projects improve their security and supply chain tracking.

Some comments that come to mind.

1. I suggest contributing the package metadata to the CPS format, instead of the ABOUT one.

The format is driven by Kitware, the developers of cmake, and thus if it’s contributed to them, a big chunk of the cpp ecosystem would get buy-in just because of the inertia of using cmake, and getting it for free with the tool.

I'm sure they'd be open to collaboration on that front.

https://cps-org.github.io/cps/overview.html

2. I'm wondering if the proposed type should really be called cpp, rather than something like native (bikeshedding allowed).

Aside from C and C++, native libraries might be using a flavor of Assembly language.

And there are other system languages that target native formats like Windows PE, Apple MachO, Linux ELF, etc.
Languages like rust and zig might have their own curated registries, but they can also be used without the respective dependencies, and still compile to a native library.

3. I wonder what would be the canonical way to identify vendored libraries which are also patched.
   You mention this in the doc, but I'm not sure if there's a proposed solution.

For example if my project embeds zlib, and also has patches on top, I would expect my project's SBOM or the respective package metadata files to reference two different PURLs: one for the pristine upstream version, and one specific for my project.

That way vulnerability tracking tools could differentiate and report vulnerabilities that are upstream, or that are specific to my vendored copy of the library.

4. The document mentions creating a centralised catalog of packages, but I'm wondering if it might be easier as an intermediate step to offer some kind of decentralised approach.

Each big project has their own infrastructure: VCS forge, CI, canonical homepage / portal: eg, ffmpeg, OpenCV, llvm, etc.

Having a way to identify those packages via a PURL that somehow references their canonical homepage, and which they would be in control of seems like a desirable choice, because the C++ ecosystem has a notorious NIH syndrome, or rather not-controlled-by-us syndrome.

Just as a disclaimer, my main motivation to research the options here are for the Qt project: https://contribute.qt-project.org/

The Qt framework build system has recently started producing its own SBOMs (SPDX), which track dependencies on third parties and also Qt-specific libraries.

The overall goal here is having a way to annotate these libraries with relevant PURLs, feed the SBOMs to tools which can then track vulnerabilities in each component.

At that moment, any component that is not tracked on github, is annotated with generic type PURLs, with subpaths pointing to vcs subdirectories where each component lives.

[pombredanne]

@alcroito Thank you ++. Cps looks great. @bretbrownjr I was referred to you by a buddy, and I reckon the topic of C/C++ package metadata looks dear to you including cps based on your GH profile pins.

I would be much interested on your take on the idea! (See also the more detailed Google doc at

#120 (comment)

)

[darakian]

I think we should start by trying to construct a clearer problem statement. There are a number of ways developers can can ingest c/c++ code and as I believe has been discussed here and elsewhere the vendoring approach seems to be the most common. Is that the user base we want to serve with this version type? Is that one of N user personas to serve? If one of N would it make sense to break out the use cases? I know source code is often available in rpm/deb format in the various linux distros as well and given that rpms and debs already have purl types I would suggest that those at least are out of scope for this new type, but iterating use cases is step one I think.

In the vendored code use case I've seen a pattern where users will rename code so as to avoid compiler namespace conflicts. Something like a function do_some_encryption -> coolVendor_do_some_encryption. The logic of the code is generally unchanged, but any vulnerability information that keys off of naming conventions would break. Similarly a tarball which has been downloaded may have been renamed as part of some ingest pipeline. One constant could be a file hash of the tarball, but hashes are brittle as well and given the known inconsistency issues in archive formats hashes may not be useful in practice and might lead users to assume they are unaffected by some issue when in fact they simply have a tarball which has a different timestamp or something in it. Hashing would also break in the renaming scenario.

Namespacing based on DNS came up in the purl community call on 2025-06-11 and this could be an alternate approach that avoids the brittleness of hashing, but I question how a scanner would be able to reconstruct a meaningful DNS name when looking at an arbitrary tarball/directory full of code.

As mentioned above out of band patches are also a thing and I'm not sure a purl which encodes a diff should be in scope for the purl project or not. Perhaps that gets more at the what is a package? questions.

So, two questions I think we need to answer for this type to be useful

1. How do we expect scanners to construct a purl based on an archive full of code / a directory full of code.
2. How do we expect security advisory authors to to construct a purl for matching with scanners

I don't think we need to be perfect either, but I do think we need to start from a framework where we can reliably construct the same purl working in either direction. Perhaps we start with the pristine download case.

One other question; why limit this to C/C++. I believe (and am willing to be wrong) that the constraints of a source code based type would be relevant to source code in any language should it be distributed in the same way that much C/C++ code is.