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

541–550 of 797 posts

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

#541

Post by embedding-shape »

jama211 wrote: post #530
embedding-shape wrote: post #513

Earlier quoted context omitted.

> NPM is too insecure for production CLI usage. NPM was never "too insecure" and remains not "too insecure" today. This is not an issue with npm, JavaScript, NodeJS, the NodeJS foundation or anything else but the consumer of these libraries pulling in code from 3rd parties and pushing it to production environments without a single review. How this still fly today, and have been since the inception of public "easy to…

“Personally, I never wear a seatbelt because all drivers on the road should just follow the road rules instead and drive carefully.” I don’t control all the drivers on the road, and a company can’t magically turn all employees into perfect developers. Get off your high horse and accept practical solutions.

> and a company can’t magically turn all employees into perfect developers

Sure, agree, that's why professionals have processes and workflows, everyone working together to build the greatest stuff you can.

But when not a single person in the entire company reviews the code that gets deployed and run by users, you have to start asking what kind of culture the company has, it's borderline irresponsible I'd say.

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

#542

Post by Aeolun »

roozbeh18 wrote: post #484
Lutger wrote: post #457

Earlier quoted context omitted.

Everything runs in the container and cannot escape it. Its like a sandbox. You have to make sure you're not putting any secrets in the container environment.

You are just reducing the blast radius with use of podman; you will likely need secrets for your app to work, which will be exposed regardless of the podman approach.

Most people don’t have NPM keys in their application containers.

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

#543

Post by jkrems »

embedding-shape wrote: post #513
twistedpair wrote: post #469

ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…

> NPM is too insecure for production CLI usage. NPM was never "too insecure" and remains not "too insecure" today. This is not an issue with npm, JavaScript, NodeJS, the NodeJS foundation or anything else but the consumer of these libraries pulling in code from 3rd parties and pushing it to production environments without a single review. How this still fly today, and have been since the inception of public "easy to…

They didn't deploy the code. That's not how this exploit works. They _downloaded_ the code to their machine. And npm's behavior is to implicitly run arbitrary code as part of the download - including, in this case, a script to harvest credentials and propagate the worm. That part has everything to do with npm behavior and nothing to do with how much anybody reviewed 3P deps. For all we know they downloaded the new version of the affected package to review it!

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

#544

Post by Operyl »

tripplyons wrote: post #503
twistedpair wrote: post #469

ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…

Is there a way to set a minimum release age globally for my pnpm installation? I was only able to find a way to set it for each individual project.

Did you try putting it in your global config file?

Windows: ~/AppData/Local/pnpm/config/rc

macOS: ~/Library/Preferences/pnpm/rc

Linux: ~/.config/pnpm/rc

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

#545

Post by 0cf8612b2e1e »

Ygg2 wrote: post #246
galangalalgol wrote: post #227

Earlier quoted context omitted.

Network without async works fine in std. However, rand, serde, and num_traits always seem to be present. Not sure why clap isn't std at this point.

> why clap isn't std at this point. Too big for many cases, there is also a lot of discussion around whether to use clap, or something smaller.

Clap is enormous and seems way too clever for everything I do. Last I looked it added 10+ seconds to compile time and hundreds of kbs to binary size. Maybe something like ffmpeg requires that complexity, but if I am writing a CLI that takes three arguments, it is a heavy cost.

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

#546

Post by pengaru »

postexitus wrote: post #540
nathan_compton wrote: post #426

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.

Would it have prevented this attack? It would still have published the secrets from your container to github.

the whole point of doing such things in ephemeral containers is to not have your secrets accessible from said container

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

#547

Post by jkrems »

jhatemyjob wrote: post #520

And this, kids, is why you should vendor your dependencies

Vendoring wouldn't really affect this at all. If anything it would keep you vulnerable for longer because your vendored copy keeps "working" after the bad package got removed upstream. There's a tiny chance that somebody would've caught the 10MB file added in review but that's already too late - the exploit happened on download, before the vendored copy got sent for review.

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

#548

Post by bpavuk »

embedding-shape wrote: post #513
twistedpair wrote: post #469

ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…

> NPM is too insecure for production CLI usage. NPM was never "too insecure" and remains not "too insecure" today. This is not an issue with npm, JavaScript, NodeJS, the NodeJS foundation or anything else but the consumer of these libraries pulling in code from 3rd parties and pushing it to production environments without a single review. How this still fly today, and have been since the inception of public "easy to…

wait, I short-circuited here. wasn't the very concept of "libraries" created to *not* have to think about what exactly the code does?

imagine reviewing every React update. yes, some do that (Obsidian claims to review every dependency, whether new or an update), but that's due to flaws of the ecosystem.

take a look at Maven Central. it's harder to get into, but that's the price of security. you have to verify the namespace so that no one will publish under e.g. `io.gitlab.bpavuk.` namespace unless they have access to the `bpavuk` GitLab group or user, or `org.jetbrains.` unless they prove the ownership of the jetbrains.com domain.

Go is also nice in that regard - you are depending on Git repositories directly, so you have to hijack into the Git repo permissions and spoil the source code there.

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

#549

Post by jkrems »

JadoJodo wrote: post #470

Would the adoption of a Deno-like security posture in NPM have mitigated this?

pnpm is the better comparison maybe in this context. Most of Deno's approach to security is focussed on whole program policies which doesn't do much in this context. Just like pnpm and others, they do have opt-in for install scripts though. The npm CLI is an outlier there by now.

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

#550

Post by parliament32 »

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 if you're too far behind, when you "need" takes days instead of hours.
Post reply on HN