5 ms·

Upcoming breaking changes for npm v12

484 points by plasma 4mo ago

TZubiri 4mo ago
Looks good? But doesn't this just change the compromise window from first installation to first run?
- christophilus 4mo ago
  Better than nothing. That’s the same problem every package manager has.
- semiquaver 4mo ago
  Ok? Not sure what a package manager can do about the fact that eventually you want to run the things you install.
  - frabcus 4mo ago
    Have any kind of provenance. eg like Debian has for 30 years. Key signing in person etc
    - tpetry 4mo ago
      That has also been implemented recently. With staged publishing the author must verify a new release with 2FA so automated attacks dont work anymore. Some human in the loop must verify a release.
- Someone1234 4mo ago
  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.
  - mschuster91 4mo ago
    An idea might be to not just pin "package xyz allowed", but "package xyz postinstall allowed with hash <1234>".
    - jffry 4mo ago
      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-scripts-pin 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>"
  - spartanatreyu 4mo ago
    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.
- grassfedgeek 4mo ago
  "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.
  - tabwidth 4mo ago
    Build tooling still runs though. Your bundler plugin or PostCSS transform gets full fs access at build time, nobody's auditing that.
    - TZubiri 4mo ago
      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 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.
  - WatchDog 4mo ago
    "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.
  - TZubiri 4mo ago
    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 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
- insanitybit 4mo ago
  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.
  - tentacleuno 4mo ago
    v8 does have a sandbox feature for running untrusted scripts, and it's quite good. There's also Node's VM module.
aniceperson 4mo ago
didn't know npm was owned by github.. well, that explains things...
- joeyhage 4mo ago
  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
  - amitport 4mo ago
    To be fair, NPM sucked long before it got acquired by Github/Microsoft. And to be fair 2: The other package repos also suck.
    - tempay 4mo ago
      To be fair, the entire problem space sucks and I’m not sure it’s possible not to.
    - jbverschoor 4mo ago
      Yeah, but the azure supply chain attack explains why all of a sudden they can make this change. It seems that if you want to get something important changed in npm, you simply need exploit some of its short comings against Microsoft instead of discussing why it’s necessary.
    - creesch 4mo ago
      > And to be fair 2: The other package repos also suck. If you mean other languages, then yeah a lot of similar issues and weirdness there as well. Maven dependencies in any complex project are a "fun" challenge as well. Though the sort of recurring supply chain attacks you see within the npm ecosystem is something I haven't seen elsewhere to this degree.
    - hinkley 4mo ago
      Maybe I have nostalgia blinders on but I do NOT remember putting up with this much bullshit in the Ruby ecosystem and I didn't even like ruby. Gemfiles were pretty okay, and gemfiles are what everyone assumed npm would be a copy of. It wasn't.
Tiberium 4mo ago
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?
- mort96 4mo ago
  Hahaha that's amazing, just a big red "RETIRED" badge above their blog post? What the hell
  - petetnt 4mo ago
    Breaking changes have had that tag for ages
    - mort96 4mo ago
      Really? Retired? What does that even mean in this context, why not "breaking" or something else that suggests breaking change?
      - behindsight 4mo ago
        > 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
        mort96 4mo ago
        What exactly is it that's now retired that used to be deprecated? Isn't this just a collection of breaking changes to defaults?
        behindsight 4mo ago
        if you go to the full changelog on the blog and click on the "retired" button, the url will have type=deprecations as the parameter. It's a holdover from previous posts where there were more clearly defined deprecations. but yes, in this case it's more of a behavioural change of defaults, so they just picked the closest vaguely mapped retired/deprecations tag. 1: https://github.blog/changelog/?type=deprecations https://github.blog/changelog/?type=deprecations
