←back to thread

218 points miketheman | 3 comments | | HN request time: 0.406s | source
Show context
belval ◴[] No.42137562[source]
I have a bit of uneasiness about how this is heavily pushing GitHub actions as the correct way to publish to PyPI. I had to check PEP740 to make sure it was not directly supported by Microsoft.

> The generation and publication of attestations happens by default, and no changes are necessary for projects that meet all of these conditions: publish from GitHub Actions; via Trusted Publishing; and use the pypa/gh-action-pypi-publish action to publish.

If you then click on "The manual way" it adds a big disclaimer:

> STOP! You probably don't need this section; it exists only to provide some internal details about how attestation generation and uploading work. If you're an ordinary user, it is strongly recommended that you use one of the official workflows described above.

Where the only official workflow is "Use GitHub Actions".

I guess I am an idealist but as a maintainer this falls short of my expectations for the openness of Python and PyPI.

replies(9): >>42137628 #>>42137831 #>>42138035 #>>42138967 #>>42140525 #>>42140881 #>>42142188 #>>42144001 #>>42144423 #
doctorpangloss ◴[] No.42140525[source]
On the one hand, you are totally right, GitHub Actions are the VS Code of automation. People choose them because they are broke, they work well enough, and the average person chooses things based on how it looks. GitHub Actions looks easy, it's cozy, it's comfy, VS Code looks like a code editor, everything has to be cozy and comfy.

On the other hand, considering all of that, you can see why Python would arrive at this design. They are the only other people besides NPM who regularly have supply chain attack problems. They are seemingly completely unopinionated about how to fix their supply chain problems, while being opinionated about the lack of opinions about packaging in general. What is the end goal? Presumably one of the giant media companies, Meta, Google or Microsoft maybe, have to take over the development of runtime and PEP process, but does that even sound good?

replies(1): >>42141248 #
LtWorf ◴[] No.42141248[source]
I think the end goal is to only allow github/google whatever accounts to publish code on Pypi, so importing whatever will be USA-sanctions safe.

The burden to ban russians/koreans/iranians will be on those big companies and pypi will be able to claim they respect the rules without having the resources themselves to ban accounts from sanctioned countries.

So in my opinion, in the future tooling will have some option to check if the software was uploaded via microsoft et al and can be considered unsanctioned in USA.

Or they might just say that's how you upload now and that's it.

replies(2): >>42141438 #>>42141488 #
woodruffw ◴[] No.42141488[source]
None of this is true. There is no plan to disable API token uploads to PyPI or to mandate Trusted Publishing, much less attestations. It's entirely intended to be a misuse-resistant way to upload to the index in the "happy case" where the package uses a CI/CD workflow that supports OpenID Connect.

(I'm disappointed by the degree to which people seem to gleefully conspiracize about Python packaging, and consequently uncritically accept the worse possible interpretation of anything done to try and improve the ecosystem.)

replies(2): >>42141561 #>>42143482 #
1. LtWorf ◴[] No.42141561[source]
I don't think you can predict the future any more than me.
replies(2): >>42141600 #>>42141836 #
2. doctorpangloss ◴[] No.42141600[source]
I understand the desire to raise awareness about your fringe concern. But it makes no sense.
3. woodruffw ◴[] No.42141836[source]
I don't baselessly speculate about it. But yes, I do think I can predict with some confidence that PyPI is not going to remove API token access.