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

81–90 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#81

Post by n_e »

jonchurch_ wrote: post #29
rvz wrote: post #22

Earlier quoted context omitted.

And absolutely pin, pin, pin, ALL your dependencies. If I see a package version dependency that looks like this: ^1.0.0 or even this: "*", then stop reading, pin it to a secure version immediately.

its so wild to have seen this advice reverse course over the past year. it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish. different times, different threat model I suppose

> it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.

This is still the right advice for libraries. For security it doesn’t matter a whole lot anymore as package managers can force the transitive dependencies version, but it allows for much better transitive dependency de duplication.

For non-libraries it doesn’t matter as the exact versions get pinned in the package-lock.

Re: Postmortem: TanStack NPM supply-chain compromise

#84

Post by wereHamster »

jonchurch_ wrote: post #23

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'm looking forward to the analysis how the attacker managed to compromise CI. I was reading through the workflow and what immediately jumped out was a cache poisoning attack. Seems plausible, given https://github.com/TanStack/config/pull/381

edit: two hard things in computer science: naming things, cache invalidation, off-by-one errors, security. something something

Re: Postmortem: TanStack NPM supply-chain compromise

#86

Post by pastel8739 »

arcza wrote: post #56
gajus wrote: post #13

Reminder to secure your npm environments. https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... Just a handful of settings to save a whole lot of trouble.

Wild claim that setting the minimum age to 7 days will result in me "never" getting a supply chain npm vuln.

There is a “fresh” in there

Re: Postmortem: TanStack NPM supply-chain compromise

#87

Post by chuckadams »

nine_k wrote: post #7
slopinthebag wrote: post #3

My decision to abandon the JS ecosystem and language entirely continues to pay off. What a mess... I am, however, concerned that this will pwn my workplace. We don't use Tanstack but this seems self-propagating and I doubt all of our dependencies are doing enough to prevent it.

Abandon NPM in exchange for what? Cargo? Go get? Pip install? Every package manager that does not analyze and run tests on the packages being uploaded (like Linux distros do) is vulnerable.

> Abandon NPM in exchange for what? Cargo? Go get? Pip install?

pnpm, deno, or bun, none of which will run the malicious "prepare" hook in the first place unless specifically allowed.

Re: Postmortem: TanStack NPM supply-chain compromise

#88

Post by saghm »

andix wrote: post #78
arcza wrote: post #56

Earlier quoted context omitted.

Wild claim that setting the minimum age to 7 days will result in me "never" getting a supply chain npm vuln.

In this case it would have, because the compromised packages were pulled within 3 hours.

This sort of mitigation seems like it makes sense in the short term, but it seems like it would only work as long as most people don't do it. If everyone has this set to seven days, it will take seven days plus three hours to get things yanked, and then there will be people who will set to 14 days...

Re: Postmortem: TanStack NPM supply-chain compromise

#89

Post by saghm »

einpoklum wrote: post #70
getcrunk wrote: post #63

I think we are at the point where everyone really needs to run each project in its own vm. Given the recent lpe vulns docker 100% won’t cut it. And containers were never meant primarily as a security boundary anyways

Luckily, projects using more secure language ecosystems like C and C++ are spared this kind of problems :-)

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