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>
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>
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>
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>
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>
If xa.languages is not explicitly set, only use the current locale
if we are installing something per-user. For system-wide installs,
default to installing all locales.
Read an xa.languages key from the [core] section of
the repo config to determine which subpaths to install
for Locales. This lets us maintain a list of system
languages without inventing a new file in /etc, and
will also work for alternative install locations.
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>
This makes it easier to avoid typos, and also makes it easier to see
what groups and keys are in use. In the header file, they are
clustered according to the group in which the keys are used.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This will slightly simplify some later refactoring. It makes no real
difference to the function’s behaviour at the moment.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This was accidentally introduced in a8ad3927 in advance of the LAN/USB
changes from PR #884 which will actually use it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This will make it easier to add another version in upcoming commits
which gets the updated configuration from another source (an
ostree-metadata branch).
This commit introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There was already a convenience method for this,
fetch_remote_summary_file(), but it wasn’t used uniformly throughout the
file. This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There are several places which query keys in the metadata in the summary
file. Factor out a common function to do that, and write it in such a
way that it could be extended to read the metadata from somewhere else
in future (the plan being that metadata will move to an ostree-metadata
branch rather than the summary file).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Unless forced by the FLATPAK_OSTREE_REPO_MODE env var, we default cache
repos to bare-user mode. Otherwise it can lead to permissions problems
because, e.g. if the system repo is configured as a "bare" repo, then
the cache repo will be too and this will lead to fchown calls even if
the user is non-privileged.
With the latest ostree, pull --mirror does not mirror the
summary for partial pulls, so system-wide installs fail. We
fix it by manually updating the summary.
This uses the new libostree APIs that landed recently to ensure
that we reject any files with mode outside of `0775` for system
helper pulls, and we also mask directory modes during checkout.
However, this does *not* fix up any already downloaded content.
For that, one could uninstall/reinstall; or a future patch could
do a one-time fixup pass.
Note that I am not aware of a way for flatpak applications to escalate their
privileges directly with this flaw; the bubblewrap `PR_SET_NO_NEW_PRIVS` turns
of setuid. However, in combination with code execution on the host via another
mechanism (e.g. unsandboxed app), a setuid app injected could be used to gain
full host privileges.
At this time we're not aware of any flatpak content exploiting this issue.
Closes: https://github.com/flatpak/flatpak/issues/845
This goes into a big old topic about Unix homedir permissions; it's not uncommon
for general purpose OS vendors to have homedirs be 0755. In that case,
applications need to ensure confidentiality for data requiring it (classically
e.g. `~/.ssh`) by making the dirs `0700`.
While most of the data in the flatpak per-user dir probably isn't confidential
(debatably) we have a different issue; if container content includes suid or
world-writable files/dirs, then having that data accessible to other users
is obviously problematic.
We're going to fix flatpak/ostree to not create files with those modes
to begin with, but this simple fix closes off the attack route for
the per-user directory.
A different fix will be necessary for the system-wide repo.
See: https://github.com/flatpak/flatpak/pull/837
Looking at the git history, this code originally retried on
some cases for pull, then stopped doing so, then a later commit
added code after it, which made it incorrect.
Just do an early return again and drop the `res` variable.
Writing things on the console every 100msec doesn't really
make any sense, the progress bar is not finegrained enough
and you can't read the text that fast anyway.
Flatpak relies on OSTree to report the progress, and
OSTree's progress report frequency fallbacks to 1 second.
Recently, however, OSTree received support for setting
custom update frequencies. Since it relies on GVariant
options, if the user has an older OSTree, it'll simply
be ignored.
This patch, then, makes Flatpak report progress every
100ms rather than the default value of 1 second.
flatpak/flatpak#609
We only allow globs, not magic matches, and we drop the glob
priority to a very low level (weight=5) which means that its
hard for app-installed mimetypes to override the system installed
ones. That should make exporting mimetypes pretty safe.
