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

61–70 of 85 posts

Re: Tinycolor supply chain attack post-mortem

#61

Post by procaryote »

darkamaul wrote: post #28

> That repo still contained a GitHub Actions secret — a npm token with broad publish rights. One of the advantages of Trusted Publishing [0] is that we no longer need long-lived tokens with publish rights. Instead, tokens are generated on the CI VM and are valid for only 15 minutes. This has already been implemented in several ecosystems (PyPI, npm, Cargo, Homebrew), and I encourage everyone to use it, it actually ma…

What we need now is a flag in repos for projects that use this kind of thing, so you can easily prohibit dependencies that don't

Re: Tinycolor supply chain attack post-mortem

#62

Post by procaryote »

acdha wrote: post #47
arp242 wrote: post #46

Earlier quoted context omitted.

I'm feeling that maybe the entire concept of "publishing packages" is something that's not really needed? Instead, the VCS can be used as a "source of truth", with no extra publishing step required. This is how Go works: you import by URL, e.g. "example.com/whatever/pkgname", which is presumed to be a VCS repo (git, mercurial, subversion, etc.) Versioning is done by VCS tags and branches. You "publish" by adding a ta…

There’s also a cost that installs take much longer, you need the full toolchain installed, and are no longer reproducible due to variations in the local build environment. If everything you do is a first-party CI build of a binary image you deploy, that’s okay but for tools you’re installing outside of that kind of environment it adds friction.

As a lot of these npm "packages" are glorified code snippets that should never have been individual libraries, perhaps this would drive people to standardise and improve the build tooling, or even move towards having sensibly sized libraries?

Re: Tinycolor supply chain attack post-mortem

#63

Post by rectang »

cyphar wrote: post #59
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.

While multiple authors' signatures would be nice, a lot of these kinds of attacks would be solved if there was any signature verification being done of the commits, tags, or generated artefacts at all . People like to complain about distribution packaging being obtuse, but most distributions have rich support for verifying that package sources were signed by a key in a keyring that is maintained by the distribution.…

Very well said — I agree with all points. But is NPM culturally averse to such mechanisms, and will they reject them as an imposition on authors even as the pace of successful supply chain attacks accelerates?

I think that one hole is that even if you require signatures, not all authors will adhere to best practices and some will still be compromised.

Also, five-dollar-wrench attacks remain feasible, although I’m uncertain if we’ve seen them in the real world.

Re: Tinycolor supply chain attack post-mortem

#64

Post by cyphar »

rectang wrote: post #63
cyphar wrote: post #59

Earlier quoted context omitted.

While multiple authors' signatures would be nice, a lot of these kinds of attacks would be solved if there was any signature verification being done of the commits, tags, or generated artefacts at all . People like to complain about distribution packaging being obtuse, but most distributions have rich support for verifying that package sources were signed by a key in a keyring that is maintained by the distribution.…

Very well said — I agree with all points. But is NPM culturally averse to such mechanisms, and will they reject them as an imposition on authors even as the pace of successful supply chain attacks accelerates? I think that one hole is that even if you require signatures, not all authors will adhere to best practices and some will still be compromised. Also, five-dollar-wrench attacks remain feasible, although I’m unc…

I think the five-dollar-wrench attack has a similar risk profile to a maintainer introducing a security flaw (intentionally or not) -- unless you are actively auditing the code of your dependencies you are ultimately trusting the upstream maintainer (as well as their personal security) at some level. Except in the most extreme scenarios I think that this kind of trust is irreducible -- if you don't trust the upstream maintainer you shouldn't use their software.

The main issue I have is that these ecosystems add so many other layers of trust you need to have that are unnecessary (trust that source forges like GitHub won't ever be compromised, trust that the access control of said source forges won't ever be compromised, trust that the per-language package repos won't ever be compromised, trust that API keys won't be leaked without being discovered quickly, etc etc).

Re: Tinycolor supply chain attack post-mortem

#65

Post by realityking »

darkamaul wrote: post #28

> That repo still contained a GitHub Actions secret — a npm token with broad publish rights. One of the advantages of Trusted Publishing [0] is that we no longer need long-lived tokens with publish rights. Instead, tokens are generated on the CI VM and are valid for only 15 minutes. This has already been implemented in several ecosystems (PyPI, npm, Cargo, Homebrew), and I encourage everyone to use it, it actually ma…

I had missed the announcement that this is now available for npm: https://github.blog/changelog/2025-07-31-npm-trusted-publish...

Guess I know what I’ll be doing this weekend.

Re: Tinycolor supply chain attack post-mortem

#66

Post by orphea »

pabs3 wrote: post #60
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.

mTLS aka TLS client certs seems like the way to go.

How is a client cert not another glorified static password? It would have been stolen from repo secrets the same way.

Re: Tinycolor supply chain attack post-mortem

#67

Post by practorz »

rectang wrote: post #40
x0x0 wrote: post #38

Earlier quoted context omitted.

That's a lot of entitlement for things you haven't paid a cent for; not just multiple authors but trusted 3rd parties; approval and review; etc.

I’ve done all those things myself (past ASF member where all that and more was SOP), so I realize what I’m asking for. It’s not crazy for authors of small packages to form small collectives and serve as each others’ trusted third parties. In any case, if the choice is “frequent supply chain compromise, take it or leave it”, the answer is of course “leave it”. If we need to pay for curated packages because the problem…

>In any case, if the choice is “frequent supply chain compromise, take it or leave it”, the answer is of course “leave it”.

There's another choice: vendor your dependencies and manually review and vet updates. That solves all your problems, no need for "trusted third parties", you are the one vetting it, only need to trust yourself.

Re: Tinycolor supply chain attack post-mortem

#68

Post by zeroq »

For the last 10 years I've been advocating for manual releases.

I've encountered a lot of backlash, but is it really that alien concept these days? CI/CD is cool, but between this and recent CF drama it seems we have a pretty solid evidence it can lead to a serious problems.

I worked at a BigBank once where deployments to production required at least five people present at a time and a lot of theatrics, but at least we knew what we were deploying.

Re: Tinycolor supply chain attack post-mortem

#69

Post by arccy »

acdha wrote: post #47
arp242 wrote: post #46

Earlier quoted context omitted.

I'm feeling that maybe the entire concept of "publishing packages" is something that's not really needed? Instead, the VCS can be used as a "source of truth", with no extra publishing step required. This is how Go works: you import by URL, e.g. "example.com/whatever/pkgname", which is presumed to be a VCS repo (git, mercurial, subversion, etc.) Versioning is done by VCS tags and branches. You "publish" by adding a ta…

There’s also a cost that installs take much longer, you need the full toolchain installed, and are no longer reproducible due to variations in the local build environment. If everything you do is a first-party CI build of a binary image you deploy, that’s okay but for tools you’re installing outside of that kind of environment it adds friction.

All not problems for Go: pull through proxy is fast and eliminates the need for a toolchain if you just want to download, and Go builds are fully bit-for-bit reproducible.

Re: Tinycolor supply chain attack post-mortem

#70

Post by arccy »

chatmasta wrote: post #18
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-li…

it's all the moving parts that allow for fine grained, time limited tokens though.

there are also interesting things you can do in combination with branch protection rulesets and limiting which tags/workflows can generate tokens with specific permissions

Post reply on HN