In his latest post Larry Garfield talks about the Composer problem that was recently brought up by the Gentoo linux project and is related to how Composer packages and system-level shared libraries differ.

This is not a new complaint; Other distributions have complained about Composer's impact before. But fundamentally I think the issue stems from having the wrong mental model of how modern PHP works when viewed from a distribution or sysadmin perspective.

In a recent heated GitHub thread, several people referred to PHP "linking" to 3rd party libraries, as if they were shared C libraries. That is simply not the case. Neither "static linking" nor "dynamic linking" really applies to PHP. From a sysadmin perspective, PHP is closer to highly complicated bash scripts than anything else.

Larry starts with a bit of history on the subject, pointing out the two methods most developers used PHP code: copy/pasted from the web or installed via PEAR. He talks about the common issues with both approaches. He then talks about how modern PHP development and Composer related and how, from a sysadmin perspective, Composer is the "compile" step of PHP and only supports static links. He also makes some suggestions to the distribution packagers around how to handle these system-level Composer dependencies (and how to treat it like a "binary" if needed).

The mistake here is trying to treat dependent packages of modern PHP applications like shared libraries. They're not. The community has spoken, and PHP simply doesn't work that way anymore. Fighting that is a losing battle. But by viewing composer as a compiler, distributions can still slot PHP into their typical workflows and get all of the security update ease that they're looking for.

Ben Ramsey has shared an interesting issue he's come across when installing packages via Composer where it installed a different version than expected when he ran an install. The problem turned out to be from an unexpected place.

For applications I control that are not distributed to the public, I like to hard-lock my Composer dependencies to a specific version. [...] Sometimes a library has updates that haven’t yet been released, and I need to use these right away. Composer allows me to specify the specific commit I want to use for a library. In this way, I can hard-lock a dependency to a specific state, even when there is not yet a release for the changes I need. This has worked well until today, when I tried to do a fresh composer install. After installing, one library contained files and methods that I did not expect. It turns out Composer was grabbing the HEAD of dev-master instead of the specific commit I referenced.

After some investigation into his "composer.lock" file's contents, he found the issue: a problem with the way that BitBucket handles the distribution zip files Composer requests. In his example, the zip file was of the HEAD on the repository, not of the specific commit (GitHub doesn't have this problem). His solution was using the (slower) "--prefer-source" option to grab the correct commit contents...not an ideal solution but it does what he needs.

Pádraic Brady has a new article on his site talking about the secure distribution of phars (PHP archive files) including some of the common pitfalls and potential solutions.

