Support multiple purl identifiers in product_identification_helper

[mprpic]

Currently, product_identification_helper allows a purl to be defined as a single item:

"purl": {
  "title": "package URL representation",
  "description": "The package URL (purl) attribute refers to a method for reliably identifying and locating software packages external to this specification.",
  "type": "string",
  "format": "uri",
  "pattern": "^pkg:[A-Za-z\\.\\-\\+][A-Za-z0-9\\.\\-\\+]*/.+",
  "minLength": 7
},

There are cases though where a component can be identified by more than one purl, for example when the component is accessible through multiple download locations, or have some other purl qualifier that is distribution-specific and can have multiple values but still point to the same component.

The spec also provides a way to list multiple SKUs, model numbers, or generic URIs already, so there is precedence for using an array of identifiers instead of just one and enforcing multiple product tree branches to be used for every component.

My suggestion is to modify the spec to allow an array of purls to be used:

"purls": {
  "title": "List of package URLs",
  "description": "Contains a list of package URLs (purl). The purl attribute refers to a method for reliably identifying and locating software packages external to this specification.",
  "type": "array",
  "minItems": 1,
  "items": {
    "title": "package URL representation",
    "description": "The package URL (purl) attribute refers to a method for reliably identifying and locating software packages external to this specification.",
    "type": "string",
    "format": "uri",
    "pattern": "^pkg:[A-Za-z\\.\\-\\+][A-Za-z0-9\\.\\-\\+]*/.+",
    "minLength": 7
  }
},

[tschmidtb51]

Hmm, I'm not sure about that. If we do that, we should probably add also a mandatory test that ensures that only the qualifiers differ between the purls. Otherwise, we open the door widely for combinations that are syntactically not correct.

[mprpic]

I'm not opposed to mandatory tests, but I feel like a vendor publishing disparate purls for a single product branch would be shooting themselves in the foot, so I'm not sure it's all that necessary.

[tschmidtb51]

I'm not sure it's all that necessary.

Unfortunately, I saw things in CSAF 2.0 that don't make sense at all, but people did those as there were no mandatory tests. As we want to make it easy to write CSAF, we need tests to guide wherever there is opportunity to make easy mistakes.

[tschmidtb51]

Could you please provide some examples for that request? I just want to make sure that we are all on the same page.

[mprpic]

You can find an example of a component with multiple purls in one of our example SBOMs: https://github.com/RedHatProductSecurity/security-data-guidelines/blob/71fb1006e269b59208cd6206a6d4c2cd7a30b68c/sbom/examples/product/rhel-9.2-eus.spdx.json#L30-L113

Or do you want a full example of a CSAF file that would use these?

[tschmidtb51]

Thank you for pointing to some example data. I wonder: Shouldn't those be different entries in the product_tree as they are differentiated by architecture? Or is that just one packages (i.e. the same files with the same hash) that run on all of these architectures?

[mprpic]

That particular package is a source package that contains source code files only and is thus architecture-agnostic. It is however distributed in every architecture-specific RPM repository so that you can download e.g. openssl-1.2.3.x86_64 and openssl-1.2.3.src from the same repository. The source package has the same checksum in every one of those repositories too.

[santosomar]

Motion Proposed via this email to the TC