[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tracking related source packages (new tool)

Hi Sylvain,

I have spent some time looking over your code and trying out the tool.
Overall, the code looks good, easy to understand, and useful in

On Sat, Aug 28, 2021 at 08:30:56PM +0200, Sylvain Beucler wrote:
> Here are a few use cases:
> # Report CVE entries that may have been missed for old renamed packages in Debian
> $ bin/related-cves.py --transitions data/renamed-packages --report

This seems to produce useful output.  I looked at some of the reported
findings for lua5.3 and it seems like the CVEs either apply, or or are
close enough that it would make sense to explicitly mark them

> # Also report CVE entries that may have been missed for newly branched packages in Debian (e.g. the golang-1.xx set)
> $ bin/related-cves.py --transitions data/renamed-packages --report --two-way
This produced much more output, much of which I am not sure would be
especially useful.  Perhaps the security team, dealing with oldstable
through unstable might benefit from it, though.  The year threshold you
mentioned seems to be useful here, if I understand it correctly.

> # Automatically add entries renamed packages in ELTS, in the extended CVE list file, restricting to supported packages
> # (can complement the script for automated <end-of-life> entries)
> $ bin/related-cves.py --transitions data/renamed-packages.elts --extcve data/CVE-EXTENDED-LTS/list --extadv data/ELA/list \
>     --start-year 2019 \
>     $(awk '{print $1}' < ../extended-lts/packages-to-support)
> # Check issues that might affect krfb and vino in Debian (due to embedding e.g. libvncserver)
> $ bin/related-cves.py --transitions data/embedded-code-copies --format embedded-code-copies --report krfb vino
> # Check issues that might affect php5 in ELTS (due to embedding various libraries)
> bin/related-cves.py --transitions data/embedded-code-copies --extadv data/ELA/list --format embedded-code-copies --report php5

It appears that if the data/CVE/list split is implemented that this
would be another tool that requires updating to deal with the new
architecture.  I wonder if it makes sense to proceed with implementing a
"list of filenames" that the script operates upon for each parameter
(e.g., CVE, DSA, DLA, etc.) in order to be ready for the coming change.



Roberto C. Sánchez

Reply to: