4 ms·

> In its current form, however, trusted publishing applies to a limited set of use cases. Support is restricted to a small number of CI providers, it cannot be

> In its current form, however, trusted publishing applies to a limited set of use cases. Support is restricted to a small number of CI providers, it cannot be used for the first publish of a new package, and it does not yet offer enforcement mechanisms such as mandatory 2FA at publish time. Those constraints have led maintainer groups to caution against treating trusted publishing as a universal upgrade, particularly for high-impact or critical packages. This isn't strictly accurate: when we designed Trusted Publishing for PyPI, we designed it to be generic across OIDC IdPs (typically CI providers), and explicitly included an accommodation for creating new projects via Trusted Publishing (we called it "pending" publishers[1]). The latter is something that not all subsequent adopters of the Trusted Publishing technique have adopted, which is IMO both unfortunate and understandable (since it's a complication over the data model/assumptions around package existence). I think a lot of the pains here are self-inflicted on GitHub's part here: deciding to remove normal API credentials entirely strikes me as extremely aggressive, and is completely unrelated to implementing Trusted Publishing. Combining the two together in the same campaign has made things unnecessarily confusing for users and integrators, it seems. [1]: https://docs.pypi.org/trusted-publishers/creating-a-project-through-oidc/ https://docs.pypi.org/trusted-publishers/creating-a-project-...

deleted 10mo ago
[deleted]
- deleted 10mo ago
  [deleted]
epage 10mo ago
As I'm not familiar with the npm ecosystem so maybe I'm misunderstanding this but it sounds like they removed support for local publishes (via a token) in favor of CI publishing using Trusted Publishing. If that is correct, I thought this was discussed when Trusted Publishing was proposed for Rust that it was not meant to replace local publishing, only harden CI publishing.
- woodruffw 10mo ago
  > If that is correct, I thought this was discussed when Trusted Publishing was proposed for Rust that it was not meant to replace local publishing, only harden CI publishing. Yes, that's right, and that's how it was implemented for both Rust and Python. NPM seems to have decided to do their own thing here. (More precisely, I think NPM still allows local publishing with an API token, they just won't grant long-lived ones anymore.)
  - the_mitsuhiko 10mo ago
    I think the path to dependency on closed publishers was opened wide with the introduction of both attestations and trusted publishing. People now have assigned extra qualities to such releases and it pushes the ecosystem towards more dependency on closed CI systems such as github and gitlab. It was a good intention, but the ramifications of it I don't think are great.
    - woodruffw 10mo ago
      > People now have assigned extra qualities to such releases and it pushes the ecosystem towards more dependency on closed CI systems such as github and gitlab. I think this is unfortunately true, but it's also a tale as old as time. I think PyPI did a good job of documenting why you shouldn't treat attestations as evidence of security modulo independent trust in an identity[1], but the temptation to verify a signature and call it a day is great for a lot of people. Still, I don't know what a better solution is -- I think there's general agreement that packaging ecosystems should have some cryptographically sound way for responsible parties to correlate identities to their packages, and that previous techniques don't have a great track record. (Something that's noteworthy is that PyPI's implementation of attestations uses CI/CD identities because it's easy, but that's not a fundamental limitation: it could also allow email identities with a bit more work. I'd love to see more experimentation in that direction, given that it lifts the dependency on CI/CD platforms.) [1]: https://docs.pypi.org/attestations/security-model/ https://docs.pypi.org/attestations/security-model/
    - blibble 10mo ago
pamcake 10mo ago
"In its current form" is in context of NPM, where I think it's accurate. Great to see PyPi taking a more reasonable path.
veeti 10mo 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 10mo 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 10mo ago
    So if I self host my own gitea/forgejo instance, will trusted publishing work for me?
    - eesmith 10mo 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 10mo ago
        In other words, it is a clear centralization drive. No two ways about it.
