Through an interview on SecurityFocus Stefan Esser has just announced his plans for the "Month of PHP Bugs" (MOPB?) during March 2007. It would be interesting to see what issues he discovers, hopefully most of them have already been reported to the PHP Security Team, in which case the upcoming 5.2.1 release will provide a resolution path for affected users. Hopefuly, unlike the MOAB and MOKB, the reported issues are not going to be infamous 0-day vulnerabilities. If they are however, which would be unfortunate, I think we'd be looking at a security fix only release in April, while releasing patches to address individual issues on a daily basis. Either way, I have to look at this as a free security audit of PHP by someone with a clue about security and ultimately, in the long run it will only make PHP better, even if March is going to be rather busy ;-)

I've packaged what looks the be the final RC for the 5.2.1 release, RC4. This release fixes another dozen or so bugs since the last release and from the given feedback looks to be regression free. That said I'd like to ask everyone to take a few minutes and try this RC with their code to make sure it really is as good as it seems and to ensure no new issues are introduced. If you come across any issue please let me know via http://bugs.php.net, this blog, or internals mailing list. The tarballs for this release can be found here: http://downloads.php.net/ilia/php-5.2.1RC4.tar.bz2 (md5sum: f50578276f653b1f523150e3ff987f03) http://downloads.php.net/ilia/php-5.2.1RC4.tar.gz (md5sum: 361197eb2b21b36e2e20cb132da2cf16)

The 3rd release candidate for PHP 5.2.1 is now available for download. The tarballs can be found here: http://downloads.php.net/ilia/php-5.2.1RC3.tar.bz2 (d3889eda8c3471ce7cf2adb35a4de736) http://downloads.php.net/ilia/php-5.2.1RC3.tar.gz (c5b3e5540d1951d4c4b976b8a39c09ab) and the Win32 binaries will be available in short order. Since the last release, there are over 20 different bug fixes resolving some annoying engine issues such as the tempval leak inside foreach(). We do not anticipate any regressions to be introduced by this RC, but I would still like to ask everyone to take a few minutes and test it against their code base. If you come across any issues please report them at http://bugs.php.net/. Depending on the stability of this release it may either be followed by a final release or another RC, therefor your feedback is critical to determining whether or not the code is stable enough to warrant the 5.2.1 final.

Thanks to Steph's hard work the last few months of weeklies are now available for reading. If you don't have the time or keep an eye on what's going on in the PHP community, especially on the developer mailing lists, weeklies are a quick shortcut to getting yourself up to date.

Every web developer knows how to make a GET redirect, in fact they've probably done it numerous times. However very few people know the same can be done for POST requests, in some instances completely transparently to the user. This by itself make not seem like an issue, but when you combine it with XSS it can be a very powerful to used to scam users. Consider the following scenario. A user goes to a trusted site where XSS had modified the action field of the login POST form, pointing it to http://p0wn3d.com/post.php. When user submits a request it goes to a 3rd party site, which captures the login credentials and then redirects the POST data to the original site. In the end to the user has no clue something sinister had happened because they never see p0wn3d.com. In fact the everything appears to have worked as intended. So how does this work. Ability to redirect POST comes as a courtesy of the little known 307 redirect code. Which in PHP can be forced in the following manner: [php] header("Location:...