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

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

Post reply on HN
Print view View original

111–120 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#111

Post by ChocolateGod »

mdavidn wrote: post #76
j-bos wrote: 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.

Well at runtime one would hope they're not giving their JS app access to their home folder.

Re: Postmortem: TanStack NPM supply-chain compromise

#112

Post by skissane »

meander_water wrote: post #60
cube00 wrote: post #41

Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/. https://github.com/TanStack/router/issues/7383#issuecomment-...

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

Maybe they have a non-standard interpretation of thumbs-down – as "thumbs-down to this fact" not "thumbs-down to you for pointing it out"

Re: Postmortem: TanStack NPM supply-chain compromise

#113

Post by bakugo »

AgentME wrote: post #32
bakugo wrote: post #8

Earlier quoted context omitted.

I highly recommend enforcing a minimum dependency release age of at least a week across all package managers used at your workplace. Most package managers support it now, and it will save you from the vast majority of these attacks. https://news.ycombinator.com/item?id=47582632

Highly recommend using the minimum release age setting, though I think a week is probably overkill. Did any of the recent supply-chain attacks have a malicious version up for more than a day?

Maybe not, but how much of that was luck? I think it's only a matter of time until a similar compromise happens but nobody notices it for a few days, better safe than sorry.

Re: Postmortem: TanStack NPM supply-chain compromise

#114

Post by noodletheworld »

meander_water wrote: post #60
cube00 wrote: post #41

Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/. https://github.com/TanStack/router/issues/7383#issuecomment-...

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 have been: “it looks like the payload installs a dead-mans switch…”

Asking the maintainers not to revoke their compromised credentials deserves every down vote it receives.

Re: Postmortem: TanStack NPM supply-chain compromise

#115

Post by cluckindan »

chuckadams wrote: post #93
n_e wrote: post #73

Earlier quoted context omitted.

> Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go. How is it not the default in npm?

It is the default in both cargo and npm, but "npm install" stupidly enough still updates the lockfile, and you need "npm ci" to actually respect it. I think there's some flag to make install work sanely, but long-term I find the best approach is to use anything other than npm. I ditched npm for yarn years ago because it had saner dependency resolution (npm's peer dependency algorithm was a constantly moving target),…

”npm install” does not update the lockfile in any current major version.

At least not if you haven’t edited your package.json manually.

Re: Postmortem: TanStack NPM supply-chain compromise

#116

Post by davnicwil »

bakugo wrote: post #25
Narretz wrote: post #21

Earlier quoted context omitted.

Isn't this article wrong about npm minumum release age. 1. The config is min-release-age. 2. For some reason they have chosen to make it days instead of minutes: https://docs.npmjs.com/cli/v11/using-npm/config#min-release-... Completely unforced fragmentation of the dependency manager space imo

This confused me too, until I realized that the article is about pnpm, not npm (pnpm reads .npmrc for some reason, despite not having the same options as npm) On a related note, it seems to be impossible to find the documentation of min-release-age by googling it. Very annoying.

I just set this up for npm, here's the command that worked for me:

npm config set min-release-age 7

The '7' is days. This is the only format that worked for me, just a single integer number of days.

Confirmed by trying to install the latest version of React 19.2.6 (published 5 days ago as of the time of this comment). It failed with a comment confirming that it could not find such a version published before a week ago.

Re: Postmortem: TanStack NPM supply-chain compromise

#117

Post by yetanotherjosh »

chrisweekly wrote: post #40

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.

Re: Postmortem: TanStack NPM supply-chain compromise

#120

Post by wavemode »

noodletheworld wrote: post #114
meander_water wrote: post #60

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…

You seem to be interpreting "please be careful when..." as "don't". I'm not sure how that interpretation makes any sense. Obviously they just mean, first kill the service (or better yet, shutdown the machine entirely) and then revoke the token...?
Post reply on HN