The discussion at the QWG meeting today suggested adding a pattern field here to specify at least one non-whitespace character:

This was thought to be better than changing:

"#/definitions/descriptionWithNonWhitespace"

so that the change would affect only the descriptions part of a CNA or ADP container. In other words, it would be best to change the meaning of #/definitions/description and thereby force a non-whitespace character in all contexts where #/definitions/description is used (e.g., impacts and rejectedReasons).

Among the few people who attended, there was no support for a more general change to the minimum character length. Prohibiting an all-whitespace value helps with these objectives:

• not accepting a submission when the provider simply forgot to fill out the field
• avoiding some types of anomalous data processing, e.g., a plausible JSON-aware application has an initial processing stage that removes leading and trailing whitespace from strings, and a second processing stage that expects that all fields are True in a boolean context. Because an empty string is considered false in some languages (e.g., Python), the application could have unexpected behavior.

Increasing the minimum character length might block some descriptions that have low utility, but providers could simply compose an equally useless description that has more characters.

Trailing (or possibly leading) whitespace is common here:

Also,

"^(?:\\S|\\S.*\\S)$"

was potentially unintended. It prevents newline characters in the middle of a string (affecting approximately a thousand CVE Records). This can be fixed by:

"^(?:\\S|\\S[\\s\\S]*\\S)$"

Leading/trailing whitespace is also seen in version fields, with more than 400 CVE Records affected. The common cases are one trailing space or one leading space.

Leading/trailing whitespace is also seen in names of vendors and names of products, with more than 2500 CVE Records affected. The common cases are one trailing space or one leading space.

One CVE Record was found with trailing versionType whitespace:

CVE-2023-1900

"versionType":"1.0.2303.633 "

@ElectricNroff Would you run similar queries against records produced in the last year? This will give us a better sense of what the current record production behavior is. We want a general sense of the magnitude of occurrence.

For records published in 2023:

fields that use the "description" definition - 2049
version fields - 166
vendor and product fields - 279

The large difference for vendor and product fields is mostly explained by one large vendor no longer including a space at the end of the product name.

Has there been a problem with CNAs providing descriptions with a single character or whitespace in the past? Is this a problem we really need to address? Is this something CVE Services could more easily handle?

For the past few months, the CVE Services server has done schema validation after stripping leading and trailing whitespace. If the description has only whitespace, container submission fails with

{"error":"INVALID_JSON_SCHEMA","message":"CVE cnaContainer JSON schema validation FAILED.",
"details":{"errors [{"instancePath":"/cnaContainer/descriptions/0/value",
"schemaPath":"#/properties/value/minLength","keyword":"minLength","params":{"limit":1},
"message":"must NOT have fewer than 1 characters"}]}}

If the description has only whitespace, container submission fails with

That seems like desirable behavior no? Do we want records to be published with blank descriptions?

Having CVE services strip leading/trailing whitespace before validation is desirable, but when this was discussed many months ago that was just part of the solution. We did intend for the schema to also enforce this as CNA may be using the schema locally to validate before submitting to services - and if we can get things fixed upstream it is better than getting all the way to submission only to have it rejected at that last step.

I feel we should ensure that required fields contain some minimal amount of information. They should not contain only whitespace - and it may be desirable to have some minimum number of non-whitespace characters.

I'm not too worried about malicious action - deliberately submitting bogus info, but mistakes happen and helping catch them is a good thing, IMHO. Belt-and-suspenders, don't rely only on CVE Services. Who knows what the future may bring and what may change there, let alone other tooling that uses the schema.