Fix security issues with the Trusted Publishing example

https://github.com/simonw/python-lib/blob/4b825ed/%7B%7Bcookiecutter.hyphenated%7D%7D/.github/workflows/publish.yml#L44-L49 suggests that building the dists within the same job that publishes them is okay. But it's not.
Such a structure opens the workflow users to privilege escalation through poisoning the build dependencies, which is why I've always insisted on the separation — the build scripts must never have access to id-token: write.

• https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/
• https://docs.pypi.org/trusted-publishers/security-model/

Another suggestion is to fix the GitHub Environment name to represent the deployment target as it's meant to. I usually go for pypi and testpypi so it's obvious that uploading to both is separate.

I saw release here https://github.com/simonw/python-lib/blob/4b825ed/%7B%7Bcookiecutter.hyphenated%7D%7D/.github/workflows/publish.yml#L33C5-L33C25, which is not an upload target but a process name which is very generic.

The declaration syntax can also be extended to include a URL:

-     environment: release
+     environment:
+       name: pypi
+       url: https://pypi.org/project/{% endraw %}{{ cookiecutter.hyphenated }}{% raw %}/${{ github.ref_name }}

Commencez par {{cookiecutter.hyphenated}}/.github/workflows/publish.yml, en particulier les lignes 33 et 44-49, puis lisez les conseils liés de PyPI Trusted Publishing. Vérifiez comment les étapes de build et de publish partagent les permissions et comment l’environnement de release est nommé. C’est terminé lorsque le workflow sépare le build de la publication, maintient l’accès à id-token à l’écart des scripts de build et nomme les cibles PyPI avec l’URL de leur projet.