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

[Alexander Larsson <alexl redhat com>]

On Thu, 2017-05-04 at 09:56 -0600, Daniel Drake wrote:
> On Thu, May 4, 2017 at 8:01 AM, Alexander Larsson <alexl redhat com>
> wrote:
> > In fact, i'm currently looking into doing this, and the design will
> > probably be quite similar. i.e. some metadata in the summary file,
> > that
> > if set will rewrite the configuration of the remote.
>
> We should definitely sync on this then. And hopefully anything I
> contribute at the ostree level can also be used by flatpak, at least
> partially.
>
> In my current implementation, I place data in a currently-unused
> a{sv}
> field attached to the new ref. But if we're now going to allow
> redirects to other remotes, we'll need to move to to the overall
> a{sv}
> field at the end of the summary file, where we could introduce
> one-to-one redirects like:
>
>  redirects: {
>    old_ref: (new_remote, new_ref)
>  }
>
> (new_remote could be NULL/empty if the new_ref is in the same remote)

I don't think this kind of repo split is right for flatpak. In the
flatpak security model there is a large degree of trust in the locally
configured remote. Primarily the remote name, the remote url and the
remote GPG key.

Whenever you install an app you have to explicitly say what remote name
it comes from (and any time there is some kind of auto-dependency-
install you have to acknowledge or choose the remote name). Once an app
is installed (pulled and deployed) we record in the deploy what remote
it came from and only every update from there. This is very different
from the apt/yum/dnf model where you just give the package name and it
installs/update the latest from any configured package repo. The reason
for this difference is that flatpak expects to live in a world where
there are many configured remotes of varying levels of trust, and you
don't want the low-trust remotes to hijack names from the trusted ones.

So, when you define a remote you give it a name and a gpg key, and you
trust anything signed with that key as long as you give that name. This
means for instance that it is ok for that remote to change to a new
URL, as long as the statement of this is signed by the current GPG key
(for instance, by using a signed summary). Its also not a problem if
this happens automatically in a silent fashion (essentially its a more
permanent HTTP redirect).

However, this is mainly useful when the repository *as a whole* moves
to a new location, say because upstream switches to a new storage
location. We don't want just one app to switch to a different remote,
because that conflicts with the security model, as you'd need a
different name for the new remote and a way to explain to the user
exactly what happened.

Now, a different thing is a rename of an app. Say for instance that
some app gets a new domain name and wants to change app id from
com.github.user.TheAppClient to org.TheApp.Client. This is more like
what you're talking about, and could also be interesting for flatpak.
However, this isn't something that can happen silently in flatpak, for
several reasons:
 * The app id might be used by the user explicitly, for instance to
   start the app, or update it. So, he needs to be aware of the new 
   name.
 * The app id is used as a reference to persistent thing, such as
   the directory name for the app-private files, and permission
   overrides and portal access.
 * The deploy directory needs to be renamed to the new name.

Basically, in flatpak such an operation is probably best exposed
by some kind of tombstone saying that this app is end-of-line and then
have the user install the new one and trigger some app-data migration
thing.

I don't really think any low-level support in ostree is very useful for
me here, other than perhaps standardizing the names and formats of the
metadata for this.


Back to the whole-repo move. Flatpak already has support for updating
some remote metadata semi-automatically. We store metadata fields
called "xa.title" and "xa.default-branch" in the global metadata dict
in the summary, and when you initially add the remote, and when you do 
"flatpak remote-modify --update-metadata" this is updated, mirrored in
similarily named config options in the remote. (xa. is from the old
xdg-app name.)

The way i plan to extend this is to first automate the current setup a
bit by essentially having flatpak automatically do --update-metadata on
all related remotes before initiating an install or an update. Then add
new fields: xa.url, xa.add-gpg-keys, and xa.remove-gpg-keys, which
should be enough to migrate to a new repo location with a different gpg
key. Additionally, the gpg keys will let us do things like migrate to a
new gpg key if the old one expires.

Flatpak also has an interesting use of a system-helper for doing
system-wide installs as a user, via a polkit helper. The updates for
this will be implemented by passing the entire new summary to the
system-helper, which will verify that it is signed with the right key
and only then do the change (with the proper auth as needed).

This all happens in a sense "above" ostree, so I'm going to implement
it in flatpak. I don't know if putting any of this in ostree itself
would really help.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's an immortal native American cyborg who hangs with the wrong crowd. 
She's a beautiful communist bounty hunter with an incredible destiny. 
They fight crime!