The more I read about Ken and Russ's admiration for Ken's work, the more I think there is an Easter egg in the Go compiler. It looks like Russ has long planted

The more I read about Ken and Russ's admiration for Ken's work, the more I think there is an Easter egg in the Go compiler. It looks like Russ has long planted the seed for his own Turing Award. From the article: > Today, however, the Go compiler does compile itelf, and that prompts the important question of why it should be trusted, especially when a backdoor is so easy to add. The answer is that we have never required that the compiler rebuild itself. Instead the compiler always builds from an earlier released version of the compiler. This way, anyone can reproduce the current binaries by starting with Go 1.4 (written in C), using Go 1.4 to compile Go 1.5, Go 1.5 to compile Go 1.6, and so on. There is no point in the cycle where the compiler is required to compile itself, so there is no place for a binary-only backdoor to hide. I think that this paragraph gives just hints on where to look for: * there is no "binary-only backdoor", so I'm expecting the backdoor to be available in the source distribution of Go. * the backdoor is either in each release and/or is propagated from one release to the other There is a feature of the Go compiler that I mistrust: //go:embed. I expect it could be a good vehicle to inject source code that isn't in the repository as a file. Especially as Russ himself is deeply involved in the design (see https://youtu.be/rmS-oWcBZaI https://youtu.be/rmS-oWcBZaI?). I also mistrust the vendored packages as a way to have backdoor code in the distribution. Normal Go programs are not allowed to import code from packages cmd/vendor/..., but what if the compiler was lifting that limit for himself?