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.
This warning is meant for interactive use, and as per #3316 it often
breaks non-interactive stuff like scripts. So, we only warn on ttys,
and only on normally interactive operations like run, install and update
to avoid warnings in cases like building (where XDG_DATA_DIRS is not
needed) or information gathering things like e.g. flatpak info.
It often happens that people use --user or --system or --installation
and get a "Remote not found" error message, because they don't
understand that remotes have to be defined separately in each
installation. Make the error message more helpful by pointing out when
one of those options was used.
Fixes https://github.com/flatpak/flatpak/issues/3296
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.
