| 07:14 | <ljharb> | bakkot: i think you can log in as tc39-user on npm? if so, it’d be great if you could make a new granular token for that one package that lasts 90 days, and update it in the spec repo secrets |
| 15:13 | <bakkot> | ljharb: I would prefer to merge https://github.com/tc39/ecma262/pull/3706 instead, unless there's a reason not to. You've said it has security issues, which would be a good reason, but I'd like to understand what those are before rejecting that approach. |
| 16:27 | <ljharb> | OIDC tokens can be exfiltrated, allowing an attacker to mint new publish tokens forever and there's no way for maintainers to mitigate it |
| 16:27 | <ljharb> | when github fixes that, then it'll no longer be worse than a 1FA token |
| 16:46 | <bakkot> | OIDC tokens are normally pretty short-lived. Are the OIDC tokens in trusted publishing really eternal? That definitely does seem bad |
| 16:49 | <bakkot> | docs definitely claim it is short-lived https://docs.github.com/en/actions/concepts/security/openid-connect#adding-permissions-settings |
| 16:50 | <bakkot> | someone else claims 5 minutes https://github.com/google-github-actions/auth?tab=readme-ov-file#inputs-workload-identity-federation |
| 16:51 | <bakkot> | do you have a specific reason to think that the ODIC token lives forever? I could go to the effort of exfiltrating one and confirm I guess |
| 16:52 | <bakkot> | their sample token in the docs also lives for 5 minutes so that number seems plausible |
| 17:04 | <ljharb> | i'm not talking about the short-lived npm publish token that oidc generates |
| 17:04 | <ljharb> | i'm talking about the oidc credentials THEMSELVES that let you mint infinite short-lived tokens |
| 17:05 | <ljharb> | (that github shouldn't be exposing to the actions workflow, which is the flaw) |
| 17:05 | <ljharb> | this isn't just me, to be clear, this is why the public position of OpenJS is that nobody should use OIDC yet |
| 17:20 | <bakkot> | Is there more about that written somewhere? The only guidance from openjs I can find is talking more about lack of 2fa and manual setup https://openjsf.org/blog/publishing-securely-on-npm |
| 17:24 | <ljharb> | no, the discoverer hasn't published a blog post yet |
| 18:22 | <Michael Ficarra> | I think we should go with whatever publicly available guidance we have from trusted sources |
| 18:23 | <Michael Ficarra> | if we're really concerned, can't we do something like this temporarily? https://github.com/step-security/wait-for-secrets#publish-to-npm-registry-using-one-time-password-otp |
| 18:24 | <bakkot> | that would be on every single commit though |
| 18:25 | <Michael Ficarra> | well they're often batched, so every time Jordan lands a batch of commits, that would be putting a OTP in once for the last one |
| 18:29 | <bakkot> | ljharb: my understanding of the trusted publishing flow is like
If github's signing key is compromised that's a very big deal. If the JWT is not actually short-lived, or the publish token is not actually short-lived, contrary to the docs, that would allow eternal publishing. but otherwise I don't understand what issue you could be talking about here. leaking the JWT is not a big deal because it expires after five minutes. leaking the publish token is not a big deal because it expires after... however long it is. |
| 18:40 | <ljharb> | Yes that’s what I’m saying, you can exfiltrate GitHub’s signing key |
| 19:05 | <Michael Ficarra> | I feel like we shouldn't be having this conversation in a public space |
| 19:06 | <Michael Ficarra> | even the existence of such an issue would be very sensitive info |
| 20:14 | <ljharb> | it's long since been discussed in a public space. |
| 20:14 | <ljharb> | btw apparently you can go to https://www.npmjs.com/settings/tc39-user/new and generate a new long-lived classic token, and the token just won't be listed on the tokens page, so that's an option too (with a nice side of 🤦♂️ for the github security folks) |
| 21:08 | <Michael Ficarra> | lol so they revoked all existing ones but still allow you to create new ones? |