cute_boi 4mo ago
They should have added a 1-day age limit by default, so security scanners have some time.
- KolmogorovComp 4mo ago
  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.
  - jnwatson 4mo ago
    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.
    - alexdns 4mo ago
      so this parameter can be passed by the attackers also thus making your point pointless
      - gbear605 4mo ago
        The idea of the parameter is stopping the attackers from getting on your system in the first place
      - therealmarv 4mo ago
        that parameter cannot be set by a package, you only can set it
    - b112 4mo ago
      While I think this may be true, what validation do you have on this point? Have you rolled the numbers, vs all of the high-pri security updates that will be missed on day one, and exploited? What is really needed is simply more nuance. I agree the delay can help, but honestly the entire ecosystem is broken. There shouldn't be a single thing installed, without someone having an eyes-on. That's how this is fixed. Distros aren't perfect, but they handle this a load better. And this really runs to the problem, people want "new new new", yet often have very little real reason to want it. 99% of npm packages could be 5 years old, and no one would care. But outside of that, npm could operate like a distro, but with more of a Debian unstable -> testing method, where it typically takes a few days for this migration to happen. My point is, the fix isn't publishing by default, then hoping to catch. The fix is that nothing gets published, without a QA/validation step. Of course, that takes money. There is naturally, a super easy fix for that. The code stays open source. The licensing stays <insert whatever by author>. However? The ToS for using any or all of the npm architecture is if you're a company, you pay. If you neglect to pay, eg you don't register as a corporate entity, set up and account, and pay per use, then as per ToS the licensing is invalid, and you're fined via a copyright infringement. And yes, this would mean all npm packages would have an altered licensing model, basically with this tacked on. Is what I'm saying perfect? Nope. Yet it's the general path which should be taken. And frankly, with the way things are going, this level of audit would allow for staff also categorize licenses, ensure accurate template files, and so on. And some of this is the perfect use of an LLM. Not to do the work, but to flag with human review. -- This ecosystem is done. Its model is broken. The concept of downloading random stuff without auditing in any way, is broken. The industry will be moving away, is starting to move away, and is having to move away. So... how can this survive with that concept? If one doesn't like my proposal above, then they should provide an alterative which allows: * companies to have validate of licensing * audits which validate change is not untoward
efortis 4mo ago
this release fixes a vulnerability reported 10 years ago https://www.kb.cert.org/vuls/id/319816 https://www.kb.cert.org/vuls/id/319816
- ares623 4mo ago
  Breaking: AI fixes 10 year old vulnerability!
Zopieux 4mo ago
Eh, that only took a few dozen actively exploited supply-chain vulns in the span of two years!
- dawnerd 4mo ago
  Only took Microsoft themselves getting hit with it for things to change.
punkbit 4mo ago
> The resulting allowlist is written to package.json Couldn’t this effectively result in the same process we get in pre-12 defaults?
- CGamesPlay 4mo ago
  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.
  - punkbit 4mo ago
    Thanks for the sanity check! Had a quick read on my mobile, and that was my first impression. Guess its more of a way to make the maintainers accountable instead of making npm reputation the main focus.
karakanb 4mo ago
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?
- philipwhiuk 4mo ago
  grep?
ComputerGuru 4mo ago
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)?
- jamiem 4mo ago
  Yes, all install scripts will be disabled by default regardless of if they are from direct or transitive dependencies. But if you're already following the os + cpu + optionalDependencies model to distribute your precompiled binaries you should be fine.
themafia 4mo ago
The "aw geez, enough is enough" release. Finally.
thatmf 4mo ago
> allowScripts defaults to off Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
- MrBuddyCasino 4mo ago
  Java‘s Maven never had them, never felt a need for them. What is their purpose in JS land?
  - dgoldstein0 4mo ago
    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.
    - WorldMaker 4mo ago
      After the backlash of using postinstall scripts for funding requests, most of that moved to the dedicated infrastructure of the `"funding"` key in package.json [1] and the `npm fund` [2] command. (Not that most companies/users pay any more attention to this funding request messaging other than maybe adding `--no-fund` to some of their `npm install` scripts, but it is still an improvement over using scripts to do it.) [1] https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#funding https://docs.npmjs.com/cli/v10/configuring-npm/package-json?... [2] https://docs.npmjs.com/cli/v11/commands/npm-fund https://docs.npmjs.com/cli/v11/commands/npm-fund
  - tuananh 4mo ago
    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
tuckwat 4mo ago
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.
- appplication 4mo ago
  Great, now it’s python’s turn next
