Underwhelmed by the misuse of versionType and version to support purl

[prabhu]

Like many, I was very excited to explore the 5.1 release with purported support for package url. But it turned out to be just a couple of string attributes versionType and version, that can be used to populate with any values without any validations. In fact, versionType could be purl, package url, PURL, anything. While purl specification has no limit on the length, version attribute has a max length of 1024, which would limit the number of qualifiers (Example repository_url=full url) that can be used.

I think if we are serious about replacing CPE with purl, it deserves a first party attribute with correct validation rules. I would appreciate if you revisit the purl support for 5.2 release.

[chandanbn]

Is it possible to check if something is a valid PURL using JSON-schema rules?

[prabhu]

Thank you for the prompt response. If the attribute is called purl that alone is usually sufficient for the downstream tools to use appropriate validation.

Below is how CycloneDX handles the various identifiers.

https://github.com/CycloneDX/specification/blob/master/schema/bom-1.6.schema.json#L972-L999

CVE spec could support an array of purls, omnibor, and swhid etc similar to cpes.

[mprpic]

Is it possible to check if something is a valid PURL using JSON-schema rules?

Fwiw, the CSAF spec has a basic regex validator for purls:

• https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#31334-full-product-name-type---product-identification-helper---purl
• https://github.com/oasis-tcs/csaf/blob/f7c818282c13ac68f14a732708d25b4359f74b02/csaf_2.0/json_schema/csaf_json_schema.json#L249-L256

[alilleybrinker]

There is an RFD proposal for more direct support for PURLs, currently under consideration by the CVE Board. If approved, it would be merged with the 5.2.0 release, not yet scheduled.

See #407