| 16:55 | <bakkot> | ljharb: can you say more about what's worse with trusted publishing than our current setup? |
| 16:56 | <bakkot> | possibly at editor call if that would be easier |
| 16:58 | <ljharb> | I’ll pop in and disclose, sure. either way tho it wouldn’t be any more secure, even if the flaw I’m referring to was addressed |
| 17:30 | <bakkot> | ... wouldn't it? right now compromise of the publish job would allow an attacker to exfiltrate the token, which gives persistent access to publishing until the token is revoked, and would allow publishing all packages controlled by the tc39 user. with trusted publishing, assuming we remove the secret, it only gives one-off access and only to the one package |
| 19:05 | <ljharb> | we can switch it to a granular token, so at least it’d be only that package. but even in a properly functioning oidc setup it’s single factor. so in that scenario we could set up an environment that requires a second approval, and then it’s actually two factor, making it safer. (but GitHub’s impl is broken) |
| 19:05 | <ljharb> | nobody’s in the call, but tldr the flaw (via an exploited workflow) allows for permanent issuing of new tokens and there’s nothing package owners can do to stop it. |
| 19:06 | <bakkot> | call moved to 2pm, sorry |
| 19:07 | <bakkot> | I agree that if there was a second factor in our current setup then that would be more secure than trusted publishing, but there isn't |
| 19:08 | <bakkot> | so as it stands, from what I can tell, trusted publishing is more secure than our current setup |
| 19:08 | <bakkot> | except for this flaw you describe |
| 19:09 | <bakkot> | also I am not interested in setups where there's a second factor required to publish the biblio, I want it to be automated and run on every commit with no manual intervention |
| 19:12 | <bakkot> | sorry about the meeting timing, I thought michael had updated the calendar invite but that must have been something else |
| 20:08 | <jmdyck> | meeting in 51min? |
| 20:42 | <bakkot> | Yes |