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