gnu-misc-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Risks of deterministic builds (was: Re: Truth matters when writing s


From: Martin
Subject: Re: Risks of deterministic builds (was: Re: Truth matters when writing software and selecting leaders)
Date: Tue, 6 Apr 2021 09:22:08 +0000

On 4/6/21 7:40 AM, Jean Louis wrote:
* 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.
If you have a source code that types of exploits are also easier to detect. Besides you can always compile your software with different flags then the one used by default. Reproducible-builds just gives you information that for a fixed environment you have the fixed binaries but usually the combinations of settings are very wide and it's only up to you how your binaries are distributed in the end.
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.
So far debian is still one of the safest linux distribution in the world. Anyway even debian is giving you the option to compile all their software from source codes and again you can tune it as you like in your custom dev environment producing completely different binaries than others do.
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.
Maybe freedom in "free software" shouldn't require from the code to be open neither. Let's just blindly trust some saint developers who cannot even control their own binaries. Actually today we are closer and closer to that sad scenario like never before in the history, because in fact most of the open-source and GNU "free software" nowadays base on blackboxed binary seeds that cannot be verified by the users not even by the core developers.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]