`canonical_convert` still assumes it will find something, resulting in AttributeError: 'NoneType' object has no attribute 'group'

[wyattearp]

I was testing out the latest code and ran into the same issue on the 3.0 release as the current head ca1de05. The code assumes that the regex match will return something correctly, which isn't always the case.

Line will still fail like issue #1300 and #1519 are intended to fix:

cve-bin-tool/cve_bin_tool/cve_scanner.py

Line 275 in ca1de05

parsed_version = parse_version(pv.group(0))

I patched it (poorly) in my code to do the following:

try:
    parsed_version = parse_version(pv.group(0))
except AttributeError:
    parsed_version = parse_version("99.99.99")
    self.logger.warn(
        f"error parsing {product_info.vendor}.{product_info.product} v{product_info.version} - manual inspection required"
    )

Likely there should be a configuration option on what happens if there's an error matching regular expressions, something like a "fail safe" and set the version to lowest possible value, which likely will create a lot of false positives, or "fail scary" which just drops a warning and tells the user to do manual inspection like I have above.

I'm happy to create a PR, but I'm not sure what the best approach should really be for this - thanks!

[terriko]

In other places, we return version UNKNOWN and print a warning, similar to your "fail scary" option, so I think the code above is probably in line with what we're doing now. I'd prefer one clear error message over a long list of false positives, and I think most users would like the same. Please go ahead and make a PR -- this is at least a decent partial solution for now.

I feel like we should probably make sure that this information is also presented in the report formats other than console so that it doesn't get missed. Could it be translated into an UNKNOWN entry with a comment explaining what went wrong? Or should we consider adding an error/warning section to the report that contains this type of information?

[terriko]

Another option: also return an error code if such a result is found (this would be helpful for CI systems and quiet mode to trigger further review)

[anthonyharrison]

@terriko I have been looking at the packaging documentaion and I think if the version string is not PEP440 compliant it will raise an InvalidVersion exception (need to check this though) which we could then translate into an Unknown version.

However it does raise the question of why we are getting invalid versions as I think the values are coming from the NVD database. Should we be validating the version when we load the data into the database?

[wyattearp]

@anthonyharrison - I'll see if I can get the exact package / binary that cause this issue, but it's on a disconnected network. Like the previous one, it was libxml2. I'll see if I can get a basic PR up sometime this week. Thanks!