4 ms·
> 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
by 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 agoYes – 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 agoNo. 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.