71–80 of 529 posts
Earlier quoted context omitted.
> Who is funding this security audit? Are folks supposed to volunteer their free time? Same people who keep the whole rust project going, a lot of those are volunteers aren't they? Not mad to think they could do the same for core packages at least
It’s absolutely mad and extremely entitled to expect that a volunteer group of developers do an order of magnitude or more additional work for no additional pay or benefits to themselves.
Why this still happens? Why after many previous supply-chain attacks maintainers of package repositories still allow anyone uploading packages and pushing updates without security audit?
Mozilla, Google and a couple of others are publishing their audits through cargo vet. There are also additional audits done by individuals you can use through cargo crev. Overall the number of audited crates is in the thousands and you will find audits for most of the popular crates. In the end it is your decision to use unaudited or refuse unaudited crates.
It should be the default behavior of the package manager to allow downloading only audited/trusted packages. Forcing end-users of the language to be responsible for audit of all dependencies is impractical.
Use containers for development. And reduce the amount of third party deps you import into your projects. This is only going to get worse.
Doing software development outside of strict containerization, at the very least, looks increasingly prone to disaster. Yes, we can argue about the culture of package management (as some of us have with especially npm from day one), but it's done, and your colleagues or AI sidekicks cannot be trusted not to download whatever and try to build and run it. All you can do is limit the effective blast radius.
minimum-release-age
In the mean time I think it's possible to hack Cargo and run all build scripts in a microVM. The blast radius will be limited to malicious code in the binary instead of uploading all your CI secrets and deleting the whole hard drive.
Cargo desperately needs sandboxing for build.rs scripts. It’s been attempted before, but didn’t go very far¹. ¹ https://rust-lang.github.io/goals/2024h2/sandboxed-build-scr...
I’m disappointed crates.io doesn’t have a stricter bar for serving a crate that has newly acquired a proc macro or build.rs. That seems like a trivial mitigation.
Mitigation for what? Compromising the code that is then most likely run in a test instead of compromising a build script is just a very slight inconvenience for the attacker. I'm not particularly fond of arbitrary build scripts either, but restricting them will not help the supply chain issue in a significant way. Also there are several ways to control build.rs execution in the Cargo ecosystem, for example with cargo…
I also disagree a build scripts is a mild convenience. A build script always runs for anyone it’s a dependency for with full access and context and often has access to secrets in CI. A compromised runtime has more limited access and requires actual invocation of code paths (if you’re lying as a dependency that’s never executed, no exploit).
Of course Rust should have language-level support for capabilities so that just invoking a function doesn’t grant it access to arbitrary disk access. But that’s a much more difficult change than tweaking the defaults for cargo.
I can very easily build a highly functional, pleasant to use Apple platform app with 5 or fewer top level dependencies. In many cases, I reach for between 0-2 total.
There’s no reason why this can’t be replicated elsewhere. The key is to make the programming language reasonably robust with at least 80% of common non-UI dev needs built in and put the remaining 20% and UI bits into a small family of well-supported, community-embraced, preferably first party libraries.
That would make it unnecessary to pull in foreign dependencies in the overwhelming majority of projects. What few do get pulled in becomes lightweight, easily verifiable syntactic sugar or libraries with purposes too niche to be worth targeting.
Of course this approach can go wrong too. You could easily end up with a monster like Boost, but that comes down to project administration keeping creep under control and proper modular design.
Also most of these dependencies provide a breadth of features that the end package does probably not need.
Earlier quoted context omitted.
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 s…
> 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.