Don't allow adding access to things like ~/foo xdg-foo/bar or similar
things just because you used to have home access, because such files
may be outside the homedir (for instance, if they are symlinks or configured
via xdg-user-dirs).
In flatpak-builtins-build-commit-from.c we call flatpak_repo_collect_sizes()
without initializing the passed in download size to zero, which mean
we sum with sizes with some random value as the start.
This is fixed by having flatpak_repo_collect_sizes() always initialize
the counters to 0 at the start.
Fixes https://github.com/flatpak/flatpak/issues/3362
This new permission exposes the host /dev, which is normally not visible
even with --device=all, as it is not really a device node but rather
a bunch of shared memory blocks available on the host.
This access is needed by jack, as explained at:
https://github.com/flatpak/flatpak/issues/1509
Long term I think a better solution for pro audio (like pipewire) is
a better solution, but for now we should at least allow jack apps to work.
Initialize the related-refs array with empty GPtrArray so that if
the remote has 'url= ' (for e.g., in case of flatpak bundle's remotes),
a empty array is returned instead of NULL.
(NULL mostly implies a operation has failed and error is set)
Also, this syncs the implementation of `if (*url == 0)` with
that of flatak_dir_find_remote_related_for_metadata function.
We rely on broadcast signals for authenticator replies rather than unicast
as these are not filtered by the sandbox (due to them being opt-in by the
receiver).
Actually this already worked fine in the flatpak side as the generated
code already subscribes to the signals, this just switches the internal
authenticators (test and oci) to using the new way to emit signals.
If the local config for the remote specifies an authenticator name
and that is should in installed, automatically add it to updates
in a transaction.
The local config can either be manually configured, or automatically
from a flatpakrepo file or the summary metadata.
flatpak build-update-repo now lets you modify the
autenticator-name/install/options keys, and these are migrated to
the summary/metadata during update.
When we call flatpak_dir_update_remote_configuration we pass it
the pre-existing FlatpakRemoteState (if known) and also take into
account if it actually changed anything before blowing away the
cached remote state.
We also ensure we have metadata in
flatpak_dir_update_remote_configuration_for_state to ensure the passed
in optional state has metadata in it.
With the latest ostree that enables the chaining of progress the
testsuite broke because we were not getting changed events. Looking
into this the reason seems to be that when we run the
ostree_async_progress_finish() on the chained progress it is marked
as dead, which causes ostree_async_progress_copy_state() to not copy
any data when called from handle_chained_progress().
The fix is to copy the content manually before calling the finish().
Also, the entire callback chaining system seems wildly
overcomplicated, so I simplified it by relying on the existing change
notification of OstreeAsyncProgress.
For apps that run in the backgroun without interaction, pass this info
to the authenticator.
This can be used to avoid sending unnecessary webflow or basic auth
request, but those were already silenced by FlatpakTransaction. However
this also allows the authenticator to avoid doing direct, native user
interaction which was otherwise not avoidable.
These should only be called at the leaf level, because the first
time its called no more change events will ever be sent on that
progress, which is not right possibly in the middle of an operation.
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.
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
