Why I do not like Composer

I really really like PHP.

Drawing of the head of an orchestra composer with arms above his head while leading an orchestra
php composer logo

For several years now, more and more PHP applications are moving to composer for installation and it really bothers me. It is fucking dangerous, and I would like to explain why.

It Encourages Laziness

When installing a web application, a system administrator needs to now the implications of what that web application does.

With Linux vendor repositories, like Fedora or RHEL/CentOS or EPEL – the system administrator at least knows the code has been reviewed by the vendor to make sure it does not do anything it is not suppose to do, but that is not the case with Composer.

The Roundcube webmail client for example, when packages by Fedora, the application in the past was patched to fix some dangerous JavaScript. When installing it as distributed by the vendor, you do not have that benefit.

When installing web applications that System administrators use to need to at least read the README file which gave some indication of things the web application did before you installed it. But now you just run the composer utility, and it installs the application and whatever it depends upon and whatever its dependencies depend upon etc. without the system administrator needing to review shit. That is dangerous.

Poor Package Security

With a proper package manager, only packages signed by repositories you trust are installed. The system administrator has to import the public encryption key from the repositories they trust, and when retrieving packages, the package manager checks the signature on the package. If the package was not signed by a key the administrator trusts, the package does not install.

This is not the case with composer. There is no local database of public keys for vendors the administrator trusts that packages are then checked against.

Someone could hack the server where I host my AWEL packages and put trojan packages there. But those packages would not be signed by me unless the attacker also managed to get my private signing key and knew what my pass phrase to that key was. That protects my users, because they would be alerted that the software packages the attacker put there were not signed or were not signed by the signing key associated with my package repository, and the trojan packages would be rejected.

Composer has no such facilities.

This is code that not only is running on your server, but is serving content to your users. I do not understand why so many system administrators are okay with this. It is reckless.

It encourages Developer Laziness

When dependencies are globally installed on a system (e.g. in the PEAR infrastructure see https://pear.php.net/) the developer of the web application has to keep their code up to date, or it will not work on systems that have newer versions of the dependency installed.

That is not the case with composer. Composer pulls the dependency inside the application directory so that the application developer never has to update their application to reflect updates in the dependency.

That sounds very attractive to application developers but it is a fucking security nightmare.

Most dependencies are developed by small teams often in their spare time, sometimes only a single individual. They often do not backport security fixes to older versions or pay attention to security issues in older versions.

Thus if a composer file specifies it needs endroid/qrcode >= 1.6.5 and < 2 – but the developer is working on version 3.5 and has not updated the older versions, the older versions may have exploitable security issues that are never fixed that composer happily installs into the web application.

It is a vector for malware

If GroovyApplication depends upon LibSanity which depends upon ClasslessMatrix which depends upon JunkBoxer which depends upon FenderBender – all those projects are installed when the system administrator uses Composer to install GroovyApplication.

All an attacker has to do is gain access to one of those dependencies, and they can add their malware to what Composer installs.

The developer of GroovyApplication has no fucking clue how well the developers of all those dependencies secure their projects, nor can the developer of GroovyApplication prevent the maintainers of one of those projects from turning development over to someone else who has malicious intent.

The Bottom Line

Bottom line is Composer is a flaws way of doing things, and it really pains me that it is becoming the standard way to do things.

We have seen what happens when shared libraries that are globally installed are not used for decades. The library gets updated to fix security issues but because applications linked against static versions of the libraries, those applications remain vulnerable.

This is why so many Android and iOS apps are exploitable – they do not use shared libraries. This is why so many Linux distributions in their package repositories frown upon or completely forbid packages that static link instead of dynamically linking to dependency libraries.

But that is exactly what Composer does, it is just like static linking because the composer JSON file allows specifying specific versions that often are never patched by their maintainer because the maintainer is working on newer versions.

Bottom line – do not use Composer, it is fucking dangerous.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s