Re: Risks of deterministic builds (was: Re: Truth matters when writing software and selecting leaders)
* Martin [2021-04-06 12:22]: > > 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. I say you are right there, only that irony is not really in place. I admire your perfectionism. - practically, majority of GNU/Linux and BSD-derivatives blindly trust their developers. It is how it is. Just few of them are actual developers who verify things and develop, and submit issues, find security problems and so on. We rely on our developers. - developers can to a degree control their binaries. It is questionable if they can boostrap compilers from pure sources, so they trust their upstream compiler providers like GNU GCC, or Haskell's origins, or other compilers. Guix is making effort and some other OS-es to make it boostrapable. - yes, with larger number of people using GNU/Linux we are closer and closer to scenario of blindly trusting our distributions. That is not good. Common users cannot anyway verify software. - You are right, that now, at this point of time, we should point out to that issue, as now it is important when it is not too late. Maybe it is too late for Haskell. I know for GCC is not too late as Guix can bootstrap it or almost bootstrap it. Not sure. If we don't point from today on about this issue, we will get serious problems in future. Awareness we need. Something practical has to be done about that. Did you contribute to Guix with your knowledge? -- 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/
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 [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.
Re: Risks of deterministic builds (was: Re: Truth matters when writing software and selecting leaders)
* Jacob Bachmeyer [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/
