In about 99% of cases, I have the option to pick between Microsoft, a 3rd party or myself. I'm picking that first option every time I can. If M$ can't handle it, I'm hand rolling it.
Dapper remains the only constant 3rd party dependency in my projects. I don't know how much longer this will last with LLM assistance. The frontier models are very good at writing repositories over arbitrary sql schemas with low level primitives now.
This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing small things (left pad) rather than larger utilit libraries maintained by a larger community.
A larger community contributing to a larger library would mean that a larger community feels responsible and checks it.
That small package mentality a trace to web usage: JavaScirpt code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.
With server side Node.js this lead to tons of dependencies ... which is worsened by npm allowing to have multiple versions of the same package in parallel. So if something depends on leftpad 1.0 and something else in leftpad 1.1 both are fetched and both are available.
IIRC 6 years ago the full dependency tree congealed into more than 2000 packages. One small example is React itself:
- 5 deps: https://www.npmjs.com/package/react/v/15.6.2
- 0 deps: https://www.npmjs.com/package/react/v/19.2.6
Another is switching from create-react-app with its hundreds of transitive dependencies to vite, which, according to the test I've ran just now, currently has 15. Etc.
I mean, the current "allow ANY filesys operation" can't cope with modern supply-chain attacks...
with deno, you can specify folders/files that the execuble/library CAN touch (or CANNOT)
Which is another part of this entire insanity:
Browsers are already <<huge>>. They're also built by <<huge>> companies companies that collect <<tons>> of analytics.
You'd think at this point they could present a proposal for a rock solid extended JavaScript standard library that would be based on actual website usage and would be comparable to what Java, .NET offer, obviously only keeping the parts that would be applicable to the web.
It sounds crazy but I think the Chrome installer is 150MB and an entire decent stdlib these days would probably be 1-5MB...
Issue probably is that the standards process is slow (unless it is a feature Google "needs") and full of bike shedding (which features and how exactly they'd look) and adaption of features by developers is slow.
JavaScript meanwhile should be stable enough as an environment to allow a broader standard library.
Luckily it is slowly getting better (see Temporal as new date library, replacing moment.js usage in many places)
The other issue is the sheer amount of tooling and “plugins” for those toolings. Like the babel and webpack situation, which is truly kafkaesque.
IME dotnet dependency situation is a tire fire, not a month goes by without another dependency biting the dust or going fully commercial with no notice. Which is fair, I suppose, but Go and Java ecosystems don't have it nearly as bad.
- FluentAssertions had no moat, and it has been forked as AwesomeAssertions. Not sure what the author's play was here.
- Moq lost trust - we have NSubstitute
- AutoMapper and MediatR have been widely misused anyway
- Maybe MassTransit is a real bummer?
The largest dotnet project I am responsible for has around 50 megabytes of source files sitting on its main branch right now. If you include the generated WCF references it's probably closer to 100 megabytes.
As opposed to the completely untrusted package supplied arbitrary code that the logged in user executes when they actually use the package immediately after installing it?
And if you run tests in CI/CD, or in a container, why you are downloading code locally ? Only thing that comes to mind is code completion but surely most people at least run unit tests locally before pushing the code out ?
Regarding npm CLIENTS, PNPM is fundamentally different from (and superior to) npm or yarn.
Strongest possible recommendation to use pnpm.
It's also a good idea to use a private registry (eg via jfrog), acting as a proxy / pull-through cache, and point trad SAST and maybe AI scanners at it.
But dropping the npm client in favor of pnpm is a no-brainer. Speed, disk space, security, determinism, flexibility, fine-grained control over your dependency graph...
rm -rf pkg/snippets & rmdir pkg\\snippets /s /q & wasm-pack build --target bundler && node prepare-web.js
Poor Claude has been trained on so much awful human code that it required several prompts for it to admit that there was indeed a problem.
The industry is the process by which convenient crap like this gets standardized.
To say nothing about running a sequence of shell commands without the -e option.
Claude probably birthed this abomination in the first place
Between average hackers and extortion groups, foreign governments and state sponsored actors and last but not least my own government, I don't think there's much room left for non-compromised supply chains these days. Treat everything that can run foreign code as potentially compromized and keep everything compartmentalized. If you keep your crypto wallets or private banking info on the same machine where you do development, you're asking to get shafted one day. Or if you keep your big corporate github keys on the same machine where you do private weekend projects. It doesn't matter what you use in particular, even if some vectors are currently more popular than others.
I agree that not running arbitrary installation scripts is the right default, but it's just an incremental improvement.
The practical difference between code that runs at installation and code that runs when the package is executed is, very typically, a small amount of time.
IMO, the hyperbole here hurts because it distracts from more effective efforts.
For example?
To see what I mean, try actually packaging a cross-platform binary dependency in their ecosystem.
This is semi-common and in no way unique to NPM.
Either way it misses the point, nobody just fetches code and removing post-install scripts wouldn't change much because you're going to run `npm run something` 5 seconds after you run `npm install`.
Really the reason not to allow that is for robustness, not security. You ideally don't want package installs doing random stuff to your system because package authors are generally bad at doing that sort of thing cleanly.
The security impact is relatively minimal because as other people have said, you just installed a package. What's the very next thing you're going to do? Compile/run it obviously.
So not running package installation scripts is a huge, massive problem.
It is possible that not running package installation scripts could improve security, but for that you need really good sandboxing/compartmentalisation of library code, e.g. with CHERI, WASI component model, or if all of your code must run in a secure context it probably helps.
But those situations are unfortunately rare in my experience.
SIXTEEN YEARS of development and they can't even resolve a tree of dependencies in the correct manner unless you nuke the lockfile and node_modules.
Dependency resolution is literally the number one task and they fail at it. How can you expect them to be good at anything else? Absolute joke.
Not running lifecycle scripts by default is eventually going to be the default behavior. Late is worse (edit: I meant better) than not at all. https://github.com/npm/rfcs/pull/868
pnpm can still be exposed, afterall the worm simply have to wait you run tests locally.
https://news.ycombinator.com/item?id=45041798
If you only ever use js/ts for frontend projects (like we do), it closes one major hole that I'm aware of, which still leaves at least two:
- the editor possibly starting random binaries from inside the mode_modules (such as biome, vitest, tsgo)
- escape from sandbox by using some kernel vulnerability, of which there have been many recently
But that's a "Perfect is the enemy of good"-like argument. Wherein: Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect.
Plus, to me, it is a culture issue. npm just doesn't take security seriously, so we don't see these improvements, and if there was additional test hardening later, I don't expect we'd see them in npm either. Since, they just don't care.
Meanwhile in the nuget ecosystem is way smaller and have way less mainteners involved for a single given dependency.
JS didn't have a passable stdlib until ES6. It had bugs built into it because Eich was given a stupidly short time window to deliver the first version. Everyone (particularly MS) had (and still sort of do) their own way of interpreting the language. In spite of all of this it became the primary way of developing applications for public consumption.
This led to a bunch of people who wanted to be the 10x JS engineer to solve problems with their own libraries and technologies. None of them really talked, they just threw their packages on NPM's registry without second thought and some gained widespread use just by accident.
Google tried fixing some of this with Dart but chickened out at the last second. TypeScript was designed by someone competent but can't fix the larger cultural issues.
This is what happens when you put SV hubris and "moving fast and breaking things" over doing things the right way.
I'm still trying to calibrate my take on this view.
If attacks are randomly chosen from the set of all potential vulnerabilities, without the attacker knowing which ones had been patched, then that logic clearly makes sense.
But in an adversarial situation where the attacker can guess which vulnerabilities you still have unpatched, or can try many different attack vectors, then having already patched some other vulnerabilities doesn't matter so much.
I guess reality is more complicated though.
I went through the package.json on my machine - seems like ~400 / 60000 or 0.7% have (pre|post)install. (That's not all of the scripts that run at install)
Seems to me like a backwards compatibility is a non argument since pnpm is popular enough to stand as existence proof that scripts can be, at least, opt-in
IMO - pre- and post- install scripts should just be abolished/deprecated. It should require a special dispensation from npm to even publish one. A better system for binaries (needed by esbuild) is probably needed.
Even saying "just use pnpm" isn't enough, we need to get the developer community to herd immunity and that isn't going to happen on an opt-in basis.
I would love for npm to sandbox as well. But I think the better way forward is just turn off scripts.
This makes it so an update to a popular library can compromise a huge number of packages that depend on it.
In Java for example almost all packages specify a concrete version, even if someone compromises the latest the blast radius is usually pretty small.
It's also the standard, and by far it's the contrast to not allow this. pnpm has a massive advantage of being the non-standard package manager, npm does not have that - what do you suggest that npm does?
It could require a 48 hour cooldown period on any package update that wants to add an install script that didn't have one before, and has a certain number of downloads. And it could publish the list of these so security researchers have an opportunity to scan them.
It could add an optional key to package.json that allows someone to whitelist which packages can run install scripts.
It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI; (2) this hardened package status would be public, and (3) a developer could set a flag in their package.json that causes any npm action to act as if all non-hardened packages had frozen versions.
And so much more.
> It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI;
Great, they did this.
> And so much more.
This shit takes time. Yes, they should have done this on day 1. Acting like any of this is easy to retrofit is just nuts though.
Of course this should have been started since the beginning of the major recent stream of supply chain attacks, circa 2024 or 2025... but even assuming the most backwards calendaring possible -starting after the last bug compromise (Axios, on March 31st)- that new flag should have already been shipped a couple weeks ago.
Shit does take time, but where there's a will there's a way, and nobody buys that this shit would take that much time.
security is a hidden requirement.
Many package formats before NPM allowed for it, and frankly, it matters little, because if it can add code to your app it can run malicious code. The fact it executes on package install rather than when dev runs tests or the app matters little, and in general if environment is sandboxes, the package install is also ran in the same sandbox so disallowing it changes little.
so yes, every package manager can be hit, the reason is twofold
* JS is such a lowest common denominator it has that much more clueless users so just by scale every issue will be more common than in other languages
* extreme fragmentation leading to hundreds of packages needed for even small projects, which is again more chances for compromise
It's not unreasonable: you're already installing software, which presents risks. If post-install scripts were not a thing, a payload could still run because you ran the software you installed. Or because the installer added it to auto-run. Or because the installer placed it somewhere where it would be dynamically loaded all the time.
You're collapsing two different threat models. The risk isn't that code runs, it's WHEN it runs. This worm spreads because npm install runs arbitrary scripts as you, automatically, just from resolving the tree. You don't have to build it, run it, or even import it. Opening the project in an IDE is enough. apt/dnf scripts run on packages a maintainer signed and a distro gatekept. Not on whatever some rando pushed to a public scope 20 minutes ago that landed in your lockfile six levels deep. "They both technically execute code" is true and beside the point. One runs signed code from a trusted path, the other runs unsigned code from the default automated path. That's the whole ballgame.
> You don't have to build it, run it, or even import it
If you just installed something with npm, chances are you'll be running it shortly, either as a tool or a library, probably minutes or seconds later. I imagine the use case of installing an npm package you don't plan on using or transitively importing, constitute a small portion of npm installs.
Unfortunately apt/dnf isn't much better here because random tutorials online suggest people add random repositories where the creator of any repository effectively has root access to anyone machine that adds it as a remote.