Publish PGP Signature for composer.phar

[soatok]

Please sign composer.phar with a PGP key, publish the key ID and signature, and update the documentation to encourage verifying the .phar before blindly piping to the PHP interpreter.

https://getcomposer.org/composer.phar
https://getcomposer.org/composer.phar.asc <- signature should go here

See also: https://defuse.ca/triangle-of-secure-code-delivery.htm by @defuse

[sarciszewski]

👍 if you need help setting this up, shoot me an email -- I'd like to see this get done!

[fabpot]

@Seldaek If you need any help here, I'm here ;)

[fabpot]

Note that signing releases is easier than tagging nightly builds as signing means manually creating the archive and manually entering a password at some point (at least, that's how it should be done.)

[sarciszewski]

So, is there going to be any momentum at all on this initiative?

[soatok]

tumbleweeds

[sarciszewski]

So, is it the official stance of the Composer team that they don't care about package integrity?

[Seldaek]

No the official stance is I am busy with tons of things and haven't had time to look into this yet but yes I agree it would be great. If one of you would like to work on a pull request for the docs that would already be a great start.

Another thing that'd help is patching https://github.com/composer/getcomposer.org/blob/master/update.sh#L26 so it generates a signature too from a local key file. If all I have left to do is generating private keys (I guess there should be a passwordless one on the server for the dev snapshots and a passworded one I can use to manually sign the releases) that'd greatly increase the chances this actually gets done soon.

[sarciszewski]

https://fedoraproject.org/wiki/Creating_GPG_Keys#Creating_GPG_Keys_Using_the_Command_Line

[Seldaek]

@sarciszewski yup I saw the PRs, thanks a bunch. I'll try to follow up on this sooner rather than later.

[sarciszewski]

Cool. Is there anything left you need done other than the actual key generation and signing steps?

(I can't really do that for you, otherwise I could easily be in a position to trojan the installer if I decided to become evil in the future, so it's best if it's your key, not mine.)

[Seldaek]

@sarciszewski sorry I took a look at it and then thought it would actually be best to sign using openssl because then we can verify in php using openssl functions which we anyway largely depend on. That'd make it easier to have a workable cross-platform solution. See composer/composer#2665 (comment) for details.

Anyway then I got stuck with conference and holiday and work and life so I couldn't get that done yet. What do you think?

[sarciszewski]

It appears the problem is you're thinking a level deeper than my complaint addresses.

I'm not advising you to write the code inside of https://getcomposer.org/installer to use PGP or openssl_verify(), I'm suggesting make sure a signature is verified before https://getcomposer.org/installer is ever executed.

The problem is not what the installer contains, the problem is how the installer is invoked.

These are not safe for the person running them:

curl https://anything | php
curl http://anything | sh

If you trust OpenSSL that much (http://www.libressl.org/ might be a better solution fwiw) and know an openssl wizard who can teach all of your users how to verify the installer before executing it, great. But I'm not that person.

Maybe @defuse can help me out here if I'm not explaining this correctly?

[stof]

@sarciszewski signing the installer itself will not guarantee the phar integrity. This means that the installer should also verify the signature of the phar when downloading it (and the phar should verify it as well when doing self updates).

So the user should indeed verify the integrity of the installer before executing it, but the installer itself needs to have logic verifying signatures for next steps

[sarciszewski]

So the user should indeed verify the integrity of the installer before executing it, but the installer itself needs to have logic verifying signatures for next steps

I agree. Both steps need to be signed, and every composer package should also be signed too. But getting the install instructions to be secure by default is a good start on this initiative.

[stof]

@sarciszewski but the signature for the phar itself, which is what you implemented in your PR is something which needs to be verified by the Composer code (both in the phar and the installer) (except for people downloading the phar directly instead of the installer).

[sarciszewski]

Let's break this up into three pieces:

1. Securing the installer.
2. Securing what the installer does.
3. Securing what the installer installs.

Until step 1 is complete, the other two don't really buy people anything except inconvenience.

[stof]

@sarciszewski but you started with a PR preparing the work for 2, not for 1

[sarciszewski]

@stof This issue, which is on the getcomposer.org repository and pertains to the install instructions, is about 1.

[stof]

nope. this issue is asking to sign the phar. And the phar is not the installer. It is what the installer downloads after checking your system. So it is about the step 2 (or about people skipping the step 1)

[sarciszewski]

Move this to #76 and #77