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

481–490 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#481

Post by phatskat »

SamuelAdams wrote: post #376
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,…

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.

Yep, I tried to use Act to get a sense of what our YAML was doing but it failed to pull the docker images and I gave up - not enough incentive to test locally when I can push to GH and yolo it and hope the ops folks can help me figure it out

Re: Postmortem: TanStack NPM supply-chain compromise

#482

Post by KajMagnus »

sophiabits wrote: post #206
ezekg wrote: post #201

> Unpublish was unavailable for nearly all affected packages because of npm's "no unpublish if dependents exist" policy. We have to rely on npm security to pull tarballs server-side, which adds hours of delay during which malicious tarballs remain installable Per https://docs.npmjs.com/policies/unpublish : > If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows…

I do not envy the position the npm team are in. They removed the ability to unpublish packages as a response to the left-pad incident[1] because it wasn't desirable for individual developers to break downstream dependencies by pulling their package maliciously. Of course the side effect is that now it's much harder to pull packages for legitimate reasons :/ [1] https://en.wikipedia.org/wiki/Npm_left-pad_incident

If a package developer maliciously breaks everyone's builds,

isn't that pretty great?

Because now you have learnt that you can't trust them

Re: Postmortem: TanStack NPM supply-chain compromise

#483

Post by [deleted] »

nabogh wrote: post #222
ezekg wrote: post #201

> Unpublish was unavailable for nearly all affected packages because of npm's "no unpublish if dependents exist" policy. We have to rely on npm security to pull tarballs server-side, which adds hours of delay during which malicious tarballs remain installable Per https://docs.npmjs.com/policies/unpublish : > If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows…

Some sort of middle ground should have been found where the unpublished package is still accessible as an archive or something. I'd much rather get my package broken than get hacked

[deleted]

Re: Postmortem: TanStack NPM supply-chain compromise

#484

Post by KajMagnus »

timwis wrote: post #285

What do folks here do to avoid having plaintext credentials on disk? I try to use 1Password's plugins where I can. I find the SSH key (and got signing) experience flawless, but the cli experience (eg aws cli) pretty clunky - they often break, and they don't even have a gcp plugin last I checked.

Check out Qubes OS and vault VMs and (I haven't started using yet) split SSH / GPG.

Re: Postmortem: TanStack NPM supply-chain compromise

#485

Post by KajMagnus »

timwis wrote: post #304
Myzel394 wrote: post #301

Earlier quoted context omitted.

I'm not a huge fan of 1Password, there have been way too many issues in the past with it. If you're on a Mac, I can highly recommend you to check out Secretive https://github.com/maxgoedjen/secretive

Love that feeling when you read through a repo and think, "Wow, this looks cool," and go to star it, and see that you already have, and clearly forgot about it Anyway, thanks for sharing. It doesn't look like it handles cli auth though (aws, npm, etc. all leave tokens sitting in your home directory). What do you use for those?

Or when you find some old source code at your workplace, and you're like: "this looks pretty nice, I wonder who wrote this?"

Re: Postmortem: TanStack NPM supply-chain compromise

#486

Post by ashishb »

codedokode wrote: post #474
ashishb wrote: post #446

Earlier quoted context omitted.

Always run third-party code (especially npm packages) inside a sandbox, take your pick: ai-jail, bubblewrap, seatbelt, or amazing-sandbox (the last one, I wrote for myself after trying all others).

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

Re: Postmortem: TanStack NPM supply-chain compromise

#487

Post by anthk »

marshray wrote: post #476
anthk wrote: post #375

Earlier quoted context omitted.

It should be a way to make system env vars (profile.d or simlar) as readonly so every users' shell had these set to empty values and unable to change them.

Shell-only, but https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

Yes; I'm aware, but for some environments writting a custom shell as the one for SDF would be an easier task. Or maybe a really restricted "ash" called "rash" -because it is- with maybe autocomplete and that's it. Hardcoded $PATH and the like.

Re: Postmortem: TanStack NPM supply-chain compromise

#488

Post by lrvick »

eviks wrote: post #345
sinsudo wrote: post #329

Earlier quoted context omitted.

Anything that can be modified by an attacker can not be used to secure the sudo command. This is a recursive requirementor hierarchy for secure systems.

You can set the permissions so that the attacker can't modify it?

You would need to prevent an attacker from installing shell aliases, or shell config files, or altering any binaries in PATH.

Like, sure you could, but you end up with a very useless system.

Easier to just use VMs for each security context.

Re: Postmortem: TanStack NPM supply-chain compromise

#489

Post by eviks »

lrvick wrote: post #488
eviks wrote: post #345

Earlier quoted context omitted.

You can set the permissions so that the attacker can't modify it?

You would need to prevent an attacker from installing shell aliases, or shell config files, or altering any binaries in PATH. Like, sure you could, but you end up with a very useless system. Easier to just use VMs for each security context.

Is any of this specific to a link vs tyre original full-pathed sudo?

Re: Postmortem: TanStack NPM supply-chain compromise

#490

Post by bpavuk »

Griffinsauce wrote: post #264
efilife wrote: post #219

Earlier quoted context omitted.

This has always been happening

We lived through a generation of agism at millennials and now we're turning around and doing it at Gen Z. It's unbelievable.

the history repeats itself approximately every 20 to 33 years!
Post reply on HN