Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

531–540 of 796 posts

Re: NPM debug and chalk packages compromised

#531
post #506

After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.

I'm a fan of post-facto confirmation. Allow CI/CD to do the upload automatically, and then have a web flow that confirms the release. Release doesn't go out unless the button is pressed. It removes _most_ of the release friction while still adding the "human has acknowledged the release" bit.

Maybe even send a user an email notification with a link...

Re: NPM debug and chalk packages compromised

#532
post #296

Earlier 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.

Yeah lol I’m making a C package manager for exactly this. No transitive dependencies, no binaries served. Just pulling source code, building, and being smart about avoiding rebuilds.

Being smart about avoiding rebuilds is serving prebuilds

Re: NPM debug and chalk packages compromised

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

I am not very sophisticated npm user on MacOS, but I installed bunch of packages for Claude Code development. How do we check if computer has a problem?

Do we just run:

npm list -g #for global installs

npm list #for local installs

And check if any packages appear that are on the above list?

Thanks!

Re: NPM debug and chalk packages compromised

#534
post #473

Earlier quoted context omitted.

I use a password manager. I was mobile, the autofill stuff isn't installed as I don't use it often on my phone. In 15 years of maintaining OSS, I've never been pwned, phished, or anything of the sort. Thank you for your input :)

I just don't get how you didn't look for an announcement about npm resetting 2fa. Especially when you get a random reset

Because you’re one person with a job which isn’t security, and the world is full of legitimate warnings from companies telling you that you must do something by an arbitrary deadline?

They screwed up, but we have thousands of years of evidence that people make mistakes even when they really know better and the best way to prevent that is to remove places where a single person making a mistake causes a disaster.

On that note, how many of the organizations at risk do you think have contributed a single dollar or developer-hour supporting the projects they trust? Maybe that’s where we should start looking for changes.

Re: NPM debug and chalk packages compromised

#535

Earlier quoted context omitted.

I agree with you, but I'd ask- what other language needs to distribute to an unknown runtime environment over the network? If it's the browser's job to implement the standard library, how do you ensure that all browsers do this in a compliant and timely fashion? And if not, how do you optimise code-on-demand delivery over the internet? I don't deny there are/could be solutions to this. But historically JS devs have w…

> what other language needs to distribute to an unknown runtime environment over the network? What is this unknown runtime environment? Even during the browser war, there was just an handful of browsers. And IE was the only major outlier. Checking the existence of features and polyfilling is not that complicated. And most time, the browser is already downloading lot of images and other resources. Arguing about bundle…

> Checking the existence of features and polyfilling is not that complicated.

Judging by what we see in the world, most developers don't agree with you. And neither do I. A handful of browsers, multiplied by many versions per browser in the wild (before evergreen browsers like Chrome became widespread, but even today with e.g. Safari, or enterprise users), multiplied by a sprawling API surface (dare I say it, a standard library) is not trivial. And that's not even considering browser bugs and regressions.

> very hypocritical of developers that won't blink

Not a great argument, as developers don't necessarily get to choose how to add analytics, and plenty of them try to push back against doing so.

Also, the cost of parsing and JIT'ing JS code is byte-for-byte different to the cost of decoding an image.

Re: NPM debug and chalk packages compromised

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

How does someone intelligent with 2FA get pwned? Serious question.

Re: NPM debug and chalk packages compromised

#537

Earlier quoted context omitted.

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

npmjs is the stdlib, or what emerged from it. It started as CommonJs ([1]) with Server-side JavaScript (SSJS) runtimes like Helma, v8cgi, etc. before node.js even existed but then was soon totally dominated by node.js. The history of Server-side JavaScript btw is even longer than Java on the server side, starting with Netscape's LifeScript in 1996 I believe. Apart from the module-loading spec, the CommonJs initiative…

> TypeScripters who need big daddy MS or other monopolist to sort it all out for them

What is this crap statement?

So you want type-checking because it helps you catch a class of errors in an automated way, and suddenly you have a daddy complex and like monopolies?

Claiming this says a lot more about you than people who use TypeScript.

Re: NPM debug and chalk packages compromised

#538
post #529
post #522

Earlier quoted context omitted.

> sometimes the password manager does not auto-fill So pick one that does? That's like its top 2 feature > he does use one He doesn't since he has no autofill installed, so loses the key security+ convenience benefit of automatch

He didn't say it didn't have the autofill feature, he said sometimes it doesn't work. I've experienced this pretty routinely with two different managers.

Yes he did, read again

> I was mobile, the autofill stuff isn't installed

Re: NPM debug and chalk packages compromised

#539
post #398
post #358

Earlier quoted context omitted.

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 wo…

> Node.js proper has floated the idea of including chalk into the standard libraries, FWIW.

Oh my word please no! Every time I run into an issue where a dependency suddenly isn’t logging colors like it’s supposed to, it always boils down to chalk trying to do something fancy to handle an edge case that doesn’t actually exist. Just log the dang colors!

Re: NPM debug and chalk packages compromised

#540
post #522

Earlier quoted context omitted.

I mostly agree and I do use one. You only need read the whole thread however to see reasons why this would sometimes not be enough: sometimes the password manager does not auto-fill, so the user can think it's one of those cases, or they're on mobile and they don't have the extension there, or... As a matter of fact, he does use one, that didn't save him, see: https://news.ycombinator.com/item?id=45175125

> sometimes the password manager does not auto-fill So pick one that does? That's like its top 2 feature > he does use one He doesn't since he has no autofill installed, so loses the key security+ convenience benefit of automatch

> So pick one that does? That's like its top 2 feature

Still doesn’t work 100% of the time, because half of the companies on earth demote their developer time to breaking 1995-level forms. That’s why every popular password manager has a way to fill passwords for other domains, why people learn to use that feature, and why phishers have learned to convince people to use that feature.

WebAuthn prevents phishing. Password managers reduce it. This is the difference between being bulletproof like Superman or a guy in a vest.

Post reply on HN