On Thu, Mar 07, 2024 at 10:01:08PM +0000, Richard W.M. Jones wrote: > On Thu, Mar 07, 2024 at 12:39:37PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > > > The effort to make package builds in Fedora reproducible has picked > > up steam again. We now have a new website: > > https://docs.fedoraproject.org/en-US/reproducible-builds > > I read this page but it doesn't cover an important point (for me). > What's the actual threat model you have in mind? The threat model is the build machine being "compromised" and modifying the build artifacts somehow. In case of a software attack, this could mean for example a rogue version of the compiler injecting additional code into the binaries. In general, any kind of "supply chain attack". But a non-malicious scenario is also possible, with the hardware being flaky or overheated or having firmware problems that result in some modification to the output binaries. I imagine that large organizations may invest in setting up a "shadow rebuild" instance that has the full pipeline from dist-git to binary rpms and does fully independent builds of packages. 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. The build infrastracture in Fedora is obviously well protected, so such an attack would be very hard to pull off, but it also is exteremely attractive because of how effective and stealthy it would be. So by making builds reproducible and allowing 3rd parties to do rebuilds, we allow more trust to be established for our packages. Nevertheless, for me, reproducibility is interesting because it aids debugability, and "threats" are not an immediate concern. 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. E.g. today I ended up creating a pull request for intltool package [1], backporting a patch to fix a race in cache creation which was corrupting translations in files. The patch is from 2015, but seemingly nobody noticed the issue in Fedora so far. More examples are [2,3], one of the many examples of noarch packages using arch-dependent macros, e.g. %_libdir, leading to packages that are "noarch", but actually depend on the build architecture, and misbehave when installed on a system with a different architecture than the build machine. [1] https://src.fedoraproject.org/rpms/intltool/pull-request/2 [2] https://src.fedoraproject.org/rpms/xbyak/pull-request/5 [3] https://src.fedoraproject.org/rpms/python-virt-firmware/pull-request/3 Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