jacquesm 10mo ago
> I think a lot of the pains here are self-inflicted on GitHub's part here It is spelled 'Microsoft'. What did you think would happen long term? I remember when that acquisition happened and there were parties thrown all around, MS finally 'got' open source. And never mind feeding all of the GitHub contents to their AI.
- woodruffw 10mo ago
  My point was that these are political and logistical problems latent to GitHub/Microsoft/whatever, not to Trusted Publishing as a design. I don't think I materially disagree with you about Microsoft not having a sterling reputation.
  - jacquesm 10mo ago
    Yes, but I think that that more than anything is the driver behind these decisions.
    - woodruffw 10mo ago
      Which ones? It wasn't a driver behind our decisions when we designed Trusted Publishing originally; the fact that GitHub has been such a mess has been a consistent source of tsuris in my life.

deleted 10mo ago

[deleted]

deleted 10mo ago
[deleted]

epage 10mo ago

As I'm not familiar with the npm ecosystem so maybe I'm misunderstanding this but it sounds like they removed support for local publishes (via a token) in favor of CI publishing using Trusted Publishing. If that is correct, I thought this was discussed when Trusted Publishing was proposed for Rust that it was not meant to replace local publishing, only harden CI publishing.

woodruffw 10mo ago
> If that is correct, I thought this was discussed when Trusted Publishing was proposed for Rust that it was not meant to replace local publishing, only harden CI publishing. Yes, that's right, and that's how it was implemented for both Rust and Python. NPM seems to have decided to do their own thing here. (More precisely, I think NPM still allows local publishing with an API token, they just won't grant long-lived ones anymore.)
- the_mitsuhiko 10mo ago
  I think the path to dependency on closed publishers was opened wide with the introduction of both attestations and trusted publishing. People now have assigned extra qualities to such releases and it pushes the ecosystem towards more dependency on closed CI systems such as github and gitlab. It was a good intention, but the ramifications of it I don't think are great.
  - woodruffw 10mo ago
    > People now have assigned extra qualities to such releases and it pushes the ecosystem towards more dependency on closed CI systems such as github and gitlab. I think this is unfortunately true, but it's also a tale as old as time. I think PyPI did a good job of documenting why you shouldn't treat attestations as evidence of security modulo independent trust in an identity[1], but the temptation to verify a signature and call it a day is great for a lot of people. Still, I don't know what a better solution is -- I think there's general agreement that packaging ecosystems should have some cryptographically sound way for responsible parties to correlate identities to their packages, and that previous techniques don't have a great track record. (Something that's noteworthy is that PyPI's implementation of attestations uses CI/CD identities because it's easy, but that's not a fundamental limitation: it could also allow email identities with a bit more work. I'd love to see more experimentation in that direction, given that it lifts the dependency on CI/CD platforms.) [1]: https://docs.pypi.org/attestations/security-model/ https://docs.pypi.org/attestations/security-model/
  - blibble 10mo ago

pamcake 10mo ago

"In its current form" is in context of NPM, where I think it's accurate. Great to see PyPi taking a more reasonable path.

veeti 10mo 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 10mo 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 10mo ago
  So if I self host my own gitea/forgejo instance, will trusted publishing work for me?
  - eesmith 10mo 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 10mo ago
      In other words, it is a clear centralization drive. No two ways about it.

jacquesm 10mo ago

> I think a lot of the pains here are self-inflicted on GitHub's part here It is spelled 'Microsoft'. What did you think would happen long term? I remember when that acquisition happened and there were parties thrown all around, MS finally 'got' open source. And never mind feeding all of the GitHub contents to their AI.

woodruffw 10mo ago
My point was that these are political and logistical problems latent to GitHub/Microsoft/whatever, not to Trusted Publishing as a design. I don't think I materially disagree with you about Microsoft not having a sterling reputation.
- jacquesm 10mo ago
  Yes, but I think that that more than anything is the driver behind these decisions.
  - woodruffw 10mo ago
    Which ones? It wasn't a driver behind our decisions when we designed Trusted Publishing originally; the fact that GitHub has been such a mess has been a consistent source of tsuris in my life.