Support installation of composer

[sebastianheuer]

No description provided.

[Ayesh]

FYI, Composer phars are signed using the keys: https://composer.github.io/pubkeys.html

[theseer]

Thanks for the reminder!

I've already looked at that page some time ago and still have no idea why one would consider embedding key information into an HTML document a good idea. Particularly when simply linking to a raw keyfile would make life so much easier for everybody? Why do we now have to parse an HTML and extract that information? And it's not like that approach would be re-usable for other projects. It's a proprietary and cumbersome solution.

I also fail to understand why the composer developers choose to use OpenSSL for signing rather than PGP - which is an established standard for package signing in the OS world with an equally established infrastructure around it to automate look-ups and key distribution.

With OpenSSL there is no independent infrastructure to publish and search for public keys. The PGP-Keyserver-System may not be perfect, but it beats parsing HTML to get the key for one project and implementing a different solution for the next.

To have support for installing composer with phive, we'd have to implement some additional custom things that are likely only relevant for composer. So, while I'd very much like to be able to install composer using phive, there are quite some things where the composer project decided to not follow established patterns. And I'm not yet convinced that phive is the correct place to "fix" that.

The main purpose of this issue is to track these potential custom requirements.

[amenk]

See also: composer/composer#5155

[Seldaek]

I now published the keys as single addressable files, see https://composer.github.io/pubkeys.html for links. The reason it wasn't done is simply that nobody asked or needed it as the keys are bundled with the composer installer.

As for choosing openssl and not PGP, it's because that allows us to work exclusively with PHP in a fully cross platform way as we require the openssl extension to be installed anyway. PGP/GPG availability can hardly be relied upon, and I am not a fan of leaving users behind because of their OS choices.

If you can see some value in supporting openssl signatures, I think that'd be great as it would make phive work in more places, but if not I guess I'll have to look into publishing PGP signatures as well.

[amenk]

So on phive side we now would need a way to "trust" these OpenSSL signatures... maybe the URLs can just be referenced in the https://github.com/phar-io/phar.io/blob/master/data/repositories.xml and/or the phive.xml ?

[Seldaek]

As of https://github.com/composer/composer/releases/tag/2.0.3 composer releases on github will have a signature attached. I just tried to install it via phive and it works now without --force-accept-unsigned 👍

Would be good if you can update the phar.io homepage to remove --force-accept-unsigned from the composer example. I also submitted phar-io/phar.io#88 to add an alias.

[theseer]

PR is merged and live. I also updated the website to reflect the change.

[theseer]

Given with Composer 2.0 we have gpg signatures, I guess we can almost close this ticket.

I'd like to comment again on one point though before I do:

So on phive side we now would need a way to "trust" these OpenSSL signatures... maybe the URLs can just be referenced in the https://github.com/phar-io/phar.io/blob/master/data/repositories.xml and/or the phive.xml ?

There are generally two things we need: Information about the key used to create a signature and the signature itself.

Signatures

Given that signatures are for all practical purposes release specific, they have to be found by an automated means. This can be done by convention, e.g. appending .asc to the URI of the actual phar-URI or filename, or by configuration. The configuration cannot be static as the location of the signature will change based upon the release, and may change over time if the provider or means of signing changes. So configuration is problematic if you want to be able to install older and newer releases.

We thus chose to use convention.

Key information

With GPG, the used key-ID is part of the signature. That enables us to use a public infrastructure to request the public key and have the user decide whether or not that key should be trusted (technically: imported into the keyring).

With openssl, the signature - as the best of my knowledge - does not contain that information. We thus would need a means to have that information somewhere. Again: We can use a convention to retrieve that from some URL derived from the original phar URI. While that would technically work, we wouldn't know anything about the key as openssl doesn't add any identifying information. So you basically are down deciding whether or not to be trusting a base64-blob of some data.

So, convention is problematic here: While we could verify the signature has been made using that key, we have no idea whom the key belongs to.

That would leave us with configuration:

We could provide the URL to the public key in our repository.xml. While that makes it marginally more trustworthy, I still have no idea whom the key belongs to and whether the data received from that URL is actually the same key that was intended to be there by the original authors, in case their service endpoint got hacked.

So maybe we should add the key content to our repository.xml? Better. But how do we handle updates? Or invalidate a lost key? We'd be reimplementing public key infrastructure. There is a reason why openssl and the likes use certificates and are build around a CA...

[theseer]

Closing this issue as composer now comes with gpg signatures and even has an alias so is now fully supported.