11 ms·
Upcoming breaking changes for npm v12
- philipwhiuk 3mo 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
- jbverschoor 3mo agoAnd when will we get rid of the vendored node_modules, and make it read only?
- aniceperson 3mo agodidn't know npm was owned by github.. well, that explains things...
- joeyhage 3mo agoMost 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 3mo agoTo be fair, NPM sucked long before it got acquired by Github/Microsoft. And to be fair 2: The other package repos also suck.
- tempay 3mo agoTo be fair, the entire problem space sucks and I’m not sure it’s possible not to.
- jbverschoor 3mo agoYeah, 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 3mo 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 3mo agoMaybe 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.
- amitport 3mo ago[dead]
- BowBun 3mo agoyes, since 2020
- shagie 3mo agoNPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 https://news.ycombinator.com/item?id=22594549 (March 16, 2020; 571 comments; 1829 points) - https://github.blog/news-insights/company-news/npm-is-joining-github/ 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. > ...
- w29UiIm2Xz 3mo agoTo be fair, the vibes (at the time) were that Microsoft has changed. Probably, in some way, a zero-interest rate phenomena.
- ok_dad 3mo agoYoung people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.
- Dylan16807 3mo agoMicrosoft has been causing a lot of problems lately but I completely disagree that it fits the pattern of "embrace, extend, extinguish".
- tyre 3mo agoYoung 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. Fifteen years ago we were writing HTML and JavaScript specifically for Internet Explorer. Edge is built on Chromium.
- ralph84 3mo agoNPM (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.
- hinkley 3mo agoNo there are gobs of node projects on GitHub. I'm sure someone did the math on how many paying customers would have been fucked if npm.org went away and it worked as a loss leader.
- materielle 3mo agoI 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.
- monster_truck 3mo agoAnd additionally was it truly worth buying if this is what we've ended up with? Some things should be allowed to fail
- arcatek 3mo agoEh, easy to say. Remember how Sourceforge started shipping ads in binaries people downloaded? If you think failing was the worst scenario, you lack imagination.
- domh 3mo agoI knew it was owned by github, but this is the first time I've personally seen the release notes on github's blog instead of npm's.
- Tiberium 3mo agoI 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 3mo agoHahaha that's amazing, just a big red "RETIRED" badge above their blog post? What the hell
- petetnt 3mo agoBreaking changes have had that tag for ages
- mort96 3mo agoReally? Retired? What does that even mean in this context, why not "breaking" or something else that suggests breaking change?
- behindsight 3mo 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 3mo agoWhat exactly is it that's now retired that used to be deprecated? Isn't this just a collection of breaking changes to defaults?
- behindsight 3mo agoif 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
- TZubiri 3mo agoLooks good? But doesn't this just change the compromise window from first installation to first run?
- christophilus 3mo agoBetter than nothing. That’s the same problem every package manager has.
- semiquaver 3mo agoOk? Not sure what a package manager can do about the fact that eventually you want to run the things you install.
- frabcus 3mo agoHave any kind of provenance. eg like Debian has for 30 years. Key signing in person etc
- tpetry 3mo agoThat 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 3mo agoI’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 3mo agoAn idea might be to not just pin "package xyz allowed", but "package xyz postinstall allowed with hash <1234>".
- cute_boi 3mo agoThey should have added a 1-day age limit by default, so security scanners have some time.
- KolmogorovComp 3mo agoI 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 3mo agoIf 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 3mo agoso this parameter can be passed by the attackers also thus making your point pointless
- gbear605 3mo agoThe idea of the parameter is stopping the attackers from getting on your system in the first place
- therealmarv 3mo agothat parameter cannot be set by a package, you only can set it
- b112 3mo agoWhile 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 3mo agothis 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 3mo agoBreaking: AI fixes 10 year old vulnerability!
- Zopieux 3mo agoEh, that only took a few dozen actively exploited supply-chain vulns in the span of two years!
- dawnerd 3mo agoOnly took Microsoft themselves getting hit with it for things to change.
- punkbit 3mo 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 3mo agoIt'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 3mo agoThanks 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 3mo agoIt 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 3mo agogrep?
- ComputerGuru 3mo agoMy 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 3mo agoYes, 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.
- thatmf 3mo ago> allowScripts defaults to off Nice that they're following pnpm's lead on this after [checks watch]... 18 months?
- MrBuddyCasino 3mo agoJava‘s Maven never had them, never felt a need for them. What is their purpose in JS land?
- dgoldstein0 3mo agoOff 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 3mo agoAfter 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 3mo agonative 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
- themafia 3mo agoThe "aw geez, enough is enough" release. Finally.
- tuckwat 3mo agoI 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 3mo agoGreat, now it’s python’s turn next
- Eji1700 3mo agoI 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 3mo agoI 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 3mo ago[deleted]
- the8472 3mo agoA 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 3mo agonpm is basically pnpm now
- cute_boi 3mo agoExcept pnpm is written in Rust and is very fast, saves disk and has much more advantage.
- uasi 3mo 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 3mo ago[deleted]
- Pxtl 3mo agoI would've assumed lockfile-by-default. We're still going with auto-updating?
- zero_shift 3mo agoYou do get a lockfile by default
- zarzavat 3mo agoThere'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 3mo agoIssue 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 3mo agoHow would this prevent Shai Halud?
- hinkley 3mo agoNo, 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 3mo agoI don't get it. How does this help with anything? You pull in a dependency to use it, right?
- dlopes7 3mo agoWell pulling some code is different than running a script on your machine
- SCLeo 3mo agoFrequency 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 3mo agoHow do you allow scripts for tools installed globally?
- jamiem 3mo agoEither pass the --allow-scripts=<pkg> flag with npx or npm install -g, or set allow-scripts=<pkg> in .npmrc
- beart 3mo agoDoes the allow list in package.json pin to the package version, or only to the package name?
- cookiengineer 3mo agoWhat 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 3mo agoI 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 3mo agoMost 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 3mo agoMost 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 3mo ago[dead]
- jocelyner 3mo ago[flagged]
- alexghr 3mo agoAre 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 3mo agoMajor 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 3mo agoThey 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.
- partsch 3mo agoI 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 3mo agoTo the people downvoting my comment: Feel free to answer my question. I really don't know the answer.
- rozenmd 3mo agoI 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 3mo ago[dead]
- arcatek 3mo agoI 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 3mo agoOne 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 3mo agoNow all the malware can move from the install script to the module itself where it will inevitably still be run
- hinkley 3mo agoBut 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 3mo agoCool, but I default to pnpm these days anyway.
- atraac 3mo agopostinstall 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 3mo agoAbsolutely 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 3mo agoThe entire use-case of that package is a security nightmare.
- gear54rus 3mo agoThen don't use it. Just don't presume to tell me if I can or can't.
- z3t4 3mo agonpmjs.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 3mo agoThat’s a bold claim to randomly write without any supporting sources
- z3t4 3mo agoI've got an example and submitted it via bug bounty channel, but they classified it as "social engineering".
- bastawhiz 3mo agoI'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.
- flexagoon 3mo agoHappened 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 3mo agoI literally said "Oh, of course" out loud.
- afavour 3mo agoEh, it was pretty terrible before the acquisition too...
- hinkley 3mo agoIt'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.
- classified 3mo agoStrategical 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 3mo agoI 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 3mo agoBetter late than never.
- WhyNotHugo 3mo 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?