OIDC is not a silver bullet either and has its own set of vectors to consider too. If it works for your org model then great, but it doesn't solve every common scenario.
Trusted Publishing addresses the vector here, which is arbitrary persistence and delayed use of credentials by attackers. You're right that it's not a silver bullet (anything claiming to be one is almost certainly a financially induced lie), but it eliminates/foreshortens the attack staging window significantly.
It's not a silver bullet in that it can open up other vectors of much more probable attack.
If I have a FOSS project where there are other contributors with write access but not publish access (very common) OIDC now allows them to publish via workflows, opening you up to Jia Tan type attacks.
Like I said, if it works for your org, great. Otherwise it can cause bigger problems.
Sorry, what's the threat model in which you're giving people write access to your repository but assuming that they can't publish?
To establish a baseline here: the assumption with Trusted Publishing is that people are already using CI/CD to publish to places like PyPI. All Trusted Publishing does is replace the user-managed credential with a machine-intermediated one.
In other words: if someone had write access to your repository before, Trusted Publishing does not change their privilege, since they could always push a new CI/CD workflow that uses your manual publishing secret directly. All Trusted Publishing does is formalize the treatment of the source repository as a source of truth, and introduce some misuse-resistance properties (short-lived credentials, minimal self-scoping).
If this isn't your user model, that's perfectly fine. But in that case you shouldn't be using CI/CD to publish at all (which is also fine); it's not an issue with Trusted Publishing per se.
> Sorry, what's the threat model in which you're giving people write access to your repository but assuming that they can't publish?
So that I'm the arbiter of what people download, and can review locally what changes were made prior to pushing it out to everyone.
> To establish a baseline here: the assumption with Trusted Publishing is that people are already using CI/CD to publish to places like PyPI.
That's not the narrative. People have been saying to switch to trusted publishing from local publishes. They're not 1:1 compatible. I agree that if you already publish via CD, then it probably already worked for your org and thus is a no brainer.
> If this isn't your user model, that's perfectly fine. But in that case you shouldn't be using CI/CD to publish at all (which is also fine); it's not an issue with Trusted Publishing per se.
