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

[Robert McQueen <rob endlessm com>]

On 12/05/17 11:13, Alexander Larsson wrote:
> 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 live TLS requirement is also not great for Endless where we're
looking at caching ostrees (with the refs that point to the latest
OS/flatpak/etc) and either sharing those again over LAN, USB, etc.

> 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?

Trust transfer is definitely a worthwhile goal - hitting the master
server is just not always possible.

As a side thought, we're a little worried about the summary file getting
much larger over time as well. When you get up to 100s or 1000s of
Flatpaks we're talking a _lot_ of refs. A cool 10MB a day just to
refresh your app list (something you might very reasonably want to do
daily, so you can implement some policy based off of that) isn't too
great if that adds up to 300MB over a month - 60% of your data plan.

At Endless we did ponder a few tweaks to summaries in terms of being
able to split out refs into a separate file (refs.d/bla...?) with inline
signatures (for atomicity) and ideally compression. That would allow you
to selectively mirror refs out of a repo without losing the signed refs,
check for updates, etc without needing to check the whole summary file.

> 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).

This would also help - you'd also be able to split these out into your
own summary files, which had valid signed refs / redirects... I like
it... :)

> 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.

Huge shout out to the signatures and the files traveling together. Even
Debian managed to solve this, after inflicting a mere 20 years of
suffering on everyone. ;)

Cheers,
Rob

........................................................................

Robert McQueen  |  +1.415.413.4159  |  Endless <http://endlessm.com/>