I've drafted a CVE, CVE-1969-12345 which exercises many, but not all, of the required and optional fields in the current schema. We should publish it, or something like it, in the main corpus. It's useful to have a representative CVE that doesn't actually implicate a particular company or project for illustrative purposes, for basic connectivity and parsing testing, and other things like that. "example.com" fulfills this role for a few different protocols, such as DNS, HTTP, and HTML.
1969 is a real year, but falls outside the expected range of CVEs, and is old enough to be obviously an example.
12345 is a five-digit part, which helps to illustrate that CVE IDs are no longer merely year-fourDigits.
I don't really care about the rest of the elements, and changes are welcome. I think the description should be descriptive of the CVE itself, but beyond that, it shouldn't matter what the other values are. Every required element should be present.
Also, this is not intended to be an all-in-one test case for downstream parses. This is not the job of example.com in its realms, so it shouldn't be the job of this CVE.
QWG could conceivably publish a full test suite of CVEs that's more useful for unit testing for parses, but that's beyond the scope of this ask.
I would love to see a decision on this before the end of July.
I've drafted a CVE, CVE-1969-12345 which exercises many, but not all, of the required and optional fields in the current schema. We should publish it, or something like it, in the main corpus. It's useful to have a representative CVE that doesn't actually implicate a particular company or project for illustrative purposes, for basic connectivity and parsing testing, and other things like that. "example.com" fulfills this role for a few different protocols, such as DNS, HTTP, and HTML.
Here is a run at CVE-1969-12345:
https://github.com/todb/junkdrawer/blob/main/CVE-1969-12345.json
I like this number specifically because:
I don't really care about the rest of the elements, and changes are welcome. I think the description should be descriptive of the CVE itself, but beyond that, it shouldn't matter what the other values are. Every required element should be present.
Also, this is not intended to be an all-in-one test case for downstream parses. This is not the job of example.com in its realms, so it shouldn't be the job of this CVE.
QWG could conceivably publish a full test suite of CVEs that's more useful for unit testing for parses, but that's beyond the scope of this ask.
I would love to see a decision on this before the end of July.