Hi all, The Yocto Project has identified an opportunity to make a significant impact within the Linux Containers space. We can build on recent improvements to the way container images can be built and tested with Yocto Project tooling, as presented by Bruce Ashfield at the recent OpenEmbedded Workshop in Brussels (slides: https://pretalx.com/media/openembedded-workshop-2026-2025/submissions/ZGLVF7/resources/_0Jc2imX.pdf). This approach gives us repeatable, auditable, curated containers using the Yocto Project’s standard build process, which includes all of the existing benefits that come with our builds.
To achieve our goals, changes will be needed in metadata layers and the autobuilder configuration. We would like to move forward with these changes rapidly and so we need 2-3 months of contractor help to turn this into an end to end technology demo. We invite individuals and organisations who are able to deliver the Statement of Work outlined below to submit quotations to the project. Responses should be submitted by email to [email protected] before *Monday 2nd March 2026, 23:59 PST*. Background The Yocto Project is a highly capable toolkit for building Linux images and distributions. We have achieved extensive use within the Embedded Linux space, as well as expanding to support real-time operating systems (RTOS) such as Zephyr. We have a long history of leading the way with our tools to support compliance, including license manifest generation, SBOM creation, CVE tracking and source archival. With the advent of the EU Cyber Resilience Act (CRA), these compliance tools have become even more relevant and are needed across the whole software industry, not just in the Embedded space. Within the wider Linux containers ecosystem, current compliance tools work by scanning a generated container image and attempting to identify the included components. This works well when all components are installed via a distribution’s package manager and when manually installed software components come with their own pre-generated SBOM. However, as container image generation is essentially a free-form process, there is no way to ensure that all components will be correctly identified and no guarantee of reproducibility. These approaches can be contrasted with the tooling provided by the Yocto Project. Here the builds system owns the complete image creation process, using strongly delineated steps of source fetching, compilation, packaging and rootfs creation. We provide clear guidance on best practices and can detect many common mistakes that can impact the quality of compliance data (for example, we can prevent attempts to download sources outside of the appropriate fetch stage). Reproducibility is treated as a first-class project goal and is covered by our test suite. These features provide much stronger guarantees about the quality of the generated compliance data than can be achieved with a free-form process. We support building Linux container images using Yocto Project via the meta-virtualization layer. Recent improvements allow for container generation using standard container tools such as docker, without the need for elevated (root) privileges or other workaround, which was the missing piece of making containers a primary project technology. Goals To fully demonstrate the project’s container capabilities, the project would like to show we can build and publish containers. We want to do this by creating and populating a reference container registry with sample container images accompanied by comprehensive SBOMs. The process of building and publishing images needs to be fully automated, running regularly on our autobuilder cluster to ensure that the reference images remain up-to-date with changes to our build system and are fully integrated into our CI workflow. Test cases and documentation need to be expanded to cover the new features, and developers need to be guided towards best practices when customising the reference images for production use cases. Required Skills • Experience of Yocto Project/OpenEmbedded builds • Knowledge of container image generation and best practises • Knowledge of publishing containers and container registries • Experience and knowledge of the Yocto Projects CI infrastructure and tooling/processes Statement of Work **Reference container recipes** New recipes must be defined for an initial set of reference container images, using the `image-oci` bbclass in meta-virtualization. The initial set should focus on software which is commonly deployed via containers, such as: • A minimal image (based on core-image-minimal) • A Python 3 base image • A sample web application written in Python • A PostgreSQL database server • A multi-service container using systemd to manage services The above list is not intended to be prescriptive - we appreciate input on appropriate reference container images. The final list of approximately 3-5 reference container images will be agreed with the Yocto Project TSC. Reference container images should be built with the standard poky distro config. They should build for multiple architectures - initially x86-64, aarch64 and riscv64. This task requires recipes for the agreed list of reference container images to be added to the meta-virtualization layer. **Test cases** We must be able to test that the container runtime and the reference container images can be built and that they behave as expected. This task requires creation of new oeqa selftest cases which perform build and runtime testing of the reference container images using the chosen container runtime. These cases should ensure that the container runtime is able to create containers from the reference container images, start the containers, interact with them and stop them without errors. **Autobuilder integration** The new test cases must be executed on the project autobuilder instance as part of our regular testing. This task consists of any integration work required to get the test cases running on the autobuilder. It may require modification of the controller configuration (yocto-autobuilder2), build/test scripts (yocto-autobuilder-helper) and working with Linux Foundation IT to make configuration changes to the autobuilder workers (such as installing additional host software). **Publishing reference containers** The reference container images must be published to a publicly accessible container registry, as multi-arch images with support for at least x86-64, aarch64 and riscv64. Images should be tagged in line with container best practices. Due to usage restrictions and rate limits, Docker Hub should not be used. In line with the Yocto Project approach of owning our infrastructure, we should run our own container registry if possible. This task requires working with Linux Foundation IT to setup a container registry server for the project - all required system administration tasks will be performed by Linux Foundation IT but they may require advice and support with things like selecting a container registry implementation that meets our needs. This task also requires integration work within the project autobuilder instance to publish container images to the registry. It may require modification of the controller configuration (yocto-autobuilder2), build/test scripts (yocto-autobuilder-helper) and working with Linux Foundation IT to make configuration changes to the autobuilder workers (such as installing additional host software). **Publishing SBOM attestations** SBOMs should be generated for the reference container images and published to the container registry as build attestations and/or OCI layers as appropriate. This task requires integration work within the project autobuilder instance to publish SBOM build attestations along with container images. It is likely to require modification of the autobuilder build/test scripts (yocto-autobuilder-helper). **Documentation** All new features must be well documented. Our documentation should guide developers on how to customise the reference container images, following best practices and making full use of compliance tools like SBOM generation. This task requires working with our documentation writer to cover the new features, bbclasses and reference container images added as part of this work. The majority of documentation changes can be made by our documentation writer, but they will require guidance and review of their proposed changes. References • openembeded-core layer: _https://git.openembedded.org/openembedded-core/_ • meta-virtualization layer: _https://git.yoctoproject.org/meta-virtualization_ • Autobuilder configuration: _https://git.yoctoproject.org/yocto-autobuilder2_ • Autobuilder helper scripts: _https://git.yoctoproject.org/yocto-autobuilder-helper_ • Documentation: _https://git.yoctoproject.org/yocto-docs_ • OCI image attestation storage: _https://docs.docker.com/build/metadata/attestations/attestation-storage/#attestation-blob_ • OCI image SBOM attestations: _https://docs.docker.com/build/metadata/attestations/sbom/_ Best regards, Paul Barker Ecosystem Engineering & Operations Lead, Yocto Project
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2270): https://lists.openembedded.org/g/openembedded-architecture/message/2270 Mute This Topic: https://lists.openembedded.org/mt/117955657/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
