Re: Adding Avahi and USB drive support to libostree

[Colin Walters <walters verbum org>]

On Wed, Mar 29, 2017, at 05:16 AM, Philip Withnall wrote:

> In the sense that each ref has a different GPG key; or in the sense
> that the ref name is a key ID? In either case, commits would need to
> support being signed by multiple keys (which I assume they do already
> by appending the signature packets in the .sig file?).

While nothing *requires* it, the naming convention established from
the start of ostree for refs encourages being globally unique - this is
*very* different from git, where almost everyone has a `master` branch. 
And the ref name is what's used for downloads/upgrades (by default).
I chose this because:
 - The concept of "master" doesn't make as much sense since it's intended
    to have multiple equally-important branches (e.g. fedora/26/x86_64/atomic-host and 
fedora/26/x86_64/workstation)
 - And besides the "content" differentiation, there's CPU architecture in the branch name

> Are you suggesting this because of the way flatpak uses OSTree --- one
> repository which deduplicates files from various separate applications,
> each of which has its own ref, and theoretically is its own security
> domain?

Right.  And the same for the host OS case - it should never happen
that a flatpak ref is the same as any existing host ref, and all of those
should be distinct from refs generated by e.g. the `atomic` command
importing Docker/OCI images, etc.

> That's a valuable use case, but not the one I am trying to address
> here. The use case I am trying to address is for updating *without* a
> connection to the internet.

OK.  I read back and didn't see this mentioned from the start.
Anyways, I'll be honest, I have very little practical experience with mesh/P2P/decentralized
networking. 

The "completely disconnected from the Internet" model also occurs
in a primary use case for me, which is servers.  But there, what we've
documented is changing the e.g. /etc/ostree/remotes.d/redhat.conf file.
In the enterprise server case of course, there are sysadmins who are
dedicated to managing configuration like this, *and* it's very typical
to model things as an "intranet" - you still use DNS, TLS (but with
custom CA certs) etc.  So pointing the remote at mirror.examplecorp.com
works just fine and is expected.

So let me ask this - in the mesh (is there a better/standard word?) case,
what are you doing for *other* applications?  What does e.g. the
web browser app do?   How do you deliver and cache non-OS content?

What prior art is there in other mesh software for problem sets
like naming/identification?  I glanced at https://gnunet.org/about
and indeed they seem to have a DNS-like system that's derived
from a public/private key. 

So from that perspective, perhaps then you're down the right path
with identifying remotes via GPG keys.  

But this is going to be a challenge for me to review/co-design because
I basically don't have experience with it.

> For example, a machine is initially installed, and has no internet
> access. It needs to be regularly updated from a USB stick.

My feeling is that we can deal with this case and the others
you have by: Try to resolve the requested ref in each remote (sorted by
priority, file:// first etc), downloading the commit object, verify signature,
then take the *newest* commit from that set.

Right?