Re: Tracking related source packages (new tool)

[Sylvain Beucler <beuc@beuc.net>]

Hi Roberto,

Thanks for your thorough review :)
I answer a couple comments below:

On 29/08/2021 05:08, Roberto C. Sánchez wrote:
> On Sat, Aug 28, 2021 at 08:30:56PM +0200, Sylvain Beucler wrote:
> > Here are a few use cases:
> >
> > ...
>
> > # 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.

Indeed --two-way would be less suitable for 'renamed-packages' (where 
the most recent package is canonical and need not be updated with older 
entries), but could be more interesting for e.g. a 'forked-packages' 
(like qemu/kvm in the past, or golang-1.xx which regularly gets newer 
versions that need to be checked).

We may not use this option daily but I found it useful to experiment, 
hence it made a good addition to this toolbox.


> 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.

The tool uses the sectracker.parsers interface from lib/ exclusively. 
Should the security-tracker architecture changes, I think the interface 
could be updated to transparently parse and save a set of split-files 
(data/CVE/list -> data/CVE/list.*)  without changing the tool itself.

Cheers!
Sylvain