Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

451–460 of 796 posts

Re: NPM debug and chalk packages compromised

#451
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…

Didn't your password manager notice that npmjs dot help was not a legit domain and avoid auto-filling there?

Re: NPM debug and chalk packages compromised

#452

Tips to protect yourself from supply-chain attacks in the JavaScript ecosystem: - Don't update dependencies unless necessary - Don't use `npm` to install NPM packages, use Deno with appropriate sandboxing flags - Sign up for https://socket.dev and/or https://www.aikido.dev - Work inside a VM

> Don't update dependencies unless necessary

And get yourself drowning in insurmountable technical debt in about two months.

JS ecosystems moves at an extremely fast pace and if you don't upgrade packages (semi) daily you might inflict a lot of pain on you once a certain count of packages start to contain incompatible version dependencies. It sucks a lot, I know.

Re: NPM debug and chalk packages compromised

#453
post #422

Yeah I know "everyone can be pwned" etc. but at this point if you are not using a password manager and still entering passwords on random websites whose domains don't match the official one then you have no business doing anything of value on the internet.

Yeah, a password manager/autofill would have set off some alarms and likely prevented this, because the browser autofill would have detected a mismatch for the domain npmjs.help.

Re: NPM debug and chalk packages compromised

#455
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.

[flagged]

For those interested, points associated with this post spiked to at least 4 then dropped back to one. Take of that what you will.

Re: NPM debug and chalk packages compromised

#457

Earlier quoted context omitted.

I can provide you with some missing background as I was a prior full time JavaScript/TypeScript developer for 15 years. Most people writing JavaScript code for employment cannot really program. It is not a result of intellectual impairment, but appears to be more a training and cultural deficit in the work force. The result is extreme anxiety at the mere idea of writing original code, even when trivial in size and sc…

If Javascript people were bad programmers, we wouldn't see two new frontend frameworks per year. Many of them are ambitious projects that must have had thousands of hours put in by people who know the language well. The observation is real however. But every culture develops its own quirks and ideas, and for some reason this has just become a fundamental part of Javascript's. It's hard to know why after the fact, but…

There's a reason you don't see two frameworks every year in another language. Being a good programmer is recognizing when a problem is solved and actually contributing to the solution instead of recreating it. Coding a new system can be done really quickly as you're mostly focusing on the happy path. The real work is ironing out bugs and optimizing the performance.

Re: NPM debug and chalk packages compromised

#458

Here we are again. 12 days ago ( https://news.ycombinator.com/item?id=45039764 ) I commented how a similar compromise of Nx was totally preventable. Again, this is not the failure of a single person. This is a failure of the software industry . Supply chain attacks have gigantic impacts. Yet these are all solved problems. Somebody has to just implement the standard security measures that prevents these compromises. W…

> Somebody has to just implement the standard security measures that prevents these compromises.

It's not that simple. You can implement the most stringent security measures, and ultimately a human error will compromise the system. A secure system doesn't exist because humans are the weakest link.

So while we can probably improve some of the processes within npm, phishing attacks like the ones used in this case will always be a vulnerability.

You're right that AI tools will make these attacks more common. That phishing email was indistinguishable from the real thing. But AI tools can also be used to scan and detect such sophisticated attacks. We can't expect to fight bad actors with superhuman tools at their disposal without using superhuman tools ourselves. Fighting fire with fire is the only reasonable strategy.

Re: NPM debug and chalk packages compromised

#459
post #418
post #77

Earlier quoted context omitted.

Because a mini thing can be written in mini time by a mini number of people

And a mini thing can be switched to another 'mini' package easy enough if the current package decides to do something dumb. If your mega package decides to drop something you need you pretty much have to follow.

> If your mega package decides to drop something you need you pretty much have to follow.

Or you can code it in. Mega packages can be very stable. Think SDL, ffmpeg, ImageMagick, Freetype...There's usually a good justification for dropping something alongside a wide deprecation windows. You don't just wake up and see the project gone. It's not like the escape codes for the unix terminal are going to change overnight.

Re: NPM debug and chalk packages compromised

#460
post #442

Earlier quoted context omitted.

We should be displaying hashes in a color scheme determined by the hash (foreground/background colors for each character determined by a hash of the hash, salted by that character's index, adjusted to ensure sufficient contrast). That way it's much harder to make one hash look like another.

As someone with red/green vision deficiency: if you do this, please don’t forget people like me are unable to distinguish many shades of colours, which would be very disadvantageous here!

It’s not like it would hurt you for there to be supplementary info others can see but you can’t.
Post reply on HN