- Eji1700 4mo ago
  I do love that javascript's history is basically just coder mentality distilled. "oh yeah we'll fix that shortly" is almost always "oh fuck now we have to"
  - port11 4mo ago
    I chuckled, but this is more about the history of NPM. In retrospect, allowing an ES consortium seat (Microsoft) to own the largest package repo for the language… might have been a bad idea? Google is one of the worst members of the language board, but Microsoft might be a close second. Given their ownership of GitHub came with a general community unease, perhaps it’s not surprising that NPM isn’t dating much better. 16 years later we are getting good security controls. Okay. I’m happy with Deno for most of my needs!
  - deleted 4mo ago
    [deleted]
  - the8472 4mo ago
    A different framing would be things moving from a high-trust equilibrium to a low-trust one due to a few bad actors and no other way to stop their activities. Security part reasonable code robustness, part Red Queen's race. Attackers expend ongoing effort for new exploits, defenders expend ongoing effort to get back into a secure place, everyone ending up where they started. If world were a nicer place we wouldn't have to "fix that shortly".
retardedsecguy 4mo ago
npm is basically pnpm now
- cute_boi 4mo ago
  Except pnpm is written in Rust and is very fast, saves disk and has much more advantage.
  - uasi 4mo ago
    > pnpm is written in Rust Not just yet. The Rust rewrite of the installation engine is still experimental and available as an opt-in preview[0]. [0] https://github.com/pnpm/pnpm/releases/tag/v11.2.2 https://github.com/pnpm/pnpm/releases/tag/v11.2.2
deleted 4mo ago
[deleted]
Pxtl 4mo ago
I would've assumed lockfile-by-default. We're still going with auto-updating?
- zero_shift 4mo ago
  You do get a lockfile by default
zarzavat 4mo ago
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.
- ifwinterco 4mo ago
  Issue is this is such a pain (and shuts out a large percentage of the world population) that you'll inevitably get a parallel ecosystem of packages without these onerous controls that everyone would end up using. I don't know how to square the circle but any variation of "make it safer but really painful and difficult for anyone to publish a package" has this problem
- inigyou 4mo ago
  How would this prevent Shai Halud?
- hinkley 4mo ago
  No, because we've already had documented cases of people socially engineering exploits into OSS projects. See also https://wikipedia.org/wiki/Confused_deputy_problem https://wikipedia.org/wiki/Confused_deputy_problem You don't need permission to publish an exploit, you just need someone or something else to do it for you.
SCLeo 4mo ago
I don't get it. How does this help with anything? You pull in a dependency to use it, right?
- dlopes7 4mo ago
  Well pulling some code is different than running a script on your machine
  - SCLeo 4mo ago
    Frequency of actions matter, especially for security changes. If we are talking about git, I agree. If we are talking about npm, I bet 95%+ times people install packages in order to use them, not just to admire the code. Someone else in this thread mentioned that npm can be used to manage pure front end libraries, which is a fair point.
thrdbndndn 4mo ago
How do you allow scripts for tools installed globally?
- jamiem 4mo ago
  Either pass the --allow-scripts=<pkg> flag with npx or npm install -g, or set allow-scripts=<pkg> in .npmrc
beart 4mo ago
Does the allow list in package.json pin to the package version, or only to the package name?
cookiengineer 4mo ago
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.
- woodruffw 4mo ago
  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.
- garbagepatch 4mo ago
  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 https://nodejs.org/api/permissions.html
  - hedora 4mo ago
    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.
vladsiu 4mo ago
[dead]
jbverschoor 4mo ago
And when will we get rid of the vendored node_modules, and make it read only?
alexghr 4mo ago
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
- jamiem 4mo ago
  Major npm version bumps have landed mid-stream for node in the past: v18.19.0[1] and v20.10.0[2] bumped npm 9 to 10. [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v10 https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v... [2]: https://nodejs.org/en/blog/release/v20.10.0 https://nodejs.org/en/blog/release/v20.10.0
- b112 4mo ago
  They are changes in defaults, which could be construed as a security posture change, but the security fix is in everyone's hands. Just set proper defaults, as per article, and done. I think the best part of this change, is that the default change will mean that lots of new DEVs just running an install, will see instant breakage with annoying packages that presume these settings are on. It should force people to stop expecting scripts to be runnable, for example.
jocelyner 4mo ago
[flagged]
partsch 4mo ago
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.
- partsch 4mo ago
  To the people downvoting my comment: Feel free to answer my question. I really don't know the answer.
- rozenmd 4mo ago
  I worked on a project that used yarn from the early days all the way up to v3, it's slow as hell, but it works. They also have the supply chain protections. Eventually we snapped and migrated to pnpm. Installs (both in CI and on local dev machines) are significantly faster. Turned out to be about a day's work to migrate with an LLM's help.
  - chandan-1427 4mo ago
    [dead]
  - arcatek 4mo ago
    I don't doubt that 3.x probably has worst perfs (it's almost two years old now), but just to clarify we closely track performances and Yarn and pnpm and pretty much on similar level: https://p.datadoghq.eu/sb/d2wdprp9uki7gfks-c562c42f4dfd0ade4885690fa719c818 https://p.datadoghq.eu/sb/d2wdprp9uki7gfks-c562c42f4dfd0ade4...
