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
os.path.dirname(__file__)+'/../data/CVE/list'.
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.
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: