6 ms·

Reproducible builds do not solve the problem of a compiler bug being used to introduce a backdoor during the translation from source code to binary.

kuschku 11y ago
Yes, they do – you take a C compiler (written in ASM) that is just good enough to compile TCC, now you prove that the source of TCC and GCC is right, you compile TCC with your simple compiler, then compile GCC with TCC, and you have a compiler which is guaranteed to be free of such backdoors. Now, you compile your code with this compiler, and if your own build reproducibly has the same results as this verified compiler, you're safe.
- AgentME 11y ago
  That defends you from a different type of attack. That can't fix bugs in your compiler or minifier. See https://zyan.scripts.mit.edu/blog/backdooring-js/ https://zyan.scripts.mit.edu/blog/backdooring-js/
  - kuschku 11y ago
    Your attack only applies if my minifier is wrong. My solution even protects me from attacks where the source of the minifier is safe, and only the minified minifier contains the bug.
- pascal_cuoq 11y ago
  > guaranteed to be free of such backdoors. You are thinking of another kind of backdoor than the one being discussed. The backdooring technique being discussed relies on a compiler bug hidden in plain sight in the compiler's source code. It has not been sneaked into the binary with a “trusting trust”-like technique. The bug is just an ordinary compiler bug, you do not need to be the one who put it there, it can be a known, published bug and have already been fixed in the compiler's development version (although you can also have found the compiler bug yourself and have omitted to report it for maximum sneakiness). Re-compiling the compiler does not make the bug go away. Compiling GCC with TCC does not fix bugs in GCC (otherwise people would be doing it more often).
  - kuschku 11y ago
    Yes – the only attack my solution does not apply against is if the compiler actually has a backdoor. But debian assumes their compilers do not. Which is the premise for this whole discussion.
    - pascal_cuoq 11y ago
      No. The discussion is about compiler bugs. The attack “your” solution does not apply against is if the compiler actually has a bug. Compiler have bugs, and some of these bugs cause them to silently emit the wrong assembly code for the source program passed to them. One of the authors of the original article that inspired bcrypt's blog post reported hundreds of bugs in Clang and GCC, of which about half are “wrong code” bugs: https://github.com/csmith-project/csmith/blob/master/BUGS_REPORTED.TXT https://github.com/csmith-project/csmith/blob/master/BUGS_RE... You are right that Debian and other distributions assume that compilers do not have “wrong code” bugs, though. The only problem is that this is not true.

kuschku 11y ago

Yes, they do – you take a C compiler (written in ASM) that is just good enough to compile TCC, now you prove that the source of TCC and GCC is right, you compile TCC with your simple compiler, then compile GCC with TCC, and you have a compiler which is guaranteed to be free of such backdoors. Now, you compile your code with this compiler, and if your own build reproducibly has the same results as this verified compiler, you're safe.

AgentME 11y ago
That defends you from a different type of attack. That can't fix bugs in your compiler or minifier. See https://zyan.scripts.mit.edu/blog/backdooring-js/ https://zyan.scripts.mit.edu/blog/backdooring-js/
- kuschku 11y ago
  Your attack only applies if my minifier is wrong. My solution even protects me from attacks where the source of the minifier is safe, and only the minified minifier contains the bug.
pascal_cuoq 11y ago
> guaranteed to be free of such backdoors. You are thinking of another kind of backdoor than the one being discussed. The backdooring technique being discussed relies on a compiler bug hidden in plain sight in the compiler's source code. It has not been sneaked into the binary with a “trusting trust”-like technique. The bug is just an ordinary compiler bug, you do not need to be the one who put it there, it can be a known, published bug and have already been fixed in the compiler's development version (although you can also have found the compiler bug yourself and have omitted to report it for maximum sneakiness). Re-compiling the compiler does not make the bug go away. Compiling GCC with TCC does not fix bugs in GCC (otherwise people would be doing it more often).
- kuschku 11y ago
  Yes – the only attack my solution does not apply against is if the compiler actually has a backdoor. But debian assumes their compilers do not. Which is the premise for this whole discussion.
  - pascal_cuoq 11y ago
    No. The discussion is about compiler bugs. The attack “your” solution does not apply against is if the compiler actually has a bug. Compiler have bugs, and some of these bugs cause them to silently emit the wrong assembly code for the source program passed to them. One of the authors of the original article that inspired bcrypt's blog post reported hundreds of bugs in Clang and GCC, of which about half are “wrong code” bugs: https://github.com/csmith-project/csmith/blob/master/BUGS_REPORTED.TXT https://github.com/csmith-project/csmith/blob/master/BUGS_RE... You are right that Debian and other distributions assume that compilers do not have “wrong code” bugs, though. The only problem is that this is not true.