> It's not "node" or "Javascript" the problem, it's this convenient packaging model.

That and the package runtime runs with all the same privileges and capabilities as the thing you're building, which is pretty insane when you think about it. Why should npm know anything outside of the project root even exists, or be given the full set of environment variables without so much as a deny list, let alone an allow list? Of course if such restrictions are available, why limit them to npm?

The real problem is that the security model hasn't moved substantially since 1970. We already have all the tools to make things better, but they're still unportable and cumbersome to use, so hardly anything does.

▲

pas 3 hours ago | parent [-]

pnpm (maybe yarn too?) requires explicit allowlisting of build scripts, hopefully npm will do the same eventually

> security model

yep, some kind of seccomp or other kind of permission system for modules would help a lot. (eg. if the 3rd party library is parsing something and its API only requires a Buffer as input and returns some object then it could be marked "pure", if it supports logging then that could be also specified, and so on)

	▲	chuckadams 2 hours ago \| parent \| next [-]
		For all the other things I like about yarn, it still executes build scripts willy-nilly, so I am looking at switching to pnpm. I'm sure my $work is going to love me changing up the build toolchain again... PHP's composer on the other hand requires an allowlist in the project's composer.json. I never would have thought PHP would be the one to be getting stuff like this right. Still, I think the "allow-scripts" section or whatever it's called should be named "allow-unrestricted-access-to-everything". Or maybe just stick "dangerously-" in front, I dunno, and drop it when the mechanism is capable of fine-grained privileges.
	▲	WorldMaker an hour ago \| parent \| prev [-]
		Deno also requires allowlisting npm scripts. It also has a deeper permissions model in general.