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

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

socket.dev

Post reply on HN
Print view View original

361–370 of 1001 posts

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#361

Post by ForHackernews »

noodlesUK wrote: post #299
btown wrote: post #252

Earlier quoted context omitted.

I'd like to think there are ways to do this and keep things decentralized. Things like: Once a package has more than [threshold] daily downloads for an extended period of time, it requires 2FA re-auth/step-up on two separate human-controlled accounts to approve any further code updates. Or something like: for these popular packages, only a select list of automated build systems with reproducible builds can push direc…

I think that we should impose webauthn 2fa on all npm accounts as the only acceptable auth method if you have e.g., more than 1 million total downloads. Someone could pony up the cash to send out a few thousand yubikeys for this and we'd all be a lot safer.

PyPI already has this. It was a little bit annoying when they imposed stricter security on maintainers, but I can see the need.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#362

Post by ForHackernews »

Yasuraka wrote: post #292
Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

> NPM, Python, Rust, Go, Ruby all suffer from this problem, because they have centralized and open package repositories Can you point me to Go's centralized package repository?

https://github.com/

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#363

Post by LtWorf »

Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

> The general solution is to do what Debian does.

If you ask these people, distributions are terrible and need to die.

Python even removed PGP signatures from Pypi because now attestation happens by microsoft signing your build on the github CI and uploading it directly to pypi with a never expiring token. And that's secure, as opposed to the developer uploading locally from their machine.

In theory it's secure because you see what's going in there on git, but in practice github actions are completely insecure so malware has been uploaded this way already.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#364

Post by LtWorf »

btown wrote: post #252
Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

I'd like to think there are ways to do this and keep things decentralized. Things like: Once a package has more than [threshold] daily downloads for an extended period of time, it requires 2FA re-auth/step-up on two separate human-controlled accounts to approve any further code updates. Or something like: for these popular packages, only a select list of automated build systems with reproducible builds can push direc…

> two separate human-controlled accounts to approve any further code updates.

Except most projects have 1 developer… Plus, if I develop some project for free I don't want to be wasting time and work for free for large rich companies. They can pay up for code reviews and similar things instead of adding burden to developers!

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#365

Post by viraptor »

chrisweekly wrote: post #128
viraptor wrote: post #36

Earlier quoted context omitted.

You can protect yourself using existing tools, but it's not trivial and requires serious custom work. Effectively you want minimal permissions and loud failures. This is something I'm trying to polish for my system now, but the idea is: yarn (and bundler and others) needs to talk only to the repositories. That means yarn install is only allowed outbound connections to localhost running a proxy for packages. It can on…

Why yarn instead of pnpm?

It doesn't matter. It applies the same to all those tools.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#366

Post by LtWorf »

noodlesUK wrote: post #299
btown wrote: post #252

Earlier quoted context omitted.

I'd like to think there are ways to do this and keep things decentralized. Things like: Once a package has more than [threshold] daily downloads for an extended period of time, it requires 2FA re-auth/step-up on two separate human-controlled accounts to approve any further code updates. Or something like: for these popular packages, only a select list of automated build systems with reproducible builds can push direc…

I think that we should impose webauthn 2fa on all npm accounts as the only acceptable auth method if you have e.g., more than 1 million total downloads. Someone could pony up the cash to send out a few thousand yubikeys for this and we'd all be a lot safer.

Pypi did that, i got 2 google keys for free. But I used them literally once, to create a token that never expires and that is what I actually use to upload on pypi.

(I did a talk at minidebconf last year in toulouse about this).

If implemented like this, it's completely useless, since there is actually no 2fa at all.

Anyway the idea of making libre software developers work more is a bad idea. We do it for fun. If we have to do corporate stuff we want a corporate salary to go with.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#367

Post by quotemstr »

perlgeek wrote: post #262
quotemstr wrote: post #160

Jesus Christ. Another one? What the fuck? This isn't a JavaScript problem. What, structurally, stops the same thing happening to PyPI? Or the Rust ecosystem? Or Lisp via QuickLisp? Or CPAN? This whole mess was foreseeable. So what's to be done? Look. Any serious project needs to start vendoring its dependencies. People should establish big, coarse grained meta-distributions like C++ Boost that come from a trustable a…

> This isn't a JavaScript problem. What, structurally, stops the same thing happening to PyPI? Or the Rust ecosystem? Or Lisp via QuickLisp? Or CPAN? For one, NPM has a really sprawling ecosystem where it's normal to have many dependencies. I remember that I once tried to get started with angular, and I did an "init" for an empty project and "compile", and suddenly had half a gigabyte of code lying in my directory. T…

> For one, NPM has a really sprawling ecosystem where it's normal to have many dependencies.

Agreed, but it's a difference of degree (literally --- graph in- and out-degree) not kind.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#368

Post by jonhohle »

silverwind wrote: post #321
Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

So, who is going to audit the thousands of new packages/versions that are published to npm every day? It only works for Debian because they hand-pick popular software.

Maybe NPM should hand pick popular packages and we should get away from this idea of every platform should always let everyone publish. Curation is expensive, but it may be worthwhile for mature platforms.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#370

Post by gedy »

weinzierl wrote: post #137
Meneth wrote: post #91

This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…

In Rust we have cargo vet, where we share these audits and use them in an automated fashion. Companies like Google and Mozilla contribute their audits.

It's too bad MS doesn't own npm, and/or GitHub repositories. Wait
Post reply on HN