Most active commenters
  • koakuma-chan(7)

←back to thread

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

(socket.dev)
1208 points jamesberthoty | 26 comments | 16 Sep 25 11:22 UTC | HN request time: 2.751s | source | bottom
Show context
codemonkey-zeta ◴[16 Sep 25 11:56 UTC] No.45261026[source]▶
I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem.

These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probably be faster and less janky anyway.

replies(18): >>45261086 #>>45261121 #>>45261140 #>>45261165 #>>45261220 #>>45261265 #>>45261285 #>>45261457 #>>45261571 #>>45261702 #>>45261970 #>>45262601 #>>45262619 #>>45262851 #>>45267210 #>>45268405 #>>45269073 #>>45273081 #
tarruda ◴[16 Sep 25 12:11 UTC] No.45261165[source]▶
AFAICT, the only thing this attack relies on, is the lack of scrutiny by developers when adding new dependencies.

Unless this lack of scrutiny is exclusive to JavaScript ecosystem, then this attack could just as well have happened in Rust or Golang.

replies(6): >>45261185 #>>45261224 #>>45261255 #>>45262968 #>>45267488 #>>45274187 #
1. hsbauauvhabzb ◴[16 Sep 25 12:13 UTC] No.45261185[source]▶
JavaScript does have some pretty insane dependency trees. Most other languages don’t have anywhere near that level of nestedness.
replies(4): >>45261308 #>>45261471 #>>45261685 #>>45261896 #
2. staminade ◴[16 Sep 25 12:25 UTC] No.45261308[source]▶
Don't they?

I just went to crates.io and picked a random newly updated crate, which happened to be pixelfix, which fixes transparent pixels in pngs.

It has six dependencies and hundreds of transient dependencies, may of which appear to be small and highly specific a la left-pad.

https://crates.io/crates/pixelfix/0.1.1/dependencies

Maybe this package isn't representative, but it feels pretty identical to the JS ecosystem.

replies(1): >>45261384 #
3. koakuma-chan ◴[16 Sep 25 12:34 UTC] No.45261384[source]▶
It depends on `image` which in turn depends on a number of crates to handle different file types. If you disable all `image` features, it only has like 5 dependencies left.
replies(1): >>45261462 #
4. staminade ◴[16 Sep 25 12:44 UTC] No.45261462{3}[source]▶
And all those 5 remaining dependencies have lots of dependencies of their own. What's your point?
replies(1): >>45261588 #
5. cxr ◴[16 Sep 25 12:45 UTC] No.45261471[source]▶
It's not possible for a language to have an insane dependency tree. That's an attribute of a codebase.
replies(2): >>45262259 #>>45262954 #
6. koakuma-chan ◴[16 Sep 25 12:55 UTC] No.45261588{4}[source]▶
> What's your point?

Just defending Rust.

> 5 remaining dependencies have lots of dependencies of their own.

Mostly well-known crates like rayon, crossbeam, tracing, etc.

replies(1): >>45262478 #
7. rixed ◴[16 Sep 25 13:03 UTC] No.45261685[source]▶
This makes little sense. Any popular language with a lax package management culture will have the exact same issue, this has nothing to do with JS itself. I'm actually doing JS quasi exclusively these days, but with a completely different tool chain, and feel totally unconcerned by any of these bi-weekly NPM scandals.
8. BrouteMinou ◴[16 Sep 25 13:21 UTC] No.45261896[source]▶
Rust is working on that. It's not far behind right now, leave it a couple of years.
9. WD-42 ◴[16 Sep 25 13:49 UTC] No.45262259[source]▶
Maybe the language should have a standard library then.
replies(1): >>45262486 #
10. johnisgood ◴[16 Sep 25 14:09 UTC] No.45262478{5}[source]▶
You cannot defend Rust if this is reality.

Any Rust project I have ever compiled pulled in over 1000 dependencies. Recently it was Zed with its >2000 dependencies.

