minor loss of backward compatibility for arrays in 2.3.3

[ElectricNroff]

The intention of #1125 in https://github.com/CVEProject/cve-services/releases/tag/v2.3.3 was to adjust whitespace in a way that is compatible with normal CNA activity. However, there is a potential complication that, if CVE Services already stored a 5.1-compliant document, and the CNA is trying to update it to another 5.1-compliant document (with a change in a location that's unrelated to any whitespace), then an API call may fail. This is not documented, and could be potentially disruptive to a CNA that needs to make a critical update quickly.

For example:

{"cnaContainer":{"affected": [{"vendor": "v","product": "p",
"platforms":["HAL 9000", "HAL 9000 "],
"defaultStatus": "affected"}],
"descriptions": [{"lang": "en","value": "abc def ghi"}],
"references": [{"url": "https://example.com/r"}]}}

fails with:

{"error":"INVALID_JSON_SCHEMA","message":"CVE cnaContainer JSON schema validation FAILED.",
"details":{"errors":[{"instancePath":"/cnaContainer/affected/0/platforms","schemaPath":
"#/properties/platforms/uniqueItems","keyword":"uniqueItems","params":{"i":0,"j":1},"message":
"must NOT have duplicate items (items ## 1 and 0 are identical)"}]}}

because the trailing whitespace in the second instance of HAL 9000 is removed by the server before schema validation.

(This would also fail in a POST request for a new CVE Record, but it's perhaps more surprising that it fails during a PUT request to make an unrelated update.)

Workarounds could include:

• the Secretariat could proactively scan the entire CVE List to identify (or possibly "repair") CNA containers that have array elements differing only in whitespace - this is not hypothetical: it needed to be done once today; see the top of https://github.com/CVEProject/cvelistV5/commit/d42805d1920dc844997c711335715b9fb3195856
• the CVE Services server could automatically remove these types of duplicate array elements in any container when the container is submitted, e.g., automatically change it to "platforms":["HAL 9000"] in the example above
• the 2.3.3 release notes could be updated to inform readers of the behavior mentioned in this issue
• other documentation could be updated to inform CNAs that, even if a container complies with the 5.1 schema, a POST or PUT request may fail because the CVE Record is modified by the server before schema validation occurs