Hello Bernhard, Due to my propensity to writing overly long and detailed emails, I have refrained until now from ever posting to this list, I'll try to be brief :)
Some background, I am an author and maintainer of the BuildStream project: https://buildstream.build/ Which is an integration (build orchestration) tool we developed at Codethink, some of our primary goals are: o Build repeatability: The ability to repeat the build process which led to producing a given build result in perpetuity. o Build reproducibility: Providing an environment which is most conducive to bit-for-bit reproducibility of builds (the reason I follow this list). And various other things, we aim to solve the build problem for complex integrated systems in a way that is decoupled from the payload you are building, instead of being another build solution that is developed as an afterthought of creating a distribution (payload). As such, we have over the years developed some rhetoric in favor or build reproducibility. On Wed, 2022-12-14 at 20:30 +0100, Bernhard M. Wiedemann via rb-general wrote: > Hi, > > a colleague of mine is rather skeptic towards bootstrapping and > reproducible-builds. > [...] I'm mainly posting here today to say that I find it confusing that in the recent couple years, the argumentation in support of build reproducibility on this list appears to have been solely focused on security. I think it started with a thread on this list where it was claimed that reproducibility would have prevented a notorious supply chain attack (which arguably it could have been, and perhaps arguably other measures could have prevented such, and perhaps taking all measures to prevent supply chain attacks is a good idea). While this security related rhetoric is compelling, I feel that it leaves out other important aspects. To my mind, one of the bigger value adds of having reproducibility is in validation, more specifically the avoidance of expensive/extensive validation of build artifacts which have not changed as the result of upgrading some dependencies. While of course unchanged binary executables still require validation against changed execution contexts (e.g. upgraded kernel, or changed adjacent services this binary may talk to over some IPC), simply knowing which build artifacts have changed as a result of some underlying changes brings huge value in validation. Another point worth making in the security and safety related spaces, is that while some arguments can be made for the trust in a binary itself based on its reproducibility in varied build contexts (which seems to be along the lines argued in the "you dont need..." link provided in this thread), there is the opposite argument which can be made that reproducibility itself serves as a valuable interrogation of the supply chain and build environment. In other words, having reproducible builds in your organization can be used as evidence to demonstrate that your organization does indeed have strict control over all build inputs and infrastructure, and non- reproducible outputs serves as an alarm which tells you that something might be compromised (non-deterministic contaminants were introduced somehow, perhaps by way of random source code/data being downloaded from the internet). I'll also provide this link to an article by our team, outlining a project where build reproducibility played a large part in our ability to acquire an ISO 26262 certification: https://www.codethink.co.uk/articles/2021/deterministic-construction-service/ Feel free to take or leave anything from this, just felt by now it was time to throw in 2 cents ;-) Cheers, -Tristan