reproduciblebuilds/docs-site
2
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Expand benefits section

Browse source
This commit is contained in:
Davide Cavalca 2024-03-08 16:12:13 -08:00
commit 0fdf1fa4f3
1 changed files with 4 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

6
modules/ROOT/pages/index.adoc
View file

@ -17,7 +17,9 @@ In Fedora, all packages that are distributed to users are built in the centraliz
Because of this strong control over the build process, reproducible builds haven’t historically been a priority in Fedora.
== Benefits
Let’s image what would happen if the hardware was broken: overheated memory on one builder does bit flips, corrupting output rpms in a subtle way. If we are able to redo any build, it would be fairly easy to verify whether this is the case. If we had a process of doing “shadow” reproducible builds for all packages, we could even detect such cases before any bug reports from users. Similarly, we could detect if a builder machine was compromised in some sort of a supply-chain attack to inject rogue code into the rpms.
Let’s image what would happen if the hardware was broken: overheated memory on one builder does bit flips, corrupting output rpms in a subtle way. If we are able to redo any build, it would be fairly easy to verify whether this is the case. If we had a process of doing “shadow” reproducible builds for all packages, we could even detect such cases before any bug reports from users. Similarly, we could detect if a builder machine was compromised in some sort of a supply-chain attack to inject rogue code into the rpms. Reproducibility allows independent verification that the dist-git sources actually correspond to the binaries that are delivered. With such checks, any kind of supply chain attack would be very hard to do undetected.
Reproducibility is also interesting because it aids debugability. Essentially, when the builds are stable, any unexpected change in the build outputs is much easier to diagnose. We have already found and submitted a bunch of obvious fixes that would not have been found otherwise. Also, when builds are stable, when working on the tools, it is easy to do a rebuild with the patched tools and observe the diff. If the build is "unstable", i.e. there are various other unrelated changes, interesting differences often drown in noise.
== Caveats
In the Fedora ecosystem, we cannot achieve reproducibility by the reproducible-builds.org definition. A fully identical result cannot be achieved, because rpm packages are distributed after signing, with the signature is embedded in the rpm (while Debian uses detached signatures). A rebuild of a package (as distributed to users) will always differ at least by this missing signature. In principle, a rebuilder could build an identical rpm and then transplant the signature from the original rpm onto the rebuilt rpm, but that wouldn’t meet the requirements either, as the premise is that the rebuild has to be reproduced without access to the build artifacts. The use of detached signatures in RPM has also been https://github.com/rpm-software-management/rpm/issues/1482[proposed] and rejected before.
@ -32,7 +34,7 @@ A build is reproducible if given the same source code, build environment and bui
We believe would still be useful to users, because it would allow them to verify that the build that was done in the official build system is trustworthy, by doing a comparison that ignores the short list of fields which are known to vary.
== Status
This work was kicked off from an initial discussion at the https://devconfcz2023.sched.com/event/1MYo0/rpm-developers-meetup[RPM developer's meetup] during https://www.devconf.info/cz/[DevConf.CZ 2023]. That led to the organization of a https://flock2023.sched.com/event/1Or8e/hackfest-reproducible-builds[hackfest] during https://flocktofedora.org/[Flock 2023], where we formalized goals, defined a general approach and started documenting known issues on the https://pagure.io/fedora-reproducible-builds/project[Pagure tracker]. A recap of this event was https://discussion.fedoraproject.org/t/report-from-the-reproducible-builds-hackfest-during-flock-2023/87469[published] on Discourse and provided the starting point for this documentation.
This work was kicked off from an initial discussion at the https://devconfcz2023.sched.com/event/1MYo0/rpm-developers-meetup[RPM developer's meetup] during https://www.devconf.info/cz/[DevConf.CZ 2023]. That led to the organization of a https://flock2023.sched.com/event/1Or8e/hackfest-reproducible-builds[hackfest] during https://flocktofedora.org/[Flock 2023], where we formalized goals, defined a general approach and started documenting known issues on the https://pagure.io/fedora-reproducible-builds/project[Pagure tracker]. A recap of this event was https://discussion.fedoraproject.org/t/report-from-the-reproducible-builds-hackfest-during-flock-2023/87469[published] on Discourse and provided the starting point for this documentation. The project itself was formally https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NRRAH67FZXVKGERYTBSVL6QIQ57BXXBG/[announced] on the Devel list in March 2024.
== Resources
* Issue tracker: https://pagure.io/fedora-reproducible-builds/project