single-file bundle gpg key handling

[Alexander Larsson]

On lör, 2015-11-21 at 11:23 -0500, Colin Walters wrote:
> 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?

Yeah

> > 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/t
> rust.md
> 
> (Which BTW, has a lot of not really novel, but still good approaches
>  for things like embedding metadata in HTML)

Yeah, we could support something like this too.

> >  * 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.

You mean a global xdg-app keyring (for all repos). I guess that would
be nice. Then you can preload stuff there in various ways.

Also, I found an issue with ostree_repo_verify_commit(). It doesn't
allow me to put in a repo name, which means it will automatically pull
in per-repo keys from *all* configured repos. How can I avoid that?

> > 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?

I've not though about this much. I kind of assumed it would be one per
author, but perhaps that is not ideal. It would make it harder to trust
a subset, and to revoke a subset.

> > * 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.

Can we do pinned TLS with libsoup?

Anyway, this would not necessarily be used for distributing to end
users. Single-file builds are also useful for e.g. doing development on
an embedded device (like a phone) where you want a simple way to upload
the build to the device to test it.

> > * 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?

Yeah, that is true. It wouldn't really be very useful. I'll change that
to fail if you didn't supply a gpg key.

> > * 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?

Yeah.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a notorious white trash grifter possessed of the uncanny powers of 
an insect. She's an orphaned foul-mouthed bounty hunter from a family of 
eight older brothers. They fight crime!