Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this.

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.

> allows all packages to run package supplied arbitrary code as the logged-in user after an update completes

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?

> That's an INSANE default.

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.

One hour ago, while looking casually at a package.json, I saw this and was horrified:

  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.

Yes, this.

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...

Maybe NPM is scared to break a ton of packages? I also think action from NPM on the repo level is vital

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.

>Putting not just your project at risk, but your entire machine/network.

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.

> since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes.

This is semi-common and in no way unique to NPM.

So do the pre- and post-install scripts of Debian packages. The problem is not this but the lack of verified and controlled release channel.

> they've taken no action.

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

Mosts packages manager, allow that.

pnpm can still be exposed, afterall the worm simply have to wait you run tests locally.

I think another thing that affects security is that in javascript culture people often tie to the latest version instead of concrete version.

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.

i've been thinking about this as well. but having built a startup, i've learned that users don't care as long as they are given the value and most convenience. they don't really care much at security as much as we do. just look at openclaw? but maybe it's our job to make sure it is taken care of vs assuming the user cares and just make it look seamless.

> That's an INSANE default.

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?

So does dpkg & rpm

> Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes.

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

[dead]

Nearly every package manager I've ever used had post-install scripts. Most run as root, since that's what usually what the package manager runs as.

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.

And all of them "thought" of security as an after-after-after-after-after-thought.

The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.

> It's frequently repeated here just cause of the average bias against Node.

It’s frequently repeated here because NPM is where it keeps happening over and over and over and over and over and over again.

How many package managers allow executing arbitrary code as part of the installation process by default?

In short, the problem is `npm` not NPM.

IIRC, go cannot run arbitrary code at build time, so that should not make it vulnerable

It's far far harder to do something exploits like this in elm because effects are tagged. There are solutions out there.

Eh, it's worse than that. The GP comment is repeating a joke derived from an Onion headline about gun control. Where the very poignant message is about political will to make change. However, the npm ecosystem is very much willing and has already made several changes. If we're going to engage in discussion instead of meme-posting, the GP should have (imo) included real commentary _in addition to_ the meme they really wanted to post. What is the policy they want? Why do they see the NPM ecosystem as still resistant to change?

Nix enters the room.

(Everyone claps.)

While true, tarring Arch here is a little unfair. AUR isn't enabled by default. It can't even be used via the same package front end, and in fact the "official" usage model requires that you clone the source yourself.

Indeed, AUR is bad as a software distribution mechanism (really it's best understood as a proving ground for baby packages before they get real maintainers and distro blessing), but it's less bad than NPM which puts the malware in the trusted/default/automated path.

I think this is a thought-terminating cliche, and false equivalences. Stating "This area where problems occur at a high rate is not a problem, as problems can happen elsewhere too" is a curt dismissal of a valid concern. It implies the course of action, rather than to address a high-problem area, is to ignore any solutions which aren't global, or equate it to lower-incidence areas.

You bring up a good point that this class of problem, or related ones can occur with other package managers. It was frustrating how long it took the Crates.io team (Rust manager) to address name squatting, in what appeared to be a "no perfect solution exists, so we won't act" line of reasoning.

Are scripts even necessary? I don't think e.g. mvn has any form of scripts¹, but if the dependency is compromised, you're likely to execute whatever compromised code is in there the next time you do mvn verify (or whatever). Slightly less wormable maybe, running tests or at least checking whether your thing still runs after upgrading package versions is really common, no?

¹ Annotation processors are a thing and somewhat similar to rust macros in function, but you need to set those up manually for each dependency, iirc.

You didn't include Perl's CPAN, which I think is older (1995) than all of these. And it allows scripts as well.

If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution.

Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack.

Definitely not bulletproof but still IMHO more robust than "Lets just spray latest code from upstream without any review directly to production with a firehose!" that seems to be the norm.

Maven does not run arbitrary scripts just by including a dependency.

> HN downmodded the first comment to hell but I know I'm right and the crowd is wrong.

Got downvoted for saying it too. Don't let it discourage you.

It's not the package manager, it's the repo and the cryptographic signatures that are trusted by the package manager and the users who choose to point their pacakge managers at those repos. The fundamental problem here is that people's risk assessment is treating a user named devioustiger12345 as having the same situation and story as Microsoft/Apple/Red Hat.

On the other hand, if the same problem keeps happening, it's hard to argue that the problem isn't foundational to the design and that it should be called out until either the problem is fixed or the design abandoned.

Why should they stop? Maybe they want to rehash the issue that's not being adequately addressed. Maybe it's not supposed to be funny.

How do you propose we address this issue? Instead of policing what people say, are you interested in sharing your or someone else ideas?

Opponents of gun control surely feel the same way about the Onion’s story.