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