Re: Moving existing ostree users to a new branch - take 2

[Alexander Larsson <alexl redhat com>]

On Thu, 2017-05-11 at 15:28 -0400, Colin Walters wrote:
> On Wed, May 10, 2017, at 06:03 AM, Alexander Larsson wrote:
>
> > Flatpak master now supports this. It looks for xa.redirect-url and
> > xa.gpg-keys and updates these in the local client automatically
> > whenever you run flatpak update of flatpak install.
>
> Some discussion on this ensued in this ostree PR:
> https://github.com/ostreedev/ostree/issues/487#issuecomment-300865803
>
> Relevant flatpak commits:
> https://github.com/flatpak/flatpak/commit/21778f1075e5ea834aeed4469cb
> fea723ef9ef8c
> https://github.com/flatpak/flatpak/commit/7a4c82529ec42c961fce341adcc
> 0d8ec9687058a
>
> So...this requires a signed summary.  Which I've been trying to get
> away from =(
> Anyways, leaving that aside then, it does seem to me that
> functionality like
> this would be potentially quite useful for the ostree-as-host case as
> well, so it's
> worth thinking about how this could live in libostree.

So, I'm of two minds about signed summaries. Yes, they are a pain
because you can't add new refs without having the gpg key on the
machine that has the entire repo. But they also have some very nice
features once they are in use:

* In flatpak we heavily cache the summary file access, because for
larger repos it will be large, and having the smaller signature to
download first makes us being able to avoid having to download the
entire summary file if nothing changes, and still be sure we're not
using stale data. Of course, something similar could be done with HTTP
ETAGs, but the fact is that we don't currently do that.

* The TLS trust model implies doing a network access before you can
trust something. This is good for when you pull from the HTTP remote,
but once you've done that you can't further forward this trust. In
particular, the way flatpak does system updates is that we do the
download as the user, in the session, and then we can hand over the
entire thing to a local-files-only privileged helper that imports the
result into the global repo. This works because the global helper is
able to verify the signature on the summary and the commits. In
particular, we need the signature on the summary, because otherwise
we'd be vulnerable to a sidegrade attack where you switch one ref to a
commit from another ref. If we record the ref in the commit, then we
can possibly avoid the sidegrade attack, but that also seems like a
weird design, commits are not supposed to be tied to one branch only.

Also, the summary being GPG signed means we can transfer the trust to
other domains, such as when we're mirroring the repo. How does trust
work in a mirror system when not using signed summaries? Do you always
have to get the summary from the master repo?

How is the performance of HTTPS these days? It seems to me that
encrypting large chunks of well-known, already signed data is a waste
of CPU cycles, and could be a problem when trying to scale an OSTree
repository. Has anyone done any experimentation on this?

> Brainstorming a bit though...how about attaching this metadata to
> commits instead?
> They have GPG coverage, and I certainly want to encourage people to
> continue to
> sign commits. 
>
> A downside is that one would have to push a new commit for each ref,
> but
> that doesn't seem too hard for people to manage.  The simplest would
> probably
> just be to add the redirect metadata to *every* new commit published.

I don't think this is fundamentally right. The configuration of the
repository (such as the url) is related to the repo itself, not the
apps in it. For instance, we mirror the gnome sdks in the flathub repo,
but we don't necessarily want to inherit the gnome repo configuration.

So, lets take a step back. We want to be able to not have signed
summaries, but we still want to be able to give updates to the global
repo state that is signed.

That leaves us with two alternatives.

1) Add a new way to sign statements. I think this is actually pretty
easy, we just define a new GVariant format and put it in the summary
metadata dict. It will just be a tuple, with a variant and a byte array
containing the gpg signature for the variant in canonical form, i.e.
"(vay)". Of course, we have to be careful about re-creating these when
updating the summary, so we need to define a format to store the data
and signature in the repo config file, but that seems very doable (in
fact, very similar to the flatpak redirect-url thing).

2) Reuse the already signed commit metadata. We can just add a fake ref
that has the global repo configuration, and sign this. Then the client
could regularly pull that and update (and refuse to downgrade).
Technically it could be sidegraded, so i guess the commit need some
magic marker that it is actually a configuration commit. Of course, the
fake ref will be visible everywhere, which is kinda ugly.

I like the first option, because its just a single atomic file, and
additionally, it could (mostly) be reused to do an in-file signature of
the ref name -> commit id map in the summary, which will get us
(optional) single-file signed summaries.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a shy coffee-fuelled card sharp with acid for blood. She's a 
time-travelling gypsy detective with the power to bend men's minds. They 
fight crime!