Earlier quoted context omitted.
> You can pretend like this is unique to JS ecosystem, but xz was compromised for 3 years. Okay, but you're not suggesting that a compression algorithm is the same scale as "is-arrayish". I don't think everyone should need to reimplement LZMA but installing a library to determine if a value is an array is bordering on satire.
FWIW, is-arrayish is primarily an internal dependency. The author (Qix) depends on it for the packages that actually get used, liked color and error-ex. But it's all one author.
NPM debug and chalk packages compromised
361–370 of 796 posts
Re: NPM debug and chalk packages compromised
#362Earlier quoted context omitted.
No, I have never, ever responded to an explicit ask to reset the most important security feature of my accounts, without me initiating it, and I use a password manager (lol) so, no, I will never, ever encounter this problem. Because I care about my data, safety, and integrity, and my users'. There's literally no reason ever why I would or will do a 2FA reset. It does happen, yes, it's not terrifying.
The wording was similar to how GitHub started requiring 2FA. It wasn't "there is the 2FA change that initiate" it was more of starting September 10 we will starting to request 2fa
Wouldn't have happened if they used passkeys or a password manager. Things that get dunked on here regularly. Hm.
Re: NPM debug and chalk packages compromised
#363Re: NPM debug and chalk packages compromised
#364Earlier quoted context omitted.
How is it terrifying? They clicked through a 2FA reset email, a process that I have never, and will never need to go through, and seemingly one that they didn't even initiate.
How many developers are there like him? If not him, they'll target someone else. And while you or I will never do such a thing under normal circumstances, that's a pretty simple mistake to make if you are stressed, sleep deprived or sick. We are supposed to have automatic safeguards against such simple mistakes. (We used to design stuff with the assumption that if a human mistake is possible, someone will eventually…
Re: NPM debug and chalk packages compromised
#365Hi, 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…
I hate that kind of email when sent out legitimately. Google does this crap all the time pretty much conditioning their customers to click those links. And if you're really lucky it's from some subdomain they never bothered advertising as legit. Great of you to own up to it.
Re: NPM debug and chalk packages compromised
#366Hi, 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…
Just want to agree with everyone who is thanking you for owning up (and so quickly). Got phished once while drunk in college (a long time ago), could have been anyone. NPM being slowish to get back to you is a bit surprising, though. Seems like that would only make attacks more lucrative.
Re: NPM debug and chalk packages compromised
#367Re: NPM debug and chalk packages compromised
#368I've come to the conclusion that avoiding the npm registry is a great benefit. The alternative is to import packages directly from the (git) repository. Apart from being a major vector for supply-chain attacks like this one, it is also true that there is little or no coupling between the source of a project and its published code. The 'npm publish' step takes pushes local contents into the registry, meaning that a ma…
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.
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:
Re: NPM debug and chalk packages compromised
#369Earlier quoted context omitted.
They phished username, password (unique to npm), and a TOTP code. They even gave me a new TOTP code to install (lol) and it worked. Showed up in authy fine. Whoever made this put a ton of effort into it.
Damn, that's an impressively well-done attack. Curious, do you use a password manager? If so, did it not autofilling feel like a red flag to you? I've always wondered if I ever get phished if I'll notice bc of that or if I'll just go "ugh 1password isn't working, guess i'll paste my password in manually" and end up pwned
Re: NPM debug and chalk packages compromised
#370I 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-.
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? I don’t think it’s ignorance or laziness or lack of knowledge about good software engineering. It’s because either ego (“I’m the maintainer of N packages with millions of downloads” sounds better than “I’m the maintainer of 1 package “), or because they get more donations or because they are actually planning to drop malware some time soon.