Cargo (and PyPI) is undeniably better than NPM, which is just shockingly bad for cultural reasons. Yet it's not safe, and it's subject to the same class of exploit, as we're seeing.
Indeed, the solution is to get away from the wild soup of author-managed dependencies and go with something with an audited collection of software that is maintained by separate human beings from the known-vulnerable hackers writing the software.
And indeed Go and .NET and Java all qualify. But the gold standard here is Debian and all its downstreams.
> the solution is to get away from the wild soup of author-managed dependencies and go with something with an audited collection of software that is maintained by separate human beings from the known-vulnerable hackers writing the software.
I think we might be able to crowdsource audits. At least in the Rust ecosystem I'm confident that this is feasible with the right tooling.
Is Rust ecosystem really that much better, if at all? This is a genuine question.
You can't disable build.rs, Rust Analyzer executes proc macros as soon as you open the project (and it needs to execute them in order assist the developer), minimum days since release has not yet made it into stable (though luckily it is planned for 1.100), and the number of project dependencies goes easily into several hundreds (still better than npm's few thousands, though, and I know that some deps are from Cargo workspaces), and on top of that, lots of packages stick to 0.x version for years.
Personally I see Rust community's packaging and security culture more akin to that of JS than to Java et al.
There is a reason why software foundations like the Apache Software Foundation exist and this is one of the bigger ones.
Turns out, it just doesn't make sense to be an independent open source developer of a critical dependency anymore. You can write the software yourself, but you can't publish it yourself.
All the Rust library crate developers will have to get together and start their own software foundation.
I personally don't believe the standard library argument is very convincing, because even with Java the latest newly added HTTP client has some blatant problems that require you to go with a wrapper like Methanol.
Indeed, the solution is to get away from the wild soup of author-managed dependencies and go with something with an audited collection of software that is maintained by separate human beings from the known-vulnerable hackers writing the software.
And indeed Go and .NET and Java all qualify. But the gold standard here is Debian and all its downstreams.