[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Auditing CPE names
From: |
Ludovic Courtès |
Subject: |
Re: Auditing CPE names |
Date: |
Mon, 13 Feb 2017 15:26:32 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Leo Famulari <address@hidden> skribis:
> On Sat, Feb 11, 2017 at 02:53:46PM -0500, Leo Famulari wrote:
>> It's important to name the package in accordance with the CPE or set
>> the cpe-name property, or else `guix lint -c cve` won't work for that
>> package.
>
> In commit 84b60a7cdfc (gnu: lcms: Fix an out-of-bounds read.) I tried to
> set the cpe-name but couldn't get it to work, and then I forgot to
> remove it from the commit message before pushing.
>
> Anyways, I still can't get it to work after trying again today.
>
> This package should be reported as vulnerable to CVE-2016-10165. The CVE
> database for 2016 includes this line in the entry for that CVE:
>
> <cpe-lang:fact-ref name="cpe:/a:littlecms:little_cms_color_engine"/>
>
> But when setting the cpe-name to little_cms_color_engine, the linter
> still doesn't report the vulnerability.
The vulnerability isn’t in ~/.cache/guix/cve/* AFAICS.
I grabbed
https://static.nvd.nist.gov/feeds/xml/cve/nvdcve-2.0-2016.xml.gz and the
reason is that the CPE string above doesn’t specify a version string,
whereas the regexp in (guix cve) expects a version string, like
cpe:/a:littlecms:little_cms_color_engine:123
So, a bug.
I’ll see what I can do before going on vacations.
There may well be other bugs of this style, so whenever ‘guix lint’
doesn’t report a CVE, it’s a good idea to check whether the bug is just
not in the XML file yet, or whether there’s a genuine bug.
Thanks!
Ludo’.