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

351–360 of 1001 posts

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

#351

Post by kirici »

rlpb wrote: post #303
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…

There is another related growing problem in my recent observation. As a Debian Developer, when I try to audit upstream changes before pulling them in to Debian, I find a huge amount of noise from tooling, mostly pointless. This makes it very difficult to validate the actual changes being made. For example, an upstream bumps a version of a lint tool and/or changes style across the board. Often these are labelled "chor…

I'm using difftastic, it cuts down a whole lot of the noise

https://difftastic.wilfred.me.uk/

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

#352

Post by Klonoar »

johnisgood wrote: post #208
WD-42 wrote: post #169

Earlier quoted context omitted.

I mostly agree. But NPM is special, in that the exposure is so much higher. The hypothetical python+htmx web app might have 10s of dependencies (including transitive) whereas your typical Javascript/React will have 1000s. All an attacker needs to do is find one of many packages like TinyColor or Leftpad or whatever and now loads of projects are compromised.

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.

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

#353

Post by kibwen »

weinzierl wrote: post #117
lucideer wrote: post #81

Earlier quoted context omitted.

> I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so. What's especially concerning is I see this take in the security industry: mitigations put in place to…

Which mitigations specifically are in npm but not in crates.io? As far as I know crates.io has everything that npm has, plus - strictly immutable versions[1] - fully automated and no human in the loop perpetual yanking - no deletions ever - a public and append only index Go modules go even further and add automatic checksum verification per default and a cryptographic transparency log. Contrast this with docker hub f…

> Go modules go even further and add automatic checksum verification per default

Cargo lockfiles contain checksums and Cargo has used these for automatic verification since time immemorial, well before Go implemented their current packaging system. In addition, Go doesn't enforce the use of go.sum files, it's just an optional recommendation: https://go.dev/wiki/Modules#should-i-commit-my-gosum-file-as... I'm not aware of any mechanism which would place Go's packaging system at the forefront of mitigation implementations as suggested here.

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

#354

Post by kibwen »

woodruffw wrote: post #107
lucideer wrote: post #81

Earlier quoted context omitted.

> I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so. What's especially concerning is I see this take in the security industry: mitigations put in place to…

Could you say more about what mitigations you’re thinking of? I ask because think the directionality is backwards here: I’ve been involved in packaging ecosystem security for the last few years, and I’m generally of the opinion that PyPI has been ahead of the curve on implementing mitigations. Specifically, I think widespread trusted publishing adoption would have made this attack less effective since there would be…

> PyPI has been ahead of the curve on implementing mitigations

Indeed, crates.io implemented PyPI's trusted publishing and explicitly called out PyPI as their inspiration: https://blog.rust-lang.org/2025/07/11/crates-io-development-...

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

#355

Post by Lumping6371 »

lithos wrote: post #83
zachrip wrote: post #38

Earlier quoted context omitted.

I can tell a lot about a dev by the fact that they single out npm/js for this supply chain issue.

Just more engineering leaning than you. Actual engineers have to analyze their supply chains, and so makes sense they would be baffled by NPM dependency trees that utterly normal projects grow into in the JavaScript ecosystem.

Good thing that at scale, private package repositories or even in-house development is done. Personally, I would argue that an engineer unable to tell apart perfect from good, isn't a very good engineer in my book, but some engineers are unable to make compromises.

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

#356

Post by cobbal »

__alexs wrote: post #243
rs999gti wrote: post #238

Earlier quoted context omitted.

> supply chain attacks You all really need to stop using this term when it comes to OSS. Supply chain implies a relationship, none of these companies or developers have a relationship with the creators other than including their packages. Call it something like "free code attacks" or "hobbyist code attacks."

I know CrowdStrike have a pretty bad reputation but calling them hobbyists is a bit rude.

I'm sure no offense was intended to hobbyists, but it was indeed rude

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

#357

Post by marcosdumay »

godshatter wrote: post #314
moi2388 wrote: post #227

Earlier quoted context omitted.

Good luck with nr 1 in the js ecosystem and its 30k dependencies 50 branches deep per package

As an outsider looking in as I don't deal with NPM on a daily basis, the 30k dependencies going 50 branches deep seems to be the real problem here. Code reuse is an admiral goal but this seems absurd. I have no idea if these numbers are correct or exaggerations but from my limited time working with NPM a year or two ago it seems like it's a definite problem. I'm in the C ecosystem mostly. Is one NPM package the equiv…

> Is one NPM package the equivalent of one object file?

No. The closest thing to a package (on almost every language) is an entire library.

> Can NPM packages call internal functions for their dependencies instead of relying so heavily on bringing in so many external ones?

Yes, they can. They just don't do it.

> Doesn't bringing in so many dependencies lead to a lot of dead code and much larger codebases then necessary?

There aren't many unecessary dependencies, because the number of direct dependencies on each package is reasonable (on the order of 10). And you don't get a lot of unecessary code because the point of tiny libraries is to only import what you need.

Dead code is not the problem, instead the JS mentality evolved that way to minimize dead code. The problem is that dead code is actually not that much of an issue, but dependency management is.

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

#358

Post by ebfe1 »

Anyone know if there is a public events feed/firehouse for npm ecosystem system? Similar to GitHub public events feed?

We, at ClickHouse, love big data and it would be super cool download and analyse patterns of all these data & provide some tooling to help with combatting this wide spread issue.

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

#359

Post by lyu07282 »

sfn42 wrote: post #168
hoppp wrote: post #135

Earlier quoted context omitted.

Lucky you. I keep coming back to it because jobs and even for desktop apps a native webview beats everything else. We fcked up with js, big time and its with us forever now

I was hyped for wasm because i thought it was supposed to solve this problem, allowing any programming language to be compiled to run in browsers. But apparently they only made it do like 95% of what JS does so you can't actually replace js with it. To me it seems like a huge blunder. I don't give a crap about making niche applications a bit faster, but freeing the web from the curse of JS would be absolutely huge. A…

That 5% of js glue code necessary right now is just monumentally difficult to get rid of, it's like a binary serialization / interface (ABI) of all DOM/BOM APIs and these APIs are huge, dynamic, callback-heavy and object-oriented. It's much easier to have that glue compiler generated, which you can already do right now (you can write your entire web app in rust if you want):

https://github.com/wasm-bindgen/wasm-bindgen https://docs.rs/web-sys/latest/web_sys/

This is also being worked on, in the future this 5% glue might eventually entirely disappear:

> Designed with the "Web IDL bindings" proposal in mind. Eventually, there won't be any JavaScript shims between Rust-generated wasm functions and native DOM methods

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

#360

Post by debo_ »

brundolf wrote: post #235

Last week someone wrote a blog post saying "We dodged a bullet" because it was only a browser-based crypto wallet scrape Guess we didn't dodge this one

We didn't really dodge a bullet. We put a bullet named 'node' in the cylinder of a revolver, spun it, pointed the gun at our head, and pulled the trigger. We just happened to be lucky enough that we got an empty chamber.
Post reply on HN