GLSA 200906-03 / phpmyadmin (June 29, 2009, Impact: high, Exploitable: remote), specifies vulnerable versions to be <2.11.9.5, and glsa-check doesn't find it. # emerge -pq phpmyadmin [ebuild NS ] dev-db/phpmyadmin-2.11.9.5 [2.11.9.4] # glsa-check --print 200906-03 | head -n2 GLSA 200906-03: phpMyAdmin: Multiple vulnerabilities And now where it goes wrong, the detection.. # glsa-check --list affected [A] means this GLSA was already applied, [U] means the system is not affected and [N] indicates that the system might be affected. # glsa-check --test 200906-03 This system is not affected by any of the listed GLSAs # glsa-check --pretend 200906-03 Checking GLSA 200906-03 Nothing to do for this GLSA It could be related to the fact that every phpmyadmin version is slotted, as derfian and few also mentioned in #gentoo-portage, but i don't have the .5 installed at all. Reproducible: Always Steps to Reproduce: Reproduce by not installing the latest phpmyadmin, and glsa-check --list affected. Actual Results: Actual: No affected phpmyadmin. Expected Results: Expected: phpmyadmin needs to be upgraded. Background: I'm using glsa-check on my server to check and mail me affected GLSA's every night (it only mails me server updates once a week). This should've been in my mailbox, as the priority of the GLSA is high and remote.
# emerge --info Portage 2.1.6.13 (hardened/x86, gcc-3.4.6, glibc-2.9_p20081201-r2, 2.6.28-hardened-r9 i686) ================================================================= System uname: Linux-2.6.28-hardened-r9-i686-Intel-R-_Pentium-R-_4_CPU_2.80GHz-with-glibc2.3.2 Timestamp of tree: Thu, 02 Jul 2009 00:20:01 +0000 app-shells/bash: 3.2_p39 dev-lang/python: 2.5.4-r2 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.63 sys-devel/automake: 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe -fforce-addr" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=pentium4 -O2 -pipe -fforce-addr" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="nl_NL.utf8" LC_ALL="nl_NL.utf8" LDFLAGS="" LINGUAS="nl" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="caps hardened logrotate mmx nls no-old-linux nptl nptlonly pic readline sse sse2 ssl unicode userlocale x86" APACHE2_MODULES="authz_host autoindex dir mime vhost_alias rewrite log_config" APACHE2_MPMS="worker" ELIBC="glibc" KERNEL="linux" LINGUAS="nl" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
# emerge -pq gentoolkit [ebuild U ] app-portage/gentoolkit-0.2.4.5 [0.2.4.2-r1]
app-portage/gentoolkit-0.2.4.5's glsa-check still doesn't detect the phpmyadmin GLSA.
This works with =app-portage/gentoolkit-0.3.0_rc7.
Indeed! Bug fixed as far as i'm concerned. Thanks :)
But not for stable users.
There's two distinct issues are at play here: (1) glsa-check will not perform SLOT upgrades (2) glsa-check from gentoolkit-0.2* will show a system as vulnerable if no upgrade path exists Regarding both: (1) Actually, I was always thinking it did perform SLOT upgrades. Looking at the code again, I am sure it does not. For web-apps, it is clear that a SLOT upgrade is the way to go, together with uninstalling the old slot afterwards. What about a Python SLOT upgrade though? (2) has been fixed in gentoolkit 0.3 (see the list of commits at the end of this comment). This will cause glsa-check to say that there is no upgrade path, because of (1): $ glsa-check -p 200906-03 Checking GLSA 200906-03 >>> The following updates will be performed for this GLSA: >>> For the following packages, no upgrade path exists: dev-db/phpmyadmin-2.11.9.4 "emerge --update phpmyadmin" will show an upgrade path however. I suggest we change glsa-check so that it says that there is an upgrade path using another SLOT, but it tells to user to run the command and unmerge the old slot herself. commit 6a94d49b666a90d5911928bf584225e10265ea07 Author: Paul Varner <fuzzyray@gentoo.org> Date: Wed May 20 21:49:39 2009 +0000 Restructure system affection detection. Store "vulnerable" and "upgrade" packages in a table, and use that data to determine which packages cannot be upgraded, and which packages actually cause upgrades git-svn-id: svn+ssh://svn.gentoo.org/var/svnroot/gentoolkit/trunk/gentoolkit@648 e84c3a59-eaf8-0310-85df-8a9fcd7b4891 commit 7dab357c32681042353167cba45ef6732e392877 Author: Paul Varner <fuzzyray@gentoo.org> Date: Wed May 20 21:46:46 2009 +0000 Change behaviour of getMinUpgrade This allows to differentiate between situations where the system is unaffected and unexistance of an upgrade path. Previously, the glsa-check would treat GLSAs that had no upgrade path (such as mask glsas) as not affecting the system. git-svn-id: svn+ssh://svn.gentoo.org/var/svnroot/gentoolkit/trunk/gentoolkit@647 e84c3a59-eaf8-0310-85df-8a9fcd7b4891
Paul, can we close this bug as fixed now, since gentoolkit-0.2.x are no longer in the tree?
Fixed in the gentoolkit-0.3 releases
