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.
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
Instead of doing meson dist on the developers machine and uploading it,
and creating the release in github, we can let the CI take care of it.
Closes#6404
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
In 4febfb59 ("flatpak: Disable progress escape sequence by default") the
escape sequence has been disabled by default, but we want to enable it
again for 1.18.
For OCI remotes, the existing sideload repository system doesn't
work: identity for OCI remotes is done by manifest digest (disguised
as a fake commit ID internally), instead of by ostree commit, so
we have no way of knowing whether a sideloaded image matches the
summary.
Allow specifying a new form of sideload repository with:
--sideload-repo=oci:<path>
The desired use case for this is preinstalling Flatpaks during OS
install, and for this, binding the entire repository to a single
collection ID is both inconvenient and not useful, so OCI sideload
repostories don't have a defined collection ID - they just apply to
all OCI remotes. (And, because of this, they are restricted to
the command line.)
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.
Adapted from: https://github.com/flatpak/flatpak/pull/6125
In systemd v259, /run/host/root will be a documented location
for bind mounting the host's root filesystem into a
container. Ref: https://github.com/systemd/systemd/pull/38384
host-root is the sledgehammer permission for file browsers
and similar apps that the user might want to give full access
to.
This works same as the existing host keywords by mounting into
/run/host/root. applications will need adjustments to essentially
treat that path as "root".
Since this opens the door to all sorts of malicious software, the
permission should be put under tight review in flatpak
repositories.
Resolves: #5723
Co-authored-by: Ryan Brue <ryanbrue.dev@gmail.com>
This adds new FlatpakTransaction API, and a new top level CLI command to
preinstall flatpaks, that is to install flatpaks that are considered
part of the operating system.
A new drop-in directory /etc/flatpak/preinstall.d/ allows configuring
what apps should be preinstalled, and a new flatpak preinstall command
installs and removes apps based on the current configuration.
A drop-in loupe.preinstall file can look something like this:
[Flatpak Preinstall org.gnome.Loupe]
Branch=stable
IsRuntime=false
The corresponding API is flatpak_transaction_add_sync_preinstalled()
which can be implemented by GUI clients to drive the actual installs
on system startup.
Resolves: https://github.com/flatpak/flatpak/issues/5579
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Add support for `oci-archive:` image sources by temporarily
unpacking the archive using libarchive.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
Similar to bundle installs, add:
flatpak install [--image] docker://registry.example.com/image:latest
flatpak install [--image] oci:/path/to/image
These is useful for testing purposes and in certain cases when installing
Flatpaks on disconnected systems.
To avoid passing around combinations of a FlaptakOciRegistry with
repository and digest, add a FlatpakImageSource type.
This also reduces duplicated code where every place that did
this independently retrieved the repository and image config.
Docker and podman can be configured to use mutual TLS authentication
to the registry by dropping files into system-wide and user
directories. Implement this in a largely compatible way.
(Because of the limitations of our underlying libraries, we
can't support multiple certificates within the same host config,
but I don't expect anybody actually needs that.)
The certs.d handling is extended so that certificates are separately
looked up when downloading the look-aside index. This is mostly
to simplify our tests, so we can use one web server for both -
in actual operation, we expect the indexes to be unauthenticated.
Also for testing purposes, FLATPAK_CONTAINER_CERTS_D is supported
to override the standard search path.
Co-authored-by: Sebastian Wick <sebastian.wick@redhat.com>
And add the FLATPAK_TTY_PROGRESS env var to re-enable it.
This seems to only be supported by recent versions of terminal emulators
which will cause problems with shipping Flatpak on older distros.
Closes https://github.com/flatpak/flatpak/issues/6052
The release checklist claimed we used titles like `Release 1.15.12`,
but in practice they've all been like `1.15.12` for a long time.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Add '--usb' and '--nousb' to the FlatpakContext option group.
Map these parameters to either the enumarable list, or the hidden
list, of a new "USB Devices" group in the metadata key file. It looks
like this:
```
[USB Devices]
hidden-devices=cls:01:*;
enumerable-devices=vnd:0fd9+dev:0080;vnd:0fd9+dev:0080;
```
Flatpak itself does not use these values, they're meant to be used
by e.g. XDG Desktop Portal to filter which devices the app can see
through the USB portal.
Hidden devices must always take precedence over enumerable devices.
This is heavily inspired by https://github.com/flatpak/flatpak/pull/4083
Co-Authored-By: Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
Co-Authored-By: Ryan Gonzalez <rymg19@gmail.com>
Signed-off-by: Hubert Figuière <hub@figuiere.net>
We now resolve the zoneinfo and always make it available at
/usr/share/zoneinfo in the sandbox so we unset TZDIR to get flatpak apps
looking at the right directory.
This is more compliant with FHS specification. Most notably, /etc
is not appropriate to hold distro configuration, which is a common
use for the remotes.d feature. It is better practice to put things
under /usr/share, and let the system administrator modify /etc to
their will, of course giving them priority.
Update documentation to reflect this change.
In the process, move to use g_build_filename
This adds a new `usb` device in the list to grant access to the whole
USB bus. This is narrower than `all` and should be enough for
anything accessing the USB directly (i.e. using libusb or equivalent).
This doesn't grant access to synthesized devices, i.e those exposed
in `/dev` but using USB, including but not limited to USB serial, webcams,
hidraw, hid, sound.
Close#4405
Signed-off-by: Hubert Figuière <hub@figuiere.net>
This option allows the application (or subsandbox) to own the specified
name on the a11y bus. This will be useful for WebKit, that has a strict
security need that the Web processes cannot talk or see each other.
An alternative approach would be to make xdg-dbus-proxy permissions
modifiable at runtime, but that seems a lot riskier than this. Owning
a well known name based on the app id has proven to be a robust and
secure approach after all.
To include all languages, the languages key must be set to `*all*`, not
`all`. That was apparently intended to provide symmetry with how the
value is represented in the output of `flatpak config`.
Following on from b8d8d80c61, add more environment variables used by
the Vulkan loader which expect paths to be provided.
These paths are typically referencing the host filesystem; if the user
is referencing paths only available in the sandbox, they can use --env
or overrides for them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Similar to how b8d8d80c61 inhibited passthrough of environment
variables pointing the Vulkan loader towards a specific ICD, do the same
for the EGL paths used by libglvnd to discover the GL driver to use, as
well as for NVIDIA's EGLStream shim.
These paths are typically referencing the host filesystem; if the user
is referencing paths only available in the sandbox, they can use --env
or overrides for them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
I don't think this env var makes much sense to pass into the sandbox
for similar reasons to LD_LIBRARY_PATH. Libraries from the host
just aren't relevant.
Users can still pass `--env=LD_PRELOAD=/foo` to use this functionality.
As discussed in #5695, I think we're reaching a point where removing
Autotools is preferable to fixing it.
1.14.x continues to use Autotools, so platforms whose Meson version is
too old can stay on that branch until it becomes unsupported. We have
a very conservative Meson dependency (Ubuntu 20.04).
Signed-off-by: Simon McVittie <smcv@collabora.com>
1. For security context creation, only relies on WAYLAND_DISPLAY, do not
use WAYLAND_SOCKET since the file descriptor defined by WAYLAND_SOCKET
can be only consumed once.
2. Due to the incompatiblity between WAYLAND_SOCKET and the security
context, add a new permission --socket=inherit-wayland-socket
to limit the usage of WAYLAND_SOCKET to an opt-in feature. Only when
this flag is set, WAYLAND_SOCKET will be passed to the sandbox.
3. When WAYLAND_SOCKET is not inherited, set FD_CLOEXEC to avoid it to
be leaked the to sandbox.
Closes: #5614
