In this recent post to his site Phil Sturgeon has a reminder that you should select the dependencies for your packages wisely, and not just because they're "cool."

When I say "make sure it is worth it" I mean, don't just switch your arrays from array() to [] just because it looks cool. That was the extent of my original tweet, because I've seen a few packages doing that and it annoyed me immensely. [...] Suffice it to say, if you require a user to upgrade their version of PHP simply so you can use some syntactical sugar inside a package that nobody else is even going to be looking at, then you're an idiot. Beyond that, you're actually hurting the community.

He notes that, by requiring users that are currently only at 3.1% of PHP installs to upgrade to 5.4 just to use your library is a quick way to not have your library used. He points out that PHP 5.4 is "more than just []" for arrays and includes a reminder that several projects are still in PHP 5.3-compatibility mode just because that's the widest audience. He also briefly touches on the "push it forward" comments that people have used to justify 5.4-only packages, but notes that it's still not as much up to the developer as it is the web host.

Greg Freeman has posted the second part of his "hacked PHP application" series (part one is here). In this new post he looks at the aftermath - what to do and check to do cleanup and fixes so it doesn't happen again.

This is a follow up post from my previous post "How to Tell if Your PHP Site has been Hacked or Compromised". This post will discuss some the first steps you should take when you have identified that your site has been compromised. The first sections discuss a few points that are not relevant to everyone, the later sections will discuss how to fix the exploits.

He includes a list of things to think about including:

• What kind of hosting you use (and if that contributed)
• The option to redirect all requests for your site to one page
• Get a list of all PHP files to locate something malicious
• Locating "non-PHP PHP files"
• Finding files with possible malicious content

He also includes a few suggestions to help prevent issues in the future - update to the latest versions, patch your code, rethinking your permissions and monitoring for potential repeat attacks.

On PHP.net the project has posted about the release of the latest versions in the PHP 5.4.x and 5.3.x series - PHP 5.4.11 and 5.3.21:

The PHP development team announces the immediate availability of PHP 5.4.11 and PHP 5.3.21. These releases fix about 10 bugs. All users of PHP are encouraged to upgrade to PHP 5.4.

You can check out the Changelog if you're interested in what bugs were corrected by this release. The downloads are available via the main downloads page (or here for the Windows users out there).

The PHP project has officially released versions 5.4.10 and 5.3.20 if the language:

The PHP development team announces the immediate availability of PHP 5.4.10 and PHP 5.3.20. These releases fix about 15 bugs. Please note that the PHP 5.3 series will enter an end of life cycle and receive only critical fixes as of March 2013. All users of PHP are encouraged to upgrade to PHP 5.4.

Downloads are available here (source) or here for Windows installations. The Changelog has the full list of bugs fixed these two releases. If you're interested in the migration from PHP 5.3 to 5.4 and are wondering what changes you can expect, check out this migration guide with a list of the new features and changes.

Engine Yard/Orchestra, a PHP platform-as-a-service (PaaS) provider has announced the release of PHP 5.4 as a part of their cloud offerings:

We're pleased to announce the general availability of PHP 5.4 for Orchestra PHP Cloud. We are committed to keeping your apps running on the latest and greatest version of PHP. After careful lab testing, we'll upgrade your apps as newer versions of PHP become available. What if you're still using PHP 5.3? Don't worry, Orchestra PHP Cloud will continue to maintain its PHP 5.3 stack. You will be able to choose which version of PHP you would like to use when you launch a new app.

The default when you set up a new application will now be PHP 5.4, so be sure you're paying attention on setup if you need something else. You can find out more about the Orchestra PaaS on the Engine Yard site and try it out for free to see how your app performs.

As reported in this new post on PHPBuilder.com, there are two new security issues that could allow an attacker to execute their own code (note: these are fixed by the latest releases, PHP 5.4.4 and PHP 5.3.14).

The flaws are related to each other, with the primary issue being an insecure implementation of the DES within the crypt() function. In his eSecurityPlanet article about recent PHP security updates, Sean Michael Kerner provides the details of these two security flaws.

The issue stems from a flaw in the DES implementation where certain keys are truncated before the DES digestion and a problem in the phar extension that could allow for arbitrary code execution. You can find more on these security issues here.

The PHP project has officially released the latest versions of the language - PHP 5.3.11 and PHP 5.4.1:

The PHP development team announces the immediate availability of PHP 5.3.11 and PHP 5.4.1. These releases focuses on improving the stability of the current PHP branches with over 60 bug fixes, some of which are security related. [...] For a full list of changes in PHP 5.3.11 and PHP 5.4.1, see the ChangeLog. For source downloads please visit our downloads page, Windows binaries can be found on windows.php.net/download/. All users of PHP are strongly encouraged to upgrade to PHP 5.3.11 or PHP 5.4.1.

Several bugs were fixed in both releases including issues with validation of the name of the uploaded file, adding open_basedir checks to readline_write_history/readline_read_history, and the addition of debug info handler to DOM objects.

In the wake of the official release of PHP 5.4 Sebastian Marek has made a quick post to his blog about bringing PHP_CodeSniffer rules help bring his code up to date with this latest version.

So with PHP 5.3 upgrade underway (and PHP 5.4 out of the door now!) I thought it's time to prepare for PHP 5.4 and make sure we're compatible. So by looking at Wim Godden's PHP53Compatibility code sniffs I have created a base for PHP 5.4 sniffs that we want to use to make sure we're compatible.

Sniffs included in set are:

• PHP54Compatibility_Sniffs_PHP_BreakContinueVarSyntaxSniff
• PHP54Compatibility_Sniffs_PHP_DeprecatedFunctionsSniff

You can grab this custom set of sniffs either from his github repository or from his personal PEAR channel if you'd rather install it that way (alpha channel).

Davey Shafik has a recent post to his blog about what he calls "The Blowfish Debacle" - the issues that came up with the PHP 5.3.7 release to upgrade the crypt_blowfish version that resulted in a larger error being introduced.

This was a great security fix, solving an issue with insecure passwords due to incorrect behavior. HOWEVER, what wasn't made clear, is that this change was actually a backwards compatibility break. If you upgraded to 5.3.7+ data hashed pre-5.3.7 would no longer match data hashed post-5.3.7; this means if you use it for passwords, it will no longer match. So what's the deal here?

He talks about the differences in the two methods of encryption, the newer being the "more correct" way of doing things. If you need the backwards compatibility because of previously hashed values, you can use the "$2x$" prefix instead of the usual "$2a$". He includes a snippet of code that can be used to upgrade all of your previously hashed blowfish passwords up to the new format.

On the PHPClasses.org blog today there's a new post looking at the security vulnerability that effected not only PHP but lots of other languages making them susceptible to attack from the outside.

In PHP and several other languages used to implement Web applications, arrays are used to store the values of request variables such as $_GET, $_POST, $COOKIE, etc.. IF you receive a request with a large number of request values, until recent versions PHP may run into trouble.

He goes on to explain why there's an issue with the array overloading and what PHP has done in recent releases to help correct the issue - the max_input_vars setting in the php.ini. He also points out that this is not a new issue - it was originally identified back in 2003 (with a video of the original presentation). He points out that the most recent releases of the PHP language have this fix in them and, if at all possible, you should upgrade to protect your applications.