Bug 60926 – glsa-check fails to detect that the system might be affected ([N]), when the GLSA applies to different version numbers of the package for different architectures, such as with glsa200408-16, probably caused by error in parse method in glsa.py

• Status: RESOLVED FIXED
• Product: Portage Development

[Description Marnix Kaart 2004-08-19 12:46:49 UTC]

after the announcement of glsa200408-16 (glibc), i noticed that glsa-check failed to detect that i have a version of glibc installed that is vulnerable. I have glibc version 2.3.3.20040420 and the glsa indicates that for x86 architectures all version <= 2.3.3.20040420 should be upgraded to >= 2.3.3.20040420-r1.

after further investigation i found that typing glsa-check -d 200408-16 also does not show the correct output for the glsa. It only mentioned the entry for ppc64.

I decided to have a look inside glsa.py and i found that the following code might be the problem:

<code>
self.packages = {}
        for p in self.affected.getElementsByTagName("package"):
            name = p.getAttribute("name")
            self.packages[name] = {}
            self.packages[name]["arch"] = p.getAttribute("arch")
            self.packages[name]["auto"] = (p.getAttribute("auto") == "yes")
            self.packages[name]["vul_vers"] = [makeVersion(v) for v in p.getElementsByTagName("vulnerable")]
            self.packages[name]["unaff_vers"] = [makeVersion(v) for v in p.getElementsByTagName("unaffected")]
            self.packages[name]["vul_atoms"] = [makeAtom(name, v) for v in p.getElementsByTagName("vulnerable")]
            self.packages[name]["unaff_atoms"] = [makeAtom(name, v) for v in p.getElementsByTagName("unaffected")]
</code>

as you can see, the name of the package is used as key in the dictionary, but since the name of the package is the same for all architectures, the same slot in the dictionary is overwritten on the parsing of the subsequent "package" elements. This might explain why only the last entry is shown and this also might explain why glsa-check fails to properly detect the applicability of this glsa on my system. 

i consider myself as a intermediate programmer, so correct me if i'm wrong, but maybe it would be an idea to use the tuple (name,arch) as key in the self.packages dictionary? That would probably require some rewriting of the code here and there, but it would prevent subsequent entries with the same name for a different architecture to overwrite the entry in the dictionary.

feel free to contact me at [e-mail] if i have not been completely clear or if my help is desired (although i say again that i consider myself as an intermediate programmer at the most)

thanks,

Marnix Kaart

Reproducible: Always
Steps to Reproduce:
1. glsa-check -t 200408-16
2.
3.

Actual Results:  
output:

WARNING: This tool is completely new and not very tested, so it should not be
used on production systems. It's mainly a test tool for the new GLSA release
and distribution system, it's functionality will later be merged into emerge
and equery.
Please read http://www.gentoo.org/proj/en/portage/glsa-integration.xml
before using this tool AND before reporting a bug.

This system is not affected by any of the listed GLSA


Expected Results:  
it should have stated that i might be affected by this glsa, something like this:

200408-16 [N] glibc: Information leak with LD_DEBUG ( sys-libs/glibc )


reed root # emerge info
Portage 2.0.50-r9 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0,
2.4.26-gentoo-r5)
=================================================================
System uname: 2.4.26-gentoo-r5 i586 Pentium MMX
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r3
Automake: sys-devel/automake-1.8.3
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -march=pentium-mmx -pipe -fomit-frame-pointer"
CHOST="i386-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=pentium-mmx -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/
http://ftp.snt.utwente.nl/pub/os/linux/gentoo
http://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/
http://gentoo.tiscali.nl/gentoo/ ftp://ftp.tiscali.nl/pub/mirror/gentoo
ftp://mirror.scarlet-internet.nl/pub/gentoo ftp://ftp.easynet.nl/mirror/gentoo/
ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo
ftp://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://192.168.55.2/gentoo-portage"
USE="apache2 berkdb crypt gd gd-external gdbm gif jpeg libg++ maildir mysql
ncurses nls pam perl php png python readline slang spell ssl truetype x86 xml2 zlib"

[Comment 1 Marius Mauch (RETIRED) 2004-08-19 13:02:58 UTC]

*** Bug 60928 has been marked as a duplicate of this bug. ***

[Comment 2 Marius Mauch (RETIRED) 2004-08-19 13:03:23 UTC]

*** Bug 60927 has been marked as a duplicate of this bug. ***

[Comment 3 Marnix Kaart 2004-08-19 13:08:40 UTC]

(i apologize for duplicate bugs, although i do not know what caused this)

[Comment 4 Marius Mauch (RETIRED) 2004-08-21 11:50:42 UTC]

I should really get around to release my fixes ...

[Comment 5 Marnix Kaart 2004-09-12 00:50:12 UTC]

Is there any news on when you expect to release your fixes?

Thanks!

[Comment 6 Marius Mauch (RETIRED) 2004-10-10 15:57:39 UTC]

should be fixed in gentoolkit-0.2.0_pre10