How to talk to skeptics?

[Tristan van Berkom]

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