Re: Keys/Signature use in OSTree/Flatpak/Flathub

[Dan Nicholson <nicholson endlessm com>]

On Fri, Oct 7, 2016 at 1:32 PM, Colin Walters <walters verbum org> wrote:
> On Fri, Oct 7, 2016, at 04:05 PM, Dan Nicholson wrote:
>
> > I think the point is that if you're doing anything nontrivial, then
> > you need to sign the summary file on the server.
>
> Can you elaborate on that bit?

We have multiple stages of repos so that we can develop on stable
branches and only push them to the production repo when we're ready
for a release. We do this as a pull local rather than doing it
internally and mirroring each stage so that the objects are hardlinked
and our public server doesn't double in disk space. Once we do the
pull, the summary needs to be regenerated and signed.

Furthermore, doing this promotion with pull rather than rsync means
that the objects and refs are properly staged and the repo is always
in a valid state. Supporting commit removal opens you up to even more
issues. See below.

> > Since you can't
> > reliably mirror an ostree repo anywhere (cross your fingers with
> > rsync!),
>
> Hmm, are you referring to https://bugzilla.gnome.org/show_bug.cgi?id=765701
> or something else?

Oh, I thought the issues here were well known. Some of this issues:

1. Works entirely by chance because objects sorts before refs, which
sorts before summary and rsync publishes in alphabetical sort order.

2. Objects are pushed directly into place. If there's a crash or
network interruption in the middle of the sync, you have a possibly
corrupt repo. If you smartly turn on the --delay-updates option so
that files are uploaded to a temporary name and renamed into place,
you now might leave behind a bunch of hidden file cruft if there's an
interruption.

3. If you want to support removing commits, then you have to use
--delete. Due to the above ordering, you'll now remove objects before
the refs have been removed and you now have an invalid repository if
anyone pulls during that window.

4. Since there's no locking of the ostree repo on the source end, you
can publish broken commits. This would happen if a source ref got
updated after rsync had completed part of the objects sync (this has
definitely happened to us before).

You can probably think of lots more. It's really only safe if you know
both sides won't be accessed during the sync.

> > that pretty much means that the private key needs to be
> > available on your public facing server.
>
> Why?  What blocks you from signing on an internal
> server and mirroring (via rsync or having the public
> server do a pull from internal or whatever)

I suppose we could do our staging internally, use pull and let the
disk space explode on the public server. But our internal server is
intentionally not public facing, so we'd have to punch a hole through
somehow.

The other idea I've been thinking about is another round of
ostree-push script where you use ssh to tunnel a local HTTP port to
the remote and and use pull. Haven't had time to play with that,
though.