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.
Instead of separate "origin", "subpaths" and eventually "installed-size"
files we store a single (extensible) gvariant with all this info, which
means we need to seek less to get it.
Also, we move this file into the deploy dir as some of the data
differs for each deploy, and that way we can rely on the the active
symlink to make the update atomic.
Mario Sanchez Prada