Earlier quoted context omitted.
Anyone can upload an NPM package without much review. For Homebrew, you at least have to submit a pull request.
Homebrew has been compromised before. To think it’s immune is a bit naive.
NPM debug and chalk packages compromised
721–730 of 796 posts
Re: NPM debug and chalk packages compromised
#722I have nothing to do with this but still I am getting second hand embarrassment. Here is an example, is-arrayish package, 73.8 MILLION downloads per week. The code? 3 lines to check if an object can be used like an array. I am sorry, but this is not due to not having a good standard library, this is just bad programming. Just pure laziness. At this point just blacklist every package starting with is-.
You don’t get it. People don’t add “is-arrayish” directly as a dependency. It goes like this: 1) N tiny dubious modules like that are created by maintainers (like Qix) 2) The maintainer then creates 1 super useful non-tiny module that imports those N dubious modules. 3) Normal devs add that super useful module as a dependency… and ofc, they end up with countless dubious transitive dependencies Why maintainers do that…
They personally buy into modularization, do-one-thing-do-it-well. Also engineering is fun, and engineering more things is more fun.
Re: NPM debug and chalk packages compromised
#723Earlier quoted context omitted.
Sorry to be dumb, but can you expand a bit on "2FA reset email..." so the rest of us know what not to do?
Ignore anything coming from npm you didn't expect. Don't click links, go to the website directly and address it there. That's what I should have done, and didn't because I was in a rush. Don't do security things when you're not fully awake, too. Lesson learned. The email was a "2FA update" email telling me it's been 12 months since I updated 2FA. That should have been a red flag but I've seen similarly dumb things co…
That's how they get you.
Re: NPM debug and chalk packages compromised
#724Hi, 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…
Re: NPM debug and chalk packages compromised
#725Earlier quoted context omitted.
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 wo…
I doubt we'll ever see eye-to-eye on this. Some people try to think about how to write less code, and some people try to think about how to write more code.
Re: NPM debug and chalk packages compromised
#726Earlier quoted context omitted.
I blame the prevalence of package mangers in the first place. Never liked em, just for this reason. Things were fine before they became mainstream. Another annoying reason is package files that are set to grab the latest version, randomly breaking your environment. This isn't just npm of course, I hate them all equally.
I'm a little confused, is this rage bait or what? > Things were fine before they became mainstream As in, things were fine before we had commonplace tooling to fetch third party software? > package files that are set to grab the latest version The three primary Node.js package managers all create a lockfile by default.
In some ways they were. I remember how much friction it was to take a dependency in your typical desktop C++ or Delphi app in late 90s - early 00s. And because of that, developers would generally be hesitant to add a new dependency without a strong justification, especially so any kind of dependency that comes with its own large dependency tree. Which, in turn, creates incentives for library authors to create fairly large, framework-style libraries. So you end up with an ecosystem where dependencies are much more coarse and there are fewer of them, so dependency graphs are shallow. Whether this is an advantage or a disadvantage in its own right can be debated, but it's definitely less susceptible to this kind of attack because updating dependencies in such a system is also much more involved; it's not something that you do with a single `npm install`.
Re: NPM debug and chalk packages compromised
#727Finally 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.
Re: NPM debug and chalk packages compromised
#728Earlier quoted context omitted.
>What about packages that are not "flagged"? You can't catch everything with normal static analysis either. LLM just produces some additional signal in this case, false negatives can be tolerated.
static analysis DOES NOT hallucinate.
There are cases an LLM may be able to catch that their static analysis can't currently catch. Should they just completely ignore those scenarios, thereby doing the worst thing by their customers, just to stay purist?
What is the worst case scenario that you're envisioning from an LLM hallucinating in this use case? To me the worst case is that it might incorrectly flag a package as malicious, which given they do a human review anyway isn't the end of the world. On the flip side, you've got LLM catching cases not yet recognised by static analysis, that can then be accounted for in the future.
If they were just using an LLM, I might share similar concerns, but they're not.
Re: NPM debug and chalk packages compromised
#729Hi, 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…
The 2FA/TOTP security theater was partly to blame for this.
Re: NPM debug and chalk packages compromised
#730Earlier quoted context omitted.
There is NO reliable indicators, because every single one of these "Legit requests don't ..." recommendations has been done by a local bank trying to get their customers to do something. My local credit union sent me a "please change your password" email from a completely unassociated email address with a link to the change password portal. I emailed them saying "Hey it looks like someone is phishing" and they said,…
> There is NO reliable indicators Completely agree. The only reliable way is to never use an email/SMS link to login, ever.