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"
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.
