This is a g_autoptr version of OstreeAsyncProgress that also
calls ostree_async_progress_finish() before being freed.
This should be used in all "leaf" functions that creates an asyncprogress
to avoid leaking any idle change idle sources. Using a auto* means
some code can be cleaned up to avoid goto out style handling for this.
Also, this adds a missing finish() in
_flatpak_dir_fetch_remote_state_metadata_branch().
If we're using a chained progress, it will be unchained
in the destroy notifier. However, it was newly constructed so we
need to also unref it or we'll leak it.
This also makes some minor cleanups:
1) Centralize version checks to one place and replace users
with #ifdef FLATPAK_DO_CHAIN_PROGRESS which makes it
easier to read and to test the fallback.
2) Make flatpak_progress_chain return a FlatpakAsyncProgressChained
to make it clear the two needs to be paired.
It turns out ostree_repo_open() overwrites custom cachedir_fd we've
set for the system using installation in case the object dir is
writable. Normally this is not a problem, because it is not writable,
but in the testsuite is *is*, which means the initial cachedir fd is
leaked, as well as using the wrong dir for summary caches during the
tests.
We work around this by setting the cache_dir after a successful
ostree_repo_open().
This fixes#3303
This is a slightly incompatible change, as we now only support
oci images generated with (what was before) build-export --oci-use-labels.
However, there are not a lot of OCI implementations in the wild, and
we can modify the ones in use to ensure there are labels (and
annotations if needed for older flatpak clients).
This also removes the --oci-use-label option from build-bundle --oci as
this is now the default.
flatpak_get_timezone () tries to access /etc/timezone if /etc/localtime
isn't a valid symlink, but gets the name wrong. Fix it.
Found by code inspection.
It turns out d91660fe2a accidentally
broke the inheritance of non-stdin/out file descriptor into children
of "flatpak run" which broke the fd passing in the flatpak spawn portal.
This reverts that, allowing all fds not specifically marked as CLOEXEC
by other means to be inherited into the child.
Fortunately the regression was not in any stable release.
We used to store all options as a gvariant format string like so:
xa.authenticator-options={"key1": <"a string value">, "key2": <"foo">}
But nobody really knows how to write these things, so now we
have instead multiple options with a common prefix that
get collected like so:
xa.authenticator-options.key1="a string value"
xa.authenticator-options.key2="foo"
This means all options are strings, but most options are, and
if not you can just parse them.
We look in these, in this order:
~/.config/flatpak/oci-auth.json
/etc/flatpak/oci-auth.json
/run/user/$uid/containers/auth.json
/run/containers/$uid/auth.json
~/.docker/config.json
The first two are flatpak specific, and the others are what
skopeo and docker use.
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.
It is confusing if we explicitly have to specify
the <> GVariant wrapping with --data, but
flatpak permissions strips it when displaying the
result.
Make it transparent by auto-applying the wrapping,
so what you need to pass to --data is the same
as what flatpak permissions shows you.
Don't skip entries that have no permissions.
I was wasting some time to track down why my
permission-set --data command wasn't working,
when in reality, the permissions command was
just not listing the entries I was adding :(
