Try out PyPI's trusted publishers

[A5rocks]

This probably won't work first try, but I think this is a good improvement! Since I used to think this was neutral or outright bad, here's a few reasons:

1. supply-chain security is topical again
2. it's significantly easier on myself! When I release, I need to make a new venv, install build, etc. It's not hard, just annoying.
3. I think only a specific set of people can approve the release? We'll need to make sure that's the case after merging of course.

Also I don't think automating other parts of the release process is worth the effort. Just this.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.64%. Comparing base (9a1964f) to head (2e930cf).
Report is 3 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2980   +/-   ##
=======================================
  Coverage   99.64%   99.64%           
=======================================
  Files         117      117           
  Lines       17594    17594           
  Branches     3171     3171           
=======================================
  Hits        17532    17532           
  Misses         43       43           
  Partials       19       19           

[A5rocks]

Windows 3.8 CI failed: https://github.com/A5rocks/trio/actions/runs/8489525533/job/23259717631#step:4:2288

Not gonna debug here but just keeping track

[TeamSpen210]

I have this setup on my own project, it's real neat. Once built and tested the run pauses, you get an email, and can then press the approve button. The security settings are to do with the "environment", in the repo settings you can configure who's allowed to authorise the deploy.

[A5rocks]

Yeah there's a release environment on this repo -- hopefully you can see it? For transparency's sake:

[TeamSpen210]

Actually I don't have the settings tab at all, that's fine though. The important transparency bit is that everyone can see the code that's being run, nobody's able to fiddle with the archive.

In regards to the CI config, I think it's better to split it up into two jobs - one to make the archive, one to do the upload. You'd use artefact upload/download to communicate between. This way, the sdist gets fully built (and can be inspected) before you give out permission to publish. And it lets you partition the permissions, so minimal code has to execute with access to the PyPI token. See the cibuildwheel setup as an example of that way.

[A5rocks]

Alright, I separated out the build step. We'll need to test this a bit but hopefully it's fine -- after all most is copied from that example!

I'm not sure how much more secure this is, but might as well do it while I'm here. (After all the only dependencies we ever even touch should be build and setuptools and if those are compromised we have bigger issues that "is someone going to exploit our OIDC thing")

[TeamSpen210]

Indeed it's probably not too critical, but it would protect against us adding something else in the future. We could also say add a test step in between to verify they install + import. Probably more relevant on a non-pure Python project though.

[webknjaz]

@A5rocks check out my PyPUG guide @ https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/ — it also shows how to publish Sigstore signatures and GitHub Releases that are useful for provenance.

I usually prefer the release workflow to be combined with testing. I put the dist creation job before testing and then, I can test those specifically and release exactly the same thing that was tested as opposed to releasing some artifacts built separately in hopes nothing broke since the test run and the artifacts are similar enough...

My earlier effort in #2541 aligns perfectly with such an approach. But I understand that you want something simple for now so the inline comments I made are what I recommend focusing on and adjusting.

@TeamSpen210

Indeed it's probably not too critical, but it would protect against us adding something else in the future.

The attack surface in this case is not what you think. I was the one to insist on telling people in all the guides and examples, that the jobs should be separated. It's exploitable through the build deps poisoning. If an attacker is able to sneak some code in, they'd be able to access OIDC and whatever that can reach. And that's not only PyPI. Imagine that at some point in the future you set up OIDC for AWS or something else — those would be the likely targets in such a case. This is even less obvious which I why I always point out to people that the separation of concerns and the least privilege principle are important.

[webknjaz]

FWIW I don't think there's a case for putting the dists of a pure-python project into two separate GHA artifacts. Perhaps, you could combine them in a single step?

[webknjaz]

Label? Looks like this is going to be triggered on any label creation? Perhaps, there's a case for sticking some filtering on the job level?

[webknjaz]

1. This refers to a GitHub Deployment Environment — a concept corresponding to some deployment target, like PyPI or TestPyPI. So I always recommend naming it pypi in all my guides. Plus William and I are trying to correct this in other places like GitHub's own docs.
2. It's possible to show nice URLs in places where GH shows deployment-related stuff. I like using full versioned URLs when there's an easy way to retrieve the version. But at least something like this would do:

Suggested change

	environment: release
	environment:
	name: pypi
	url: https://pypi.org/p/trio

[webknjaz]

Nit: it's not the entire workflow but the publish job of the release workflow that will be paused until approved.

[A5rocks]

Re: your PR about testing the sdist/wheel, I have a few concerns and I didn't want to think too hard about it yet:

1. the guides I saw all used a release.yml file, presumably for extra security:tm:. How does inter-file dependencies for gha work?
2. I'm not sure if push events encompass tag pushing...

I had some other stuff but I forgot. And now that I think about it I think we could use that workflow_call event + move artifact creation to ci.yml. Nonetheless that can be done later.

---

And I was the one to bring up threat models for building dependencies cause I don't quite see the point of separating out building (for trio, atm, specifically); I don't see why not though so might as well do it if others think it's good!

---

Your PR feedback makes sense, I'll do that.

[webknjaz]

Re: your PR about testing the sdist/wheel, I have a few concerns and I didn't want to think too hard about it yet:

1. the guides I saw all used a release.yml file, presumably for extra security:tm:. How does inter-file dependencies for gha work?

There are a few ways this works. First of all, you can "chain" workflows so one runs after another. In this case, you cannot share state/data between those.
Second, you can "include" the reusable workflows — this is very useful for modularization but PyPI doesn't support reusable workflows currently. So I usually recommend doing this with other parts of the CI except for the PyPI publish job.

I found that a nice way to apply this in practice is having a "top-level" workflow that lists the event triggers and dependencies between different processes but the processes themselves are declared in reusable workflows. You can pass inputs into such workflows and they can set outputs. These "modules" don't list normal events as triggers.
The PyPI publish job is the only one fully declared on the top level fully.

2. I'm not sure if push events encompass tag pushing...

I had some other stuff but I forgot. And now that I think about it I think we could use that workflow_call event + move artifact creation to ci.yml. Nonetheless that can be done later.

The push event happens whenever a tag or a branch is pushed (or force-pushed). This requires filtering "in the runtime". When there's no tag existing at the time of the push, a create event also fires (if you delete a tag and re-push it'll happen again too).
However, personally, I like triggering the release automation via a workflow_dispatch event that allows typing in the target version in the GH UI. Though, this is more complex and I don't suggest extending the scope of this PR.

And I was the one to bring up threat models for building dependencies cause I don't quite see the point of separating out building (for trio, atm, specifically); I don't see why not though so might as well do it if others think it's good!

Yeah, but the case I describe targets things beyond the Python ecosystem and is therefore more dangerous. Another reason is that you need to have the publishing part protected and conditional. But it's a good idea to have a smoke test building and testing the artifacts in PRs and on pushes. You can also check the metadata with twine check --strict so that you don't hit upload failures too late in the process.