- homebrewer 4mo ago
  One distinguishing feature is their optional install strategy: running packages directly from compressed archives instead of unpacking them into node_modules. https://yarnpkg.com/features/pnp https://yarnpkg.com/features/pnp Very similar to using .jar's in Java instead of directory trees of .class files. It's somewhat hacky though, and editor/tool support varies. - since there are far fewer small files, it can be faster especially on Windows if you're forced to work on it for some reason - the archives can be stored into the git repository (through git-lfs or friends), removing dependency on the internet and the package registry
peterkelly 4mo ago
Now all the malware can move from the install script to the module itself where it will inevitably still be run
- hinkley 4mo ago
  But at least we have ways now to stay a week behind everyone else and see how many people drop dead before us. So what it'll really be is people injecting exploits that are patient.
chimpanzee2 4mo ago
Cool, but I default to pnpm these days anyway.
atraac 4mo ago
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.
- gear54rus 4mo ago
  Absolutely not, there are plenty of use-cases for them. https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package comes to mind off the top of my head. Hopefully current hysteria will not result in some bs decisions like this.
  - philipwhiuk 4mo ago
    The entire use-case of that package is a security nightmare.
    - gear54rus 4mo ago
      Then don't use it. Just don't presume to tell me if I can or can't.
      - dgellow 4mo ago
        Given that has an impact over the whole industry, I will for sure tell you that patching on install SHOULD NOT be a thing. Up to you to run your own post install script yourself
        gear54rus 4mo ago
        [flagged]
        ramon156 4mo ago
        Elaborate on the "behave properly". What is properly here?
philipwhiuk 4mo ago
> 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
z3t4 4mo ago
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.
- tobyhinloopen 4mo ago
  That’s a bold claim to randomly write without any supporting sources
  - z3t4 4mo ago
    I've got an example and submitted it via bug bounty channel, but they classified it as "social engineering".
bastawhiz 4mo ago
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.
- afavour 4mo ago
  Eh, it was pretty terrible before the acquisition too...
  - hinkley 4mo ago
    It's way less shitty now. Though one could kill a couple beers just complaining about how many major node versions it took before it wasn't shitty.
- flexagoon 4mo ago
  Happened in 2020 apparently https://github.blog/news-insights/company-news/npm-is-joining-github/ https://github.blog/news-insights/company-news/npm-is-joinin...
- beardsciences 4mo ago
  I literally said "Oh, of course" out loud.
- classified 4mo ago
  Strategical positioning for enshittification, control and future squeezing of profits. Embrace, Extend, Extinguish. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
  - sneak 4mo ago
    I don't think Microsoft is trying to extend and extinguish javascript or typescript. I do, however, think they are using their standard anticompetitive playbook to disadvantage IDEs that aren't VS Code and agents that aren't Copilot. For example, it requires some hackery to use your Copilot subscription via the Copilot extension in VSCodium (the f/oss distribution). They want the default to be writing javascript (where the default is npm), written in VS Code, publishing to GitHub. You can already see NPC devs mindlessly following this pattern. The response is to refuse to use Microsoft software. Use a Mac, don't use Excel or Word, don't use VS Code. I've also pulled my repos from GitHub and won't publish there or on npm. Their ecosystem makes the world worse, even before you factor in the fact that they happily provide services to ICE to aid them in running concentration camps.
butz 4mo ago
Better late than never.
WhyNotHugo 4mo ago
> To see what would be blocked, run npm approve-scripts --allow-scripts-pending This naming is atrocious: the verb is "allow", but this actually _displays_ a list of those unapproved? Was --show-blocked too obvious?

