| 1 |
the guys who maintain the security CVE project [1] [2] (designed to be the |
| 2 |
authority when it comes to indexing security related vulnerabilities in |
| 3 |
projects) have a CPE specification [3] to make tracking CVEs back to a |
| 4 |
canonical source in a machine parseable format. |
| 5 |
|
| 6 |
the ChromiumOS project wants to be able to tie CPEs to a specific package. |
| 7 |
this would probably also be a good thing for our own security team to tie into |
| 8 |
the GLSA process. the Debian project too is extending their database to |
| 9 |
include CPE information [4]. |
| 10 |
|
| 11 |
we've already got a database for maintaining this sort of thing on a per- |
| 12 |
package basis: metadata.xml. so let's extend the DTD to cover this. the |
| 13 |
existing remote-id field looks like a pretty good fit, so the proposal is |
| 14 |
simple: add a new "cpe" type. the entries for net-misc/curl would be: |
| 15 |
<upstream> |
| 16 |
<remote-id type="cpe">cpe:/a:curl:curl</remote-id> |
| 17 |
<remote-id type="cpe">cpe:/a:curl:libcurl</remote-id> |
| 18 |
</upstream> |
| 19 |
|
| 20 |
or the gzip package: |
| 21 |
<upstream> |
| 22 |
<remote-id type="cpe">cpe:/a:gnu:gzip</remote-id> |
| 23 |
</upstream> |
| 24 |
|
| 25 |
for most packages, there will probably be only one cpe entry, but as you can |
| 26 |
see here, sometimes more than one can track back to a single package. |
| 27 |
|
| 28 |
we have some scripts running on the CrOS side to try and do an initial seed |
| 29 |
(at least, for all the packages we're using), so i'll probably take care of |
| 30 |
merging that into the main tree. i'm not proposing this be required or |
| 31 |
anything (since not all packages will have one). |
| 32 |
|
| 33 |
thoughts ? |
| 34 |
-mike |
| 35 |
|
| 36 |
[1] http://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures |
| 37 |
[2] http://cve.mitre.org/ |
| 38 |
[3] http://cpe.mitre.org/specification/ |
| 39 |
[4] http://wiki.debian.org/CPEtagPackagesDep |
Archives