Re: [gentoo-dev] extending metadata.xml to support CPE information

[Sven Vermeulen]

On Tue, May 07, 2013 at 11:59:18PM -0400, Mike Frysinger wrote:
> the guys who maintain the security CVE project [1] [2] (designed to be the
> authority when it comes to indexing security related vulnerabilities in
> projects) have a CPE specification [3] to make tracking CVEs back to a
> canonical source in a machine parseable format.
>
> the ChromiumOS project wants to be able to tie CPEs to a specific package.
> this would probably also be a good thing for our own security team to tie into
> the GLSA process.  the Debian project too is extending their database to
> include CPE information [4].
>
> we've already got a database for maintaining this sort of thing on a per-
> package basis: metadata.xml.  so let's extend the DTD to cover this.  the
> existing remote-id field looks like a pretty good fit, so the proposal is
> simple: add a new "cpe" type.  the entries for net-misc/curl would be:
> <upstream>
>  <remote-id type="cpe">cpe:/a:curl:curl</remote-id>
>  <remote-id type="cpe">cpe:/a:curl:libcurl</remote-id>
> </upstream>
>
> or the gzip package:
> <upstream>
>  <remote-id type="cpe">cpe:/a:gnu:gzip</remote-id>
> </upstream>
>
> for most packages, there will probably be only one cpe entry, but as you can
> see here, sometimes more than one can track back to a single package.
>
> we have some scripts running on the CrOS side to try and do an initial seed
> (at least, for all the packages we're using), so i'll probably take care of
> merging that into the main tree.  i'm not proposing this be required or
> anything (since not all packages will have one).

I'm all for it. We can then easily map CVEs against packages, especially if
the version structure we use in the ebuilds is the same one as used upstream
(so the remainder of the CPE with version can be easily obtained).

http://blog.siphos.be/2013/04/matching-packages-with-cves/

Wkr,
	Sven Vermeulen