> 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 w

> 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.