Entitlement server and protected repos support

[Damián Nohales]

Hello there,

I'm Damián from Endless, we are implementing a private repo support
for Flatpak and friends with the objective to have a generic way of
supporting purchases and things like that, Dan Nicholson already
talked to you about the flat-manager part of this project [1].

I'm working on the Flatpak side of things and I want to make I'm
getting peer review of the approach, so this makes it to upstream.

The idea is that, before pulling a ref from a private remote, Flatpak
requests to a special server a token to then be used in the subsequent
commits/superblocks/etc requests to the repo, somehow then, the repo
CDN and flat-manager will deal with the verification of that token to
send the objects, as we discussed in the other thread.

I was planning to add a new remote option called
xa.entitlements-server-url or xa.auth-server-url (for some reason, we
are struggling on deciding the name of the option :) ) with the base
URL of the special server for which we have a WIP implementation
called flatpak-entitlements-server.

So, the steps are:

1. A ref is about to be pulled (repo_pull is called).
2. Before calling ostree_repo_pull_with_options, we get a token from
the entitlements server (if configured) usable to download just the
ref_to_fetch that expires in a short period of time .
3. We set the token in http-headers pull option as a Bearer token
Authorization header.
4. We call ostree_repo_pull_with_options with the pull options.

Then we have the P2P case:

1. A ref is about to be pulled (repo_pull is called).
2. The P2P code path is used (we have a collection_id)
3. ostree_repo_find_remotes_async is called
4. For each finder result, we set a new "OstreeRepoFinderResult {
GVariant *options }" field that will override the common
ostree_repo_pull_from_remotes_async's options argument. That new field
is populated with the Bearer token in the http-headers field of the
finder result option.
5. ostree_repo_pull_from_remotes_async will use the options specific
to the remote to fetch the objects.

The only thing I cannot see integrating well to upstream is the
mechanism to get the credentials to talk to the entitlements server.
In our specific case, these credentials lives in the user's keychain,
so it's fetched using libsecret and an Endless specific SecretSchema.

So maybe we can create some sort of entitlements-server credentials
providers that are dynamically loaded as plugins so each distro can
provide their own .so files with the specific implementations?

Let me know your thoughts!

[1] https://lists.freedesktop.org/archives/flatpak/2019-April/001545.html

Cheers

-- 
Damián Nohales  |  Endless