Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

681–690 of 797 posts

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

#681

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…

For Python ecosystem people:

> Does not default to running post-install scripts (must manually approve each)

To get equivalent protection, use `--only-binary=:all:` when running `pip install` (or `uv pip install`). This prevents installing source distributions entirely, using exclusively pre-built wheels. (Note that this may limit version ability or even make your installation impossible.) Python source packages are built by following instructions provided with the package (specifying a build system which may then in turn be configured in an idiosyncratic way; the default Setuptools is configured using a Python script). As such, they effectively run a post-install script.

(For PAPER, long-term I intend to design a radically different UI, where you can choose a named "source" for each package or use the default; and sources are described in config files that explain the entire strategy for whether to use source packages, which indexes to check etc.)

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

Pip does not support this; with uv, use `--exclude-newer`. This appears to require a timestamp; so if you always want things up to X days old you'll have to recalculate.

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

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

Because it is not a serious ecosystem run by serious people. Do you know what serious people do? They have package repositories with people called "maintainers", who are, crucially, trusted members of a community who don't write the software they package. "Oh but that's GATEKEEPING!", they screech. Yes, that's the entire point. Gatekeeping prevents shit like this from happening. There's a reason why this doesn't happ…

Agreed that some level of gatekeeping and some level of friction to protect quality are useful things.

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

#683
post #474

Earlier quoted context omitted.

Or maybe just get comfortable with adding versions and deprecation. eg optparse to argparse (though tbf, I would have just preferred it was optparse2). Or maybe the problem is excessive stability commitments. I think I prefer languages that realize things can improve and are willing to say if you want to run 10 year old code, use a 10 year old compiler/runtime.

I think I prefer languages that realize things can improve and are willing to say if you want to run 10 year old code, use a 10 year old compiler/runtime. IMHO, the trouble with that stance is that it leaves no path to incrementally update a long-lived system to benefit from any of those improvements. Suppose we have an application that runs on 2025’s most popular platform and in ten years we’re porting it to whateve…

> leaves no path to incrementally update

Sure it does? Or do I not understand? It pushes the work to the application, not the language.

And it works fine on rails. If you want to stay on an EOL rails, you're on your own, or you can buy ongoing security backports from at least 2 (that I know of, maybe more) vendors. LTS lives roughly 2 years and then you either upgrade or deal with eol yourself.

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

#684

Earlier quoted context omitted.

Npm is what happens when you let tech debt stack up for years too far. It took them five attempts to get lock files to actually behave the way lock files are supposed to behave (lockfile version 3, + at least 2 unversioned attempts before that). It’s clear from the structure and commit history they’ve been working their asses off to make it better, but when you’re standing at the bottom of a well of suck it takes tha…

but this stuff is basically solved. We have enough history with languages and distribution of packages, repositories, linux, public trust, signing, maintainers, etc. One key shift is there is no packager anymore. Its just - trust the publisher. Any language as big as Node should hire a handful of old unix wizards to teach them the way the truth and the life.

Likely they wouldn’t listen. Modern languages and environments seem intent on reinventing bad solutions to solved problems. I get it if it’s a bunch of kids that have never seen anything better but there is no excuse these days not to have at least a passing knowledge of older systems if you’ve been around a while.

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

#685

Earlier quoted context omitted.

Npm is what happens when you let tech debt stack up for years too far. It took them five attempts to get lock files to actually behave the way lock files are supposed to behave (lockfile version 3, + at least 2 unversioned attempts before that). It’s clear from the structure and commit history they’ve been working their asses off to make it better, but when you’re standing at the bottom of a well of suck it takes tha…

but this stuff is basically solved. We have enough history with languages and distribution of packages, repositories, linux, public trust, signing, maintainers, etc. One key shift is there is no packager anymore. Its just - trust the publisher. Any language as big as Node should hire a handful of old unix wizards to teach them the way the truth and the life.

> One key shift is there is no packager anymore. Its just - trust the publisher.

Repositories like NPM's, and PyPI, contain many more packages than any Linux distro. And the Linux Foundation actually gets funded.

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

#686

Earlier quoted context omitted.

but this stuff is basically solved. We have enough history with languages and distribution of packages, repositories, linux, public trust, signing, maintainers, etc. One key shift is there is no packager anymore. Its just - trust the publisher. Any language as big as Node should hire a handful of old unix wizards to teach them the way the truth and the life.

Likely they wouldn’t listen. Modern languages and environments seem intent on reinventing bad solutions to solved problems. I get it if it’s a bunch of kids that have never seen anything better but there is no excuse these days not to have at least a passing knowledge of older systems if you’ve been around a while.

there's certainly a piece of it. Also most seasoned people are not very interested in new languages and environments, and most languages are not 'spec built' by experts like Rob Pike building Go who explicitly set out to solve a lot of his problems, but are more naturally grown and born.

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

#687

Earlier quoted context omitted.

You don't need post-install scripts for this. Use optionalDependencies instead https://github.com/nrwl/nx/blob/master/packages/nx/package.j... Each of those deps contains a constraint installing only for the relevant platform.

That’s cool, now I wish all libraries that need binaries would opt to use that instead of post script

Do keep in mind that the binaries are still binaries. Even if your installation process doesn't run any untrusted code from the package, you can't audit the binaries like you might the .js files prior to first run.

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

#688
post #543

Earlier quoted context omitted.

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

If people stop running install scripts, isn't Shai-Hulud 3: Electric Boogaloo just going to be designed to run its obfuscated malware at runtime rather than install time? Who manually reviews new versions of their project dependencies after installing them but before running them? GP is correct. This is a workflow issue. Without a review process for dependencies, literally every package manager I know of is vulnerabl…

> If people stop running install scripts, isn't Shai-Hulud 3: Electric Boogaloo just going to be designed to run its obfuscated malware at runtime rather than install time?

Many such forms of malware have already been published and detected.

> Who manually reviews new versions of their project dependencies after installing them but before running them?

One person putting in this effort can protect everyone thereafter.

The PyPI website has a "Report project as malware" button on each project page for this purpose.

But yes, this is the world we live in. Without this particular form of insecurity, there is no "ecosystem" at all.

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

#689
post #55

Earlier quoted context omitted.

I don't buy this line of reasoning. There are zero/one day vulnerabilities that will get extra time to spread. Also, if everyone switches to the same cooldown, wouldn't this just postpone the discovery of future Shai-Huluds? I guess the latter point depends on how are Shai-Huluds detected. If they are discovered by downstreams of libraries, or worse users, then it will do nothing.

Your line of reasoning only makes sense if literally almost all developers in the world adopt cooldowns, and adopt the same cooldown. That would be a level of mass participation yet unseen by mankind (in anything, much less something as subjective as software development). I think we're fine.

I don't think so. What fraction of developers would even notice the malware? Some malware seems to barely be noticed.
Post reply on HN