Instead of using flatpak_oci_manifest_descriptor_get_ref which requires
the `org.opencontainers.image.ref.name` annotation, get any valid
manifest, and make sure to return NULL if there are multiple valid
manifests.
Closes: https://github.com/flatpak/flatpak/issues/6081
Since flatpak_image_source_new_remote() already tries to load files
from the registry, having a separate flatpak_image_source_set_token()
doesn't work - when the token is set, it's already too late to
be passed along with the initial requests.
The F_DUPFD and its relative F_DUPFD_CLOEXEC both expect an int argument
as extra argument, being the minimal value for the new FD. This argument
must be within the accepted range (see ulimit -H -n).
This was detected in Ubuntu during testing against the latest glibc,
stracing resulted in:
107244 fcntl(1, F_DUPFD_CLOEXEC, 1847846346272) = -1 EINVAL (Invalid argument)
On the system in question (ppc64el machine running Ubuntu Questing), the
relevant limit is 524288.
For the fix we use 3 as a reasonable floor value, as in the first one
after stderr. It also happens to be the one used in revokefs/main.c.
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2121039
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>
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>
