Here’s a thought that’s been living in my head rent free ever since: what if we don’t have transitive dependencies at all? What if we just… package them all up together? That sounds absurd, but we are almost all using a build system, we who are all have sourcemaps and dead code elimination baked in. We can standardize this. The package NPM delivers is already different from the published thing. We can define “this is how you reproduce my build”, and distributors can say “this is what is present in this package” with high confidence. Sourcemaps can deduplicate.
If package M is malicious, what difference does it make if it's required directly by your app, or through a sub-dependency chain, like A -> B -> C -> M?
If you have an approach that allows you to vet all your direct dependencies, why wouldn't that allow you to vet sub-dependencies as well?
It also reduces the surface area to vet in the first place. It’s highly likely many dependencies will be stripped down considerably, if not outright deduplicated or eliminated. The “npm installs thousands of dependencies” thing is a real problem, but it’s also partly because it’s installing stuff you’ll never actually execute in any way.
You can pare down sub-dependencies with confidence, because you already know what code paths are hit by the parent dependency at packaging time. You can’t do that with direct dependencies until you go to package/deploy, because of course you may expand your usage of their APIs during development.
From my superficial understanding of how this works, couldn't the "build" phase take note which parts of dependencies are loaded, and then compare those with where the known vulnerabilities are? I realize some issues may be bigger or harder to narrow down, but it still looks like it would be a step in the right direction.
I think it could go further than the state of the art tree shaking, by adding deduplication of unchanged code between different versions of the same package. This would mostly be a benefit for shrinking installed dependencies, but that helps make the idea of actually vetting/auditing them a lot more plausible too. And it could help make dealing with semver-incompatible versions more flexible (i.e. if the remaining code is identical, tada now it's semver-compatible because it’s the same code!), somewhat mitigating a common audit resolution blocker.
All of this of course would need some sort of a manifest detailing which code comes from which location(s) in which package(s), and (at least optionally) a human-friendly file system structure that users can actually audit/vet.
If I didn’t already have a backlog of side projects a mile long, I’d probably be working on this already, because there’s a clear need for improvement in this area. But none of it feels outlandishly hard to pull off if anyone wanted to run with the idea.
Ultimately package repos run on trust and a low level of risk is tolerated because of the benefits of being able to get stuff done.
Of course. But your comment still reads as "we can't make it perfect, so might as well not try at all". I think there can still be value in limiting the blast radius.
Your while(1), if present, is likely to be intentionally malicious. But I've seen many naïve libraries implement "accidentally quadratic" algorithms, which is basically a disguised while(1), but unintentional.
The point is that the end result of `rm -rf /` is painful. It doesn't matter if someone managed to maliciously sneak that into your supply chain, or if it rises from some funky corner case of some package whose only goal is to bring world peace. So being able to prevent some leftpad lib from accessing the file system at all makes a lot of sense.
In SES, that is controlled by allowing assignment of a budget and failing if it's exceeded. Similar to how gas works in the EVM.
while(1) - kill -9 / Task Manager / Activity Monitor
All files deleted - cry.
Or is there some security feature of node or JS that I'm missing?
Of the popular languages, though, JavaScript is the closest to being strict enough for this style of programming, and there’s been active work for a while towards that goal:
I don't understand why this is so often treated as a dichotomy, where either you trust every single author to not delete your files, or you review every line of code to make sure it doesn't delete your files. Both seem unsustainable. I think we need to look at the problem from a different perspective: why is every single transitive dependency able to delete your files?
Take a look at the node-ipc method reference: https://www.npmjs.com/package/node-ipc#ipc-methods
What functionality does node-ipc have that requires it to have unfettered access to the filesystem? Well, with its current implementation, it needs to be able to create a unix socket for e.g. 'serve()'. But if you changed the API a bit, you could conceivably pass it a file handle to a unix socket that you've just created, instead. Now that module doesn't need any arbitrary filesystem access at all! You could make similar changes to those methods responsible for making outbound network connections, etc. At that point, you could almost completely sandbox this module, because all it needs is what you've given it.
In other words: let's apply the principle of least authority for real.
https://medium.com/agoric/pola-would-have-prevented-the-even...