<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html lang="de" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><title></title><style type="text/css">html,body{background-color:#fff;color:#333;line-height:1.4;font-family:arial, helvetica, sans-serif;;}</style></head><body><p>Hello all</p>
<p>Yes that is true what Tristan wrote.</p>
<p>By myself I have introduced reproducible build approaches for controlling software in plants, because I want to know whether the old given sources (from archive) firstly produces the same code which was delivered on plant in the past, before (!) I do some fixes. Why? The possibility that something may be wrong cannot be excluded (faulty include path on build, changed tools, confuse what are the real true sources,...). </p>
<p>If the new build delivers the exact same binary (after a long time, on maybe changed environment), only then I am free to work on a fix, without trouble that some trouble comes to me because unknown reasons.</p>
<p>After fix the sources, it is also nice to compare for example Object files, or parts of binaries, which should not be changed, whether they are really not changed. </p>
<p>The benefit comes on test. In my understandment, if a binary is changed and it is unknown what is impacted, ALL functionality should be tested (a high effort on plant software). But if I am sure that some binaries are not changed, there behavior is expectable the same, and I can prove to the organizers of the plant test, which tests are really necessary, and which should be only tested with reduced effort. And this saves many money (time of test hours) - or can be used with the same time budget to more elaborately test the really sophisticated thinks. </p>
<p>That I have done by myself as software developer, only by tuning some conditions for build (for example using anytime exact the same drive and path of sources, the paths are written in Objects, and influences also the binaries) - some years ago. I hope other colleague of this team (I am yet outside) have understand this approach, unfortunatelly it was never in focus of adminstration. Reproducible build seems to be not in focus of software management in most companies. That is the problem. </p>
<p>I hope I have well contributed in thinking about this topics.</p>
<p>Best regards from Hartmut Schorrig, Germany. My own web page is <a href="http://www.vishia.org" target="_blank" rel="nofollow noopener">www.vishia.org</a></p>
<p> </p>
<div ></div>
<p>Tristan van Berkom schrieb am 17.12.2022 07:04 (GMT +01:00):</p>
<blockquote cite="mid:8c4653e2b6524949ded717615da6cc78c6b7a91c.camel@codethink.co.uk">
<pre>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: <a href="https://buildstream.build/" target="_blank" rel="nofollow noopener" title="https://buildstream.build/">https://buildstream.build/</a>
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:
<a href="https://www.codethink.co.uk/articles/2021/deterministic-construction-service/" target="_blank" rel="nofollow noopener" title="https://www.codethink.co.uk/articles/2021/deterministic-construction-service/">https://www.codethink.co.uk/articles/2021/deterministic-construction-service/</a>
Feel free to take or leave anything from this, just felt by now it was
time to throw in 2 cents ;-)
Cheers,
-Tristan
</pre>
</blockquote></body></html>