Repository navigation
Signing of releases should not depend on personal keys #4659
Description
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 releases@wp-cli.org 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.
Activity
schlessera commentedon Feb 1, 2018
We should also discuss how the public key is being distributed, as that goes hand in hand with the signing of the releases.
maltfield commentedon May 18, 2022
I just stumbled on this when trying to securely install wp-cli, so I'll provide my $0.02
Private keys should not be shared. This is fundamental.
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.