Re: Dealing with CVEs that apply to unspecified package versions

[Leo Famulari]

On Mon, Mar 06, 2017 at 10:36:48PM +0100, Ludovic Courtès wrote:
> Unfortunately, there’s no way to know whether such CVEs are actually
> fixed at a specific package version or not, and they’re not uncommon.
> Consequently, ‘guix lint -c cve’ would now report old CVEs that possibly
> no longer apply to our package versions.

I didn't notice any change in what the CVE checker reports after
applying the diff. Did I miss a step?

> 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.

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 :)

signature.asc
Description: PGP signature