35 ms·

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 m

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.
      - lucideer 2y ago
        > the current GitHub requirement is an explicitly temporary restriction It seems reasonable to suggest that advertising a solution for public use at a point in time when support is at <2 systems is not an ideal way to encourage an open ecosystem.
        woodruffw 2y ago
        It’s an eminently ideal way, given that the overwhelming majority of Python packages come from GitHub. It would be unreasonable to withhold an optional feature just because that optional feature is not universal yet. Again, I need people to let this sink in: Trusted Publishing is not tied to GitHub. You can use Trusted Publishing with GitLab, and other providers too. You are not required to produce attestations, even if you use Trusted Publishing. Existing GitLab workflows that do Trusted Publishing are not changed or broken in any way by this feature, and will be given attestation support in the near future. This is all documented.
        HelloNurse 2y ago
        Let this sink in: a "security" feature that depends on Trusted Publishing providers puts the developer at the mercy of a small set of Trusted Publishing providers, and for most people none of them are acceptable feudal lords. Let this sink in: if it is possible to check attestations, attestations will be checked and required by users, and PyPI packages without them will be used less. Whether PyPI requires attestations is unimportant.
        woodruffw 2y ago
        > PyPI packages without them will be used less. Whether PyPI requires attestations is unimportant. This points to a basic contradiction in how people are approaching open source: if you want your project to be popular on a massive scale, then you should expect those people to have opinions about how you're producing that project. That should not come as a surprise. If, on the other hand, you want to run a project that isn't seeking popularity, then you have a reasonable expectation that people won't ask you for these things and you shouldn't want your packages downloads from PyPI as much as possible. When people do bug you for those things, explicitly rejecting them is (1) acceptable, and (2) should reduce the relative popularity of your project. The combination of these things ("no social expectations and a high degree of implicit social trust/criticality") is incoherent and, more importantly, doesn't reflect observed behavior (people who do OSS as a hobby - like myself - do try and do the more secure things because there's a common acknowledgement of responsibility for important projects).
    - ziddoap 2y ago
      This is exactly what I meant when I said "people that seem to have willfully not read any of the docs or your clarifying comments here"
    - cpburns2009 2y ago
      Attestations are worthless unless they're checked. I have no doubt they'll eventually become the default in pip which effectively makes them mandatory for 99% of people not willing to jump through the hoops of installing an unattested package.
      - HelloNurse 2y ago
        The "hoops", which will only increase in the future, make GitHub-dependent attested packages privileged and give GitHub (and maybe, in the future, other inappropriate entities) significant power over open source Python packages.
  - ljdgah 2y ago
    Since roughly 2014 there have been so many rug pulls in the Python organization that no one believes anything any more. It always starts small: "Oh, we just want everyone to be nice, so we have this super nice CoC document. Anyone who distrusts us is malicious." Ten years later you have a corporate-backed inner circle that abuses the CoC to silence people, extend their power and earning potential and resort to defamation and libel. It is possible that the people here who defend this corporate attestation-of-provenance-preferably-on-our-infrastructure scheme think that nothing nefarious will happen in the future. Well, given the repressive history of Python they are naive then. It just takes pip to add a flag to enable "non-attested" packages. And of course they'll name it something like --allow-insecure-potentially-malicious.
- lucideer 2y ago
  > I am begging you to re-read the docs The gp was pointing out that the docs heavily emphasise (& therefore encourage) GHA usage & suggested language changes. If people are confused about what they need to use Trusted Publishing & you're suggesting (begging) a re-read as the solution, that seems evidence enough that the gp is correct about the docs needing a reword.
  - nmstoker 2y ago
    It could just as easily imply that people aren't paying attention when they read it. Inability to understand a text is not always on the author, plenty of times it's on the reader.
- st3fan 2y ago
  Well, yes and no. From the perspective of an infosec professional who is focussed on supply chain security I can tell you that your package having an attestation from a trusted platform like GitHub or GitLab gives me a warm feeling. It is not the only thing we will look at but definitely part of a longer list of checks to understand risk around dependencies. With an attestation from GitHub I know at least that the workflow that ran it and the artifacts it produced will be 100% traceable and verifyable. This doesn't mean the code was not malicious, but for example it will rule out that someone did the build at home and attached an alternative version of an artifact to a GitHub release. Like how that was done with the xz project. It is fine to not like GitHub, but I think that means we need more trusted builders. Developers cannot be pushed toward just GitHub.
  - woodruffw 2y ago
    > It is fine to not like GitHub, but I think that means we need more trusted builders. Developers cannot be pushed toward just GitHub. Yes, agreed. This is why the docs explicitly say that we’re planning on enabling support for other publisher providers, like GitLab.
