Open joshuagl opened 1 year ago
@joshuagl Thank you for your comments. Do you have a proposal to solve this?
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.
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.
The draft Telco SBOM specification states that a package SHOULD be identified by a Package URL (PURL) in an ExternalRef, and that:
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.