Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tinycolor supply chain attack post-mortem

sigh.dev

Post reply on HN
Print view View original

11–20 of 85 posts

Re: Tinycolor supply chain attack post-mortem

#11

Post by STRiDEX »

bikeshaving wrote: post #9

> Local 2FA based publishing isn’t sustainable... Why is local 2FA unsustainable?! The real problem here is automated publishing workflows. The overwhelming majority of NPM packages do not publish often enough or have complicated enough release steps to justify tokens with the power to publish without human intervention. What is so fucking difficult about running `npm publish` manually with 2FA? If maintainers are un…

That's fair, I'm referring to the number of mistakes that happen with local publishing. Publishing the wrong branch, not building from latest etc

Re: Tinycolor supply chain attack post-mortem

#13

Post by cyberax »

> exfiltrated a npm token with broad publish rights

I freaking HATE tokens. I hate them.

There should be a better way to do authentication than a glorified static password.

An example of how to do it correctly: Github as a token provider for AWS: https://aws.amazon.com/blogs/security/use-iam-roles-to-conne... But this is an exception, rather than a rule.

Re: Tinycolor supply chain attack post-mortem

#14

Post by Scaevolus »

STRiDEX wrote: post #3
drdrey wrote: post #2

> A while ago, I collaborated on angulartics2, a shared repository where multiple people still had admin rights. That repo still contained a GitHub Actions secret — a npm token with broad publish rights. This collaborator had access to projects with other people which I believe explains some of the other 40 initial packages that were affected. > A new Shai-Hulud branch was force pushed to angulartics2 with a maliciou…

Sorry if that wasn't clear. This was a token with global publish rights to my npm packages.

I was confused too. Was it your npm token stored in angulartics2 as a Github Actions secret, so it could publish new angulartics2 versions?

Re: Tinycolor supply chain attack post-mortem

#15

Post by STRiDEX »

Scaevolus wrote: post #14
STRiDEX wrote: post #3

Earlier quoted context omitted.

Sorry if that wasn't clear. This was a token with global publish rights to my npm packages.

I was confused too. Was it your npm token stored in angulartics2 as a Github Actions secret, so it could publish new angulartics2 versions?

Yes, exactly.

Re: Tinycolor supply chain attack post-mortem

#16

Post by rectang »

tcoff91 wrote: post #7
rectang wrote: post #4

Two-factor auth for publishing is helpful, but requiring cryptographically signed approval by multiple authors would be more helpful. Then compromising a single author wouldn't be enough.

Many packages have only 1 author.

The conclusion I'm coming to is that depending on packages which only have a single author is problematic. There are too many ways that packages published by one person can be compromised.

Packages which don't have approval and review by a reliable third party shouldn't be visible by default in a package manager.

Re: Tinycolor supply chain attack post-mortem

#17

Post by er4hn »

cyberax wrote: post #13

> exfiltrated a npm token with broad publish rights I freaking HATE tokens. I hate them. There should be a better way to do authentication than a glorified static password. An example of how to do it correctly: Github as a token provider for AWS: https://aws.amazon.com/blogs/security/use-iam-roles-to-conne... But this is an exception, rather than a rule.

Well the idea behind tokens is that they should be time and authZ limited. In most cases they are not so they degrade to a glorified static password.

Solutions like generating them live with a short lifetime, using solutions like oauth w/ proper scopes, biscuits that limit what they can do in detail, etc, all exist and are rarely used.

Re: Tinycolor supply chain attack post-mortem

#18

Post by chatmasta »

cyberax wrote: post #13

> exfiltrated a npm token with broad publish rights I freaking HATE tokens. I hate them. There should be a better way to do authentication than a glorified static password. An example of how to do it correctly: Github as a token provider for AWS: https://aws.amazon.com/blogs/security/use-iam-roles-to-conne... But this is an exception, rather than a rule.

These machine-to-machine OIDC flows seem secure, and maybe they are when they’re implemented properly, but they’re really difficult to configure. And I can’t shake the feeling that they’re basically just “tokens with more moving parts,” at least for a big chunk of exploitation paths. Without a human in the loop, there’s still some “thing” that gets compromised, whether it’s a token or something that generates time-limited tokens.

In the case of this worm, the OIDC flow wouldn’t even help. The GitHub workflow was compromised. If the workflow was using an OIDC credential like this to publish to npm, the only difference would be the npm publish command wouldn’t use any credential because the GitHub workflow would inject some temporary identity into the environment. But the root problem would remain: an untrusted user shouldn’t be able to execute a workflow with secret parameters. Maybe OIDC would limit the impact to be more fine-grained, but so would changing the token permissions.

Re: Tinycolor supply chain attack post-mortem

#19

Post by Hackbraten »

rectang wrote: post #16
tcoff91 wrote: post #7

Earlier quoted context omitted.

Many packages have only 1 author.

The conclusion I'm coming to is that depending on packages which only have a single author is problematic. There are too many ways that packages published by one person can be compromised. Packages which don't have approval and review by a reliable third party shouldn't be visible by default in a package manager.

How are you supposed to gain collaborators for a project that no one can possibly find?

Re: Tinycolor supply chain attack post-mortem

#20

Post by undecidabot »

cyberax wrote: post #13

> exfiltrated a npm token with broad publish rights I freaking HATE tokens. I hate them. There should be a better way to do authentication than a glorified static password. An example of how to do it correctly: Github as a token provider for AWS: https://aws.amazon.com/blogs/security/use-iam-roles-to-conne... But this is an exception, rather than a rule.

Trusted publishing is a thing now for many package registries, including npm: https://github.blog/changelog/2025-07-31-npm-trusted-publish...
Post reply on HN