Steve Beattie (7):
* [d59485f] d2u.py: python3 does not allow unbuffered text output
* [7f21058] d2u.py: decode output from runcmd to convert to str
* [a9c801b] d2u.py: fix debug function to print message
* [f6f7c1a] gitignore: ignore the local clone of ubuntu-cve-tracker
* [bf1585a] d2u.py: add an option to restrict to a set of packages
* [0b151b2] d2u.py: fix issue where multiple releases match debian version
* [eae1574] d2u.py: point ubuntu cve reference at ubuntu.com page
d2u.py: fix issue where multiple releases match debian version
Amir Naseredini noticed that in a few cases, the same fix for the same
CVE was being reported multiple times; for example libxstream-java in
focal would report something like:
2022-Feb-15 Merge libxstream-java focal 1.4.11.1-1ubuntu0.3 1.4.11.1-1+deb9u5 Ubuntu/Debian CVE-2021-43859 needs-triage medium
2022-Feb-15 Merge libxstream-java focal 1.4.11.1-1ubuntu0.3 1.4.11.1-1+deb9u5 Ubuntu/Debian CVE-2021-43859 needs-triage medium
2022-Feb-15 Merge libxstream-java focal 1.4.11.1-1ubuntu0.3 1.4.11.1-1+deb9u5 Ubuntu/Debian CVE-2021-43859 needs-triage medium
2022-Feb-15 Merge libxstream-java focal 1.4.11.1-1ubuntu0.3 1.4.11.1-1+deb9u5 Ubuntu/Debian CVE-2021-43859 needs-triage medium
The reason this was happening is because the script performs an SQL
lookup against the locally cached information about versions of
libxstream-java in ubuntu, and does this lookup for each release
in ubuntu *but did not match against the specific release in the
generated SQL query*. Because the versions in both focal and bionic are
derived from 1.4.11.1-1, this meant that when checking for bionic, it
would discover that the focal version matched and report it, then when
it would look at focal it would also again report the focal version.
Fix this by adding the release to the SQL query (and re-formatting the
function call to be a little easier to read).
Signed-off-by: Steve Beattie <email address hidden>
d2u.py: avoid lp roundtrips by caching distro_series
Any attempts to access distro_series from a publishedSource results in a
query to launchpad, which means the release series gets looked up over
and over again; cache it on each published source lookup to reduce it to
once per publication source.
Applying this drops the of http GET calls to launchpad in a current run
from ~34K calls to ~13.5K. If we could get the publishedSource to give
us a consistent distro_series object reference, we could cut it down
significantly more.
Signed-off-by: Steve Beattie <email address hidden>
