I'm not sure how I missed that npm was acquired by GitHub, but man, a lot of stuff suddenly makes a lot of sense. I really can't think of a worse home for such a critical part of the Node ecosystem.
show comments
atraac
postinstall scripts should've been removed long time ago, it's the cancer of NPM packages. There's so many deeply nested, uncontrolled postinstalls that run randomly when you pull something it's insane, I don't know how someone at some point ever though that was a good idea.
show comments
tuckwat
I bet there have been a hundred different discussions about this inside of NPM since it was disclosed 10 years ago. With Shai Halud it's gotten too big to ignore.
show comments
karakanb
It is not obvious from the post but it seems like the allow list for the scripts supports whitelisting packages instead of a global setting. This should make it easier to maintain org-wise rules to allow scripts only for specific packages.
Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?
show comments
alexghr
Are the current LTS node versions (iirc 22, 24, 26) going to update the bundled npm to v12 to benefit from these security fixes? All come with npm v11 now
show comments
partsch
I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.
show comments
aniceperson
didn't know npm was owned by github..
well, that explains things...
show comments
beart
Does the allow list in package.json pin to the package version, or only to the package name?
thatmf
> allowScripts defaults to off
Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
show comments
butz
Better late than never.
ComputerGuru
My big question as an OSS dev distributing some precompiled binaries via npm for easy installation: does allowScripts also default to disabled when directly installing a package (globally or otherwise)?
show comments
efortis
this release fixes a vulnerability reported 10 years ago
Now all the malware can move from the install script to the module itself where it will inevitably still be run
chimpanzee2
Cool, but I default to pnpm these days anyway.
TZubiri
Looks good? But doesn't this just change the compromise window from first installation to first run?
show comments
Zopieux
Eh, that only took a few dozen actively exploited supply-chain vulns in the span of two years!
show comments
thrdbndndn
How do you allow scripts for tools installed globally?
show comments
z3t4
npmjs.org is a joke at this point. I guess their support is run by LLM because you can just write to them and they will transfer ownership of any module nilly willy.
show comments
jbverschoor
And when will we get rid of the vendored node_modules, and make it read only?
heldrida
> The resulting allowlist is written to package.json
Couldn’t this effectively result in the same process we get in pre-12 defaults?
show comments
philipwhiuk
> On balance, it’s npm’s belief that the utility of having installation scripts is greater than the risk of worms. This is a tradeoff that we will continue to evaluate.
They chose...poorly
Pxtl
I would've assumed lockfile-by-default. We're still going with auto-updating?
show comments
retardedsecguy
npm is basically pnpm now
show comments
cute_boi
They should have added a 1-day age limit by default, so security scanners have some time.
show comments
themafia
The "aw geez, enough is enough" release.
Finally.
Tiberium
I hope GitHub changes their vibecoded badges, what does RETIRED even signify in this context? Why does the preview have to be in ominous red?
show comments
cookiengineer
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.
show comments
SCLeo
I don't get it. How does this help with anything? You pull in a dependency to use it, right?
show comments
zarzavat
There's an easy way to stop most supply chain attacks:
1. Publishing users must approve each and every release from a smartphone app.
2. Publishing users must provide verified government ID.
The first step prevents the types of attacks where an attacker gets control of a maintainer's computer and publishes a new release.
The second step discourages attacks where a user tries to get a malicious package used by others.
When combined with the security features that already exist, e.g. delays and automatic scanning, it would make it considerably harder to pull off a successful attack.
I'm not sure how I missed that npm was acquired by GitHub, but man, a lot of stuff suddenly makes a lot of sense. I really can't think of a worse home for such a critical part of the Node ecosystem.
postinstall scripts should've been removed long time ago, it's the cancer of NPM packages. There's so many deeply nested, uncontrolled postinstalls that run randomly when you pull something it's insane, I don't know how someone at some point ever though that was a good idea.
I bet there have been a hundred different discussions about this inside of NPM since it was disclosed 10 years ago. With Shai Halud it's gotten too big to ignore.
It is not obvious from the post but it seems like the allow list for the scripts supports whitelisting packages instead of a global setting. This should make it easier to maintain org-wise rules to allow scripts only for specific packages.
Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?
Are the current LTS node versions (iirc 22, 24, 26) going to update the bundled npm to v12 to benefit from these security fixes? All come with npm v11 now
I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.
didn't know npm was owned by github.. well, that explains things...
Does the allow list in package.json pin to the package version, or only to the package name?
> allowScripts defaults to off
Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
Better late than never.
My big question as an OSS dev distributing some precompiled binaries via npm for easy installation: does allowScripts also default to disabled when directly installing a package (globally or otherwise)?
this release fixes a vulnerability reported 10 years ago
https://www.kb.cert.org/vuls/id/319816
Now all the malware can move from the install script to the module itself where it will inevitably still be run
Cool, but I default to pnpm these days anyway.
Looks good? But doesn't this just change the compromise window from first installation to first run?
Eh, that only took a few dozen actively exploited supply-chain vulns in the span of two years!
How do you allow scripts for tools installed globally?
npmjs.org is a joke at this point. I guess their support is run by LLM because you can just write to them and they will transfer ownership of any module nilly willy.
And when will we get rid of the vendored node_modules, and make it read only?
> The resulting allowlist is written to package.json
Couldn’t this effectively result in the same process we get in pre-12 defaults?
> On balance, it’s npm’s belief that the utility of having installation scripts is greater than the risk of worms. This is a tradeoff that we will continue to evaluate.
They chose...poorly
I would've assumed lockfile-by-default. We're still going with auto-updating?
npm is basically pnpm now
They should have added a 1-day age limit by default, so security scanners have some time.
The "aw geez, enough is enough" release.
Finally.
I hope GitHub changes their vibecoded badges, what does RETIRED even signify in this context? Why does the preview have to be in ominous red?
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.
I don't get it. How does this help with anything? You pull in a dependency to use it, right?
There's an easy way to stop most supply chain attacks:
1. Publishing users must approve each and every release from a smartphone app.
2. Publishing users must provide verified government ID.
The first step prevents the types of attacks where an attacker gets control of a maintainer's computer and publishes a new release.
The second step discourages attacks where a user tries to get a malicious package used by others.
When combined with the security features that already exist, e.g. delays and automatic scanning, it would make it considerably harder to pull off a successful attack.