From what I can gather the CPE list is used for Debian which is discussed briefly http://lists.debian.org/debian-devel/2011/02/msg00005.html the list is used to check that the NVD CVE lists match up to Debian advisories, ie to catch any missing vulnerabilities/packages in CVE but not in Debian.
 
I have created the CPE list for Fedora 13. There are only about 300 entries due partly to the fact that Debian's CPE list only contains about 1100 entries/packages.
 
https://github.com/silviocesare/Equivalent-Packages/blob/master/CPE/Fedora13.CPE.generated
Visually looking over the results, it seems fairly reasonable for much of the data. Some entries are clearly wrong and would need to be corrected. I'm not expecting to Fedora to necessarily use this list, but it's there if you want to.
 
Incidentally, a CPE list has uses in other applications besides security. It seems cross distro app installers want CPE info or package equivalencies, eg http://lists.debian.org/debian-devel/2011/01/msg00676.html
 
--
Silvio

On Tue, Feb 1, 2011 at 1:13 AM, Tomas Hoger <thoger@redhat.com> wrote:
Hi Silvio!

On Mon, 31 Jan 2011 19:21:39 +1100 Silvio Cesare wrote:

> Debian maintain a list of CPE inormation for packages on their
> security tracker
> http://svn.debian.org/wsvn/secure-testing/data/CPE/list

We currently do not use CPE names for security tracking in Fedora, so
I don't see an obvious benefit maintaining such list.  Can you explain
briefly how you use it for Debian security tracking and what benefits
it brings?

> This makes it relatively static except when packages are added or
> removed from the repository.

It's not that uncommon to see new packages added to Fedora repositories
even after the release of some Fedora version.

> In the past I generated an automatic mapping between packages in
> Debian and Fedora
> https://github.com/silviocesare/Equivalent-Packages/blob/master/NearestNeighbour/Debian5_Fedora13_Matches

I played a little more with this list and noticed few problems:
- quite a few Debian packages map to Fedora arptools or binclock.
 Probably packages with not much sources, where other file (license,
 configure) confuse your tool to match unrelated packages
- there does not seem to be a good way to list cases where multiple
 components contain the same sources.  In Fedora, mingw32-* packages
 are a good example, and the list often maps Debian package foo to
 Fedora package mingw32-foo, while there is Fedora package foo that
 should be similarly good match.  Another example is
 zlib:arm-gp2x-linux-zlib.

Did you review "unexpected matches" to see if the sources are really
similar, and how the match is picked when there are multiple "good
candidates"?

--
Tomas Hoger / Red Hat Security Response Team