Funding Projects

This pages collects ideas for projects where OpenEmbedded/Yocto project might be able procure funding to get work done on the project. If you have a proposal, please add a new heading with the information about a given proposal

Reproducible Build Improvements

Contact: Joshua Watt

Overview

There are a number of open features related to the way that reproducible are tested that could improve them to expand our coverage of reproducibility. Some or all of these might be good options to procure funding:

1. Testing final binary root file systems for reproducibility (https://bugzilla.yoctoproject.org/show_bug.cgi?id=13515)
2. Test kernel and kernel modules for reproducibility (in DEPLOY_DIR) for reproducibility (https://bugzilla.yoctoproject.org/show_bug.cgi?id=12719)
3. Support for generic reproducibility testing of DEPLOY_DIR files
4. Test native recipes for reproducibility
5. Test that nativesdk packages and SDKs are reproducible (specifically, uninative tarball and buildtools-*-tarball)
6. Fake timestamps when running reproducible builds to suss out additional reproducible problems (https://bugzilla.yoctoproject.org/show_bug.cgi?id=13509)
7. Fake current username when running reproducible builds to suss out additional reproducible problems (https://bugzilla.yoctoproject.org/show_bug.cgi?id=13511)
8. Fake hostname when running reproducible builds to suss out additional reproducible problems (https://bugzilla.yoctoproject.org/show_bug.cgi?id=13510)
9. Test additional architectures (arm64?) (https://bugzilla.yoctoproject.org/show_bug.cgi?id=13521)

Description

In software, reproducible builds [1] is the ability to build software from source, and every time the same source code is used as input, the exact same binary outputs will be produced. This is an important concept is the software supply chain, as reproducible builds allow for the detection of inadvertent or malicious source code tampering, being required to trust the tooling using to build binaries in the first place [2], and other side benefits such as reduced build times, etc. This ability is necessary for any mission critical applications where precise knowledge of where precise control over the software supply chain is of paramount importance. This includes sectors such as Automotive, Aerospace, Civil Infrastructure, Defense, and others.

Due to building not only target binaries from source, but also most of the host tools needed to build those target binaries (E.g. cross-compilers), the Yocto project is an unique position to be able to provided strong reproducible build support for users of the project. In fact, the project is already testing the reproducibility of many packages it can produce, and is doing so at a stricter sense of reproducibility than most other projects are currently achieving.

While the current testing the project does for reproducible builds give good coverage for project users, there are still places where the project can improve its testing of reproducibility and provide an even better experience to end users. These additional tests focus on expand the items covered by reproducible testing, and also expanding the mechanisms for reproducible testing to try and catch more places where non-reproducible results can creep into builds.

[1]: https://reproducible-builds.org/

[2]: Wheeler, David A. (2009) Fully Countering Trusting Trust through Diverse Double-Compiling, arXiv:1004.5534

Deliverables

• Testing root file systems for reproducibility
  1. The ReproducibleTests oe-selftest test cases are extended to test that the final images produced by a recipe are built in a binary reproducible manner
  2. The OpenEmbedded Core images core-image-minimal, core-image-sato, core-image-full-cmdline, and core-image-weston pass the test and build in a reproducible manner
  3. When a reproducible test fails for an image, a report is generated that helps users to debug the problem post-mortem (e.g. using diffoscope)
  4. Yocto project documentation is updated to describe how end users can test their own images

• Testing kernel and kernel modules for reproducibility
  1. The ReproducibleTests oe-selftest test cases are extended to test that the kernel and kernel modules produced by a kernel recipe are built in a binary reproducible manner
  2. The linux-yocto kernel and kernel modules pass the test and are built in a reproducible manner
  3. When the test fails for an kernel or kernel modules, a report is generated that helps users to debug the problem post-mortem (e.g. using diffoscope)
  4. Yocto project documentation is updated to describe how end users can test their own kernels and kernel modules

• Testing native recipes for reproducibility
  1. The ReproducibleTests oe-selftest test cases are extended to validate that the intermediate native tools used in the build are built in a binary reproducible manner
     1. This includes the files produced by a native recipe that are shared by other recipes in the Recipe Specific Sysroot
  2. All native recipes used when building the OpenEmbedded Core images core-image-minimal, core-image-sato, core-image-full-cmdline, core-image-weston, and world pass the reproducibility test -OR- an exception for a recipe is granted by the OE TSC for a recipe to dealt with later by the community
  3. When the test fails for a native recipe, a report is generated that helps users to debug the problem post-mortem (e.g. using diffoscope)
  4. Yocto project documentation is updated to describe how end users can test their own images (if required)

• Test that nativesdk packages and SDKs are reproducible
  1. The oe-selftest is extended with test cases that can validate if SDKs built from the project are binary reproducible
  2. The buildtools-tarball, buildtools-extended-tarball, and uninative-tarball are tested by default on the Yocto project autobuilder and pass
  3. Support in the tests is included for users to be able to modify the tests to cover their own SDKs if desired.
  4. When the test fails for a SDK, a report is generated that helps users to debug the problem post-mortem (e.g. using diffoscope)
  5. Yocto project documentation is updated to describe how end users can test their own SDKs

Dashboard

Contact: ????

Collect the various webpages into a single, viewable, easily locatable place