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. |
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
The `affected` array is an array containing `product` objects, which must at minimum include an "identifier" (which may be a composite identifier composed of multiple fields) along with a set of version bounds or a default status. Products may also specify an assortment of additional fields which further constrain the applicability of the CVE to its intended target hardware or software. Previously, the set of identifiers available were: - A `vendor` and `product` - A `collectionURL` and `packageName` This commit adds support for a new identifier, called `packageURL`, which uses the purl (Package URL) specification. The contents of the commit add this as a new field on the `product` type, with a description and examples, and also update the data constraints on the `product` type, both to make `packageURL` an option to fulfill the identifier requirement already in place on the type, and to ensure that the new `packageURL` field is not mixed with the existing `collectionURL` or `packageName` fields, as they are redundant with `packageURL` and including both increases the possibility of data inconsistency within a single CVE record. This inclusion of a new `packageURL` type which can be used instead of the existing pair of `collectionURL` and `packageName` would require consumers of CVE records to update their logic both to accept the new field, and to use it in places where they may today use the pair of `collectionURL` and `packageName`. This commit does not include a regular expression to parse Package URLs specifically. Rather, it reuses the existing `uriType` schema. So we can be sure after validating CVE records against this updated record format that the `packageURL` field is a URL, but not that it is a valid Package URL per the Package URL specification. It would be the responsibility of CVE Services to further validate the field to ensure values match the Package URL specification. We do not perform this validation in-schema due to the complexity of expressing the validation in the form of a regular expression. This work is submitted as an alternative formulation of the design proposed in the draft RFD on software identifiers [1], and as an alternative to the existing proposals for making the `cpeApplicability` structure generic [2] (instead of it being CPE-specific) and enhancing this new generic applicability structure with support for Package URLs [3]. If this change is accepted, then [2] and [3] should not be accepted. [1]: CVEProject#407 [2]: CVEProject#391 [3]: CVEProject#397 Signed-off-by: Andrew Lilley Brinker <[email protected]>
|
I've gone through and responded to the open comments on this. The full motivation and reasoning behind the proposal is shared in the RFD for software identifiers (#407). Currently, the one remaining open issue tracked in the RFD is whether to extend the @pombredanne, if you have a regular expression for validating Package URLs, I think we could consider using it instead of the more generic |
|
Closing this, as the project has opted for an approach based on the |
|
@alilleybrinker can you elaborate a little? |
|
@pombredanne this PR added Package URLs by extending the |
(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.