Re: Dealing with renamed source packages during CVE triaging
On 2018-06-15 10:27:45, Moritz Muehlenhoff wrote:
> 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:
>> 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.
Maybe the same principle applies as with the approach I considered. We
could have a --stop argument that would consider entries up to a certain
CVE number and ignore the rest of the file.
> Lots of the false positives will result from crappy/outdated entries
> in embedded-code-copies, so fixing those up will drastically reduce
> false positives.
If the embedded-code-copies is used more systematically, with a
semi-automated script, in the triaging process, we'll be more inclined
to keep it up to date as well so I think it would actually help with
that as well...
bam: do you want me to start working on that script or were you working
on this already?
Thanks for the feedback,
Ils versent un pauvre miel sur leurs mots pourris et te parlent de pénurie
Et sur ta faim, sur tes amis, ils aiguisent leur appétit
- Richard Desjardins, La maison est ouverte