Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support multiple purl identifiers in product_identification_helper #774

Open
mprpic opened this issue Aug 26, 2024 · 8 comments · May be fixed by #781
Open

Support multiple purl identifiers in product_identification_helper #774

mprpic opened this issue Aug 26, 2024 · 8 comments · May be fixed by #781
Assignees
@mprpic @tschmidtb51
Labels
csaf 2.1 csaf 2.1 work motion_passed A motion has passed

Comments

@mprpic
Copy link
Contributor

mprpic commented Aug 26, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

mprpic commented Aug 26, 2024

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
Copy link
Contributor

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
Copy link
Contributor

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

@mprpic
Copy link
Contributor Author

mprpic commented Aug 26, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

mprpic commented Aug 27, 2024

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 santosomar added the csaf 2.1 csaf 2.1 work label Aug 28, 2024
@santosomar
Copy link
Contributor

santosomar commented Aug 28, 2024 •
edited
Loading

Motion Proposed via this email to the TC

@santosomar santosomar added the motion This item has a motion pending label Aug 28, 2024
@mprpic mprpic linked a pull request Aug 30, 2024 that will close this issue
Open
@tschmidtb51 tschmidtb51 added motion_passed A motion has passed and removed tc-discussion-needed motion This item has a motion pending labels Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mprpic mprpic

@tschmidtb51 tschmidtb51

Labels
csaf 2.1 csaf 2.1 work motion_passed A motion has passed
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Draft: Support multiple purl identifiers in product_identification_helper mprpic/csaf
4 participants
@mprpic @santosomar @tschmidtb51 and others