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.
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.
Show active and background state, based on information obtained
from the background portal backend about which apps have (active) windows.
This currently tries all known portal backends in turn. It might
be nicer to have a portal frontend api to query this, or to find
out which backend to talk to.
