The OmniBOR folks would love to talk with you!

[alilleybrinker]

Hi! I'm part of the OmniBOR Working Group, defining a work-in-progress spec and associated implementations for...

1. Independently-reproducible, content-based identities for software artifacts
2. Manifests which record the inputs used to produce software artifacts

The general vision of OmniBOR is to eventually have various build and distribution tools which produce software artifacts produce these manifests, enabling thorough and precise tracking of the "dependency graph"s for those artifacts.

I think this is similar in purpose to cargo-auditable, and we'd love to talk with you all about it!

[alilleybrinker]

I'll add that CISA, the Cybersecurity & Infrastructure Security Agency of the United States, recently produced a paper titled "Software Identification Ecosystem Option Analysis" which identified OmniBOR as one of three major options in this space, alongside Package URLs (pURLs) and CPE (Common Platform Enumeration) identifiers.

[Shnatsel]

I had a close run-in with the pURL specification recently while working on cargo cyclonedx and it is not very well defined, leading to compatibility issues: package-url/purl-spec#261

I am not convinced a standard like that would be a good fit for cargo auditable specifically, but I would be happy to talk to you about OmniBOR could potentially be applied to Rust in general.

[alilleybrinker]

Sounds good! I'm taking some time off for Thanksgiving but will be working again on November 29th. If it's alright with you I can try to find a time for us (and anyone else you think may be interested) to meet and discuss after that.

Also, to distinguish OmniBOR and pURL a bit. From my perspective, pURLs (unless they encode some sort of hash) are really describing locations, not identities, because the software found at a given package name and version may change. OmniBOR Artifact Identifiers are purely based on the contents of the artifacts being identified, making them independently reproducible, and OmniBOR's overall design is intended to be complementary to software bills of material (SBOMs).

[pombredanne]

@Shnatsel you wrote:

I had a close run-in with the pURL specification recently while working on cargo cyclonedx and it is not very well defined, leading to compatibility issues: package-url/purl-spec#261

I am looking into this in details, but the issues may be also about tools implementing the spec incorrectly... and if there is more than one doing mistakes there, then this may be the spec's fault alright, e.g, my fault. 😬 , and this will be fixed on way or another.

[pombredanne]

@Shnatsel I am not sure what are you goals here in details, but a PURL for cargo is exactly as specific and identifying as what you would put in a Cargo.toml:

cargo-auditable/cargo-auditable/Cargo.toml

Line 21 in da85607

pico-args = "0.5"

points to pico-args = "0.5" and the PURL is pkg:cargo/[email protected] ... you could add checksum and a URL as found in a Cargo.lock alright, but the whole point is that there is nothing more to it than that. It just embraces and reuses the norms, specs and convention of your package ecosystem with an obvious and simple syntax that can work across ecosystems and works decently well for this purpose. It can locate an identify if that's what you use to identify. A PURL is not too concerned with cryptographic verification in general beyond supporting optional simple checksums. If that's what you want that's not the tool alright. If you have a vulnerability database, an SBOM, a VEX, some tool that scans code and collects inventories of packages, then it works decently well with low ceremony and has been adopted by some specs (CycloneDX, SPDX, CSAF and OpenVEX to name a few) and tools and vulnerability data sources. The fact this is simple and obvious promotes interop between these tools and specs.
/hth

[Shnatsel]

I am going to try converting cargo auditable to CycloneDX and by extension PURL, once I get the time to do so.

That said I do see issues with the spec, not just for my use case but places where it is ill-defined or contradicts itself, which leads to non-interoperable implementations. package-url/purl-spec#261 is just one instance of this.

@pombredanne I could do a detailed write-up of the issues I've discovered while trying to use it, if you are interested.