4 ms·

I know I’m kind of late to the post, but maybe you or someone else will still see this. Would a scheme like this only work for well known providers (GitHub is

by vamega 3y ago

I know I’m kind of late to the post, but maybe you or someone else will still see this. Would a scheme like this only work for well known providers (GitHub is done, others could be in the pipeline according to the article)? Does a new hosting provider need to approach PyPi/PyPa to integrate with the hosting provider, or is it possible for any hosting provider to implement a set of APIs and more or less transparently be able to support becoming a Trusted Publisher. I think it’s the former, since it seems strange that anyone can be a trusted publisher, but that does make it much harder for smaller CI providers to onboard. A self hosted CI platform doesn’t seem like it could be “trusted”. Is that accurate? In case it’s not obvious - I’m not super well versed in the details of OIDC/OAuth.

adobrawy 3y ago
Current Pypi implementation requires custom onboarding of each new OIDC provider on Pypi server, so you are completely right. However, OIDC protocol (and JWT token used by it) is pretty flexible, so it should not be challenging to add new publishers (it's mostly about mapping token field to new configuration form).
woodruffw 3y ago
Thanks for posting your question! Your understanding is accurate: the security advantages of using an OIDC provider stem primarily from them being big and from being closely tied to the ecosystem that’s hosting the associated code (like GitHub). For personal source code hosts, the threat model for a self-hosted IdP wouldn’t be much better than just using API tokens directly. And yes, re: additional providers: each needs to be individually implemented by PyPI, since each has slightly different claim sets and trust conditions. It would be nice if there was something standard we could do here, but the underlying data model between different CI providers is too different.

by vamega 3y ago

adobrawy 3y ago

Current Pypi implementation requires custom onboarding of each new OIDC provider on Pypi server, so you are completely right. However, OIDC protocol (and JWT token used by it) is pretty flexible, so it should not be challenging to add new publishers (it's mostly about mapping token field to new configuration form).

woodruffw 3y ago

Thanks for posting your question! Your understanding is accurate: the security advantages of using an OIDC provider stem primarily from them being big and from being closely tied to the ecosystem that’s hosting the associated code (like GitHub). For personal source code hosts, the threat model for a self-hosted IdP wouldn’t be much better than just using API tokens directly. And yes, re: additional providers: each needs to be individually implemented by PyPI, since each has slightly different claim sets and trust conditions. It would be nice if there was something standard we could do here, but the underlying data model between different CI providers is too different.