This commit checks if <revision>:.gitmodules exists in the repo before
calling git-show on it, so an error message doesn't show up in the
program's output.
It turns out that flatpak_dir_remote_fetch_summary can return TRUE,
yet leave summary_bytes NULL. The code further down does not deal
gracefully with summary_bytes being NULL, so error out early instead
of crashing.
We don't really need to create an origin remote if the same
uri is already there for an enumeratable remote, we can
just reuse that. Having multiple remotes for a single
repository just means we'll be downloading the summary file
multiple times.
Without this patch flatpak-remote-add (and anything else that uses this
section of code) segfaults if org.freedesktop.Flatpak.SystemHelper is
unavailable because it tries to cast an integer to a GDbusProxy.
An app id like org.domain.App-name is now allowed (dashes in the
last element), but blindly appending e.g. ".Locale" to these
for the locale extension will cause an invalid id.
In order to handle this we replace "-" with "_" in this case, which
should be fine as both are under the org.domain control which can
make sure there are no conflicts, and there is no requirement for
the id prefixes to exactly match.
This fixes https://github.com/flatpak/flatpak/issues/370
It makes no sense to allow you to install an application systemwide
if it only works for your user. However, its generally fine if to
install a per-user app that relies on a system-installed runtime.
In particular, this fixes installing system-wide extra-data apps where
we need the runtime to be system-installed to run the unpack script.
This works around:
https://github.com/ostreedev/ostree/issues/541
Which is causing us to not pull the entire set of objects, rather
stopping at the first object which is locally available. We fix
this by pulling twice in the subdirs != NULL case, which works
because the second time the new commit is marked partial and
we then pull the entire thing.
This means we will not end up with a partial download if something
goes wrong during the extra-data download, because we don't
commit the downloaded base files until everything is finished.
Note, this requires the latest ostree for this feature.
The g_key_file_load_from_bytes() function was added in GLib 2.50, and that
is too high as flatpak wants to support centos7/rhel7, which is now in 2.42.
We want to use the new transactioned detached metadata support,
multi-subdirs pull, and inherit-transactions on pull. Also, there are
some fixes we like.
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.
If you put a section like:
[Extra Data]
uri=https://sdk.gnome.org/gno%6De.flatpakrepo
checksum=ace1b504d32eefdf05b53044e6f785fe7886cc5657b5df034c3b9ac8e3aeb70c
size=1335
uri2=http://sdk.gnome.org/gedit.flatpakref
checksum2=d8baa109fb5fdcfe90379f3e93c5ab29f11772b42bf569bb3481e4aff489b0dd
size2=1472
name2=renamed.flatpakref
Then this information will be put in the commit object and the
later will be used when downloading the app.
Mario Sanchez Prada