Re: Dealing with renamed source packages during CVE triaging
On Fri, Jun 15, 2018 at 04:34:14PM +1000, Brian May wrote:
> Moritz Muehlenhoff <firstname.lastname@example.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:
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
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