Research for app purchases

[Alexander Larsson]

On Mon, Oct 14, 2019 at 10:14 PM Dan Nicholson <nicholson at endlessm.com> wrote:
>
> > This is fine for certain kinds of operations, like tab completion or
> > listing things. However, the resolve phase requires certain things to
> > be 100% correct, such as permissions and dependencies. We can't claim
> > the app needs a set of permissions then install one with a different
> > set, or download a runtime for the app which isn't the one it will
> > actually use.
> >
> > This is why the p2p case downloads the actual commit that will be
> > used, and I unfortunately can't see a way out of this.
>
> Hmm, I wasn't aware of that but I see what you're saying. Can you
> point me to any discussion/issues for that? I don't want to get off
> onto a tangent, but I think this needs to be fixed for p2p. Here's a
> strawman I thought of:
>
> * p2p server generates a summary file, which will contain the refs
> that it's mirroring. If the mirrored refs in the repo don't match
> those in the ostree-metadata commit from the mirrored repo, the
> summary generation fails.
> * p2p client pulls both the summary and the ostree-metadata commit,
> verifying only the ostree-metadata commit since its signature from the
> mirrored remote
> * p2p client validates the mirrored refs in the summary match the refs
> in the ostree-metadata commit. If they don't match, it's a warning. If
> they don't match and the remote defines an authenticator, then it's an
> error. I haven't thought that all the way through, but the idea is
> that old p2p clients and servers can still operate but if you want to
> participate in purchasing by declaring an authenticator, then the p2p
> server needs to DTRT.
> * p2p client pulls only mirrored refs from the p2p server and falls
> back to the remote for non-mirrored refs.

This is more complicated than that. Lets start with the basic premise.
There is somewhere a master server. This is the only place that can
add or update a ref, because it has the GPG key that allows it to sign
the commit, as well as signed versions of the summary. While updating
the summary it also updates the ostree-metadata ref with a subset of
the information in the full summary file.

Additionally we have N mirror repos. They all copy refs as-is from the
master repo, because they have no gpg key so they can't produce new
commit objects. However, they *do* create their own summary files,
which is possible because the summary file in the mirrors is not
signed. This is required because the summary file has to match the
refs & commits that the mirror actually has. Each mirror can be a
subset of the full master repo, and can be out of sync wrt the master
repo, but also between its own refs (i.e. individual could have been
updated at different points), including the ostree-metadata ref.

On the client side when we want to install something we essentially do
a parallel operation that gets the summary file for each mirror and
then we pick the one that has the newest version of each ref and pull
those. The same happens for the ostree-metadata branch which is used
for things like listing refs and whatnot.

Note here that we have only one copy of each ref locally, including
the ostree-metadata one, and we update that to the latest version
available in any mirror, and even avoid updating it if the local copy
is already newer than any available one.  This means that even if each
individual mirror was itself internally consistent (e.g. by the rules
you specify above), that may not be consistent with the client. So,
adding (and verifying) rules to the p2p mirrors doesn't really help.

However, in practice I think what will happen is that you either have
access to the  master repo itself, or a single p2p mirror that is in
sync with the master at some point (but subset). So, in that case we
*could* use the ostree-metadata info to resolve the refs, but only if
we can verify that the ostree-metadata info is up-to-date for a
particular ref. This is not currenly possible, because the
ostree-metadata repo only contains a collection+ref -> metadata map,
and we have no idea what version this metadata came from.

But, we could add to the ostree-metadata info the commit ids, and then
we could use that when available for the resolve operation, not having
to download each individual commit if the version we're pulling (which
we know from the partial summit) matches the one in the
ostree-metadata. This seems like a useful optimization at the very
least.

I can still imagine cases where it would fail though. For example if
you had contact with the master repo at some point and updated the
ostree-metadata branch, but now you only have contact with a p2p
mirror that has an older ostree-metadata version. We would only be
able to install the mirrored version of a ref if it happened to match
what was the current commit when you talked to the master repo. Maybe
this limitation is fine for the case of purchased refs though?
Opinions? Ideas?

> The simpler "log in to server" dialog where you provide your
> credentials to the application implies that the application will act
> *as* you. Likely it will want to store your credentials locally so
> that it can authenticate non-interactively again later. I found
> https://www.oauth.com/oauth2-servers/background/ to be useful when
> thinking about this process.
>
> Anyways, the point is that I think the authentication process should
> cater to these types of authentication schemes where you do not enter
> your credentials directly to the flatpak application.

Yeah, I agree with this, will do some more thinking.