Authenticated downloads & summary file

[Daniel Drake]

Hi,

I'm working on an OS-level feature around managing OS aspects which
are not managed by ostree itself:
https://mail.gnome.org/archives/ostree-list/2020-February/msg00000.html

Working through this in our product context, I am facing the necessity
of authenticated access to ostree branches. Right now I just need a
design - the implementation can come later. And naturally adopting the
same design as flatpak would be ideal.

Looking through the current flatpak authenticated downloads work, I
have a couple of questions.

1. Am I right in saying that the current design does not protect the
summary file? The ref name and commit ID for all private flatpak refs
can be seen by anyone, without authentication?

In this case, I would like to have private refs that cannot be
enumerated by anyone who doesn't already know that they are there. In
other words, I would like to protect the textual info expressed in the
ref name from the general public. (Obfuscating it would be one option,
but not an ideal one).

I experimented with ostree (without the authenticated downloads bits).
If there is no summary file on the server, I get the desired
behaviour, refs can't be enumerated by a remote client, but known refs
can be pulled.

If there is a summary file though, ostree will trust it as a full list
of refs. If you try to access a ref that is not listed there, the
ostree client will fail, even if the ref truly exists and removing the
summary file would actually make it accessible.

Omitting the summary file on a production server doesn't appear
practical, because static delta functionality relies on it being
there.

Hopefully ostree's client behaviour could be tweaked to allow access
to refs even though they aren't listed in any summary file which
actually exists.

If so, is there room in the flatpak authenticated download design to
allow for authenticated access to such "ghost" refs? Or is their
presence in the summary file a fundamental part of this access control
feature?

2. Are static deltas protected?
If a static delta corresponds to a protected ref, the delta will be
listed in the summary file (in terms of which commits the delta can be
applied from and to). Is the download of such static delta content
protected in the same way as the commit object is?

In this case, it is desired that the static delta download is authenticated.


Thanks,

Daniel