Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

441–450 of 797 posts

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

#441
post #402

Earlier quoted context omitted.

Also add it to ~/.npmrc!

So, I do this because it's universally recommended, but why does it help? Can't they just jam the malware into the package itself? It runs with the same permissions on my machine (in unit tests, node servers, etc).

Yes, if the malware is injected in the application code this doesn’t prevent it.

But in some cases it could help for that. For instance, if the package runs in the browser and the payload requires file-system access, etc., then the attack can’t execute in the browser. And if in addition it was added to a life-cycle script, it would be mitigated.

At any rate, it’s worth having `ignore-scripts=true` because NPM life-cycle scripts are a common target (e.g., this one targets `preinstall`).

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

#442

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

But even then you are still depending on others to catch the bugs for you and it doesn't scale: if everybody did the cooldown thing you'd be right back where you started.

To find a vulnerability, one does not necessarily deploy a vulnerable version to prod. It would be wise to run a separate CI job that tries to upgrade to the latest versions of everything, run tests, watch network traffic, and otherwise look for suspicions activity. This can be done relatively economically, and the responsibility could be reasonably distributed across the community of users.

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

#443

I never, ever, do development outside of a podman container these days. Basically if I am going to run some code from somewhere and I haven't read it, it goes in a container. I know its not foolproof, but I can't believe how often people run code they haven't read where it can make a huge mess, steal secrets, etc. I'll probably get owned someday, I'm sure, but this feels like a bare minimum.

I ssh into a second local user and do development there instead with tmux.

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

#444

I never, ever, do development outside of a podman container these days. Basically if I am going to run some code from somewhere and I haven't read it, it goes in a container. I know its not foolproof, but I can't believe how often people run code they haven't read where it can make a huge mess, steal secrets, etc. I'll probably get owned someday, I'm sure, but this feels like a bare minimum.

> if I am going to run some code from somewhere and I haven't read it, it goes in a container

How does this work? Every single npm package has tons of dependency tree nodes

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

#445
post #369

Earlier quoted context omitted.

The trusted publishing is rather new or? Awesome to see that they implemented it. Just saying that maven central required it already years ago.

Maven Central does not currently support OIDC-based authentication (commonly called "Trusted Publishing").

Didn’t know this term. After reading I wonder why short lived tokens get this monocle. But yeah I prefer OIDC over token based access as well. Only small downside I see is the setup needed for a custom OIDC provider. Don’t know the right terms out of my head but we had quite the fun to register our internal Jenkins to become a create valid oidc tokens for AWS. GitHub and GitHub Actions come with batteries included. I mean the downside that a huge vendor can easily provide this and a custom rolled CI needs extra steps / infrastructure.

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

#446
post #349

Earlier quoted context omitted.

Rand, uuid, and no built in logging implementation are three examples that require crates but probably shouldn’t.

No built in logging seems pretty crazy. Is there a story behind that?

Rust's standard library hasn't received any major additions since 1.0 in 2015, back when nobody was writing web services in Rust so no one needed logging.

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

#447
post #337

Earlier quoted context omitted.

Pnpm (a very popular npm replacement) makes completely locked packages easy and natural and ultra fast: https://pnpm.io/cli/install Benchmarks: https://pnpm.io/benchmarks

pnpm is so laughably terrible compared to Cargo it's not even comparable in the same breath.

Why specifically? Your comment isn't very informative.

Anyhow, here a Claude.ai comparison: https://claude.ai/share/72d2c34c-2c86-44c4-99ec-2a638f10e3f0

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

#449
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…

Node is the new PHP: massive ecosystem, enormous mind share, and made up for a large part by programming newbies for whom JS is their first language and have no serious understanding of engineering practices, security and quite eager to use a library rather than wasting hours figuring out how to pad a string.

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

#450
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…

[flagged]
Post reply on HN