v3.4 excludes micro-ecc when version is "1" instead of "1.0" which worked in 3.3 #4467
Comments
|
So, my guess is what happened here is that it's a side effect of having to move away from the old version compare library. The old library had moved to more PEP440 compliance and was rejecting anything that didn't comply with that format (which is a HUGE number of versions in the overall database). So there's no chance of going back; it would break a lot of things. At a guess, the problem is either that we're doing a string compare so "1" != "1.0" for the basic equals case or that the comparison code is saying that the two items have different length of arguments so therefore they can't be the same. Given that this came up due to excel's over-zealous number handling, my guess is that it's only going to happen with versions that are XXX.0 so that may be easy to add in as a special case. The question is whether anyone actually does mean XXX.0 to not be the same as XXX, but I don't think I've seen that in the data yet. My instinct is that we should fix this and then be prepared to re-work only if it turns out to be a problem. |
* fixes intel#4467 If you edit a csv/spreadsheet in excel, it will modify values that "look like" integers to it, so the version 1.0 becomes 1, truncating the final ".0" from the version string. This adds an edge case in to the version compare function so it treats these truncated versions as the same (which was the behaviour in previous versions of cve-bin-tool). Signed-off-by: Terri Oda <[email protected]>
Description
@terriko requested I open a new bug report:
in v3.4 of this tool when the micro-ecc version is set at 1 in the SBOM CSV file (because Excel keeps changing 1.0 to 1 before the CSV is saved) the tool doesnt find the micro-ecc vulnerability at all even though it's in our triage input file.
This was found to be due to the fact that it was not 1.0 However, as I said this worked in v3.3 so users didnt have to fight with excel to constantly re-force it to 1.0.
This was found when testing v4.4 in this bug report: micrium uC/Lib vulnerability causes cve-bin-tool to delete triage response data from triage input file
To reproduce
Steps to reproduce the behavior:
Expected behavior: to list the known issue as the tool did in v3.3
Actual behavior: the output report doesnt contain the known issue
Version/platform info
Version of CVE-bin-tool( e.g. output of
cve-bin-tool --version): 3.4Installed from pypi or github?
Operating system: Linux/Windows: Windows 10
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19042 N/A Build 19042
Python version (e.g.
python3 --version): v3.12.0Running in any particular CI environment we should know about? N/A
Anything else?
Feel free to add any other context here.
You can get the files I used from the bug report linked at the beginning here
The text was updated successfully, but these errors were encountered: