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

511–520 of 1001 posts

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

#511

Post by ncruces »

jen20 wrote: post #471
zwnow wrote: post #404

Earlier quoted context omitted.

Unfortunately that's almost the whole industry. Every software project I've seen has an uncountable amount of dependencies. No matter if npm, cargo, go packages, whatever you name.

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

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

#513

Post by worik »

Klonoar wrote: post #352
johnisgood wrote: post #208

Earlier quoted context omitted.

Well, your typical Rust project has over 1000 dependencies, too. Zed has over 2000 in release mode.

Your typical Rust project does not have over 1000 dependencies. Zed is not a typical Rust project; it's a full fledged editor that includes a significant array of features and its own homegrown UI framework .

What is a "typical Rust project", I wonder?

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

#514

Post by kjok »

kilobaud wrote: post #497
pragma_x wrote: post #484

So, other packaging environments have a tendency to slow down the rate of change that enters the user's system. Partly through the labor of re-packaging other people's software, but also as a deliberate effort. For instance: Ubuntu or RedHat. Is anyone doing this in a "security as a service" fashion for JavaScript packages? I imagine a kind of package escrow/repository that only serves known secure packages, and acti…

I've worked in companies that do this internally, e.g., managed pull-through caches implemented via tools like Artifactory, or home-grown "trusted supply chain" automation, i.e., policy enforcement during CI/CD prior to actually consuming a third-party dependency. But what you describe is an interesting idea I hadn't encountered before! I assume such a thing would have lower adoption within a relatively fast-moving e…

> managed pull-through caches implemented via tools like Artifactory

This is why package malware creates news, but enterprises mirroring package registries do not get affected. Building a mirroring solution will be pricey though mainly due to high egress bandwidth cost from Cloud providers.

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

#515

Post by drdaeman »

CraftThatBlock wrote: post #413
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…

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.

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

#517

Post by gmueckl »

hermannj314 wrote: post #474
IshKebab wrote: post #454

Earlier quoted context omitted.

That's very naive. We can do better than this.

Almost all software has a no warranty clause. I am not a lawyer but in pretty plain English every piece of software I have ever used has said exactly that I can fuck off if I expect it to work or do anything. To clarify - I dont think it is naive to assume the software is as-is with all responsibilities on the user since that is exactly what lawyers have made all software companies say that for over 50 years.

Product liability is coming for software. Warranty disclaimers in licenses will be rendered ineffective by the end of 2026 at the latest.

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

#519

Post by erulabs »

duped wrote: post #489
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…

Personally, I go further than this and just never update dependencies unless the dependency has a bug that affects my usage of it. Vulnerabilities are included. It is insane to me how many developers update dependencies in a project regularly. You should almost never be updating dependencies, when you do it should be because it fixes a bug (including a security issue) that you have in your project, or a new feature t…

counterpoint, if the runtime itself (nodejs) has a critical issue, you haven't updated for years, you're on an end-of-life version, and you cannot upgrade because you have dependencies that do not support the new version of the runtime, you're in for a painful day. The argument for updating often is that when you -are- exposed to a vulnerability that you need a fix for, it's a much smaller project to revert or patch that single issue.

Otherwise, I agree with the sentiment that too many people try to update the world too often. Keeping up with runtime updates as often as possible (node.js is more trusted than any given NPM module) and updating only when dependencies are no longer compatible is a better middle ground.

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

#520

Post by BoredPositron »

bpt3 wrote: post #307
SkiFire13 wrote: post #219

Earlier quoted context omitted.

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

What hardware isn't supported by Debian stable that is supported by unstable? Or is this just a "don't use Linux" gripe?

I haven't had much problems prior but Blackwell support was really buggy for the first two weeks.
Post reply on HN