DOC/REL: add SSH signing for release tags

[rgommers]

We've used PGP signing for releases to date. Unfortunately that has poor usability, and it doesn't add much real-world protection especially if keys aren't exercised regularly, don't have a broad web of trust, and cannot be revoked.

The poor usability now bit us concretely - I don't have access to the machine I normally do releases from, so the key in the docs isn't available. This isn't fixable on a reasonable time-scale. So, do the obvious thing (short of stopping signing completely) and switch to SSH-signed tags. Those are much easier to use, and in case of new machines, lost keys, etc. a maintainer can easily create a new key and use the features GitHub offers to make it a signing key. The .github/allowed_signers file should then be updated for it.

Amend the 0.21.0 Changelog entry for this change. Also fix the release date in the Changelog.

See https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification for relevant docs.

@dnicolodi I realized this too late, sorry about that. We should merge this before pushing the release tag. If you want to add your own signing key as well, feel free to push to this PR (or add it later).

[eli-schwartz]

The poor usability now bit us concretely - I don't have access to the machine I normally do releases from, so the key in the docs isn't available. This isn't fixable on a reasonable time-scale. So, do the obvious thing (short of stopping signing completely) and switch to SSH-signed tags. Those are much easier to use, and in case of new machines, lost keys, etc. a maintainer can easily create a new key and use the features GitHub offers to make it a signing key. The .github/allowed_signers file should then be updated for it.

This argument doesn't really make sense. Both a PGP key and an SSH key are "cryptographic private key material shoved into a text file", both come with trivially usable subcommands to easily generate a new key, both can be trivially uploaded to GitHub and redownloaded as trusted account-linked key material.

Ssh signing has bad usability and equally bad tooling among people who verify signatures. And delegating trust to a file checked into git is inherently illogical -- any attack that could forge a commit and switch to new ssh signatures would also update the signing file.

"Don't trust an unidentified file with a security signature to also contain a field / unpacked file telling you what public key to trust" is only not the number one rule of cryptographic security because people assumed it went without saying, like "1+1 == 2" and "water is wet".

[eli-schwartz]

We've used PGP signing for releases to date. Unfortunately that has poor usability, and it doesn't add much real-world protection especially if keys aren't exercised regularly, don't have a broad web of trust, and cannot be revoked.

• web of trust is a cute theory but doesn't accurately model how people actually use it, which is actually to rely on the builtin "TOFU" model provided by PGP. Anyways, software signing has always relied quite heavily on TOFU by way of embedding a list of valid signing keys anywhere you check it. That trust list is generally scraped from "other sources the legitimate maintainer controls", and e.g. GitHub's associated PGP keys for a user account can be trusted to be reliable even if a PAT or a CI workflow compromise allowed an attacker to commit to a repository and create malicious tags, because adding ssh / pgp keys in the settings page is a much more trusted action than pushing.
• PGP keys can absolutely be revoked... unlike ssh keys, which can only be deleted / delisted leaving no real clue as to why and people tracking that ssh key in their own automation will usually not even know it was deleted (without significantly more effortful work). And you cannot allow an ssh key to be permitted to sign old releases and not new releases.

[rgommers]

PGP keys can absolutely be revoked

Yes I know - but you need access to the original key, so if that's on a temporarily shelved machine that I don't have access to, it cannot be done in practice.

I'm not interested in a PGP vs. SSH debate. I'm using PGP twice a year, for meson-python releases, and it's a pain, with little upside. SSH keys on the other hand I'm using constantly. It's just much nicer. And in case something went wrong with it, I'd actually notice, unlike PGP. So, switching to that.

[dnicolodi]

I am with @eli-schwartz on this. I don't think that switching to SSH keys for signing has any practical advantage offers much weaker protection that what is potentially allowed with a PGP key.

Those are much easier to use, and in case of new machines, lost keys, etc. a maintainer can easily create a new key and use the features GitHub offers to make it a signing key. The .github/allowed_signers file should then be updated for it.

I don't see how this is any different from generating a new PGP key and adding it to the documentation next to the old one with a note saying that the old one has been used till the last version and the new one will be used from the next version onward. AFAIK, doing this would have the exact same guarantees that adding the hash of an SSH key to a text file in the repository.

If the issue is that a new PGP key would not be signed by anyone, I am happy to sign your new PGP key if we find a minute any day to get into a video chat. I am sure @eli-schwartz could do the same.