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

551–560 of 1001 posts

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

#551

Post by kelnos »

drdaeman wrote: post #515
CraftThatBlock wrote: post #413

Earlier quoted context omitted.

pnpm just added this: https://pnpm.io/blog/releases/10.16

This sounds nice in theory, but does it really solve the issue? I think that if no one's installing that package then no one is noticing the malware and no one is reporting that package either. It merely slightly improves the chances that author would notice a version they didn't release, but this doesn't work if author is not particularly actively working the compromised project.

No, it doesn't solve the issue, but it probably helps.

And I agree that if everyone did this, it would slow down finding issues in new releases. Not really sure what to say to that... aside from the selfish idea that if I do it, but most other people don't, it won't affect me.

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

#553

Post by kelnos »

TZubiri wrote: post #509
kelnos wrote: post #405

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…

Install less dependencies, code more.

Sure, and I do that whenever I can. But I'm not going to write my own react, or even my own react-hook-form. I'm not going to rewrite stripe-js. Looking through my 16 direct dependencies -- that pull in a total of 653 packages, jesus christ -- there's only one of them that I'd consider writing myself (js-cookie) in order to reduce my dependency count. The rest would be a maintenance burden that I shouldn't have to take on.

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

#554

Post by foxfired »

My problem is that, in the JS ecosystem, every single time you go through a CI/CD pipeline, you redownload everything. We should only download the first time and with the versions that are known to work. When we make a manual update to version, than only that should be downloaded once more.

I just checked one of our repos right now and it has a 981 packages. It's not even realistic to vet the packages or to know which one is compromised. 99% of them are dependencies of dependencies. Where do we even get started?

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

#555

Post by homebrewer »

kelnos wrote: post #405

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…

Don't update your dependencies manually. Setup renovate to do it for you, with a delay of at least a couple of weeks, and enable vulnerability alerts so that it opens PRs for publicly known vulnerabilities without delay

https://docs.renovatebot.com/configuration-options/#minimumr...

https://docs.renovatebot.com/presets-default/#enablevulnerab...

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

#556

Post by kelnos »

eschneider wrote: post #449
kelnos wrote: post #405

As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…

If you pull something into your project, you're responsible for it working. Full stop. There are a lot of ways to manage/control dependencies. Pick something that works best for you, but be aware, due diligence, like maintenance is ultimately your responsibility.

Oh I'm well aware, and that's the problem. Unfortunately none of the available options hit anything close to the sweet spot that makes me comfortable.

I don't think this is a particularly unreasonable take; I'm a relative novice to the JS ecosystem, and I don't feel this uncomfortable taking on dependencies as I do in pretty much any other ecosystem I participate in, even those (like Rust) where the dependency counts can be high.

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

#557

Post by amarshall »

foxfired wrote: post #554

My problem is that, in the JS ecosystem, every single time you go through a CI/CD pipeline, you redownload everything. We should only download the first time and with the versions that are known to work. When we make a manual update to version, than only that should be downloaded once more. I just checked one of our repos right now and it has a 981 packages. It's not even realistic to vet the packages or to know whic…

Redownloading everything isn’t a risk when the lock file contains a hash of the download on first update.

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

#558

Post by brw »

foxfired wrote: post #554

My problem is that, in the JS ecosystem, every single time you go through a CI/CD pipeline, you redownload everything. We should only download the first time and with the versions that are known to work. When we make a manual update to version, than only that should be downloaded once more. I just checked one of our repos right now and it has a 981 packages. It's not even realistic to vet the packages or to know whic…

Isn't that what lockfiles are for? By default `npm i` downloads exactly the versions specified in your lockfile, and only resolves the latest versions matching the ranges specified in package.json if no lockfile exists. But CI/CD pipelines should definitely be using `npm ci` instead, which will only install packages from a lockfile and throws an error if it doesn't exist.

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

#559

Post by whstl »

ncruces wrote: post #511
jen20 wrote: post #471

Earlier quoted context omitted.

Zero-external-dependency Go apps are far more feasible than Rust or Node, simply because of the size and quality of the standard library.

Just the other day someone argued with me that it was reasonable for Limbo (the SQLite Rust rewrite) to have 3135 dependencies (of those, 1313 Rust dependencies). https://github.com/tursodatabase/turso/network/dependencies

This is incredible.

At this rate, there's a non-zero chance that one of the transitive dependencies is SQLite itself.

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

#560

Post by homebrewer »

foxfired wrote: post #554

My problem is that, in the JS ecosystem, every single time you go through a CI/CD pipeline, you redownload everything. We should only download the first time and with the versions that are known to work. When we make a manual update to version, than only that should be downloaded once more. I just checked one of our repos right now and it has a 981 packages. It's not even realistic to vet the packages or to know whic…

Generate builder images and reuse them. It shaves minutes off each CI job with projects I'm working on and is non-optional because we're far from all major datacenters.

Or setup a caching proxy, whatever is easier for your org. I've had good experience with nexus previously, it's pretty heavy but very configurable, can introduce delays for new versions and check public vulnerability databases for you.

It's purely an efficiency problem though, nothing to do with security, which is covered by lock files.

Post reply on HN