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.

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

PURL matching with qualifiers #27

Closed
itaysk opened this issue Jun 7, 2023 · 3 comments
Closed

PURL matching with qualifiers #27

itaysk opened this issue Jun 7, 2023 · 3 comments
Labels
area/product Issues and PRs related to the product field

Comments

@itaysk
Copy link

itaysk commented Jun 7, 2023

It is clear that pkg://my@1.2.3?arch=amd64 means just the amd64 variation of package my@1.2.3, but what does pkg://my@1.2.3 means? Instinctively, no qualifiers means all possible variations of the package, but since PURL specifiers are optional, we don't know if the user omitted the qualifiers intentionally in order to widen the scope, or neglected to include them for another reason (since they are optional).
This is relevant to VEX because when matching the product id PURLs, we need to assume that the PURL in both locations followed the same choices as to which specifiers to use.

Example:
Let there be package pkg://npm/libA that has only amd64 architecture variation. SBOM-tool-A generated SBOM with package pkg://npm/libA@1.2.3 while SBOM-tool-B generated SBOM with pkg://npm/libA@1.2.3?arch=amd64. Note that Both SBOM tools produced correct results.
Since libA has only one architecture variation, maintainers of libA issued VEX with product id: pkg://npm/libA@1.2.3. What should the VEX consumer do?

Possible approaches:

  1. Ignore qualifiers and compare just base package - in this case it would mismatch if another qualifiers was used in the VEX (maintainers decide to add ?file_name=libA, or if the same qualifier will be used in a another VEX (maintainers later added support for arm64).
  2. Compare all qualifiers - in this case scanner would not apply VEX to SBOM generated by SBOM-tool-B.
  3. Compare common qualifiers and ignore the rest - This is likely the most reasonable compromise (although not perfect).
@luhring
Copy link
Contributor

luhring commented Jun 12, 2023

+1 — This is a great question, and we need to be clear on the expectation here!

My vote is for approach number 1 above. Here's how I'm thinking about it: I would treat qualifiers similar to how query string parameters would idiomatically be handled in an HTTP request.

Continuing with the npm/lib SBOMs example, I'd expect:

  • a VEX statement with a PURL with no qualifiers would match any similar package PURLs irrespective of their qualifiers
  • a VEX statement with a qualifier for arch=amd64 would match only the package from SBOM-tool-B
  • a VEX statement with a totally different qualifier than what's found in the SBOMs (e.g. license=MIT or arch=arm64) would match neither of the SBOMs' packages
  • SBOMs can add more qualifiers to their PURLs freely without affecting the VEX-filtered results, for cases when the VEX PURL doesn't include the newly added qualifiers

@puerco
Copy link
Member

puerco commented Jun 14, 2023

I agree with Dan's expectations. VEX qualifiers can glob the SBOM qualifiers, obviously not the other way around. We should write this down and implement a function to compare purls in the OpenVEX libraries to ensure applications match purls in the same way.

@puerco puerco added the area/product Issues and PRs related to the product field label Jun 14, 2023
@puerco
Copy link
Member

puerco commented Aug 22, 2023

This issue is now resolved by the release of the v0.2.0 spec and the v0.2.5 libraries that have built-in purl matching. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/product Issues and PRs related to the product field
Projects
None yet
Development

No branches or pull requests

3 participants