Re: Adding Avahi and USB drive support to libostree

[Colin Walters <walters verbum org>]

[Will try to contain my use of characters to boring old ASCII]

On Tue, Mar 28, 2017, at 06:20 PM, Philip Withnall wrote:
> Exploring other solutions makes sense. GPG keys and repository
> identification are not entirely orthogonal in this situation, since if
> we're going to support downloading objects from untrusted hosts on the
> local network (rather than a trusted central server), GPG signing is
> mandatory, and hence a GPG key will always be present as a bit of
> shared data between the client and the remote.

Right, I agree with that.

It feels like perhaps what we should have done from the start is to bind
*ref* to GPG key.   That'd be somewhat ugly to retrofit now though.
 
> Using a GPG key is basically equivalent to your previous suggestion of
> a UUID per repository. I decided that a GPG key would be a bit more
> usable, since a UUID is an additional bit of incomprehensible-hex-
> string to be associated with each repository. However, this comes at
> the cost of somewhat overloading the semantics of GPG keys. I would be
> OK with using a UUID instead, if you want to bypass the semantic issue
> here.

UUID-in-repo definitely has its own set of problems, let's dive into the
below more a bit:

> Not quite. Resolving the ref to a commit hash needs to involve all the
> potential remotes, since they might all resolve it differently, and
> some remotes might resolve it to a more recent commit than others.

What I was proposing is that the client contacts the "canonical remote"
first.  This is in line with my proposal in [previous 
discussions](https://mail.gnome.org/archives/ostree-list/2016-October/msg00002.html) around mirroring - the 
mirrorlist or "fetch objects
from multiple places" is for *content* - we would still retrieve
the summary/commit metadata+signature from the more-strongly-protected
metadata part of the remote.

See also https://github.com/ostreedev/ostree/issues/707

> Put differently, the decision about which URI to pull from, and which
> other URIs to consider as mirrors of it, needs to be taken only after
> the summary information is available from each remote. As far as I
> understand, mirrorlists do not do that (nor do we want them to?).

We could.  https://github.com/ostreedev/ostree/issues/687 is also
a bit related to this.

But this is all a bit of an aside - if we do the "retrieve commit hash from
canonical remote, try finding commit in local mirrors" model, it
wouldn't apply.