Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

161–170 of 797 posts

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

#161
Is there a terminal AI assistant that doesn't have heaps of depenedancies and preferably no node? Claude and codex both require node. I'm a fan of the lightweight octofriend. But also node. I do not like installing node on systems that otherwise would not require it.

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

#163
post #7

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 "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…

An open question is why PyPI doesn’t have the same problem.

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

#164

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…

Ah yes PHP, the language known for its strong security...

Modern PHP is leagues above Javascript

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

#165
post #158
post #133

Earlier quoted context omitted.

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.

I agree, but imo the Rust ecosystem has the same problem. Not to the extent of NPM, but worse than C/C++.

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

#166

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

Pretty easy to do using npm-check-update:

https://www.npmjs.com/package/npm-check-updates#cooldown

In one command:

  npx npm-check-updates -c 7

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

#167

Earlier quoted context omitted.

Not knowing that much about apt, isn't _any_ package system vulnerable, and purely a question of what guards are in place and what rights are software given upon install?

It's not the packaging tech. Apt will typically mean a Debian-based distro. That means the packages are chosen by the maintainers and updated only during specific time periods and tested before release. Even if the underlying software gets owned and replaced, the distro package is very unlikely to be affected. (Unless someone spent months building trust, like xz) But the basic takeover... no, it usually won't affect…

Given the years (or decades) it takes updates to happen in Debian stable, it’s immune to supply chain attacks. You do get to enjoy vulnerabilities that have been out for years, though.

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

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

An open question is why PyPI doesn’t have the same problem.

PyPI is also subject to supply chain attacks. What do you mean?

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

#169

Earlier quoted context omitted.

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.

> If we're talking about Node.js, there's a long list of dependencies by default.

But that's not true? I initialize a project locally, there is zero dependencies by default, and like I did five years ago, I can still build backend/frontend projects with minimal set of dependencies.

What changed is what people are willing/OK with doing. Yes, it'll require more effort, obviously, but if you want things to be built properly, it usually takes more effort.

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

#170
post #41

Earlier quoted context omitted.

The packages were published using a compromised key directly, not through our ci/cd. We rolled the key, and published a new clean version from our repo through our CI/CD: https://github.com/PostHog/posthog-js/actions/runs/196303581...

Why do you keep using token auth? This is unacceptable negligence these days. NPM supports GitHub workflow OIDC and you can make that required, disabling all token access.

[dead]
Post reply on HN