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

331–340 of 1001 posts

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

#331

Post by ronsor »

thewebguyd wrote: post #320
noodlesUK wrote: post #299

Earlier quoted context omitted.

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.

Why even put a package download count on it? Just require it for everything submitted to NPM. It's not hard.

Because then it's extra hassle and expense for new developers to publish a package, and we're trying to keep things decentralized.

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

#332

Post by kjok »

progbits wrote: post #220
m4r71n wrote: post #203

Earlier quoted context omitted.

Since so many vendors discovered these packages seemingly independently, you'd think that they would share those mechanisms with NPM itself so that those packages would never be published in the first place. But I guess that removes their ability to sell an "early alert" mechanism through their offerings...

NPM is owned by github/microsoft. I'm sure they could afford to buy one of these products or just build their own, but clearly security is not a thing they care about.

Why should MS buy any of these startups when a developer (not any automated tech) found the malware? It looks like these startups did after-the-fact analysis for PR.

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

#333

Post by Liskni_si »

Is there any way to install CLI tools from npmjs without being affected by a recent compromise?

Rust has `cargo install --locked`, which will use the pinned versions of dependencies from the lockfile, and these lockfiles are published for bin packages to crates.io.

But it seems npmjs doesn't allow publishing lockfiles, neither for libraries nor for CLI tools, so if you try to install let's say @google/gemini-cli, it will just pull the latest dependencies that fit the constraints in package.json. Is that true? Is it really this bad? If you try to install a CLI tool on a bad day when half of npmjs is compromised, you're out of luck?

How is that acceptable at all?

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

#334

Post by motorest »

epolanski wrote: post #270
motorest wrote: post #222

Earlier quoted context omitted.

> Why are people using React to write simple ecommerces? What leads you to believe React is not well suited to simple ecommerce sites?

1. It's a solution meant for highly interactive app-like websites, not static-content driven websites like ecommerces. React in this context is just the wrong tool for the problem that will give you a huge array of performance, bugs and ux problems. 2. Extensive ecommerce experience including Disney, Carnival Cruises, Booking, TUI, and some of the European leaders in real estate and professional home building tools a…

> 1. It's a solution meant for highly interactive app-like websites, not static-content driven websites like ecommerces. React in this context is just the wrong tool for the problem that will give you a huge array of performance, bugs and ux problems.

Strongly disagree. React is not about interactivity, but reactivity. If you have to consume an API and update your app based on the responses, React does all the heavy lifting for you without requiring full page reloads.

On top of that, and as a nice perk, React also gives you all the tools you will ever need to optimize perceived performance.

Claiming that a tool designed for reactive programming is not suited for the happy flow of reactive programming is simply fundamentally wrong.

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

#335

Post by junon »

Liskni_si wrote: post #333

Is there any way to install CLI tools from npmjs without being affected by a recent compromise? Rust has `cargo install --locked`, which will use the pinned versions of dependencies from the lockfile, and these lockfiles are published for bin packages to crates.io. But it seems npmjs doesn't allow publishing lockfiles, neither for libraries nor for CLI tools, so if you try to install let's say @google/gemini-cli, it…

Lock files wouldn't work if they were locking transitive dependencies; otherwise the version solver would not have any work to actually do and you'd have many, many versions of the same package rather than a few versions that satisfy all of the version range constraints.

Lots of good ideas since last week, the one I like most being that published packages, especially those that are high in download count, don't actually go publish for a while until after publishing, allowing security scanners to do their thing.

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

#336

Post by debazel »

simiones wrote: post #317
lucideer wrote: post #291

Earlier quoted context omitted.

> in JS land almost everyone uses lax dependency declarations They do, BUT. Dependency versioning schemes are much more strictly adhered to within JS land than in other ecosystems. PyPi is a mishmash of PEP 440, SemVer, some packages incorrectly using one in the format of the other, & none of the 3 necessarily adhering to the standard they've chosen. Other ecosystems are even worse. Also - some ecosystems (PyPi again…

The point is still different. In PyPI, if I put `requests` in my requirements.txt, and I run `pip install -r requirements.txt` every time I do `make build`, I will still only get one version of requests - the latest available the first time I installed it. This severely reduces the attack radius compared to NPM's default, where I would get the latest (patch) version of my dependency every day. And the ecosystem being…

> This severely reduces the attack radius compared to NPM's default, where I would get the latest (patch) version of my dependency every day.

By default npm will create a lock file and give you the exact same version every time unless you manually initiate an upgrade. Additionally you could even remove the package-lock.json and do a new npm install and it still wouldn't upgrade the package if it already exists in your node_modules directory.

Only time this would be true is if you manually bump the version to something that is incompatible, or remove both the package-lock.json and your node_modules folder.

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

#337

Post by veber-alex »

SkiFire13 wrote: post #219
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…

> 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. Unfortunately most people don't want old software that doesn't support newer hardware so most people don't end up using Debian stable.

I don't know why you went with hardware.

Most people don't want old software because they don't want old software.

They want latest features, fixes and performance improvements.

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

#338

Post by junon »

nine_k wrote: post #201
xrisk wrote: post #171

Earlier quoted context omitted.

Seems to be a separate incident?

Separate? Yes. Unrelated? Hard to tell.

It's unrelated in every observable technical way, but related in that it's a bit crazy how often this is happening to npm lately.

I'm glad it wasn't this particular attack that hit me last week.

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

#339

Post by thunky »

mdaniel wrote: post #249
paulddraper wrote: post #225

Earlier quoted context omitted.

Go’s package repository is just GitHub. At the end of the day, it’s all a URL. You’re asking for a blessed set of URLs. You’d have to convince someone to spend time maintaining that.

As hair splitting, that's actually not true: Go's package manager is just version control of which GitHub is currently the most popular hosting. And it also allows redirecting to your own version control via `go mod edit -replace` which leaves the sourcecode reference to GitHub intact, but will install it from wherever you like

How does that relate to the bigger conversation here? Are you suggesting people stop pulling Go packages from GitHub and only use local dependencies?

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

#340

Post by Liskni_si »

junon wrote: post #335
Liskni_si wrote: post #333

Is there any way to install CLI tools from npmjs without being affected by a recent compromise? Rust has `cargo install --locked`, which will use the pinned versions of dependencies from the lockfile, and these lockfiles are published for bin packages to crates.io. But it seems npmjs doesn't allow publishing lockfiles, neither for libraries nor for CLI tools, so if you try to install let's say @google/gemini-cli, it…

Lock files wouldn't work if they were locking transitive dependencies; otherwise the version solver would not have any work to actually do and you'd have many, many versions of the same package rather than a few versions that satisfy all of the version range constraints. Lots of good ideas since last week, the one I like most being that published packages, especially those that are high in download count, don't actua…

In the Rust ecosystem, you only publish lock files for binary crates. So yeah then you get churn like https://github.com/cargo-bins/cargo-binstall/releases/tag/v1... bumping transitive deps, but this churn/noise doesn't exist for library crates - because the lock file isn't published for them.
Post reply on HN