I guess that rewriting liblzma in Rust would not have prevented this backdoor. But would have likely increased the confidence in its safety.
Using the build system (and potentially the compiler) to insert malicious backdoors is far from a new idea, and I don't see why this example would the only case.
It would have made it worse, because there would be 300 crates with 250 different maintainers, all pulled in by several trivial/baseline dependencies. More dependencies = higher the probability that a malicious maintainer has gotten maintainer's rights for one of them, especially because many original authors/maintainers of rust style microdepencency crates move on with their lives and eventually seek to exit their maintainer role. At least for classic C/C++ software, by the virtue of it being very inconvenient to casually pull 300 dependencies for something trivial, there are fewer dependencies, i.e. separate projects/repos, and these tend to be more self-contained. There are also "unserious" distributions like Fedora and something like stable/testing/unstable pipeline in Debian, which help with catching the most egregious attempts. Crates.io and npm are unserious by their very design, which is focused on maximizing growth by eliminating as many "hindrances" as possible.
Rust specifically chose a minimal standard library to not get stuck with the Python "dead batteries" problem. There's a strong culture as well of minimizing a project's dependencies in Rust.
Don’t know all the details and rust isn’t immune to a build attack, but stuff like that tends to stand out a lot more I think in a build.rs than it would in some m4 automake soup.
The backdoor hinged on hiding things in large shell scripts, obscure C "optimizations", and sanitizer disabling. I'd expect all of those would be a much bigger red flag in the Rust world.
This hack exploited a fairly unique quirk in the linux C ecosystem / culture. That packages are built from "tarballs" that are not exact copies of the git HEAD as they also contain generated scripts with arbitrary code.
It would not have happened in any modern language. It probably wouldn't have even happened in a Vistual Studio C-project for windows either.
`pip install` does do exactly the same thing: it downloads and executes code from a tarball uploaded to PyPi by its maintainer. There's no verification process that ensures that tarball matches what's in the git repository.
Using the build system (and potentially the compiler) to insert malicious backdoors is far from a new idea, and I don't see why this example would the only case.