Allow a snake-case in the app-id to convert to a '-' or '_' in the
DConf path to be considered similar enough for DConf migration purposes.
This allows the org.gnome.SoundJuicer app-id to migrate its
/org/gnome/sound-juicer DConf path.
F: Ignoring D-Conf migrate-path setting /org/gnome/sound-juicer/
This is no longer needed since a FlatpakRemoteState is passed in, which
ensures the repo exists. The similar call was already removed from
flatpak_dir_install().
Avoid shadowing variables that are already declared in a previous scope,
and make such occurrences compile-time errors. These are not functional
changes.
In a few places do related code cleanup.
A similar ostree PR is here:
https://github.com/ostreedev/ostree/pull/2195
This is primarily for test coverage ("design for test"): it will let us
pretend a temporary directory is the host for the purposes of testing
--filesystem=host-etc, --filesystem=host-os, and the os-release handling
from #3733.
It can also be used to build a bwrap command-line that will be used on
the host, while already inside a container, which will be useful for
Steam's pressure-vessel tool (which copies some of the Flatpak code).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Without this patch, the remote-info command will sometimes emit a
critical error "g_utf8_strlen: assertion 'p != NULL || max == 0' failed"
and print (null) for the "Commit:" field, since the commit doesn't get
initialized properly.
In case we need to authenticate for updates (in my test case i was
doing an OCI downgrade) we might need to download a commit object (or
in the OCI case a manifest json), so it did a request_required_tokens(),
but that noticed during the flatpak_transaction_normalize_ops() call
that the partial resolve to a particular commit actually was the
same as the local installed commit and marked op->skip = TRUE.
However, when we got back to resolving the op again we didn't actually
look at the skip, so it kept looping wanting (but never doing) auth.
The fix is to just directly resolve ops marked as skipped.
Runtimes also have appstream data - with description, license information,
and so forth, so we should extract the appstream data from the index
for refs that start with runtime/ as well.
The docs claimed that SDK runtimes are considered used even if there is
no app using them or runtime for which they are the SDK, but the
implementation does not match that.
We could change the implementation to always consider SDK runtimes used,
but that would be problematic because some apps use an SDK as their
runtime, and in that case the runtime would persist forever after the
app is uninstalled, instead of eventually being garbage collected by the
subsequent commits to this one.
When "flatpak uninstall --unused" is run, we don't remove unused
runtimes that are pinned. List them in the output so the user knows they
are being left installed.
This commit also adds new library API,
flatpak_installation_list_pinned_refs().
If a runtime is installed explicitly rather than as a dependency, pin it
so it doesn't get automatically removed when unused runtimes are being
removed. We do this because the runtime might be installed for
development or other uses.
This commit also rearranges some code in the mask and pin commands, and
adds a unit test.
As discussed here [1], we want a way to mark runtimes to be kept even
when they are unused by any apps and we are removing such runtimes.
Currently this is a command that can be run manually; a subsequent
commit will pin runtimes automatically if they are installed
independently of any app.
A unit test is included.
[1] https://github.com/flatpak/flatpak/issues/2639#issuecomment-662311756
flatpak doesn't yet use -Wswitch-enum, but perhaps it should at some
point. Now that FLATPAK_FILESYSTEM_MODE_NONE is a member of the enum,
it should be handled; and if we're doing that, we might as well make
the same function fully responsible for it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Historically we didn't accept them, but there's no real reason why not.
They're normalized to the form in which earlier Flatpak releases would
want to see them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Making it an equivalent of --filesystem=host would be misleading,
because it wouldn't do what you'd think it does: host mounts some host
system directories in their usual places, but others below /run/host.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Paths containing ".." are rejected: they're almost certainly a
terrible idea.
Paths containing "." or multiple slashes are syntactically normalized.
This assumes that nobody is going to use "--filesystem=/foo/bar/" to
mean "make /foo/bar available, unless it's a non-directory, in which
case fail".
Signed-off-by: Simon McVittie <smcv@collabora.com>
When we're talking about a "mode", sometimes we mean a
FlatpakFilesystemMode, sometimes we mean a FlatpakFilesystemMode that
must be strictly greater than NONE, and sometimes we're willing to
accept the FAKE_MODE constants too.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This gives us the ability for the parse function (the former verify
function) to carry out a normalization step as well.
Signed-off-by: Simon McVittie <smcv@collabora.com>
https://systemd.io/CONTAINER_INTERFACE/ describes a generic way to tell
programs and libraries that they are running in a container: set
pid 1's ${container} to the name of the container manager in lower case,
and populate /run/host/container-manager with the same string followed
by a newline. Let's be nice to application code by doing that, instead
of requiring it to look at /.flatpak-info.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This allows OSTree to avoid re-checking the `summary.sig` for freshness
once per pull in a transaction, since flatpak has already done that.
This avoids latency in a transaction (especially on high latency or
lossy network connections) and avoids the potential race condition of
the `summary` file changing on the server part-way through a
transaction.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
`FlatpakRemoteState` already caches the parsed `GVariant` form of the
summary, but it will be useful (in the following commits) to also have a
pointer to the `GBytes` which backs that variant. The `GBytes` will be
passed into OSTree in the following commits, to allow it to avoid
unnecessarily re-downloading the `summary` file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When uninstalling a single app (an example of a transaction which is
entirely local-only), there’s no need to update the repository metadata
beforehand — but the code was doing that.
This avoids an unnecessary download of the `summary.sig` file (or other
repository metadata, depending on what’s out of date) when uninstalling.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
`flatpak-dir.c` supports two caches for `summary{,.sig}` files: one in
memory (per `FlatpakDir` instance) and one on disk (shared between all
users of the repository). Clarify in this comment which one is being
referred to.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Adding brackets makes it a little more obvious that it’s 5 minutes, and
less likely that operator precedence where the macro is used will result
in the wrong value being calculated.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Cache hits didn’t result in the cache entry’s timeout being extended,
and timeouts didn’t result in the entry being removed from the cache to
free up resources (even though it would never be returned as a cache hit
again).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This commit is a follow-up for the commit "dir: Validate locally
configured collection IDs". Whereas in that commit we validate the
collection ID in flatpak_remote_state_fetch_commit_object(), here we do
it in _flatpak_dir_get_remote_state(), since fetch_commit_object() is
not called on the code path normally taken for a transaction (only if
try_resolve_op_from_metadata() fails and in other niche scenarios).
This should ensure that if someone erroneously sets a collection ID on a
remote, the error will be caught quickly. It also helps the eos-updater
unit tests pass.
Some things could need to run e.g. i386 code in apply_extra (for
example #3742). In this very limited context (almost everything is
read-only) this seems pretty secure.
We could require the app to specify a multiarch pemission to allow
this, but such permissions only really make sense for an app, and
extra data is often used for other things like runtimes and
extensions, that seems a bit weird. Lets just enable it always.
These are system dbus calls that could potentially be somewhat slow
and its unlikely that the local config changes during runtime of the
session (because the desktop really needs a restart to pick up a new
locale). Also, if there are any issues with these (such as #3755) each
call will be the 25sec dbus timeout, which is not great.
Fixes https://github.com/flatpak/flatpak/issues/3792
Currently when searching for a remote to provide the runtime for an app,
we search remotes in priority order. This commit makes it so we search
the remote providing the app before others with the same priority, and
otherwise still search in priority order. This means for the common
case where every remote has the default priority of 1, the app's origin
will have the first chance to provide the runtime. This behavior seems
logical, but the impetus for this change was also to keep a unit test
passing in eos-updater[1] after a port to FlatpakTransaction.
Originally the eos-updater unit test was written to prioritize the
origin remote regardless of the priorities on any other remote, but
during code review it was decided to let higher priority remotes stay
above the app's origin.
In practice it's usually true that only one remote provides a runtime
and priorities aren't set at all, so this is an edge case that probably
doesn't come up much.
A unit test and documentation updates are included.
[1] eede0a8b9c/tests/test-update-install-flatpaks.c (L1919)
In applications with --filesystem=host or --filesystem=host-os, the
library directories in /run/host/usr and /run/host/lib* can be used
like a sysroot to inspect the host's library stack, regardless of
whether the host system has undergone the "/usr merge" or not. This is
particularly relevant for Steam's pressure-vessel container tool,
which imports graphics drivers from the host system, or for potential
future work on using host graphics drivers via libcapsule in Flatpak
apps.
The original implementation of this feature assumed that the /usr merge
always creates symbolic links /foo -> /usr/foo or /foo -> usr/foo, for
some value of foo. However, Arch Linux uses a variation of multilib
in which /usr/lib contains 64-bit libraries, and has a non-matching
symbolic link /lib64 -> usr/lib (instead of a chain of symlinks
/lib64 -> usr/lib64 -> lib). Similarly, Arch uses /sbin -> usr/bin
and /usr/sbin -> bin, instead of a chain of symlinks
/sbin -> usr/sbin -> bin.
This led to Flatpak ignoring the symlink and treating it like a directory,
so the host /usr/lib would be bind-mounted on both /run/host/usr/lib and
/run/host/lib64. This is *mostly* equivalent, but whether a directory
is a symlink or a real directory sometimes matters, for example when
evaluating relative symlinks that contain ".." components; so try harder
to preserve symlinks as symlinks.
Fixes: 08d65c54 "exports: If --filesystem=host, provide /run/host/lib etc."
Signed-off-by: Simon McVittie <smcv@collabora.com>
This made its way into the Debian symbols file, but looks like it was
never supposed to be exported.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
clone() is a mad syscall with about 4 different argument orders. While
most of them agree that argument 0 is flags, s390 and s390x have the
flags argument second - A0 is the child stack pointer there.
[smcv: Add an explanatory comment; also test __CRIS__ for completeness]
Bug-Debian: https://bugs.debian.org/964541
Bug-Ubuntu: https://launchpad.net/bugs/1886814
Signed-off-by: Simon McVittie <smcv@collabora.com>
Currently if the user configures a collection ID on a remote which is
incorrect, either because it doesn't match the one configured server
side or because the server doesn't have one configured at all, Flatpak
will not notice the issue and happily still pull from the remote. This
is new since 1.7.1; before that such a problem would be caught because
the server wouldn't provide the ostree-metadata ref for the configured
collection ID.
This commit catches such errors by checking commit metadata, as we
already do for the ref binding metadata. Otherwise such a mismatch would
prevent successful offline distribution of the apps/runtimes provided by
the remote.
The impetus for this is to keep an eos-updater unit test passing with
Flatpak 1.8.x:
"/updater/install-flatpaks-pull-to-repo-error-if-collection-id-invalid"
Don't leave options set on the remote in one of the unit tests. If
something should be set for every test it should be done in
global_setup(). This commit also changes the FlatpakRemote
implementation to allow unsetting title and default branch.
When --device=all is *not* passed to Flatpak, --dev is passed to bwrap,
which causes it to use an intermediate user namespace to mount devpts
because it can only be mounted as UID 0. Therefore, when expose-pids
is used, Flatpak will pass both --userns *and* --userns2 to handle
the presence of the intermediate namespace.
However, when --device=all *is* passed, there is no intermediate
namespace. Thus, setns(userns2) will fail with EINVAL. In order to
handle this, --userns2 is no longer passed if the namespace is
identical to that passed via --userns.
Fixes#3722.
We already verify that the ref is not installed on add_ref(), so we
did check for "user error". If the transaction either raced with some
other process, or the install from the install-authentitcator signal
that should not be treated as an error.
Ensure we normalize ops before requesting authentication so we
can trust the op->skip value to be set for no-op updates (which
don't need authentication).
