Closed nscuro closed 1 year ago
The algorithm for vers
parsing is defined here: https://github.com/package-url/purl-spec/blob/version-range-spec/VERSION-RANGE-SPEC.rst#parsing-and-validating-version-range-specifiers
Seems the incoming data (produced by mirror-service) is incorrect.
vers:generic/2.4.0|2.4.33.1
says "Version 2.4.0 and 2.4.33.1 are affected", but according to the CPEs it should be "Versions >= 2.4.0 and < 2.4.33.1 are affected".
So it should've been a vers
range like vers:generic/>=2.4.0|<2.4.33.1
instead (see https://github.com/package-url/purl-spec/blob/version-range-spec/VERSION-RANGE-SPEC.rst#version-constraint).
Raised #733 to revisit the parsing on the mirror-service side of things.
The API server fails to properly parse
vers
version ranges from records in thedtrack.vulnerability
topic.When encountering a
vers
range likevers:generic/2.6.0|2.6.17.9
, the parsing logic assumes that the range is not definite, and skips it.It does however still create a
VulnerableSoftware
record on this case, but it does so without any version information at all. What should happen instead, is that no record will be created at all. At the moment, this behavior causes duplicateVulnerableSoftware
records, because multiple ranges end up with identicalVulnerableSoftware
representations.Example BOV
In a unit test, the above BOV ends up creating the following
VulnerableSoftware
records:Beside their ID and UUID, they are identical. Also note how the BOV contains 4 additional CPEs that were not parsed, and for which the
affected.versions
node is empty for some reason.