So that ~30 or so additional CVEs that we’d need to look at.

>> In the patch, I added the ability to specify a ‘patched-vulnerabilities’
>> property to work around that (with Coreutils as an example).  The
>> downside is that we’d have to maintain these lists by ourselves, which
>> is not great, but might still be better than the status quo.
>
> Overall, I think it's better for the CVE checker to omit some CVEs than
> to show a large number of false positives. Otherwise people may not pay
> attention to it at all. And the CVE checker will never be authoritative;
> Guix developers have to look for security advisories from a wide variety
> of sources.
>
> I wonder if we could maintain the set 'patched-vulnerabilities' fields
> satisfactorily.
>
> Changing the subject, this implementation of 'patched-vulnerabilities'
> doesn't preserve the valuable information of how we know the
> vulnerability was fixed (patch?  update? only applicable to non-GNU
> platforms? et cetera).
>
> If we were to start collecting and curating this information, we should
> try to preserve it and make it useful to the other distros.

Right, we’d need to add a clear comment to each vulnerability that we
mark as patched.

> In that case, we could instead update the CVE database through MITRE's
> new CVE form, which recently became the only way to get new CVEs from
> MITRE:
>
> https://cveform.mitre.org
>
> I think the goal is to reduce the friction of requesting and amending
> CVEs. Let's try it :)

Yes, that’s what I thought.  But either way, that’s quite a bit of
non-trivial work.

What about raising the issue on oss-sec?  Ideally the QEMU folks would
take care of labeling QEMU’s CVEs, the libxml2 folks would take care of
theirs, etc.

Thanks for your feedback!

Ludo’.