In order to eliminate some race conditions around updating the
summary{,.sig} file on the server, and to decouple signing the summary
from signing commits, and to support peer to peer mirrors of content
from multiple upstream collections: add support for unsigned summary
files.
This relaxes the requirement for gpg-verify-summary=true iff
collection-id is set in a remote’s local configuration. It depends on
some pending libostree changes to verify the ref for each commit using
the commit’s signed metadata. See
https://github.com/ostreedev/ostree/issues/983.
Metadata storage has moved from the summary file to a new
ostree-metadata well-known branch on each repository, since this can be
signed for each update and for each collection separately. If the
collection-id is set in a remote’s local configuration, flatpak will
retrieve all repository metadata from this branch rather than from the
summary file. If collection-id is unset, it will ignore this branch and
continue to use the summary file, which will continue to be updated (and
externally signed as summary.sig) for backwards compatibility.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Search for updates on peer to peer sources as well as the internet in
check_for_updates(), and pass the resulting OstreeRepoFinderResult array
to the pull() calls, so a consistent set of checksums are pulled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously they weren’t getting distributed unless the system helper was
enabled at configure time for distcheck. They should be distributed
unconditionally so the user can choose whether to enable the system
helper when they call configure.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The GLib logging framework automatically appends a \n to messages, so it
doesn’t need to be added by callers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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.
