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 probab…
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.
Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
71–80 of 1001 posts
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#72Earlier quoted context omitted.
> How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user? Zero? How many developers have plain-text tokens lying around on disk? Avoiding that been hammered into me from every developer more senior than me since I got involved with professional software development.
How do you manage secrets for your projects?
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#73I knew npm was a train wreck when I first used it years ago and it pulled in literally hundreds of dependencies for a simple app. I avoid anything that uses it like the plague.
I can tell a lot about a dev by the fact that they single out npm/js for this supply chain issue.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#74I knew npm was a train wreck when I first used it years ago and it pulled in literally hundreds of dependencies for a simple app. I avoid anything that uses it like the plague.
I can tell a lot about a dev by the fact that they single out npm/js for this supply chain issue.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#75Earlier quoted context omitted.
Rendering template partials server-side and fetching/loading content updates with HTMX in the browser seems like the best of all worlds at this point.
Until you need to write JavaScript?
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#76Earlier quoted context omitted.
as much as i can yes. I try to avoid JS, as it is a horrible language, by design. That does include TS, but it at least is useable, but barely - because it still tied to JS itself.
Off-topic, but I love how different programmers think about things, and how nothing really is "correct" or "incorrect". Started thinking about it because for me it's the opposite, JS is an OK and at least usable language, as long as you avoid TS and all that comes with it. Still, even I who'd call myself a JavaScript developer also try to avoid desktop applications made with just JS :)
It is full of gotchas that serves 0 purpose nowadays.
Also remember that it is basically a Lisp wearing Java skin on top, originally designed in less than 2 weeks.
Typescript is one of few things that puts safety barrier and sane static error checking that makes JS bearable to use - but it still has to fall down to how JS works in the end so it suffers from same core architectural problems.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#77We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?
It's just javascript being javascript.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#78Earlier quoted context omitted.
> New day, new npm malware. Sigh.. This. But the problem seems to go way deeper than npm or whatever package manager is used. I mean, why is anyone consuming a package like colors or tinycolors? Do projects really need to drag in a random dependency to handle these usecases?
So rather than focusing on how Microsoft/npm et al can prevent similar situations in the future, you chose to think about what relevance/importance each individual package has? There will always be packages that for some people are "but why?" but for others are "thank god I don't have to deal with that myself". Sure, colors and whatnot are tiny packages we probably could do without, but what are you really suggesting…
But the issue isn't just about the “thank god I don't have to deal with that myself” perspective. It's more about asking: do you actually need a dependency, or do you simply want it?
A lot of developers, especially newer ones, tend to blur that distinction. The result is an inflated dependency tree that unnecessarily increases the attack surface for malware.
The "ship fast at all costs" mindset that dominates many startups only makes this worse, since it encourages pulling in packages without much thought to long-term risk.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#79I'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 probab…
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.
Languages without package managers have a lot more friction to pull in dependencies. You usually rely on the operating system and its package-manager-humans to provide your dependencies; or on primitive OSes like Windows or macOS, you package the dependencies with your application, which involves integrating them into your build and distribution systems. Both of those involve a lot of manual, human effort, which reduces the total number of dependencies (attack points), and makes supply-chain issues like this more likely to be noticed.
The language package managers make it trivial to pull in dozens or hundreds of dependencies, straight from some random source code repository. Your dependencies can add their own dependencies, without you ever knowing. When you have dozens or hundreds of unvetted dependencies, it becomes trivial for an attacker to inject code they control into just one of those dependencies, and then it's game over for every project that includes that one dependency anywhere in their chain.
It's not impossible to do that in the OS-provided or self-managed dependency scenario, but it's much more difficult and will have a much narrower impact.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#80Earlier quoted context omitted.
Apparently Maven has 61.9M indexed packages. As Java has a decent standard lib, mini libs like leftpad are not contributing to this count. NPM has 3.1M packages. Many are trivially simple. Those stats would suggest that NPM has disproportionately more issues than other services. I would argue that is only one of the many issues with the JS/TS/NPM ecosystem. Many of the other problems have been normalized. The constan…
> Apparently Maven has 61.9M indexed packages. Where did you see that number? Maven central says it has about 18 million [1] packages. Maybe with all versions of those 18 million packages there are about 62 million artifacts? While the Java ecosystem is vastly larger, in Java (with Maven, Gradle, Bazel, etc.) it is not common to use really small libraries. So you end up with vastly less transitive dependencies in you…