We pass FLATPAK_RUN_FLAG_NO_A11Y_BUS_PROXY when running the
sandboxed apply_extra_data script, because otherwise we run into
a crash due to the lack of an .flatpak-info file (and also, because
it is not needed).
Icons are really only a bunch of pngs, and the icon theme specification
has been stable since forever and never broke ABI. So, exposing the
host fonts should be pretty safe, comparable to the fonts that we
already expose.
This ends up being kind of important since a lot of things pick up the
icon theme from the host. In particular, it means that libXcursor can pick up
the correct cursor icons for the current cursor theme.
In case the summary file is GPG-signed, we already have other better
ways of verifying expectations around the installed ref.
If the deployed branch does not match xa.ref, simply warn instead of
aborting.
Based on a patch by Dan Nicholson <nicholson@endlessm.com>
Many flatpak commands only work on *.flatpak or *.flatpakref files, so
the bash auto completion showing every file is distracting and
unnecessary. This commit makes flatpak only show relevant files when
possible by using the "-G globpattern" compgen option.
As discussed in https://github.com/flatpak/flatpak/issues/975, it is
better to have the temporary repos for installing into the system repo
outside the home directory. This helps in the case when the home
directory is on a different filesystem. In particular it is more
likely to be on the same partition as the system repo in /var/lib.
There are multiple advantages if the two repos are on the same filesystem:
* Less chance of filling up the space on a filesystem that is not
the final target.
* It is possible to use fs operations like reflink or copy_file_range to
optimize the copies from the temporary repo to the system repo.
* The home directory is more often on NFS or other weird filesystem
type.
If a flatpakref has this set, for instance:
SuggestRemoteName=gnome-apps
Then flatpak install will ask if you want to configure
this as a "real" remote, rather than an origin remote (which
will only install that app).
This is useful when creating flatpakref files for remotes
that have multiple applications in them, such as e.g. flathub
or the gnome nightly builds. However, it should not be
set of one-application repositories.
* Get language list from AccountsService's dbus
Fixes issue #950
When xa.languages is not set in repo config, system installs will
get language list from AccountsService's dbus.
Lookup extra-data files as
~/.local/share/flatpak/extra-data/SHA256/FILENAME, Similar to files
downloaded in the .flatpak-builder directory.
For now, if a corresponding file exists, assume it's the full download
and read bytes from it. Then proceed to do the same checks as for the
bytes downloaded by Soup.
In the future this directory could be used to support resumed downloads
by storing partial downloads.
Factor out the pull options which are common to the collection-based and
non-collection-based code paths. This should make the code a little
easier to read.
This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When the summary file is updated, it’s kept in a local cache, so that
parts of flatpak can refresh it at will without network impact. We need
the same for the ostree-metadata ref, which stores the repository’s
metadata when collection IDs and P2P are used.
Implement that by comparing the checksum of the ostree-metadata ref from
the summary file and from the local repository. If they differ, it’s
almost certainly going to be because the summary file is advertising a
more up-to-date ostree-metadata ref, which we should pull. If they don’t
differ, there’s no need to try and update the ref. Therefore, this
chains off the caching of the summary file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add a sanity check and error message which prevents pulling the
ostree-metadata ref (the repository metadata) unless GPG verification is
enabled, as it needs to be signed to be trusted.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This isn’t really used internally, but will be used by gnome-software
for when it configures new flatpak remotes.
This is new public API, but is only declared if compiling with
--enable-p2p.
Includes some basic smoketests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to provide a transition path for repositories to add collection
IDs to themselves and propagate those collection IDs to clients’ remote
configurations, add another repo config key which controls whether the
repository’s collection ID is published. If xa.collection-id is set in
the repo’s published metadata, the client will update its configuration
to the given ID — but only if no ID is set already. This is a one-time
transition to prevent malicious repositories from remotely changing the
user’s configuration to associate their remote with a well-known
collection ID they don’t own.
Add a test for this.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
To allow staged deployment of collection-ID-based repositories,
introduce the code to update a local repository configuration to add a
collection ID to it, based on updated metadata from the remote (as is
currently supported for other configuration keys).
As a security measure, this only allows updating the collection ID from
an empty to a non-empty value. We do not allow collection IDs to be
renamed (or a malicious repository owner could bypass the user’s manual
verification of the collection ID by changing it after the user has
configured an unrelated remote).
The idea is that most repositories should remain without collection IDs
for now, and use this mechanism to set their collection IDs in future,
once the functionality is more stable.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than silently ignoring them. Note that invalid configurations
are distinct from missing configuration keys.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It can return FALSE with an error set, or FALSE without one set, which
indicates the key was not found.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When pulling from a local, untrusted repo (i.e. one which the user
downloaded into, and we want to pull into the trusted system repo),
verify the collection ID and ref bindings in the commit metadata for
each commit.
This is something which is normally done by libostree, but since we’re
rewriting the commit manually, we’re bypassing that part of the pull()
code path.
This is an inlined version of the check from verify_bindings() in
libostree.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add support for collection IDs to the code which finds and pulls
related refs and other extensions.
Currently, related refs must have the same collection ID as the parent
ref — this is the most likely scenario anyway. In future, it should be
possible to extend the code to support pulling related refs from other
collections.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Also add collection and ref binding metadata to the generated appstream
commits, so they can be verified when using unsigned summary files.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We need to consistently handle the case where the collection ID is set
to the empty string (and treat it the same as if it were unset). Best
done in a helper function.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Newer repositories will store metadata there, rather than in the summary
file (although the summary file will still be updated where possible for
backwards compatibility).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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>
It will be used by builtins-repo-update in a following commit to allow
updating the collection ID for an upstream repo.
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>
This adds support in flatpak-dir.c for using the new libostree API for
finding remotes dynamically for a given set of refs, if flatpak is
configured with --enable-p2p.
The new code paths are only taken if the repository is configured with
a collection ID set.
These changes by themselves aren’t sufficient for full P2P support, as
all the infrastructure for downloading summary files and finding refs
needs to be modified in the following commits.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This includes a change in how ostree reports missing gpg signatures
which makes the test-suite pass. Additionally that change requires
us to change how we detect such missing gpg signatures in one place.
We could try to support both versions, but the easiest fix is to just
require the latest ostree.
flatpak_decompose_ref() can fail, but in this situation we know it won’t
since find_matching_refs() checks it for us and hence guarantees that it
only returns decomposable refs. Add some assertions to make this clearer
and to shut Coverity up.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Everywhere else that index->manifests is used, it’s checked for being
NULL beforehand, which probably means that, sometimes, it might be NULL.
Let’s check that here too.
Coverity issue: 1452432
Signed-off-by: Philip Withnall <withnall@endlessm.com>
