Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-src
Sebastian Bergmann wrote: Rasmus Lerdorf wrote: rasmus Wed, 25 Nov 2009 01:30:06 + Revision: http://svn.php.net/viewvc?view=revisionrevision=291283 Log: Someone strap down Jani and give him a sedative please. This makes our toolchain work with the latest versions of autoconf and avoids a lot of end-user grief. Without autoconf2.13 installed, I get the following on my Ubuntu 9.10: I didn't claim to have fixed all warnings. I simply claimed that I made it work. Those are just warnings. Everything builds fine now where it didn't work at all before. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-s
On 25.11.2009 09:57, Pierre Joye wrote: hi Sebastian, open a bug please :) On Wed, Nov 25, 2009 at 7:54 AM, Sebastian Bergmann s...@sebastian-bergmann.de wrote: Rasmus Lerdorf wrote: rasmus Wed, 25 Nov 2009 01:30:06 + Revision: http://svn.php.net/viewvc?view=revisionrevision=291283 Log: Someone strap down Jani and give him a sedative please. This makes our toolchain work with the latest versions of autoconf and avoids a lot of end-user grief. Without autoconf2.13 installed, I get the following on my Ubuntu 9.10: I suspect there is no way to fix it. And also no point to fix it, since it still works fine, even with all these warnings. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-sr
On 25.11.2009, at 12:59, Antony Dovgal wrote: On 25.11.2009 09:57, Pierre Joye wrote: hi Sebastian, open a bug please :) On Wed, Nov 25, 2009 at 7:54 AM, Sebastian Bergmann s...@sebastian-bergmann.de wrote: Rasmus Lerdorf wrote: rasmus Wed, 25 Nov 2009 01:30:06 + Revision: http://svn.php.net/viewvc?view=revisionrevision=291283 Log: Someone strap down Jani and give him a sedative please. This makes our toolchain work with the latest versions of autoconf and avoids a lot of end-user grief. Without autoconf2.13 installed, I get the following on my Ubuntu 9.10: I suspect there is no way to fix it. And also no point to fix it, since it still works fine, even with all these warnings. Wouldn't following recommendations printed in warnings help? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-sr
On 25.11.2009 13:36, Alexey Zakhlestin wrote: Wouldn't following recommendations printed in warnings help? Sure, but only for newer autoconf versions. Which means we would break autoconf 2.13 if we follow them. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-sr
On 25.11.2009, at 13:43, Antony Dovgal wrote: On 25.11.2009 13:36, Alexey Zakhlestin wrote: Wouldn't following recommendations printed in warnings help? Sure, but only for newer autoconf versions. Which means we would break autoconf 2.13 if we follow them. Is that a problem for trunk, for example? All modern systems have newer autoconf-versions. And trunk means +1 year from now, at least -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-sr
On Wed, 25 Nov 2009, Alexey Zakhlestin wrote: On 25.11.2009, at 13:43, Antony Dovgal wrote: On 25.11.2009 13:36, Alexey Zakhlestin wrote: Wouldn't following recommendations printed in warnings help? Sure, but only for newer autoconf versions. Which means we would break autoconf 2.13 if we follow them. Is that a problem for trunk, for example? All modern systems have newer autoconf-versions. And trunk means +1 year from now, at least 2.13 works a whole lot better, so yes, that is a problem. Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: / pecl/pdo_4d/trunk/config.m4 pecl/pdo_ibm/trunk/config.m4 pecl/pdo_informix/trunk/config.m4 pecl/pdo_user/trunk/config.m4 php/php-src/branches/PHP_5_2/acinclude.m4 php/php-sr
Alexey Zakhlestin wrote: On 25.11.2009, at 13:43, Antony Dovgal wrote: On 25.11.2009 13:36, Alexey Zakhlestin wrote: Wouldn't following recommendations printed in warnings help? Sure, but only for newer autoconf versions. Which means we would break autoconf 2.13 if we follow them. Is that a problem for trunk, for example? All modern systems have newer autoconf-versions. And trunk means +1 year from now, at least All new autoconf versions suck. Only properly working version is 2.13. Please, it works, leave it alone. There are more important things to worry about. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Hello, clang is indeed a great tool but since it does a lot more than just static analysis. For those cases where one wants source code analysis, especially security oriented, I'd recommend flawfinder [http://www.dwheeler.com/flawfinder]. This is a very good tool and it exists in the official repos for Debian, Ubuntu and FC [and probably many others but these I checked]. It can operate on both C and C++ source files [less relevant for the PHP engine but good to know, right?]. I ran it against the PHP 5.2.11 sources and am now sorting through results, patching suggestions may follow :) May the source be with you, Best regards, Jess Portnoy Michael Maclean wrote: Hi, Gwynne pointed me at the clang static analyser earlier on today, and so I've run it against current PHP_5_3. In the course of messing with it, it noticed a potential null dereference in ext/ftp - I've attached a one-liner to fix it. Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Hi, Jess Portnoy wrote: clang is indeed a great tool but since it does a lot more than just static analysis. Yeah, it looked like an interesting thing and so I decided to play with it. Incidentally, I discovered later that clang appears to compile PHP 5.3 pretty much flawlessly just now (at least for my particular set of configure options). The scan-build analyser thing I used ran the code through clang before forwarding it on to gcc for the actual compilation. For those cases where one wants source code analysis, especially security oriented, I'd recommend flawfinder [http://www.dwheeler.com/flawfinder]. I'll have a look. Thanks for the tip. I ran it against the PHP 5.2.11 sources and am now sorting through results, patching suggestions may follow :) Heh. If anyone wants to see the output from scan-build that I got, it's at http://mgdm.net/~michael/php-5.3-clang/ along with the notes.txt that I'm filling in as I go along. Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Hey, The thing I like a lot about clang is that it can be used as a drop-in substitute for GCC so you can actual call clang or clang++ instead of executing gcc/g++, see here: http://clang.llvm.org/get_started.html The results you published certainly look interesting :) May the source be with you, Best regards, Jess Portnoy Michael Maclean wrote: Hi, Jess Portnoy wrote: clang is indeed a great tool but since it does a lot more than just static analysis. Yeah, it looked like an interesting thing and so I decided to play with it. Incidentally, I discovered later that clang appears to compile PHP 5.3 pretty much flawlessly just now (at least for my particular set of configure options). The scan-build analyser thing I used ran the code through clang before forwarding it on to gcc for the actual compilation. For those cases where one wants source code analysis, especially security oriented, I'd recommend flawfinder [http://www.dwheeler.com/flawfinder]. I'll have a look. Thanks for the tip. I ran it against the PHP 5.2.11 sources and am now sorting through results, patching suggestions may follow :) Heh. If anyone wants to see the output from scan-build that I got, it's at http://mgdm.net/~michael/php-5.3-clang/ along with the notes.txt that I'm filling in as I go along. Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Jess Portnoy wrote: The thing I like a lot about clang is that it can be used as a drop-in substitute for GCC so you can actual call clang or clang++ instead of executing gcc/g++, see here: Sure, that's how I compiled PHP with it. CC=clang ./configure --enable-all --my-usual=stuff make make test :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Jess Portnoy wrote: Hello, clang is indeed a great tool but since it does a lot more than just static analysis. For those cases where one wants source code analysis, especially security oriented, I'd recommend flawfinder [http://www.dwheeler.com/flawfinder]. I find that flawfinder is way too simplistic. It just does a grep for certain strings and spews a canned warning. For example: basic_functions.c:137: [4] (buffer) sprintf: Does not check for buffer overflows. Use snprintf or vsnprintf. basic_functions.c:2778: [4] (buffer) sprintf: Does not check for buffer overflows. Use snprintf or vsnprintf. basic_functions.c:2779: [4] (format) printf: If format strings can be influenced by an attacker, they can be exploited. Use a constant for the format specification. Now, that sounds very scary, until you look at those source code lines: 137: #undef sprintf 2778: PHP_NAMED_FE(sprintf, PHP_FN(user_sprintf), arginfo_sprintf) 2779: PHP_NAMED_FE(printf,PHP_FN(user_printf),arginfo_printf) It is so littered with false positives like this that I don't find it useful. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Hello, I agree that it [potentially] many false positives and the is even addressed in the homepage. While this is common to most static analyzers to some extent and requires going through each find with care while mumbling again with this crap.., I still think it has some value. One person's opinion. May the source be with you, Best regards, Jess Portnoy Rasmus Lerdorf wrote: Jess Portnoy wrote: Hello, clang is indeed a great tool but since it does a lot more than just static analysis. For those cases where one wants source code analysis, especially security oriented, I'd recommend flawfinder [http://www.dwheeler.com/flawfinder]. I find that flawfinder is way too simplistic. It just does a grep for certain strings and spews a canned warning. For example: basic_functions.c:137: [4] (buffer) sprintf: Does not check for buffer overflows. Use snprintf or vsnprintf. basic_functions.c:2778: [4] (buffer) sprintf: Does not check for buffer overflows. Use snprintf or vsnprintf. basic_functions.c:2779: [4] (format) printf: If format strings can be influenced by an attacker, they can be exploited. Use a constant for the format specification. Now, that sounds very scary, until you look at those source code lines: 137: #undef sprintf 2778: PHP_NAMED_FE(sprintf, PHP_FN(user_sprintf), arginfo_sprintf) 2779: PHP_NAMED_FE(printf,PHP_FN(user_printf),arginfo_printf) It is so littered with false positives like this that I don't find it useful. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] default session serialization
Hi! Attached is a patch (against HEAD) which adapts the default (php) session serializer to serialize the whole array using php_var_serialize instead of calling it once per element. This simplifies the serialization code, and allows unicode session keys, or even ascii keys containing the pipe character. I think it makes sense. One note: your code allows numeric session keys, previously not allowed. Not sure if it's important. However it would be a significant BC break, as old serialized session records would be unreadable after upgrading. We could mitigate this by providing a script to convert old session files. If it would be a problem, we could always keep an old one as php_old for a while for those who need it, just not make it the default. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP socket automatically shuts down after ? hours of idling?
Hi all, after running a strace program, I've found the real issue with in it. It was a mysql connection timeout causing the PHP encountering a fatal error, and shuts down the server. Thank you all again for your time and help. :D Hi what is your platform ?2. Provide a working, migth be a recent problem regarding x socket, can you observe and dump your tcp connexion? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
