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 <jmm@inutil.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
>> 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.
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,
A.
--
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
Reply to: