On 2019-06-10 11:18:35 -0400 (-0400), Kyle Edwards wrote: [...] > If you're using GPG on the published repository, how does your > repository server handle its signing GPG key? Does someone have to type > in a password every time it wants to publish a package, or is it > unattended, with either an unencrypted private key or a passhprase > file? Does the key live on the same server as the repository, or do you > have a dedicated signing server? Keeping unattended GPG keys secure is > tough...
A few tips borne out of past experience, in no particular order: 1. Maintain (at least) two valid master keys and keep them in different places, only signing with one and holding the other in reserve for emergencies; this way if you ever need to revoke a master key in an emergency, you're not left with a sudden bootstrapping problem. 2. Don't place all your trust key revocation, instead plan a rotation schedule so that even if a key falls into the wrong hands it's more likely users will smell something fishy when they see it used to sign new artifacts after expiration, even if they're not regularly checking for key revocations. 3. Use signing-only subkeys in your automation, not your master keys; this way the master keys can kept symmetrically encrypted somewhere you only access to create or revoke subkeys (maybe even on the other side of an air gap or locked up in an HSM). 4. Package the public keys and make sure your pregeneration/rotation schedule takes into account a slowest reasonable update frequency, so that your users are likely to have your next key in place and trusted before you transition to signing anything with it. 5. It probably goes without saying, but always generate a revocation certificate for every master key when you create that key, and keep it somewhere safe as a precaution in case you lose control of the master. 6. To allow for easier manual verification of key transitions, always sign new keys with their predecessors when creating them. 7. You *may* want to separate signing and artifact building onto different systems so you have tighter control over key distribution and can shield key material from processes involving the running of less-trusted/arbitrary code, though this still comes with its own "chain of custody" problem as you need some way for the signing system to trust not only the build system but now also the channel through which the artifacts are transferred. 8. Publishing fingerprints and validity dates for your keys alongside your release documentation/announcements is sometimes beneficial for bootstrapping initial trust (we also publish full copies of our public keys on their own page, in addition to pushing them into the public keyserver network). 9. As an added step, we have the infrastructure team members responsible for generating and maintaining the keys sign them with their own personal keys, which are fairly well-established in our community's web of trust (and a number of our community release managers transitively attest to those public keys as well for added coverage). There's probably more I'm forgetting, but that's at least a good start at mitigating unattended use of unencrypted keys while maintaining a robust and resilient signing infrastructure. -- Jeremy Stanley
signature.asc
Description: PGP signature
