Have you tried Diverse Double-Compiling (DDC) to test if the official rust compiler has a backdoor?
Use crustc to compile the rust source code, producing a new compiler. Then use this new compiler and the official rustc binary, both with deterministic flags, to compile the rust source code again. The two outputs should match bit for bit.
This was done with mrustc, which produced byte identical output.
Better than that, you can get a bootstrapped rust from the Guix project, which has bootstrapped its entire system from source code from only a tiny verifiable binary.
It's not diverse in that case - it's the same compiler source compiled to binaries twice - it's just that with one compiler you've gone via a C intermediate representation. For the purposes of diversity it's the same as compiling rustc with the cranelift/gcc backend.
From a "trusting trust" point of view, compiling rustc-translated-to-C with a C compiler (and comparing the result to normally-compiled rustc) is a valid demonstration, because we're again starting from code and can eliminate the possibility of a binary-resident compromise.
The actual issue here is that the translation was done using a rustc backend, and therefore an existing rustc binary which could be compromised and inject a "if (user=="wmanley") {...}" that isn't present in the original Rust code. If cilly was completely standalone (like mrustc), or if you had a rustc+cilly build you trusted, there would be no issue.
This reminds me of https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
The sole and entire purpose of Diverse Double-Compiling is addressing Thompson's Trusting Trust: https://dwheeler.com/trusting-trust/
I didn't know there's a solution, thanks!
I'm also a fan of https://www.teamten.com/lawrence/writings/coding-machines/
Reflections on Trusting TRust.
tRust
Awesome idea!