DOCS - Provide guidance on how to format the affected/notaffected JSON data

[kurtseifried]

So when filling out the affected/notaffected data in the JSON file the two main options are:

1. explicitly list every version (1.0, 1.0.1, 1.0.2, 1.0.3, etc.)
2. list ranges, e.g. ">= 1.0.3" or "1.0 through 1.0.3"

There are advantages and disadvantages to both.
Explicitly listing:

con: Explicitly listing all the versions affected assumes that no new versions that are vulnerable will be released, and if they are the JKSON data needs to be updated ASAP.

pro: Explicitly listing all the affected versions makes matching the versions up easy, and consumers of CVE data don't need to guess and expand the data, e.g. "5.6 through 8.2", so for pattern matching a version we want (please note regex, so .* is any char, not just . then star) "^5.6.", "^6.", "^7.", "^8.2." which is annoying with numbers, but some projects use named releases now.

Range listing:
con: people have to parse the range to some degree, we use "through" "prior to", "before", "after", "=/>/</!/?/??????" which is tough for humans to parse let alone software (we'd want to document this).
pro: it covers software released in the meantime that may still be vulnerable, (e.g. if you list "1.2 through 2.4" and you release 1.6.... is it vuln or not?)

One major way to help solve this is to start listing the fixed versions explicitly as notaffected.

Can anyone else list any other major pros/cons to this, once done we can add it to the docs.

[chandanbn]

You are combing three different problems:

1. How do you compare given two versions to determine what came first.

Short answer: it requires encoding the entire set (or at least actively maintained set) of versions as a directed acyclic graph. Pattern matching or alphanumeric comparison is not reliable.
IMHO encoding this graph in per CVE JSON could be an overkill. Perhaps this can be done in the per CNA JSON?

2. Given this graph, how do you encode which versions are affected, which versions are not affected, and which are unknown?

See my update to #42

3. What do you make of versions not covered by what is stated or can be inferred from JSON?

Answer: status should be considered as unknown.
If a CNA wants to declare something as not affected, it is better to explicitly state it.

[mprpic]

Assuming this is no longer relevant. If there are any additional questions on version information in the CVE schema, please file a new issue in https://github.com/CVEProject/cve-schema/.