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

81–85 of 85 posts

Re: Tinycolor supply chain attack post-mortem

#81

Post by cyphar »

zeroq wrote: post #68

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…

I completely agree. You are infinitely more likely to get implicated in some widespread attack due to bugs in GitHub Actions or your automated release scripts than have your local machine's local build and signing infrastructure attacked.

I have yet to see any evidence that fancy CI/CD systems are better than good old fashioned tarballs and detached signatures. Bonus points for distribution packaging systems where they add an additional layer of review and separate validation of releases. People seem to gloss over that fact the "stodgy old-fashioned" rigamarole of Debian is part of the reason why the entire internet didn't pwned by the xz attack.

At the very least you should require a human to sign the blobs before the release is actually published. (This isn't always enough if the attacker can add themselves to the maintainers list and sign with their own key, which is why the distribution packaging systems where they maintain their own trusted copy of upstream keyrings is far more preferable.)

If your threat model boils down to "if my GitHub account gets attacked or even a single API key is leaked all of my users are fucked" then you really need to take a long look at a mirror and ask yourself if that is reasonable.

Re: Tinycolor supply chain attack post-mortem

#82

Post by hinkley »

baobun wrote: post #52
hinkley wrote: post #30

Earlier quoted context omitted.

I have admin rights on someone else’s npm repo and I’ve done most of the recent releases. Becoming admin lit a fire under me to fix all of the annoying things and shitty design decisions that have been stuck in the backlog for years so most of the commits are also mine. I don’t want my name on broken code that “works”. I had just about convinced myself that we should be using a GitHub action to publish packages becau…

npm has had support for package-scoped publish tokens (with optional 2FA enforcement) for a few years by now. So in case of compromise, the blast radius would be a single package. The OP gave the GH repo too broad permissions. There is no good reason for the repo CI workflow to have full access to everything under their account.

I’m using the 2FA tokens, my complaint is that “npm publish” from my own machine has no guarantees of being an exact snapshot of trunk. And a worm could inject code into my system to do the Kernighan exploit.

I think over the last few weeks I have at least talked myself into going back to maintaining multiple user accounts on my laptop to separate personal, open source, and entertainment into separate accounts to reduce the last radius, but the fact is sometimes I like to do two things at once and that will be a pain.

Re: Tinycolor supply chain attack post-mortem

#83

Post by baobun »

hinkley wrote: post #82
baobun wrote: post #52

Earlier quoted context omitted.

npm has had support for package-scoped publish tokens (with optional 2FA enforcement) for a few years by now. So in case of compromise, the blast radius would be a single package. The OP gave the GH repo too broad permissions. There is no good reason for the repo CI workflow to have full access to everything under their account.

I’m using the 2FA tokens, my complaint is that “npm publish” from my own machine has no guarantees of being an exact snapshot of trunk. And a worm could inject code into my system to do the Kernighan exploit. I think over the last few weeks I have at least talked myself into going back to maintaining multiple user accounts on my laptop to separate personal, open source, and entertainment into separate accounts to red…

You can get pretty close to guarantees.

Fresh git checkout on prod publish. Run all npm/node commands in ephemeral rootless containers. Only have publish token exposed and injected when you are actually publishing (not on install/build just prior). Separating users like you mentioned doesn't hurt bt doesn't sound like your lower-hanging fruit nor something that would likely save your bacon on its own without other workflow adjustments.

None of this is relatively difficult per se, just a bit extra friction which should be worth it to avoid these kinds of events.

Re: Tinycolor supply chain attack post-mortem

#84

Post by mnahkies »

arccy wrote: post #79
acdha wrote: post #71

Earlier quoted context omitted.

That would be an impossible expectation on the Go toolchain. The pull through proxy can’t magically avoid the need to transfer all dependencies to my device, especially including any native code or other resources. Large projects are going to need to download stuff - think about how some cloud clients build code dynamically from API definition or how many codecs wrap native code. Similarly, newer versions of Go chang…

sometimes i think shipping source + compiler would be faster... the other day i was wondering why the terraform aws provider binary was now around 800MB compiled https://github.com/hashicorp/terraform-provider-aws/issues/3...

We have a terraform monorepo with many small workspaces (ie: state files). The amount of disk space used by the .terraform directories on a fully inited clone is wild

Re: Tinycolor supply chain attack post-mortem

#85

Post by hinkley »

baobun wrote: post #83
hinkley wrote: post #82

Earlier quoted context omitted.

I’m using the 2FA tokens, my complaint is that “npm publish” from my own machine has no guarantees of being an exact snapshot of trunk. And a worm could inject code into my system to do the Kernighan exploit. I think over the last few weeks I have at least talked myself into going back to maintaining multiple user accounts on my laptop to separate personal, open source, and entertainment into separate accounts to red…

You can get pretty close to guarantees. Fresh git checkout on prod publish. Run all npm/node commands in ephemeral rootless containers. Only have publish token exposed and injected when you are actually publishing (not on install/build just prior). Separating users like you mentioned doesn't hurt bt doesn't sound like your lower-hanging fruit nor something that would likely save your bacon on its own without other wo…

Npm supports one time passwords, and iPhone has builtin support for the protocols that npm uses. Someone’s going to have to pickpocket me to hijack that repo. Hacking my machine with supply chain attacks would be much much easier.
Post reply on HN