A left pad incident isn't possible on crates.io. Yanking a package from the registry doesn't remove the code if you have an existing lockfile.

left-pad is symbolic of dependency and supply chain issues generally. If all you took away from that incident is that there's risk only from someone unpublishing the module then you probably need to go back and think about it some more.

I think it'd be more productive to say that instead, since it's strictly more correct than comparing it to left-pad.

(An interesting thing to consider: the worst "supply-chain" type attack in recent memory is probably xz, which has a much more traditional maintenance, development, and distribution model than the median Rust package does. I don't think Rust's ecosystem is even remotely immune to the risk of malicious packages, but I imagine the kinds of dependencies that exist in the current coreutils are much more appealing to a high-sophistication attacker because of their relative lack of publicity/transparency.)

Don't chide people for failing to read your mind. If you wanted people to take that away, you should've said that. Using a specific example as a metonym for a larger phenomenon is a poor choice in terms of clarity. Of course people responded to the specific example.

Why would I take anything away beyond the specific scope of the vulnerability to supply chain issues that NPM had? Cargo offers a variety of tools for auditing and managing dependencies that specifically mitigate supply chain issues. If your only suggestion is to not use dependencies at all, that's an extreme opinion.

pretty sure you'd have to call it something else. I don't think the crates setup allows what exactly happened with left-pad to happen. It's much more likely to involve malicious code.

> There is more and more tooling around to help mitigate the risk, he said.

Could anyone expand on this? I could imagine tools... better static analysis, maybe? being able to help. But I'd really want to see details. Both to see if it really helps, and because if there is tooling to help then I want to know so I can adopt it!

Static analysis is embedded in rust, but you can't mitigate intended malicious behavior of software dependencies. That would be like a virus killer for dependencies. The past has shown that this isn't working.

There's cargo vet, cargo audit and I think various other tools. There's also a process for reporting and removing malicious ones and stuff like that, like you'd expect. Rust didn't really have a major supply chain attack as I'm avare. I remember one typo-squat with malicious code, but that was found pretty quickly and don't think it was exploited.

crates.io does not allow a dependency of another crate to be arbitrarily deleted as per their usage policy section 'package ownership' paragraph 4.

... when rewriting Linux system software, I'd only use Rust dependencies from a distro (probably something LTS, like Debian stable, or such).

Given how simple it is to use cargo, and avoiding the per distro dependency problem being one of the reasons people like rust, what are the chances people actually bother doing that? Especially given most dependencies are statically linked

I was a little horrified to see that quote, and really hope there's some context that makes it less of a disaster. That is not an appropriate answer or attitude. Also... what "tooling" is he talking about?!

The simple truth is that in "modern" package systems optimized around Reuse-Uber-Alles principles, the ability of J. Random Attacker to "get code into" a downstream app is much, much higher than it was in the days of coarse-grained projects. We need to start dealing with that as a problem to be solved and not excused away.

Just using dependencies isn't bad IMO. Your code might be of much higher quality when you use libraries that are used by many other packages instead of coding your own stuff that is only used by your package and thus less reviewed / less improved upon.

How many people do you think are reviewing stuff? Does more reviews make code better?

That is much less true than you think. It's undeniably true for "complicated" stuff. If you as an app developer roll your own DEFLATE implementation vs. using zlib, you're being an idiot, etc... But the lines around those utilities have long since been drawn already, and traditional open source projects have already organized themselves around this. We don't need crates.io to put libz.so into a separate package, it's already there.

Instead, what's left over is a bunch of random junk that saves developers 20-30 minutes of typing and Stack Overflow research. "Here's a small package to automate the creation of a zip file with this format and add a manifest file to it", stuff like that.

And more, downstreams tend not to use the whole package anyway. So you end up importing a "small" 2000-line crate just to use 7% of it. The "code quality" calculus tends to invert very rapidly when you have that kind of ratio.

> And more, downstreams tend not to use the whole package anyway. So you end up importing a "small" 2000-line crate just to use 7% of it.

Does that really matter? The compiler only includes the stuff you actually use anyways.

> The compiler only includes the stuff you actually use anyways.

Goodness, no. The compiler can elide unreferenced symbols, that's not at all the same thing as "stuff you actually use". Just build a static glibc binary someday around "int main(void) { return 0; }" for a reference as to just how much stuff can get sucked in even if you think you aren't using it.

In fact "unexpectedly included feature" was part of the xz-utils attack last year! The backdoor leveraged the fact that the openssh daemon linked against libsystemd for authentication, which links against liblzma (for some reason, I don't know why), despite xz not being required for anything in the ssh protocol. Boom.

And in that case, the two dependencies (systemd and xz-utils) were inarguably in the "complicated" category that apps can't be expected to reimplment. Think how much more complicated this gets if every bit of junk logic becomes a "dependency".

People need to be thinking about this as a problem!

Thanks. Definitely have to read more into this.

But Rust is so secure, what could ever happen? ;)