On Thu, 2013-08-29 at 09:12 -0400, Colin Walters wrote:
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
Management can be complex for sure. But that's partially out of the scope of the packaging system/ostree. E.g. apt just uses (a set of) trusted gpg keyrings which are managed by the packaging system itself. Which might be a suitable setup for ostree as well (or having a configure file as you indicate later on). The big issue is always what happens when you transition to a new key, which is something to think about more. (Probably the trusted gpg keys should be shipped inside the ostree itself so they can be updated by ostree?). The tricky bit here with ostree is that there are no guaranteed intermediary states (which i'm wondering if they maybe needed at some stage for production deployments, but that's for the future).
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.
So SSL root certificates can help you in establishing a chain (but what if the root certificate gets updated?). But that's something you can do with GPG as well. For our security model, https & tls isn't very useful though. We want to verify the commit was done or acknowledged by a trusted party, not necessarily that the repository is from a server we trust. Also the requirement to verify the server means you can't easily mirror the repositories onto other machines or do offline upgrades from e.g. USB key and still do the verification. In my view it's better to create the "master" repository & commit in a secure location (e.g. no public service, limited amoutn of users etc), sign it and then throw it out into the world via whatever way, which can be http, https, or sneaker net.
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).
-- Sjoerd Simons <sjoerd simons collabora co uk> Collabora Ltd.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature