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

On 4/6/21 7:40 AM, Jean Louis wrote:
> * Jacob Bachmeyer <[email protected]> [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.