484 points by plasma 4mo ago

TZubiri 4mo ago

Looks good? But doesn't this just change the compromise window from first installation to first run?

christophilus 4mo ago
Better than nothing. That’s the same problem every package manager has.
semiquaver 4mo ago
Ok? Not sure what a package manager can do about the fact that eventually you want to run the things you install.
- frabcus 4mo ago
  Have any kind of provenance. eg like Debian has for 30 years. Key signing in person etc
  - tpetry 4mo ago
    That has also been implemented recently. With staged publishing the author must verify a new release with 2FA so automated attacks dont work anymore. Some human in the loop must verify a release.
Someone1234 4mo ago
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.
- mschuster91 4mo ago
  An idea might be to not just pin "package xyz allowed", but "package xyz postinstall allowed with hash <1234>".
  - jffry 4mo ago
    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-scripts-pin 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>"
- spartanatreyu 4mo ago
  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.
grassfedgeek 4mo ago
"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.
- tabwidth 4mo ago
  Build tooling still runs though. Your bundler plugin or PostCSS transform gets full fs access at build time, nobody's auditing that.
  - TZubiri 4mo ago
    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 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.
- WatchDog 4mo ago
  "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.
- TZubiri 4mo ago
  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 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
insanitybit 4mo ago
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.
- tentacleuno 4mo ago
  v8 does have a sandbox feature for running untrusted scripts, and it's quite good. There's also Node's VM module.

aniceperson 4mo ago

didn't know npm was owned by github.. well, that explains things...

joeyhage 4mo ago
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
- amitport 4mo ago
  To be fair, NPM sucked long before it got acquired by Github/Microsoft. And to be fair 2: The other package repos also suck.
  - tempay 4mo ago
    To be fair, the entire problem space sucks and I’m not sure it’s possible not to.
  - jbverschoor 4mo ago
    Yeah, but the azure supply chain attack explains why all of a sudden they can make this change. It seems that if you want to get something important changed in npm, you simply need exploit some of its short comings against Microsoft instead of discussing why it’s necessary.
  - creesch 4mo ago
    > And to be fair 2: The other package repos also suck. If you mean other languages, then yeah a lot of similar issues and weirdness there as well. Maven dependencies in any complex project are a "fun" challenge as well. Though the sort of recurring supply chain attacks you see within the npm ecosystem is something I haven't seen elsewhere to this degree.
  - hinkley 4mo ago
    Maybe I have nostalgia blinders on but I do NOT remember putting up with this much bullshit in the Ruby ecosystem and I didn't even like ruby. Gemfiles were pretty okay, and gemfiles are what everyone assumed npm would be a copy of. It wasn't.

Tiberium 4mo ago

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?

mort96 4mo ago
Hahaha that's amazing, just a big red "RETIRED" badge above their blog post? What the hell
- petetnt 4mo ago
  Breaking changes have had that tag for ages
  - mort96 4mo ago
    Really? Retired? What does that even mean in this context, why not "breaking" or something else that suggests breaking change?
    - behindsight 4mo ago
      > 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
      - mort96 4mo ago
        What exactly is it that's now retired that used to be deprecated? Isn't this just a collection of breaking changes to defaults?
        behindsight 4mo ago
        if you go to the full changelog on the blog and click on the "retired" button, the url will have type=deprecations as the parameter. It's a holdover from previous posts where there were more clearly defined deprecations. but yes, in this case it's more of a behavioural change of defaults, so they just picked the closest vaguely mapped retired/deprecations tag. 1: https://github.blog/changelog/?type=deprecations https://github.blog/changelog/?type=deprecations

cute_boi 4mo ago

They should have added a 1-day age limit by default, so security scanners have some time.

