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 :(
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.
