Hacker News Reader

Comment by stephc_int13 | Hacker News Reader

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.

View on HN

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.

Why is rust beginning to sound like JavaScript?

Modern coders have been conditioned to import random libs to save 30mins work.

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.

> Rust specifically chose a minimal standard library to not get stuck with the Python "dead batteries" problem.

So has C++ in the past although there seems to be a push for a more batteries included approach recently.

> There's a strong culture as well of minimizing a project's dependencies in Rust.

This doesn't match what anyone can observe by looking at dependencies of Rust projects.

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.

There was a drama back then where serde tried to ship its derive macro as a precompiled binary: https://news.ycombinator.com/item?id=37189462

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.

> It would not have happened in any modern language.

It would. pip for example installs from tarballs uploaded to PyPi, not from a git repository.

Pip and similar are their own can of worms yeah. They trade convinience for an almost complete lack of oversight.

But in this case we are talking about people (distro packagers) manually downloading the source and building it which is not quite the same thing.

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

Yes I know, and that's what I meant when I said "their own can of worms".

Distro-provided python packages don't use pip however, at least afaik.

The distro-provided Python packages are usually still build from the source on PyPi as uploaded by the maintainer, not what's in git.

Funny you should say that, given they definitely have exploit code in `vcpkg`

If it were using Cargo as its build system, it might make such manipulations more obvious / understandable?

Reply on news.ycombinator.com