Emerging mod_php 4.3.10 and using the +hardenedphp flag, it appears the source code is not being patched with the hardenedphp patch. The php.ini file /etc/php/apache2-php4/php.ini shows no hardened configuration options (ie: varfilter.max_value_length , etc). Manually entering these configuration options will result in no action. Reproducible: Always Steps to Reproduce: 1. USE=hardenedphp emerge -v mod_php 2. /etc/init.d/apache2 restart 3. View /etc/php/apache2-php4/php.ini (no hardened options available) Actual Results: Hardened php options are not included with PHP Expected Results: Contain hardenedphp options in php, as stated at the hardenedphp site: http://www.hardened-php.net/documentation.php ---[ 1.5 - php.ini Directives ]----------------------------------- The behavior of Hardened-PHP's variable filter can be modified from within php.ini. There are currently 4 directives that control several aspects of variable filtering: varfilter.max_request_variables (default: 200) - The maximum number of variables that can be passed per request varfilter.max_varname_length (default: 64) - Maximum length for a variable name varfilter.max_value_length (default: 10000) - Maximum length for a variable value. varfilter.max_array_depth (default: 100) - Maximum depth of an Array. Portage 2.0.51-r3 (default-linux/x86/2004.0, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.4.26-gentoo-r13 i686) ================================================================= System uname: 2.4.26-gentoo-r13 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.4.16 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.19,sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" 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="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apache2 apm berkdb bitmap-fonts crypt curl encode esd f77 fam foomaticdb fortran gdbm gif gpm gtk gtk2 hardenedphp imagemagick imlib innodb jpeg ldap libg++ libwww mad mikmod motif mpeg mysql ncurses nls oggvorbis opengl openssh oss pam pdflib perl php png pwdb python qt quicktime readline samba sdl slang snmp spell sqlite ssl svga tcpd tiff truetype x86 xml2 xmms xv zlib"
Created attachment 46700 [details, diff] Patch to php-sapi.eclass to handle newer php and hardened-php versions This patch adds the correct hardened-php versions to the php-sapi.eclass for all versions of PHP4 currently on the portage tree, now that hardened-php is finally available for the more recent versions of PHP.
Added the patch to eclass.. now receiving digest error. Not sure if I need to create digest (emerge hardened-php-4.3.10-0.2.6.patch.gz digest) within /usr/portage/dev-php/mod_php. Can you advise? !!! No message digest entry found for file "hardened-php-4.3.10-0.2.6.patch.gz." !!! Most likely a temporary problem. Try 'emerge sync' again later. !!! If you are certain of the authenticity of the file then you may type !!! the following to generate a new digest: !!! ebuild /usr/portage/category/package/package-version.ebuild digest
Lou, You might want to try running ebuild /usr/portage/dev-php/mod_php/mod_php-4.3.10.ebuild digest as the error suggests
*** Bug 89155 has been marked as a duplicate of this bug. ***
Why is this trivial bug still unfixed?
That's a very good question. Comments?
Created attachment 57415 [details, diff] Updated patch to php-sapi.eclass to handle php-4.3.11 This is an updated version of the previous patch, adding support for php-4.3.11. Unfortunately, there seems to be a bug in portage preventing the eclass from correctly adding the address of the patch to SRC_URI.
Created attachment 57655 [details, diff] Working patch for php-4.3.11 The previous patch was faulty, this is the correct one. Still no workaround for the SRC_URI problem.
Right now we have #74552, #74880 (this one) and #89155 open basically for the same issue. Would someone look into this and fix the eclass, *please*. Thanks.
I agree that both this bug and #89155 cover the same problem; Bug #74552 is the same for php-5, which uses its own eclass, AFAIK. And it is really annoying to see these bugs unfixed, mainly because this is also a security problem. Right now, there is a useflag which should make a php installation more secure. But the ebuild/eclass (almost) silently fails to apply the patch and installs php anyway. (This could be fixed by using 'epatch ... || die' but that belongs into another bug, one yet to be filed. :) )
The php-sapi.eclass now has support for Hardened-PHP for PHP versions 4.3.9, 4.3.10, and 4.3.11.
