Document best practices on handling keys for signing gitian builds

[Ruteri]

It's surprisingly hard to find good sources for how to generate and store private keys.

We want as many people as possible to sign unit-e's gitian builds, and we want this group to be diverse.

To achieve it, and to be confident that the keys are not going to be exposed or lost, we should include best practices on handling the keys. Debian's subkey wiki is probably a good to place to start.

We can also add howtos on more advanced setups, like storing pgp keys in a yubikey or a ledger.

[cornelius]

GitHub has a little bit of documentation including generating keys: https://help.github.com/en/articles/signing-commits. This is not very extensive but quite some people probably use this documentation because of the popularity of GitHub.

Another popular guide with best practices is https://riseup.net/en/security/message-security/openpgp/best-practices. This goes much deeper than the GitHub documentation. It is also more general and doesn't cover code signing.

https://keybase.io is a nice way to associate online identities to keys. This might serve as an alternative or an addition to the traditional GPG web of trust.

[castarco]

GitHub has a little bit of documentation including generating keys: https://help.github.com/en/articles/signing-commits. This is not very extensive but quite some people probably use this documentation because of the popularity of GitHub.

I'm very much in favour of signing our commits (I already started doing it :smile: ).

[cornelius]

I'm very much in favour of signing our commits (I already started doing it 😄 ).

The problem is that it doesn't work well with the workflow of squashing commits on merging pull requests. So you are squashing signed commits, which is a bit better than merging unsigned commits, but the resulting commits on master are then still all just signed by GitHub.