Earlier quoted context omitted.
`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?
Postmortem: TanStack NPM supply-chain compromise
411–420 of 501 posts
Re: Postmortem: TanStack NPM supply-chain compromise
#412Please 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-...
> as a systemd user service Hah! I know why I don't use systemd.
Could just as easily install it in your user's crontab though?
Re: Postmortem: TanStack NPM supply-chain compromise
#413Re: Postmortem: TanStack NPM supply-chain compromise
#414What 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.
If /usr/bin/bar wants a credential via a FOO_API_KEY environment variable, I create a /usr/local/bin/bar wrapper script like so:
#!/bin/bash
set -eu +x
if [[ -z "${FOO_API_KEY:-}" ]]; then
echo >&2 Decrypting FOO_API_KEY
FOO_API_KEY="$(pass show bar/FOO_API_KEY)"
fi
export FOO_API_KEY
exec /usr/bin/bar "$@"Re: Postmortem: TanStack NPM supply-chain compromise
#415Re: Postmortem: TanStack NPM supply-chain compromise
#416Wow. 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…
Re: Postmortem: TanStack NPM supply-chain compromise
#417It 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: chan…
The astral blog recently pointed out how they do release gates (manual approvals on release workflows) even with trusted publishing. And sadly, all of the documentation for trusted publishing (NPM/PyPi/Rubygems) doesn't even mention this possibility, let alone defaulting to it.
Re: Postmortem: TanStack NPM supply-chain compromise
#418The malware uses a "prepare" hook to use bun to run the payload, an attack that ironically enough, bun is immune to. Enabling lifecycle scripts in dependencies by default in 2026 is just plain malpractice.
Re: Postmortem: TanStack NPM supply-chain compromise
#419Re: Postmortem: TanStack NPM supply-chain compromise
#420Wow. 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…