This gives us conditionals for shares and features. So far we have no
use case for this, but the system already exists, it makes the code
simpler, and when we need this in the future, we don't have to wait for
it to roll out.
For device and socket the negated versions are nodevice and nosocket,
but for shares, the strings are allow and disallow. Take arguments for
both forms.
Allow specifying a lookside URL for downloading signatures for
an OCI remote. This can be specified:
In a .repofile with the SignatureLookaside key
As the --signature-lookaside option to remote-add/remote-modify
FlatpakOciSignature was a Flatpak-specific analog to
the containers/image "simple signatures" - but it wasn't used at
all, and Flatpaks on registry.redhat.io are signed by the
original simple signatures. So modify it correspond to
the original simple signatures.
There is some code for OCI signature verification that isn't currently
hooked up at all. In preparation for reworking it to usefully check
signatures that actually exist in OCI registries, move it to a
separate file.
We declare the autoptrs explicitly on those typedefs so it works on
older systems but this one accidentally uses the type provided by polkit
itself.
Fixes: 1372e16d ("dir: Check parental control authorization via system bus name")
When an xdg dir is not available, it is supposed to point at $HOME. We
do not want to mount $HOME though in that case, so we just skip the xdg
dir instead.
The check compares the strings of the the xdg dir path and the home dir
path. So far it relied on the functions internally canonicalizing the
paths in the same way, but there was a glib regression:
https://gitlab.gnome.org/GNOME/glib/-/issues/3811
("g_get_user_special_dir doesn't strip trailing slash from $HOME")
Which then was fixed in cb3e9fe74 ("gutils: Strip all trailing
slashes").
We can however just canonicalize on the paths on the caller side to make
this more robust, so let's just do that.
Closes: #6323
Extra-data usually is downloaded on the user side into an ostree repo.
For system installs, a temporary ostree repo is used on the user side
and then imported on the system side. This doesn't work for OCI images
because importing the image into an ostree repo makes it impossible for
the system side to verify the data.
So instead, the OCI image is first mirrored into a local OCI repo and
then gets imported on the system side, which can verify the image from
the index by the digest.
Closes: https://github.com/flatpak/flatpak/issues/3790
It took in a ostree commit before, but it really only needs the detached
metadata. The single caller now converts it correctly.
This will become useful when we want to know the size of the extra data
when the metadata is coming from an OCI image.
This cleans up flatpak_dir_pull_extra_data in a way that it is only
responsible for downloading the extra-data. In has no dependencies on
ostree concepts any more.
The new flatpak_dir_pull_ostree_extra_data now takes care of extracing
the extra data sources and saving it in the detached metadata.
CURLcode return values from curl_easy_setopt() were being compared
with CURLM_OK (a CURLMcode constant) instead of CURLE_OK. This is
incorrect as CURLM_OK is for multi interface functions, not easy
interface functions.
A few years ago there was a very painful attempt at porting from
libsoup2 to libsoup3. Flatpak libsoup3 support never landed and it seems
like a large amount of distros have switched over to libcurl instead.
This commit removes libsoup2 support completely instead of growing
libsoup3 support.
Closes#5915Closes#4582
Add an option to build OCI bundles with zstd compressed layers.
gzip is kept as the default for maximum compatibility:
Ecosystem support:
distribution/distribution: no explicit support, but works
quay.io: sinc 2021
Amazon ECR: supported
pulp_container: since 2022
flatpak: since first-OCI supporting version
tardiff: since first version
This comment needs to be modernized for 2025. It notably fails to
mention the two projects that are actually still using code that looks
like Flatpak's.
If an SDK is already installed in a dir that is not targeted with a
flatpak transaction, and the transaction has auto_install_sdk set,
add_new_dep_op returns NULL in dep_op which is not correctly handled in
add_deps.
Fixes#5894
We could previously just assume that the first enabled remote
(potentially matching the collection ID) contains the ref, but that
obviously is not always the case.
The change here looks up the remote state of the remotes to figure out
if they actually contain the ref, and adds the first matching remote to
the transaction.
Sudo can be used in several ways other than calling a command with the
root user. For example, one can use -u to run the command as the
specified user, or -g to specify a primary group to run the command
as.
Flatpak adds a check when --user is used to prevent an installation in
the root's directory, for example, but it does it by only checking if
sudo was used. As stated previously, it does not necessarily imply
root, so this patch explicitly checks if the command is being run with
the root user.
Fixes: https://github.com/flatpak/flatpak/issues/5979
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
The appstream docs say:
Release data may be present directly in a component metainfo file, but
also optionally be split out into an external metadata file.
The file must be installed as
/usr/share/metainfo/releases/%{cid}.releases.xml, where cid is the
component ID of the component the release information belongs to.
This change allows flatpak build-finish to export those external release
files.
Closes#6057
PIDs are pretty much always a bad idea because they can be racy. The
authorization did use the PID though. We can replace it by a check via
the system bus name.
Closes: https://github.com/flatpak/flatpak/issues/6212
The memory management of returning a VarRefInfoRef is tricky - it
points to data owned by the summary or the sideload repo. External
consumers were always retrieving a copy of the summary metadata,
so make the public function do that.
For some reason, flatpak build always had host permissions set by
default. There really isn't a good reason for this. The build should be
isolated from the host as much as possible by default.
Without doing so, flatpak_dir_get_config() won't reflect changes made
with flatpak_dir_set_config().
This fixes passing multiple patterns to `flatpak mask` for the system
installation.
Closes#5464
Fixes#4268
Make sure that session-helper always tracks the destinations of symlinks.
This fixes a race condition on systems where '/etc/resolv.conf' is a symlink.
This adds a new type that is meant to track more complex permissions
than a pure bitmask, including conditional dependencies. It is not yet
used, but it will be used for at least the socket and device
permissions.
For each possible permission we track whether the permission is
unconditionally allowed, unconditionally disallowed, or if it is
conditionally allowed (allowed if some conditions are met).
Additionally we track for each permission whether stacking the context
on top of another will reset permissions in the layer below. This is a
new feature, because previously merging layers *always* overrode the
value from below, whereas conditional permissions can either stack on
top of, or replace the underlying layer.
In terms of the keyfile, there are 4 possible types of layers:
1) Add a permission, removes all partial permissions below
socket=pipewire
2) Remove access, removes both partial and full permissions below
socket=!pipewire
3) Adds a partial permission, keeping whatever is already there:
socket=pipewire;pipewire:if:has-wayland
Note: This adds a plain `pipewire` for backwards compat.
Note: If parent has full pipewire access, this is a no-op.
4) Adds a partial permission, remove all previous access
socket=!pipewire;pipewire;pipewire:if:has-wayland
Note: This seems weird as it has both !pipewire and pipewire, but older versions
will read these in order and get the right result.
Additionally, partial permissions can have multiple conditions:
socket=pipewire;pipewire:if:has-something;pipewire:if:has-other;
In such a case the socket will be accessible if any condition matches.
Conditions can also be negated:
socket=pipewire;pipewire:if:!has-something;
Due to backwards compatibility we have to add the non-conditional
permission as well as the conditional, as older flatpak will ignore
the conditional. This is handle when serializing/deserializing the
permissions, and internally we don't have to care about this.
Instead of pulling out data from the context and passing it to the
function. This allows to make further changes to the function which
require more data from the context.
