OpenChain-Project / Telco-WG

This is the OpenChain Telco Work Group
Other
13 stars 6 forks source link

[Bug] Telco SBOM a Package URL doesn't (always) "uniquely identify software packages" #74

Open joshuagl opened 1 year ago

joshuagl commented 1 year ago

The draft Telco SBOM specification states that a package SHOULD be identified by a Package URL (PURL) in an ExternalRef, and that:

Package URL (PURL) is a de facto standard to uniquely identify software packages.

However, there's no uniformity around PURL usage to ensure that a given PURL is a unique identifier for a software component.

There have been requests for guidance/"Documentation around using PURLs as unique identifiers": https://github.com/package-url/purl-spec/issues/242 -- however this appears to still be an unresolved question in the PURL community.

Expected behavior

It's clear how to use a PURL to uniquely identify a software package, or the claim to uniquely identify a software package is diluted. This may be a section of the Telco SBOM which describes how to construct a PURL such that the identified package is uniquely identifiable, or may be working with the upstream to ensure this is covered by the PURL spec.

vargenau commented 1 year ago

@joshuagl Thank you for your comments. Do you have a proposal to solve this?

nishakm commented 1 year ago

https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst is the canonical place to look for best practices to create pURLs for each ecosystem. I'm looking forward to hearing if this solves your problem.

joshuagl commented 1 year ago

Apologies for the delayed response. I think the question of how to resolve this depends on the purpose for using pURL.

The draft spec says that the pURL is used as to identify packages, however the pURL maintainer(s) state (in purl#242 comment) that pURL is primarily a locator format:

A PURL is a locator and a mostly unique way to identify a package. But this does not mean that there is a single unique PURL for a given package.

I believe the goal for use of pURL in the telco SBOM is to provide a reference to the original location the package was retrieved from? If that's correct, we can update the draft spec to align the language with pURL's statements.

If that's not correct, the spec should better describe the goal and how pURL can be used to achieve it. Perhaps referencing the pURL types document that Nisha referenced.