Both collect exports and flatpak_export_dir recursively export the
directories in their respective directory lists. Because of this,
including share/metainfo/releases when share/metainfo is already in the
lists is unnecessary and can cause exporting to fail because of
duplicate files.
Signature downloads can use a different URL from the OCI registry
itself, so they must not depend on TLS options left on the reused curl
handle. Resolve certificates for the URI and pass them explicitly.
Annotating the return as (transfer full) causes bindings to additionally
unref each element on array free, resulting in a use-after-free.
Change the annotation to (transfer container) so bindings know to unref
the array only.
Fixes: https://github.com/flatpak/flatpak/issues/6666
It was solved partially in e0e1b20, but not for completely disallowed code path.
Steps to reproduce:
1. Run any flatpak with explicit --unshare option, e.g:
[user@user-standardpc ~]$ flatpak run --unshare=network --command=bash io.gitlab.librewolf-community
2. Inside flatpak shell spawn any executable:
[io.gitlab.librewolf-community ~]$ flatpak-spawn ls /
Result is:
error: Unknown option --noshare=network
Add a regression test that installs from an auth-protected OCI registry.
The registry requires a bearer token for all /v2/ requests; the client
authenticates via the mock test authenticator and the installation
completes successfully. The test runs for both user and system install
paths.
Assisted-by: Cursor
Add infrastructure for testing OCI installations from auth-protected
registries. The mock server now supports requiring a bearer token on all
/v2/ requests, configurable via a new POST /testing-auth/configure admin
endpoint. The client gains a corresponding 'configure-auth' subcommand.
Assisted-by: Cursor
In flatpak_pull_from_oci we can be in in the system helper where we pull
the mirrored OCI image into the system repo. However, to fetch the
signatures in GPG signed repos, we used a remote OciImageSource created
through `flatpak_remote_state_fetch_image_source`. This caused fetching
some data from the registry which we don't want in the deploy method,
and also fails if a token is required to access the repo.
This change fetches the signatures from the mirrored OCI repo instead of
pulling them from the remote OciImageSource. The signatures can come from
anywhere because we verify them against the GPG key in the system repo.
The important bit is the change in `flatpak_pull_from_oci` where we now
pass in the local image_source to fetch the signatures from, and in the
system helper, where we get the right metadata to check the signatures
against (eventually ends up in `flatpak_oci_signatures_verify`).
The bare tuple unpack 'executable, = re.findall(...)' raises a cryptic
ValueError if the pattern matches zero or more than one line. Replace it
with an explicit length check and a clear error message.
Also pass count=1 to str.replace() so a /newroot prefix is only stripped
once and /app/ paths are passed through unchanged.
This fixes a bug where the warning about not being a flatpaked
application was being printed for flatpaks. This was due to a
change in bwrap so that the paths no longer start with /newroot.
Being unable to access the system-bus is nto a security boundry since,
in that case it's trivial to start your own session and set
DBUS_SYSTEM_BUS_ADDRESS. This is the same fix as 3afdfd2 but for handling
installation instead. See said commit for more details.
Adapted from #5609Fixes#5076
Co-authored-by: Dan Nicholson <dbn@endlessaccess.org>
/dev/kfd is used for AMD ROCm/OpenCL compute. Add it to the dri
device list so apps can request GPU compute access without
needing --device=all.
Fixes: https://github.com/flatpak/flatpak/issues/5383
Sourcing profile/flatpak.fish spawns `flatpak --installations` on every
fish shell startup, which costs ~15 ms on a typical desktop and
dominates fish's non-interactive init time when flatpak is installed.
On any system where the login stack (pam_env, systemd user session,
distro-specific init) has already populated XDG_DATA_DIRS with the
canonical user flatpak export path, this spawn is redundant: the
subsequent `contains` loop would be a no-op because the canonical
entry is already there.
Add a fast-path guard that checks for `$XDG_DATA_HOME/flatpak/exports/share`
(falling back to `$HOME/.local/share/flatpak/exports/share` when
XDG_DATA_HOME is unset) at the top of the script. When present, skip
the slow path entirely.
The slow path is preserved verbatim for sessions where the canonical
entry is missing — e.g. a freshly-created user, or environments where
session init hasn't populated XDG_DATA_DIRS yet — so custom
installations configured via /etc/flatpak/installations.d/*.conf are
still discovered in that case.
Measured on Linux with `hyperfine --warmup 5 'fish -c exit'`:
before: ~23 ms of startup spent in `flatpak --installations`
after: ~10 us (a single `contains` check) on the common path.
The warning seems to happen with GCC 11 but not with GCC 13 or newer.
A simple void cast still leaves the warning enabled due to a bug
or intentional choice in GCC [1], so it is assigned to a variable first
and then void-ed.
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
I accidentally screwed up the arch I passed to a `flatpak update`
invocation and was very confused as to what actually went wrong. Adding
the actual refs in the commit should help make failure cause more
obvious.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
GTimeVal and g_get_current_time() are deprecated since GLib 2.62
and tv_sec is 32-bit on 32-bit platforms, causing Y2038 overflow.
g_get_real_time() returns gint64 and is safe on all platforms.
polkit_subject_to_string() is called inside the HAVE_LIBSYSTEMD guard
in flatpak_dir_log(), but <polkit/polkit.h> is only included when
USE_SYSTEM_HELPER is defined. This causes a build failure on
configurations that have libsystemd but no system helper.
Guard the polkit call with USE_SYSTEM_HELPER and fall back to "(none)"
so the subject string is always valid for the sd_journal_send() call.
Fixes: f9d5c5c ("dir: Free result of polkit_subject_to_string")
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
If we convert fallback-x11 internally to a conditional x11 permission,
we cannot express current fallback-x11 stacking behavior:
lower: empty + upper: !fallback-x11 -> no x11 access
lower: fallback-x11 + upper: !fallback-x11 -> x11 access
The reason is that conditionals have no view of the lower level.
This changes things in a way that fallback-x11 stays its own socket
permission with two interactions with the x11 socket permission:
* If a upper level resets x11 (--socket=x11, --nosocket=x11), the lower
level fallback-x11 permission gets dropped
* When computing the allowed sockets, --socket=fallback-x11 gets
converted to --socket=if:x11:!has-wayland
Fixes: #6556
Instead of trying to read them into variables, which could fail if there
were null bytes in the key.
Fixes: 43642337 ("dir: Try to delete the remote if we failed to add it entirely")
I was convinced that the pattern `! command` with -e aborts when
`command` fails. This is not the case (the result of `false` is the same
as `! true` but somehow this doesn't matter).
Fix the tests and use the newly introduced `assert_not` function. One
could also use `command && assert_not_reached "message"` but who has
time to write error messages for all the cases.
Add an integration test that verifies the Flatpak-Upgrade-From HTTP
header is correctly sent during update operations but absent during
fresh installs. This header is used by Flathub to distinguish updates
from new installs in download statistics.
To support the test, extend web-server.py to optionally log Flatpak-*
request headers to a separate file.
Ideally, we would be able to atomically add and remove remotes, but
we're very far from that ideal state. The current behavior is really
suboptimal and leaves the remotes in a inconsistent state if
initialization failed. We can at least make it better by trying to clean
up the half-initialized mess we're currently in. It does however not
protect against SIGKILL-like aborts, as that would require it to be
atomic.
Closes: #6449
Co-authored-by: craftyguy "Clayton Craft" <clayton@craftyguy.net>
If _flatpak_dir_ensure_repo is called with allow_empty=true, it is
allowed to fail to create the repo, and is supposed to return success in
that case.
The system helper handles this correctly, but we then call to
ensure_repo_opened no matter if the repo actuall exists and return an
error when it does not, no matter if allow_empty is set or not.
Closes: #6618
