3 ms·

Yet in practice, only the big boys are allowed to become "Trusted Publishers": > In the interest of making the best use of PyPI's finite resources, we only pla

by veeti 9mo ago

Yet in practice, only the big boys are allowed to become "Trusted Publishers": > In the interest of making the best use of PyPI's finite resources, we only plan to support platforms that have a reasonable level of usage among PyPI users for publishing. Additionally, we have high standards for overall reliability and security in the operation of a supported Identity Provider: in practice, this means that a home-grown or personal use IdP will not be eligible. How long until everyone is forced to launder their artifacts using Microsoft (TM) GitHub (R) to be "trusted"? [1] https://docs.pypi.org/trusted-publishers/internals/#how-do-i-become-a-trusted-publishing-provider https://docs.pypi.org/trusted-publishers/internals/#how-do-i...

woodruffw 9mo ago
I wrote a good chunk of those docs, and I can assure you that the goal is always to add more identity providers, and not to enforce support for any particular provider. GitHub was only the first because it’s popular; there’s no grand evil theory beyond that.
- VorpalWay 9mo ago
  So if I self host my own gitea/forgejo instance, will trusted publishing work for me?
  - eesmith 9mo ago
    According to their docs, they have a "have high standards for overall reliability and security in the operation of a supported Identity Provider: in practice, this means that a home-grown or personal use IdP will not be eligible." If you think your setup meets those standards, you'll need to use Microsoft (TM) GitHub (R) to contact them.
    - VorpalWay 9mo ago
      In other words, it is a clear centralization drive. No two ways about it.
      - jopsen 9mo ago
        npm is centralized to start with, so how is this a problem?
      - eesmith 9mo ago
        PyPI is already centralized. Back when I started with PyPI, manual upload through the web interface was the only possibility. Have they gotten rid of that? My understanding is that "trusted publishing"[0] was meant as an additional alternative to that sort of manual processing. It was never decentralized. As I recall, the initial version only supported GitHub and (I think) GitLab. [0] I do not trust Microsoft as an intermediary to my software distribution. I don't use Microsoft products or services, including GitHub. Yes, this makes contacting PyPI support via GitHub impossible for me. That is one of the reasons I stopped using PyPI and instead distribute my wheels from my own web site.
  - woodruffw 9mo ago
    If you had enough users and demonstrated the ability to securely manage a PKI, then I don’t see why not. But if it’s just you on a server in your garage, then there would be no advantage to either you or to the ecosystem for PyPI to federate with your server. That’s why API tokens are still supported as a first-class authentication mechanism: Trusted Publishing is simply not a good fit in all possible scenarios.
    - pamcake 9mo ago
      > if it’s just you on a server in your garage, then there would be no advantage to either you or to the ecosystem for PyPI to federate with your server. Why not leave decision on what providers to trust to users, instead of having a centrally managed global allowlist at the registry? Why should he registry admin be the one to decide who is fit to publish for each and all packages?
      - acdha 9mo ago
        They’re running the most popular registry but nothing says you can’t use your own to implement whatever policy you want. The default registry has a tricky balance of needing to support inexperienced users while also only having a very modest budget compared to the companies which depend on it, and things like custom authentication flows are disproportionately expensive.
        pamcake 9mo ago
        What's the issue exactly? They seem to manage to handle account signups with email addresss from unknown domain names just as fine as for hotmail.com and gmail.com. I don't see how this is any different. The whole point of standards like OIDC (and supposedly TP) is that there is no need for provider-specific implemenations or custom auth flows as long as you follow the spec and protocol. It's just some fields that can be put in a settings UI configurable by the user.
        woodruffw 9mo ago

by veeti 9mo ago

woodruffw 9mo ago

I wrote a good chunk of those docs, and I can assure you that the goal is always to add more identity providers, and not to enforce support for any particular provider. GitHub was only the first because it’s popular; there’s no grand evil theory beyond that.

VorpalWay 9mo ago
So if I self host my own gitea/forgejo instance, will trusted publishing work for me?
- eesmith 9mo ago
  According to their docs, they have a "have high standards for overall reliability and security in the operation of a supported Identity Provider: in practice, this means that a home-grown or personal use IdP will not be eligible." If you think your setup meets those standards, you'll need to use Microsoft (TM) GitHub (R) to contact them.
  - VorpalWay 9mo ago
    In other words, it is a clear centralization drive. No two ways about it.
    - jopsen 9mo ago
      npm is centralized to start with, so how is this a problem?
    - eesmith 9mo ago
      PyPI is already centralized. Back when I started with PyPI, manual upload through the web interface was the only possibility. Have they gotten rid of that? My understanding is that "trusted publishing"[0] was meant as an additional alternative to that sort of manual processing. It was never decentralized. As I recall, the initial version only supported GitHub and (I think) GitLab. [0] I do not trust Microsoft as an intermediary to my software distribution. I don't use Microsoft products or services, including GitHub. Yes, this makes contacting PyPI support via GitHub impossible for me. That is one of the reasons I stopped using PyPI and instead distribute my wheels from my own web site.
- woodruffw 9mo ago
  If you had enough users and demonstrated the ability to securely manage a PKI, then I don’t see why not. But if it’s just you on a server in your garage, then there would be no advantage to either you or to the ecosystem for PyPI to federate with your server. That’s why API tokens are still supported as a first-class authentication mechanism: Trusted Publishing is simply not a good fit in all possible scenarios.
  - pamcake 9mo ago
    > if it’s just you on a server in your garage, then there would be no advantage to either you or to the ecosystem for PyPI to federate with your server. Why not leave decision on what providers to trust to users, instead of having a centrally managed global allowlist at the registry? Why should he registry admin be the one to decide who is fit to publish for each and all packages?
    - acdha 9mo ago
      They’re running the most popular registry but nothing says you can’t use your own to implement whatever policy you want. The default registry has a tricky balance of needing to support inexperienced users while also only having a very modest budget compared to the companies which depend on it, and things like custom authentication flows are disproportionately expensive.
      - pamcake 9mo ago
        What's the issue exactly? They seem to manage to handle account signups with email addresss from unknown domain names just as fine as for hotmail.com and gmail.com. I don't see how this is any different. The whole point of standards like OIDC (and supposedly TP) is that there is no need for provider-specific implemenations or custom auth flows as long as you follow the spec and protocol. It's just some fields that can be put in a settings UI configurable by the user.
        woodruffw 9mo ago