71–80 of 137 posts
Earlier quoted context omitted.
So if you want to avoid trusting trust, you need to audit not only a C compiler and the source code for the Go compiler you plan on using, but also every past Go compiler as well?
You can't avoid trusting trust. "Ken was here" :)
Here we go again. Another compiler that can't be bootstrapped from source code. It's a packaging nightmare. Another magic binary to trust not to have a Thompson virus.
It can be bootstrapped from source - it just needs to be bootstrapped either using gccgo[0], or using the 1.4 compiler (which is guaranteed to work for all 1.x compilers, not just 1.5)
> Another magic binary to trust not to have a Thompson virus.
"Reflections on Trusting Trust" gets posted on HN regularly, and it's an interesting exercise, but you are far more likely to have an exploit hiding in plain sight in a compiler compiled from source once than you are to have one that only appears after multiple iterated compilations.
It's a good concept for security experts and compiler developers to be aware of, but the likelihood is incredibly small.
Also, for what it's worth, "Trusting Trust" is over three decades old, and there have been numerous response to it in the interim, with lots of study. It's like saying "Your problem reduces to 3-SAT, and satisfiability is NP-hard, so you can't solve it', throwing your hands up, and leaving it at that. In reality, solving 3-SAT in the general case is NP-hard, but it is well-studied enough that, in practice, solving SAT/3-SAT is actually pretty easy most of the time. Some of these responses have even been posted elsewhere in this thread, though they're also pretty easy to find online as well.
[0] which is written in C++ - frankly, I'd be much more concerned about a single-compilation bug in any C++ code than I'd be about a multiple-compilation bug in Go.
Earlier quoted context omitted.
So if you want to avoid trusting trust, you need to audit not only a C compiler and the source code for the Go compiler you plan on using, but also every past Go compiler as well?
You can't avoid trusting trust. "Ken was here" :)
So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler? Maybe it matters less, you used to always assume bootstrap from C but that more or less died with C++ based compilers, although you can do a multistage bootstrap from the last gcc before C++ still.
Earlier quoted context omitted.
It is explained in the design document: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw... Basically, you start from the last C version, and every version is supposed to be able to compile the next one.
So if you want to avoid trusting trust, you need to audit not only a C compiler and the source code for the Go compiler you plan on using, but also every past Go compiler as well?
[0] http://www.dwheeler.com/trusting-trust/dissertation/html/whe...
So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler? Maybe it matters less, you used to always assume bootstrap from C but that more or less died with C++ based compilers, although you can do a multistage bootstrap from the last gcc before C++ still.
What's the bootstrap process for the C compiler part of the compiler?