The security announcement for the recent zlib dos vulnerability advises using revdep-rebuild to rebuild any packages which depend on the older version of zlib. This however does *not* rebuild packages which have been statically linked to the package. Reproducible: Always Steps to Reproduce: 1. emerge -av zlib 2. revdep-rebuild Actual Results: localhost etc # qpkg -q zlib sys-libs/zlib-1.2.1-r3 * DEPENDED ON BY: gnupg-1.2.5 ghostscript-7.07.1-r5 mysql-4.0.20 python-2.3.4 libxml2-2.6.12 python-fchksum-1.7.1 libgnomeprint-2.6.2 libgsf-1.10.0 yelp-2.6.1 mozilla-thunderbird-0.7.3-r1 gimp-2.0.4 graphviz-1.12-r1 imagemagick-6.0.5.2 inkscape-0.39 freetype-2.1.5-r1 gd-2.0.28 lcms-1.12 libmng-1.0.8 libmpeg3-1.5.2 libpng-1.2.5-r8 libwmf-0.2.8.2 netpbm-10.20 tiff-3.6.1-r1 openssh-3.9_p1 apache-2.0.50 lynx-2.8.5 module-init-tools-3.0-r2 gcc-3.3.4-r1 xorg-x11-6.7.0-r2 qt-3.3.3 ttmkfdir-3.0.9-r1 xscreensaver-4.16 SYSTEM PROFILE Expected Results: I don't know if there is a tool that will properly rebuild those. If so, that should be mentioned in a security announcement. If not, the lack of a proper tool should be mentioned, as well as any upgrading suggestions or processes. This seems rather important -- apache, for example, would be a prime target for a DoS exploit. Portage 2.0.50-r10 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r0, 2.6.8-gentoo-r1) ================================================================= System uname: 2.6.8-gentoo-r1 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz Gentoo Base System version 1.5.3 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-Os -march=i686 -mcpu=i686 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -march=i686 -mcpu=i686 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox userpriv" GENTOO_MIRRORS="http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow X acpi aim alsa apache2 apm avi berkdb bindist bzlib calendar cdr crypt curl curlwrappers dba dga dio directfb divx4linux doc dvd dvdr encode exif fbcon flac flash foomaticdb gd gdbm gif gnome gpm gtk gtk2 gtkhtml icq imagemagick imlib jabber java jbig jikes joystick jpeg kde ldap libg++ libwww mad mbox mikmod mime ming mmap mmx mng motif mozilla mpeg msn mysql ncurses nls oggvorbis opengl oscar oss pam pdflib perl php pic png posix python qt quicktime readline sasl sdl slang spell spl sse ssl svg svga tcltk tcpd tiff tokenizer truetype unicode usb videos wmf x86 xinerama xml xml2 xmms xpm xv xvid yahoo zlib"
Some of those packages may not even be statically linked, but only depending on the shared zlib-library. To find all static linked things, there's a tool from official zlib.net: http://cert.uni-stuttgart.de/files/fw/find-zlib
agree we should at least note in the GLSA that statically compiled packages won't be captured by this. We should update the zlib glsa on the web site. don't need an errata on this one.
I'm not sure how to handle this. There are three cases : 1/ packages with zlib dynamically linked in all cases That's the case of most of the packages (if not all) listed here. They will be caught by revdep-rebuild if needed. 2/ packages with zlib statically linked in all cases There shouldn't be any package of this type in portage. If there are (like the statically included neon libs in openoffice or sitecopy) these packages should be included in the zlib advisory as affected (please file security bugs if you find some). 3/ packages with zlib dynamically or statically compiled depending on the "static" USE flag presence. Those would still be affected even with a revdep-rebuild. But I'm not sure it's the point of the GLSA to worry everyone with a very complex explanations about that situation just to take care of that small percentage of expert users deliberately choosing the static USE flag. They should know it makes it nearly impossible for them to be sure they are protected. Maybe that should be clearly stated in the static USE flag description that it makes people using it out of reach of GLSA instructions. If someone finds a wording that won't cast unnecessary fear on casual users, I'll take it :)
And as a sidenote to the reporter, the fact that revdep-rebuild doesn't rebuild all packages that have a zlib dependance is not a bug, it's normal. You only need to rebuild executables with dynamically-linked libraries if there is a big change in the library (like a filename change or new functions). So if you used a recent version of zlib (same name and same definition, only small security fix), it's quite normal that revdep-rebuild doesn't do anything. That's the whole point of DLLs : not to require everything to be rebuilt all the time.
OK -- in the future, I recommend using a sentence similar to the following on all GLSAs where this type of issue applies: "Packages which depend on this libarary may need to be recompiled. Tools such as revdep-rebuild may assist in identifying some of these packages."
Amen. Sentence added to GLSA coordinator guide.
