This adds a new way for authenticators to trigger interactive authentication
in the client for simple user/password dialogs. These are not recommended
to use as a webflow is often better. However, for OCI remotes that
use http basic auth this is useful and allows the CLI experience to work
with that.
Given a configuration like:
[remote "oci-remote"]
url=oci+http://some.server.com/api/v1/organization/foo?index=labels
xa.authenticator-name=org.flatpak.Authenticator.Oci
xa.default-token-type=1
xa.authenticator-options={"auth": <"a-token-here">}
I was able to install an app from an OCI remote that required a login
This tries to do a HEAD request to the repository and if that fails
with 401 uses the OCI mechanism to (given a basic auth token) generate
a token for the download.
In the non-p2p case add the per-commit summary info into the autheticator
request. This rewrites the keys with a "summary." prefix.
In the p2p case this doesn't make sense, so nothing there.
This will be needed for the OCI case where we need the
xa.oci-repository key.
This adds the remote uri, and the per-ref commit id, as well
as extensible per-ref and per-request dicts we can add stuff to
as needed.
These will be used for the OCI case.
The autoptr cleanup function for FlatpakRepoTransaction depends on the
OstreeRepo object that it was created with still being alive. If the
repo object is also an autoptr then it can depend on the order the
variables were declared in whether this works or crashes.
That is obviously an evil trap, so have FlatpakRepoTransaction take a
ref on the repo object and release it in the autoptr cleanup function,
in case the repo's autoptr cleanup function runs before that of
FlatpakRepoTransaction.
flatpak_transaction_progress_get_status() returns a pointer created by
g_strdup() but was annotated transfer-none. A quick grep shows that
calling code in the tests does treat it as transfer-full, so change the
annotation to match the actual behaviour.
An event happens more often as its frequency gets higher, so these
values were confusing me.
Rename the constants to include their unit (ms) as well, to avoid
confusion.
Anything that affects public API (such as
flatpak_transaction_progress_set_update_frequency()) or libostree's
options passed to ostree_repo_pull_with_options(), is left as is.
Here we're using the same GError pointer multiple times without clearing
it, which is an error. Use a local_error and print a debug message
instead, which matches the behavior in the loop above.
In commit 88aaaab7b, I overlooked that there
was already a doc comment for the flatpak-version-macros
section at the bottom. To make things worse,
the duplicate I added was malformed.
Fix things up to work as intended.
Given the pid of an existing flatpak process, if --parent-expose-pids is
specified, the new sandbox is run such that its processes are visible in
the specified sandbox.
In all other senses the two are disjoint though. The new sandbox is
still isolated from the host and the existing sandbox.
This allows the authenticator to directly do UI and parent it to the
relevant window. The actual parent string is specified just like
the xdg-desktop-portal one.
There is a new flatpak_transaction_set_parent_window() function that
clients can use to signal the what window they want to be parented to.
This allows the authenticator to handle each token type differently.
For example, this allows a "purchase" type to run the donation
webflow, but not require login (and then store the fact that this was
run locally).
This makes it very easy to reuse a single authenticator for several
remotes. This is useful for the a default authenticator implementation
that we can ship with flatpak and use for e.g. flathub.
These signals are emitted when the authenticator needs some kind of
web-based authentication. If the caller implements webflow-start and
returns TRUE, then it needs to show the user the URL and allow the user
to interact with it.
Typically this ends with the web-page being redirected to a url to
localhost or similar which tells the authenticator the result of the
operations. This will cause the webflow-done signal to be emitted and
the transaction operation to continue. If something goes wrong (or the
signal is not handled) it will also report webflow-done, but then the
transaction will fail in a normal way.
Generally all users of FlatpakTransaction need to do is:
On webflow-start, show a browser window with the url and return TRUE.
On webflow-done, close the browser window if its still visible.
If the user closes the browser window early, call
flatpak_transaction_abort_webflow().
When we need a bearer token, look up the configured authenticator for
the remote and ask it for tokens. Also updates the test-auth test
with to use the new test authenticator instead of the previous
env var hack.
The p2p case is kinda weird wrt tokens. We can do most of the basics,
like which refs need updating using the partial summary from the p2p
mirrors, but we can't rely 100% on the ostree-metadata info for core
info like permissions or dependencies, since it may be out-of-sync.
So, if the information in the ostree-metadata doesn't match the
commit we're resolving, the p2p resolve code actually pulls the actual
commit objects as part of a resolve.
Now, the commit objects are protected by bearer tokens, so we need to
pass them while doing this pull. Unfortunately the information about
which refs requires tokens are part of the commit, which is a circular
dependency. We resolve this by relying on the (possibly stale, but
probably ok) copy of the need-token info in the ostree-repo metadata.
So, we do the first part of the p2p resolve, then for all the
not-yet-resolved ops (i.e. ones that actually need updates) we look
in the ostree-metadata for which refs need tokens, generate tokens
and then do the pulling with the tokens.
This is an iterative process, because resolving a ref can create more
update operations, which may need more tokens.
Also, since the lower level APIs don't allow you to pass different tokens
for different parts change this function to support passing a subset
of the resolves, so that we can pass all that need a specific token in
one go, and then call this multiple times. The way we handle this is
by saving all the original ref_to_checksum hashtables for all results
and then re-create them with the subset of refs needed when pulling.
If the commit is available in the ostree-metadata and it matches what
the latest available commit in the p2p results then resolve it to that, so
we don't have to download the commit object.
This tries to resolve the p2p resolve operation from the info in
a ostree-metadata commit. This only works if the resolve ended up
on the same commit id as what was available in the ostree-metadata
which may not be correct if the two are not synchronized.
We extract the need-token key from the summary and if set we
calculate a token to use for the operation, which we then pass
to install/update.
For now the actual token just comes from the FLATPAK_TEST_TOKEN
environment var. The details of this will be fleshed out later.
Additionally, this does not support the p2p case, because there
we need the token in order to request the commit during the resolve.
This will also be added later.
