Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

431–440 of 796 posts

Re: NPM debug and chalk packages compromised

#431
post #415
post #349

Earlier quoted context omitted.

Being able to sign releases would help, too. I would happily have that enabled since I'm always publishing from one place.

Wouldn't they have been able to change your key if they had compromised your entire npm account? Also, junon.support++ – big thanks for being clear about all this.

Yes though in theory my public key would have been published elsewhere at least for verification. Valid point though, yes they would have been able to do that.

Re: NPM debug and chalk packages compromised

#433
post #141

Earlier quoted context omitted.

Yo, someone at npm needs to unpublish simple-swizzle@0.2.3 IMMEDIATELY. It’s still actively compromised.

It's been almost two hours without a single email back from npm. I am sitting here struggling to figure out what to do to fix any of this. The packages that have Sindre as a co-publisher have been published over but even he isn't able to yank the malicious versions AFAIU. If there's any ideas on what I should be doing, I'm all ears. EDIT: I've heard back, they said they're aware and are on it, but no further details.

My god. The npm team should urgently review their internal processes. These two hours of neglect will cost a lot of money downstream. At this stage, they act nothing short of irresponsible.

Re: NPM debug and chalk packages compromised

#434
post #412
post #246

Earlier quoted context omitted.

We also caught this right away at Socket, https://socket.dev/blog/npm-author-qix-compromised-in-major-... While it sucks that this happened, the good thing is that the ecosystem mobilized quickly. I think these sorts of incidents really show why package scanning is essential for securing open source package repositories.

So how do you detect these attacks?

AI based code review with escalation to a human

Re: NPM debug and chalk packages compromised

#435
post #187

Earlier quoted context omitted.

Try the same recursive grep on ~/.npm to see if you have it cached too. Not just the latest in the current project.

Haven't installed any modules today, but I ran these commands to clear caches for npm and pnpm just to be safe. npm cache clean --force pnpm cache delete

You probably want to check before you clear cache

Re: NPM debug and chalk packages compromised

#436

Earlier quoted context omitted.

yes. ripgrep just does it faster, is all.

Make it work, make it right, make it fast. For security checks, the first 2 out of 3 is just fine.

Sure, but if you can get the last for free, why not?

Re: NPM debug and chalk packages compromised

#437
post #415
post #349

Earlier quoted context omitted.

Being able to sign releases would help, too. I would happily have that enabled since I'm always publishing from one place.

Wouldn't they have been able to change your key if they had compromised your entire npm account? Also, junon.support++ – big thanks for being clear about all this.

Hmm, maybe npm needs to do the same thing the iPhone does now.

If you change your key you can't use it for like 12 hours or something?

Re: NPM debug and chalk packages compromised

#438

Earlier quoted context omitted.

This is the answer IMO. The number of targets and noise would be a lot less if JS had a decent stdlib or if we had access to a better language in the browser. I have no hope of this ever happening and am abandoning the web as a platform for interactive applications in my own projects. I’d rather build native applications using SDL3 or anything else.

But this can't be the whole story. In the Java world, it's pretty common to import a couple huge libraries full of utility functions, but those are each one import , that you can track and version and pay attention to. Apache Commons helper libraries don't import sub libraries for every little thing, they collect a large toolbox into a single library/jar. Why instead do people in the javascript ecosystem insist on se…

Bundle size optimisation. See my comment upthread for more detailed explanation. Bundle size is one of the historical factors that makes JS ecosystem a unique culture, and I'd argue uniquely paranoid.

Re: NPM debug and chalk packages compromised

#439
post #424

Earlier quoted context omitted.

I would agree if this were one of those `curl | sh` scenarios, but don't we consider things like `brew` to be sufficiently low-risk, akin to `apt`, `dnf`, and the like?

APT repos for Debian, Trisquel, Ubuntu... require far more checkings and bureaucracy.

I'll bet they don't. There's way to much churn for it all to be checked

Re: NPM debug and chalk packages compromised

#440
post #9

Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…

> Made the mistake of clicking the link instead of going directly to the site like I normally would (since I was mobile). Does anyone know how this attack works? Is it a CSRF against npmjs.com?

Fake site.

You login with your credentials, the attacker logins to the real site.

You get an SMS with a one time code from the real site and input it to the fake site.

The attacker takes the code andc finishes the login to the real site.

Post reply on HN