4 ms·
Interesting proposal, but with severe risks: becoming dependent on a single specific compiler and rustc could include malicious code that isn’t obvious to an ou
by runningmike 11mo ago
Interesting proposal, but with severe risks: becoming dependent on a single specific compiler and rustc could include malicious code that isn’t obvious to an outside auditor. See https://aeb.win.tue.nl/linux/hh/thompson/trust.html https://aeb.win.tue.nl/linux/hh/thompson/trust.html Ken Thompson demonstrated this.
But what will the future of RustPython be? https://github.com/RustPython/RustPython/ https://github.com/RustPython/RustPython/
Major shifts like this are complex, not so only from a technical perspective but even more because a lot of humans with different opinions are involved. But radical changes are sometimes needed to be innovative again.
- aw1621107 11mo ago> and rustc could include malicious code that isn’t obvious to an outside auditor. I believe mrustc [0] is generally considered the current defense against a trusting trust attack, and IIRC it has verified the lack of such an attack up to rustc 1.74, which is the latest version it currently supports. Presumably whenever gccrs comes online that will be yet another defensive layer. [0]: https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc