Entitlement server and protected repos support

[Alexander Larsson]

On Fri, Jun 7, 2019 at 12:02 AM Damián Nohales <damian at endlessm.com> wrote:
> Hello Alex,
>
> So, after talking to the team at Endless, specifically about this
> situation. We are finally thinking of this approach:
>
> The repo will have in its configuration (in the summary) two new options:
>   * xa.authenticator: Which can be a query string with multiple
> parameters describing the way the repo should manage the
> authentication.
>   * xa.authenticator-gpg-key: The public key the repo must use to
> validate pull tokens.
>
> On the other hand, we will create a D-Bus interface called
> org.flatpak.Authenticator, anything outside Flatpak could implement
> that interface, right now, I'm thinking that interface could have only
> one method called GetToken which accepts what's inside the
> authenticator, the refs that Flatpak wants a token for and basic
> information about the remote (like URL and Collection ID), and returns
> the bearer token to be used in the pull requests.
>
> So basically Flatpak doesn't know anything about how to get the token
> at all, but it delegates that work to the available services
> implementing org.flatpak.Authenticator. It only knows what is returned
> there, must be used as Bearer token afterwards (unless we want to be
> flexible there too). Depending on the information in xa.authenticator,
> the authenticator could try to fetch the token, or ignore the request
> and return null. When Flatpak detects an authenticator returning
> something, it stops calling the rest.

I think this sounds good. But, the devil is in the details, and in
particular I think you need to be very careful when designing the
org.flatpak.Authenticator API. Your initial implementation will just
immediately return the endless entitlement data, so it is very easy
for the API to be modelled on that and become token =
send_token_request_and_wait_for_response (bus, config). However,
conceptually the authentication API can do some form of authentication
UI as well as potentially problematic network i/o. So, one has to take
into consideration that this API can:
 * Block
 * Take a long time
 * Run into network/connectivity issue
 * Be cancelled by the user

And the above issues must be taken into account when designing the
dbus API. For instance it can't be a regular single-message send
request + get response, because those typically times out in 30 sec.
Also, the flatpak library code wrapping the dbus calls will also look
different if the call is something you can expect to call
synchronously, or something that is blocking and does interaction.

I recommend that you look at the portal dbus API, as it has similar
requirements. For example, the base portal request is:
  https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Request.xml
Which takes what is really a single portal request and makes an object
representing it that will eventually get a response as a signal, or
that can be cancelled from the caller side if the user is not
interested in the request anymore.







-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com