Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

Post reply on HN
Print view View original

371–380 of 797 posts

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#371

Post by tim1994 »

plomme wrote: post #346
darkamaul wrote: post #26

The "use cooldown" [0] blog post looks particularly relevant today. I'd argue automated dependency updates pose a greater risk than one-day exploits, though I don't have data to back that up. That's harder to undo a compromised package already in thousands of lock files, than to manually patch a already exploited vulnerability in your dependencies. [0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.

Because updates don't just include new features but also bug and security fixes. As always, it probably depends on the context how relevant this is to you. I agree that cooldown is a good idea though.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#372

Post by 15155 »

oftenwrong wrote: post #309
JD557 wrote: post #265

Earlier quoted context omitted.

I have a similar opinion but I think Java's model with maven and friends hits the sweet spot: - Packages are always namespaced, so typosquating is harder - Registries like Sonatype require you to validate your domain - Versions are usually locked by default My professional life has been tied to JVM languages, though, so I might be a bit biased. I get that there are some issues with the model, especially when it comes…

Maven does not support "scripts" as NPM does, such as the pre-install script used for this exploit. With scripts enabled, the mere act of downloading a dependency requires a high degree of trust in it.

Downloading a dependency also requires a high degree of trust in whatever transitive dependencies that a trusted dependency decides to pull in.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#373

Post by kunley »

Why the biggest package mess is always with the Node ecosystem?

Why in particular this community still insists on preemptively updating all deps always, on running complicated extra hooks together with package installation and pretending this all is good engineering practices? ("Look, we have so plenty of things and are so busy, thus it must be good")

Why certain kind of mindset is typical to this community?

Why the Node creator abandoned his creation years ago?

Why, oh why?

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#375

Post by kernc »

giantg2 wrote: post #220
bodash wrote: post #217

I compiled a list of NPM best practices one can adopt to reduce supply chain attack risks (even if there's no perfect security preventions, _always_): https://github.com/bodadotsh/npm-security-best-practices Discussion on HN last time: https://news.ycombinator.com/item?id=45326754

Do you know of anything similar for pip?

No.1: Run untrusted code in a sandbox! https://github.com/sandbox-utils/sandbox-venv

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#376

Post by Ygg2 »

nalekberov wrote: post #139
Ygg2 wrote: post #25

Earlier quoted context omitted.

But you also need the latest versions to avoid zero-day attacks.

do zero-days even care about versions?

They care how long you take to patch your versions. Delaying patching by 7 days will affect it.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#377

Post by sublinear »

rlpb wrote: post #320
sublinear wrote: post #5

Earlier quoted context omitted.

The list of affected packages are all under namespaces pretty much nobody uses or are subdependencies of junk libraries nobody should be using if they're serious about writing production code. I'm getting tired of the anti-Node.js narrative that keeps going around as if other package repos aren't the same or worse.

You need to explain how one is supposed to distinguish and exclude "namespaces pretty much nobody uses" when writing code in this ecosystem. My understanding is that a typical Node developer pretty much has no control over what gets pulled in if they want to get anything done at all. If that's the case, then you don't have an argument. If a developer genuinely has no control, then the point is moot.

How is this situation any different from any other ecosystem? I think you don't have an argument here other than that npm is a relatively large public repository. Bad actors and ignorant developers are everywhere else too.

There are plenty of npm features to help assess packages and prevent unintended updates, but nothing replaces due diligence.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#378

Post by WorldMaker »

vintagedave wrote: post #2

Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about. I just keep reading more and more stories about dangerous npm packages…

I've started to feel it is much more an npm problem than a node problem. One of the things I've started leaning on more is prioritizing packages from JSR [0]. JSR is a part of Deno's efforts, so is often easiest to use in Deno packages, but most of the things with high scores on JSR get cross-published to npm and the few that prefer JSR only there's an alright JSR bridge to npm.

Of course using more JSR packages does start to add more reason to prefer Deno to Node. Also, there are still some packages that are deno.land/x/ only (sort of the first version of JSR, but no npm cross-compatibility) worth checking out. For instance, I've been impressed with Lume [1], a thoughtful SSG that's sort of the opposite of Astro in that it iterates at a slow, measured pace, and doesn't try to be a kitchen sink but more of workbench with a lot of tools easy to find. It's deno.land/x/ only for now for reasons I don't entirely agree with but I can't deny that JSR can be quite a step up in publishing complexity for not exactly obvious gain.

[0] https://jsr.io/

[1] https://lume.land/

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#379

Post by jalapenos »

kunley wrote: post #373

Why the biggest package mess is always with the Node ecosystem? Why in particular this community still insists on preemptively updating all deps always, on running complicated extra hooks together with package installation and pretending this all is good engineering practices? ("Look, we have so plenty of things and are so busy, thus it must be good") Why certain kind of mindset is typical to this community? Why the…

Feels good, just for a second, to type pretence you're above everyone doesn't it? Just for those few seconds, you're better than a big whole arbitrary collection of people, and for those few seconds you have relief from the reality of your life.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#380

Post by theptip »

tim1994 wrote: post #371
plomme wrote: post #346

Earlier quoted context omitted.

Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.

Because updates don't just include new features but also bug and security fixes. As always, it probably depends on the context how relevant this is to you. I agree that cooldown is a good idea though.

IMO for “boring software” you usually want to be on the oldest supported main/minor version, keeping an eye on the newest point version. That will have all the security patches. But you don't need to take every bug fix blindly.
Post reply on HN