KolmogorovComp 4mo ago
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.
- jnwatson 4mo ago
  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.
  - alexdns 4mo ago
    so this parameter can be passed by the attackers also thus making your point pointless
    - gbear605 4mo ago
      The idea of the parameter is stopping the attackers from getting on your system in the first place
    - therealmarv 4mo ago
      that parameter cannot be set by a package, you only can set it
  - b112 4mo ago
    While I think this may be true, what validation do you have on this point? Have you rolled the numbers, vs all of the high-pri security updates that will be missed on day one, and exploited? What is really needed is simply more nuance. I agree the delay can help, but honestly the entire ecosystem is broken. There shouldn't be a single thing installed, without someone having an eyes-on. That's how this is fixed. Distros aren't perfect, but they handle this a load better. And this really runs to the problem, people want "new new new", yet often have very little real reason to want it. 99% of npm packages could be 5 years old, and no one would care. But outside of that, npm could operate like a distro, but with more of a Debian unstable -> testing method, where it typically takes a few days for this migration to happen. My point is, the fix isn't publishing by default, then hoping to catch. The fix is that nothing gets published, without a QA/validation step. Of course, that takes money. There is naturally, a super easy fix for that. The code stays open source. The licensing stays <insert whatever by author>. However? The ToS for using any or all of the npm architecture is if you're a company, you pay. If you neglect to pay, eg you don't register as a corporate entity, set up and account, and pay per use, then as per ToS the licensing is invalid, and you're fined via a copyright infringement. And yes, this would mean all npm packages would have an altered licensing model, basically with this tacked on. Is what I'm saying perfect? Nope. Yet it's the general path which should be taken. And frankly, with the way things are going, this level of audit would allow for staff also categorize licenses, ensure accurate template files, and so on. And some of this is the perfect use of an LLM. Not to do the work, but to flag with human review. -- This ecosystem is done. Its model is broken. The concept of downloading random stuff without auditing in any way, is broken. The industry will be moving away, is starting to move away, and is having to move away. So... how can this survive with that concept? If one doesn't like my proposal above, then they should provide an alterative which allows: * companies to have validate of licensing * audits which validate change is not untoward

efortis 4mo ago

this release fixes a vulnerability reported 10 years ago https://www.kb.cert.org/vuls/id/319816 https://www.kb.cert.org/vuls/id/319816

ares623 4mo ago
Breaking: AI fixes 10 year old vulnerability!

Zopieux 4mo ago

Eh, that only took a few dozen actively exploited supply-chain vulns in the span of two years!

dawnerd 4mo ago
Only took Microsoft themselves getting hit with it for things to change.

punkbit 4mo ago

> The resulting allowlist is written to package.json Couldn’t this effectively result in the same process we get in pre-12 defaults?

CGamesPlay 4mo ago
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.
- punkbit 4mo ago
  Thanks for the sanity check! Had a quick read on my mobile, and that was my first impression. Guess its more of a way to make the maintainers accountable instead of making npm reputation the main focus.

karakanb 4mo ago

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?

philipwhiuk 4mo ago
grep?

ComputerGuru 4mo ago

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)?

jamiem 4mo ago
Yes, all install scripts will be disabled by default regardless of if they are from direct or transitive dependencies. But if you're already following the os + cpu + optionalDependencies model to distribute your precompiled binaries you should be fine.

themafia 4mo ago

The "aw geez, enough is enough" release. Finally.

thatmf 4mo ago

> allowScripts defaults to off Nice that they're following pnpm's lead on this after [checks watch]... 18 months?

MrBuddyCasino 4mo ago
Java‘s Maven never had them, never felt a need for them. What is their purpose in JS land?
- dgoldstein0 4mo ago
  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.
  - WorldMaker 4mo ago
    After the backlash of using postinstall scripts for funding requests, most of that moved to the dedicated infrastructure of the `"funding"` key in package.json [1] and the `npm fund` [2] command. (Not that most companies/users pay any more attention to this funding request messaging other than maybe adding `--no-fund` to some of their `npm install` scripts, but it is still an improvement over using scripts to do it.) [1] https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#funding https://docs.npmjs.com/cli/v10/configuring-npm/package-json?... [2] https://docs.npmjs.com/cli/v11/commands/npm-fund https://docs.npmjs.com/cli/v11/commands/npm-fund
- tuananh 4mo ago
  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

tuckwat 4mo ago

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.

