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?

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

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.

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

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.

> 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

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.

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

> 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

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

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.

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

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

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

Are scripts even necessary? I don't think 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?

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.

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.

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.

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?

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.

Nix enters the room.

(Everyone claps.)

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.

It’s on by default in yarn 4 too now, but pnpm was the first to market that default minimum gate.

https://github.com/yarnpkg/berry/pull/7135

Sadly I haven't seen that Visual Studio/Rider/dotnet/Vs Code have such a feature for the c#/dotnet ecosystem.

pip has recently added a similar option, i.e.

`pip install --uploaded-prior-to P7D pre-commit`

https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-upl...

And somehow poetry doesn’t in 2026.

I’m having a real problem at work with security theatre and the growing push to obsess over numbers of “vulnerabilities” in our projects. And then auto Dependabot PRs that encourage churn to fix issues that if an informed person actually reviews easily concludes it doesn’t affect us in the slightest.

"maybe high and critical vulnerabilities don’t need to be a minor version upgrade"

huh? what do you suggest instead?

The gist link above covers how to use it in yarn, npm, and pnpm

The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level.

There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a ton of value with very little downside if people implement a one week cooldown period.

To answer your question directly, though. If everyone else moves to a one week cooldown, I would absolutely suggest a two week cooldown is a good idea. Being the "slow" moving organization is a good security trade-off so long as you don't take it to extremes and have escape hatches when you actually need to be moving quickly.

A large array of automated and semi-automated security scanners are finding things quickly. The main benefit of waiting before updating is to give those scanners time to work.

Security scans and authors realizing an unauthorized version was pushed will generally happen regardless of whether regular users updated. Even for compromises that are found by users updating, it'd generally be better to reduce the number of people affected with a slow roll-out rather than everyone jumping on at once.

You rely on the security companies scanning the packages.

Always one day more than people on HN tell you. If something is compromised you will hear people complaining here that three days is not enough.

This will never happen unless it's made the default. Most people will always stick with the defaults.

The problem is that node.js doesn't have a good standard library so one must rely on external packages to build even basic apps.

But presumably, you only include dependencies that you trust and those dependencies themselves do their trusting more strictly than you. Trust is built on vetting, signatures and reputation.

That is, at least what we do, in theory. In practice, we cross fingers and let the LLM pick dependencies, are satisfied if it just works and we either update our deps frequently or infrequently.

Except most of the attacks so far has not landed actually source code changes to git IIRC. They have targeting the release files directly.

It's a generic and very old term for committing dependencies to your repo, it's not go-specific.

I mean there’s nothing stopping you from committing node_modules to git (after running something like https://github.com/timoxley/cruft on it) and reviewing code changes on dependency updates.

I even managed to make that part of the workflow on one team I worked with but several other teams since thought it was a crazy idea. :)

Let’s not ignore that dependencies are far more common in JS than any of those other languages. My Go projects generally only include a handful of external packages. Node projects on the other hand…

In case others are unaware, you just have to set https://yarnpkg.com/configuration/yarnrc#npmMinimalAgeGate to the value you want. It defaults to 1 day.

I’ve always felt this automation shouldn’t exist at all, but should rather be selectively controlled via a hook. The hooks yarn offers out of the box for example can be used to run any code you need to after install. Putting the project owner in control instead of the dependency.

it wouldn't surprise me if insights was in fact a wrapper around npm install

https://dayssincelastjavascriptframework.com

Yeah but you don’t have to use that I think. I think us Node people can just pretend to write Ecmascript 2 in Java and be fine.

https://github.com/s4u/pgpverify-maven-plugin

If you want paranoid mode, you can verify literally every part of the maven build process.

What do u recommend?

Yes (assuming they're doing frontend dev and including the resources from the page). The code is fetched and executed from the browser, so It'll have to escape the browser sandbox to do something nefarious.

Yes, none of npm's lifecycle hooks. You're just pulling bytes over the wire.

So why else do we pay someone to package and certify/verify open source projects? This is absolutely 90++% of what should be RedHats core day job.