some non-PEP440 version constraints for GHSA python packages in grype-db

[willmurphyscode]

Hello,
I'm facing the same issue with grype 0.83.0
[0222] ERROR failed to inflate vulnerability record (by language): failed to parse constraint='>=1.7.0,<1.9.0ubuntu1.2' format='Python': unable to parse pep440 constrain phrase failed to create comparator for '&{< 1.9.0ubuntu1.2}': unable to parse

Originally posted by @de4Ru in #2195 (comment)

edit: here's an example of the records that can't be inflated:

SELECT 
    id, namespace, version_constraint 
FROM vulnerability 
WHERE
     version_constraint like "%0ubuntu1%" and namespace like "%python%";'

against a current grype db produces:

id	namespace	version_constraint
GHSA-pj65-3pf6-c5q4	github:language:python	>=1.7.0,<1.9.0ubuntu1.2
GHSA-rp8m-h266-53jh	github:language:python	>=1.7.0,<1.9.0ubuntu1.2

[willmurphyscode]

I've added needs-discussion for a couple reasons:

First, it was specifically requested (for similar issue #2195) on discourse, and second, there are a few aspects to the right approach here: Upstream data vendors can (and do) publish data that doesn't conform to what we'd expect (in this case a version string that seems not to be PEP440 compliant on a python package, or a version string for an APK package that doesn't conform to what that tooling expects in the case of #2195), so there are a few things we could do when seeing data like this:

1. Drop the record at DB build time - this has the drawback that there might be false negatives, so we probably shouldn't do this if we can help it. this would make issues harder to find, options at runtime are more preferable here
2. Try to normalize the record at DB build time
3. Fall back to other ways of trying to parse the version, for example trying to regex it to semver, and eventually falling back to string sorting
4. Try to make Grype more permissive in the kinds of version comparisons it can do.
5. Make grype isolate version parse failures completely from the rest of the matching process (we should probably due this anyway, and there's some of this done now)

The discussion is to explore these options and try to agree on some next steps.

[wagoodman]

We should look into 3 & 4:

• looser restrictions around left-hand, right-hand type comparisons
• better fallbacks for other looser version formats when parsing specific formats fails

[westonsteimel]

Specifically on apk it is important that we can do both apk to apk comparisons and the upstream to apk comparisons since we use NVD + fix feed. So upstream version 1.5.0 should be considered equal to alpine version 1.5.0-r0, etc. That will also become important with the enriched data which will be brought in with v6 grype db schema, because we'll want to be able to dow things like compare a deb package version from the sbom with an upstream semantic version directly. I did some testing and this seems to work at the moment, so just need to ensure we don't somehow break that with any changes