libspeex: GLSA 200804-17 unzip: GLSA 200804-06 zlib: uncountable
I'm attaching a patch to the ebuild and a patches tarball. The problems with the games-fps/openarena-0.8.1 ebuild in portage that my patch fixes: 1. CFLAGS The current ebuild first removes -fno-strict-aliasing in a patch then adds it back using sed. The current ebuild causes the user's CFLAGS to be specified twice in each command line (add V=1 to emake invocation to see). This was noted in bug 268851. 2. SPEEX It uses internal bundled libspeex and was unable to link against the system one. I added a link against libspeexdsp (a shared library built by the same package as libspeex) and now it links against the system speex. I have no idea how to test this, please test if void works. 3. LDFLAGS The makefile confusingly uses a variable named LDFLAGS to denoate the libs every executable should link against. The link step does not use the user's LDFLAGS, and portage does not even warn you. I have renamed that variable and added LDFLAGS to the right places. Now it links with --as-needed if you want it to. 4. ZLIB The package uses app-arch/unzip to build (the distfile is a zip), but does not use it at runtime so Flameeyes can stop worrying. What the package uses at runtime to access its data files (in zip files called .pak) is a very old version of minizip (http://www.winimage.com/zLibDll/minizip.html). The bundled version actually has the entire zlib-1.1.3 inside. I have removed the zlib and linked against system zlib. It is possible to replace the minizip with a modern version but I don't know what that would accomplish. The patch unfortunately contains the entire source of zlib-1.1.3 and this necessitated the use of a patch tarball. 5. JPEG The package bundles jpeg-6 (not the jpeg-6b which is in portage), with a modified reader (from a memory buffer rather than a FILE*). The bundled jpeg is configured with RGB_PIXELSIZE 4 rather than the default 3. This compile time option of libjpeg disables some functionality and thus is inadvisable for a system-wide installation. What it does is change the output of 24bpp images to 32bpp. The package relies on this functionality. I have fixed the reader to compile against system libjpeg headers and make the package link against system libjpeg. I have also added a bit of code to fix the RGB output from jpeg decompression to RGBA, to correctly use the system libjpeg. I have not measured any performance degradation due to this change, because texture decompression is a seldom occurrence and the operation is fast. 6. x86_64 COMPILED VM The package has a bytecode VM for game scripts. There is an interpreter suitable for any architecture and a special assembly coded version for 32 and 64 bit x86. The makefile relies on the variable ARCH being x86_64 to decide that this architecture has a the compiled VM and use it instead of the interpreter. Portage sets this variable to "amd64", so the interpreter is used instead. Watch the stdout from running the game to see the corresponding messages. I have fixed this and now the compiled VM is used. Measured consistent speedup from 169 to 172 frames per second. Obviously the game can't really tax a modern 64bit cpu. 7. rm bundled libraries To make sure bundled libraries' code is not used, I used the idea from the alternate ebuild attached to bug 245759 and rm'd as much as possible.
Created attachment 198720 [details, diff] patch to the ebuild (update dependencies, use patch tarball, etc.)
Created attachment 198721 [details] patch tarball, because patches are over 100K
Security, since we got some patches from Zeev, can we consider boosting this?
# Samuli Suominen <ssuominen@gentoo.org> (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. zlib, jpeg, speex and likely # others # # http://bugs.gentoo.org/show_bug.cgi?id=255453 # # Masked for removal in 60 days. games-fps/openarena
Dear security team: Why not apply my patch instead of deleting the ebuild? Have you looked at it? It's not big - the size is because it removes the entire source of zlib, the actual changes for review are pretty small.
Requesting permission to apply the patch
(In reply to comment #7) > Requesting permission to apply the patch > Please Do.
(In reply to comment #7) > Requesting permission to apply the patch > Yes, please. You might want to drop in #gentoo-games to review the commit before committing, though (In reply to comment #6) > It's not big - the size is because it removes the entire source of zlib, the Why delete it from the source tree, if the build system is patched to ignore it? Or you can rm -rf in the ebuild them.
> (In reply to comment #6) > > It's not big - the size is because it removes the entire source of zlib, the > > Why delete it from the source tree, if the build system is patched to ignore > it? Or you can rm -rf in the ebuild them. This difficult to do beacause entire zlib source code included in one file unzip.c (bad, really bad). I tested patch, code/qcommon/unzip.c after patching have about 35K. I think better just replace original file with patched one.
(In reply to comment #9) > (In reply to comment #7) > > Requesting permission to apply the patch > > > > Yes, please. You might want to drop in #gentoo-games to review the commit > before committing, though e source tree, if the build system is patched to ignore > it? Or you can rm -rf in the ebuild them. > Review what? The patches are here. All I will do is to apply them and get rid of this bug
(In reply to comment #11) > (In reply to comment #9) > > (In reply to comment #7) > > > Requesting permission to apply the patch > > > > > > > Yes, please. You might want to drop in #gentoo-games to review the commit > > before committing, though > e source tree, if the build system is patched to ignore > > it? Or you can rm -rf in the ebuild them. > > > > Review what? The patches are here. All I will do is to apply them and get rid > of this bug > Please wait. I will get on it this week. Promise
I committed a fix taking into account speex and zlib unbundling, taking the attached patches as an input. I will analyze all the other point the next days. Thanks
Not to be too picky, but shouldn't unmasking happen only after it's fully fixed ?
If that fixes the forementioned vulnerability libspeex: GLSA 200804-17 unzip: GLSA 200804-06 zlib: uncountable I think it should be unmasked. Not sure about the unzip vulnerability. Does it get fixed just replacing the zlib?
now it is using system media-libs/jpeg. So the bug as for summary is to be considered closed It stay open only for the other items zeev raised
Fixed usage of vm for amd64 arch.
Fixing the remaining issues on LDFLAGS and CFLAGS.
