Created attachment 304739 [details] build.log of gobject-introspection Looks like expat-2.1.0_beta2 breaks dev-lang/python[xml] parser? Upgrade to =dev-libs/expat-2.1.0_beta2 Try to emerge gobject-introspection Rebuilding dev-lang/python doesn't help.
[ebuild R *] dev-libs/expat-2.1.0_beta2 USE="unicode -examples -static-libs" 0 kB [ebuild R ] dev-lang/python-2.7.2-r3 USE="gdbm ipv6 ncurses readline sqlite ssl threads tk (wide-unicode) xml -berkdb -build -doc -examples -wininst" 0 kB [ebuild R ] dev-lang/python-3.2.2 USE="gdbm ipv6 ncurses readline sqlite ssl threads (wide-unicode) xml -build -doc -examples -tk -wininst" 0 kB [ebuild R ] dev-libs/gobject-introspection-1.30.0-r2 USE="-doc -test" 0 kB
Using expat-2.1.0_beta2: xmlwf -n /usr/share/gir-1.0/GLib-2.0.gir /usr/share/gir-1.0/GLib-2.0.gir:17:6: unbound prefix Using expat-2.0.1-r6: xmlwf -n /usr/share/gir-1.0/GLib-2.0.gir (no output). The prefix it complains about is the "xml" one: <doc xml:whitespace="preserve">Integer representing a day of the month; between 1 and http://www.w3.org/TR/REC-xml-names/#xmlReserved says: "The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and MUST NOT be bound to any other namespace name." So I think this is an expat bug. I haven't actually found the change in expat responsible for this yet, though.
The "xml" prefix is added to the relevant hash table quite early after parser creation, via a call to setContext(parser, implicitContext) in XML_ParserCreate_MM. The secret salt used with the hash table is initialized later, in XML_Parse or XML_ParseBuffer. This seems incorrect: the "xml" prefix is added to the prefixes hash table with the wrong salt, so lookups after the salt is initialized do not find it. And the secret salt is new in this version of expat, so that fits. Upstream (expat) needs to fix this properly though (obviously messing with this secret hash without knowing what I am doing could easily re-break the vulnerability the randomization is meant to fix). Can you file this upstream or would you prefer for me to do it?
I've gone ahead and reported it (see the URL now set) as I'm fairly certain I'm right. Will morph this bug if upstream agrees (as it's not a python bug then).
+ 10 Mar 2012; Samuli Suominen <ssuominen@gentoo.org> expat-2.1.0_beta2.ebuild, + +files/expat-2.1.0_beta2-move_setContext_call.patch: + Move call to setContext right after the setting of salt wrt #407555 using + upstream patch. Thanks to Marien Zwart for bisecting the issue.