WhyNotHugo 2y ago
They’re not encouraging open infrastructure. In fact, this whole design doesn’t even contemplate the possibility of self hosting. Trust must be blindly delegated to one of the existing partners.

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.
    - lucideer 2y ago
      > the current GitHub requirement is an explicitly temporary restriction It seems reasonable to suggest that advertising a solution for public use at a point in time when support is at <2 systems is not an ideal way to encourage an open ecosystem.
      - woodruffw 2y ago
        It’s an eminently ideal way, given that the overwhelming majority of Python packages come from GitHub. It would be unreasonable to withhold an optional feature just because that optional feature is not universal yet. Again, I need people to let this sink in: Trusted Publishing is not tied to GitHub. You can use Trusted Publishing with GitLab, and other providers too. You are not required to produce attestations, even if you use Trusted Publishing. Existing GitLab workflows that do Trusted Publishing are not changed or broken in any way by this feature, and will be given attestation support in the near future. This is all documented.
        HelloNurse 2y ago
        Let this sink in: a "security" feature that depends on Trusted Publishing providers puts the developer at the mercy of a small set of Trusted Publishing providers, and for most people none of them are acceptable feudal lords. Let this sink in: if it is possible to check attestations, attestations will be checked and required by users, and PyPI packages without them will be used less. Whether PyPI requires attestations is unimportant.
        woodruffw 2y ago
        > PyPI packages without them will be used less. Whether PyPI requires attestations is unimportant. This points to a basic contradiction in how people are approaching open source: if you want your project to be popular on a massive scale, then you should expect those people to have opinions about how you're producing that project. That should not come as a surprise. If, on the other hand, you want to run a project that isn't seeking popularity, then you have a reasonable expectation that people won't ask you for these things and you shouldn't want your packages downloads from PyPI as much as possible. When people do bug you for those things, explicitly rejecting them is (1) acceptable, and (2) should reduce the relative popularity of your project. The combination of these things ("no social expectations and a high degree of implicit social trust/criticality") is incoherent and, more importantly, doesn't reflect observed behavior (people who do OSS as a hobby - like myself - do try and do the more secure things because there's a common acknowledgement of responsibility for important projects).
  - ziddoap 2y ago
    This is exactly what I meant when I said "people that seem to have willfully not read any of the docs or your clarifying comments here"
  - cpburns2009 2y ago
    Attestations are worthless unless they're checked. I have no doubt they'll eventually become the default in pip which effectively makes them mandatory for 99% of people not willing to jump through the hoops of installing an unattested package.
    - HelloNurse 2y ago
      The "hoops", which will only increase in the future, make GitHub-dependent attested packages privileged and give GitHub (and maybe, in the future, other inappropriate entities) significant power over open source Python packages.
- ljdgah 2y ago
  Since roughly 2014 there have been so many rug pulls in the Python organization that no one believes anything any more. It always starts small: "Oh, we just want everyone to be nice, so we have this super nice CoC document. Anyone who distrusts us is malicious." Ten years later you have a corporate-backed inner circle that abuses the CoC to silence people, extend their power and earning potential and resort to defamation and libel. It is possible that the people here who defend this corporate attestation-of-provenance-preferably-on-our-infrastructure scheme think that nothing nefarious will happen in the future. Well, given the repressive history of Python they are naive then. It just takes pip to add a flag to enable "non-attested" packages. And of course they'll name it something like --allow-insecure-potentially-malicious.
lucideer 2y ago
> I am begging you to re-read the docs The gp was pointing out that the docs heavily emphasise (& therefore encourage) GHA usage & suggested language changes. If people are confused about what they need to use Trusted Publishing & you're suggesting (begging) a re-read as the solution, that seems evidence enough that the gp is correct about the docs needing a reword.
- nmstoker 2y ago
  It could just as easily imply that people aren't paying attention when they read it. Inability to understand a text is not always on the author, plenty of times it's on the reader.
st3fan 2y ago
Well, yes and no. From the perspective of an infosec professional who is focussed on supply chain security I can tell you that your package having an attestation from a trusted platform like GitHub or GitLab gives me a warm feeling. It is not the only thing we will look at but definitely part of a longer list of checks to understand risk around dependencies. With an attestation from GitHub I know at least that the workflow that ran it and the artifacts it produced will be 100% traceable and verifyable. This doesn't mean the code was not malicious, but for example it will rule out that someone did the build at home and attached an alternative version of an artifact to a GitHub release. Like how that was done with the xz project. It is fine to not like GitHub, but I think that means we need more trusted builders. Developers cannot be pushed toward just GitHub.
- woodruffw 2y ago
  > It is fine to not like GitHub, but I think that means we need more trusted builders. Developers cannot be pushed toward just GitHub. Yes, agreed. This is why the docs explicitly say that we’re planning on enabling support for other publisher providers, like GitLab.

WhyNotHugo 2y ago

They’re not encouraging open infrastructure. In fact, this whole design doesn’t even contemplate the possibility of self hosting. Trust must be blindly delegated to one of the existing partners.