Switch to do releases from CI

[dnicolodi]

Currently we do releases from maintainers machines as this allowed us to upload PGP signatures for the releases. However, PyPI support for PGP signatures has never been great, it has been deprecated, and even removed. Digital Attestations have been implemented to replace PGP signatures https://docs.pypi.org/attestations/producing-attestations/ However, these are supported only when publishing with Trusted Publishing https://docs.pypi.org/trusted-publishers/ and only with GitHub and GitLab-based Trusted Publishers.

I think we should move our release process to do the upload of sdists and wheels from CI with Trusted Publishing and Digital Attestations.

[eli-schwartz]

For what it's worth, meson itself has always uploaded the sdist and PGP signature together directly to GitHub Releases and never done anything there with PyPI (other than treating PyPI as a secondary download site with barely enough information make pip install work). It works fine, and the people who care about PGP signatures know where they are and use them.

I think that the meson release manager would be surprised that PyPI had something to remove. It doesn't change the release calculus.

PyPI has long ago declined to treat PGP signatures the way GitHub does, and instead opted to, essentially, vandalize what support they did have to the point where no one knew that it had any vestiges of support at all. The community correspondingly moved off site. Meson is not the only project that screwed up the numbers for the PyPI proposal by using their own alternative download site as the primary and PyPI as a pip-specific emergency backup.

[rgommers]

I'm fine with moving to truster publishers. I think we can have both, since as of right now the only place where GPG signatures end up is in the signed release tag, and that can stay unchanged:

[eli-schwartz]

The signed release tag is only usable when checking out a git clone of meson-python -- you can't use it to e.g. verify a source code archive in a Linux distro packaging recipe, although I suppose maintainers of a distro package could checkout meson-python in their home directory, verify the git tag, and run diff -Naur sdist/ git-repo/ to establish an indirect code signing assertion that covers the sdist. It's not very tooling friendly, although the Debian project sidesteps this by expecting all source packages to be tarballed, signed and uploaded by the Debian maintainer, who manually imports the project from "personal choice of upstream sources, including the git repository as an option" and does check the git PGP signature at that time.

Note as well that git still relies on sha1 and is believed safe at the moment. Efforts are still ongoing to move to sha256, but that git signature only signs a message describing the sha1 hash of the tag object. Fingers crossed that the remaining blockers to upgrade to sha256 get resolved by the git project soon. ;)