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

781–790 of 797 posts

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

#781

Post by rlpb »

sublinear wrote: post #377
rlpb wrote: post #320

Earlier quoted context omitted.

You need to explain how one is supposed to distinguish and exclude "namespaces pretty much nobody uses" when writing code in this ecosystem. My understanding is that a typical Node developer pretty much has no control over what gets pulled in if they want to get anything done at all. If that's the case, then you don't have an argument. If a developer genuinely has no control, then the point is moot.

How is this situation any different from any other ecosystem? I think you don't have an argument here other than that npm is a relatively large public repository. Bad actors and ignorant developers are everywhere else too. There are plenty of npm features to help assess packages and prevent unintended updates, but nothing replaces due diligence.

Debian does not excuse security compromises by saying "oh nobody uses that far corner of our repository anyway".

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

#782

Post by nycalexander »

Made a package (that I needed personally), to easily reinstall all dependencies (using the same versions) in a project and check them using Aikido's safe chain for malware (supported npm, pnpm, bun, and yarn). It also easily switches a project's package manager to another. https://www.npmjs.com/package/eazypm

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

#783

Post by mbreese »

YetAnotherNick wrote: post #780
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.

You can't "require" manual intervention. Sure you can say that the keys stays on say 2 developers laptops, but personal devices have even more surface area for key leak than CI/CD pipeline. It wouldn't have prevented attacks like this issue in any case where the binary just searched for keys across the system. One alternative is to do the signing on airlocked system stored in physically safe but accessible location,…

As someone else mentioned, the easiest way would be to have some kind of MFA in the loop. It’s not perfect, but better than what we have now.

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

#784

Post by alextingle »

iknowstuff wrote: post #587
alextingle wrote: post #275

Earlier quoted context omitted.

Every time I look at a new project, my face falls when it's written in Rust. I simply don't trust a system that pulls in gigabytes of god-knows-what off the cloud, and compiles it on my box. It's a real barrier to entry, for me. When I download a C project, I know that it only depends on my system libraries - which I trust because I trust my distro. Rust seems to expect me to take a leap in the dark, trusting hundred…

You don't know that about a C project. And you still don't know what lurks in its 1000th reimplementation of http header parsing.

Well, yes I do know when a C project only depends on my system libraries, because otherwise it won't compile. That's the point.

Furthermore, for the purposes of this discussion, it really doesn't matter what code there is in the C project. What's there has been put there by the people who run the project. If they are malicious, then at least I know who they are. With Rust, I'm downloading and compiling code from many, many third parties. I have no idea who they are. The potential for one of them to be malicious is much, much higher.

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

#785

Post by [deleted] »

gred wrote: post #74
Gigachad wrote: post #13

Earlier quoted context omitted.

The problem isn't specific to node. NPM is just the most popular repo so the most value for attacks. The same thing could happen on RubyGems, Cargo, or any of the other package managers.

NPM has about 4 million packages, Maven Central has about 3 million packages. If this were true, wouldn't there have been at least one Maven attack by now, considering the number of NPM attacks that we've seen?

[deleted]

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

#786

Post by jcgl »

TheDong wrote: post #711
robot-wrangler wrote: post #370

Earlier quoted context omitted.

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, logr…

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

I honestly don't know how common it is to use zap, logrus and co on new projects anymore. I know I always go for slog.

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

This isn't a practical problem at all. First of all, the stdlib shouldn't make backwards-incompatible changes just for the sake of logging. Second, slog.NewLogLogger()[0] exists as a way to get log.Loggers to be used with things that rely on the old log.Logger.

[0] https://pkg.go.dev/log/slog#NewLogLogger

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

#787

Post by jcgl »

iknowstuff wrote: post #492
poly2it wrote: post #383

Earlier quoted context omitted.

Go is also famous for encouraging a culture of keeping down dependency count while exposing a simple to use package manager and ecosystem.

https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... this article made the rounds here after the author pulled the thread on dependencies in Go

That's pulling on a dependency. An ugly case, but a very specific one relating to a tricky backwards-incompatible change that the Go team fudged on back in the pre-module times.

That story doesn't generally speak to the reality that most Go packages have rather small dependency graphs.

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

#788

Post by cluckindan »

benoau wrote: post #537
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…

Or just 'npm ci' so you install exactly what's in your package-lock.json instead of the latest version bumps of those packages. This "automatic updating" is a big factor in why these attacks are working in the first place. Make package updating deliberate instead of instant or on an arbitrary lag.

”npm install” does not auto-upgrade packages, it installs them according to the lockfile.

It didn’t always work like that, but it has worked like that for many years.

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

#789

Post by cluckindan »

dachris wrote: post #726
benoau wrote: post #537

Earlier quoted context omitted.

Or just 'npm ci' so you install exactly what's in your package-lock.json instead of the latest version bumps of those packages. This "automatic updating" is a big factor in why these attacks are working in the first place. Make package updating deliberate instead of instant or on an arbitrary lag.

You'd be surprised how many people run 'npm i' in their CI. I've seen this on multiple occasions. 'npm ci' is some mitigation, but doesn't protect against getting hit when running 'npm i(nstall)' during development.

Update your knowledge. ”npm install” hasn’t done auto-upgrades for years now.

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

#790

Post by loumf »

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…

When you do regular updates, they are quick. But also, you can timebox it and then back out and plan a harder than expected update.

Also, it keeps you in touch with your deps so you can consider if it’s even worth it. My favorite update was removing the dep (or starting a plan to remove it because it was interfering with regular updates)

Post reply on HN