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.
This is in the same order as the xa.cache array and contains the id of
the commit that the cached data is about. This is not necessary in the
non-p2p summary metadata, because in that we always have a matching
ref -> commit array.
However, in the p2p case this information can be useful.
Historically the p2p resolve code always did a parallel call to find
all the available commits for the refs, and then it took the results
and pulled only the commits for all the refs so that it could resolve
against the exact commits that were available (which might not match
with whatever metadata we have in the local ostree-metadata copy.
This splits this into two phases, the first that uses the summary only,
and a second one that pulls the commit.
The reason for this is that we want to be able to do some stuff inbetween
these, such as resolving some refs via the ostree-metadata and maybe
requesting bearer tokens that we need for pulling the commit objects.
These are explicitly made short to save space, so lets have defines
for them to make sure we don't mistype them, especially as we
will be adding new keys.
These were added so that extra-data would work in #2954, however that
was a bit broad. We only need extension deps for extensions that:
1) Uses extra data (so we can run apply-extra)
2) Doesn't specify NoRuntime=true (because the apply-extra is static)
Fixes https://github.com/flatpak/flatpak/issues/3173
This means sandboxes with dbus access can use portals etc, but they can't
talk to the main app, or impersonate it, but you can still use dbus and
well-known names to talk to them if needed.
It does mean however that if you use this, different sandboxes can see each
other on the bus, so be careful.
