3 ms·

I'd like to have touch to sign from a YubiKey or similar. The whole idea of trusting the cloud to manage credentials on your behalf seems like a mistake.

cluckindan 5mo ago
”TanStack maintainer Tanner Linsley said the attacker used an orphaned commit to gain access to the workflow run that stores the OIDC token, effectively bypassing the project’s existing publishing protections. He noted that two-factor authentication is enabled for everyone on the team”
- dboreham 5mo ago
  Apologies if this is a dumb question but how does this attack work? (I know what an orphaned commit is but not how you use one to bypass project access control).
  - fny 5mo ago
    TLDR is that the attacker leveraged actions/cache to cache a poisoned pnpm store which contains something that will be triggered during the package.json lifecycle. All it required was for someone to merge any PR to run whats in the cache trigger the second stage of the exploit: mint an OIDC token, build evil tarballs, and publish.
- bakkoting 5mo ago
  2fa being enabled for people on the team is different from 2fa being required for publishing. It is not current possible to enforce (or use) 2fa for publishing with trusted publishing.
- duskdozer 5mo ago
  github holding on to orphaned commits has been a noted issue for a while now
  - koolba 5mo ago
    It’s a wonderful feature when you accidentally nuke your one and only local copy.
    - lexicality 5mo ago
      Depending on how badly you nuked it, it's probably still in your `git reflog` locally. Normal git hangs on to orphaned commits too. (Until `git gc` runs)
matt_kantor 5mo ago
> The whole idea of trusting the cloud to manage credentials on your behalf seems like a mistake. Isn't this what the "trusted" in "trusted publishing" implies? Maybe you're saying that trusted publishing itself seems like a mistake, but if so you don't need to use it: you can publish your packages the old-fashioned way and npm will make you go through the 2fa flow.

cluckindan 5mo ago

”TanStack maintainer Tanner Linsley said the attacker used an orphaned commit to gain access to the workflow run that stores the OIDC token, effectively bypassing the project’s existing publishing protections. He noted that two-factor authentication is enabled for everyone on the team”

dboreham 5mo ago
Apologies if this is a dumb question but how does this attack work? (I know what an orphaned commit is but not how you use one to bypass project access control).
- fny 5mo ago
  TLDR is that the attacker leveraged actions/cache to cache a poisoned pnpm store which contains something that will be triggered during the package.json lifecycle. All it required was for someone to merge any PR to run whats in the cache trigger the second stage of the exploit: mint an OIDC token, build evil tarballs, and publish.
bakkoting 5mo ago
2fa being enabled for people on the team is different from 2fa being required for publishing. It is not current possible to enforce (or use) 2fa for publishing with trusted publishing.
duskdozer 5mo ago
github holding on to orphaned commits has been a noted issue for a while now
- koolba 5mo ago
  It’s a wonderful feature when you accidentally nuke your one and only local copy.
  - lexicality 5mo ago
    Depending on how badly you nuked it, it's probably still in your `git reflog` locally. Normal git hangs on to orphaned commits too. (Until `git gc` runs)

matt_kantor 5mo ago

> The whole idea of trusting the cloud to manage credentials on your behalf seems like a mistake. Isn't this what the "trusted" in "trusted publishing" implies? Maybe you're saying that trusted publishing itself seems like a mistake, but if so you don't need to use it: you can publish your packages the old-fashioned way and npm will make you go through the 2fa flow.