Earlier quoted context omitted.
Can you post full message headers somewhere? It'd be interesting which MTA was involved in delivery from the sender's side.
Yep - https://gist.github.com/Qix-/c1f0d4f0d359dffaeec48dbfa1d40ee...
NPM debug and chalk packages compromised
391–400 of 796 posts
Re: NPM debug and chalk packages compromised
#392Earlier quoted context omitted.
Sorry, I am unfamiliar with ripgrep. Is this simply scanning for the string `_0x112fa8`? Could we do the same thing with normal grep -r?
yes. ripgrep just does it faster, is all.
But also respects .gitignore by default so I’m not sure you want to use ripgrep to scan your node_modules
Re: NPM debug and chalk packages compromised
#393Earlier quoted context omitted.
In all fairness—npm belongs to GitHub, which belongs to Microsoft. Amateur-hour is both not a valid excuse anymore, and also a boring explanation. GitHub is going to great lengths to enable SLSA attestations for secure tool chains; there must be systemic issues in the JS ecosystem that make an implementation of proper attestations infeasible right now, everything else wouldn't really make sense. So if we're discussin…
The NPM team has repeatedly commented that it's "too hard", effectively, and would discourage new developers from publishing packages. See: https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://news.ycombinator.com/item?id=38645969 https://github.com/npm/cli/commit/5a3b345d6d5d175ea9ec967364...
The npm team is, frankly, a bunch of idiots for saying that. It has been obvious for TEN YEARS that the bar for publishing npm packages is far too low. That’s what made npm what it is, but it’s no longer needed. They should put on their big boy pants.
Re: NPM debug and chalk packages compromised
#394Hi, 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…
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.
[flagged]
Re: NPM debug and chalk packages compromised
#395Earlier quoted context omitted.
Tbh, it's not your fault per se; everybody can fall for phishing emails. The issue, IMO, lies with npmjs which publishes to everyone all at the same time. A delayed publish that allows parties like Aikido and co to scan for suspicious package uploads first (e.g. big changes in patch releases, obfuscated code, code that intercepts HTTP calls, etc), and a direct flagging system at NPM and / or Github would already be a…
Being able to sign releases would help, too. I would happily have that enabled since I'm always publishing from one place.
Provenance can be added to NPM https://docs.npmjs.com/generating-provenance-statements
So if the hacker did an npm publish from local it would show up.
Re: NPM debug and chalk packages compromised
#396Another great example of why things like dependabot or renovate for automatically bumping dependencies to the latest versions is not a good idea. If it's not a critical update, better to let the world be your guinea pig and only update after there's been a while of real world usage and analysis. If it is a critical enough update that you have to update right away, then you take the time to manually research what's in…
If the update isn't from a security alert, I let most dependabot PRs marinate for about a week precisely for this reason. Not the most scientific approach, but less stressful for sure.
Re: NPM debug and chalk packages compromised
#397Hi, 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…
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.
[deleted]
Re: NPM debug and chalk packages compromised
#398Finally validated for writing my own damn ANSI escape codes.
Yeah, I get that learning the codes is a little annoying, but not actually harder than finding, incorporating, and learning one of the APIs here. Also one is standard while the other is not. Seems a bit nuts to use a package for this.
Hi, missing a lot of history here. When Chalk was written, colors in the terminal wasn't a flashy thing people tried to do very often, at least not in the JS world. Coming from browsers and wanting to make CLI apps using the flashy new Node.js 0.10/0.12 at the time saw a lot of designers and other aesthetically-oriented folks with it. Chalk filled a hole for people to do that without needing to understand how TTYs worked.
Node.js proper has floated the idea of including chalk into the standard libraries, FWIW.
Re: NPM debug and chalk packages compromised
#399Earlier quoted context omitted.
As a C developer, having being told for a decade that minimising dependencies and vendoring stuff straight from release is obsolete and regressive, and now seeing people have the novel realisation that it's not, is so so surreal. Although I'll still be told that using single-header libraries and avoiding the C standard library are regressive and obsolete, so gotta wait 10 more years I guess.
NPM dev gets hacked, packages compromised, it's detected within couple of hours. XZ got hacked, it reached development versions of major distributions undetected, right inside an _ssh_, and it only got detected due to someone luckily noticing and investigated slow ssh connections. Still some C devs will think it's a great time to come out and boast about their practices and tooling. :shrug:
xz didn't get hacked (phished).
For xz an advanced persistent threat, inserted hypertargeted self modifying code into a tarball.
A single npm dev was "hacked" (phished) by a moderate effort, (presumably drive by) crypto thief.
I have no idea what you meant by "right inside _ssh_" but I don't think that's a good description of what actually happened in any possible case.
I'm unlikely to defend C devel practices but this doesn't feel like an indictment of C, if anything the NPM ecosystem looks worse by this comparison. Especially considering the comment you replied to was advocating for minimizing dependencies, which if the distros effected by xz being compromised had followed, (instead of patching sshd) they wouldn't have shipped a compromised version.
Re: NPM debug and chalk packages compromised
#400Earlier 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…
Originally I think it was to avoid the applet experience of downloading a large util.jar or etc. (Not that most js devs really care.) However, I suspect the motivation is often social status on GitHub & their resume.