Diverse double compiling is not "checksums and versioning". You need other compilers from sufficiently different sources as to minimize the chance that they all were subject to the same modification.
Edited to add:
Which is to say, it's actually a pretty cool idea, and not super complicated[1], and amazing it took 20ish years to spot.
[1] Though do be careful; I'm amazed at the number of comments that misunderstand it.
>Diverse double compiling is not "checksums and versioning". You need other compilers from sufficiently different sources as to minimize the chance that they all were subject to the same modification.
I was assuming you would write your own.
Of course, if you keep going along this line of thinking, you end up wire wrapping your own computer and writing your OS and other utilities in assembly.
That only works if you do it in machine code (and your hex-editor is clean). The point of the whole thing is that you can use compilers from untrusted sources, just provided you use several of them, and trust that at least one of the compilers you are checking won't have the same modifications as the others.
> That only works if you do it in machine code (and your hex-editor is clean).
Not necessarily. It would be very hard to get a ken trojan to propagate if you were to write your compiler in a high-level language such as python and then use a C compiler to Compile the Java runtime which you would use to run a C compiler to compile say go, then use the go-based c compiler to compile the python source, which you would then use to compile gcc. Gcc would then compile itself, resulting in an almost certainly clean gcc. If the gcc were compiled by the go compiler, presumably that gcc would be functionally equivalent to any other gcc binary of the same version. If it's functionally equivalent then when you compile the clean gcc with your go compiled gcc, it should be binary equivalent to any other gcc binary compiled with the same compiler, flags, and version.
EDIT: Now that I think about it, you wouldn't need to write your own compiler at all at that point, making your earlier point correct. But I meant something else when I was talking about checksums and versioning.
You then compare the checksum of your final result with the one on the server, if they don't match theres probably a problem.
Another approach would be to use assembly to implement a higher level language such as scheme, and then use that to write a C compiler.
Also, I would pay $50 to see a hex editor or assembler that can detect that it is writing a C compiler in all possible cases and bug the users final program.
Of course, none of that matters if your hardware has a backdoor in it. So everything enumerated here depends on the assumption that your hardware is trustworthy.
