Reproducible Builds can help you build your code in the future

This post introduces the reproducible build and how we can plan to take advantage of its features during the software release process.

The main goal of reproducible builds [^1] is to ensure that a set of source code will always produce the same binary. In other words, to make sure the build process is deterministic.

The Yocto Project implements reproducible builds [^2] to basically create the same binary from the same source code and build configuration, no matter when it happens.

There are several benefits of using a reproducible build. Let's list some of them:

• Control if there is an unrequested injection of source code (with potential for vulnerabilities) in preexisting source code

• Being able to build an old* release again; for example, to fix a vulnerability or include a bug fix

• With SBOMs, a binary release can get the source code tracked for release management and audits

The steps you need to execute today and then build again in the future:

1. Tag your release: This could mean creating one tag for each meta-layer used. However, if you use FoundriesFactory®, you can just tag your lmp-manifest. This manifest includes the git hash for all the meta-layers used in the project.

2. Backup the meta-layers source code: If you are using git, this step is unnecessary—the source code is already in the git repository. If you use FoundriesFactory, the source code is safe in the server and backed up. Understand Factory data retention policies[^4].

3. Keep an offline copy of the packages used: You can use bitbake <image> -c fetchall to download source code from every package. Remember to configure DL_DIR, where all the packages will go. If you use FoundriesFactory, the fetch dependency is already backed up in the server.

4. Backup the Dockerfile: It is highly recommended to build the release using a container so you can use the same container in the future and avoid worrying about OS dependencies. If you are using FoundriesFactory, you are already building inside a container and don't need to worry.

These steps and some Gigabytes should be enough to preserve an environment where you can rebuild a release. Remember, this is only one aspect of reproducible builds. We can explore others in the future.

* The Yocto Project has supported reproducible builds since Dunfell, but other aspects can impact the build feasibility.

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

[^2] https://wiki.yoctoproject.org/wiki/Reproducible_Builds

[^3] https://docs.yoctoproject.org/singleindex.html#document-test-manual/reproducible-builds

[^4] https://docs.foundries.io/latest/reference-manual/factory/data-retention.html