'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
dmix2026-06-01 22:42
ENGLISH (원문)
Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
phoronixrly2026-06-01 22:43
ENGLISH (원문)
What happens when everyone adopts this policy? You just change it to two weeks?
iwhalen2026-06-01 22:45
ENGLISH (원문)
uv supports the same for any Python developers out there: https://docs.astral.sh/uv/concepts/resolution/#dependency-co...
matheusmoreira2026-06-01 22:45
ENGLISH (원문)
All programming language package managers are vulnerable. They all have the exact same caveats as the Arch Linux User Repository. There are no trusted maintainers taking responsibility for things. Any random person can make an account and push packages.
chuckadams2026-06-01 22:46
ENGLISH (원문)
The big attacks of today are spread across several package ecosystems: TrapDoor and Shai-Hulud have been hitting npm, pypi, composer, and crates with the same malware.
ajross2026-06-01 22:47
ENGLISH (원문)
PyPI and Cargo are, 100%, vulnerable to this same class of compromises. That NPM sucks isn't a statement that everyone else doesn't.
gbuk20132026-06-01 22:47
ENGLISH (원문)
I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)
kalcode2026-06-01 22:51
ENGLISH (원문)
People make this joke often. It's package managers and how loose we are with installing them, not NPM. Cargo,PyPi,Nuget,PHP has had these recent too. It's not just only NPM. It's frequently repeated here just cause of the average bias against Node. But this problem isn't isolated to NPM.
darth_avocado2026-06-01 22:52
ENGLISH (원문)
There is something to be said about the need to keep all the packages as the latest and the greatest at all times. Every minor version update doesn’t need to be immediately applied. And maybe high and critical vulnerabilities don’t need to be a minor version upgrade.
Someone12342026-06-01 22:53
ENGLISH (원문)
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. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of other security settings, like minimum age, no trust downgrade, etc etc. All attackers can attack packages by updating how a package functions; but npm is particularly problematic as it runs non-sandbox scripts as the calling user. Putting not just your project at risk, but your entire machine/network. And this stuff has been known about for YEARS, they've taken no action.
twodave2026-06-01 22:55
ENGLISH (원문)
For smaller shops (by small I mean <1,000 employees) this isn't even tenable. We (engineering team of about 10 people) mitigate what we can via tooling and cooldown periods/minimum release age. This will work as long as these malicious packages remain reasonably detectable. I think that's the proper balance, because we can adjust the # of days we are willing to risk against the SOTA of detection tooling.
TZubiri2026-06-01 22:59
ENGLISH (원문)
tbf this is happening with a lot of package managers now, including pypi and composer
Cthulhu_2026-06-01 22:59
ENGLISH (원문)
Nothing that couldn't be automated; in Go land this is (arguably) called vendoring (https://go.dev/ref/mod#vendoring). Good to offload or reduce dependencies on 3rd party dependency hosters, pull a dependency into your own code review tools, and to ensure reproducible builds long term.
dboreham2026-06-01 22:59
ENGLISH (원문)
I think the general idea that your supply chain should be rooted in source repositories and associated commit hashes is the right one. Tooling can be made to automate the process of putting together a product from those defined sources. Some languages/systems already have some support for this. E.g. Golang and Rust. The concept of a "binary" artifact is really dead now everyone uses git and builds are quick. It lives on in things like npm and docker hub but we don't actually need it.
junon2026-06-01 23:07
ENGLISH (원문)
Please stop posting this on every single security incident thread with npm. It was funny once, it's just rehashing the same debate over and over.
Bilal_io2026-06-01 23:21
ENGLISH (원문)
The problem would be the dependencies of your dependencies, and keep going many levels.
mellosouls2026-06-01 23:23
ENGLISH (원문)
Should link to the original announcement I think: https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...
nailer2026-06-01 23:25
ENGLISH (원문)
I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong. So, explicitly: - pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer (limited) - Maven ...all allow scripts. We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager. npm shouldn't allow scripts, but exploits happen everywhere.
latexr2026-06-01 23:27
ENGLISH (원문)
There’s actually a blog post with that exact title. https://kevinpatel.xyz/posts/no-way-to-prevent-this/ https://news.ycombinator.com/item?id=48155690
댓글
20