Signing of releases should not depend on personal keys

The way releases are currently signed depends on a single, personal key.

We need a mechanism that allows us to sign releases in a secure way without directly attaching it to an individual person.

Current thoughts: A. Have a key attached to a general email, like [email protected] that does not belong to one single person. The private key should be shared amongst maintainers, and the email should forward to the maintainers group. B. Have a signing bot that is in possession of the signing private key, with personal keys giving access to that bot.

Not sure what the best/most practical approach is here, so open for feedback.

We should also discuss how the public key is being distributed, as that goes hand in hand with the signing of the releases.

I just stumbled on this when trying to securely install wp-cli, so I'll provide my $0.02

A. Have a key attached to a general email, like [email protected] that does not belong to one single person. The private key should be shared amongst maintainers, and the email should forward to the maintainers group.

Private keys should not be shared. This is fundamental.

B. Have a signing bot that is in possession of the signing private key, with personal keys giving access to that bot

Release signing private keys should not be stored on hot storage. So if your pipeline includes an HSM, then this would work.

May I propose:

C. (the easy & secure solution) If you cannot have the private key in an HSM, then the organization should designate one developer to sign all releases, and every time that person changes then a signed Key Transition Statement is published.

D. (the hard & very secure solution) Store the release signing key in an HSM. Use fero to sign your releases only if M-of-N developers sign-off on the release with their individual private keys.