←back to thread

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

(socket.dev)
1208 points jamesberthoty | 5 comments | 16 Sep 25 11:22 UTC | HN request time: 0.001s | source
Show context
homebrewer ◴[16 Sep 25 12:14 UTC] No.45261199[source]▶
When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages, and 1200 lines of JavaScript".

Not much has changed since then. The best counter-example I know is esbuild, which is a fully featured bundler/minifier/etc that has zero external dependencies except for the Go stdlib + one package maintained by the Go project itself:

https://www.npmjs.com/package/esbuild?activeTab=dependencies

https://github.com/evanw/esbuild/blob/755da31752d759f1ea70b8...

Other "next generation" projects are trading one problematic ecosystem for another. When you study dependency chains of e.g. biomejs and swc, it looks pretty good:

https://www.npmjs.com/package/@biomejs/biome/v/latest?active...

https://www.npmjs.com/package/@swc/types?activeTab=dependenc...

Replacing the tire fire of eslint (and its hundreds to low thousands of dependencies) with zero of them! Very encouraging, until you find the Rust source:

https://github.com/biomejs/biome/blob/a0039fd5457d0df18242fe...

https://github.com/swc-project/swc/blob/6c54969d69551f516032...

I think as these projects gain more momentum, we will see similar things cropping up in the cargo ecosystem.

Does anyone know of other major projects written in as strict a style as esbuild?

replies(6): >>45261429 #>>45261662 #>>45261809 #>>45264078 #>>45267771 #>>45267783 #
cookiengineer ◴[16 Sep 25 12:40 UTC] No.45261429[source]▶
Part of the reason of my switch to using Go as my primary language is that there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x.

These kind of projects usually are pretty great because they aim to work with CGO_ENABLED=0 so the libs are very portable and work with different syscall backends.

Additionally I really like to go mod vendor my snapshot of dependencies which is great for short term fixes, but it won't fix the cause in the long run.

However, the go ecosystem is just as vulnerable here because of lack of signing off package updates. As long as there's no verification possible end-to-end when it comes to "who signed this package" then there's no way this will get better.

Additionally most supply chaib attacks focussed on the CI/CD infrastructure in the past, because they are just as broken with just as many problems. There needs to be a better CI/CD workflow where signing keys don't have to be available on the runners themselves, otherwise this will just shift the attack surface to a different location.

In my opinion the package managers are somewhat to blame here, too. They should encourage and mandate gpg signatures, and especially in git commits when they rely on git tags for distribution.

replies(1): >>45262299 #
juliend2 ◴[16 Sep 25 13:53 UTC] No.45262299[source]▶
> there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x.

I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture.

IMO, it might be due to the fact that Go mod came rather late in the game, while NPM was introduced near the beginning of NodeJS. But it might be more related to Go's target audience being more low-level, where such tools are less ubiquitous?

replies(5): >>45262496 #>>45262505 #>>45262822 #>>45263409 #>>45263724 #
1. Ajedi32 ◴[16 Sep 25 14:34 UTC] No.45262822[source]▶
> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture.

I think it's because the final deliverable of Go projects is usually a single self-contained binary executable with no dependencies, whereas with Node the final deliverable is usually an NPM package which pulls its dependencies automatically.

replies(2): >>45263431 #>>45263465 #
2. yunohn ◴[16 Sep 25 15:13 UTC] No.45263431[source]▶
> usually an NPM package which pulls its dependencies automatically

Built applications do not pull dependencies at runtime, just like with golang. If you want to use a library/source, you pull in all the deps, again just like golang.

replies(1): >>45263537 #
3. int_19h ◴[16 Sep 25 15:16 UTC] No.45263465[source]▶
With Node the final deliverable is an app that comes packaged with all its dependencies, and often bundled into a single .js file, which is conceptually the same as a single binary produced by Go.
replies(1): >>45263585 #
4. Ajedi32 ◴[16 Sep 25 15:22 UTC] No.45263537[source]▶
Not at runtime no, but at install time yes. In contrast, with Go programs I often see "install time" being just `curl $url > /usr/local/bin/my_application` which is basically never the case with Node (for obvious reasons).
5. Ajedi32 ◴[16 Sep 25 15:25 UTC] No.45263585[source]▶
Can you give an example? While theoretically possible I almost never see that in Node projects. It's not even very practical because even if you do cram everything into a single .js file you still need an external dependency on the Node runtime.