As I said there, Wheeler was exemplary for handling most of this right ahead of time. He gave credit to Karger for inventing the compiler subversion attack. He wrote the reference page on high-assurance FLOSS (for compiler verification) and high-assurance SCM (for repo security, esp distribution). He also wrote a cheat I gripe about in reproducible builds to give us something to work with if high-assurance methods get ignored. Any of his stuff on this subject is worth reading.
It shouldn't be hard, and I've played with the Go AST before. I ... could :)
This was sort of a bucket list thing though, doing it a second time is less fun :p And I don't have that much time.
Why don't you try? The technique explained in the blog post is pretty universal. Go has an AST too, and while the Folder abstraction doesn't exist in its codebase (as far as I know), you can still tweak the AST. In the case of Go it would be easier to do the injection during parsing. https://github.com/golang/go/blob/5c9035acc1e1540a564ea66000... would be a good entry point. https://golang.org/pkg/go/ast/ should help.
(I am not a Go compiler dev so there may be better entry points)
> Simply recompile the purported source code twice: once with a second (trusted) compiler, and again using the result of the first compilation. If the result is bit-for-bit identical with the untrusted binary, then the source code accurately represents the binary
This sounds very familar to me. If I remember correctly, this is exactly what happens when you build GCC. GCC's 3-stage bootstrap process is well-known for a long time, as well as the decussion about whether this makes sense or is just paranoid.
It's nice to have this written down and analyzed throughly in a scientific paper, though.
I'll dig into the article, but out front there is something I don't understand. What is this second, trusted compiler? How did we get that? Why not just use that and its results, rather than vetting foreign compilers...? EDIT: Reading, but I think I'm having more questions, not less. The compiler source could introduces optimizations into the compiler binary's output that could be used to recompile the source again and get a _better_ binary right? The article speaks of compiling the source once with the the foreign compiler and then again with its results; but, on the trusted side it seems to be saying you just do one compilation and you don't compile the source again with the result of that compilation. Seems like you'd have to use the same measures on both sides before comparing binaries?
We can't. It's why we need verifiable builds. C0, CompCert, KCC, and Simpl all have strong evidence of their ability to produce correct code from good C or specs of it. Checking that on local tooling plus an assembly build of it would be a start. It can build other things.
Or you can use the incremental approach I describe elsewhere in this thread.