replies(1): >>45262797 #
11. skydhash ◴[16 Sep 25 14:10 UTC] No.45262486{3}[source]▶
C library is smaller than Node.js (you won’t have HTTP). What C have is much more respectable libraries. If you add libcurl or freetype to your project, it won’t pull the whole jungle with them.
replies(2): >>45263387 #>>45266734 #
12. koakuma-chan ◴[16 Sep 25 14:33 UTC] No.45262797{6}[source]▶
I think it's justified for Zed. It does a lot of things.
replies(1): >>45264272 #
13. orbital-decay ◴[16 Sep 25 14:42 UTC] No.45262954[source]▶
Modern programming languages don't exist in a vacuum, they are tied to the existing codebase and libraries.
replies(2): >>45264151 #>>45267432 #
14. int_19h ◴[16 Sep 25 15:10 UTC] No.45263387{4}[source]▶
What C doesn't have is an agreed-upon standard package manager. Which means that any dependency - including transitive ones! - requires some effort on behalf of the developer to add to the build. And that, in turn, puts pressure on library authors to avoid dependencies other than a few well-established libraries (like libpng or GLib),
15. cxr ◴[16 Sep 25 16:08 UTC] No.45264151{3}[source]▶
Whatever you're trying to say, you aren't.
16. rudedogg ◴[16 Sep 25 16:17 UTC] No.45264272{7}[source]▶
Zed isn’t special, I doubt Sublime Text has thousands of dependencies. It’s a language/culture problem.

Edit: Ghostty is a good counter-example that is open source. https://github.com/ghostty-org/ghostty/tree/main/pkg

replies(1): >>45266706 #
17. koakuma-chan ◴[16 Sep 25 19:23 UTC] No.45266706{8}[source]▶
Zed is closer to IntelliJ or VSCode than to Sublime Text.
replies(1): >>45270137 #
18. koakuma-chan ◴[16 Sep 25 19:25 UTC] No.45266734{4}[source]▶
You can add curl to a Rust project too.
replies(1): >>45270294 #
19. kelnos ◴[16 Sep 25 20:20 UTC] No.45267432{3}[source]▶
Sort of, but I don't really buy this argument. Someone could go and write the "missing JS stdlib" library that has no dependencies of its own. They could adopt release policies that reduce the risk of successful supply chain attacks. Other people could depend on it and not suffer deep dependency trees.

JS library authors in general could decide to write their own (or carefully copy-paste from libraries) utility functions for things rather than depend on a huge mess of packages. This isn't always a great path; obviously reinventing the wheel can come with its own problems.

So yes, I'd agree that the ecosystem encourages JS/TS developers to make use of the existing set of libraries and packages with deep dependency trees, but no one is holding a gun to anyone's head. There are other ways to do it.

20. biggusdickus69 ◴[17 Sep 25 00:38 UTC] No.45270137{9}[source]▶
In the amount of bloat, yes.
replies(1): >>45277037 #
21. aakkaakk ◴[17 Sep 25 01:01 UTC] No.45270294{5}[source]▶
But why, when reqwest is enough for 99% of cases.
replies(3): >>45270603 #>>45278194 #>>45281451 #
22. koakuma-chan ◴[17 Sep 25 01:45 UTC] No.45270603{6}[source]▶
It's bloated.
23. johnisgood ◴[17 Sep 25 15:29 UTC] No.45277037{10}[source]▶
It is also important to note that this is not specific to Zed. As someone else have mentioned, it is a cultural problem. I picked Zed as an example because that is what I compiled the last time, but it is definitely not limited to Zed. There are many Rust projects that pull in over 1000 dependencies and they do much less than Zed.
replies(1): >>45279323 #
24. WD-42 ◴[17 Sep 25 16:42 UTC] No.45278194{6}[source]▶
It requires Tokio, and believe it or not there are actual cases for non-async rust. So you can't use it in that case.
25. koakuma-chan ◴[17 Sep 25 18:12 UTC] No.45279323{11}[source]▶
Yeah tbh one time I had a Rust job and their back-end had like 700-800 dependencies.
26. bigstrat2003 ◴[17 Sep 25 21:11 UTC] No.45281451{6}[source]▶
Because it requires using async, and for most programs async is not worth the extra effort (plus very heavy dependency in the form of Tokio).