Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

151–160 of 797 posts

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

#151

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…

If I had to bet, the most likely and pragmatic solution will be to have dependencies cooldown and that's it

If everyone does it, then it becomes less effective, because there'd be fewer early testers to experience and report issues, no?

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

#152

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…

It's not just npm, you should also not trust pypi, rubygems, cargo and all the other programming language package managers. They are built for programmers, not users. They are designed to allow any random untrusted person to push packages with no oversight whatsoever. You just make an account and push stuff. I have no doubt you can even buy accounts if you're malicious enough. Users are much better served by the Linu…

There are far too many languages and many packages for each of them for this (good) idea to be practicable.

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

#153

Earlier quoted context omitted.

I can guarantee that any financial institution which has standard auditing requirements and is using Node.js has fully audited all of the dependencies they use. Outside that, the issue is not unique to Node.js.

Sorry, but that had me laughing out loud. No, they haven't. I should know, I check those companies for a living. This is one of the most often flagged issues: unaudited Node.js dependencies. "Oh but we don't have the manpower to do that, think about how much code that is".

When I last looked (as a consulting dev in a bank or three, horrified) absolutely they had not!

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

#154

Earlier quoted context omitted.

Okay then, tell me a way to prevent this.

The same way it always has been done - vendor your deps.

That literally makes no difference at all. You’ll just vendor the malicious versions. No, a lock file with only exact versions is the safe path here. We haven’t seen a compromise to existing versions that I know of, only patch/minor updates with new malicious code.

I maintain that the flexibility in npm package versions is the main issue here.

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

#155
post #7

Earlier quoted context omitted.

It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…

I hate to be the guy saying AI will solve it, but this is a case where AI can help. I think in the next couple of years we’ll see people writing small functions with Claude/codex/whatever instead of pulling in a dependency. We might or might not like the quality of software we see, but it will be more resistant to supply chain attacks.

An approach I learnt from a talk posted to HN (I forget the talk, not the lesson) is to not depend on the outside project for its code, just lift that code directly in to your project, but to rely on it for the tests, requiring/importing it etc when running your own tests. That protects you from a lot of things (this kind of attack was not mentioned, afaic recall) but doesn’t allow bugs found by the other project to be missed either.

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

#156
post #24

I guess you should never use the latest versions of libraries.

Everyone needs to switch to pnpm and enable https://pnpm.io/settings#minimumreleaseage Pnpm also blocks preinstall scripts by default.

Nah - dependency cooldown is all the rage but it’s only effective if you have some noncompliant canary users. Once everyone is using it it will cease to be effective because nobody will be taking the first step/risk until everybody does.

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

#157
post #7

Earlier quoted context omitted.

It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…

I hate to be the guy saying AI will solve it, but this is a case where AI can help. I think in the next couple of years we’ll see people writing small functions with Claude/codex/whatever instead of pulling in a dependency. We might or might not like the quality of software we see, but it will be more resistant to supply chain attacks.

How is this going to solve the supply chain attack problem at all though? It just obfuscates things even more, because once an LLM gets "infected" with malicious code, it'll become much more difficult to trace where it came from.

If anything, blind reliance on LLMs will make this problem much worse.

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

#158
post #133

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

There's nothing technically different between NPM and, say, Cargo, here that would save Cargo, is there?

This is a cultural problem created through a fundamental misunderstanding (and mis-application) of Unix philosophy. As far as I'm aware the Rust ecosystem doesn't have a problem appropriately sizing packages which in turn reduces the overall attack surface of dependencies.

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

#159
post #113

Earlier quoted context omitted.

Just a last month someone was trying to figure the cargo tree on which Rust package got imported implicitly via which package. This will totally happen in rust as well as long as you use some kind of package manager. Go for zero or less decencies.

less?

Roll your own standard library - or go without one entirely

`#![no_std]`

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

#160

Earlier quoted context omitted.

We chose to write our platform for product security analytics (1) with PHP, primarily because it still allows us to create a platform without bringing in over 100 dependencies just to render one page. I know this is a controversial approach, but it still works well in our case. "require": { "php": ">=8.0", "ext-mbstring": "*", "bcosca/fatfree-core": "3.9.1", "phpmailer/phpmailer": "6.9.3", "ruler/ruler": "0.4.0", "ma…

Not sure what the language has anything to do with it, we've built JavaScript applications within pulling in 100s of NPM packages before NPM was a thing, people and organizations can still do so today, without having to switch language, if they don't want to. Does it require disciple and a project not run by developers who just learned program? You betcha.

I might say that every interpreter has a different minimum dependency level just to create a simple application. If we're talking about Node.js, there's a long list of dependencies by default.

So yes, in comparison, modern vanilla PHP with some level of developer discipline (as you mentioned) is actually quite suitable, but unfortunately not popular, for low-dependency development of web applications.

Post reply on HN