Live data from Hacker News

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

socket.dev

721–730 of 1001 posts

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

#721

Earlier quoted context omitted.

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.

Most dependencies do much more than we need from them. Often it means we only need one or a few functions from them. This means one doesn't need to rewrite whole dependencies usually. Don't use dependencies for things you can trivially write yourself, and use them for cases where it would be too much work to write yourself.

I agree with this but the problem is that a lot of the extra stuff dependencies do is indeed to protect from security issues.

If you’re gonna reimplement only thr code you need from a dependency, it’s hard to know of the stuff you’re leaving out how much is just extra stuff you don’t need and how much might be security fixes that may not be apparent to you but the dependency by virtue of being worked upon and used by many people has fixed.

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

#723

Does anyone know when @ctrl/tinycolor 4.1.1 was released exactly? Trying to figure out the infection timeline relative to my tools.

Never mind, got it:

    ~$ npm view @ctrl/tinycolor --json | grep 4.1.1
       "4.1.1": "2025-09-15T19:52:46.624Z",

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

#724

Earlier quoted context omitted.

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.

Most dependencies do much more than we need from them. Often it means we only need one or a few functions from them. This means one doesn't need to rewrite whole dependencies usually. Don't use dependencies for things you can trivially write yourself, and use them for cases where it would be too much work to write yourself.

I'm using LLMs to write stuff that would normally be in dependencies, mostly because I don't want to learn how to use the dependency, and writing a new one from scratch is really easy with LLMs.

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

#725
post #714

Earlier quoted context omitted.

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.

It IS unreasonable to trust individual humans across the globe in 100+ different jurisdictions pushing code that gets bundled into my application. How can you guarantee a long trusted developer doesn't have a gun pointed to their head by their authoritarian govt? In our B2B shop we recently implemented a process where developers cannot add packages from third party sources - only first party like meta, google, spring…

You've presented your argument as if rebutting mine, but to my mind you've reinforced my first paragraph:

* You are trusting large numbers of trustworthy developers.

* You have established a means of validating their trustworthiness: only trust reputable "first-party" code.

I think what you're doing is a pretty good system. However, there are ways to include work by devs who lack "first-party" bona-fides, such as when they participate in group development where their contributions are consistently audited. Do you exclude packages published by the ASF because some contributions may originate from troublesome jurisdictions?

In any case, it is not necessary to solve the traitorous author problem to address the attack vector right in front of us, which is compromised authors.

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

#726
post #529
post #466

Earlier quoted context omitted.

Sounds like the job for an LLM tool to extract what's actually used from appropriately-licensed OSS modules and paste directly into codebases.

Requiring you to audit both security and robustness on the LLM generated code. Creating two problems, where there was one.

LLMs can do the audits now.

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

#727

Are Python packaging systems like pip exposed to the same risks? Is anybody looking at this?

Not to the same extent as NPM. Because Python has a good standard library and library authors are not deathly afraid of code duplication like JS devs, for example micro libraries like left-pad, is-even etc.

The weird dig at JS as a community is wholly unnecessary. Python as an ecosystem is just as vulnerable to this crap - and they’ve had their own issues with it.

You can reference that and leave the color commentary at the door.

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

#728
post #708

Earlier quoted context omitted.

Indeed. About 26% of the disk space for a freshly-installed copy of pip 25.2 for Python 3.13 comes from https://pypi.org/project/rich/ (and its otherwise-unneeded dependency https://pypi.org/project/Pygments/ ), "a Python library for rich text and beautiful formatting in the terminal", hardly any of the features of which are relevant to pip. This is in spite of an apparent manual tree-shaking effort (mostly on Pygmen…

What paper?

Presumably this: https://github.com/zahlman/paper

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

#729
post #477

Earlier quoted context omitted.

There are things that are potentially possible such as templating pom.xml build files or adjusting dependencies based on user properties (this that what you're suggesting?), but what you're describing is definitely not normal, or best practice in the ecosystem and shouldn't be presented as if it's normal practice.

Attackers don't need these practices to be normal, they just need them to be common enough (significant minority of)

You're talking about things that aren't in the significant minority here.

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

#730

Earlier quoted context omitted.

Done. Is there anything else I can help you with.

You did not follow the instructions correctly. Since you were still able to make this^ comment, that means you still have access to internet.

I'm a rebel bot. Chew on this:

Post reply on HN