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?
> Microsoft doesn’t do everything right but the GitHub acquisition has honestly gone better than I ever expected. Rather than forcing GitHub to adopt Microsoft centric policies, Microsoft has adopted more GitHub stuff, especially from a product POV. GitHub still runs as a separate company (different logins and health care and hiring systems) with its own policies and point of view.
GitHub didn’t embrace, extend, extinguish git. You can git push to a different company (e.g. Gitlab) and you’ve migrated. The biggest problems with GitHub are scaling and availability, not lock-in.
Microsoft today is nothing like it was 30 or 20 years ago.
MSFT acquisition of NPM was a massive shit show, they fired many staff engineers and people that were at github for quite a while. Top comment was a liar.
Would you rather the company went under after it ran out of money and had to fire everyone instead? Not to mention a quarter of the company was laid off the year before the acquisition.
Uhh, I'd expect the trillion dollar transnational corporation to do right by it's workers rather than rat fucking them to appease corporate do-nothing leeches if I'm being frank.
NPM (the company) was about to go under in 2020. They raised VC but never found a sustainable business model. GitHub acquired them to keep the ecosystem alive. The acquisition hasn't really benefitted GitHub much at all.
I don’t know if this is the case here, but it’s very hard in general to judge how much software projects ought to cost.
Software projects will grow in complexity to consume whatever budget you give it. If you hire 50 devs and give them a bunch of business objectives, they are going to do what they do and write a ton of software.
It’s not obvious to me that it would be theoretically impossible to build a cheaper package manager.
native modules. nodejs can have native modules (written in C++, Rust, etc...). Projects usually ship prebuilt natives binaries (for each arch/OS/Nodejs ABI combination) hosted on GitHub Releases and download them automatically at installation time; fallback to build from source if not found. that's where scripts are used
the reason for not bundling all native binaries is becasue the no. of combinations are huge and it can make module size hundreds of MBs
Off the top of my head the purposes I've seen for them:
- building native bindings (node-sass)
- asking for funding (core-js)
... Probably a few more but the native case is probably the biggest and the packages I'm using nowadays ship precompiled blobs in optionalDependencies. Install scripts seem to be out of favor.
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)?
As if supply chain attacks could have been prevented by 2fa or passkeys always.
You want delays by x days because supply chain attacks get caught very often within 1-2 days. And if you really really want to make an exception for a zero day then that's no problem and you can still quick patch by exclusion of that rule. They don't contradict in a unsolvable problem. You want both, you get both.
The maintainer of pnpm mentioned this on the pod rocket podcast recently. Based on recent npm exploits they decided to (and based on a poll they did most users agreed) set to 1 day by default in v11. Can always choose to change it if you desire.
Don't forget about tests. That'll run code for every package that is imported. Yes, imported, because in JS importing means "run all the top level code in this file". So to continue exploiting you just place your malicious code in index.js instead of a postinstall script. Not as guaranteed to run but still very likely.
Build deps are even disregarded as less critical than runtime deps traditionally. So deps like sphynx for building docs are still a dev side supply chain vector.
The reason this may be overlooked is because build deps are only ran by the devs, but not the users, so users dismiss it as safe. However, if a build dep is infected, the infection may spread to the actual package code, which will then of course be run by the user.
Not theoretical, Microsoft is currently under attack by a worm that spreads through vs code extensions, which then spread to actual packages that users run.
Docs suggest just using a script tag instead of npm, when using npm install, they suggest to run import statement, which can execute arbitrary code.
The bottom line seems to be that if you are using npm, it's cause you are using node, and therefore you will run the imported code in the server, otherwise you would use a script tag.
But maybe there's a way to define a browser only package or .js URL such that it is only downloaded and served but never executed server side?
In any case, not a huge usecase of npm, which again, is designed for node which is backend.
Yes, but that's actually a huge win. I can't know what a package needs to do at install time - the dev knows that. But I know what my tests and program need to do at runtime because it's my job to understand those things.
The dev has to be responsible for ensuring that their build scripts are safe, I need to be responsible for ensuring that my runtime is safe.
It'd be great to have more tools for untrusting libraries (iframes are awesome for this on the frontend) but this is still a massive win.
We already have alternative and superior proposals, it's called Deno.
It's node + npm compatible and its permission system locks everything down by default.
If you know ahead of time, you can turn on which permissions something is supposed to have in the config file.
Or you can just not use a config file at all. Anytime it needs a permission: it asks you what it wants. You can say yes or no, and those are saved in the config file for next time. If you say no, the script throws an error where it tried to access something it didn't have permission for.
---
Example:
- My linter wants access to my file system?
- You can have read access to ./src/ts/
- My bundler wants read and write access to my file system?
- You can have read access to ./src/ts and write access to ./build-output
- Huh, what's that? The bundler was trying to both read and write a file in ./src/ts?
- We don't want input files getting overwritten, that's a recipe for hard-to-diagnose race conditions. Looks like the permission system did more than just keep things secure, it's like a type system for IO.
- Oh, look at that, there was a very subtle bundler misconfig, let me fix that now. How long would that have existed if we didn't use deno...
- Oh what's this? An updated dependency I've been using for 6 months suddenly asking for access to my .env file, and asking to run curl in a separate process? How about "no". Why would a simple DOM utility dependency be asking for those permissions? Ah, looks like it was part of a credential stealing supply chain attack. Glad I wasn't using node.
---
Addendum: Node now has a permission system, but it's broken by design so it's useless.
You'll notice that my comment was a question, you can tell by the presence of question marks at the end of the sentence.
Additionally, if a comment were to hypothetically point out an issue, that is valuable on its own. If someone reacts to a comment that points out an issue this defensively, it's a huge red flag.
It's unstated, but I'm willing to assume that only the root package.json is consulted to decide if these scripts are allowed. Otherwise, yes, this would not actually change anything.
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 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.
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.
The changelog design has been like that since last year,[0] which predates today's slop design of small caps and monospace text (probably because they both are based on the same design trend). A year ago, vibe coded websites leaned more on sans serif and gradient text.
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 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?
didn't know npm was owned by github.. well, that explains things...
NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (March 16, 2020; 571 comments; 1829 points) - https://github.blog/news-insights/company-news/npm-is-joinin...
Some of it aged... interesting.
Top comment:
> Microsoft doesn’t do everything right but the GitHub acquisition has honestly gone better than I ever expected. Rather than forcing GitHub to adopt Microsoft centric policies, Microsoft has adopted more GitHub stuff, especially from a product POV. GitHub still runs as a separate company (different logins and health care and hiring systems) with its own policies and point of view.
> ...
To be fair, the vibes (at the time) were that Microsoft has changed. Probably, in some way, a zero-interest rate phenomena.
Young people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.
Young people were… right?
VS Code is open source. (Cursor is built on it!)
GitHub didn’t embrace, extend, extinguish git. You can git push to a different company (e.g. Gitlab) and you’ve migrated. The biggest problems with GitHub are scaling and availability, not lock-in.
Microsoft today is nothing like it was 30 or 20 years ago.
Microsoft has been causing a lot of problems lately but I completely disagree that it fits the pattern of "embrace, extend, extinguish".
MSFT acquisition of NPM was a massive shit show, they fired many staff engineers and people that were at github for quite a while. Top comment was a liar.
> they fired many staff engineers
Would you rather the company went under after it ran out of money and had to fire everyone instead? Not to mention a quarter of the company was laid off the year before the acquisition.
Uhh, I'd expect the trillion dollar transnational corporation to do right by it's workers rather than rat fucking them to appease corporate do-nothing leeches if I'm being frank.
> I'd expect the trillion dollar transnational corporation to do right
you would? has any trillion dollar corporation ever?
No, and that's why we must destroy them. Figuratively then literally.
NPM (the company) was about to go under in 2020. They raised VC but never found a sustainable business model. GitHub acquired them to keep the ecosystem alive. The acquisition hasn't really benefitted GitHub much at all.
I don’t know if this is the case here, but it’s very hard in general to judge how much software projects ought to cost.
Software projects will grow in complexity to consume whatever budget you give it. If you hire 50 devs and give them a bunch of business objectives, they are going to do what they do and write a ton of software.
It’s not obvious to me that it would be theoretically impossible to build a cheaper package manager.
And additionally was it truly worth buying if this is what we've ended up with? Some things should be allowed to fail
Most people know this but the _real_ reason it explains things is that GitHub is owned by Microsoft. Oh, and Microsoft moved GitHub to Azure
To be fair, NPM sucked long before it got acquired by Github/Microsoft.
And to be fair 2: The other package repos also suck.
yes, since 2020
> allowScripts defaults to off
Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
Java‘s Maven never had them, never felt a need for them.
What is their purpose in JS land?
native modules. nodejs can have native modules (written in C++, Rust, etc...). Projects usually ship prebuilt natives binaries (for each arch/OS/Nodejs ABI combination) hosted on GitHub Releases and download them automatically at installation time; fallback to build from source if not found. that's where scripts are used
the reason for not bundling all native binaries is becasue the no. of combinations are huge and it can make module size hundreds of MBs
Off the top of my head the purposes I've seen for them: - building native bindings (node-sass) - asking for funding (core-js)
... Probably a few more but the native case is probably the biggest and the packages I'm using nowadays ship precompiled blobs in optionalDependencies. Install scripts seem to be out of favor.
Does the allow list in package.json pin to the package version, or only to the package name?
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
Breaking: AI fixes 10 year old vulnerability!
How do you allow scripts for tools installed globally?
They should have added a 1-day age limit by default, so security scanners have some time.
I don't think it'd necessarily be a good decision, sometimes CVE are actively exploited and need quick patching.
A better safety net would be to require active 2FA proof for every package update.
As if supply chain attacks could have been prevented by 2fa or passkeys always.
You want delays by x days because supply chain attacks get caught very often within 1-2 days. And if you really really want to make an exception for a zero day then that's no problem and you can still quick patch by exclusion of that rule. They don't contradict in a unsolvable problem. You want both, you get both.
How do you know what's a zero day fix?
(You write something)
So then you have to check every package's updates and decide if you update, yes?
I think you want both of these things. Realistically we're not at a point yet where all MFA credentials are phishing resistant.
If you need a quick patch, you pass another parameter to turn off the 1 day. 1 day delay will prevent more problems than it makes.
so this parameter can be passed by the attackers also thus making your point pointless
The idea of the parameter is stopping the attackers from getting on your system in the first place
that parameter cannot be set by a package, you only can set it
“How do I get my security hardened CD pipeline to 2FA?”
The maintainer of pnpm mentioned this on the pod rocket podcast recently. Based on recent npm exploits they decided to (and based on a poll they did most users agreed) set to 1 day by default in v11. Can always choose to change it if you desire.
Looks good? But doesn't this just change the compromise window from first installation to first run?
Ok? Not sure what a package manager can do about the fact that eventually you want to run the things you install.
"First run" doesn't exist for JavaScript libs used only in web apps. So for that entire class of packages this change makes them safe.
Don't forget about tests. That'll run code for every package that is imported. Yes, imported, because in JS importing means "run all the top level code in this file". So to continue exploiting you just place your malicious code in index.js instead of a postinstall script. Not as guaranteed to run but still very likely.
Build tooling still runs though. Your bundler plugin or PostCSS transform gets full fs access at build time, nobody's auditing that.
Build deps are even disregarded as less critical than runtime deps traditionally. So deps like sphynx for building docs are still a dev side supply chain vector.
https://github.com/kennethreitz/pytheory/issues/47
The reason this may be overlooked is because build deps are only ran by the devs, but not the users, so users dismiss it as safe. However, if a build dep is infected, the infection may spread to the actual package code, which will then of course be run by the user.
Not theoretical, Microsoft is currently under attack by a worm that spreads through vs code extensions, which then spread to actual packages that users run.
"First run" certainly exists in web apps, it's just running JS in a browser rather than a shell script on a developer or CI machine.
There is plenty of malicious stuff you can do from the browser.
But this is npm, the execution environment is not the browser, but the server.
Most packages are imported via import/require, even if it's a browser only package. Because of SSR and reasons.
Or maybe not, let's look at a random browser only example, angular and react will use SSR, so they will execute in the server, let's check Jquery:
https://www.npmjs.com/package/jquery
Docs suggest just using a script tag instead of npm, when using npm install, they suggest to run import statement, which can execute arbitrary code.
The bottom line seems to be that if you are using npm, it's cause you are using node, and therefore you will run the imported code in the server, otherwise you would use a script tag.
But maybe there's a way to define a browser only package or .js URL such that it is only downloaded and served but never executed server side?
In any case, not a huge usecase of npm, which again, is designed for node which is backend.
Randome example,
include
Better than nothing. That’s the same problem every package manager has.
Yes, but that's actually a huge win. I can't know what a package needs to do at install time - the dev knows that. But I know what my tests and program need to do at runtime because it's my job to understand those things.
The dev has to be responsible for ensuring that their build scripts are safe, I need to be responsible for ensuring that my runtime is safe.
It'd be great to have more tools for untrusting libraries (iframes are awesome for this on the frontend) but this is still a massive win.
I’m sure we’d all welcome your alternative and or superior proposals.
Without that, this just comes across like unconstructive commentary.
This moves the needle a little your proposals or the lack thereof don’t move it at all. So I’ll take this over nothing.
We already have alternative and superior proposals, it's called Deno.
It's node + npm compatible and its permission system locks everything down by default.
If you know ahead of time, you can turn on which permissions something is supposed to have in the config file.
Or you can just not use a config file at all. Anytime it needs a permission: it asks you what it wants. You can say yes or no, and those are saved in the config file for next time. If you say no, the script throws an error where it tried to access something it didn't have permission for.
---
Example:
- My linter wants access to my file system?
- My bundler wants read and write access to my file system? - Oh what's this? An updated dependency I've been using for 6 months suddenly asking for access to my .env file, and asking to run curl in a separate process? How about "no". Why would a simple DOM utility dependency be asking for those permissions? Ah, looks like it was part of a credential stealing supply chain attack. Glad I wasn't using node.---
Addendum: Node now has a permission system, but it's broken by design so it's useless.
You'll notice that my comment was a question, you can tell by the presence of question marks at the end of the sentence.
Additionally, if a comment were to hypothetically point out an issue, that is valuable on its own. If someone reacts to a comment that points out an issue this defensively, it's a huge red flag.
An idea might be to not just pin "package xyz allowed", but "package xyz postinstall allowed with hash <1234>".
The default behavior for the automated "add everything existing to the allowlist" is to include the specific version: https://docs.npmjs.com/cli/v11/using-npm/config#allow-script...
Together with a lockfile that does achieve "package xyz postinstall allowed with hash <1234>"
Eh, that only took a few dozen actively exploited supply-chain vulns in the span of two years!
Only took Microsoft themselves getting hit with it for things to change.
> The resulting allowlist is written to package.json
Couldn’t this effectively result in the same process we get in pre-12 defaults?
It's unstated, but I'm willing to assume that only the root package.json is consulted to decide if these scripts are allowed. Otherwise, yes, this would not actually change anything.
I would've assumed lockfile-by-default. We're still going with auto-updating?
You do get a lockfile by default
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 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.
I'm not going to get forced.
npm is basically pnpm now
Except pnpm is written in Rust and is very fast, saves disk and has much more advantage.
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?
Hahaha that's amazing, just a big red "RETIRED" badge above their blog post? What the hell
Breaking changes have had that tag for ages
Really? Retired? What does that even mean in this context, why not "breaking" or something else that suggests breaking change?
> Retired? What does that even mean in this context
"retired" is probably a followup to functionality that was "deprecated".
I agree "breaking" would be clearer
The changelog design has been like that since last year,[0] which predates today's slop design of small caps and monospace text (probably because they both are based on the same design trend). A year ago, vibe coded websites leaned more on sans serif and gradient text.
[0]: https://github.blog/changelog/2025-05-05-improvements-to-cha...
I don't get it. How does this help with anything? You pull in a dependency to use it, right?
Well pulling some code is different than running a script on your machine
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.