appplication 4mo ago
Great, now it’s python’s turn next
Eji1700 4mo ago
I do love that javascript's history is basically just coder mentality distilled. "oh yeah we'll fix that shortly" is almost always "oh fuck now we have to"
- port11 4mo ago
  I chuckled, but this is more about the history of NPM. In retrospect, allowing an ES consortium seat (Microsoft) to own the largest package repo for the language… might have been a bad idea? Google is one of the worst members of the language board, but Microsoft might be a close second. Given their ownership of GitHub came with a general community unease, perhaps it’s not surprising that NPM isn’t dating much better. 16 years later we are getting good security controls. Okay. I’m happy with Deno for most of my needs!
- deleted 4mo ago
  [deleted]
- the8472 4mo ago
  A different framing would be things moving from a high-trust equilibrium to a low-trust one due to a few bad actors and no other way to stop their activities. Security part reasonable code robustness, part Red Queen's race. Attackers expend ongoing effort for new exploits, defenders expend ongoing effort to get back into a secure place, everyone ending up where they started. If world were a nicer place we wouldn't have to "fix that shortly".

retardedsecguy 4mo ago

npm is basically pnpm now

cute_boi 4mo ago
Except pnpm is written in Rust and is very fast, saves disk and has much more advantage.
- uasi 4mo ago
  > pnpm is written in Rust Not just yet. The Rust rewrite of the installation engine is still experimental and available as an opt-in preview[0]. [0] https://github.com/pnpm/pnpm/releases/tag/v11.2.2 https://github.com/pnpm/pnpm/releases/tag/v11.2.2

deleted 4mo ago

[deleted]

Pxtl 4mo ago

I would've assumed lockfile-by-default. We're still going with auto-updating?

zero_shift 4mo ago
You do get a lockfile by default

zarzavat 4mo ago

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.

ifwinterco 4mo ago
Issue is this is such a pain (and shuts out a large percentage of the world population) that you'll inevitably get a parallel ecosystem of packages without these onerous controls that everyone would end up using. I don't know how to square the circle but any variation of "make it safer but really painful and difficult for anyone to publish a package" has this problem
inigyou 4mo ago
How would this prevent Shai Halud?
hinkley 4mo ago
No, because we've already had documented cases of people socially engineering exploits into OSS projects. See also https://wikipedia.org/wiki/Confused_deputy_problem https://wikipedia.org/wiki/Confused_deputy_problem You don't need permission to publish an exploit, you just need someone or something else to do it for you.

SCLeo 4mo ago

I don't get it. How does this help with anything? You pull in a dependency to use it, right?

dlopes7 4mo ago
Well pulling some code is different than running a script on your machine
- SCLeo 4mo ago
  Frequency of actions matter, especially for security changes. If we are talking about git, I agree. If we are talking about npm, I bet 95%+ times people install packages in order to use them, not just to admire the code. Someone else in this thread mentioned that npm can be used to manage pure front end libraries, which is a fair point.

thrdbndndn 4mo ago

How do you allow scripts for tools installed globally?

jamiem 4mo ago
Either pass the --allow-scripts=<pkg> flag with npx or npm install -g, or set allow-scripts=<pkg> in .npmrc

beart 4mo ago

Does the allow list in package.json pin to the package version, or only to the package name?

cookiengineer 4mo ago

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.

woodruffw 4mo ago
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.
garbagepatch 4mo ago
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 https://nodejs.org/api/permissions.html
- hedora 4mo ago
  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.

vladsiu 4mo ago

[dead]

jbverschoor 4mo ago

And when will we get rid of the vendored node_modules, and make it read only?

alexghr 4mo ago

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

jamiem 4mo ago
Major npm version bumps have landed mid-stream for node in the past: v18.19.0[1] and v20.10.0[2] bumped npm 9 to 10. [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v10 https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v... [2]: https://nodejs.org/en/blog/release/v20.10.0 https://nodejs.org/en/blog/release/v20.10.0
b112 4mo ago
They are changes in defaults, which could be construed as a security posture change, but the security fix is in everyone's hands. Just set proper defaults, as per article, and done. I think the best part of this change, is that the default change will mean that lots of new DEVs just running an install, will see instant breakage with annoying packages that presume these settings are on. It should force people to stop expecting scripts to be runnable, for example.

jocelyner 4mo ago

[flagged]

partsch 4mo ago

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.

partsch 4mo ago
To the people downvoting my comment: Feel free to answer my question. I really don't know the answer.
rozenmd 4mo ago
I worked on a project that used yarn from the early days all the way up to v3, it's slow as hell, but it works. They also have the supply chain protections. Eventually we snapped and migrated to pnpm. Installs (both in CI and on local dev machines) are significantly faster. Turned out to be about a day's work to migrate with an LLM's help.
- chandan-1427 4mo ago
  [dead]
- arcatek 4mo ago
  I don't doubt that 3.x probably has worst perfs (it's almost two years old now), but just to clarify we closely track performances and Yarn and pnpm and pretty much on similar level: https://p.datadoghq.eu/sb/d2wdprp9uki7gfks-c562c42f4dfd0ade4885690fa719c818 https://p.datadoghq.eu/sb/d2wdprp9uki7gfks-c562c42f4dfd0ade4...
