PHP 4.3.2 Released

seldo writes "Everyone's favourite scripting language ;-) has released an update. From their site: 'The PHP developers are proud to announce the immediate availability of PHP 4.3.2. This release contains a huge number of bug fixes and is a strongly recommended update for all users of PHP. Full list of fixes can be found in the NEWS file.' This incremental release also has useful additions, such as updating to support GD 2.0.12."

Comments

How's the Apache 2.0 support?

[poulbailey]

What's the official word on Apache 2.0 support? Do they still recommend that you use Apache 1.x for now?

Re:How's the Apache 2.0 support?

[yelvington]

PHP and Apache 2.0 play together nicely. However, some third-party libraries that extend PHP's core functionality do NOT play nicely in a threaded environment. Solution: Run Apache 2.0 in prefork mode.

Re:How's the Apache 2.0 support?

[yelvington]

There's a list of commonly used libraries on the Apache Web site, but it's full of question marks, and postgres isn't mentioned.

http://httpd.apache.org/docs-2.1/developer/threa d_ safety.html#commonlibs

The list really addresses the issue of linking the libraries directly with Apache, but I presume it's the same issue as indirectly linking through PHP.

libmysqlclient is thread-safe if compiled with the proper flags.

php programmers

[InsaneCreator]

PHP, being one of the simplest languages to learn, unfortunately attracts HUGE numbers of really bad programmers, who only know how to retrieve data from a DB (mysql, of course) and print it out using a simple loop. And then they think they know everything.

Theese are the people creating many "professional" websites - people, who have no idea why using register_globals is a distster waiting to happen, what is SQL injection, why every bit comming from the user should be treated as unsafe, etc.

PHP might be easy to use, but it's also very easy to write scripts, which should never be allowed to run on a networked computer.

changes to note

[ubiquitin]

I combed through the changenotes and here are the ones that I thought were among the most important:

# Added a new Apache 2 SAPI module (apache2handler) based on the old version (apache2filter).
# Fixed several 64-bit problems
# Fixed bug #22672 (User not logged under Apache2). (Ian)
# Fixed bug #22989 (sendmail not found by configure). (igyu@ionsphere.org)
# Fixed bug #17098 (make Apache2 aware that PHP scripts should not be cached). (Ilia)
# Fixed bug #20802 (PHP would die silently when memory limit reached). (Ilia)
# Fixed bug #21498 (mysql_pconnect connection problems). (Georg)

Deeply unfair moderation

[$rtbl_this]

Everything InsaneCreator just said is true. I've worked with people who have written amazingly dangerous PHP scripts for commercial web sites and don't have the programming background to understand why their code is so insecure. With support for automating PHP code generation built into Dreamweaver this is probably going to become a more widespread problem.

It's very easy to pick up the basics of PHP and develop scripts quickly, even with limited programming experience. Sadly until recently so many of the default settings in PHP (still required by a lot of freely available scripts out there) make it a non-trivial task to secure these scripts. The point about register_globals is a good one -- the fact that it allows users to change the value of a variable by specifying it in the URL is extremely dangerous for obvious reasons. This has not been the default behaviour in PHP for some time, but most people I know end up switching it back on to avoid having to rewrite all their scripts to use HTTP session variables.

Of course it's possible to write insecure code in any language, and the newer versions of PHP have filled in some of the bigger security holes, but by being so newbie friendly it's still going to end up with more than its share of dangerous scripts.

And don't even get me started on PHP-Nuke! :)

Re:Deeply unfair moderation

[mbogosian]

It's very easy to pick up the basics of PHP and develop scripts quickly, even with limited programming experience. Sadly until recently so many of the default settings in PHP (still required by a lot of freely available scripts out there) make it a non-trivial task to secure these scripts.

The same might be said for C. How many inexperienced C programmers have you seen do something like this:

#include <string.h>

int main(int argc, char *argv[])
{
char buffer[1024];

if (argc > 1)
{
strcpy(buffer, argv[1]);
}

return 0;
}

register_globals was never a good idea. That's why it's been off by default for the past several releases. Unless you're using placeholders in your SQL, nearly every Web app has the potential to be susceptable to bad things:

/* SQL injector's dream */
$db->execute("SELECT * FROM my_table WHERE id = $userInput");

vs.

/* The only way to fly */
$db->execute('SELECT * FROM my_table WHERE id = :?', $vars);

This is not limited to the 'Nukes or PHP. Perl, Python, C, Java, etc. all suffer from the same problem.

Re:Deeply unfair moderation

[Just Some Guy]

Mainly because $userInput could be something like '"foo" or creditCard not null' to get a listing of every record with a credit card field in that table.

Re:Apache & PHP

[clonebarkins]

The last sentence on the right of the main PHP page says:

PHP is a project of the Apache Software Foundation.

You're confusing one Apache propject (namely, the webserver) with the entire suite of Apache software.

Re:It has to be said...

[tha_mink]

People still use perl? I thought it died in the big explosion at the punctuation factory....