Re: Risks of deterministic builds (was: Re: Truth matters when writing software and selecting leaders)

[Jean Louis]

* Jacob Bachmeyer <jcb62281@gmail.com> [2021-04-06 05:39]:
> Exploits are easier to develop when hardcoded offsets, virtual addresses,
> etc. can be used.  In a "binary monoculture" environment, that is possible.
> This contributes to and worsens security problems in proprietary software,
> which is almost always distributed as a single identical set of binaries.
> 
> Reproducible builds are useful for validating the compiler, but there is a
> potential downside in that they make any exploit that can be found in the
> reproducibly built program much more reliable, since everyone will have
> exactly identical binaries.  Note that this is an identical risk with binary
> distributions:  if you simply install the binaries form Debian, an exploit
> can be tuned to Debian's version of that binary and it will work on your
> machine.
> 
> 
> -- Jacob

That is right.

>From practical viewpoint, among milions and millions of users, when it
comes to validating compiler, they would have to validate the
reproducible build with comparison to something. Benefits of
reproducible builds thus depend of number of people validating it and
reporting problems. It depends of publicity of problems and
research. Small group of people may do the work, but they cannot
possibly make sure to do the work for ALL distributions and for all
people. Thus practically for an individual it means nothing, unless
individual is highly skilled to verify internals of the compiler, and
we have plethora of compilers on every single GNU/Linux operating
system. Thus whole countries may be converted into spying backdoor
teams by using marketing of reproducible builds of packages that
people cannot really verified. Reproducible build of system is not
yet reality. We hope for it in future.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/