Re: Tracking related source packages (new tool)
On Mon, Aug 30, 2021 at 10:57:59AM +0200, Sylvain Beucler wrote:
> 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).
Ah yes, that makes sense.
> We may not use this option daily but I found it useful to experiment, hence
> it made a good addition to this toolbox.
Of course. I was not meaning to imply that it shouldn't be there. I
was just a bit surprised by how much additional output it produced.
> > 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.
OK. The specific thing that caught my attention with respect to this
was the invocation of the Packages2CVEs constructor, which references
But as you are the author, you are in a bettern position to know if
architecture is flexible in this regard.
Thanks again for the added explanations.
Roberto C. Sánchez