getcomposer.org
getcomposer.org copied to clipboard
composer
After PHP 7.1 support is dropped, use Ed25519
The example strings were created with this keypair
- Secret key:
7994a18843df8a750f2bbe2ad2c4b04b2c0eda6b7f766648d5316c0e272a5c6c8e2e93807649253619106b49110d9b051847f1f82c476aef704393b207c2a5ae - Public key:
8e2e93807649253619106b49110d9b051847f1f82c476aef704393b207c2a5ae
Ehm, why? We're just verifying the contents of a simple install script here. Not dealing with government secrets.
You may have missed the memo about recent supply-chain attacks. Or the not-so-recent memos.
PHP powers a lot of the Internet. An enormous (and increasing) number of PHP projects use Composer. Even WordPress, the biggest holdout for Composer adoption, is likely to adopt it in the next year or so.
Not dealing with government secrets.
Put bluntly: If you worked for a nation state at the same level as NSA's TAO and wanted to compromise the target systems of a rival nation, and you weren't targeting Composer as an easy way into software written in PHP, you're really bad at your job.
So let's be better at ours.
:man_shrugging:
It will be quite a long time until we actually drop support for PHP 5.x
I'm aware.
For some background: I do open source stuff (among other things) while streaming on Twitch. Someone asked about a Node.js project I'm building (misread npm as rpm and thought it was RedHat-specific) and we got talking about package managers. I mentioned that Composer was saner than others, and someone in chat interjected about the long install instructions.
So I started talking about how, if you hacked the server, you could replace the hash and the installer since they're in the same place but there's already a mechanism in place to verify the hashes (which change infrequently) using GPG. And then I started drafting an example of what a Ed25519-SHA384 installer would look like. And since I had taken the trouble to write that, I figured I'd submit it for the Composer team's eventual consideration.
I won't be offended at all if this collects dust for years before being merged.
(You can see the discussion surrounding this towards the end of the broadcast if you're curious.)
I think that if you managed to hack the server, we'd have bigger issues. It opens up a range of attack vectors, least of all the install script.
Also I think the install script actually is not used that much anymore. We also offer official Composer docker containers, the Phar as a release asset on Github, etc. I think it might be more interesting to sign the Phar artifacts themselves? Most distribution channels would benefit from that.
If I understand correctly, Phars can only be "signed" (tortured misuse of cryptography terms) using hash functions or via OpenSSL (which doesn't support Ed25519), and furthermore, you can strip an OpenSSL signature to replace it with SHA1 and PHP will not complain.
Fixing that will require reworking some of the Phar extension in PHP 8.
@soatok I fail to see how switching the signing algo would prevent anything in the case where the server serving that page is hijacked? Can't the attacker show a different piece of install code there then? Or at least change the signature and key to be theirs? Most people copy paste this stuff blindly anyway.. And for those who don't, we already offer a way to check from a different source, granted only with sha-384 atm but AFAIK that is still considered safe against collision attacks?
wget https://raw.githubusercontent.com/composer/getcomposer.org/76a7060ccb93902cd7576b67264ad91c8a2700e2/web/installer -O - -q | php -- --quiet
