Re: Redistributing refs from multiple origins in a single repository

[Colin Walters <walters verbum org>]

On Sat, May 27, 2017, at 06:53 PM, Philip Withnall wrote:

> Let’s introduce the concept of an ‘origin’, which is a collection of
> related refs, all within the same trust domain. 

Let me echo Krzesimir on the "origin" term - we do already have
that for the ostree-as-host case.  How about one of:

 - "uremote" (unique remote)
 - "gu-remote" (globally unique remote)
 - "keybound remote"

> For example, all the
> refs for a particular OS as provided by that OS vendor; or all the refs
> for flatpak apps packaged by a particular organisation; or all the
> personal branches produced by a specific person.
> An origin is tightly bound to the GPG key which is used to sign its
> refs, although they are not actually equivalent, because the GPG key
> could change in future (key rotation, etc.). So, instead of basing the
> origin’s identity on its key, an opaque string identifier is used
> instead.
> This could be, for example, ‘gnome-apps’, or ‘flathub’, or
> ‘uk.co.tecnocode’. The exact naming scheme, and how to ensure
> uniqueness, is up for discussion (see the section below).

There's of course a very commonly used scheme to bind short globally
unique, human-readable strings with cryptographic keys:  the pairing of DNS and TLS
used for HTTP.

This type of thing is why I'm still pushing for doing "ca-pinned TLS" for metadata;
so many things are instantly solved with well-understood tooling.

A really good example of a problem is:
https://arstechnica.com/security/2017/04/chrome-firefox-and-opera-users-beware-this-isnt-the-apple-com-you-want/
(Now, I'd say that adding a new flatpak source should be an unusual
 operation, a bit distinct from visiting a web page - and the user interface
 should probably reflect this)

Do we expect these (i'm going to use the term "guremote") to show
up in a user interface like gnome-software?  It seems unavoidable.

Hm, well I guess really we should look at Flatpakrepo files as they
exist today.  You mention those below.

Assuming one is using an OS without flatpak repos defined already, we're
basically relying on the existing TLS infra to bootstrap things.

So...given the existing:

```
[Flatpak Repo]
Title=Gnome Stable Runtimes
Url=http://sdk.gnome.org/repo/
Homepage=https://www.gnome.org/get-involved/
Comment=The standard Gnome runtime used by most gnome apps
Description=GNOME runtimes are released with each major release and contain the main GNOME platform 
libraries. At the moment they only receive minor bug fixing and security updates, but should be considered 
ABI stable and frozen.
Icon=https://www.gnome.org/wp-content/themes/gnome-grass/images/gnome-logo.png
GPGKey=mQENBFUUCGcB...
```

You're saying that we want the ability to change any or all of that, and so
we need a new persistent value (stored in that file?  Or I guess per-commit)?

This also brings up an issue with flatpak {repo,ref} files in that they aren't signed
with the GPG key.  

Hmm.  So if we're trying to support key rotation, Alex already added the
xa.gpgkeys to commits, which will cause new updates to extend the keyring.
It feels like for the P2P case what we need is a way to communicate the key
rotation *separately* from the apps.  Then it's easier for us to ensure that
all clients get notified of the latest keys.

And once we have that done, we can simply have the repo uuid be the latest
key fingerprint.   In the offline computer lab case, plugging a USB stick into one
with a set of "key transitions" + "commit data" would ensure that as the
machines picked up the key transitions, they would then start looking for
refs advertised by the new key.