Version Range Upper and Lower Bounds Semantics

[ccoffin]

The QWG needs to make a decision as to whether we should require upper and lower bounds semantics (currently 0 and *). This decision needs to be made so that we can determine how to move forward with #371. The current versions.md text (https://github.com/CVEProject/cve-schema/blob/main/schema/docs/versions.md) states:

In any version range, the details of the version syntax and semantics depend on the version type, but by convention, "version": "0" means that the range has no lower bound, and a * in an upper bound denotes “infinity”, as in "lessThan": "2.", which denotes a range where the 2.X version series is the upper bound, or "lessThan": "", which denotes a range with no upper bound at all.

What are QWG members thoughts? Should we require the 0 and * for upper and lower bounds in semver 2.0.0? If yes, this means we must modify the semver 2.0.0 pattern match to include matches in these cases. A option would be to require * as an upper bound, but force the use of 0.0.0 as a lower bound in place of the usual 0. Another option is to NOT include 0 and * and create a new set of properties to handle upper and lower bounds differently.

[ccoffin]

In my opinion, we need to include * as an upper bound for both ease of use and backwards compatibility. If we are modifying the match to include *, we should probably also include 0 as a lower bound for backwards compatibility. I am still open to new points of view, but this is my current stance.

[darakian]

we need to include * as an upper bound for both ease of use and backwards compatibility.

Can you expand on this? Would the PR as it is right now not be considered a semver/schema ver minor addition to the cve format?

[ccoffin]

For the expanding part, i'd list out the items mentioned in the semver 2.0 PR. see #371 (comment). It was mentioned that adding 0 and * would not be following the specification, however, i don't think the semver specification would ever need to take version ranges into account in the way that the CVE Program needs to. I would be good with calling it something slightly different if others agreed.

Also, i think it's really important for us not to make changes between versionTypes unless the need is great. In the case of semver 2.0, i think we can mirror what has been done previously. This allows producers and consumers of the CVE Records to more easily produce and ingest the Records without a lot of extra work.

For the PR as it stands now, i'd probably view this as an addition under schemaver (https://snowplow.io/blog/introducing-schemaver-for-semantic-versioning-of-schemas). It is a new versionType and is an addition. But it's interesting how this change interacts with the other versionTypes and how a consumer might need to change their tooling to ingest CVE Records using semver 2.0 in the current PR. This appears to present another dimension to the schemaver model, though i might be missing something as i haven't read though it recently.

[darakian]

i don't think the semver specification would ever need to take version ranges into account in the way that the CVE Program needs to. I would be good with calling it something slightly different if others agreed.

Semver itself doesn't actually even have a concept of ranges. The range construction is my own but borrows from how number line ranges are constructed in mathematics.

https://mathworld.wolfram.com/ClosedInterval.html
https://mathworld.wolfram.com/Half-ClosedInterval.html
https://mathworld.wolfram.com/OpenInterval.html

Where each end of the interval is a valid semver value. Semver does define an ordering which allows for this construction.

Also, i think it's really important for us not to make changes between versionTypes unless the need is great. In the case of semver 2.0, i think we can mirror what has been done previously. This allows producers and consumers of the CVE Records to more easily produce and ingest the Records without a lot of extra work.

I would like to point out that the reason for my push at all is that records are not easy to ingest today. The situation as I see it is that the spec makes record production easy at the expense of consumption. The version types are under specified and data is represented inconsistently which forces consumers to construct complicated, convoluted and error prone parsing logic. I'd be curious if you agree with me on this perspective.

But it's interesting how this change interacts with the other versionTypes and how a consumer might need to change their tooling to ingest CVE Records using semver 2.0 in the current PR.

I would argue that my PR doesn't interact with other versionTypes at all. Are you suggesting that parsers today should work with new versionTypes going forward?

[dwelch2344]

I apologize for being late on this. Solid vote for not using 0 or * – it's either x.y.z or null (for infinity)