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

351–360 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#351

Post by baq »

ljm wrote: post #14
nine_k wrote: post #7

Earlier quoted context omitted.

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.

The community decided it's too much effort to vet code before publishing it so here we are. (I'm not being stupid, even ten years ago there were arguments on HN about whether you should audit your dependencies) I landed on the 'yes, you should know what code you are getting involved with' side.

'yes, you should' needs to be reconciled with 'it's f*g expensive' and 'risk is low'.

nowadays, 'risk is low' isn't true anymore and it's actually cheaper to have a robot spit out a reimplementation of the 5.4% of what you need out of your dependencies instead of auditing the 100%.

Re: Postmortem: TanStack NPM supply-chain compromise

#352

Post by Ciantic »

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, because everything is configured as YAML, yet everything is layed out in the background to directories and files.

What if your CI pipeline was old-school bash script instead? This would be far more obvious to greater amount of people how it works, and what is left behind by other runs. We know how directories and files work in bash scripts.

Could we go back to basics and manage pipelines as scripts and maybe even run small server?

Re: Postmortem: TanStack NPM supply-chain compromise

#353

Post by timwis »

pprotas wrote: post #341
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.

`sops` combined with `age` is great! Benefit is that it doesn't tie you into 1Password's ecosystem

That looks interesting, but unless I'm missing it, it still leaves you with things like ~/.aws/credentials in plaintext on disk, doesn't it?

Re: Postmortem: TanStack NPM supply-chain compromise

#354

Post by silon42 »

Gigachad wrote: post #162
eqvinox wrote: post #158

Earlier quoted context omitted.

[On Linux:] If you didn't give yourself "free" (passwordless) sudo, that's not necessary… …unless it happened in a week with 2 and a half Linux kernel LPEs.

On linux realistically whatever user you installed the malicious NPM package with has access to everything you care about anyway.

I had an idea to always run 2 users, the "main" one (or more) and a "project one"... one could sudo to the project user, but that one could not sudo out... (npm would only be installed for the project user).

Re: Postmortem: TanStack NPM supply-chain compromise

#356

Post by 7373737373 »

Gigachad wrote: post #138
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

QubesOS had the right idea. You want layers and layers of security, with multiple VMs at the root.

See also: https://genode.org/

Also, in addition to isolation and https://en.wikipedia.org/wiki/Capability-based_security between processes, capability security within processes, see languages like E (https://web.archive.org/web/20260506035108/https://erights.o...) or Monte (https://monte.readthedocs.io/en/latest/index.html)

Re: Postmortem: TanStack NPM supply-chain compromise

#357

Post by signed-log »

michaelmior wrote: post #340
lrvick wrote: post #334

Earlier quoted context omitted.

You do not need sudo for installing software. Can just install to ~/.local. Many package managers require sudo, sure, but there is no good reason for them to in a modern linux system, and not all require this. Even with systemd, you can use systemd --user.

That depends on what the software is. If you want to run a service that bonds to a privileged port for example, you need sudo.

For most things, you can do with capabilities

Issue is that it increases friction and you need sudo anyways to set the capabilities.

Most web servers would happy to run unprivileged with only CAP_NET_BIND_SERVICE

Re: Postmortem: TanStack NPM supply-chain compromise

#358

Post by lrvick »

michaelmior wrote: post #340
lrvick wrote: post #334

Earlier quoted context omitted.

You do not need sudo for installing software. Can just install to ~/.local. Many package managers require sudo, sure, but there is no good reason for them to in a modern linux system, and not all require this. Even with systemd, you can use systemd --user.

That depends on what the software is. If you want to run a service that bonds to a privileged port for example, you need sudo.

If you set the appropriate linux capabilities flag on a binary such as sshd at bootup then unprivileged users can bind to 22, no problem.

setcap 'cap_net_bind_service=+ep' /usr/sbin/sshd

Could even run it as a daemon unprivileged from a home directory with "systemd --user"

That said if you have multiple users and want every user to have their own sshd reachable on port 22 on the same machine you probably want to listen on vhost namespaced unix sockets and have something like haproxy listen on port 22 instead. Haproxy could of course also run unprivileged provided it has read access to all the sockets.

Re: Postmortem: TanStack NPM supply-chain compromise

#359

Post by zrm »

michaelmior wrote: post #340
lrvick wrote: post #334

Earlier quoted context omitted.

You do not need sudo for installing software. Can just install to ~/.local. Many package managers require sudo, sure, but there is no good reason for them to in a modern linux system, and not all require this. Even with systemd, you can use systemd --user.

That depends on what the software is. If you want to run a service that bonds to a privileged port for example, you need sudo.

For that you really only need CAP_NET_BIND_SERVICE.

The bigger issue is that if you want to install or update system-wide packages, many of those will be used by privileged processes. Suppose you want to update /bin/sh. Even if the only permission you had is to write binaries, that'll get you root.

Re: Postmortem: TanStack NPM supply-chain compromise

#360

Post by postalcoder »

63stack wrote: post #315
postalcoder wrote: post #132

Wow. Another huge package got compromised. I'm going to repost my PSA[0][1] that I posted after Axios and LiteLLM were compromised. The bit about lifecycle scripts apply too: PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle sc…

The last time I looked at this, using ignore-scripts = true with npm results in "npm run xyz" getting blocked as well, is that still the case?

Nope, that's not the case. This blocks lifecycle scripts, but it doesn't block scripts that are explicitly invoked by `npm run`. From the documentation[0]:

  Note that commands explicitly intended to run a particular script, such as 
  npm start, npm stop, npm restart, npm test, and npm run-script will still
  run their intended script if ignore-scripts is set, but they will not 
  run any pre- or post-scripts.
0: https://docs.npmjs.com/cli/v8/commands/npm-run-script#ignore...
Post reply on HN