Re: signing commits

[Colin Walters <walters verbum org>]

On Wed, 2013-08-28 at 15:44 -0600, Jeremy Whiting wrote:
> Hello all,
>
> In considering implementing signing of commits I wanted to ask a couple of 
> questions about how to approach the feature.  My first thought after a little 
> discussion on irc is to do something like the following
>
> ostree commit --gpg-sign=<key-id>
>
> to sign the commit file. I was thinking I'd put the commit signature in a 
> hash.sig next to the hash.commit.

Right; I'd prefer it to be out-of-band (i.e. a separate file) rather
than as part of the commit object.  The issue is that the current commit
object format needs to be reworked.  See the entry "Rethink commit
objects" in TODO.

If it is out of band, do we really need it to be part of the commit
command?  (Ok, we need to have the GPG signature there before the ref
gets written, otherwise the client may update in between and not find
the signature).

The OstreeRepo API note splits commits into two parts: create commit
object, then write ref pointing to it.  We could tell a client that
wants to do GPG signatures to write a custom commit program using the
API (this isn't too hard to do).  Or alternatively, something like
ostree commit --exec="gpg --sign {}" ? (ok, yeah, eww).

> Then on the other side, something like this:
>
> ostree --repo=blah pull --require-signature will when pulling look for .sig 
> files for each .commit, and not stage the .commit into objects/ unless it 
> verifies against the signature.

This is a good illustration of the point that the hardest part about
deploying crypto, particularly public/private key, is around policies
and procedures, not the actual algorithms.

Concretely here, you're glossing over the question of *which key* the
commit is signed with.  Anyone can make up GPG keys, if you're just
requiring commits be signed, there is basically no security gained.

Ubuntu has been working on image based upgrades; while some of their
ideas are not so well thought out, their page on GPG shows just how
complex key management can get:

https://wiki.ubuntu.com/ImageBasedUpgrades/GPG

This sort of thing is why for the OSTree core I just went with SSL/TLS;
it's simpler, and enterprises love the centralized management from root
certificates.  You can do stuff like configure client machines using
OSTree to only trust a particular root if you want.

But rather than configuring this on the command line, there is already
an available knob "tls-permissive" that one can set
in /ostree/repo/config.  If we're doing GPG we probably want something
like:

"gpg-trusted-keys=1CEC 7A9D F7DA 85AB EF84  3DC0 A866 D7CC AE08 7291;"

(an array of GPG key fingerprints).