On Fri, Jun 15, 2018 at 04:34:14PM +1000, Brian May wrote: > Moritz Muehlenhoff <j...@inutil.org> writes: > > > On Wed, Jun 13, 2018 at 05:19:40PM +1000, Brian May wrote: > >> "as I said in the mailing list discussion, I don't like the usage of the > >> undetermined tag... we use it to hide stuff we can't investigate under > >> the carpet, I would much prefer that we put it as <removed> directly > >> when it's the case, or <unfixed> otherwise." > > > > Of course, those can be resolved; it just needs someone to do the analysis > > work. > > Switching to some other tags (and incorrect ones!) doesn't change anything. > > Seems like this a mute point anyway, as from the comments you left in > the pull request, you don't like this approach of automatically adding > entries in data/CVE/list. Fair enough. > > So we could write a script, lets say: > bin/list-potential-packages-affected-by-code-copies
You're mixing two things; my comment above refers to <undetermined>, those are one-off investigations and don't need any particular tooling. > That generates a report of all packages that we need to check. I assume > we would need some way of marking packages that we have checked and > found to be not affected, so we can get a list of packages that need > immediate attention and don't repeatedly check the same package multiple > times. How should we do this? Maybe another file in the security tracker > repository? Maybe start with the script initially and see whether it's useful as an approach in general. State tracking can be discussed/added later. Lots of the false positives will result from crappy/outdated entries in embedded-code-copies, so fixing those up will drastically reduce false positives. Cheers, Moritz