Entitlement server and protected repos support

[Damián Nohales]

On Thu, May 23, 2019 at 9:33 AM Philip Withnall <philip at tecnocode.co.uk> wrote:
>
> On Thu, 23 May 2019, at 08:19, Alexander Larsson wrote:
> > On Thu, May 23, 2019 at 12:56 AM Damián Nohales <damian at endlessm.com> wrote:
> > > 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.
>
> I don’t think you want to extend the OstreeRepoFinderResult struct, because it’s specific to a remote, whereas you want to use a different bearer token for each ref/commit.

Why use a different bearer per ref/commit? the token (at least for
flat-manager) could be suitable for the entire ref or many refs in one
remote.

>
> Instead, add an option to ostree_repo_pull_from_remotes_async() which maps refs (or commit checksums) to an a(ss) of HTTP headers to use when pulling that commit metadata. Each set of HTTP headers would contain the relevant bearer token header.

Ok, I like more this idea, you mean a hash table that maps ref +
remote to HTTP headers?

>
> > I think this will do the right thing for the actual upstream remote.
> > However, the p2p case is interesting, because what does it even mean
> > in terms of a private repo? What ensures that some random p2p node
> > doesn't give you the commits even without the bearer token? Maybe that
> > node did do an authenticated download, and now its just another commit
> > in the local repo that it is being nice to the peers on the local
> > network by giving out.
>
> We have three options:
>  1) Allow P2P peers to forward paid-for apps without any checks. Not really an option.
>  2) Don’t allow P2P peers to forward paid-for apps at all.
>  3) Allow P2P peers to forward paid-for apps on receipt of a valid bearer token, with some validation of the token.
>
> (2) is probably the easiest option for the first iteration of developing this, but we presumably want to allow (3) in the future. So the bearer tokens need to be designed so that either:
>  (a) a peer Bob can validate that a token from another peer Alice actually comes from that peer, that it was issued by a token server which Bob trusts, and that it hasn’t expired
>  (b) Bob can forward a token from Alice to the token server (which Bob must trust) and have the token server validate it
>
> (a) would allow full decentralisation, and is probably necessary if we want this to work for machines which are completely disconnected from the internet and which receive their apps over USB sticks. (b) probably isn’t significantly simpler.

The flat-manager repo relies on validating the token since
flat-manager is the one signing the token and has the secret to
validate the signature. It's like the peer has to share the secret
with the original repo somehow? I don't know if flat-manager supports
signing with public and private keys, maybe that's a way to transfer
and validate the token between peers.

I'm not familiar on how this P2P app sharing work, I don't know how
the peer could "know" that it needs to validate a token before send
the app. I should probably investigate more on how P2P works.

>
> So, I think (and please check this carefully — it’s only initial musing), this means that the token needs to:
>  • Contain a public identifier for the user it’s generated for, which can be checked by peers of that user’s machine. Perhaps the machine’s IP address, for example.
>  • Contain a public identifier for the token server which generated the token (so that peers can check whether they trust it).
>  • Contain an expiry timestamp on some global clock.
>  • The entire payload is signed by the key associated with that token server.

In the current implementation. The token it's not generated by the
token-server but it's requested to flat-manager through the
/token_subset API, what it does is to tell flat-manager to create a
permission limited token that is a subset of the permissions of the
token that the token-server uses to communicate with flat-manager. So
the only one able to validate the token, is the remote, through
flat-manager.
-- 
Damián Nohales  |  Endless