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

Re: Tracking related source packages (new tool)

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.


Reply to: