Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

121–130 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#121
post #89

Earlier quoted context omitted.

No, instead the code that isn't from a dependency is what will cause you to get pwned

I think you missed the joke/sarcasm there.

It's been less than a month since I responded to a comment on a different thread arguing basically the same thing about C/C++ in a serious way. I've long since lost the ability to distinguish.

Re: Postmortem: TanStack NPM supply-chain compromise

#122
post #67

Earlier quoted context omitted.

that dead man's switch surely smells like that tbh

The dead man's switch reminds me of worms and viruses from my childhood, whose primary purpose was apparently just to wreak havoc rather than direct financial gain. It's a childish gimmick.

If an infected computer gets disabled after deactivating one stolen credential, it might slow down the victim from deactivating their other stolen credentials.

Re: Postmortem: TanStack NPM supply-chain compromise

#123

Earlier quoted context omitted.

its a cult in react web dev circles. Just be glad that you never had to encounter devs who insist that everything must be on "tan" stack.

React Query is great. I’ve used his router and table component as well. IMO his stuff became popular on merit more than some cargo culting à la redux

as someone who encountered this cargo culted at a number of start ups -- I beg to differ. React Query I will always pass on. the other lesser known hits of tanstack -- won't even consider.

Re: Postmortem: TanStack NPM supply-chain compromise

#124

Postinstall scripts are deadly. Everyone should be using pnpm. Crazy that an "orphan" commit pushed to a FORK(!) could trigger this (in npm clients). IMO GitHub deserves much of the blame here. A malicious fork's commits are reachable via GitHub's shared object storage at a URI indistinguishable from the legit repo. That is absolutely bonkers.

How is this not a Github P0? Can anyone explain? When I read that, I thought they must be using 'fork' wrong, and actually mean branch on the official repo, as that can't be right!?" Good lord.

they probably used the publish token in a pull-request-target workflow or something?

Re: Postmortem: TanStack NPM supply-chain compromise

#125

It is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: chan…

I still think that Trusted Publishing is a significant win but I do like the idea of requiring a second factor to mark a release as truly published. It would make these CI worms very hard to pull off.

Re: Postmortem: TanStack NPM supply-chain compromise

#126

Earlier quoted context omitted.

I don't understand why people were voting this comment down in the issue page

There is no such thing as please be careful when revoking tokens. What does that mean? Dont revoke them? Look at them carefully before revoking them? And what? Just let the actor just keep using them to spread to other people? Always rotate your tokens immediately if they're compromised. If it hurts, well, that sucks. …but seriously , not revoking the tokens just makes this worse for everyone. A fair comment would ha…

my understanding is that careful means cleaning up the dead-man’s switch before revoking

Re: Postmortem: TanStack NPM supply-chain compromise

#127

It is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: chan…

I was always confused at why people claimed trusted publishing would make any difference to this kind of supply chain attack.

Because it does. The attack has to involve the CI pipeline rather than the dev environment, there's no token to revoke after (if you evict the attacker you're done, the OIDC credentials expire), it's easier to monitor for externally, you can build things like branch protections in and isolate things like "run tests" from "publish", etc. Trusted Publishing is not itself a solution to all supply chain issues but it is a massive improvement.

Re: Postmortem: TanStack NPM supply-chain compromise

#128
Appreciate the tanstack postmortem, however the security issue as far as the rest of the npm ecosystem goes is still an ongoing concern, correct?

Is there evidence that any downstream packages that may have pulled/included tanstack packages should be considered safe?

Re: Postmortem: TanStack NPM supply-chain compromise

#129
post #76
post #61

> it installs that commit's declared dependencies (which include bun) and then runs its prepare lifecycle script Again? How have lifecycle scripts not instantly been defaulted off? Yes breaking things is bad, but come on, this keeps happening, the fix is easy, and if an *javascript* build relies of dependendlcy of dependency's pulled build time script, then it's worth paying in braincells or tokens to digure it out a…

If the payload couldn't execute at install time, it would at runtime? Disabling prepare scripts does not seem like an effective countermeasure.

Postinstall scripts have remained an effective attack vector for quite a while – which, ironically, has meant the worm's authors had little incentive to try something else, so it was easier to inoculate yourself. Alas, you're right, it should be pretty simple to bypass this kind of protection, if they haven't already (and seems like they have).

Re: Postmortem: TanStack NPM supply-chain compromise

#130

Earlier quoted context omitted.

I don't understand why people were voting this comment down in the issue page

There is no such thing as please be careful when revoking tokens. What does that mean? Dont revoke them? Look at them carefully before revoking them? And what? Just let the actor just keep using them to spread to other people? Always rotate your tokens immediately if they're compromised. If it hurts, well, that sucks. …but seriously , not revoking the tokens just makes this worse for everyone. A fair comment would ha…

[deleted]
Post reply on HN