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

741–750 of 797 posts

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

#741

Post by gr4vityWall »

Chris_Newton wrote: post #365
TheFlyingFish wrote: post #316

Earlier quoted context omitted.

Requests is a great example of my point, actually. Creating a brand-new Python venv and running `uv add requests` tells me that a total of 5 packages were added. By contrast, creating a new Rust project and running `cargo add reqwest` (which is morally equivalent to Python's `requests`) results in adding 160 packages, literally 30x as many. I don't think languages should try to include _everything_ in their stdlib, a…

IMHO, the ideal for package management in a programming language ecosystem might recognise multiple levels of “standardisation”. At the top, you have the true standard library for the language. This has very strong stability guarantees. Its purpose is twofold: to provide universal implementations of essentials and to define standard/baseline interfaces for common needs like abstract data types, relational databases,…

I agree with your general idea. I'd add it also looks very similar to what typical GNU/Linux have in practice: blessed packages from the distros' repositories, and third-party repos for those who want them.

Debian also has something 'in the middle' with additional repositories that aren't part of the main distribution and/or contain proprietary software.

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

#742

Post by Yasuraka »

eptcyka wrote: post #111
sph wrote: 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…

Go is just as bad.

Nope. Know the difference.

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

#743

Post by lrvick »

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…

Pnpm cannot be built without an existing pnpm binary meaning there is no way to bootstrap it from audited source code. Perfect trusting trust attack situation.

Full source bootstrapped NPM with manually reviewed dependencies is the only reasonably secure way to use NodeJS right now.

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

#744

Post by Vinnl »

btown wrote: post #669
skybrian wrote: post #356

Earlier quoted context omitted.

The arguments for doing frequent releases partially apply to upgrading dependencies. Upgrading gets harder the longer you put it off. It’s better to do it on a regular schedule, so there are fewer changes at once and it preserves knowledge about how to do it. A cooldown is a good idea, though.

There's another variable, though, which is how valuable "engineering time now" is vs. "engineering time later." Certainly, having a regular/automated update schedule may take less clock time in total (due to preserved knowledge etc.), and incur less long-term risk, than deferring updates until a giant, risky multi-version multi-dependency bump months or years down the road. But if you have limited engineering resourc…

At the same time, unplanned engineering time is almost always more expensive than planned engineering time. I'd rather have some regular, expected, upgrade work, than all of a sudden having to scramble because I need something at a moment when I didn't plan for that.

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

#745

Post by kibwen »

sapiogram wrote: post #446
robot-wrangler wrote: post #370

Earlier quoted context omitted.

No built in logging seems pretty crazy. Is there a story behind that?

Rust's standard library hasn't received any major additions since 1.0 in 2015, back when nobody was writing web services in Rust so no one needed logging.

This is patently false. The majority of the "features" that get added to Rust in every release are additions to the standard library.

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

#746

Post by kpcyrd »

sph wrote: post #7
vintagedave wrote: post #2

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…

Out of the 789 npm packages in this incident, only 4 were ever used in any dependency tree of any Linux operating system (including Homebrew). Not in the affected versions, but ever.

If your Rust software observes a big enough chunk of the computer fever dream you are likely to end up with 2-3 digit amount of Rust dependencies, but they are probably all going to be high profile ones (tokio, anyhow, reqwest, the hyper crates, ...), instead of niche ones that never make it into any operating system.

This is not a silver bullet of course, but there seems to be an inverse correlation between "is part of any operating system dependency tree" and "gets compromised in an npm-like incident".

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

#747

Post by port11 »

eyberg wrote: post #671
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.

The same podman that had three new CVE breakouts not even two weeks ago? Containers do not contain.

Security is oft done in layers. Podman is just another layer that might fail. There's no such thing as the perfect solution.

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

#748

Post by junon »

woodruffw wrote: post #273
junon wrote: post #192

Earlier quoted context omitted.

OIDC is not a silver bullet either and has its own set of vectors to consider too. If it works for your org model then great, but it doesn't solve every common scenario.

Trusted Publishing addresses the vector here, which is arbitrary persistence and delayed use of credentials by attackers. You're right that it's not a silver bullet (anything claiming to be one is almost certainly a financially induced lie), but it eliminates/foreshortens the attack staging window significantly.

It's not a silver bullet in that it can open up other vectors of much more probable attack.

If I have a FOSS project where there are other contributors with write access but not publish access (very common) OIDC now allows them to publish via workflows, opening you up to Jia Tan type attacks.

Like I said, if it works for your org, great. Otherwise it can cause bigger problems.

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

#749

Post by 0manrho »

vintagedave wrote: post #2

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…

Npm has been a shit show from day 1. Unfortunately, Industry momentum and vc funded "fail fast, fail often" is a hell of a drug.

EDIT: Coffee hasnt kicked in yet, that was harsher than I intended. For what it's worth, it's not specifically/solely NPM/nodes fault, more of a convergance of the above and the ecosystem/users just as much as any of the Node/NPM devs/maintainers in combination with it having such a large attack cross section. Even if it had a reputation for being bulletproof and secure as fuck there's still such a large userbase with huge potential if exploited that'd it'd almost assuredly inevitably be compromised from time to time regardless.

While I feel we could use a whole lot less javascript on the web (client and server side both), without a competitor or something, it's shear size ensures any such expliot/issue gets amplified 1000x versus nearly any other project save for maybe major OS's and Browsers themselves.

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

#750

Post by woodruffw »

mbreese wrote: post #738
woodruffw wrote: post #718

Earlier quoted context omitted.

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

What person do you want to remove from the process?

The person who intermediates the trust relationship between the index and the source repository. There’s no reason for the credential that links those two parties to be intermediated by a human; they’re two machine services talking.

(You obviously can’t disintermediate the human from maintenance or development!)

Post reply on HN