Add release signing workflow.

[ni4]

This workflow works in two ways:

• once version tag is pushed to the repository (named like v1.2.3), it triggers, checks out code which corresponds to the tag, and calls signing via https://github.com/rnpgp/release-sign script. Then new release draft is created, and signatures are attached to this draft.
• also it may be run manually, for an already existing tag.

For signing it uses secret and public keys, stored in corresponding GitHub secrets. Unfortunately it is needed to save secret key to a file (see Sign and Cleanup steps). If there are better ideas how to handle that - all suggestions are welcome!

As a result it creates release draft, which will not overwrite already existing one(s), and then person, responsible for release, needs to update changelog and press 'Publish release' button. This may be automated further, but IMHO it is more safe to do publishing step manually.

UPDATE: Also open questions are:

• should we publish sha256 sums as well?
• where should we store release signing public key - in the repository, upload it to some key server?
• Should we include key fingerprint into the release message?

[ronaldtse]

• should we publish sha256 sums as well?

Yes, that'd be great.

• where should we store release signing public key - in the repository, upload it to some key server?

Probably both, and also on rnpgp.org?

• Should we include key fingerprint into the release message?

Is this necessary?

[ni4]

• should we publish sha256 sums as well?

Yes, that'd be great.

Ok, will update script.

• where should we store release signing public key - in the repository, upload it to some key server?

Probably both, and also on rnpgp.org?

• Should we include key fingerprint into the release message?

Is this necessary?

Not, if user clearly see where he may obtain the public key and how to validate signatures.

[ni4]

@ronaldtse as from https://github.com/rnpgp/rnp/pull/1555#issuecomment-879465425 : Is https://github.com/softprops/action-gh-release is preferable compared to the https://github.com/ncipollo/release-action ? I used the second, as it seems updated more recently, and does what it should (though it has less forks/likes).

[ronaldtse]

Is https://github.com/softprops/action-gh-release is preferable compared to the https://github.com/ncipollo/release-action ? I used the second, as it seems updated more recently, and does what it should (though it has less forks/likes).

@ni4 I'm not sure, I usually use https://github.com/softprops/action-gh-release because it was linked from the official (now deprecated) action: https://github.com/actions/upload-release-asset

[ni4]

Is https://github.com/softprops/action-gh-release is preferable compared to the https://github.com/ncipollo/release-action ? I used the second, as it seems updated more recently, and does what it should (though it has less forks/likes).

@ni4 I'm not sure, I usually use https://github.com/softprops/action-gh-release because it was linked from the official (now deprecated) action: https://github.com/actions/upload-release-asset

Got it. I used one linked from the another official (now deprecated) action: https://github.com/actions/create-release SoI guess we may stick to any of those given that they work and maintained.

[antonsviridenko]

Are you seriously going to store secret key for release signs on an external server not physically controlled by you??? That's totally unacceptable, this key can be considered already compromised. Signing key must be locally stored on a developer's machine and never uploaded to internet. Not everything should be automated, and signing releases is one of such procedures that should be done manually.

[ribose-jeffreylau]

In light of the concerns about secret key stored in servers not in our control, another workflow I see is, instead of automatic signing, the developer signs the package locally and uploads the signatures to a separate (public) repo, in a specific directory (e.g. named by the RNP version number), which is then downloaded by this workflow and uploaded to the release. Something like that. Maybe could be made even simpler.

[ni4]

I would not be concerned that much as primary secret key is offline, and in GitHub cellars we store only secret signing subkey, which expires in a year and can be easily revoked once/if compromised. Again, GitHub stores a lot of other secrets like access tokens and all security info, compromising which would allow to modify repository in a different ways. Also approach with stored GitHub secret would allow to make releases by developers without possession of secret key itself.

[antonsviridenko]

releases are done once in a several months, what's the point in compromising security for the sake of automation

[ni4]

Let's close this as non-relevant now, being superceded by https://github.com/rnpgp/release-sign