[PHP-BUG] Req #65169 [NEW]: php-cgi: Content-type bfore Directive no longer available
From: spamik at yum dot pl Operating system: PHP version: 5.3.26 Package: *General Issues Bug Type: Feature/Change Request Bug description:php-cgi: Content-type bfore Directive no longer available Description: # ./php-cgi -n a.php X-Powered-By: PHP/5.4.16 Content-type: text/html # ./php-cgi -n -d magic_quotes_gpc=1 a.php Fatal error: Directive 'magic_quotes_gpc' is no longer available in PHP in Unknown on line 0 expected: # ./php-cgi -n -d magic_quotes_gpc=1 a.php X-Powered-By: PHP/5.4.16 Content-type: text/html Fatal error: Directive 'magic_quotes_gpc' is no longer available in PHP in Unknown on line 0 Not outputing Content-type header means that apache webserver will only return 500 error without a webmaster actualy seeing error. -- Edit bug report at https://bugs.php.net/bug.php?id=65169&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65169&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65169&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65169&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65169&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65169&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65169&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65169&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65169&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65169&r=support Expected behavior: https://bugs.php.net/fix.php?id=65169&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65169&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65169&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65169&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65169&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65169&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65169&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65169&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65169&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65169&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65169&r=mysqlcfg
Req #50802 [Com]: Allow "disable_functions" in httpd.conf
Edit report at https://bugs.php.net/bug.php?id=50802&edit=1 ID: 50802 Comment by: spamik at yum dot pl Reported by:h dot reindl at thelounge dot net Summary:Allow "disable_functions" in httpd.conf Status: Wont fix Type: Feature/Change Request Package:Feature/Change Request Operating System: All PHP Version:5.2.12 Block user comment: N Private report: N New Comment: disable_functions should be made PHP_INI_ALL with exception that once set in can't be set to less restrictive (like open_basedir is nowadays). Yes it is tought to make because of curent code, but that is no reason to reject feature request completly! Don't reject it, maybe some dev someday will find motivation to do this. Previous Comments: [2012-01-30 02:23:04] k dot reznichak at pcpin dot com Hello, any updates here? Doesn't matter if "suhosin"-like or any other way, this feature would dramatically simplify server administration and reduce costs. My current solution with different apache instances listening on different ports via proxy was pain to set up and hurts every time I manage it. Please consider that some admins just going easy way by enabling sensitive functions globally for all virtual hosts causing security risk. That does not means PHP is insecure by itself, however it encourages people to act insecure. Kind Regards [2010-01-29 15:45:08] h dot reindl at thelounge dot net > Suhosin doesn't disable functions. > It adds a separate blacklist > mechanism. Yes, and it works fine > This bug was about being able to do per-request disabling > with the existing disable_function mechanism. And shows that the existing mechnism is poorly implemented if you need a extension to make a SECURITY-SETTING usable which is able to do nearly the same and would not be needed if the php-core does handle this better [2010-01-29 15:39:30] ras...@php.net Suhosin doesn't disable functions. It adds a separate blacklist mechanism. This bug was about being able to do per-request disabling with the existing disable_function mechanism. [2010-01-29 14:43:51] h dot reindl at thelounge dot net http://www.webhostingtalk.com/showthread.php?t=623944 If it is not possible because performance why it works with suhosin-extension perfectly with the only problem that "function_exists()" does not realize the suhosin setting? Sorry, but this sounds like "it's possible but i say is not because i do not like to touch the code" [2010-01-19 20:47:32] h dot reindl at thelounge dot net Hm very bad - so i have three choises * allow a function i would never like on all hosts * make a own httpd-instance for 2 vhosts * change the whole company-infrastructure especially adminpanel > The performance hit would be way too high About what time-gain are we speaking? I can not believe that refresh this list takes a really long time With open_basedir it works also and you have to check this before every fs-operation - where is the difference and would it not make sense to look how to optimize initalizing the functon table? > I agree with you that the phpinfo() out is misleading, > but that's not what you filed a bug about. Of course i have because i saw this day that a function is active that should not and i never ever would have configured the machine this way if phpinfo() had not shown me that the configuration is active The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=50802 -- Edit this bug report at https://bugs.php.net/bug.php?id=50802&edit=1
Bug #64258 [Opn]: --with-mcrypt causes bad linking (with --with-libxml-dir). Reason: -lltdl flag
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:--with-mcrypt causes bad linking (with --with-libxml-dir). Reason: -lltdl flag Status: Open Type: Bug Package:*Compile Issues PHP Version:5.4.16 Block user comment: N Private report: N New Comment: ./buildconf --force sorry I've missed that. Now patch does work Previous Comments: [2013-06-13 17:11:46] spamik at yum dot pl # cat /usr/include/mutils/mcrypt.h | grep VER #define MCRYPT_API_VERSION 20021217 #define LIBMCRYPT_VERSION "2.5.8" I've aplied PATCH but it DOES NOT WORK (tested on freshly unpacked source) root@sv18 [/root/naox/php-5.4.16]# patch -p1 < p patching file ext/mcrypt/config.m4 # ./configure --with-libxml-dir=/usr/libxml2-2.7.8 --with-mcrypt && make root@sv18 [/root/naox/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f95fe8bd000) root@sv18 [/root/naox/php-5.4.16]# cat Makefile|grep 'lltdl' EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lmcrypt -lltdl -lrt -lm -ldl -lnsl - lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz - lm -lxml2 -lz -lm -lcrypt -lltdl is still present even with the pathc [2013-06-13 08:56:02] der...@php.net The following patch has been added/updated: Patch Name: mcrypt-config-20130613 Revision: 1371113762 URL: https://bugs.php.net/patch-display.php?bug=64258&patch=mcrypt-config-20130613&revision=1371113762 [2013-06-13 08:55:32] der...@php.net It's a linker helper library as used by gnu libtool. I have no idea why it messes the libxml include though, and as far as I know, that library is no longer needed since libmcrypt 2.5.4. So unless your version is that old, -lltdl should not be part of your Makefile. If I manually remove -lltdl from the Makefile, PHP still compiles and links, so I would recommend you try the following: cat /usr/include/mutils/mcrypt.h | grep VER And let me know what it says. Secondly, apply the attached patch to ext/mcrypt/config.m4 and then run: make clean ./buildconf --force ./config.nice make and see which libxml it now links too. -------------------- [2013-06-13 00:57:01] spamik at yum dot pl root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 && make root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/libxml2-2.9.0/lib/libxml2.so.2 (0x7f6b2c098000) root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 -- with-mcrypt && make root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f1478692000) When configured with mcrypt Makefile has EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lmcrypt -lltdl -lrt -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt - lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt when configured without mcrypt Makefile has EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm - lxml2 -lz -lm -lxml2 -lz -lm -lcrypt problem seems to be caused by flag -lltdl. When removed manualy, libxml2 is liked ok. What is this flag? ---------------- [2013-06-12 20:58:07] spamik at yum dot pl or better I'll put in into to compile issues... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64258 -- Edit this bug report at https://bugs.php.net/bug.php?id=64258&edit=1
Bug #64258 [Opn]: --with-mcrypt causes bad linking (with --with-libxml-dir). Reason: -lltdl flag
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:--with-mcrypt causes bad linking (with --with-libxml-dir). Reason: -lltdl flag Status: Open Type: Bug Package:*Compile Issues PHP Version:5.4.16 Block user comment: N Private report: N New Comment: # cat /usr/include/mutils/mcrypt.h | grep VER #define MCRYPT_API_VERSION 20021217 #define LIBMCRYPT_VERSION "2.5.8" I've aplied PATCH but it DOES NOT WORK (tested on freshly unpacked source) root@sv18 [/root/naox/php-5.4.16]# patch -p1 < p patching file ext/mcrypt/config.m4 # ./configure --with-libxml-dir=/usr/libxml2-2.7.8 --with-mcrypt && make root@sv18 [/root/naox/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f95fe8bd000) root@sv18 [/root/naox/php-5.4.16]# cat Makefile|grep 'lltdl' EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lmcrypt -lltdl -lrt -lm -ldl -lnsl - lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz - lm -lxml2 -lz -lm -lcrypt -lltdl is still present even with the pathc Previous Comments: [2013-06-13 08:56:02] der...@php.net The following patch has been added/updated: Patch Name: mcrypt-config-20130613 Revision: 1371113762 URL: https://bugs.php.net/patch-display.php?bug=64258&patch=mcrypt-config-20130613&revision=1371113762 [2013-06-13 08:55:32] der...@php.net It's a linker helper library as used by gnu libtool. I have no idea why it messes the libxml include though, and as far as I know, that library is no longer needed since libmcrypt 2.5.4. So unless your version is that old, -lltdl should not be part of your Makefile. If I manually remove -lltdl from the Makefile, PHP still compiles and links, so I would recommend you try the following: cat /usr/include/mutils/mcrypt.h | grep VER And let me know what it says. Secondly, apply the attached patch to ext/mcrypt/config.m4 and then run: make clean ./buildconf --force ./config.nice make and see which libxml it now links too. -------------------- [2013-06-13 00:57:01] spamik at yum dot pl root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 && make root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/libxml2-2.9.0/lib/libxml2.so.2 (0x7f6b2c098000) root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 -- with-mcrypt && make root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f1478692000) When configured with mcrypt Makefile has EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lmcrypt -lltdl -lrt -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt - lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt when configured without mcrypt Makefile has EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm - lxml2 -lz -lm -lxml2 -lz -lm -lcrypt problem seems to be caused by flag -lltdl. When removed manualy, libxml2 is liked ok. What is this flag? -------------------- [2013-06-12 20:58:07] spamik at yum dot pl or better I'll put in into to compile issues... ---------------- [2013-06-12 20:56:32] spamik at yum dot pl changing to mcrypt package. Maybe more devs there will be more active. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64258 -- Edit this bug report at https://bugs.php.net/bug.php?id=64258&edit=1
Bug #64258 [Opn]: --with-mcrypt causes bad linking (with --with-libxml-dir). Reason: -lltdl flag
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl -Summary:--with-mcrypt causes bad linking when --with-libxml-dir is present +Summary:--with-mcrypt causes bad linking (with --with-libxml-dir). Reason: -lltdl flag Status: Open Type: Bug Package:*Compile Issues PHP Version:5.4.16 Block user comment: N Private report: N New Comment: root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 && make root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/libxml2-2.9.0/lib/libxml2.so.2 (0x7f6b2c098000) root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 -- with-mcrypt && make root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f1478692000) When configured with mcrypt Makefile has EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lmcrypt -lltdl -lrt -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt - lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt when configured without mcrypt Makefile has EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm - lxml2 -lz -lm -lxml2 -lz -lm -lcrypt problem seems to be caused by flag -lltdl. When removed manualy, libxml2 is liked ok. What is this flag? Previous Comments: ---- [2013-06-12 20:58:07] spamik at yum dot pl or better I'll put in into to compile issues... ---- [2013-06-12 20:56:32] spamik at yum dot pl changing to mcrypt package. Maybe more devs there will be more active. ---- [2013-06-12 20:53:47] spamik at yum dot pl Problem is still not addressed. root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/libxml2-2.9.0/lib/libxml2.so.2 (0x7f6b2c098000) root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 -- with-mcrypt root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f1478692000) [2013-02-27 03:15:03] veillard at redhat dot com just to point out that xmlTextReaderSetup is not part of libxml2 ABI, nor on current version nor on 2.6.26. thinkpad:~/XML -> grep xmlTextReaderSetup doc/libxml2-api.xml thinkpad:~/XML -> [root@test-rhel55 ~]# gunzip -c /usr/share/doc/libxml2-devel-2.6.26/libxml2-api.xml.gz | grep xmlTextReaderSetup [root@test-rhel55 ~]# it would be good if PHP didn't use name which looks like that they are coming from libxml2 even if they are possibly wrappers around libxml2 functions. -------------------- [2013-02-22 01:56:19] spamik at
Bug #64258 [Opn]: --with-mcrypt causes bad linking when --with-libxml-dir is present
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:--with-mcrypt causes bad linking when --with-libxml-dir is present Status: Open Type: Bug -Package:mcrypt related +Package:*Compile Issues PHP Version:5.4.16 Block user comment: N Private report: N New Comment: or better I'll put in into to compile issues... Previous Comments: [2013-06-12 20:56:32] spamik at yum dot pl changing to mcrypt package. Maybe more devs there will be more active. [2013-06-12 20:53:47] spamik at yum dot pl Problem is still not addressed. root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/libxml2-2.9.0/lib/libxml2.so.2 (0x7f6b2c098000) root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 -- with-mcrypt root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f1478692000) [2013-02-27 03:15:03] veillard at redhat dot com just to point out that xmlTextReaderSetup is not part of libxml2 ABI, nor on current version nor on 2.6.26. thinkpad:~/XML -> grep xmlTextReaderSetup doc/libxml2-api.xml thinkpad:~/XML -> [root@test-rhel55 ~]# gunzip -c /usr/share/doc/libxml2-devel-2.6.26/libxml2-api.xml.gz | grep xmlTextReaderSetup [root@test-rhel55 ~]# it would be good if PHP didn't use name which looks like that they are coming from libxml2 even if they are possibly wrappers around libxml2 functions. ---- [2013-02-22 01:56:19] spamik at yum dot pl I would guess that mere presence of --with-mcrypt on configure breaks linking to custom libxml2 directory (--with-libxml-dir=/usr/libxml2-2.9.0/) and it defaults to system /usr/lib64 (and there is distro standard old libxml2 there which break things). ---- [2013-02-22 01:38:34] spamik at yum dot pl also during make install (php) i see ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version informatio
Bug #64258 [Opn]: --with-mcrypt causes bad linking when --with-libxml-dir is present
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl -Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) +Summary:--with-mcrypt causes bad linking when --with-libxml-dir is present Status: Open Type: Bug -Package:XML Reader +Package:mcrypt related -PHP Version:5.4.11 +PHP Version:5.4.16 Block user comment: N Private report: N New Comment: changing to mcrypt package. Maybe more devs there will be more active. Previous Comments: [2013-06-12 20:53:47] spamik at yum dot pl Problem is still not addressed. root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/libxml2-2.9.0/lib/libxml2.so.2 (0x7f6b2c098000) root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 -- with-mcrypt root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f1478692000) [2013-02-27 03:15:03] veillard at redhat dot com just to point out that xmlTextReaderSetup is not part of libxml2 ABI, nor on current version nor on 2.6.26. thinkpad:~/XML -> grep xmlTextReaderSetup doc/libxml2-api.xml thinkpad:~/XML -> [root@test-rhel55 ~]# gunzip -c /usr/share/doc/libxml2-devel-2.6.26/libxml2-api.xml.gz | grep xmlTextReaderSetup [root@test-rhel55 ~]# it would be good if PHP didn't use name which looks like that they are coming from libxml2 even if they are possibly wrappers around libxml2 functions. [2013-02-22 01:56:19] spamik at yum dot pl I would guess that mere presence of --with-mcrypt on configure breaks linking to custom libxml2 directory (--with-libxml-dir=/usr/libxml2-2.9.0/) and it defaults to system /usr/lib64 (and there is distro standard old libxml2 there which break things). [2013-02-22 01:38:34] spamik at yum dot pl also during make install (php) i see ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /roo
Bug #64258 [Com]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 Comment by: spamik at yum dot pl Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Problem is still not addressed. root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml libxml2.so.2 => /usr/libxml2-2.9.0/lib/libxml2.so.2 (0x7f6b2c098000) root@sv18 [~/php-5.4.16]# ./configure --with-libxml-dir=/usr/libxml2-2.9.0 -- with-mcrypt root@sv18 [~/php-5.4.16]# ldd sapi/cli/php|grep xml sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by sapi/cli/php) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x7f1478692000) Previous Comments: [2013-02-27 03:15:03] veillard at redhat dot com just to point out that xmlTextReaderSetup is not part of libxml2 ABI, nor on current version nor on 2.6.26. thinkpad:~/XML -> grep xmlTextReaderSetup doc/libxml2-api.xml thinkpad:~/XML -> [root@test-rhel55 ~]# gunzip -c /usr/share/doc/libxml2-devel-2.6.26/libxml2-api.xml.gz | grep xmlTextReaderSetup [root@test-rhel55 ~]# it would be good if PHP didn't use name which looks like that they are coming from libxml2 even if they are possibly wrappers around libxml2 functions. [2013-02-22 01:56:19] spamik at yum dot pl I would guess that mere presence of --with-mcrypt on configure breaks linking to custom libxml2 directory (--with-libxml-dir=/usr/libxml2-2.9.0/) and it defaults to system /usr/lib64 (and there is distro standard old libxml2 there which break things). [2013-02-22 01:38:34] spamik at yum dot pl also during make install (php) i see ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /u
Req #64437 [Opn]: [feature request] log of php writes to local files
Edit report at https://bugs.php.net/bug.php?id=64437&edit=1 ID: 64437 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:[feature request] log of php writes to local files Status: Open Type: Feature/Change Request Package:Filesystem function related PHP Version:5.4.13 Block user comment: N Private report: N New Comment: That might be good in a perfect world but php also needs to write to files - for example auto updates, log files, instalation of extensions, file uploads. Setup you are describing is like 199X year. Nobody can't provide such rescrictive eviroments now for hosting because aplications depend of file writes and even self-modifying writes (updates). Also executing code as one user under shared conditions? BIG NO. apc, fastcgi, fcgid way of running php default setup conforms to what I'm saying. Previous Comments: [2013-03-25 22:17:36] mail+php at requinix dot net But a setup shouldn't allow PHP to do anything to files in the first place (with possible exceptions for things like file uploads). Directories should be locked down to 0755 or better, files to 0644 or better, and the web server/PHP running as a very under-privileged user like "nobody". Then there's no risk of creating new files or overwriting code or really any kind of modifications at all. -------- [2013-03-18 20:23:42] spamik at yum dot pl Only writes to files with selected extensions (by php.ini, like php|htm|html|js) should be logged. -------- [2013-03-15 23:27:01] spamik at yum dot pl Just to clarify that log would actualy be later on used by user land aplications that would scan those files that were writen to. In light of what is happening with php aplications, mass hacks, botnets, people are moving to other languages that are more obscure just for their obscurity. PHP really need to counteract and provide functionality like one I propose. -------- [2013-03-15 23:21:02] spamik at yum dot pl Description: As you probably know there are a lot of security bugs in current world php aplications. Using these bugs attacker executes his own code that writes to a new .php files (usualy) or modyfy existing one - putting there his malicious "botnet zombie" code. It is really hard to quick and efectivly detect changes on filesystem/kernel level, especialy if where are talking about monitoring milions of directories (as in popular shared hosting). I propose making php file write log (to a file defined in php.ini). Operations that write to local files should be logged there (file_put_contents() and all fopen() except 'r' and 'r+' mode) Log should contain: unix_timestampabsolute path of file that used write functionabsolute file of modified file could be '\0' as it can't be in filename anyway. Other solution would be to escape paths as those can contain spaces etc. most of this code should probably go to ext/standard/file.c I've made very very crude implementation of this for myself but that is really bad code because I lack c skills. It actualy seg faults in some cases. So I wont even share it, no point. -- Edit this bug report at https://bugs.php.net/bug.php?id=64437&edit=1
[PHP-BUG] Req #64484 [NEW]: [feature request] second auto_prepend_file
From: spamik at yum dot pl Operating system: PHP version: 5.4.13 Package: *General Issues Bug Type: Feature/Change Request Bug description:[feature request] second auto_prepend_file Description: There is need for second auto_prepend_file for administrative purposes (for example hosting providers). It would allow users to still user auto_prepend_file and hosting to use its own. Example uses: a) $_ENV['APPLICATION_ENV'] = $_SERVER["REDIRECT_APPLICATION_ENV"]; (because apache dont pass env to fastcgi, instead it passes it into fastcgi protocol) b) setting open_basedir (it can't be relaxed later on since php 5.3) -- Edit bug report at https://bugs.php.net/bug.php?id=64484&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64484&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64484&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64484&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64484&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64484&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64484&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64484&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64484&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64484&r=support Expected behavior: https://bugs.php.net/fix.php?id=64484&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64484&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64484&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64484&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64484&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64484&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64484&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64484&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64484&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64484&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64484&r=mysqlcfg
Req #64437 [Opn]: [feature request] log of php writes to local files
Edit report at https://bugs.php.net/bug.php?id=64437&edit=1 ID: 64437 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:[feature request] log of php writes to local files Status: Open Type: Feature/Change Request Package:Filesystem function related PHP Version:5.4.13 Block user comment: N Private report: N New Comment: Only writes to files with selected extensions (by php.ini, like php|htm|html|js) should be logged. Previous Comments: [2013-03-15 23:27:01] spamik at yum dot pl Just to clarify that log would actualy be later on used by user land aplications that would scan those files that were writen to. In light of what is happening with php aplications, mass hacks, botnets, people are moving to other languages that are more obscure just for their obscurity. PHP really need to counteract and provide functionality like one I propose. [2013-03-15 23:21:02] spamik at yum dot pl Description: As you probably know there are a lot of security bugs in current world php aplications. Using these bugs attacker executes his own code that writes to a new .php files (usualy) or modyfy existing one - putting there his malicious "botnet zombie" code. It is really hard to quick and efectivly detect changes on filesystem/kernel level, especialy if where are talking about monitoring milions of directories (as in popular shared hosting). I propose making php file write log (to a file defined in php.ini). Operations that write to local files should be logged there (file_put_contents() and all fopen() except 'r' and 'r+' mode) Log should contain: unix_timestampabsolute path of file that used write functionabsolute file of modified file could be '\0' as it can't be in filename anyway. Other solution would be to escape paths as those can contain spaces etc. most of this code should probably go to ext/standard/file.c I've made very very crude implementation of this for myself but that is really bad code because I lack c skills. It actualy seg faults in some cases. So I wont even share it, no point. -- Edit this bug report at https://bugs.php.net/bug.php?id=64437&edit=1
Req #64437 [Com]: [feature request] log of php writes to local files
Edit report at https://bugs.php.net/bug.php?id=64437&edit=1 ID: 64437 Comment by: spamik at yum dot pl Reported by:spamik at yum dot pl Summary:[feature request] log of php writes to local files Status: Open Type: Feature/Change Request Package:Filesystem function related PHP Version:5.4.13 Block user comment: N Private report: N New Comment: Just to clarify that log would actualy be later on used by user land aplications that would scan those files that were writen to. In light of what is happening with php aplications, mass hacks, botnets, people are moving to other languages that are more obscure just for their obscurity. PHP really need to counteract and provide functionality like one I propose. Previous Comments: [2013-03-15 23:21:02] spamik at yum dot pl Description: As you probably know there are a lot of security bugs in current world php aplications. Using these bugs attacker executes his own code that writes to a new .php files (usualy) or modyfy existing one - putting there his malicious "botnet zombie" code. It is really hard to quick and efectivly detect changes on filesystem/kernel level, especialy if where are talking about monitoring milions of directories (as in popular shared hosting). I propose making php file write log (to a file defined in php.ini). Operations that write to local files should be logged there (file_put_contents() and all fopen() except 'r' and 'r+' mode) Log should contain: unix_timestampabsolute path of file that used write functionabsolute file of modified file could be '\0' as it can't be in filename anyway. Other solution would be to escape paths as those can contain spaces etc. most of this code should probably go to ext/standard/file.c I've made very very crude implementation of this for myself but that is really bad code because I lack c skills. It actualy seg faults in some cases. So I wont even share it, no point. -- Edit this bug report at https://bugs.php.net/bug.php?id=64437&edit=1
[PHP-BUG] Req #64437 [NEW]: [feature request] log of php writes to local files
From: spamik at yum dot pl Operating system: PHP version: 5.4.13 Package: Filesystem function related Bug Type: Feature/Change Request Bug description:[feature request] log of php writes to local files Description: As you probably know there are a lot of security bugs in current world php aplications. Using these bugs attacker executes his own code that writes to a new .php files (usualy) or modyfy existing one - putting there his malicious "botnet zombie" code. It is really hard to quick and efectivly detect changes on filesystem/kernel level, especialy if where are talking about monitoring milions of directories (as in popular shared hosting). I propose making php file write log (to a file defined in php.ini). Operations that write to local files should be logged there (file_put_contents() and all fopen() except 'r' and 'r+' mode) Log should contain: unix_timestampabsolute path of file that used write functionabsolute file of modified file could be '\0' as it can't be in filename anyway. Other solution would be to escape paths as those can contain spaces etc. most of this code should probably go to ext/standard/file.c I've made very very crude implementation of this for myself but that is really bad code because I lack c skills. It actualy seg faults in some cases. So I wont even share it, no point. -- Edit bug report at https://bugs.php.net/bug.php?id=64437&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64437&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64437&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64437&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64437&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64437&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64437&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64437&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64437&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64437&r=support Expected behavior: https://bugs.php.net/fix.php?id=64437&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64437&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64437&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64437&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64437&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64437&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64437&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64437&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64437&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64437&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64437&r=mysqlcfg
Bug #64258 [Opn]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: I would guess that mere presence of --with-mcrypt on configure breaks linking to custom libxml2 directory (--with-libxml-dir=/usr/libxml2-2.9.0/) and it defaults to system /usr/lib64 (and there is distro standard old libxml2 there which break things). Previous Comments: [2013-02-22 01:38:34] spamik at yum dot pl also during make install (php) i see ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) I did not linked to usr/lib64/libxml2.so.2 !! Some error in linking (but only when mcrypt is present) ---- [2013-02-22 01:23:02] spamik at yum dot pl >>Problem appears when compiling with mcrypt and extension (and libxml2 2.9)<< Package libmcrypt-devel-2.5.8-4.el5.centos.x86_64 already installed and latest version ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install datadata'; $xml->XML($xmldata); ?> /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup I've also tried compiling libmcrypt from source - no changes. ./configure --prefix=/usr/libmcrypt-2.5.8 --disable-posix-threads make install ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt=/usr/libmcrypt-2.5.8' sill does not work (it works with libxml2 2.6.x for some reason) ---- [2013-02-22 00:28:10] spamik at yum dot pl I've tested with ONLY --with-libxml-dir=/usr/libxml2-2.9.0 and it does work. Some other extension (on my normal configure) must be interfering. I will try to determine which one with trial and error and soon let you know. [2
Bug #64258 [Opn]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: also during make install (php) i see ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) I did not linked to usr/lib64/libxml2.so.2 !! Some error in linking (but only when mcrypt is present) Previous Comments: ---- [2013-02-22 01:23:02] spamik at yum dot pl >>Problem appears when compiling with mcrypt and extension (and libxml2 2.9)<< Package libmcrypt-devel-2.5.8-4.el5.centos.x86_64 already installed and latest version ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install datadata'; $xml->XML($xmldata); ?> /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup I've also tried compiling libmcrypt from source - no changes. ./configure --prefix=/usr/libmcrypt-2.5.8 --disable-posix-threads make install ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt=/usr/libmcrypt-2.5.8' sill does not work (it works with libxml2 2.6.x for some reason) ---- [2013-02-22 00:28:10] spamik at yum dot pl I've tested with ONLY --with-libxml-dir=/usr/libxml2-2.9.0 and it does work. Some other extension (on my normal configure) must be interfering. I will try to determine which one with trial and error and soon let you know. [2013-02-21 15:33:00] r...@php.net Cannot reproduce. php 5.4.11 and 5.4.12 build against libxml2 and work as expected. [2013-02-21 00:01:56] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.11 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined
Bug #64258 [Opn]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: >>Problem appears when compiling with mcrypt and extension (and libxml2 2.9)<< Package libmcrypt-devel-2.5.8-4.el5.centos.x86_64 already installed and latest version ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install datadata'; $xml->XML($xmldata); ?> /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup I've also tried compiling libmcrypt from source - no changes. ./configure --prefix=/usr/libmcrypt-2.5.8 --disable-posix-threads make install ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt=/usr/libmcrypt-2.5.8' sill does not work (it works with libxml2 2.6.x for some reason) Previous Comments: ---------------- [2013-02-22 00:28:10] spamik at yum dot pl I've tested with ONLY --with-libxml-dir=/usr/libxml2-2.9.0 and it does work. Some other extension (on my normal configure) must be interfering. I will try to determine which one with trial and error and soon let you know. [2013-02-21 15:33:00] r...@php.net Cannot reproduce. php 5.4.11 and 5.4.12 build against libxml2 and work as expected. -------------------- [2013-02-21 00:01:56] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.11 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 XMLReader is not compatibile with new libxml2 version. -- Edit this bug report at https://bugs.php.net/bug.php?id=64258&edit=1
Bug #64258 [Opn]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: I've tested with ONLY --with-libxml-dir=/usr/libxml2-2.9.0 and it does work. Some other extension (on my normal configure) must be interfering. I will try to determine which one with trial and error and soon let you know. Previous Comments: [2013-02-21 15:33:00] r...@php.net Cannot reproduce. php 5.4.11 and 5.4.12 build against libxml2 and work as expected. [2013-02-21 00:01:56] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.11 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 XMLReader is not compatibile with new libxml2 version. -- Edit this bug report at https://bugs.php.net/bug.php?id=64258&edit=1
Bug #63378 [Nab]: xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup
Edit report at https://bugs.php.net/bug.php?id=63378&edit=1 ID: 63378 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup Status: Not a bug Type: Bug Package:XML Reader PHP Version:5.4.8 Block user comment: N Private report: N New Comment: I never said it does not build! /usr/bin/php: undefined symbol: xmlTextReaderSetup is obviosly runtime crash not a build problem (which does not happen when build against very old libxml2 2.6.26) I always do clean build. Previous Comments: [2013-02-21 12:36:14] paj...@php.net @spamik at yum dot pl What Felipe said is correct. It builds just fine using 2.9.0 (be unix or windows). Try again using a clean build (read: either download 5.4.x again or do a buildconf, configure, etc.). [2013-02-20 23:58:13] spamik at yum dot pl Not an answer. Not related to the question. Yes a bug in libxml extension which is not compatibile with new libxml2 libs. [2012-10-29 15:25:36] fel...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Not a PHP problem. Try a clean PHP build on your system again. [2012-10-28 21:29:03] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.8 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 -- Edit this bug report at https://bugs.php.net/bug.php?id=63378&edit=1
[PHP-BUG] Bug #64258 [NEW]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
From: spamik at yum dot pl Operating system: PHP version: 5.4.11 Package: XML Reader Bug Type: Bug Bug description:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Description: datadata'; $xml->XML($xmldata); ?> php 5.4.11 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 XMLReader is not compatibile with new libxml2 version. -- Edit bug report at https://bugs.php.net/bug.php?id=64258&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64258&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64258&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64258&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64258&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64258&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64258&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64258&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64258&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64258&r=support Expected behavior: https://bugs.php.net/fix.php?id=64258&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64258&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64258&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64258&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64258&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64258&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64258&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64258&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64258&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64258&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64258&r=mysqlcfg
Bug #63378 [Nab]: xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup
Edit report at https://bugs.php.net/bug.php?id=63378&edit=1 ID: 63378 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup Status: Not a bug Type: Bug Package:XML Reader PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Not an answer. Not related to the question. Yes a bug in libxml extension which is not compatibile with new libxml2 libs. Previous Comments: [2012-10-29 15:25:36] fel...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Not a PHP problem. Try a clean PHP build on your system again. [2012-10-28 21:29:03] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.8 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 -- Edit this bug report at https://bugs.php.net/bug.php?id=63378&edit=1
Bug #61492 [Nab]: flock for php 5.3.2 - regression
Edit report at https://bugs.php.net/bug.php?id=61492&edit=1
ID: 61492
User updated by:spamik at yum dot pl
Reported by:spamik at yum dot pl
Summary:flock for php 5.3.2 - regression
Status: Not a bug
Type: Bug
Package:Streams related
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
right, all changes are for the better...
Previous Comments:
[2012-03-26 00:43:40] ahar...@php.net
The manual sums this up: the behaviour was (intentionally) changed in 5.3.2,
and
isn't going to change again.
[2012-03-23 16:42:12] spamik at yum dot pl
"The automatic unlocking when the file's resource handle is closed was removed.
Unlocking now always has to be done manually."
----
[2012-03-23 16:27:16] spamik at yum dot pl
Description:
http://www.php.net/manual/en/function.flock.php
"On versions of PHP before 5.3.2, the lock is released also by fclose() (which
is also called automatically when script finished)."
This is huge regression. I've used with success file locking to check if
another
instance of file is already running putting code like this in front of the
script or append_script
$h55 = fopen($_SERVER['argv'][0],"r");
while(!flock($h55, LOCK_EX + LOCK_NB )) {
echo "cant get lock, die\n";
die();
}
or
$h55 = fopen($_SERVER['argv'][0],"r");
while(!flock($h55, LOCK_EX + LOCK_NB )) {
echo "cant get lock, waiting 10s\n";
sleep(10);
}
I've used it for scripts that had variable running time with a crontab. Now it
is all impossible thanks to that change :(
--
Edit this bug report at https://bugs.php.net/bug.php?id=61492&edit=1
[PHP-BUG] Bug #63378 [NEW]: xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup
From: spamik at yum dot pl Operating system: PHP version: 5.4.8 Package: XML Reader Bug Type: Bug Bug description:xmlreader libxml2 2.9.0 undefined symbol: xmlTextReaderSetup Description: datadata'; $xml->XML($xmldata); ?> php 5.4.8 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 -- Edit bug report at https://bugs.php.net/bug.php?id=63378&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63378&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63378&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63378&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63378&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63378&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63378&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63378&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63378&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63378&r=support Expected behavior: https://bugs.php.net/fix.php?id=63378&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63378&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63378&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63378&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63378&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63378&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63378&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63378&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63378&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63378&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63378&r=mysqlcfg
Req #62397 [Com]: disable_functions = eval does not work
Edit report at https://bugs.php.net/bug.php?id=62397&edit=1 ID: 62397 Comment by: spamik at yum dot pl Reported by:spamik at yum dot pl Summary:disable_functions = eval does not work Status: Re-Opened Type: Feature/Change Request Package:*General Issues PHP Version:5.3.14 Block user comment: N Private report: N New Comment: good point about assert and preg_replace /e - there also should be option to disable it then (especialy this /e in preg_replace). Writers of malicious code so far did not had to use it because eval is enabled in every php version... As for eval etc. documentation states that it sould be avoided by developers - and it is actualy. However it used to mask infected, malicious code by those that hacked php software. eval is commonly used to evaluate base64_encoded string and that makes very hard to see what code is doing and to detect it automaticly (by something like antivirus software). Change on magic_quotes_gpc in php 5.4 is much greater change then turning off eval by default would be. Since most legitimate software don't use it (since documentation says its bad)would affect only very few. This also would not increase security. However it would make code infections so much easier to detect and analize its nature. Previous Comments: [2012-06-24 11:25:51] ni...@php.net Irregardless of the FR, I'd like to point out that eval() is a useful and legitimate language construct. It *definitely* will not be disabled by default. I won't argue with the fact that it is commonly misused by ignorant developers, but this does not mean that eval() itself is in any way fundamentally "evil". Also, I completely do not understand your arguments that people are migrating to other languages, because PHP has an eval() construct. All dynamic languages have an eval() function, including JS, Python and Ruby. Furthermore you should realize that disabling eval() will not likely improve the security of your application. There are just to many other ways to execute code. E.g. the assert() function can be used to evaluate arbitrary code. Or the preg_replace /e modifier. But in any case, I don't really see why eval() is a language construct. In my eyes it could just as well be a function. This would make it disableable and would also provide other advantages, like allowing its use as a callback function. [2012-06-24 10:05:00] larue...@php.net okey, change to FR makes sense to me. -------- [2012-06-24 04:08:24] spamik at yum dot pl I think that that not only should be done but also made default php behavior, to stop widespread madness of php code infection. Eval should be by default disabled in php like 5.5 ... -------- [2012-06-24 04:02:31] spamik at yum dot pl feature request then [2012-06-24 03:59:29] krzf83 at gmail dot com treat it as feature request if it helps you sleep at night. However this issue is critical in face of current mailicous code boom. Eval (by base64_encode etc) does not allow for any scanning and detection. This funcionality of php had begun its downfall really. People are migrating to other languages just because infections there are rare and code cannot be just like that obfucated! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62397 -- Edit this bug report at https://bugs.php.net/bug.php?id=62397&edit=1
Bug->Req #62397 [Nab]: disable_functions = eval does not work
Edit report at https://bugs.php.net/bug.php?id=62397&edit=1 ID: 62397 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:disable_functions = eval does not work Status: Not a bug -Type: Bug +Type: Feature/Change Request Package:*General Issues PHP Version:5.3.14 Block user comment: N Private report: N New Comment: I think that that not only should be done but also made default php behavior, to stop widespread madness of php code infection. Eval should be by default disabled in php like 5.5 ... Previous Comments: [2012-06-24 04:02:31] spamik at yum dot pl feature request then [2012-06-24 03:59:29] krzf83 at gmail dot com treat it as feature request if it helps you sleep at night. However this issue is critical in face of current mailicous code boom. Eval (by base64_encode etc) does not allow for any scanning and detection. This funcionality of php had begun its downfall really. People are migrating to other languages just because infections there are rare and code cannot be just like that obfucated! [2012-06-24 03:56:32] krzf83 at gmail dot com "eval is not a function but language construct" - that might be the reason why disable_functions don't work on it now but that does not mean it could not or should not. I would not dismiss this isssue so easily. Eval problem caused that php is currently (almost) only one language is so often infected. It allows for attacker to hide code, purpose, use ecodings (like base64) to diminish any hope of detection by searching for common traits (like antivirus software does). Eval is a functionality of php and could be disabled if apropriate modifications to php source code were made. [2012-06-23 12:52:55] bobwei9 at hotmail dot com Why can't you simply add a new core directive for disabling this language construct? [2012-06-23 12:29:45] larue...@php.net as I said, eval is not a *function*, so disable_*functions* has no effect to eval.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62397 -- Edit this bug report at https://bugs.php.net/bug.php?id=62397&edit=1
Bug #62397 [Nab]: disable_functions = eval does not work
Edit report at https://bugs.php.net/bug.php?id=62397&edit=1 ID: 62397 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:disable_functions = eval does not work Status: Not a bug Type: Bug Package:*General Issues PHP Version:5.3.14 Block user comment: N Private report: N New Comment: feature request then Previous Comments: [2012-06-24 03:59:29] krzf83 at gmail dot com treat it as feature request if it helps you sleep at night. However this issue is critical in face of current mailicous code boom. Eval (by base64_encode etc) does not allow for any scanning and detection. This funcionality of php had begun its downfall really. People are migrating to other languages just because infections there are rare and code cannot be just like that obfucated! [2012-06-24 03:56:32] krzf83 at gmail dot com "eval is not a function but language construct" - that might be the reason why disable_functions don't work on it now but that does not mean it could not or should not. I would not dismiss this isssue so easily. Eval problem caused that php is currently (almost) only one language is so often infected. It allows for attacker to hide code, purpose, use ecodings (like base64) to diminish any hope of detection by searching for common traits (like antivirus software does). Eval is a functionality of php and could be disabled if apropriate modifications to php source code were made. [2012-06-23 12:52:55] bobwei9 at hotmail dot com Why can't you simply add a new core directive for disabling this language construct? [2012-06-23 12:29:45] larue...@php.net as I said, eval is not a *function*, so disable_*functions* has no effect to eval.. [2012-06-23 10:56:33] anon at anon dot anon A reason why a bug exists is not a reason why it is not a bug. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62397 -- Edit this bug report at https://bugs.php.net/bug.php?id=62397&edit=1
[PHP-BUG] Bug #62397 [NEW]: disable_functions = eval does not work
From: spamik at yum dot pl Operating system: PHP version: 5.3.14 Package: *General Issues Bug Type: Bug Bug description:disable_functions = eval does not work Description: disable_functions = eval does not work. eval is often used to obfucate code by malicious viruses. I see no reason why blocking access to eval() is not doable. -- Edit bug report at https://bugs.php.net/bug.php?id=62397&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62397&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62397&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62397&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62397&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62397&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62397&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62397&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62397&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62397&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62397&r=support Expected behavior: https://bugs.php.net/fix.php?id=62397&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62397&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62397&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62397&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62397&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62397&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62397&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62397&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62397&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62397&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62397&r=mysqlcfg
Req #61492 [Opn]: flock for php 5.3.2 - regression
Edit report at https://bugs.php.net/bug.php?id=61492&edit=1
ID: 61492
User updated by:spamik at yum dot pl
Reported by:spamik at yum dot pl
Summary:flock for php 5.3.2 - regression
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
"The automatic unlocking when the file's resource handle is closed was removed.
Unlocking now always has to be done manually."
Previous Comments:
[2012-03-23 16:27:16] spamik at yum dot pl
Description:
http://www.php.net/manual/en/function.flock.php
"On versions of PHP before 5.3.2, the lock is released also by fclose() (which
is also called automatically when script finished)."
This is huge regression. I've used with success file locking to check if
another
instance of file is already running putting code like this in front of the
script or append_script
$h55 = fopen($_SERVER['argv'][0],"r");
while(!flock($h55, LOCK_EX + LOCK_NB )) {
echo "cant get lock, die\n";
die();
}
or
$h55 = fopen($_SERVER['argv'][0],"r");
while(!flock($h55, LOCK_EX + LOCK_NB )) {
echo "cant get lock, waiting 10s\n";
sleep(10);
}
I've used it for scripts that had variable running time with a crontab. Now it
is all impossible thanks to that change :(
--
Edit this bug report at https://bugs.php.net/bug.php?id=61492&edit=1
[PHP-BUG] Req #61492 [NEW]: flock for php 5.3.2 - regression
From:
Operating system:
PHP version: 5.3.10
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:flock for php 5.3.2 - regression
Description:
http://www.php.net/manual/en/function.flock.php
"On versions of PHP before 5.3.2, the lock is released also by fclose()
(which
is also called automatically when script finished)."
This is huge regression. I've used with success file locking to check if
another
instance of file is already running putting code like this in front of the
script or append_script
$h55 = fopen($_SERVER['argv'][0],"r");
while(!flock($h55, LOCK_EX + LOCK_NB )) {
echo "cant get lock, die\n";
die();
}
or
$h55 = fopen($_SERVER['argv'][0],"r");
while(!flock($h55, LOCK_EX + LOCK_NB )) {
echo "cant get lock, waiting 10s\n";
sleep(10);
}
I've used it for scripts that had variable running time with a crontab. Now
it
is all impossible thanks to that change :(
--
Edit bug report at https://bugs.php.net/bug.php?id=61492&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61492&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61492&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61492&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61492&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61492&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61492&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61492&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61492&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61492&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61492&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61492&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61492&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61492&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61492&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61492&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61492&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61492&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61492&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61492&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61492&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61492&r=mysqlcfg
[PHP-BUG] Bug #61407 [NEW]: Directive no longer available in PHP
From: Operating system: PHP version: 5.4.0 Package: *General Issues Bug Type: Bug Bug description:Directive no longer available in PHP Description: ./php-cgi Fatal error: Directive 'allow_call_time_pass_reference' is no longer available in PHP in Unknown on line 0 Fatal error: Directive 'magic_quotes_gpc' is no longer available in PHP in Unknown on line 0 1) It should return Content-type header before those errors. Without it webserver wont display error but instead it will generate 500 error 2) It is stupid to throw fatal error on that. Same php.ini are used with multiple php versions commonly. It should be warrning not fatal error. I get that you are trying to show programers that magic quotes are finished but still it is bad decision on fatal error. -- Edit bug report at https://bugs.php.net/bug.php?id=61407&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61407&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61407&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61407&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61407&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61407&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61407&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61407&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61407&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61407&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61407&r=support Expected behavior: https://bugs.php.net/fix.php?id=61407&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61407&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61407&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61407&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61407&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61407&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61407&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61407&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61407&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61407&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61407&r=mysqlcfg
Req #61017 [Fbk->Opn]: ~ in include_path
Edit report at https://bugs.php.net/bug.php?id=61017&edit=1 ID: 61017 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:~ in include_path -Status: Feedback +Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.10 Block user comment: N Private report: N New Comment: right, people are still using mod_php :( That of course is not a issue with suexec + fastcgi Previous Comments: [2012-02-08 17:25:31] ras...@php.net How would that work? Generally the web server will run as some generic user, so ~ and $LOGIN will not have a meaningful value. [2012-02-08 17:21:02] spamik at yum dot pl Description: include_path needs something for home directory or username substitution. Without it tens of tousands of unmanagable php.ini specific to every username are needed. in php.ini include_path = ".:~/pear/php/" or include_path = ".:/home/$LOGIN/pear/php/" -- Edit this bug report at https://bugs.php.net/bug.php?id=61017&edit=1
[PHP-BUG] Req #61017 [NEW]: ~ in include_path
From: Operating system: PHP version: 5.3.10 Package: *General Issues Bug Type: Feature/Change Request Bug description:~ in include_path Description: include_path needs something for home directory or username substitution. Without it tens of tousands of unmanagable php.ini specific to every username are needed. in php.ini include_path = ".:~/pear/php/" or include_path = ".:/home/$LOGIN/pear/php/" -- Edit bug report at https://bugs.php.net/bug.php?id=61017&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61017&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61017&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61017&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61017&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61017&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61017&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61017&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61017&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61017&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61017&r=support Expected behavior: https://bugs.php.net/fix.php?id=61017&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61017&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61017&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61017&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61017&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61017&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61017&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61017&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61017&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61017&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61017&r=mysqlcfg
[PHP-BUG] Req #60354 [NEW]: MYSQL_CLIENT_COMPRESS in php.ini
From: Operating system: PHP version: 5.3.8 Package: MySQL related Bug Type: Feature/Change Request Bug description:MYSQL_CLIENT_COMPRESS in php.ini Description: Using or not using mysql compression (or encryption) is a administrative decision, not decision that should be left for programmer as he usualy has no idea what is mysql configuration, what storage does it use and quite often this programmer just writes genuine aplications. default for compression in mysql client (MYSQL_CLIENT_COMPRESS) should be settable in php.ini http://pl2.php.net/manual/en/mysql.constants.php#mysql.client-flags This would also to permanent connections but You made it into two diffrent commands so it would be more difficult. -- Edit bug report at https://bugs.php.net/bug.php?id=60354&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60354&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60354&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60354&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60354&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60354&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60354&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60354&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60354&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60354&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60354&r=support Expected behavior: https://bugs.php.net/fix.php?id=60354&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60354&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60354&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60354&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60354&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60354&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60354&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60354&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60354&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60354&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60354&r=mysqlcfg
Bug->Req #55242 [Bgs]: upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL
Edit report at https://bugs.php.net/bug.php?id=55242&edit=1 ID: 55242 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL Status: Bogus -Type: Bug +Type: Feature/Change Request Package:Safe Mode/open_basedir PHP Version:5.3.6 Block user comment: N Private report: N New Comment: - Previous Comments: [2011-09-16 04:12:20] spamik at yum dot pl >> Input (including file uploads) processing is done before the script is >> executed I know that, if it were not like that I would chagne it myself. Still a valid bug/feature request. [2011-09-15 15:57:44] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Input (including file uploads) processing is done before the script is executed, this means any ini_set() calls within the script won't matter. For that reason the setting remains as PHP_INI_SYSTEM. [2011-07-19 13:23:44] spamik at yum dot pl Description: http://pl2.php.net/manual/pl/ini.list.php since open_basedir is PHP_INI_ALL since 5.3.x it makes no sense that upload_tmp_dir is still PHP_INI_SYSTEM. Those functions are entwined, even documentation says so: "upload_tmp_dir string The temporary directory used for storing files when doing file upload. Must be writable by whatever user PHP is running as. If not specified PHP will use the system's default. If the directory specified here is not writable, PHP falls back to the system default temporary directory. If open_basedir is on, then the system default directory must be allowed for an upload to succeed." -- Edit this bug report at https://bugs.php.net/bug.php?id=55242&edit=1
Bug #55242 [Bgs]: upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL
Edit report at https://bugs.php.net/bug.php?id=55242&edit=1 ID: 55242 User updated by:spamik at yum dot pl Reported by:spamik at yum dot pl Summary:upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL Status: Bogus Type: Bug Package:Safe Mode/open_basedir PHP Version:5.3.6 Block user comment: N Private report: N New Comment: >> Input (including file uploads) processing is done before the script is >> executed I know that, if it were not like that I would chagne it myself. Still a valid bug/feature request. Previous Comments: [2011-09-15 15:57:44] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Input (including file uploads) processing is done before the script is executed, this means any ini_set() calls within the script won't matter. For that reason the setting remains as PHP_INI_SYSTEM. [2011-07-19 13:23:44] spamik at yum dot pl Description: http://pl2.php.net/manual/pl/ini.list.php since open_basedir is PHP_INI_ALL since 5.3.x it makes no sense that upload_tmp_dir is still PHP_INI_SYSTEM. Those functions are entwined, even documentation says so: "upload_tmp_dir string The temporary directory used for storing files when doing file upload. Must be writable by whatever user PHP is running as. If not specified PHP will use the system's default. If the directory specified here is not writable, PHP falls back to the system default temporary directory. If open_basedir is on, then the system default directory must be allowed for an upload to succeed." -- Edit this bug report at https://bugs.php.net/bug.php?id=55242&edit=1
[PHP-BUG] Req #55271 [NEW]: open_basedir_include_dir
From:
Operating system:
PHP version: 5.3.6
Package: Safe Mode/open_basedir
Bug Type: Feature/Change Request
Bug description:open_basedir_include_dir
Description:
I'd like to propose making new php.ini var - open_basedir_include_dir -
like
safe_mode_include_dir , which would allow accessing one dir (files only in
it)
when open_basedir is set to other dir. Usual aplication of this would be
"/tmp".
Since 5.3.x php allows tightening open_basedir. However tempnam() function
(http://www.php.net/manual/pl/function.tempnam.php) does require as first
parameter dir name. It does not take it from any php.ini var. So
programmers had
to hardcode in almost every program something like tempnam("/tmp",
This makes open_basedir tightening useless as /tmp will remain unaccessible
so
tempnam() will fails. Solution would be open_basedir_include_dir ...
--
Edit bug report at https://bugs.php.net/bug.php?id=55271&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55271&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55271&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55271&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55271&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55271&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55271&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55271&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55271&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55271&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55271&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55271&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55271&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55271&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55271&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55271&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55271&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55271&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55271&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55271&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55271&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55271&r=mysqlcfg
[PHP-BUG] Bug #55242 [NEW]: upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL
From: Operating system: PHP version: 5.3.6 Package: Safe Mode/open_basedir Bug Type: Bug Bug description:upload_tmp_dir should be PHP_INI_ALL since open_basedir became PHP_INI_ALL Description: http://pl2.php.net/manual/pl/ini.list.php since open_basedir is PHP_INI_ALL since 5.3.x it makes no sense that upload_tmp_dir is still PHP_INI_SYSTEM. Those functions are entwined, even documentation says so: "upload_tmp_dir string The temporary directory used for storing files when doing file upload. Must be writable by whatever user PHP is running as. If not specified PHP will use the system's default. If the directory specified here is not writable, PHP falls back to the system default temporary directory. If open_basedir is on, then the system default directory must be allowed for an upload to succeed." -- Edit bug report at https://bugs.php.net/bug.php?id=55242&edit=1 -- Try a snapshot (PHP 5.2): https://bugs.php.net/fix.php?id=55242&r=trysnapshot52 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55242&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55242&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55242&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55242&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55242&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55242&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55242&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55242&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55242&r=support Expected behavior: https://bugs.php.net/fix.php?id=55242&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55242&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55242&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55242&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55242&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55242&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55242&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55242&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55242&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55242&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55242&r=mysqlcfg Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55242&r=trysnapshot54
