6 ms·

I get that, that's why I didn't go "This is Embrace Extend Extinguish", but as constructive feedback I would recommend softening the language and to replace: >

by belval 2y ago

I get that, that's why I didn't go "This is Embrace Extend Extinguish", but as constructive feedback I would recommend softening the language and to replace: > STOP! You probably don't need this section; In https://docs.pypi.org/attestations/producing-attestations/#the-manual-way https://docs.pypi.org/attestations/producing-attestations/#t... Perhaps also add a few of the providers you listed as well? > The only reason it emphasizes GitHub Actions is because that's where the overwhelming majority of automatic publishing traffic comes from GitHub being popular is a self-reinforcing process, if GitHub is your first class citizen for something as crucial as trusted publishing then projects on GitHub will see a higher adoption and become the de-facto "secure choice".

woodruffw 2y ago
> but as constructive feedback I would recommend softening the language and to replace: I can soften it, but I think you're reading it excessively negatively: that warning is there to make sure people don't try to do the fiddly, error-prone cryptographic bits if they don't need to. It's a numerical fact that most project owners don't need that section, since most are either using manual API tokens or are publishing via GitHub Actions. > Perhaps also add a few of the providers you listed as well? They'll be added when they're enabled. Like I said in the original comment, we're using a similar enablement pattern as happened with Trusted Publishing: GitHub was enabled first because it represents the majority of publishing traffic, followed by GitLab and the others. > GitHub being popular is a self-reinforcing process, if GitHub is your first class citizen for something as crucial as trusted publishing then projects on GitHub will see a higher adoption and become the de-facto "secure choice". I agree, but I don't think this is PyPI's problem to solve. From a security perspective, PyPI should prioritize the platforms where the traffic is. (I'll note that GitLab has been supported by Trusted Publishing for a while now, and they could make the publishing workflow more of a first class citizen, the way it is on GHA.)
- belval 2y ago
  > I agree, but I don't think this is PyPI's problem to solve. From a security perspective, PyPI should prioritize the platforms where the traffic is. To me that's a bit of a weird statement, PyPI is part of the Python foundation, making sure that the project remains true to its open-source nature is reasonable? My concern is that these type of things ultimately play out as "we are doing the right thing to limit supply chain attacks" which is good an defendable, but in ~5 years PyPI will have an announcement that they are sunsetting PyPI package upload in favor of the trusted provider system. pip (or other tooling) will add warnings whenever I install a package that is not "trusted". Maybe I am simply pessimistic. That being said we can agree to disagree, I am not part of the PSF and I did preface my first comment with "I guess I am an idealist".
  - woodruffw 2y ago
    > making sure that the project remains true to its open-source nature is reasonable? What about this, in your estimation, undermines the open-source nature of PyPI? Nothing about this is proprietary, and I can't think of any sane definition of OSS in which PyPI choosing to verify OIDC tokens from GitHub (among other IdPs!) meaningfully subverts PyPI's OSS committment. > PyPI package upload in favor of the trusted provider system. pip (or other tooling) will add warnings whenever I install a package that is not "trusted". Maybe I am simply pessimistic. Let me put it this way: if PyPI disables API tokens in favor of mandatory Trusted Publishing, I will eat my shoe on a livestream. (I was the one of the engineers for both API tokens and Trusted Publishing on PyPI. They're complementary, and neither can replace the other.)
    - mananaysiempre 2y ago
      > What about this, in your estimation, undermines the open-source nature of PyPI? Absence of support for self-hosting, in the spirit of freedom 0 = OSD 5&6? Or, for that matter, for any provider whose code is fully open source?
      - woodruffw 2y ago
        > Absence of support for self-hosting, or for that matter for any non-proprietary service? This has nothing to do with self-hosting, whatsoever. You can upload to PyPI with an API token; that will always work and will not do anything related to Trusted Publishing, which exists entirely because it makes sense for large services. PyPI isn't required to federate with the server in my basement through OpenID Connect to be considered open source.
        takluyver 2y ago
        I believe you that token uploads will continue to be possible, but it seems likely that in a couple of years trusted publishing & attestations will be effectively required for all but the tiniest project. You'll get issues and PRs to publish this way, and either you accept them, or you have to repeatedly justify what you've got against security. And maybe that's a good thing? I'm not against security, and supply chain attacks are real. But it's still kind of sad that the amazing machines we all own are more and more just portals to the 'trusted' corporate clouds. And I think there are things that could be done to improve security with local uploads, but all the effort seems to go into the cloud path.
- BiteCode_dev 2y ago
  I'm with @belval on this one, it's ok to prioritize github, but people that want the standard to implement an alternative should not feel like they are doing something that may not be supported. It kinda feels like that right now.
  - woodruffw 2y ago
    Again, to be clear: the standard does not stipulate GitHub or any other specific identity providers. The plan is to enable GitLab and the other Trusted Publisher providers in short order. This is exactly the same as Trusted Publishing, where people accused the feature of being a MSFT trojan horse because GitHub was enabled first. I think it would behoove everybody to assume the best intentions here and remember that the goal is to secure the most people by default.
    - int_19h 2y ago
      I think the point is that this needs to be made clearer in the official docs from the get go.
      - woodruffw 2y ago
        It's said explicitly in the second sentence in the usage docs[1]. > Attestations are currently only supported when uploading with Trusted Publishing, and currently only with GitHub-based Trusted Publishers. Support for other Trusted Publishers is planned. See #17001 for additional information. [1]: https://docs.pypi.org/attestations/producing-attestations/ https://docs.pypi.org/attestations/producing-attestations/
    - deleted 2y ago
      [deleted]
    - TheRealPomax 2y ago
      At this point it should be fairly obvious that if you have to defend the phrasing in multiple threads here on HN, get some folks to help rephrase the current document instead so you can comment with "we updated the text to make it clear this is a first pass and more options are getting added to the doc soon". If you draw an ugly cat, and someone tells you it's ugly, it doesn't matter how much you insist that it isn't, and the same is true for docs. It doesn't matter what your intention was: if people keep falling over the same phrasing, just rephrase it. You're not your writing, it's just text to help support your product, and if that text is causing problems just change it (with the help of some reviewers, because it's clear you think this is phrased well enough, but you're not the target audience for this document, and the target audience is complaining).
- guappa 2y ago
  > error-prone cryptographic bits if they don't need to They can't. Because you wouldn't accept their key anyway.
  - woodruffw 2y ago
    I think you're missing something. The key in question is a short-lived ECDSA key that lives inside a publishing workflow and is destroyed after signing; neither GitHub nor the Sigstore CA generates a signing key for you. PyPI will accept any key bound to an identity, provided we know how to verify that identity. Right now that means we accept Trusted Publishing identities, and GitHub identities in particular, since that's where the overwhelming majority of Python package publishing traffic comes from. Like what happened Trusted Publishing, this will be expanded to other identities (like GitLab repositories) as we roll it out.
    - guappa 2y ago
      How does pypi know I'm not github? Because I can sign with my keys and not with github's key. Never mind all the low level details of the temporary keys and hashes and all of that. This is an high level comment not a university book about security.
HelloNurse 2y ago
PyPI should support and encourage open infrastructure. If I don't want to use GitHub, let alone GitHub Actions, I am now effectively excluded from publishing my work on PyPI: quite unacceptable.
- woodruffw 2y ago
  That’s now how any of this works. I am begging you to re-read the docs and understand that this does not require anybody to use GitHub, much less GitHub Actions, much less Trusted Publishing, much less attestations. You can still, and will always be able to use API tokens.
  - ziddoap 2y ago
    Thank you for being patient with people that seem to have willfully not read any of the docs or your clarifying comments here, are saying you are lying, and/or are making up hypothetical situations. It's appreciated! Edit: woodruffw is sitting here and thoughtfully commenting and answering people despite how hostile some of the comments are (someone even said "This is probably deserving a criminal investigation"! and it has more upvotes than this comment). I think that should be appreciated, even if you don't like Python.
    - HelloNurse 2y ago
      I know attestations are not mandatory, but the rug has already been pulled: PEP 740 distinguishes "good" and "bad" packages and "good" packages require GitHub.
      - woodruffw 2y ago
        It does nothing of the sort, and the current GitHub requirement is an explicitly temporary restriction, like it was for Trusted Publishing. Again: I am begging you to read the docs that we’ve compiled for this.
        2y ago

by belval 2y ago

woodruffw 2y ago

> but as constructive feedback I would recommend softening the language and to replace: I can soften it, but I think you're reading it excessively negatively: that warning is there to make sure people don't try to do the fiddly, error-prone cryptographic bits if they don't need to. It's a numerical fact that most project owners don't need that section, since most are either using manual API tokens or are publishing via GitHub Actions. > Perhaps also add a few of the providers you listed as well? They'll be added when they're enabled. Like I said in the original comment, we're using a similar enablement pattern as happened with Trusted Publishing: GitHub was enabled first because it represents the majority of publishing traffic, followed by GitLab and the others. > GitHub being popular is a self-reinforcing process, if GitHub is your first class citizen for something as crucial as trusted publishing then projects on GitHub will see a higher adoption and become the de-facto "secure choice". I agree, but I don't think this is PyPI's problem to solve. From a security perspective, PyPI should prioritize the platforms where the traffic is. (I'll note that GitLab has been supported by Trusted Publishing for a while now, and they could make the publishing workflow more of a first class citizen, the way it is on GHA.)

belval 2y ago
> I agree, but I don't think this is PyPI's problem to solve. From a security perspective, PyPI should prioritize the platforms where the traffic is. To me that's a bit of a weird statement, PyPI is part of the Python foundation, making sure that the project remains true to its open-source nature is reasonable? My concern is that these type of things ultimately play out as "we are doing the right thing to limit supply chain attacks" which is good an defendable, but in ~5 years PyPI will have an announcement that they are sunsetting PyPI package upload in favor of the trusted provider system. pip (or other tooling) will add warnings whenever I install a package that is not "trusted". Maybe I am simply pessimistic. That being said we can agree to disagree, I am not part of the PSF and I did preface my first comment with "I guess I am an idealist".
- woodruffw 2y ago
  > making sure that the project remains true to its open-source nature is reasonable? What about this, in your estimation, undermines the open-source nature of PyPI? Nothing about this is proprietary, and I can't think of any sane definition of OSS in which PyPI choosing to verify OIDC tokens from GitHub (among other IdPs!) meaningfully subverts PyPI's OSS committment. > PyPI package upload in favor of the trusted provider system. pip (or other tooling) will add warnings whenever I install a package that is not "trusted". Maybe I am simply pessimistic. Let me put it this way: if PyPI disables API tokens in favor of mandatory Trusted Publishing, I will eat my shoe on a livestream. (I was the one of the engineers for both API tokens and Trusted Publishing on PyPI. They're complementary, and neither can replace the other.)
  - mananaysiempre 2y ago
    > What about this, in your estimation, undermines the open-source nature of PyPI? Absence of support for self-hosting, in the spirit of freedom 0 = OSD 5&6? Or, for that matter, for any provider whose code is fully open source?
    - woodruffw 2y ago
      > Absence of support for self-hosting, or for that matter for any non-proprietary service? This has nothing to do with self-hosting, whatsoever. You can upload to PyPI with an API token; that will always work and will not do anything related to Trusted Publishing, which exists entirely because it makes sense for large services. PyPI isn't required to federate with the server in my basement through OpenID Connect to be considered open source.
      - takluyver 2y ago
        I believe you that token uploads will continue to be possible, but it seems likely that in a couple of years trusted publishing & attestations will be effectively required for all but the tiniest project. You'll get issues and PRs to publish this way, and either you accept them, or you have to repeatedly justify what you've got against security. And maybe that's a good thing? I'm not against security, and supply chain attacks are real. But it's still kind of sad that the amazing machines we all own are more and more just portals to the 'trusted' corporate clouds. And I think there are things that could be done to improve security with local uploads, but all the effort seems to go into the cloud path.
BiteCode_dev 2y ago
I'm with @belval on this one, it's ok to prioritize github, but people that want the standard to implement an alternative should not feel like they are doing something that may not be supported. It kinda feels like that right now.
- woodruffw 2y ago
  Again, to be clear: the standard does not stipulate GitHub or any other specific identity providers. The plan is to enable GitLab and the other Trusted Publisher providers in short order. This is exactly the same as Trusted Publishing, where people accused the feature of being a MSFT trojan horse because GitHub was enabled first. I think it would behoove everybody to assume the best intentions here and remember that the goal is to secure the most people by default.
  - int_19h 2y ago
    I think the point is that this needs to be made clearer in the official docs from the get go.
    - woodruffw 2y ago
      It's said explicitly in the second sentence in the usage docs[1]. > Attestations are currently only supported when uploading with Trusted Publishing, and currently only with GitHub-based Trusted Publishers. Support for other Trusted Publishers is planned. See #17001 for additional information. [1]: https://docs.pypi.org/attestations/producing-attestations/ https://docs.pypi.org/attestations/producing-attestations/
  - deleted 2y ago
    [deleted]
  - TheRealPomax 2y ago
    At this point it should be fairly obvious that if you have to defend the phrasing in multiple threads here on HN, get some folks to help rephrase the current document instead so you can comment with "we updated the text to make it clear this is a first pass and more options are getting added to the doc soon". If you draw an ugly cat, and someone tells you it's ugly, it doesn't matter how much you insist that it isn't, and the same is true for docs. It doesn't matter what your intention was: if people keep falling over the same phrasing, just rephrase it. You're not your writing, it's just text to help support your product, and if that text is causing problems just change it (with the help of some reviewers, because it's clear you think this is phrased well enough, but you're not the target audience for this document, and the target audience is complaining).
guappa 2y ago
> error-prone cryptographic bits if they don't need to They can't. Because you wouldn't accept their key anyway.
- woodruffw 2y ago
  I think you're missing something. The key in question is a short-lived ECDSA key that lives inside a publishing workflow and is destroyed after signing; neither GitHub nor the Sigstore CA generates a signing key for you. PyPI will accept any key bound to an identity, provided we know how to verify that identity. Right now that means we accept Trusted Publishing identities, and GitHub identities in particular, since that's where the overwhelming majority of Python package publishing traffic comes from. Like what happened Trusted Publishing, this will be expanded to other identities (like GitLab repositories) as we roll it out.
  - guappa 2y ago
    How does pypi know I'm not github? Because I can sign with my keys and not with github's key. Never mind all the low level details of the temporary keys and hashes and all of that. This is an high level comment not a university book about security.

HelloNurse 2y ago

PyPI should support and encourage open infrastructure. If I don't want to use GitHub, let alone GitHub Actions, I am now effectively excluded from publishing my work on PyPI: quite unacceptable.

woodruffw 2y ago
That’s now how any of this works. I am begging you to re-read the docs and understand that this does not require anybody to use GitHub, much less GitHub Actions, much less Trusted Publishing, much less attestations. You can still, and will always be able to use API tokens.
- ziddoap 2y ago
  Thank you for being patient with people that seem to have willfully not read any of the docs or your clarifying comments here, are saying you are lying, and/or are making up hypothetical situations. It's appreciated! Edit: woodruffw is sitting here and thoughtfully commenting and answering people despite how hostile some of the comments are (someone even said "This is probably deserving a criminal investigation"! and it has more upvotes than this comment). I think that should be appreciated, even if you don't like Python.
  - HelloNurse 2y ago
    I know attestations are not mandatory, but the rug has already been pulled: PEP 740 distinguishes "good" and "bad" packages and "good" packages require GitHub.
    - woodruffw 2y ago
      It does nothing of the sort, and the current GitHub requirement is an explicitly temporary restriction, like it was for Trusted Publishing. Again: I am begging you to read the docs that we’ve compiled for this.
      - 2y ago