Birbla

Discussion summary

The post discusses a supply-chain compromise involving TanStack packages, with community members sharing concerns and tools for detection. Some highlight the complexity and safety issues of package management systems like npm.

What the discussion says

  • Some users believe TanStack is fragile and verbose for type safety.
  • Others compare npm's safety to other package managers like pip and pandas.
  • Community members suggest tools to detect compromised packages.
“TanStack is so fragile and verbose just to ensure type safety.”
— the_inflator
“NPM is the windows of package managers right now.”
— ljm

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • > 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 the package to be downloaded but publishes a clear warning message (that you get to write) every time the package is downloaded, and on the package's npmjs.com page. Users will know that you do not recommend they use the package, but if they are depending on it their builds will not break. We consider this a good compromise between reliability and author control.

    I don't even know what to say here, npm.

    by ezekg
  • Am I understanding this attack vector correctly: Did tanstack have anything misconfigured on their github or make any mistakes that led to this happening? This is the second time, at least, the github actions cache has been seemingly detrimental to massive and widespread supply chain compromise; what is going on over there?
    by 827a
  • https://tanstack.com/blog/npm-supply-chain-compromise-postmo...

    We (TanStack) just released our postmortem about this.

    by crutchcorn
  • @mistralai/mistralai npm package was also compromised as part of this worm https://github.com/mistralai/client-ts/issues/217

    It has been pulled from the npm registry now.

    by varunsharma07
  • Postinstall scripts are deadly. Everyone should be using pnpm.

    Crazy that an "orphan" commit pushed to a FORK(!) could trigger this (in npm clients). IMO GitHub deserves much of the blame here. A malicious fork's commits are reachable via GitHub's shared object storage at a URI indistinguishable from the legit repo. That is absolutely bonkers.

    by chrisweekly
  • 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?

    by Ciantic
  • 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: changed "still not secure" to "still not enough by itself" bc that is the point I want to make)

    Going to Trusted Publishing / pipeline publishing removes the second factor that typically gates npm publish when working locally.

    The story here, while it is evolving, seems to be that the attacker compromised the CI/CD pipeline, and because there is no second factor on the npm publish, they were able to steal the OIDC token and complete a publish.

    Interesting, but unrelated I suppose, is that the publish job failed. So the payload that was in the malicious commit must have had a script that was able to publish itself w/ the OIDC token from the workflow.

    What I want is CI publishing to still have a second factor outside of Github, while still relying on the long lived token-less Trusted Publisher model. AKA, what I want is staged publishing, so someone must go and use 2fa to promote an artifact to published on the npm side.

    Otherwise, if a publish can happen only within the Github trust model, anyone who pwns either a repo admin token or gets malicious code into your pipeline can trivially complete a publish. With a true second factor outside the Github context, they can still do a lot of damage to your repo or plant malicious code, but at least they would not be able to publish without getting your second factor for the registry.

    by jonchurch_
  • Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/.

    https://github.com/TanStack/router/issues/7383#issuecomment-...

    by cube00

Explore Birbla archives