Flatpak paid apps and private repos design document

[Philip Withnall]

On Tue, 2019-08-20 at 14:58 +0200, Alexander Larsson wrote:
> On Thu, Aug 1, 2019 at 4:51 PM Owen Taylor <otaylor at redhat.com>
> wrote:
> > I'm looking at this from the perspective of the "OCI" codepaths in
> > Flatpak - the idea of this is that we can package up a Flatpak as a
> > OCI (or docker) container and install it from a container registry.
> > From that perspective, some things here seem over-specified -
> > specific
> > to the classic ostree codepaths, or perhaps even to flat-manager.
> > 
> > Authentication/authorization is still interesting, but probably for
> > different cases:
> >   - The entire repository is private and you need to provide
> > credentials to get the index (summary equivalent)
> >   - The repository index is public, but you need to provide
> > credentials for a "subscribed account" to download some or all
> > content
> > 
> > In addition, we are generally interested in leveraging existing
> > container repositories - so there isn't much ability to change how
> > the
> > repository works - so while authorization might still be by bearer
> > token, specifying the exact details of what is in the bearer token
> > isn't going to work.
> 
> So, I see two issues here:
>  1) The document lists tokens as JWT, which might not be what an OCI
> registry uses. However, I don't really see why we have to require
> JWT,
> as long as whatever token we use is handled correctly on the server
> (and i commented re that in the doc). The only case where we would
> need to verify the token elsewhere is in the p2p case, and we could
> easily document that p2p only works with JWT tokens.

Indeed, or perhaps we could add additional methods to the authenticator
interface which allow it to verify an incoming token when being used
for P2P. For authenticators which use JWT, this would use the public
key copied from the remote server’s configuration to verify the JWT
signature. For other authenticators, they can do what they like
(including returning an error saying that P2P isn’t supported).

> 2) Some OCI registries will require a bearer token for the index
> (i.e.
> summary file), and the current API doesn't consider that. I think we
> could add a separate request for that though, could we not? I.e.
> something you call before RequestRefTokens as you download the
> summary
> file. RequestSummaryToken() or suchlike.

Right, seems reasonable.

> Other than that everything here is hidden behind the authenticator
> API
> and could be easily made to work for OCI repos, no?

I think so, although it needs someone to go through the document with
an OCI hat on and actually check.

Philip