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.
While flatpak carefully doesn’t expose any OSTree symbols in its C API,
it does sometimes return GErrors with the domain `OSTREE_GPG_ERROR`.
Applications can happily link against flatpak and receive such errors,
but won’t be able to understand them without also linking against
OSTree.
OSTree is a hard dependency of flatpak, so we might as well move it to
`Requires` rather than `Requires.private` to ensure that clients link
against it.
See https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/336/diffs#note_650999
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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.
