single-file bundle gpg key handling

[Alexander Larsson]

Now that ostree master has the single-file delta stuff I'm working on
using this in xdg-app to create a single-file bundle that you can user
to distribute an app.

I need to figure out how this should work wrt GPG signatures though.
Colin, you expressed some doubts in the pull-request, so can you give
some comments on this?

First, the basic assumptions:

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.

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.

Now, how do we handle GPG signatures in this case?

There are two basic things that can be signed. The commit in the file,
and commits that are later pulled from the origin.

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
 * Shipped in the bundle
 * Don't verify signatures
And if any of these *don't* have signatures we can either ignore or
fail.

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. 

However, we should place the same level of trust in whatever comes from
the origin that the bundle specified. So, unless the user supplies a
gpg key, or the bundle contained one we should never set up automatic
updates.

This would mean that the behaviour we would have is:

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

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

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

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a suave playboy dog-catcher on a search for his missing sister. 
She's an orphaned hypochondriac magician's assistant fleeing from a 
Satanic cult. They fight crime!