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

591–600 of 796 posts

Re: NPM debug and chalk packages compromised

#591

Post by eviks »

acdha wrote: post #540
eviks wrote: 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

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

You don't need 100%, just a high enough frequency that you wouldn't get used to dismissing the fail on auto pilot. Perfect shouldn't be the enemy of the good?

Re: NPM debug and chalk packages compromised

#592

Post by josephg »

hsbauauvhabzb wrote: post #573
josephg wrote: post #560

Earlier quoted context omitted.

Apparently it found this attack more or less immediately. It seems strange to attack a service like this right after it actively helped keep people safe from malware. I'm sure its not perfect, but it sounds like they deserve to take a victory lap.

I don’t think celebrating a company who has a distinct interest in prolonging a problem while they profit off it is a good thing, no.

They're profiting off helping to solve the problem through early warning and detection. And by keeping their customers safe from stuff like this.

Seems good to me. I want more attention and more tooling around this problem. You seem mad at them for helping solve a real problem?

Re: NPM debug and chalk packages compromised

#593

Post by albedoa »

fn-mote wrote: post #466
dmitrygr wrote: post #404

Earlier quoted context omitted.

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

Nah… Everybody knows npm is a gaping security issue waiting to happen. Repeatedly. It’s convenient, so it’s popular. Many people also don’t vendor their own dependencies, which would slow down the spread at the price of not being instantly up to date.

> Nah…

I mean, I believe you, but the person you are replying to obviously believes that they are similar. Could you explain the significant differences?

Re: NPM debug and chalk packages compromised

#594

Post by Mawr »

ATechGuy wrote: post #555
33a wrote: post #498

Earlier quoted context omitted.

We use a mix of static analysis and AI. Flagged packages are escalated to a human review team. If we catch a malicious package, we notify our users, block installation and report them to the upstream package registries. Suspected malicious packages that have not yet been reviewed by a human are blocked for our users, but we don't try to get them removed until after they have been triaged by a human. In this incident,…

You rely on LLMs riddled with hallucinations for malware detection?

"LLM bad"

Very insightful.

Re: NPM debug and chalk packages compromised

#595

Post by crabmusket »

palmfacehn wrote: post #589
crabmusket wrote: post #441

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…

A batteries included standard lib included with the runtime is one approach. Yes, you would know upfront the version which the browser implements. From there you could dynamically load a polyfill or prompt the user to upgrade. Alternatively, because there are now (often ridiculous) build systems and compilation steps, we might expect similar behavior to other compiled binaries. Instead we get the worst of both worlds…

> A purely compiled WASM approach

I would love to see if a browser could like... "disaggregate" itself into WASM modules. E.g. why couldn't new JS standards be implemented in WASM and hot loaded into the browser itself from a trusted distributor when necessary?

Missing CSS Level 5 selectors? Browser goes and grabs the reference implementation from the W3C.

Low-level implementations could replace these for the browsers with the most demanding performance goals, but "everyone else" could benefit from at least remaining spec compatible?

(I guess this begs the question of "what's the API that these WASM modules all have to conform to" but I dunno, I find it an interesting thought.)

Re: NPM debug and chalk packages compromised

#596

Post by vasco »

tbossanova wrote: post #523
naikrovek wrote: post #312

Earlier quoted context omitted.

I feel like you were trying to help here, but anyone can do this for themselves. Providing information in this way sort of indicates that you don't believe that the person you're replying to can do it on their own, and for that reason it's considered rude.

I see what you mean, but I actually think there is a place for copy/pasting AI responses. I think of it as a kind of cache, surely a HN comment being served to n users means less resources used and faster access than if all n did their own AI query. But then of course you don’t get exactly your preference e.g. you might prefer a terser response than what is pasted here. Interesting to see how the etiquette around thi…

If you ever wanted to share an AI response, you probably should share your prompt, not the response. But likely you should not share anything, for the reasons already explained. Your argument about saving energy makes zero sense if you have any understanding of orders of magnitude but I won't share what AI says about it.

Re: NPM debug and chalk packages compromised

#597

Post by jffry »

Already__Taken wrote: post #479
0cf8612b2e1e wrote: post #299

Earlier quoted context omitted.

Not a web guy, but that seems a bonkers default. I would have naively assumed a lockfile would be used unless explicitly ignored.

We didn't get locking until npm v5 (some memory and googling, could be wrong.) And it took a long time to do everything you'd think you want. Changing the main command `npm install` after 7 years isn't really "stable". Anyway didn't this replace versions, so locking won't have helped either?

> Anyway didn't this replace versions, so locking won't have helped either?

The lockfile includes a hash of the tarball, doesn't it?

Re: NPM debug and chalk packages compromised

#598

Post by yawaramin »

junon wrote: post #473
sneak wrote: post #472

Earlier quoted context omitted.

Can happen to anyone… who doesn’t use password manager autofill and unphishable 2FA like passkeys. Most people who get phished aren’t using password managers, or they would notice that the autofill doesn’t work because the domain is wrong. Additionally, TOTP 2FA (numeric codes) are phishable; stop using them when U2F/WebAuthn/passkeys are available. I have never been phished because I follow best practices. Most peop…

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'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 getting phished.

Re: NPM debug and chalk packages compromised

#599

Post by Culonavirus »

ATechGuy wrote: post #555
33a wrote: post #498

Earlier quoted context omitted.

We use a mix of static analysis and AI. Flagged packages are escalated to a human review team. If we catch a malicious package, we notify our users, block installation and report them to the upstream package registries. Suspected malicious packages that have not yet been reviewed by a human are blocked for our users, but we don't try to get them removed until after they have been triaged by a human. In this incident,…

You rely on LLMs riddled with hallucinations for malware detection?

He literally said "Flagged packages are escalated to a human review team." in the second sentence. Wtf is the problem here?

Re: NPM debug and chalk packages compromised

#600

Post by jondwillis »

hsbauauvhabzb wrote: post #518
33a wrote: post #499

Earlier quoted context omitted.

When we find malware on any registry (npm, rubygems, pypi or otherwise), we immediately report it to the upstream registry and try to get it taken down. This helps reduce the blast radius from incidents like this and mitigates the damage done to the entire ecosystem. You can call it ambulance chasing, but I think this is a good thing for the whole software ecosystem if people aren't accidentally bundling cryptosteale…

So instead you prolong the problem while making money? Nice!

I’m all for thinking about second, or third, or fourth order effects of behavior, but unless you have proof that Socket is doing something like lobbying that developers keep using NPM against their own best interests, frankly, I don’t know what your point here is.
Post reply on HN