Auditing CPE names

Auditing CPE names

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

I wonder if anyone checks the Common Platform Enumeration (CPE) names of
new packages when creating them?

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.

There is an example of setting the cpe-name in the package definition of
isc-dhcp, where the cpe-name is 'dhcp'.

Maybe we should audit the whole package set to find packages that appear
to not be covered by CPE.

https://nvd.nist.gov/cpe.cfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Auditing CPE names

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> I wonder if anyone checks the Common Platform Enumeration (CPE) names of
> new packages when creating them?
>
> 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.
>
> There is an example of setting the cpe-name in the package definition of
> isc-dhcp, where the cpe-name is 'dhcp'.
>
> Maybe we should audit the whole package set to find packages that appear
> to not be covered by CPE.

I think it’s a good idea, everyone should check whether important
packages are covered.

Packages that are definitely not covered are those for which we add a
prefix to the upstream name, such as “python-”.  We could tell ‘guix
lint -c cve’ to strip common prefixes like this one, but I suspect this
won’t be enough.

Thoughts?

Ludo’.

Re: Auditing CPE names

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

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.

Any ideas?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Auditing CPE names

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> 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’.