We want to use collection IDs to specify what remote to install from
when processing /etc/flatpak/preinstall.d; in order for this to work
for OCI remotes, we need to permit collection IDs.
- In flatpakrepo files, don't require a GPGKey for a OCI remote
with a collection - we don't have signature verification for GPG remotes.
- Don't validate that the collection ID appears in the summary -
the image index doesn't currently contain an image ID
Instead of passing the delta URL along with the image source, when
we create an image source for a remote registry, if we find a delta
URL in the metadata, set it on the FlatpakImageSource for later use.
Centralize duplicated code for creating an image source for a remote
repository based on a summary lookup into one place.
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.
