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

421–430 of 1001 posts

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

#421

Post by kelnos »

Maskawanian wrote: post #348
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.

Golang at least gives you the option to easily vendor-ize packages to your local repository. Given what has happened here, maybe we should start doing this more!

This doesn't really help you. I assume Go records the sha1 hash of the commit it grabs, so it doesn't really matter if you vendor it, or download it every time.

The problem comes when you want to upgrade your dependencies. How do you know that they are trustworthy on first use?

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

#422

Post by q3k »

LPisGood wrote: post #387
ronsor wrote: post #331

Earlier quoted context omitted.

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

I don’t understand what benefits this kind of “decentralization” offers

Larger pool of people you can hack/blackmail/coerce into giving you access to millions of systems :)

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

#423

Post by rectang »

ncruces wrote: post #381
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…

This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-…

It's not unreasonable to trust large numbers of trustworthy dependency authors. What we lack are the institutions to establish trust reliably.

If packages had to be cryptographically signed by multiple verified authors from a per-organization whitelist in order to enter distribution, that would cut down on the SPOF issue where compromising a single dev is enough to publish multiple malware-infested packages.

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

#424

Post by AnonymousPlanet »

zwnow wrote: post #404
ncruces wrote: post #381

Earlier quoted context omitted.

This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-…

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.

Every place I ever worked at made sure to curate the dependencies for their main projects. Heck, in some cases that was even necessary for certifications. Web dev might be a wild west, but as soon as your software is installed on prem by hundreds or thousands of paying customers the stakes change.

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

#425

Post by curtisf »

Ajedi32 wrote: post #420
gameman144 wrote: post #416

Earlier quoted context omitted.

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…

If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.

This is true to the extent that you actually _use_ all of the features of a dependency.

You only need to rewrite what you use, which for many (probably most) libraries will be 1% or less of it

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

#426

Post by AlecBG »

Ajedi32 wrote: post #420
gameman144 wrote: post #416

Earlier quoted context omitted.

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…

If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.

Not sure I completely agree as you often use only a small part of a library

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

#427

Post by EGreg »

gameman144 wrote: post #416
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…

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…

Exactly.

I always tried to keep the dependencies to a minimum.

Another thing you can do is lock versions to a year ago (this is what linux distros do) and wait for multiple audits of something, or lack of reports in the wild, before updating.

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

#428

Post by Yasuraka »

matthew16550 wrote: post #417
Yasuraka wrote: post #292

Earlier quoted context omitted.

> 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://pkg.go.dev/ Which works together with https://proxy.golang.org/

That's a doc site and a pull-through cache, neither is a package repository

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

#429

Post by Yasuraka »

ForHackernews wrote: post #362
Yasuraka wrote: post #292

Earlier quoted context omitted.

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

git isn't centralized nor a package repository

For what it's worth, our code is on GitLab

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

#430

Post by edtech_dev »

neutrinobro wrote: post #403
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 lack of an easy method to automatically pull in and manage dependencies in C/C++ is starting to look a lot more like a feature than a bug now.

Author of Odin is also against adding a package manager: https://www.gingerbill.org/article/2025/09/08/package-manage...
Post reply on HN