Formalize versionTypes

[darakian]

At the moment the versionType

cve-schema/schema/CVE_Record_Format.json

Lines 306 to 318 in 6af5c9c

	"versionType": {
	"type": "string",
	"description": "The version numbering system used for specifying the range. This defines the exact semantics of the comparison (less-than) operation on versions, which is required to understand the range itself. 'Custom' indicates that the version type is unspecified and should be avoided whenever possible. It is included primarily for use in conversion of older data files.",
	"minLength": 1,
	"maxLength": 128,
	"examples": [
	"custom",
	"git",
	"maven",
	"python",
	"rpm",
	"semver"
	]

identifier is fairly loosely defined. The description reads

This defines the exact semantics of the comparison (less-than) operation on versions, which is required to understand the range itself.

However it does not inform the reader of the exact semantics of any of the example version types (nor does it lay out a complete list of types).
In essence that just means that all the versionType are fancy unstructured text.

I suggest that for a future revision of the spec we create and maintain a list of supported version schemes. Custom likely needs to remain for backwards compatibility, however I suggest that we also encourage users of the custom type to propose new versionTypes. I would advise against version types that are named for languages eg. python as languages can end up in packages/executables which tend to not share the same idea of a version as the backing language.

If I understand the intent of the python identifier correctly (big if) then I would suggest that it be renamed to pypa and follow the convention here
https://packaging.python.org/en/latest/specifications/version-specifiers/

For the purpose of longterm maintainability I suggest that whatever versionTypes are formally adopted have their full spec copied into this repo. This allows the spec to say we support that one right there in that file we control and we won't be subject to a spec being updated without anyone knowing. Downside there is that it will require updates to the versionType spec over time and maybe versions for versionType (yo dawg). Ideally each version type also has an associated ordering (might be hard for a git type), but failing that then versions could be presented as a list.

Semver for instance is on version 2.0.0 and no change log (that I can find) exists from 1.x.y. So it would be most correct to rename semver -> semver 2.0.0

or 1.x.y if that's desired instead.
https://semver.org/

I do not propose that we attempt to catalog a large number of version schemes. Quite a few exist out there and most really don't matter. Some may as well be strings eg.
https://central.sonatype.org/publish/requirements/#correct-coordinates

The version can be an arbitrary string and can not end in -SNAPSHOT , since this is the reserved string used to identify versions that are currently in development.

Some more fun ones
https://nesbitt.io/2024/06/24/from-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source.html

I think a manageable approach would be to support custom (for a catch all case) semver (2.0.0), datever, and maybe a few others where we know people publishing date can reliably provide them. Then as CNAs need/want more options we ask them to make a proposal for new versions and we add them to the list.

[MrMegaZone]

Today 'versionType' is basically free text - you can put anything in there you want. So I could do something like "F5-BIG-IP-Versioning" or something silly like that. Today I use 'Custom' because what we do with that product doesn't fit any of the other buckets. (It is kind of a mutant semver - but NOT semver compliant.)

Are you suggesting we make this more of a defined list of allowed strings and remove the free text ability today? I could see how that could make validation easier. I'm not sure it would fix a common problem we have today though - which is the 'versionType' being provided, but being incorrect. For example, stating 'semver' when it isn't actually semver - a mistake I made on F5 CVEs for a while, before someone called me on it and I switched to 'custom'. I've seen similar issues with others.

If we do get proscriptive about what the string can be, I'd suggest we explicitly add 'x_' as a prefix to allow additional versionTypes to be used while pending addition to an official list/future schema.

I'm not sure how to solve the issue of mismatched versionType declarations. 'semver' is one of the easier types to validate, and even that isn't necessarily 'simple' to do. Should we have validation for any supported types we add to ensure they aren't misused?

[darakian]

Are you suggesting we make this more of a defined list of allowed strings and remove the free text ability today?

I'm suggesting we make a defined list for sure. Removing free text could be a goal, but maybe we can get around to that in a century or two once we observe that most cve publication is covered by the version types that we formalize. In the short term we keep free text, observe how its used and attempt to make a better way for the patterns we observe.

Using your F5-BIG-IP-Versioning example (or maybe F5-BIG-IP-Versioning-1.0.0 👀) rather than simply putting that label in versionType in an adhoc way, you (or whoever at f5) would open a PR to suggest F5-BIG-IP-Versioning-1.0.0 be added to the list and in that PR we would collectively define how F5-BIG-IP-Versioning-1.0.0 versions are specified and how they are ordered. After the new type is merged you publish your CVEs with those versions and everyone has a shared understanding of how to interpret the versions on them.

I'm not sure it would fix a common problem we have today though - which is the 'versionType' being provided, but being incorrect."

Agreed. We would need to have validation in place and to collectively correct errors when we observe them. That said, we can't correct anything until we define what "correct" is, hence this issue.

I'd suggest we explicitly add 'x_' as a prefix to allow additional versionTypes to be used while pending addition to an official list/future schema.

I think I disagree there. imo custom should be used until a type is formalized. Adding x_ would allow for adhoc creation of version schemas which would very likely be poorly defined and we would circle back to the problems we have today. It is better in my mind to define a format before usage rather than after.

Should we have validation for any supported types we add to ensure they aren't misused?

Yes.

[sentientcellcluster]

(George) Among other things, disallow relational operators as part of the version string.

[darakian]

(George) Among other things, disallow relational operators as part of the version string.

Say more. Are you talking about <, > and company? What issues are you hitting with them and would they work if their usage was well defined?

[sentientcellcluster]

Yes, I encountered a version number with “<” prepended. Having to check for them including possibilities like >= seems like complexity easily avoided by sensible rules.

…

-gm From: Jon ***@***.***> Sent: Thursday, November 21, 2024 4:51 PM To: CVEProject/cve-schema ***@***.***> Cc: George Masters ***@***.***>; Comment ***@***.***> Subject: Re: [CVEProject/cve-schema] Formalize versionTypes (Issue #362) [Caution - External] (George) Among other things, disallow relational operators as part of the version string. Say more. Are you talking about <, > and company? What issues are you hitting with them and would they work if their usage was well defined? — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https:/github.com/CVEProject/cve-schema/issues/362*issuecomment-2492649075__;Iw!!O7uE89YCNVw!LzPTaX-ZBZUjColT7EZohISb-WaZUknRCrya9_i1KQqVoDjbSgUc7srfHdDuUGdb-h3qVSKrPQw4a9m4WRFP63vTKb0Z$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AM4UNHIGWA2S5STP75VYULL2BZ5Y5AVCNFSM6AAAAABR2A72X6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJSGY2DSMBXGU__;!!O7uE89YCNVw!LzPTaX-ZBZUjColT7EZohISb-WaZUknRCrya9_i1KQqVoDjbSgUc7srfHdDuUGdb-h3qVSKrPQw4a9m4WRFP60F429lf$>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[darakian]

Can you share some examples? From the conversation in the QWG meeting yesterday I thought most of us were aligned that we wanted to support ranges (and hence relational operators). Is the issue you're hitting more to do with a lack of consistency or a misuse of the operators?

[sentientcellcluster]

I expect we would support ranges by defining endpoint variables that a CNA selects and sets values for to describe <condition> at <version>, <condition> starting at <version> before <version>, <condition> after <version>, <condition> before <version>, etc. Like MZ, I prefer to avoid wildcards, and I prefer for <version> values to always refer to a single unambiguous point in version history. I don’t recall the one where I recently saw ‘<’ prepended, but this seems to me misuse. If we have such endpoint variables that define endpoints and definitions of those variables that describe how they relate to bounding of vulnerable (or not vulnerable) ranges, then it seems redundant to also allow relational operators. It imposes a burden of additional processing to detect and handle them – and also to handle the possibility that they may conflict with the variables’ definitions. (Similar to my observation before of a CVE where the CNA had used a terminating wildcard in a ‘lessThanOrEqual’ value – probably a copy/paste error from using the same in a ‘lessThan’ field) For me, the core mission is supporting defenders’ use of automation to support vulnerability discovery in development projects or in procured products. … and for this, I favor simplicity. Cheers…

…

-gm From: Jon ***@***.***> Sent: Friday, November 22, 2024 12:36 PM To: CVEProject/cve-schema ***@***.***> Cc: George Masters ***@***.***>; Comment ***@***.***> Subject: Re: [CVEProject/cve-schema] Formalize versionTypes (Issue #362) [Caution - External] Can you share some examples? From the conversation in the QWG meeting yesterday I thought most of us were aligned that we wanted to support ranges (and hence relational operators). Is the issue you're hitting more to do with a lack of consistency or a misuse of the operators? — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https:/github.com/CVEProject/cve-schema/issues/362*issuecomment-2494752099__;Iw!!O7uE89YCNVw!LDrty-0qnuRBaSVwWJS9-gkC5CN9dcBUf8mHBE1kORwNzKphst-FATvfV0-yCPoyP0HNDZ5dXCRyeqS9FPZd2PV6buWJ$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AM4UNHNXQR5YIWJAMFPGJ4L2B6IRNAVCNFSM6AAAAABR2A72X6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJUG42TEMBZHE__;!!O7uE89YCNVw!LDrty-0qnuRBaSVwWJS9-gkC5CN9dcBUf8mHBE1kORwNzKphst-FATvfV0-yCPoyP0HNDZ5dXCRyeqS9FPZd2Kg6WCLj$>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[darakian]

I prefer for values to always refer to a single unambiguous point in version history.

Agreed. That's part of the idea of defining specific version types so that the reader of the version information knows.

If we have such endpoint variables that define endpoints and definitions of those variables that describe how they relate to bounding of vulnerable (or not vulnerable) ranges, then it seems redundant to also allow relational operators.

I think that's a semantic difference. If we define a type which is a tuple (x, y) and the rules of the type says that the values should be read as x is an inclusive lower bound and y is an exclusive upper bound then that's equivalent to defining the type as >= x, < y.
Though a tuple would probably be easier to build validation for in practice.

[sentientcellcluster]

Easier validation is as essential as is automation-friendliness. Both help to improve data quality and usefulness of the data. My problem isn’t relational expressions per se, but allowing them bonded to a version identifier. In my world, a version identifier refers to a specific point in time, so a relational operator when combined with one makes it no longer a version identifier – so I have to consider that it now becomes two data elements instead of one. Thinking of validation, we want also to discourage such practices as in CVE-2024-30102. I tripped over this one a day or two ago. "versions": [ { "version": "16.0.1", "lessThan": https://aka.ms/OfficeSecurityReleases, "versionType": "custom", "status": "affected" } This range information should have failed validation, and it is not useful for automated comparison. This one requires direct human intervention to be useful – something to be avoided. Which suggests the question: What does “custom” version type allow? It would be pretty hard to make the argument that that URL is a version identifier in any sense of the term. … there are an awful lot of “custom” versionTypes in the database. How do we formulate validation rules for “custom” ? Maybe this is the place to concentrate thinking - about bounds for what “custom” can mean and bounds for version range statements. Happy Thanksgiving!

…

-gm From: Jon ***@***.***> Sent: Monday, November 25, 2024 1:38 PM To: CVEProject/cve-schema ***@***.***> Cc: George Masters ***@***.***>; Comment ***@***.***> Subject: Re: [CVEProject/cve-schema] Formalize versionTypes (Issue #362) [Caution - External] I prefer for values to always refer to a single unambiguous point in version history. Agreed. That's part of the idea of defining specific version types so that the reader of the version information knows. If we have such endpoint variables that define endpoints and definitions of those variables that describe how they relate to bounding of vulnerable (or not vulnerable) ranges, then it seems redundant to also allow relational operators. I think that's a semantic difference. If we define a type which is a tuple (x, y) and the rules of the type says that the values should be read as x is an inclusive lower bound and y is an exclusive upper bound then that's equivalent to defining the type as >= x, < y. Though a tuple would probably be easier to build validation for in practice. — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https:/github.com/CVEProject/cve-schema/issues/362*issuecomment-2499087843__;Iw!!O7uE89YCNVw!KPuqhECiXHKOsXaOz7r5RNSVNYHYU5qoFIdVDafg66Cp-NnyETp6QzWT4G2KmgCvyYLJFZ0hhmDT3EZK5bIk9yE1RFLZ$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AM4UNHIUIXJ7ZP3NARGTVG32COKFHAVCNFSM6AAAAABR2A72X6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJZGA4DOOBUGM__;!!O7uE89YCNVw!KPuqhECiXHKOsXaOz7r5RNSVNYHYU5qoFIdVDafg66Cp-NnyETp6QzWT4G2KmgCvyYLJFZ0hhmDT3EZK5bIk9181v44U$>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[darakian]

@ryOF65aErb for the purposes of this issue I'd like to keep things focused away from the custom type since that's more or less unstructured by definition. I'm more curious what new types would be useful to you (and to others).

[sentientcellcluster]

A valid wish. I do wonder, though, what % are “custom”. Do we know that? Have we painted ourselves into a corner? If by allowing “custom” we make the data store less useful, we might want to consider being less accommodating – perhaps by structuring things to make ‘custom’ less attractive (less of an invitation to not do work to be specific in the data submitted). Just sayin’… I see automation as job 1.

…

-gm From: Jon ***@***.***> Sent: Monday, December 2, 2024 11:12 AM To: CVEProject/cve-schema ***@***.***> Cc: George Masters ***@***.***>; Mention ***@***.***> Subject: Re: [CVEProject/cve-schema] Formalize versionTypes (Issue #362) [Caution - External] @ryOF65aErb [github.com]<https://urldefense.com/v3/__https:/github.com/ryOF65aErb__;!!O7uE89YCNVw!Lk18iEzduATqafq6AntgX_6ijR09QtZnG6gPjicLldhAxSuRUeLMaSv485Ngwfw9SgGw04mj-8yDYpRAStFltk3mxOGO$> for the purposes of this issue I'd like to keep things focused away from the custom type since that's more or less unstructured by definition. I'm more curious what new types would be useful to you (and to others). — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https:/github.com/CVEProject/cve-schema/issues/362*issuecomment-2512512695__;Iw!!O7uE89YCNVw!Lk18iEzduATqafq6AntgX_6ijR09QtZnG6gPjicLldhAxSuRUeLMaSv485Ngwfw9SgGw04mj-8yDYpRAStFltiR8aJ5H$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AM4UNHO6OOSIJXVSIM2ZF632DSWI3AVCNFSM6AAAAABR2A72X6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJSGUYTENRZGU__;!!O7uE89YCNVw!Lk18iEzduATqafq6AntgX_6ijR09QtZnG6gPjicLldhAxSuRUeLMaSv485Ngwfw9SgGw04mj-8yDYpRAStFltrEZ1lNI$>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[darakian]

what % are “custom”.

Functionally 100% today since there are no rules for any of the types. Good news is that there's room for improvement 👍

I see automation as job 1.

Totally aligned. Again, please share any specific version specs you think would be useful.

[zmanion]

I support selecting/developing an initial set of properly-specified version types. Open to what these might be. Some thoughts and addtional input, not expressing a strong preference:

• SemVer
• purl (All types? Some types? Just an example of types? purl only works with defined types.)
• vers (came from purl)
• vers-like (from CSAF, a degenerate use of vers)
• The vulnogram UI semi-supports specific version types but I don't think it validates or enforces anything
• The OSV schema requires an ecosystem, which IIUC means an ecosystem-specific version syntax

It makes sense to choose something that is already in use and/or demand.

[zmanion]

While this issue is about version types, this implicates how ranges work (e.g., operators, wildcards) and even status, which may vary by version type. I'd prefer that CVE maintains only one set of range rules if possible. Also a reminder that CVE doesn't include a "fixed" status and we've been living on implications for 20+ years.