Bugzilla Bug 28021

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.