audit log watch to gpg key signing subcommand

[philips]

Goal: Automate the signing of RPM and APT repos by having a tool that reads the audit logs and publishes signatures.

Many projects publish RPM and APT repos and as part of that process must have a GPG key that signs the repos. However, this inevitably creates the issue of who has the GPG key, what protections exist for the key, and what is the automation to get a release out the door.

A proposal for solving this would be to have a tool that creates GPG signatures for things that it finds on the audit log. So the workflow for a Deb repo would be something like:

• Create a Release file (e.g. Release) and upload it to a URL
• Add that URL to the audit log
• A signing service is watching the log, sees a Release URL for a domain it watches, and creates a signature
• Signature is uploaded to another service for publishing

rget signature-generator --key 600CD204FBCEA418BD2CA74F154343260542DF34 --watch 'https://packages.cloud.google.com/apt/dists/.*/Release'

Then lets says an audit log append for https://packages.cloud.google.com/apt/dists/cloud-sdk-xenial/Release comes in. The tool would generate the Release.gpg and add it to a local directory to be uploaded to git/etc using a sidecar service.

Aside: This is a sort of inversion to the way web CAs work with certificate transparency. Web CAs can issue certs without them being in the log first, but the certs MUST appear in a log within N hours of issuance to be trusted by web browsers. The end result is the same: all signatures end up in the log.

This is a problem Kubernetes (#33) would like to solve.

Prior art or similar ideas:

• https://github.com/coreos/fero
• https://cacrcybersecurity.wordpress.com/2016/02/24/chain-of-custody/
• https://pagure.io/sigul

[philips]

cc @thockin @spiffxp @justinsb @justaugustus @dims