I've noticed this by looking at the output of my symbols collision script: Symbol PyBaseObject_Type@@ (32-bit UNIX System V ABI Intel 80386) present 30 times /usr/games/bin/diameter /usr/bin/vim /usr/bin/gedit /usr/lib/root/libPyROOT.so.5.22 /usr/lib/python2.5/site-packages/opencv/_highgui.so /usr/lib/libpython2.5.so.1.0 /usr/bin/eog /usr/games/lib/mcl/plugins/python.so /usr/sbin/bextract /usr/bin/zapping /usr/lib/python2.5/site-packages/opencv/_cv.so /usr/bin/gvim /usr/bin/gwp /usr/bin/cooledit /usr/lib/planner/plugins/libpython-plugin.so /usr/sbin/bacula-fd /usr/sbin/bacula-sd /usr/lib/dia/libpython_plugin.so /usr/lib/xchat/plugins/python.so /usr/lib/xchat-gnome/plugins/python.so /usr/sbin/bacula-dir /usr/lib/gnumeric/1.8.3/plugins/python-loader/python_loader.so /usr/games/bin/adonthell /usr/games/bin/kiki /usr/lib/libgnt.so.0.0.0 /usr/bin/epiphany /usr/lib/python2.5/site-packages/_lcms.so /usr/lib/perl5/vendor_perl/5.8.8/i686-linux/auto/Inline/Python/Python.so /usr/lib/apache2/modules/mod_wsgi.so /usr/lib/apache2/modules/mod_python.so These files don't link to libpython2.5.so but rather to the .a. I've debugged this with eog: flame@yamato eog-2.24.2 % egrep ^PYTHON_ Makefile PYTHON_CFLAGS = -I/usr/include/python2.5 PYTHON_EXEC_PREFIX = ${exec_prefix} PYTHON_EXTRA_LIBS = -lpthread -ldl -lutil PYTHON_LIBS = -lpython2.5 PYTHON_LIB_LOC = -L/usr/lib/python2.5/config PYTHON_PLATFORM = linux2 PYTHON_PREFIX = ${prefix} PYTHON_VERSION = 2.5 since -L/usr/lib/python2.5/config -lpython2.5 is passed, that path is searched first, but then: flame@yamato eog-2.24.2 % ls -l /usr/lib/{,python2.5/config/}libpython2.5.* lrwxrwxrwx 1 root root 19 2008-12-10 11:16 /usr/lib/libpython2.5.so -> libpython2.5.so.1.0 -r-xr-xr-x 1 root root 1472168 2008-12-10 11:15 /usr/lib/libpython2.5.so.1.0 -rw-r--r-- 1 root root 2617334 2008-12-10 11:15 /usr/lib/python2.5/config/libpython2.5.a The two libraries, static and dynamic, should be put in the same path, whichever it is.
Hey this can be fun, since if you got these packages built with older Pyhton vulnerable to GLSA 200807-16, you might still have vulnerable packages in the system. Pretty nice considering that mod_python and mod_wsgi are involved.
Interestingly enough this might actually involve other distributions. At least Fedora 10 comes with the same layout for libpython2.5.so and libpython2.5.a. I'm having trouble to find the other files in Fedora though to check if it is actually vulnerable to this kind of problems out of the box. On the other hand binary distributions might as well release all the packages from scratch every time, but I wouldn't be sure about that.
Okay just checked the Python plugin for xchat and in Fedora it's not vulnerable so it might as well be they are not vulnerable _for their packages_ to the issue. But I'm sure that if someone compiled the rest of the packages outside of the RPMs it's going to have the same issues.
Python team, please advise. Could you provide an updated ebuild please?
You can find packages that need rebuilding and using this command: # scanelf -q -s +Py_Initialize /{,usr/}{bin,sbin,lib32,lib64} /usr/libexec \ | fgrep -v python2. | awk '{ print $2 }' \ | qfile -q -e -C -f - | sed -e "s:^:=:g" \ | xargs echo emerge -1av
python: is this going to be fixed for python 2.4 and 2.6 as well?
The patch, which fixes this bug, has been included in 2.5.4-r3 and 2.6.2-r1. I hope that upstream will accept this patch or similar.
Uhh I just noticed there's a missing -R in the scanelf commandline. Also, Python team, you might want to replace at least part of the manual checks with that.
(In reply to comment #8) > you might want to replace at least part of the manual checks with that. Which checks do you mean?
python-updater.
