Add Rector to Phive

[Aerendir]

Phive is like Composer but for phar packages.

It permits to install, update and manage phar files of supported packages.

Using Phive it is possible to avoid dependencies' hell and make the use of the tools easier also in CI environments.

The main site of Phive is https://phar.io

To make Phive support Rector, those are the steps (https://phar.io/distribute-your-own.html)

• Attach the .phar to each release
• Update the repositories.xml file on Phive.io (Add Rector. phar-io/phar.io#75)
• Create a personal or company GPG key (https://phar.io/howto/generate-gpg-key.html)
• Upload the key to the SKS keyservers (https://phar.io/howto/uploading-public-keys.html)
• Attach the signature to the release

Currently all the part related to the signature is missing and I think that only you, @TomasVotruba , can do it 😅

On my own I've already submitted a PR to Phar.io to add Rector to the list of supported packages.

Waiting for you ❤️

[TomasVotruba]

I did all those steps... can I share public key here? :)

If not, it's under {{ secrets.OPEN_PGP_KEY }} in GitHub Action

[theseer]

The idea of a public key is that it is supposed to be public. Hence it's name ;-)

[TomasVotruba]

I wish naming was that easy :D
Could you share all your public ssh keys? ;)

[theseer]

I could.

Question is why anyone would want to do that because the only use case would be to allow someone who has the private key for it, allow to login to your system.. :)

[theseer]

What you want to keep private is - you guessed it ;) - the private key.

[TomasVotruba]

Actually, you could do some nasty things with open-source deploy and public keys only :). Just know how and where (I won't tell you more for security reasons)

[TomasVotruba]

Ping @Aerendir I've added what I could, what now?

[Aerendir]

@TomasVotruba , I’ll study how to attach the key to the phar in the week end: yesterday I had some spare time and opened the issues and moved the work forward... but next days are a real Hell!😅

[theseer]

Not sure if this is helpful, but maybe it is...

Short docs on how to generate the signature file: https://phar.io/howto/sign-and-upload-to-github.html

If you already have a method in place to attach the .phar file, it should be the same for the .phar.asc file.

The only "question" you have to answer for yourself is whether or not to trust github enough to automate singing and thus have the private key used uploaded as well as the passphrase to unlock it stored in their systems.

[Aerendir]

@theseer

Short docs on how to generate the signature file: https://phar.io/howto/sign-and-upload-to-github.html

This article explains how to do the work manually, but I think it should be automated, also because...

If you already have a method in place to attach the .phar file, it should be the same for the .phar.asc file.

... (yes) there already is a workflow in place that creates the PHAR file (see https://github.com/rectorphp/rector-prefixed/blob/master/.github/workflows/continuous-deployment.yaml)

The only "question" you have to answer for yourself is whether or not to trust github enough to automate singing and thus have the private key used uploaded as well as the passphrase to unlock it stored in their systems.

This is, in my opinion, not a question.

Nothing prevents from having more than one key pair. So, the only thing to do is to create a pair to use only for Rector.

This means that is absolutely secure to upload the private key on GitHub as it is used only for Rector.

@TomasVotruba, as told, in those days I don't have the time to setup this. But, reading again the comments, you only mentioned the public key.

The process should be this (again, I reserve my self to go deeper in the understanding):

1. Register the public key in the GPG registry
2. Store the private key in GitHub
3. On new releases of the PHAR, make GitHub Workflow use the private key to generate a signature of the created PHAR file (the file release-name.phar.asc file mentioned in https://phar.io/howto/sign-and-upload-to-github.html)
4. Attach the generated release-name.phar.asc file along with the release.

At this point, when Phive will download the Phar, it will:

1. Download the PHAR file;
2. Download the public key from the GPG registry
3. Download the release-name.phar.asc
4. Using the public key from the GPG registry and the release-name.phar.asc, verify the integrity of the downloaded PHAR file.

So, in the end, you should also upload the private key in github, as a secret, instead of the public one.

You should also upload the public one on a GPG registry: https://phar.io/howto/uploading-public-keys.html

I think, again, this is something that should be done by yoourself as it is a procedure sctrictly tied to the owner of the key (and of the repository).

Once the public key is uploaded and the private key stored as secret in GitHub, then the Workflow will be configurable to create the release-name.phar.asc file.

[TomasVotruba]

So, in the end, you should also upload the private key in github, as a secret, instead of the public one.

You should also upload the public one on a GPG registry: phar.io/howto/uploading-public-keys.html

tl;dr; So you need me to do these 2 steps?

[Aerendir]

Yes! 😬

[theseer]

Someone, preferably a person "speaking" for the rector project, needs to generate a gpg key pair dedicated for signing releases.

The public key needs to be uploaded to a gpg keyserver (as @Aerendir described by linking to phar.io's documentation), and the private key needs to be available to the github action that'll generate the signature. How that private key is uploaded/made available is up to you, a secret store seems to make sense. It should not be public for obvious reasons and not use a passphrase as providing a passphrase via cli scripting is not that simple (read: it can be done but is annoying ;) ). If you are paranoid, you can add a passphrase and then use expect scripting to provide a it, potentially by reading it from ENV...

[TomasVotruba]

@Aerendir Public keys pushed and private added to Github secrets 👍
What now?

[theseer]

Now somebody needs to create a release which includes the phar and the gpg signature for it made using the private key.

I didn't check if @Aerendir already added the steps to a github action, but if not, the easiest way to automate it is to have the build system create the phar upon release, sign it and attach both the phar and the signature to the release in github's release tab. Once it's available, we can add the alias to the phar.io database.

[TomasVotruba]

@theseer PR?

[TomasVotruba]

Closing as stale

[kennaar]

Are there any plans to add built phar's to the releases? rector is one of the few tools I can't install using phive, which is a shame.