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