Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

191–200 of 796 posts

Re: NPM debug and chalk packages compromised

#191

Post by kelvinjps10 »

Deukhoofd wrote: post #87
grishka wrote: post #46

Earlier quoted context omitted.

Not Java, thankfully! Libraries containing 1-2 trivial classes do exist, but they're an exception rather than a rule. Might be that the process of publishing to Maven Central is just convoluted enough to deter the kinds of people who would publish such libraries.

Also because Java, .NET, etc. all have very expansive standard libraries. You don't need to import most stuff, as it's already built-in.

But then you depend on Microsoft for everything. I prefer python where it's battery Included but you depend on a foundation

Re: NPM debug and chalk packages compromised

#192

Post by withinboredom »

diggan wrote: post #178
withinboredom wrote: post #175

Earlier quoted context omitted.

This isn’t exactly true. My password manager fails to recognise the domain I’m on, all the time. I have to go search for it and then copy/paste it in. That being said, if you’re making login pages: please, for the love of god, test them with multiple password managers. Oh, and make sure they also work correctly with the browser’s autotranslation. Don’t rely on the label to make form submission decisions ... please.

> This isn’t exactly true. My password manager fails to recognise the domain I’m on, all the time. I have to go search for it and then copy/paste it in. I'd probably go looking for a new password manager if it fails to do one of the basic features they exist for, copy-pasting passwords defeats a lot of the purpose :) > That being said, if you’re making login pages I think we're doomed on this front already. My previo…

> I'd probably go looking for a new password manager if it fails to do one of the basic features they exist for, copy-pasting passwords defeats a lot of the purpose :)

This isn’t the fault of the password managers themselves, but devs not putting the right metadata on their login forms, or havo the password field show only after putting in the email address, causing the password input to fail to be filled, etc.

Re: NPM debug and chalk packages compromised

#193

Post by herpdyderp »

wch wrote: post #106

When I run `npm audit`, it points me to a security advisory at GitHub. For example, for debug, it is https://github.com/advisories/GHSA-8mgj-vmr8-frr6 . That page says that the affected versions are ">=0". Does that seem right? That page also says: > Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediatel…

I also see:

- https://github.com/advisories/GHSA-hfm8-9jrf-7g9w

- https://github.com/advisories/GHSA-5g7q-qh7p-jjvm

- https://github.com/advisories/GHSA-8mgj-vmr8-frr6

- https://github.com/advisories/GHSA-m99c-cfww-cxqx

I wonder if they're all from the same thing, they all popped up at the same time.

edit: they do appear to all be the same thing, and the advisory version wildcard is wrong: https://github.com/github/advisory-database/issues/6099

Re: NPM debug and chalk packages compromised

#194

Post by koolba »

Another 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 the package, what changed, and why it is being updated.

Re: NPM debug and chalk packages compromised

#195

Post by HexDecOctBin »

simpaticoder wrote: post #121

I'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.

Re: NPM debug and chalk packages compromised

#196

Post by 0cf8612b2e1e »

nine_k wrote: post #30
stathibus wrote: post #18

As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?

Having a module for every little trivial thing allows you to only bring these modules inside the JS bundle you serve to your client. If there's a problem in one trivial-thing function, other unrelated trivial things can still be used, because they are not bundled in the same package. A comprehensive library might offer a more neat DX, but you'd have to ship library code you don't use. (Yes, tree-shaking exists, but s…

Given how fat a modern website is, I am not sure that a kitchen sink library would change much. It could actually improve things because there would be fewer redundant libraries for basic functionality.

Say there is neoleftpad and megaleftpad - both could see widespread adoption, so you are transitively dependent on both.

Re: NPM debug and chalk packages compromised

#197

Post by alexellisuk »

junon wrote: post #112
SSLy wrote: post #64

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

How did simply opening this email in something like Gmail or a desktop client result in it being able to compromise NPM packages under your control?

I'm just curious - and as a word of warning to others so we can learn. I may be missing some details, I've read most of the comments on the page.

Re: NPM debug and chalk packages compromised

#198

Post by cgijoe »

joaomoreno wrote: post #129

From sindresorhus: You can run the following to check if you have the malware in your dependency tree: `rg -u --max-columns=80 _0x112fa8` Requires ripgrep: `brew install rg` https://github.com/chalk/chalk/issues/656#issuecomment-32668...

Sorry, I am unfamiliar with ripgrep. Is this simply scanning for the string `_0x112fa8`? Could we do the same thing with normal grep -r?

Re: NPM debug and chalk packages compromised

#199

Post by IshKebab »

junon wrote: post #45
nodesocket wrote: post #14

Earlier quoted context omitted.

What did the phishing email say that made you click and login?

That it had been more than 12 months since last updating them. Npm has done outreach before about doing security changes/enhancements in the past so this didn't really catch me. Screenshot here: https://imgur.com/a/q8s235k

And then what happens when you click the link? Wouldn't your password manager fail to auto fill your details?
Post reply on HN