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

491–500 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#491

Post by ownagefool »

Ciantic wrote: post #352

What I want to focus on is mental model of your CI pipeline, and problem with too much YAML, consider this quote: > Cache scope is per-repo, shared across pull_request_target runs (which use the base repo's cache scope) and pushes to main. A PR running in the base repo's cache scope can poison entries that production workflows on main will later restore. This is very difficult to understand, and teach to new people,…

This isn't true.

Our old jenkins hosts were largely forever instances with forever credentials that were just waiting to take down the org.

Modern pipelines are orchestrates that run ephemeral execution environments with ephemeral credentials that can significantly decrease the impact and timescales of getting pwned.

They're not perfect, but you can get pretty good posture by applying expertise to the subject. The problem, like always, is this expertise is neither valued nor rewarded.

Re: Postmortem: TanStack NPM supply-chain compromise

#493

Post by codedokode »

ashishb wrote: post #486
codedokode wrote: post #474

Earlier quoted context omitted.

Bubblewrap doesn't help with protecting DBus bus (and you can do a lot with unrestricted access to DBus), accessing the GPU, Wayland and audio daemon. It cannot protect /proc and /sys filesystems. So it works only for simplest CLI programs. As I remember, some Node.js utility (maybe npm) had a bug where it hang if there were no /proc filesystem because it couldn't figure out how many CPUs are available. Telegram cras…

Then try https://github.com/ashishb/amazing-sandbox I use it every day for CLI tools > How would you sandbox an Electron app I haven't figured that out yet

This seems to have similar or less features than bubblewrap, but requires Docker which loads huge images and wastes disk space. No Wayland, DBus, Pipewire, proc, sys filtering. Furthermore, Docker docs explicitly says that it cannot be used for security sandboxing. Also, Docker is a huge binary, run as root, with lot of APIs and wide attack surface.

Re: Postmortem: TanStack NPM supply-chain compromise

#494

Post by ashishb »

codedokode wrote: post #493
ashishb wrote: post #486

Earlier quoted context omitted.

Then try https://github.com/ashishb/amazing-sandbox I use it every day for CLI tools > How would you sandbox an Electron app I haven't figured that out yet

This seems to have similar or less features than bubblewrap, but requires Docker which loads huge images and wastes disk space. No Wayland, DBus, Pipewire, proc, sys filtering. Furthermore, Docker docs explicitly says that it cannot be used for security sandboxing. Also, Docker is a huge binary, run as root, with lot of APIs and wide attack surface.

> Also, Docker is a huge binary, run as root, with lot of APIs and wide attack surface.

You can run it without root. And that's what you should do.

> No Wayland, DBus, Pipewire, proc, sys filtering.

Yeah, I don't need Wayland for CLI tools. For others, you get them inside Docker, isolated from the rest of the system. When I run `npm install`, I want isolation.

Re: Postmortem: TanStack NPM supply-chain compromise

#495

Post by darepublic »

c-hendricks wrote: post #184
darepublic wrote: post #123

Earlier quoted context omitted.

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.

React Query I've managed to avoid but it's really a cache + promise hook, it's fairly versatile. Tanstack Start / Router are pretty great coming from nextjs, and not limited to React either.

Nah there are better cache plus promise hook libs than react query that don't try to sell you courses or bump the major version several times and preach that developers can't handle fetch data logic. It's the monetization of small helpful lib by a megalomaniac

Re: Postmortem: TanStack NPM supply-chain compromise

#496

Post by Lionga »

eviks wrote: post #314
sevenzero wrote: post #280

So how many supply chain attacks do we need to actually change things? Feels like I read about new supply chain attacks every day at this point.

As many as fit in a period of time it takes a better generation of developers to grow up

It only takes as much time until the golden "make no mistakes" proompt finally works. Must be any day now as Altman and Amodei promised us developers will not exist anymore in 12 month about 18 month ago.

Re: Postmortem: TanStack NPM supply-chain compromise

#497

Post by ric2b »

squidsoup wrote: post #35
rvz wrote: post #16

Once again, Shai-Hulud wrecking havock in the Javascript and Typescript ecosystems via NPM. One of the worst ecosystems that has been brought into the software industry and it is almost always via NPM. Not even Cargo (Rust) or go mod (Golang) get as many attacks because at least with the latter, they encourage you to use the standard library. Both Javascript and Typescript have none and want you to import hundreds of…

If cargo was as popular as npm, the same issues would surface.

No, because Rust has a standard library that covers the basics enough to not push you to start adding decencies as quickly.

Re: Postmortem: TanStack NPM supply-chain compromise

#498

Post by ric2b »

robertjpayne wrote: post #45
rvz wrote: post #16

Once again, Shai-Hulud wrecking havock in the Javascript and Typescript ecosystems via NPM. One of the worst ecosystems that has been brought into the software industry and it is almost always via NPM. Not even Cargo (Rust) or go mod (Golang) get as many attacks because at least with the latter, they encourage you to use the standard library. Both Javascript and Typescript have none and want you to import hundreds of…

I don't really buy this. NPM is targeted because it's the largest attack surface with the biggest payoff for a successful attack. Other ecosystems package managers are really no different in a lot of ways. NPM's biggest fault is just it allows post/pre install scripts by default without user intervention.

Your last two sentences are contradictory. That is a very significant difference.

Another significant difference is how useful the standard library of each language is, so that you can avoid 3rd party libraries.

Also the tendency in the JS ecosystem to break libraries into tiny parts, because it helps or historically helped to ship less code to the user.

Re: Postmortem: TanStack NPM supply-chain compromise

#499

Post by pas »

ricardobeat wrote: post #324
jonchurch_ wrote: post #173

Earlier quoted context omitted.

The compromised action here was using pnpm. They poisoned the github action cache, which was caching the pnpm store. The chain required pull_request_target on the job to check bundle size, which had cache access and poisoned the main repo’s cache The malicious package that was publisjed will compromise local machines its installed in via the prepare script, though.

Those are two different attack vectors. The exploit they used on Github Actions would work for either npm or pnpm. But the replication part using postinstall scripts, once it is installed on another machine, would be stopped by pnpm. What I'm curious about is: how can you poison the cache in CI, if the lockfile has an integrity hash for each package? Did the incoming PR modify pnpm-lock.yaml? If so, that would an obv…

Perhaps pnpm trusts the local store?

Re: Postmortem: TanStack NPM supply-chain compromise

#500

Post by SamuelAdams »

shykes wrote: post #466
SamuelAdams wrote: post #376

Earlier quoted context omitted.

The other advantage with bash is that most developers can run it locally to validate what it is doing and debug issues. With GitHub Actions you need to always commit and push, slowing down the DX.

Shameless plug: solving this "push and pray" problem is something we have been focusing on with Dagger. It's an open-source CI platform that decouples the runtime from the triggers . The runtime is open source and local-first, so you develop the actual logic of your pipelines with a proper dev loop. Then, you separately wire up your git triggers. The same pipeline logic can be triggered locally or from git events. IM…

You should add an Easter egg in your cli program: dagger attack, which prints out a favourite Top Gun quote.
Post reply on HN