Pádraic Brady has a new "let’s watch Paddy think aloud in a completely unstructured manner blog post" about the future of security when it comes to the popular PHP package manager Composer. It's recently come under criticism around its lack of package signing and TLS/SSL support.

The Composer issue, as initially reported by Kevin McArthur, was fairly simple. Since no download connection by Composer was properly secured using SSL/TLS then an attacker could, with the assistance of a Man-In-The-Middle (MITM) attack, substitute the package you wanted to download with a modified version that communicated with the attacker’s server. They could, for example, plant a line of code which sends the contents of $_POST to the attacker’s server.

He's been working on some updates to the project, one of with is TLS/SSL support as defined in this pull request currently pending. It enables peer verification by default, follows PHP 5.6 TLS recommendations and uses local system certificates in the connection. He talks some about other additional TLS/SSL measures that could be added in the future and how, despite it being safer than nothing, TLS/SSL is not the "cure all" for the problem.

He then moves on to package signing and suggests one method for implementation - signing the "composer.phar" executable and signing "everything else" (packages to be downloaded) to verify their validity.

The flaw in Composer’s installer isn’t that it’s unsigned, it’s that it doesn’t afford the opportunity for the downloader to read it before it gets piped to PHP. It’s a documentation issue. You can go down the route of using a CA, of course, but that’s further down the rabbit hole than may be necessary. Signing the composer.phar file is another matter.