Hacker News Reader

Comment by cookiengineer | Hacker News Reader

What a pointless change.

If you force every user to just use "--enable-unsecure-feature", guess what will happen?

This is not about improving security. This is about shifting blame.

A much better alternative would've been the introduction of sandboxes or simulation runs that would output which scripts and programs are running due to unpredictable dependencies. This way the user could check before the actual execution, and maintain an allow list much easier. That could be done via an npm update && npm upgrade workflow where the update generates the list that the user has to manually confirm.

Heck, even a chroot would be an improvement, and they're almost pointless these days, considering how good malware got at escaping chroots.

View on HN

I don't think it's pointless. A large number (the majority?) of users probably don't need install scripts, so disabling them by default is a net security improvement. Those that do can enable the insecure behavior, which will become an explicit decision that is trackable, auditable, etc.

You're not wrong about sandboxing, but sandboxing isn't something that can just be blithely introduced to a large packaging ecosystem that previously assumed full system access. Doing so results in the same kind of regression you point out: if the sandboxing breaks peoples' builds, they'll just disable it and move on with their goals.

Most users don't need it. Having it on by default is a feature for malware writers not users.

But to your point, Node has had permission flags for a while[0] but allows everything by default. Npm could use them to increase security even more. I just hope it doesn't take them another 10 years to change the default.

[0] https://nodejs.org/api/permissions.html

Most packages don’t need it, but I imagine a large percentage of users do since most projects pull in an insane number of packages.

Still, “default off” is better. It would be nice if there were a lightweight way to fork upstream packages, and cache the native builds. It’d improve build times, make the build step more explicit / sandboxable and allow for easier binary builds for operating systems and processors that M$ treats as second class.

This is kind of like arguing that immutable by default variables are pointless.

If you force every user to just write "mut", guess what will happen?

They will write "mut" when they need mutable variables, which in practice turns out to be the minority of variables.

It's the same with "Option". The vast majority of variables or struct members do not need to be nullable at all.

> If you force every user to just write "mut", guess what will happen?

This is the wrong analogy.

The equivalent analogy would be using a compiler flag that is triggered for all dependencies and all included libraries without a per-library or per-file changeability. Something like "gcc --force-mut-all-yolo".

Variables have scopes of concern. This new NPM feature has no scope. And that's what my critique is about, because it makes it still unpredictable if any of your dependencies of dependencies needs a script.

The spread vector of potential malware stays identical, because the reason the miasma worm is spreading so fast is because of dependencies of dependencies that are impossible to audit on a case-by-case basis, given the lack of sandboxes and the lack of allowlisting scripts on a per-dep-and-version basis.

This is pip with --break-system-packages heh

I'm not going to get forced.

Reply on news.ycombinator.com