nexB
Alpine: possibly wrong information is indexed
As I mentioned in #801 there is an issue with the way Alpine packages are indexed.
The following example illustrates this:
https://git.alpinelinux.org/aports/tree/main/py3-jinja2/APKBUILD?id=8531e658bb1a196c87ac3e8abf0bb18022266aa5
This APKBUILD file says the version of the package is 2.11.3-r0. But at line 18 there is a different version number:
# secfixes:
# 1.11.3-r0:
# - CVE-2020-28493
It looks like someone made a typo in the version number and it is this number that VulnerableCode seems to be using (as demonstrated in #801 ).
The solution is to do a little clean up and cross correlate this information with the Alpine package information.
@armijnhemel Thank you ++ That's a beautiful finding! We are getting the data from the Alpine secdb https://secdb.alpinelinux.org/ and this is likely wrong there too. So we can fix this indeed with some correlation and cross-checking (and then contribute it back upstream to Alpine)
@armijnhemel Thank you ++ That's a beautiful finding! We are getting the data from the Alpine secdb https://secdb.alpinelinux.org/ and this is likely wrong there too. So we can fix this indeed with some correlation and cross-checking (and then contribute it back upstream to Alpine)
Just verified, it is wrong in their secdb
@pombredanne @armijnhemel if we check this reference https://cve.report/qid/501765 they also have stated Affected Package versions prior to 1.11.3-r0
@pombredanne @armijnhemel if we check this reference https://cve.report/qid/501765 they also have stated
Affected Package versions prior to 1.11.3-r0
But it is the wrong version. This version of Ninja2 never existed. The Alpine maintainer made a typo in the package version, as can be clearly seen in the packaging information. Why not fix it?
@armijnhemel Thank you ++ That's a beautiful finding! We are getting the data from the Alpine secdb https://secdb.alpinelinux.org/ and this is likely wrong there too. So we can fix this indeed with some correlation and cross-checking (and then contribute it back upstream to Alpine)
I am wondering how many other errors there are in the Alpine security database. What I could imagine is that you would check the Alpine recipes to see if a certain version exists or ever existed. I could even imagine also checking the upstream sources to see if a package version actually has ever existed.