[Secure-testing-team] Comparing NVD and Debian CVE tracking

[Petter Reinholdtsen]

[Yves-Alexis Perez]
> Btw I wonder if the CPE names could be matched against packages
> names the same way packages are matched accross distros (see the
> appinstaller meeting report by Enrico Zini:
> http://www.enricozini.org/2011/debian/distromatch/)

I'm sure it could be used for this.

There are two hurdles to overcome.  First, there is no CPE for all the
packages in Debian (the focus has been on those with known security
issues.  Not a big problem, as the CPE dictionary is updated on
request.  We simply have to ask for new CPEs where they are missing.

The second problem is that the CPE usage in NVD and elsewhere is
slightly inconsistent.  Some programs are refered to using multiple
IDs.  Not quite sure why this could happen.  Here is an example:

  cpe:/a:interchange_development_group:interchange
  cpe:/a:icdevgroup:interchange

We can of course handle this too, by documenting CPE aliases.  I
suspect such duplicates should be reported to the people handing out
CPE IDs to try to get one of the IDs dropped and everyone to use only
one ID for a given project.

I find such duplicates by comparing the CVE database in Debian with
the CVE data base from NVD.

> What it needs is:
>
> ----
> The data it requires for a distribution should be rather straightforward
> to generate:
>
>      1. a file which maps binary package names to source package names
>      2. a file with the list of files in all the packages
> ----

The Packages list in the APT repository maps from binary to source
package name, so that is already available in Debian.

> (not sure if it's helpful either, we can keep the CPE/packages
> matching list in secure-testing repository and maintain it here)

I believe it is best to keep the CPE ids of Debian source packages in
each individual package source file, to increase the chance of keeping
it up-to-date and to allow those knowing the package best to control
the setting.  But for now I have settled for a central file, to get
started before a way to store it in the source package is in place.

Happy hacking,
-- 
Petter Reinholdtsen