I think I've found a bug in zlib's gzprintf. I'm running an up-to-date gentoo (without ~x86 flags). I've already sent this issue to the zlib mantainers. This is the test program: ** gztest.c ** #include <zlib.h> #include <stdio.h> #include <stdlib.h> int main() { gzFile gzfp = gzopen("testgz.gz","wb"); gzprintf(gzfp,"A%c%c%cB",1,0,1); gzclose(gzfp); system("gunzip -f testgz.gz"); FILE * fp = fopen("testplain","wb"); fprintf(fp,"A%c%c%cB",1,0,1); fclose(fp); } ** end of file ** now compile and launch it: #gcc -o gztest gztest.c -lz #./gztest and examine the two files with an hex editor. gzprintf considers a %c argument with value 0 as an end-of-string in the format string. The obvious workaround is to use gzputc, or sprintf and then gzwrite. NOTE: I'm not sure, but I think this doesn't happen with RedHat 9. Please check. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.49-r3 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1, 2.4.22) ================================================================= System uname: 2.4.22 i686 AMD Athlon(TM) XP 2000+ ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=athlon-xp -march=athlon-xp -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -fexpensive-optimizations -mmmx -msse -m3dnow -mfpmath=sse" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O3 -mcpu=athlon-xp -march=athlon-xp -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -fexpensive-optimizations -mmmx -msse -m3dnow -mfpmath=sse" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 oss apm avi crypt encode foomaticdb jpeg libg++ mad mikmod mpeg ncurses nls pdflib png quicktime spell truetype xmms xv zlib gdbm berkdb slang readline arts tetex bonobo svga java X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gnome gtk qt kde motif opengl 3dnow aalib cdr cups directfb dga doc dvb faad fbcon ggi gif gphoto2 gtk2 guile jikes lcms ldap mmx mozaccess mozcalendar mozilla mozp3p mozsvg mozxmlterm mysql offensive parse-clocks samba scanner slp sse tcltk tiff v4l wmf wxwindows xml xml2 xvid"
The fix for this bug is to remove CFLAGS="${CFLAGS}" which appears as an argument to emake. Supplying it overrides the additions made by configure. As a consequence the #ifdefs of the security patch are not taken into account.
Let me see if I got it straight: zlib-1.1.4 has a security bug that you have fixed with a patch. However, if I specify any CFLAGS in make.conf when building zlib, that patch isn't applied since my CFLAGS overwrite the CFLAGS="-DAPPLY_SECURITY_PATCH" or like that supplied by the ebuild (or the configure) file. As a result, *no user* has the patch installed, as *all users* use their own CFLAGS. (I *really* hope I misunderstood). So why in heaven don't you just *append* your CFLAGS to the global ones????
firstly: it's not my patch. I am just helping track down the problem you reported. :-) the ebuild contains the lines: ./configure --shared --prefix=/usr || die append-flags -fPIC emake CFLAGS="${CFLAGS}" || die the argument CFLAGS="${CFLAGS}" precisely takes into account the user's CFLAGS, but overrides the additions computed by configure (which is patched) and which are intended to select the correct #ifdef alternatives of some parts of the security patch. It is this argument which should be removed. I have no idea why it was put in in the first place.
Fixed in -r2, thanks.
