Skip to content

The Yocto Project - Where We’re Going and What’s Next - Philip Balister, The Yocto Project

Philip BalisterRoss BurtonTim

Blue TeamThe Linux Foundation37 minOpen on YouTube ↗

Investigates the Yocto Project - Where teamsre Going and Whats Next - Philip Balister, The Yocto Project and evaluates key implications for security practitioners.

Summary

### Overview Philip Balister outlines the history, current state, and five-year strategic plan for the Yocto Project. Originating in 2010 as the first Linux Foundation collaborative project to address maintenance fragmentation in OpenEmbedded, Yocto has grown into a member-supported organization backing embedded Linux development. However, widespread commercial adoption has pulled experienced developers into private industry, leaving core infrastructure, tooling, and ecosystem maintenance under-resourced. Balister details an Advisory Board initiative that established a Five-Year Plan and published an RFQ (Request for Quotations) to fund and staff critical maintenance, testing, and developer tooling.

### Key Topics - **Project Sustainability & Funding:** Relying on membership dues (Silver, Gold, Platinum) and RFQs to finance dedicated work, maintainers, documentation, and core infrastructure like the AutoBuilder. - **Patch Submission & Testing:** Reviving `patchtest` on top of an updated Patchwork branch, enabling local test execution, and reducing patch integration failures across diverse configurations (such as musl libc). - **Developer Tooling & UI:** Modernizing Toaster to inspect complex dependency graphs, improving `recipetool` and `devtool` to support newer languages (Rust, Go) and Python versions, and building VS Code / IDE integrations for remote debugging and SDK workflows. - **Layer Management & Binary Artifacts:** Addressing fragmented layer setup practices (e.g., git submodules, kas, combo-layer, bitbake features) and exploring shared state CDN acceleration and binary distribution prototypes. - **Security & Ecosystem Health:** Transitioning security from volunteer efforts to a dedicated security team, establishing formal processes, supporting SPDX 3.0 SBOM generation, and actively pruning or updating unmaintained recipes in `meta-openembedded`.

### Technical Details - **Testing Infrastructure:** The project's AutoBuilder runs extensive test matrices (approx. 50 jobs per patch bundle) across hardware targets, QEMU, and configurations like musl. - **Maintenance in meta-openembedded:** Unlike OpenEmbedded-Core, sub-layers (such as `meta-python`, `meta-oe`, `meta-networking`) suffer from uneven maintenance. Proposed upgrades include automated CVE checks, the Automated Upgrade Helper (AUH), expanded p-tests, formal source mirroring for LTS releases, and reproducible build enhancements. - **Security & Hardening:** Discussions during the talk confirmed that hardening systemd services is supported via proper service configuration and enabling libraries such as `libseccomp`. - **CROPS & Containerization:** Audience contributor Tim detailed the evolution of CROPS from host-abstraction tooling (running builds across macOS/Windows) into reproducible build containers, noting recent efforts around a kconfig-based container generator to help vendors customize and package SDK containers. - **Release Lifecycles:** The release cadence remains a six-month cycle, with Long Term Support (LTS) releases extending to four years of support.

### Takeaways The Yocto Project's Five-Year Plan identifies key technical debt across patch validation, layer management, modern language packaging, and security response. Overcoming the "bus factor" and revitalizing lagging tools requires broader organizational investment, whether through Linux Foundation membership, dedicating engineering cycles to upstream contributions, or bidding on tasks outlined in the published RFQ.

Related talks