Currently Flatpak only supports extensions which come from the same
remote as the thing being extended; for discussion on this see
https://github.com/flatpak/flatpak/issues/861
However in general it isn't clear from the metadata what remote provides
an extension. For example com.endlessm.apps.Platform//5 defines the
extension org.freedesktop.Platform.VAAPI.Intel (inherited from
org.freedesktop.Platform) which can be found on flathub not eos-sdk. So
we don't want to add an extension refspec to the transaction if the
current remote is not the one that actually provides it. In
flatpak_dir_find_remote_related_for_metadata() this invariant is
maintained because we check if the ref exists in the remote before
adding it with add_related(). However in
flatpak_dir_find_local_related_for_metadata() we check for existing
deploy data but omit checking that the deploy origin matches the origin
passed in, and in that case can accidentally add an incorrect refspec to
a transaction. So this commit adds the missing origin check.
One way to reproduce this issue is with this command, having both the
Endless platform and the VAAPI extension already installed:
$ flatpak update --no-pull com.endlessm.apps.Platform//5
Looking for updates…
error: Refspec 'eos-sdk:runtime/org.freedesktop.Platform.VAAPI.Intel/x86_64/1.6' not found
This issue also affects GNOME Software which does a no-deploy
transaction followed by a no-pull transaction (this issue occurs in the
latter) and is treated as fatal causing updates not to be applied.
However it only happens in some niche circumstances, because
flatpak_transaction_add_op() will only use the first remote passed to it
if called more than once for the same ref from different remotes. This
is normally fine; refs generally only come from one remote. But it does
mean this issue only occurs if the extension in question was not already
added to the transaction with a correct origin.
Instead of relying on the runtime tzdate we now always expose the host
/usr/share/zoneinfo in that location and make /etc/localtime a regular
symlink to it. This means applications that parse the content of the
localtime symlink will work, and additionally it means that we're
guaranteed that the host configure timezone exists (and works with)
the tzdata in the app.
This unfortunately means we no longer make the localtime an indirect
file via the session helper, and thus that localtime configurations
are static over the lifetime of an app sandbox. However, I don't
think there is a workable solution to this.
This fixes https://github.com/flatpak/flatpak/issues/3338
We only want the run dir to be overridable in unit tests because we
depend on it being /run/flatpak in flatpak-create-sideload-symlinks.sh,
so don't mention it in the flatpak man page.
Currently we only support links in /var/lib/flatpak/sideload-repos,
/run/flatpak/sideload-repos, etc. to be actual ostree repos, but this
commit makes it so you can also link to the root directory of a USB,
and Flatpak will check the subpaths "ostree/repo", ".ostree/repo", and
".ostree/repos.d" for compatibility with "flatpak create-usb". This will
allow the logic in the following commit to be much simpler, where we're
linking to hot-plugged drives in a script run by systemd.
Note that we still only allow actual repos in the other places where a
sideload path can be specified, such as the --sideload-repo CLI option.
If a transaction requires to install an authenticator before it can
continue this signal will be emitted, allowing you to create a new
transaction to install the required authenticator.
Per the conventions around using GError, failure code paths must set a
GError if a non-NULL pointer is passed for that parameter. And in case
the error is left unset it leads to an assertion failure (and crash) in
flatpak_installation_list_installed_refs_for_update(); see
https://github.com/endlessm/flatpak/pull/224
So add assertions to the failure code paths in
flatpak_transaction_real_run() to catch such mistakes earlier and make
the resulting crash stack trace more useful, since it points closer to
where the problem is. This could be implemented with the "goto out;"
idiom but I don't think that's a good idea in this case because in the
latter half of the function we have to do some cleanup before returning.
Currently in the FlatpakTransaction implementation we add dependencies
and related refs for each operation in the transaction regardless of if
it's skipped or not. This is an issue in the case of an
end-of-life-rebased ref because in that case if the user agrees a new
install operation is added for the new ref, an uninstall operation is
added for the end-of-lifed ref, and the update operation for the
end-of-lifed one is marked as to be skipped. Then the dependencies of
the end-of-lifed ref get added to the transaction and ultimately after
all the sorting is done you end up with duplicate operations. In the
case of having org.gnome.tetravex installed, "flatpak update" yields a
transaction which uninstalls org.gnome.tetravex.Locale twice and errors
out on the second time (in addition to uninstalling org.gnome.tetravex
and installing org.gnome.Tetravex and org.gnome.Tetravex.Locale).
Fix the issue by skipping operations marked as to be skipped when adding
dependencies and related refs to the transaction.
Alternative fix to https://github.com/flatpak/flatpak/pull/3389
If an app has PulseAudio access, also allow direct ALSA device access.
The practical permissions of ALSA and PulseAudio access are
essentially the same (in fact, its possibly less damaging to have
direct device access as bugs in pulseaudio could allow sandbox
breakout that wouldn't be possible with deivce access).
We could add a separate option for this, but since they are
essentially the same, and since both are not the end goal (which is
using portals and PipeWire for audio), seems like unnecessary churn in
apps and code.
This is useful if to avoid changing the no-interaction of the whole
FlatpakInstallation. Also, having this per transaction lets us
clean up the code in FlatpakQuietTransaction a bit.
The terms whitelist and blacklist are hurtful to some people, and per
our code of conduct Flatpak is an inclusive community. Replace them with
allowlist and blocklist which are also more clear. This terminology
change is being implemented more broadly in the software industry; see
e.g. https://go-review.googlesource.com/c/go/+/236857/
While creating the ld.so.cache file we write to a temporary file
and then rename it to the final reused cache location only when it is
completely finished.
This solves two issues:
a) New app instances never end up with a cache that is not finished
b) Two app starting at the same time don't both try to write the
cache in the same place, failing like in #3029.
This is an alternative fix to https://github.com/flatpak/flatpak/pull/3617
If the magical io.github.containers.DeltaUrl label is set in the
index, then try to download this to use as the delta manifest for the
image. This allows servers to store deltas outside the registry
itself. The label is propagated to the xa.delta-url metadata in the
generated "fake summary" for the remote, and read back on pull.
Note that the delta manifest layers descriptor will need to have a
"urls" key where it references the blobs if the blobs are also not
stored on the registry.
If the specified manifest doesn't exist or doesn't apply to the target
image we fall back to resolving via the _deltaindex tag.
Call flatpak_remote_state_ensure_summary() before dereferencing
RemoteState->summary to return an error instead of crashing if
downloading the summary failed.
When mirroring to a local OCI dir we apply deltas and generate
uncompressed layer blobs instead of regular blobs. Then we pick this
up on the system-helper side.
This is a version of flatpak_oci_registry_apply_delta() that generates
a new blob in a local repo, rather than a temporary file. This is used
when mirroring using a delta into a child oci registry for system-helper
use.
When we create a system child registry we also set the current token on
it. This is not used directly in the client, however its saved in a
file called .token and re-read in the system-helper, allowing it to
also do the remote registry operations it needs to verify the child
registry.
We typically only load by digest id, resolving tags in other ways.
However, we need to load the _deltaindex tag by tagname, so support
this when possible.
It turns out that libarchive doesn't always read the entire file until
the end if it can figure out that the tarfile ended. Normally this is
not hit, because the decompressor reads all the input, but for
uncompressed tarfiles (like those from applied deltas) this is
important.
