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). thoughts ? -mike [1] http://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures [2] http://cve.mitre.org/ [3] http://cpe.mitre.org/specification/ [4] http://wiki.debian.org/CPEtagPackagesDep
signature.asc
Description: This is a digitally signed message part.
