Add support for Package URLs #397
Conversation
This "renames" (not actually a rename, see below) the existing "cpeApplicability" structure and its children from CPE-specific names to generic names. For example, "cpeApplicability" becomes "applicability." This is intended to permit future record format updates to add support for additional kinds of software identifiers. This change itself does not add any new kinds of software identifiers. The prior "cpeApplicability" structure remains entirely supported, though CNAs and any future ADPs enriching with software ID information should be encouraged to use the more expressive new "applicability" structure instead, and use of both at the same time should be treated as an error to avoid ambiguity. Signed-off-by: Andrew Lilley Brinker <[email protected]>
Signed-off-by: Andrew Lilley Brinker <[email protected]>
alilleybrinker
force-pushed
the
alilleybrinker/purl
branch
from
1365b7f to
8989c0c
Compare
|
@alilleybrinker re:
|
|
Also questions originally posted by @alilleybrinker in #391 (comment)_
What do you mean?
There is nothing super special about it. What's at issue?
This is a bug in the spec. It will be fixed.
Not sure if this is relevant, but we have a version range spec in PURL: The namespace and name must be lowercased. |
| { | ||
| "anyOf": [ | ||
| { "required": ["cpeMatch"] }, | ||
| { "required": ["purlMatch"] } |
There was a problem hiding this comment.
Ah, this appears to be a naming error. Will correct it.
| "type": "boolean" | ||
| }, | ||
| "criteria": { | ||
| "description": "Placeholder until we find a formal purl schema", |
| ] | ||
| }, | ||
| "purl_match": { | ||
| "description": "purl match string or range", |
There was a problem hiding this comment.
purl_match is the internal name of the object type as it exists in the schema, it is not a user-facing name, and is named thus to stylistically match the equivalent existing cpe_match structure.
| "matchCriteriaId": { | ||
| "$ref": "#/definitions/uuidType" | ||
| }, | ||
| "versionStartExcluding": { |
There was a problem hiding this comment.
For version ranges, purl uses this https://github.com/package-url/purl-spec/blob/main/VERSION-RANGE-SPEC.rst
There was a problem hiding this comment.
Yes, our plan is to not use the vers spec, but instead to reuse the existing mechanism for expressing version constraints used for CPE. We expect this will both be easier to existing consumers of CVE data and will mitigate concerns around the vers spec's readiness for production use.
Yes, this was an editing error made when I split the prior single PR into three. It's now fixed. |
I'll add that the list above was intended just to capture issues raised during the meeting, and are not arguments from me, I'm just relaying them as best I can. |
There was a problem hiding this comment.
I do want to add a regular expression constraint to ensure that purls submitted are actually syntactically valid. We haven't yet reached a consensus on whether versions should be permissible in the purl itself, so that would need to be resolved to determine the exact contents of the regex.
The regex could also help protect against accidental submission of purls which are not URL encoded (and thus not valid).
purls should also probably be pulled out as their own type, both for current clarity and for possible reuse elsewhere in the schema where purls may become usable in the future.
|
After discussion with the QWG, a Request for Discussion-style document is in the works to more completely address the design considerations in this proposal. |
alilleybrinker
changed the title
(Depends on #391; will need to be rebased on
developif/when that is merged, before this can be merged)Introduce support for Package URLs in the CVE record format.
For more background on the topic of software identification, review CISA's "Software Identification Ecosystem Option Analysis" paper.
Warning
When reviewing, focus on the last commit. This is a "Stacked PR," on top of #391, but GitHub shows both the commit making the
cpeApplicabilitystructure generic (from #391) and the commit adding purls (the part we care about here), when you click "Files changed" at the top of the PR, making review harder.