We download the summary and send it to the system helper, it verifies
the checksum and applies the changes, with the same polkit permissions
required as for an app update (i.e. typically none).
This allows us to update metadata automatically, without permission
requests.
If EXTERNAL_INSTALL_DIR wasn't defined (which is likely, since nothing
in the build system does), then we would tell the system helper
to search /exports/share, which is not Flatpak's territory
(but is a semi-commonly-used path for site-specific NFS shares,
which might have contents that are inappropriate to search here).
Installations that do define an external installation directory
(Endless OS?) can easily override the Environment to include it
by placing a drop-in in
/etc/systemd/user/flatpak-system-helper.service.d/external.conf
or similar.
This change fixes GCC compiler warnings where a cleanup function was
specified on an uninitialised pointer, which in the view of GCC could
result in an errornous free of uninitialised memory, if the functions
that initialise them do not return NULL.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
Newer versions of dbus support stateless directories, and many distributions
now use /usr/share/dbus-1/system.d for the vendor configuration files, as
opposed to the legacy /etc/dbus-1/system.d directory.
To enable this, we add a new --with-dbus-config-dir option to control the
configuration directory, whilst retaining backwards compatibility for those
still using older versions of dbus.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
If the bundle contains an origin link we can now install related
things from it, such as locale data.
You can also build the bundle with --runtime-repo=URL, where the url
points to a flatpakrepo file for a repo with runtimes. This works
similar to the RuntimeRepo= feature in flatpakref files.
There will be a way to retrieve the list of all system installations,
not just the default one, so we rename this for backward compatibility.
Note that some (most?) of the places where we will be now using this
renamed function will likely have to migrate to using specific system
installations, but we don't have the necessary APIs yet so we do this
as an initial step to all the incremental changes that will come next.
If the downloaded app has a "xa.extra-data-sources" property in
the commit, then we download these as part of the pull operation
and store the result in the commitmeta object in the repo.
Then during deploy we look at the xa.extra-data-sources properties
again and extract them from the commitmeta into /app/extra
in the app, and afterwards we run /app/bin/apply_extra in a minimal
sandbox that has read-write access to /app/extra, but nowhere else.
There are some complexities:
We need to re-verify when extracting, because the commitmeta is not
really signed, so we could have picked up random stuff there
from the upstream repo, or from an attacker misusing the system-helper
local install codepath.
When using the system-helper the pull will fail if the commitmeta
is to large, so we have some code in this case to manually transfer
the larger commitmeta on the side to the local-pull code.
Creating a policykit proxy was causing timeouts for me for unclear
reasons when running under the tests. But we're not using policykit at
all during the tests, so we can just avoid this call completely.
Drop the intltool dependency that was recently added, and use
upstream gettext and its its features for the same purpose.
Note that polkit currently does not install .its files (I've
sent a patch). Until that is in place, this change has the
effect of installing the untranslated policy file.
Due to an issue with ostree (https://github.com/ostreedev/ostree/pull/362)
applying non-from-scratch deltas fail when using parent_repo such as
in the system-helper case. We fix this temporarily by disabling the
use of deltas for that case.
For a local (file:// uri) remote, do an (untrusted) direct pull instead
of pulling into the users cached repo first. This way we do less copies,
as well as guaranteeing the source of the data. The later means its
mostly safe to also allow this for non-gpg signed remotes.
Alexander Larsson