homebrewer 4mo ago
One distinguishing feature is their optional install strategy: running packages directly from compressed archives instead of unpacking them into node_modules. https://yarnpkg.com/features/pnp https://yarnpkg.com/features/pnp Very similar to using .jar's in Java instead of directory trees of .class files. It's somewhat hacky though, and editor/tool support varies. - since there are far fewer small files, it can be faster especially on Windows if you're forced to work on it for some reason - the archives can be stored into the git repository (through git-lfs or friends), removing dependency on the internet and the package registry

peterkelly 4mo ago

Now all the malware can move from the install script to the module itself where it will inevitably still be run

hinkley 4mo ago
But at least we have ways now to stay a week behind everyone else and see how many people drop dead before us. So what it'll really be is people injecting exploits that are patient.

chimpanzee2 4mo ago

Cool, but I default to pnpm these days anyway.

atraac 4mo ago

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.

gear54rus 4mo ago
Absolutely not, there are plenty of use-cases for them. https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package comes to mind off the top of my head. Hopefully current hysteria will not result in some bs decisions like this.
- philipwhiuk 4mo ago
  The entire use-case of that package is a security nightmare.
  - gear54rus 4mo ago
    Then don't use it. Just don't presume to tell me if I can or can't.
    - dgellow 4mo ago
      Given that has an impact over the whole industry, I will for sure tell you that patching on install SHOULD NOT be a thing. Up to you to run your own post install script yourself
      - gear54rus 4mo ago
        [flagged]
        ramon156 4mo ago
        Elaborate on the "behave properly". What is properly here?

philipwhiuk 4mo ago

> 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

z3t4 4mo ago

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.

tobyhinloopen 4mo ago
That’s a bold claim to randomly write without any supporting sources
- z3t4 4mo ago
  I've got an example and submitted it via bug bounty channel, but they classified it as "social engineering".

bastawhiz 4mo ago

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.

afavour 4mo ago
Eh, it was pretty terrible before the acquisition too...
- hinkley 4mo ago
  It's way less shitty now. Though one could kill a couple beers just complaining about how many major node versions it took before it wasn't shitty.
flexagoon 4mo ago
Happened in 2020 apparently https://github.blog/news-insights/company-news/npm-is-joining-github/ https://github.blog/news-insights/company-news/npm-is-joinin...
beardsciences 4mo ago
I literally said "Oh, of course" out loud.
classified 4mo ago
Strategical positioning for enshittification, control and future squeezing of profits. Embrace, Extend, Extinguish. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
- sneak 4mo ago
  I don't think Microsoft is trying to extend and extinguish javascript or typescript. I do, however, think they are using their standard anticompetitive playbook to disadvantage IDEs that aren't VS Code and agents that aren't Copilot. For example, it requires some hackery to use your Copilot subscription via the Copilot extension in VSCodium (the f/oss distribution). They want the default to be writing javascript (where the default is npm), written in VS Code, publishing to GitHub. You can already see NPC devs mindlessly following this pattern. The response is to refuse to use Microsoft software. Use a Mac, don't use Excel or Word, don't use VS Code. I've also pulled my repos from GitHub and won't publish there or on npm. Their ecosystem makes the world worse, even before you factor in the fact that they happily provide services to ICE to aid them in running concentration camps.

butz 4mo ago

Better late than never.

WhyNotHugo 4mo ago

> To see what would be blocked, run npm approve-scripts --allow-scripts-pending This naming is atrocious: the verb is "allow", but this actually _displays_ a list of those unapproved? Was --show-blocked too obvious?