Re: Question about Debian build infrastructure
On Mon, 2019-06-10 at 16:56 +0000, Jeremy Stanley wrote:
> 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.
We generate new keys once a year, publishing them in a keyring package
6 months before they start being used. We are currently signing with
the 2019 key, and will generate the 2020 key in a few weeks.
> 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).
We are doing this already :)
> 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.
We are publishing a keyring package which takes care of this.
> 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.
We are doing this already :)
> 6. To allow for easier manual verification of key transitions,
> always sign new keys with their predecessors when creating them.
We haven't signed the new key at the GPG key-signing level, but we've
effectively signed it at the APT level by publishing it in the
repository 6 months before it gets used.
> 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.
The only place where the APT key gets used is to publish the APT
repository itself. Internally, the build process signs with a
disposable, unpublished GPG key that can easily be revoked if it's
compromised. (The Aptly server is also only visible inside our network,
so outsiders can't upload to it anyway.)
> 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).
I've published the key and installation instructions on our APT landing
page.
> 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.
It sounds like I'm doing most of this already. Thank you for all the
advice!
Kyle
Reply to: