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.
NPM debug and chalk packages compromised
431–440 of 796 posts
Re: NPM debug and chalk packages compromised
#432Re: NPM debug and chalk packages compromised
#433Earlier 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.
Re: NPM debug and chalk packages compromised
#434Earlier 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?
Re: NPM debug and chalk packages compromised
#435Earlier 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
Re: NPM debug and chalk packages compromised
#436Re: NPM debug and chalk packages compromised
#437Earlier 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.
If you change your key you can't use it for like 12 hours or something?
Re: NPM debug and chalk packages compromised
#438Earlier 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…
Re: NPM debug and chalk packages compromised
#439Earlier 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.
Re: NPM debug and chalk packages compromised
#440Hi, 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?
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.