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.
Which allows one to create an image source from a container location.
It also adds a new FlatpakDockerReference to access different parts of a
docker reference and changes to FlatpakOciIndex to get a manifest for a
specific architecture.
This will become useful in the next commit when we're going to add
support for installing OCI images.
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.
flatpak run writes /run/host/font-dirs.xml, but flatpak build so far
didn't. This resulted in fontconfig writing:
Fontconfig error: Cannot load config file "/run/host/font-dirs.xml": No such file: /run/host/font-dirs.xml
to the stderr of all processes utilizing fontconfig and run during
flatpak build, as /run/host/font-dirs.xml is included via
/etc/fonts/50-flatpak.conf. This could cause issues for tests run during
building an application, for example.
Closes#6137
CI currently skips a lot of tests. This is due to AppArmor restricting
user namespacing to specific executables with a profile. We however
build bwrap ourselves and that makes it hard to have a profile for it.
Let's just turn the restriction off entirely.
Autotools support was removed as of commit 8e63eda,
remove mention of the Autotools support in the CONTRIBUTING file
Signed-off-by: Ryan Brue <ryanbrue.dev@gmail.com>
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>
The systemd Desktop Environments conventions for cgroup names is
app[-<launcher>]-<ApplicationID>-<RANDOM>.scope
where RANDOM should ensure that multiple instances of the application
can be launched. Currently flatpak uses the PID of itself but the
instance fullfills this convention and is a bit more useful for matching
the cgroup to a flatpak instance.
There are cases where flatpak is doing some internal work (apply extra
data) where there is no instance id, and more philosophically also no
app instance. In those cases we simply do not move the process to the
cgroup with the XDG convention.
The original idea behind this code was that the initial lockless scan
of reachable objects will make the locking one fast enough that
it won't matter to software managing flatpak repos like flat-manager.
Few years later I can say this is not true, and the locking variant
of scan does take too long and affects Flathub's publishing process.
By keeping only the lockless variant in dry run, we can run it on a
weekly schedule without affecting operations, and issue actual pruning
with flat-manager which will hold a lock in external system and avoid
executing any actions requiring locking to avoid errors/timeouts.
We already build and test with asan with the newer
toolchain in the ubuntu 24.04 job. Sometimes the older
toolchain found in 22.04 or the asan version will
trigger issues that are either false positive or that
have been already against in newer versions.
Currently, app installs and updates are treated the same from the point
of view of the parental controls permissions checks. This was intended so
that parents have to re-check each app update to make sure it’s still
appropriate for their children.
In practice, though, parents are not that hands-on, and there are a lot of
regular app updates. The tradeoff between app updates (which bring
security fixes and features) and not changing so much in apps that a
parent’s initial assessment of their suitability for their child is
probably skewed the wrong way. We should be preferring updates (in
particular, so we get security updates), and assuming that if an app is
OK to begin with, it’s probably not going to change so radically as to
become unsuitable for a child with an update.
As a data point, Google Play’s parental controls will allow apps to be
automatically updated even if a child account can’t install new apps.
So, implement this by splitting the existing
`org.freedesktop.Flatpak.override-parental-controls` polkit action in
two: the existing action for _installs_, and a new
`org.freedesktop.Flatpak.override-parental-controls-update` action for
_updates_. `FlatpakDir` is changed to use the appropriate action
depending on whether an app is being installed from scratch or updated.
The default policies for the two actions differ.
Users/Distros who disagree with the new default policy can provide their
own polkit rules to change the behaviour of
`override-parental-controls-update` so that it matches
`override-parental-controls`, to bring back the old behaviour.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: https://github.com/flatpak/flatpak/issues/5552
udmabuf allows clients to allocate virtual memory as dmabufs,
which then potentially can be imported by other dma subsystems -
most importantly GPU drivers and KMS. This can avoid copies and
thus increase performance.
Unlike other dmabuf allocators like e.g. dma heaps this doesn't
have known issues relevant for sandboxing. Notably memory accounting
works as expected, so apps can't use udmabuf to escape resource
limitations. For this reason systemd, since version 257[1], grants
"uaccess" access to udmabuf by default, considering it as "safe".
With udmabuf increasingly being availably by default, various apps
and libraries start making use of it - examples include libcamera,
mesa llvmpipe and Gstreamer. Thus let's grant access to it in Flatpak
as well.
For now limit it to "dri" access as sharing buffers with GPUs is
the most common use-case. There is no strong reason to not lift
restrictions further if the need arises, though.
1: https://github.com/systemd/systemd/pull/33738
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Robert Mader <robert.mader@collabora.com>
