[Raphael Geissert] > It would be great if anyone could make any progress on that.
Yeah. > Some time ago it was mentioned as a possible way to automate the > processing of new CVE ids (i.e. when MITRE publishes the description > and other info) and to detect incorrect Not-For-Us entries in the > security tracker. Yes. I did a quick implementation here at the university for tracking our localy maintained software, and today mapped around 150 package/version pairs to CPEs allowing me to see which of our packages had known security holes. > One way to get started is by using the tracker's list of affected > packages per CVE and match them with the CPEs provided by MITRE. It > would be even better if in the future that information is provided > by source packages themselves. I suspect doing it manually is just as easy for now. The 2240 entries in my /var/lib/debsecan/history file only represent 293 binary packages, which should be quick to look up in the CPE dictionary. If it is to be stored in the source package, I suspect putting it directly in the control file alongside the homepage URL make most sense. It would allow anyone to figure out relevant CVEs and make it trivial to compare Debian and Ubuntu derivatives for the packages originating from Debian. Perhaps something like: Xs-CPE: cpe:/a:bash:bash in debian/control would do it? To get a versioned CPE, ":$version" could be appended. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2fl39ogais0....@login1.uio.no
