> A fine grained capability system for packages would dramatically improve the safety profile

I think Deno does that (the new project by Node's original creator):

https://blog.logrocket.com/what-is-deno/

Deno gives all packages the same permissions of the main app. So if your app can make network requests, so can every dependency you use. It’s not a great situation. I’ve brought this up to them and their response is that per-package permissions would be too difficult to implement.

The app design is going to have to change around per-process permissions. build.ts doesn't need the same as main.ts but at that point what are you getting where you couldn't just use docker and abstract that pattern to literally all software and dependencies that aren't in deno.

Maybe it's a start of better tooling? Kicking out a graph of package/permission call stack might be useful to audit

Yes, checking everyone at the main door is indeed easier than checking everyone at every single point of contact. It needs a vast architectural change compared to current implementation as you need to enforce those rules at runtime!

Well yeah, but I thought the whole point of deno was to make vast architectural changes to allow for increased security. Seems odd to stop half way.

Woohoo! I just noticed Deno is at release candidate stage for v1.0.

Deno (a modern JS runtime from the same original author as Node) is heading this direction, albeit it’s currently more a traditional opt-in than OpenBSD-style opt-out.

This is a much more productive answer to the node dependency tree question than I'm used to encountering, and it's much more in line with most large modern systems are tending to address security from >1th party sources. Wall it off, require explicit permission, worry more about the security of the sandbox and less about the security of the dependencies. It doesn't address everything (and it becomes a lot riskier when you do give permission), but it's a far better proposal than shouting about how many dependencies are common in the JS ecosystem without any additional steps.

This describes what I am currently missing the most in the node ecosystem. Deno is a good approach but it will take some time to see how adoption goes. I would prefer some fine grained capability-based solution. Approaches similar to this have often been articulated [1]. Many of my concerns are best described here [2]. There even was an article from someone who would have been able to overtake many high profile npm accounts with very little effort some time ago (cannot find it anymore).

With tighter snyk integration into npm and the acquisition of npm through ms one could argue that security bar may have risen/will rise but I (speaking as a js/ts dev) am still sceptical. I haven't really looked to deep into stuff like selinux/apparmor/firejail [3] maybe someone can give an opinion on this. I'd wish for something that would be codeified on package level to make review easier and give me some peace of mind.

For now my plan is to dockerize most of my projects and it's dependencies. It should give a little more protection against malicious postinstall scripts.

Unfortunately, I depend more and more on npm modules outside of projects (coc-vim comes to mind/for others it may be vscode etc.).

[1] https://medium.com/hackernoon/npm-package-permissions-an-ide... (2018) [2] https://medium.com/hackernoon/im-harvesting-credit-card-numb... (2018) [3] https://github.com/netblue30/firejail/blob/master/README.md

I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of package A but not of package B (because package B drops some privileges that D expects to have).

Maybe it could be solved by type checking during dependency resolution time: instead of just checking version numbers, also check capabilities that transitive dependencies declare.

Maybe you could slowly boil the ocean by assuming that everything that doesn't declare required capabilities implicitly requires the "ALL" capability, and triage+prioritize a growing core of packages that have explicit capability requirements. In my mind it's kind of like purifying functions in a library: you start at the lowest level / leaves of the call graph and make sure they don't do any I/O, and then the things that call them can be made pure and so on up the chain.

> I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of package A but not of package B (because package B drops some privileges that D expects to have).

That sounds like it would be working. If you declare that your package doesn't need network, and it fails because it used the network, that sounds like a bug was caught.

My first reaction was that if we need protection from pieces of software we ship because nobody knows what we ship, something must be deeply wrong.

But npm-snark aside, maybe some lack of trust must come from a highly modular open source ecosystem.

If a library I ship could abstain from unneeded platform capabilities, that would certainly reduce catastrophic bug/attack surface, and I'd sleep better.

This capabilities based OS library reminds me of genode some.

This is a really cool idea.