Ken Thompson presented an interesting paper back in 1984:
https://dl.acm.org/doi/pdf/10.1145/358198.358210
I continue to wonder at the collaboration that ocurued at Bell Labs in those days:
I have not worked on mainstream UNIX in many years, yet I continue to get undeserved credit for the work of others. Therefore, I am not going to talk about
UNIX, but I want to thank everyone who has contributed.
That brings me to Dennis Ritchie. Our collaboration has been a thing of beauty. In the ten years that we have worked together, I can recall only one case of miscoordination of work. On that occasion, I discovered that we both had written the same 20-line assembly language program. I compared the sources and was astounded to find that they matched character-for-character. The result of our work together has been far greater than the work that we each contributed.
In this paper, Ken describes modifying a program that will perpetuate a bug, even after it has been removed from the source code. Following this, the comment is made:
The moral is obvious. You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code.
Russ Cox recently published a follow-up to this paper:
https://research.swtch.com/nih
In this article, Russ reproduces Ken’s experiment and then discusses how they handle this in the Go project:
Today, however, the Go compiler does compile itself, 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. In fact, we recently published programs to make it easy to rebuild and verify the Go toolchains, and we demonstrated how to use them to verify one version of Ubuntu’s Go toolchain without using Ubuntu at all. See “Perfectly Reproducible, Verified Go Toolchains” for details.
It is nice to see people working at levels like this, but trust is still essential in this world – we just can’t get around that.