systemd OCI Image Pull

systemd-pull is the downloader behind systemd-importd and importctl, fetching tarballs and raw disk images for systemd-nspawn containers and portable services. Most container images are published as OCI images in registries like Docker Hub, Quay and GHCR. Upstream #39621 taught systemd-pull to download them directly without third-party conversion tools. A correct pull spans the container distribution stack: resolving references through registry databases, bearer-token authentication with the OCI Distribution API, platform selection from an image index, digest verification, and layer unpacking. Images are not flattened: each layer is stored once, content-addressed, with OCI whiteouts (deletion markers) converted for unprivileged overlayfs, and the image is a mount stack listing its layers in order.

The agent adds an oci verb to systemd-pull with a pinned interface. References resolve through registry database files in systemd's configuration search path, with specified file-name escaping and fields for protocol, registry and image overrides, prefixes and default tags. Registry access follows the OCI Distribution Specification, image handling the OCI Image Format Specification v1.1. Any digest or size mismatch aborts the pull and leaves no mount stack.

The offline sandbox (4 CPUs, 8 GB, 4 hours) holds the systemd repository with full history at the starting commit, a Debian trixie toolchain and a build tree configured with the verifier's options. A local registry server, a test CA and nine example images come with their expected image roots. The graded pull scenarios are held out.

The committed tree is rebuilt from scratch in a separate environment with existing test sources restored from a trusted copy, and the meson test suite must pass everything the starting commit passes. The candidate's systemd-pull runs as root in a user namespace mapping 65,536 ids, against registries the verifier serves over HTTP and HTTPS, on secret-seeded images and registry configurations. Each image root is read the way overlayfs and systemd-nspawn's settings parser would interpret it and compared with the specifications; invalid or unverifiable content must be refused. Checks span eight areas, from layer unpacking and whiteouts through authentication and registry resolution; a pass requires each to reach 90%.