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

691–700 of 796 posts

Re: NPM debug and chalk packages compromised

#691

Post by lelanthran »

rollcat wrote: post #677
lelanthran wrote: post #376

Earlier quoted context omitted.

> The problem is email as it’s used currently. The solution is to not use email. No. The problem is unsigned package repositories. The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.

> The solution is to tie a package to an identity using a certificate. Identity on the Internet is a lie. Nobody knows you're a dog. The solution is to make security easy and accessible, so that the user can't be confused into doing the insecure thing.

> Identity on the Internet is a lie.

What do you think HTTPS is?

Re: NPM debug and chalk packages compromised

#692

Post by [deleted] »

sangeeth96 wrote: post #204
austin-cheney wrote: post #167

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…

> Most people writing JavaScript code for employment cannot really program. > As a proof ask any JavaScript team at your employment to build their next project without a large framework and just observe how they respond both verbally and non-verbally. With an assumption like that, I bet the answer is mostly the same if you ask any Java/Python dev for example — build your next microservice/API without Spring or DRF/Fl…

[deleted]

Re: NPM debug and chalk packages compromised

#693

Post by zero_shift »

12_throw_away wrote: post #306
zero_shift wrote: post #180

Earlier quoted context omitted.

> The responses vary but often take the form of reused cliches of which some don't even directly apply. "It has been tested by a 1000 people before me" "What if there is an upstream optimisation?" "I'm just here to focus on Business Problems™" "It reduces cognitive load" --- Whilst I think you are exaggerating, I do recognise this phenomenon. For me, it was during the pandemic when I had to train / support a lot of b…

> They were anxious to perform in their new career and interpreted that as shipping tickets as fast as possible. [...].. they had like, no drive at all to engage with problems To be honest, I think these programmers understood their jobs perfectly here. Their bosses view programmers as commodities, are not concerned with robustness, maintainability, or technical merit - they want a crank they can turn that spits out…

I think you are right. Those feature factory teams were the ones hiring as fast as they could; they didn't need to filter on programming fundamentals; and they could exploit the anxiety of junior developers who sensed the market was becoming competitive.

Re: NPM debug and chalk packages compromised

#694

Post by [deleted] »

IshKebab wrote: post #217
austin-cheney wrote: post #167

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…

Not my experience at all. It's more like a) JS devs view NPM packages as a mark of pride and so they try to make as many as possible (there are people proud of maintaining hundreds of packages, which is obviously dumb), and b) people are lazy and will take a ready-made solution if it's available, and c) there are a lot of JavaScript developers. The main reasons you don't see this in other languages is they don't have…

[deleted]

Re: NPM debug and chalk packages compromised

#695

Post by benchloftbrunch »

lelanthran wrote: post #376
notmyjob wrote: post #184

Earlier quoted context omitted.

Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.

> The problem is email as it’s used currently. The solution is to not use email. No. The problem is unsigned package repositories. The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.

As long as you're OK with self signed certificates or PGP keys, I'd be on board with this.

I really, really dislike the idea of using TLS certificates as we know them for this purpose, because the certificate authority system is too centralized, hierarchical, and bureaucratic, tightly coupled to the DNS.

That system is great for the centralized, hierarchical, bureaucratic enterprises who designed it in the 90s, but would be a pain in the ass for a solo developer, especially with the upcoming change to 45 day lifetimes.

Re: NPM debug and chalk packages compromised

#696

Post by nialv7 »

hdjrudni wrote: post #626
yawaramin wrote: post #598

Earlier quoted context omitted.

I'm angry about this. Large megacorps with the budget of medium-sized countries allocate the minimum amount of budget to maintain their auth systems and still allow the use of phishable auth methods. If npm disabled passwords and forced people to use passkeys, this huge problem just disappears tomorrow. But instead, we're left with this mess where ordinary developers are forced to deal with the consequences of gettin…

Passkeys can be a pain in the ass too. Evidentially I set up my Yubikey with Github as some point, which is fine if I'm at my desktop where my key is plugged in, but if I want to sign in on mobile.... now what? I just couldn't log in on mobile for months until I realized I think there's a button on there somewhere that's like "use different 2fa" but then what was even the point of having a key registered if it can be…

you can use yubikeys for both passkey and password+2fa. this way you aren't bypassing anything. and btw, you can get USB-C yubikeys so you can plug it into your phone. if even that's not an option, you can get a USB-C to USB-A adapter.

Re: NPM debug and chalk packages compromised

#697

Post by n8m8 »

junon wrote: 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…

Thanks for leaving a transparent response with what happened, how you responded, what you're doing next, and concisely taking accountability Great work!

Re: NPM debug and chalk packages compromised

#698

Post by diggan »

Macha wrote: post #654
sunaookami wrote: post #582

Earlier quoted context omitted.

Then get a good password manager that matches the domain and triple-check if it's a new domain. If your password manager shows you your npm login for npmjs.com and you are suddenly on a new domain and your password manager doesn't show logins, you will notice.

I've noticed failure to fill the right fields (or any fields) on Lastpass, 1Password, Bitwarden and the KeepassXC browser extension. What is your mythical "good password manager"?

I'm using 1Password+Firefox+Linux, it fails to find the right username+passwords maybe 10% of the time, mostly because services keep using different domains for login than for signup, so it doesn't recognize it's a valid domain.

In those cases, I carefully review the new domain, make sure it belongs to the right owner, then add it to the list of domains to accept. Now the account list properly show up in the future too, until they again change it. But it gives me a moment to pause and reflect before just moving past it.

I cannot remember any times in the last years where 1Password was 100% unable to fill out the username/password for a website unless the website itself prevented pasting passwords (like my old bank).

But even if it fills the wrong fields, it still provides safety as you wouldn't even see the accounts in the list if you're on the wrong domain, so that's your first warning sign.

Re: NPM debug and chalk packages compromised

#699

Post by n8m8 »

what wrote: post #571
tripplyons wrote: post #344

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.

Agreed that it's a bit funny given the context and no community-managed package manager should be 100% trusted.

That said, I think rg is pretty well known to linux daily-drivers and they just wanted to share something quickly for powerusers who want to check their workspaces quickly. Probably better to just instruct n00bs to use grep than install a whole cli tool for searching

Come to think of it, I wonder if a 2-phase attack could be planned by an attacker in the future: Inject malware into a package, flood guidance with instructions to install another popular tool that you also recently compromised... lol

Re: NPM debug and chalk packages compromised

#700

Post by n8m8 »

hunter2_ wrote: post #446
dmitrygr wrote: post #404

Earlier quoted context omitted.

> don't we consider things like `brew` to be sufficiently low-risk, Like ... npm?

I thought getting code into brew is blocked by some vetting (potentially insufficient, which could be argued for all supply chains), whereas getting code into npm involves no vetting whatsoever.

Went and found the link: https://docs.brew.sh/Acceptable-Casks#apps-that-bundle-malwa...

> Unfortunately, in the world of software there are bad actors that bundle malware with their apps. Even so, Homebrew Cask has long decided it will not be an active gatekeeper (macOS already has one) and users are expected to know about the software they are installing. This means we will not always remove casks that link to these apps, in part because there is no clear line between useful app, potentially unwanted program, and the different shades of malware—what is useful to one user may be seen as malicious by another.

Post reply on HN