Comment by woodruffw
3 days ago
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.
That's exactly the point I'm making.