single-file bundle gpg key handling

[Colin Walters]

On Tue, Nov 10, 2015, at 05:21 AM, Alexander Larsson wrote:

> We have a single bundle file that contains a single ostree commit (of
> an xdg-app application), as well as its detached metadata (i.e. gpg
> signatures). It can also optionally contain an origin uri for further
> updates, and a gpg key that can be used to verify commits in this
> commit and in later updates.

To confirm, you're thinking the origin URI and gpg key come inside
the bundle metadata a{sv} too?

> During installation of the bundle we automatically create a remote for
> the given origin, so that later updates are simple. This remote allows
> us to set up gpg trust configuration for later updates.

Yep, OK.

> And for each of those there are several possible options for the gpg
> public key to use:
>  * Explicitly specified by the user at install time

Or a different approach to this is to have an explicit `add trust`
phase.  Something like:

https://github.com/coreos/rkt/blob/master/Documentation/subcommands/trust.md

(Which BTW, has a lot of not really novel, but still good approaches
 for things like embedding metadata in HTML)

>  * Shipped in the bundle

The thing I think *doesn't* work is what yum/rpm does by showing
you a fingerprint and saying "Trust 0xcafebabe? [y/N]".

I think bootstrapping off of the TLS CA certs, is going to be
"good enough" for a lot of use cases, and for those that want
to be explicit, supporting an xdg-app specific keyring where
keys are explicitly imported would be good.

> In my opinion, if you have a downloaded file we should trust the
> content of that file that by default. If you cared about security you
> got it in a safe way (such as https), and I don't see how it would
> carry less trust than e.g. a gpg key you downloaded from https. 

Ok yeah, I agreed above, but I'd also note there's interesting things
in the rkt domain around binding keys <-> domains and such.

It's worth thinking about keys for people providing multiple applications - 
do we expect one key per author, or one key per app, etc?

> * Bundle with unsigned commit
>   - Install even though not signed (we trust the bundle), although
>     fail if the user specified a manual gpg key with --gpg-file.
>   - Add origin as a remote, but set gpg-verify=true, so updates from
>     it will fail until you configure a gpg key for it. If a gpg key
>     is passed on the command line with --gpg-file we directly configure
>     it.

Hmm...is this also without TLS to the origin?  I could see some
people not wanting to bother with GPG at all, and relying on
pinned TLS.

> * Bundle with signed commit, but no gpg key
>   - Verify the commit *only* if you manually specified a gpg key with
>     --gpg-file
>   - Add origin just like for unsigned commit.

Why would one do this?  The key is going to be small enough
relative to most app sizes it shouldn't matter to just require its inclusion,
right?

> * Bundle with signed commit, and gpg key
>   - Verify the commit with the included gpg key (or with the manually
>     specified one if any)
>   - Add origin with the included gpg key configured (overridden with
>     the --gpg-file specified one)

This is basically "bootstrap GPG off TLS", right?