I've come across a few posts on forums (Gentoo and elsewhere) asking why Gentoo doesn't make security-related patches on the tree. Some people think this is the case because they do not notice (m)any GLSAs, which are Gentoo's security advisories. However, it isn't that Gentoo doesn't push out security fixes - it is a matter of putting the necessary human resources against it to write down the GLSAs.

Gentoo is often quick with creating the necessary ebuilds for newer versions of software. And newer versions often contain security fixes that mitigate problems detected in earlier versions. So by keeping your system up to date, you get those security fixes as well. But without GLSA, it is difficult to really know which packages are necessary and which aren't, let alone be aware that there are potential problems with your system.

I already captured one of those needs through the cvechecker application, so I took a step further and wrote an extremely ugly script (it's so ugly, it would spontaneously become a joke of itself when published) which compiles a list of potential CPEs (identifiers for products used in CVEs) from the Gentoo package list (ugliness 1: it assumes that the package name is the product name). It then tries to assume what the version of that software is based on the ebuild version (ugliness 2: it just takes the a.b.c number). Then, it lists the CVEs affiliated with a particular package, and checks this list with the list of CVEs from an earlier version (ugliness 3: it requires the previous, vulnerable version to still be in the tree). If one of the CVEs has "disappeared", it will report that the given package might fix that CVE. Oh, and if the CVE has a CPE that contains more than just a version, the script ignores it (ugliness 4). And it probably ignores a lot of other things as well while not checking the input (ugliness 5 and higher).

But if we ignore all that, what does that give for the Gentoo portage tree for the last 7 days? In other words, what releases have been made on the tree that might contain security fixes (and that do comply with the above ugliness)?

app-editors/emacs-23.4-r5 might fix CVE-2010-0825
app-editors/emacs-24.2-r1 might fix CVE-2012-0035
app-editors/emacs-24.2-r1 might fix CVE-2012-3479
dev-lang/python-2.6.8-r1 might fix CVE-2010-3492
dev-lang/python-2.6.8-r1 might fix CVE-2011-1521
dev-lang/python-2.6.8-r1 might fix CVE-2012-0845
dev-lang/python-2.6.8-r1 might fix CVE-2012-1150
dev-lang/python-2.6.8-r1 might fix CVE-2008-5983
dev-php/smarty-2.6.27 might fix CVE-2009-5052
dev-php/smarty-2.6.27 might fix CVE-2009-5053
dev-php/smarty-2.6.27 might fix CVE-2009-5054
dev-php/smarty-2.6.27 might fix CVE-2010-4722
dev-php/smarty-2.6.27 might fix CVE-2010-4723
dev-php/smarty-2.6.27 might fix CVE-2010-4724
dev-php/smarty-2.6.27 might fix CVE-2010-4725
dev-php/smarty-2.6.27 might fix CVE-2010-4726
dev-php/smarty-2.6.27 might fix CVE-2010-4727
dev-php/smarty-2.6.27 might fix CVE-2012-4277
dev-php/smarty-2.6.27 might fix CVE-2012-4437
media-sound/rhythmbox-2.97 might fix CVE-2012-3355
net-im/empathy-3.6.3 might fix CVE-2011-3635
net-im/empathy-3.6.3 might fix CVE-2011-4170
sys-cluster/glusterfs-3.3.1-r2 might fix CVE-2012-4417
www-client/seamonkey-2.17 might fix CVE-2013-0788
www-client/seamonkey-2.17 might fix CVE-2013-0789
www-client/seamonkey-2.17 might fix CVE-2013-0791
www-client/seamonkey-2.17 might fix CVE-2013-0792
www-client/seamonkey-2.17 might fix CVE-2013-0793
www-client/seamonkey-2.17 might fix CVE-2013-0794
www-client/seamonkey-2.17 might fix CVE-2013-0795
www-client/seamonkey-2.17 might fix CVE-2013-0796
www-client/seamonkey-2.17 might fix CVE-2013-0797
www-client/seamonkey-2.17 might fix CVE-2013-0800

As you can see, there is still a lot of work to remove bad ones (and add matches for non-default ones), but at least it gives an impression (especially those that have CVEs of 2012 or even 2013 are noteworthy), which is the purpose of this post.

It would be very neat if ebuilds, or the package metadata, could give pointers on the CPEs. That way, it would be much easier to check a system for known vulnerabilities through the (publicly) available CVE databases as we then only have to do simple matching. A glsa-check-ng (what's in a name) script would then construct the necessary CPEs based on the installed package list (and the metadata on it), check if there are CVEs against it, and if there are, see if a newer version of the same package is available that has no (or fewer) CVEs assigned to it.

Perhaps someone can create a GSoC proposal out of that?