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.
> ...
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.
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 to be fair 2: The other package repos also suck.
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.
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.
It wasn't.
Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process.
So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens.
It seems to me that this is a small stumbling block at best, unless the whole ecosystem moves to a deno-like sandboxed environment. Maybe that is the plan?
Removing automated execution of postinstall is a necessary step and may as well be the first one.
[1] https://docs.cypress.io/app/component-testing/get-started?ut...
I didn't try devcontainers stuff, TBH. But that's how I often develop my apps.
That said, there are other attack surfaces for that approach. For example I'm not sure if I can trust LSP server not to execute application code. So keeping everything in a container or in a VM seems to be the only sane approach to work with code you don't trust.
At this point I will not do any dev outside of a container - so many things can be supply chained in the OSS dev stack it's just not worth it, and once you get used to developing in containers it's actually a lot cleaner to move between hosts - you're essentially treating your client as a remote terminal.
If you're doing web dev work in this day an age SSH with tmux or some editor with SSH server support should be your dev setup.
That would / could kill performance
> Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process.
So I doubt most people trace every dependency they install all the way. So sometimes it comes upstream. Maybe you don't run it. It could have been a dev dependency accidentally set for runtime and now you have it.
And IIRC that one was fixable by a PR, because they'd done something weird and there was an idiomatic way to accomplish the same thing.
Hopefully current hysteria will not result in some bs decisions like this.
If there are other use cases that really need post-install scripts, you can whitelist just those in pnpm. In projects I'm working with, there are often zero post-install scripts that must be enabled for everything to work properly, and it's usually from poorly cobbled packages that use them to download prebuilt binaries (well written packages, like biome or tsgo, use per-architecture subpackages).
You enable just one or two of those, and block everything else.
I work in a monorepo where running install calls dozens of deeply nested postinstalls of some elaborate NextJs or React Native dependencies other projects use. It's borderline insane. Unless you regularly screen everything, it's impossible to know whether one of those is compromised, especially in the world of Node where is-even is being used and the sheer amount of crypto scams around.
A better safety net would be to require active 2FA proof for every package update.
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.
(You write something)
So then you have to check every package's updates and decide if you update, yes?
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
https://red.anthropic.com/2026/n-days/
So that is a poor bandaid to use now. Maybe instead validate things before, and have more of a cathedral and human reputation system.
Which was a little weird for the modules that don't run standalone but whatever.
https://github.blog/news-insights/company-news/npm-is-joinin...
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
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.
Or Linux: an actual FOSS OS.
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.
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.
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.
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.
If you force every user to just write "mut", guess what will happen?
They will write "mut" when they need mutable variables, which in practice turns out to be the minority of variables.
It's the same with "Option". The vast majority of variables or struct members do not need to be nullable at all.
This is the wrong analogy.
The equivalent analogy would be using a compiler flag that is triggered for all dependencies and all included libraries without a per-library or per-file changeability. Something like "gcc --force-mut-all-yolo".
Variables have scopes of concern. This new NPM feature has no scope. And that's what my critique is about, because it makes it still unpredictable if any of your dependencies of dependencies needs a script.
The spread vector of potential malware stays identical, because the reason the miasma worm is spreading so fast is because of dependencies of dependencies that are impossible to audit on a case-by-case basis, given the lack of sandboxes and the lack of allowlisting scripts on a per-dep-and-version basis.
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!
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".
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.
See also 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.
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
[1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v... [2]: https://nodejs.org/en/blog/release/v20.10.0
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.
Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?
But if you're already following the os + cpu + optionalDependencies model to distribute your precompiled binaries you should be fine.
So what it'll really be is people injecting exploits that are patient.
