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.

Re:php programmers

[tha_mink]

how can this post be modded as troll when he has a very valid point?


Easy, because the same could be said of ASP, .NET, VBScript, and yes PERL. I have seen plenty of bastardized perl. Yes perl monkeys, people can abuse your shitty language too. You can write shitty code in ANY language. (visual c++ comes to mind)

Apache & PHP

[termos]

This story is about PHPs new version. PHP is a scripting language which can do a lot of things. The most used is of course on the WEB, but there is also a lot of httpd, and apache is one of them, so I ask: What does story have to do with Apache?.
Perl is also supported by Apache, but I don't see Perl news under some Apache section. Don't get me wrong on this though, I love Apache and PHP, but they are two independent pieces of software.

Re:Apache & PHP

[TheSunborn]

The point MIGHT be that php is part of apache. Remember Apache is far more then just a webserver. Just have a look at php.apache.org

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.

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:It has to be said...

[tha_mink]

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

PHP 4.3.2 Release Summary

[dananderson]

Major changes, from the release Announcement:

• Fixes several potentially hazardous integer and buffer overflows.
• Fixes for several 64-bit problems.
• New Apache 2.0 SAPI module (sapi/apache2handler, enabled with --with-apxs2).
• New session_regenerate_id() function. (Important feature against malicious session planting).
• Improvements to dba extension.
• Improvements to thttpd SAPI module.
• Dropped support for GDLIB version 1.x.x (php_gd.dll) on Windows.
• An unix man page for CLI version of PHP.
• New "disable_classes" php.ini option to allow administrators to disable certain classes for security reasons.

python

[Alpha_Nerd]

Everyone's favourite scripting language ;-)

I use Python you insensitive clod!