The compiler-based backdoor is described by the authors in PoC||GTFO #8:

https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf

Note that this isn't "Reflections on Trusting Trust" - the backdoor in question relies on specific non-buggy code in "sudo" triggering a pre-existing miscompilation bug in clang 3.3. If you examine the source to sudo, the backdoor isn't there; if you compile it with any other compiler, the backdoor doesn't exist.

Except that it requires a patch to sudo to work.

It is more a question of, can I socially engineer a way to get a snippet of code into a project, that looks innocent (and is), but exploits version specific compiler bugs.

One absolute way to defend against a compiler-based backdoor is to not use a compiler at all...

I've thought about how one could create a computer system that one could absolutely trust to be free of any outside interference - one that would have to be built "from scratch" by its owner - and if you assume that the hardware is OK (presumably because you built it yourself from equally simple components), it inevitably begins with manually entering individual bits into memory.

Looking at the complexity of modern software stacks, and all the chances for bugs they introduce, perhaps we should not be stacking abstractions higher but wider, and making systems simpler overall.

One way of defending against compiler-based backdoor would be to make the compiler binary as audit-able as possible (or to make it as easy as possible to be implemented "from scratch"), i.e. for it to be as small as possible, and what you've suggested comes out as a consequence - not stacking abstractions on the compiler, or at least not on the compiler's lowest level (that gets translated into machine code). The simplest implementation as I see it is to rely on a very small core of language primitives like C (although a simpler core was possible even there).

"Be suspicious of baroque patch submissions"

"baroque" strikes me as a bad metaphor.

If you look at the patch/backdoor, I would have come to the same wording.

    /∗ Perfect hash function for mapping debug 
       levels to intended verbosity ∗/
    #define DEBUG_TO_VERBOSITY(d) \ (5%(3 ∗ (d))+2)

You could call that over-engineering also, but baroque is a better name.

I googled "baroque patch submissions" to see if it was in common use; now I think about it, its quite ironic that the phrase is rather self referential.