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?

[h3]

some third-party libraries that extend PHP's core functionality do NOT play nicely in a threaded environment

This has been the stock answer for a while (and I don't question it), but has anyone ever seen a list detailing each module and whether they are thread-safe under Apache 2? There are *tons* of modules and I only use a small subset so I would like to be able to check a list to see if I might be OK to try Apache 2.

The big one for me would be Postgres.

Anyone seen such a list? I've asked one of the developers and he sort of brushed it off. A list such as this might very well speed up adoption for people like me.

-h3

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.

Re:How's the Apache 2.0 support?

[h3]

Hey, cool, thanks for the link. Turns out Postgres *is* on there, listed under "libpq" and marked as thread-safe with a couple of exceptions.

-h3

Re:How's the Apache 2.0 support?

[C_Kode]

I have a webapp that uses PHP/Apache2/PostgreSQL without issue. But I would research more before using it for your applications. I had gotten to test it quite abit before porting the whole application over to PostgreSQL from MySQL.

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

[spectral]

PHP, being one of the simplest languages to learn, unfortunately attracts HUGE numbers of really bad programmers

And that's exactly why I use PHP! Err..

I know how to write good code (I think. How do you define what's good?). I know why register_globals is bad (and I have it turned off). I have no clue wtf SQL injection is, but obviously every bit coming from the user should be treated as unsafe, and I code that way too. Fucking with sites that don't is something I consider my civil duty. (Way too many rating sites allow you to put in any rating you want by a simple HTML hack. Yep, a couple ratings of like 1,000 stars is all you need to boost that [skin/program/artist/website] up to the top of the list..)

PHP is nice for quickly doing things, and being able to read it the week afterwards. Perl just scares me. :)

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)

Re:php programmers

[aled]

So what you are saying is that php is the visual basic of the web? :-)

Re:php programmers

[Islington_66_81]

people need to get away from using PHP and start using JSP. In simple terms its basicly the same thing but you have access to all the wonderful things that Java servlets provides and PHP doesnt. (ie. easy to read. easy to code. much greater functionality.)

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

[bofkentucky]

The /. cabal only regards two languages as relevant C and Perl, they deny or try to bury other interesting and/or useful languages, like PHP, Java, Ruby, or Smalltalk. I wonder if a properly tuned php/apache combo could keep up with /code's perl/mod_perl/apache cluster setup. Admitedly /code has served them mostly well for 250,000 users with some hiccups here and there, but there are plenty of other CMS+Blog engines out there written in php or perl. Scoop, php-Nuke, and postNuke are some of the big ones.

Re:Apache & PHP

[questionlp]

Although PHP is available for many other web servers and is capable running as a standalone scripting engine, the PHP Project under the Apache Software Foundation umbrella (as stated on the front page of php.net). I'm not sure when the change took place though.

So it make some sense putting it under the Apache section, though putting it under the Developers section as well as Apache, and PHP would have been a better choice.

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.

Re:Apache & PHP

[tha_mink]

So I guess perl is a part of apache too then eh?...


http://perl.apache.org/

Re:Apache & PHP

[TheSunborn]

It is listen as an apache project at www.apache.org

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)

Re:changes to note

[Kris_J]

Have they fixed the "arrays don't deep copy" problem yet? Man, that bites.

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:Deeply unfair moderation

[FryGuy1013]

not necessarily.

He didn't use single quotes around the id, so for instance:

$userInput = "12 or 1 = 1";

would cause problems. However, I still don't think turning off register globals is a good thing necessarily. How many people will just start using $POST["foo"] instead of $foo and not checking anything?

I think the main people that think leaving register_globals on is for attacks on code like this:

$rows = sql_query("select users from users where username = '$username'");
foreach ($rows as $row) {
if ($row["password"] == $password)
$access = true;
}

if ($access) {
`$shellcommand`;
}

Which is inherently bad because variables are not initialized. If you initialize your variables, then I don't see any problems with leaving register_globals on.

Re:Deeply unfair moderation

[mbogosian]

Which is inherently bad because variables are not initialized. If you initialize your variables, then I don't see any problems with leaving register_globals on.

I agree that it's bad to not be in the habbit of initializing your variables. However might forget once or twice. Since PHP doesn't complain (unless debugging is on) if that happens, having register_globals on it makes things that much more precarious.

The moral?

1. always initialize your variables in the scope in which you intend to use them
2. leave debugging on throughout most of your testing
3. keep register_globals off

Re:It has to be said...

[tha_mink]

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

SQL Injection Considered Harmful

[dananderson]

I have no clue wtf SQL injection is

SQL injection is, TF, inserting SQL code through HTLM forms. This is done by adding close and open quotes and comments.

The SQL code added could do anything, if not otherwise restricted--such as dump or modify the data base.

Re:SQL Injection Considered Harmful

[spectral]

meh, I mostly just make sure its the type of data I expect.. if it's supposed to be a string containing only certain chars, make sure it does. if it's a freeform string, use the function(s) available for escaping it. If it's supposed to be numeric.. well, that's what is_numeric is for.

Then I just shove them in the query the way they are if they pass the tests... Is there any other way to do this? (what's this :? thing someone posted about below?)

Re:It has to be said...

[perrin_harkins]

You're fooling yourself if you believe that PHP is going to be inherently easier to read and maintain than well-written Perl. Bad PHP code and bad Perl code are both awful to look at.

Re:It has to be said...

[tha_mink]

C'mon dude....
Two words. Overloaded Operators.

Re:It has to be said...

[perrin_harkins]

Operator overloading is a very rarely used feature. I've never seen anyone use it for anything more than improving the string representation of objects. Good code doesn't do things like that when they aren't necessary.

There's no point in talking about all the ways people could intentionally obscure their code. Good coders who intend to write readable code have no problem doing so in Perl.

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!

Re:It has to be said...

[Vajsvarana]

Sorry... I've tried to write obfuscated code in both language, and you can believe me when I say that there is NO WAY, no matter how hard you try, to make a badly written PHP script less readable than a not-much-badly written Perl one.

SQL Injection example from PostNuke

[brlewis]

PostNuke security alert due to SQL Injection