William ML Leslie <william.leslie....@gmail.com> writes: > Remember: I'm not suggesting what the outcome of your project will be, > just that if the result is negative, we still know nothing. When > testing a system for subterfuge, we need to examine *all* of the > moving parts, even those that appear to be unused. If the system you're > building your assembler on is compromised, it can still give you a > negative answer. That's what was so scary about this particular type > of attack.
If I understood Mr. Grant right, the thing is that while a number of GCC builds might have been infected a decade ago and spreading it everywhere since we all use GCC built with GCC, if we use a new language right now to verify GCC, a language which since it's new couldn't have its evaluator infected at any layer (C compiler, assembler, hardware) since it's unknown to everyone, then we can be sure. In other words, since this language with new semantics is being created right here and now, it's *very* implausible (much more so than GCC being infected) that our communications would be intercepted right away and this language's evaluator also immediately infected to make the GCC verification fail. Also, since we define a simple semantics for which a new evaluator could be implemented at any time in any language, it becomes ever more and more implausible that *all* tools everywhere have been previously "patched" to infect all the evaluators being implemented or automatically generated in all kinds of different environments. I might not have fully grokked the topic so I hope I'm not just babbling. Taylan