The PHAR ecosystem has become a separate distribution mechanism for PHP code, distinct from what we usually consider PHP packages via PEAR and Composer. However, they still suffer from all of the same problems, namely the persisting whiff of security weaknesses in how their distribution is designed. [...] [Several security-related issues introduce an element of risk that the code you receive is not actually the code the author intended to distribute, i.e. it may decide to go do some crazy things that spell bad news when executed.

He shares some of the steps he's taken to secure his own phar for a CLI application with things like:

• Distribute the PHAR over HTTPS
• Enforce TLS verification
• Sign your PHAR with a private key
• Avoid PHAR Installer scripts
• Manage Self-Updates securely

He finishes the post with one of the most important parts of the article - a reminder to do all of the things on the list above consistently.

This is not an outrageous outcome to introducing proper security on PHAR downloads. Go forth and do it for all PHARs. Help create an environment where distributing and installing code in secure ways is the normal expected thing to do.

Despite the misleading title, this post on Reddit talks some about a switch that some Linux distributions are making when it comes to JSON support in PHP. They're moving away from the built-in support in favor of including this one.

In a quote from Nikita Popov (a comment on the post) he notes that:

It is true that some Linux distribution switched from json to json-c, but this should be transparent to the user. The standard PHP distribution still ships the JSON extension as it always did. [...] You should all take this chance to switch to PHP 5.5, so you can see that everything works fine and that PHP 5.5 is awesome

He also includes comments from the Remi (Fedora) project about the switch, noting that the end user shouldn't notice any kind of issues. The reasoning behind the switch has to do with licensing and usage issues of the previously built-in extension. You can find out more about that issue in this bug report.

In this new post to her blog Lorna Mitchell takes a look at some of the current statistics around PHP version adoption - all the way from the ancient 5.0 through the shiny new (upcoming) 5.5 releases.

PHP runs over 75% of all websites whose technologies are known (source: w3techs), which makes for a really REALLY long tail of users who once installed wordpress, phpmyadmin, or some other open source project that helped their business needs at the time. What they don't do is upgrade. PHP's current usage statistics look like this (source and raw numbers are if you want them):

She points out that around half of the results show that sites are running on unsupported versions of PHP (<=5.2) but notes that it's not always their choice. There's lots of factors that play into upgrading these versions that are not always in the user's control (like the speed of distro updates). She covers some of the things that came around in the newer versions of PHP 5.2 and 5.3 including some large performance jumps, especially in 5.4.

In truth, the future is already here for those people on PHP 5.4 and beyond. Keeping PHP upgraded is just part of our regular maintenance workflow, and the language is progressing in regular and manageable steps. If you've been left behind then I strongly recommend that you start making plans for upgrading your platform, or moving to a newer one.

Ilia Alshanetsky has posted the next set of results from his domains-running-PHP research he's been doing. In this latest post he looks at the domain distribution by city mostly falling in the US, Europe and China.

I am making available two additional geographic chats that breakdown the domain distribution by top world cities. The first chart a preview of which can been below (click to see full, browse-able/zoomable version) shows the Top 150 cities, by domain distribution. These cities represent a total 91.3% of some 102 million domains that could be resolved to a city level.

The top ranking city falls in the US in Scottsdale, Arizona (because of the large domain provider GoDaddy being based there) with the second place spot going to San Francisco, California. He's created both a interactive map you can use to see the numbers for different parts of the world and a concentration view of the same results making it a bit easier to digest.

Stuart Herbert is looking for some more input on a different sort of question (one that I can't say I've seen asked before) - what are some of the issues with default Linux distribution PHP installs.

Most Linux distributions ship with packages for PHP, but not everyone is happy with these packages. If you’re not happy with the PHP packages for a specific Linux distro (no matter how obscure), I’d love to hear what you think the problems are and (if possible) what the correct solution should be.

Just leave a comment on the post with the things you might have noticed. Comments already made reference issues in Debian/Ubuntu, RedHat and a few other more general "state of PHP packages" comments too.

Derick Rethans has a few choice words for those developing PHP packages for linux distributions out there - don't cripple PHP. His example deals specifically with RedHat and their choices on timezone management.

Red Hat thought it'd be wise to create a patch to use the system provided timezone database instead. We (the PHP development team) thought that to be a bad idea because of several reasons. Among them is that it removes control from PHP's users about which database is, decreased performance, and some missing functionality

He mentions other problems - other issues related to timezone support - that caused them to not accept RedHat's patch to try to "fix" things by disabling the bundled timezone database. He looks at why this is such a bad thing, why it can cause trouble with PHP's date handling and what the future holds for this database support (hint: PHP 5.3 will shake things up).

Andi Gutmans has some great news for Ubuntu users - the Zend Framework will be included in a future version of the linux distribution (Hardy Heron, Ubntu 8).

We are very proud to be an integral part of the Ubuntu distribution going forward. This is an important step towards making Zend Framework accessible to a broader audience and by working closely with the MOTUs we are able to ensure a positive end-user experience.

Andi also points out some of the stats from the framework's life so far: 4M downloads of Zend Framework, 500K of them unique and only growing stronger.

In this new advisory posted on the Secunia.com site today, there's an announcement of a highly critical update for Ubuntu users for their PHP distributions.

Ubuntu has issued an update for php. This fixes some vulnerabilities, where some have unknown impacts and others can be exploited by malicious users to bypass certain security restrictions and potentially by malicious people to compromise a vulnerable system.

Check out the posting to grab the links for the packages for the various distributions (and for the different version numbers of Ubuntu). As this issue is marked as "highly critical" it's recommended that you update your installation as soon as possible.