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

711–720 of 797 posts

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

#711

Post by TheDong »

robot-wrangler wrote: post #370
WD-42 wrote: 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?

It seems like the normal and rational choice to not include logging to me.

Java included 'java.util.logging'. No one uses it because it's bad, everyone just uses slf4j as the generic facade instead, and then some underlying implementation.

Golang included the "log" package, which was also a disaster. No one used it so they introduced log/slog recently, and still no one uses that one, everyone is still using zap, logrus, etc.

Golang is also a disaster in that the stdlib has "log/slog" as the approved logging method, but i.e. the 'http.Server.ErrorLog' is the old 'log.Logger' you're not supposed to use, and for backwards compatibility reasons it's stuck that way. The go stdlib is full of awkward warts because it maintains backwards compatibility, and also included a ton of extra knobs that they got wrong.

The argument of structured vs unstructured logging, arguments around log levels (glog style numeric levels, trace/debug/info/warn/error/critical or some subset, etc), how to handle lazy logging or lazy computations in logging, etc etc, it's all enough that the stdlib can't easily make a choice that will make everyone happy.

Rust as a language has provided enough that the community can make a sl4j like facade (conveniently, the clearly named 'log' crate seems to be the winner there), so there's no reason it has to be in the stdlib.

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

#712

Post by twistedpair »

dschofie wrote: post #646
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…

Reading through the post it looks like this infects via preinstall? > The new versions of these packages published to the NPM registry falsely purported to introduce the Bun runtime, adding the script preinstall: node setup_bun.js along with an obfuscated bun_environment.js file.

You're right. PNPM disables all install scripts by default. I was just noting one example.

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

#713

Post by calvinmorrison »

zahlman wrote: post #685
calvinmorrison wrote: post #675

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.

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

NPM isn't a package repository it's more akin a code repository.

There's a reason why most distributions dont ship upstream (except basically Arch)

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

#714

Post by salomonk_mur »

benjifri wrote: post #635
latchkey wrote: post #488

Earlier quoted context omitted.

ProTip: `use bun` Funny that this is getting downvoted, but it installs dependencies super fast, and has the same approval feature as pnmp, all in a simple binary.

This is like saying "use MacOS and you won't get viruses" in the 2000s

Which was for the most part true.

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

#715

Post by zahlman »

acdha wrote: post #710
zahlman wrote: post #681

Earlier quoted context omitted.

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…

> 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. I do this by having my shell init do this: export UV_EXCLUDE_NEWER=$(date -Iu -d "14 days ago") That’s easy to override if you need to but otherwise seamless.

FWIW, I'd like if these tools had an option to prefer the oldest version satisfying the given constraints (rather than the newest, as it is now — probably still a better default).

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

#716

Post by mbreese »

woodruffw wrote: post #695
mbreese wrote: post #678

Earlier quoted context omitted.

Or require manual intervention to publish a new package. I'm not sure why we need to have a fully automated pipeline here to go from CI/CD to public package release. It seems like having some kind of manual user interaction to push a new version of a library would be a good thing.

The basic issue with manual interaction is a question of authority: a pretty common problem for companies (and open source groups) is when $EARLY_EMPLOYEE/$EARLY_CONTRIBUTOR creates and owns the entire publishing process for a key package, and then leaves without performing a proper transfer of responsibility. This essentially locks the company/group out of its own work, and increases support load on community mainta…

I don’t buy this. I mean, I’m sympathetic to the issue. It’s easy for things to get jumbled when companies are young. But we’re talking about libraries that are used by your customers. To many, this is the externally visible interface to the company.

What you describe sounds like a process problem to me. If an $EARLY_EMPLOYEE if the only one with the deploy keys for what is a product of the company, then that’s a problem. If a deployment of that key library can be made without anyone approving it, that’s also a problem. But those are both people problems… and you can’t solve a people problem with a technical solution.

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

#718

Post by woodruffw »

mbreese wrote: post #716
woodruffw wrote: post #695

Earlier quoted context omitted.

The basic issue with manual interaction is a question of authority: a pretty common problem for companies (and open source groups) is when $EARLY_EMPLOYEE/$EARLY_CONTRIBUTOR creates and owns the entire publishing process for a key package, and then leaves without performing a proper transfer of responsibility. This essentially locks the company/group out of its own work, and increases support load on community mainta…

I don’t buy this. I mean, I’m sympathetic to the issue. It’s easy for things to get jumbled when companies are young. But we’re talking about libraries that are used by your customers. To many, this is the externally visible interface to the company. What you describe sounds like a process problem to me. If an $EARLY_EMPLOYEE if the only one with the deploy keys for what is a product of the company, then that’s a pro…

> But those are both people problems… and you can’t solve a people problem with a technical solution.

I don’t think it is a people problem in this case: the only reason there’s a person involved at all is because we’ve decided to introduce one as an intermediating party. A more misuse-resistant scheme disintermediates the human, because the human was never actually a mandatory part of the scheme.

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

#719

Post by hexasquid »

benjifri wrote: post #635
latchkey wrote: post #488

Earlier quoted context omitted.

ProTip: `use bun` Funny that this is getting downvoted, but it installs dependencies super fast, and has the same approval feature as pnmp, all in a simple binary.

This is like saying "use MacOS and you won't get viruses" in the 2000s

"Rewrite it in rust"

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

#720

Post by developerjhp »

I’ve been tracking these supply-chain incidents as well, so I built a small real-time scanner that looks for suspicious SHA-1 patterns inside repositories.

It’s basically a lightweight CLI tool you can run directly inside any local project:

    npx sha1-hulud-scanner
Repo is here: https://github.com/developerjhp/sha1-hulud-scanner

It’s not meant to be a full security product — just a simple “first-pass” detector that helps catch unexpected checksum strings or injected artifacts before they slip into CI. Feedback and contributions are welcome!

Post reply on HN