During a system install with the system helper enabled, the initial
network pull goes to a temporary repo and then via pull local from that
repo to the final system repo while during user install there is only
one pull from network to the final repo.
c672c55 set the logger to use the temporary repo path as installation
but the history command afc87ad since the same day filters the initial
pull out as the installation name will never match the temporary path.
This causes the initial pull operation to be never show up in flatpak
history when using system installs while they work for user installs as
`INSTALLATION=user`.
This is presumably also broken for custom installations as they
will similarly not match the temp repo path.
So don't pass the path at all to flatpak_dir_log and we can later
fall back via flatpak_dir_get_name_cached() which sets the correct
`INSTALLATION` for system installs ie. `INSTALLATION=system`.
This also allows us to remove the workaround of adding two different
expected history outputs from ad1ff6d as both branches log the pull.
Without system helper `flatpak install` needs to be executed as
priviledged to operate on system install so the initial pull was
always logged correctly for that branch.
Help messages were inconsistent about whether they ended with periods or
not. I chose to remove the periods from those that had them rather than
the other way around because the help messages automatically generated
by argparse do not have periods.
There are a couple related changes made here, with the intention of
making it easier to implement additional features in the future:
- Mutual exclusivity of --build-directory and app is better enforced
both through types and at runtime. The types will let type checkers
ensure that we cannot reach the run function without at least one of
them being valid. At runtime, it no longer allows both to be
specified, which could result in confusion over which takes
precedence.
- Instead of wrapping the entire program in a class, there is now only a
small class that handles validation of the arguments and holding the
data to be passed to run. This provides a better separation of
concerns, with the argument parsing now being a little less tied to
running the debugger.
-m with no argument currently results in coredumpctl_matches having a
value of "", which is exactly the same as if it weren't used at all. As
far as I can tell, allowing this does nothing useful, only making the
usage slightly less clear.
`emit_progress` is called from a thread while another thread could
unexport/close the GDbusInterfaceSkeleton. If that happens, the
connection becomes NULL which is illegal for
`g_dbus_connection_emit_signal` which results in dereferencing an unset
error.
The fix is to lock the UpdateMonitorData, and then only emit the signal
if it is not closed.
The file forwarding feature errors out when the path or URI does not
lead to an actual file that can be forwarded. The empty path never
describes an actual file, so we always have to error out.
Without the check, we would get a NULL path from
`flatpak_file_get_path_cached` and crash later.
Closes: #6689
The tests assumed that a system installation always uses the XDG cache
location unless running as root. However, Flatpak only uses that cache
location when the system helper is available at both compile and run
time. [1]
Builds configured with -Dsystem_helper=disabled instead use the
repo-local cache directory [2], causing the tests to look for cached
summaries in the wrong location and fail.
[1]: 96ad6825f3/common/flatpak-dir.c (L4853-L4862)
[2]: 96ad6825f3/common/flatpak-dir.c (L4942-L4943)
* backports, local-alloc: Provide a backport of g_autofd
* build: Add meson.override_dependency('libglnx', libglnx_dep)
* fdio: Add support for name_to_handle_at
* chase: Add glnx_chase_and_mkdirat
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
1. Removed unnecessary punctuation to help with readability
2. Loop over RES elements directly instead of indexing
3. Declare COMPGEN_OPTS only once vs redeclaring on each iteration
A few global variables were being created unecessarily still. This makes
sure that users shell environments are not polluted by extra variables
and that the completion doesn't modify unrelated variables
We found that there is a common use case where we need to get a
subdirectory (potentially multiple levels) which might not exist yet.
Adding another flag for this to GlnxChaseFlags is what systemd has done,
but creating a directory takes a mode, so the flag creates directories
with a fixed mode. This approach instead takes the mode as argument.
It takes a callback which gets called every time we try to open the next
segment of the path. This allows implementing more specific and advanced
use cases to be implemented without adding more complexity to the chase
algorithm itself.
We were handling null properties the same as missing properties
*except* that the MANDATORY flag allowed null properties but
not missing properties. Fix this, so null is disallowed by
MANDATORY.
When checking signatures, the image identity could only have
been NULL if it was null in the input file - so replace a
conditional check on it being non-null with an assertion.
It's legitimate to have manifests listed in an image index that
have no platform object, and hence no architecture - avoid crashing
if we encounter such a manifest.
Mark all properties required by the OCI specification as required;
this eliminates a bunch of cases where we were assuming that
descriptor->digest was non-NULL, and potentially generating
critical errors from g_return_if_fail().
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.
