PHP 4.3.2 Released 49
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."
Re:It has to be said... (Score:5, Funny)
Re:It has to be said... (Score:1)
Re:It has to be said... (Score:1)
Two words. Overloaded Operators.
Re:It has to be said... (Score:1)
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.
Re:It has to be said... (Score:1)
How's the Apache 2.0 support? (Score:4, Insightful)
Re:How's the Apache 2.0 support? (Score:5, Informative)
Re:How's the Apache 2.0 support? (Score:1)
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 de
Re:How's the Apache 2.0 support? (Score:5, Informative)
http://httpd.apache.org/docs-2.1/developer/thre
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? (Score:1)
-h3
Re:How's the Apache 2.0 support? (Score:1)
php programmers (Score:3, Insightful)
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 (Score:2)
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 man
SQL Injection Considered Harmful (Score:2)
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 (Score:2)
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
SQL Injection example from PostNuke (Score:2)
Re:php programmers (Score:2, Informative)
Easy, because the same could be said of ASP,
Deeply unfair moderation (Score:4, Insightful)
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 (Score:5, Informative)
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:
$db->execute("SELECT * FROM my_table WHERE id = $userInput");
vs.
$db->execute('SELECT * FROM my_table WHERE id =
This is not limited to the 'Nukes or PHP. Perl, Python, C, Java, etc. all suffer from the same problem.
Re:Deeply unfair moderation (Score:4, Informative)
Re:Deeply unfair moderation (Score:1)
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
Re:Deeply unfair moderation (Score:2)
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. lea
Re:php programmers (Score:1)
Re:php programmers (Score:1)
Apache & PHP (Score:2, Interesting)
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 (Score:2)
Re:Apache & PHP (Score:1)
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 (Score:3, Insightful)
Re:Apache & PHP (Score:1)
http://perl.apache.org/
Re:Apache & PHP (Score:2)
Re:Apache & PHP (Score:4, Informative)
The last sentence on the right of the main PHP page says:
You're confusing one Apache propject (namely, the webserver) with the entire suite of Apache software.
changes to note (Score:5, Informative)
# 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 (Score:2)
PHP 4.3.2 Release Summary (Score:3, Informative)
python (Score:2, Funny)
I use Python you insensitive clod!