Comment 2 for bug 2028762

Hi Jürgen,

thanks for getting back to me!

> PyPI is the de-facto publishing platform for Python packages.

That might be the case. However, it is also severely flawed when it comes to distributing sources. Sdist tarballs are not well-defined, very often lack files that downstream packagers need (e.g. tests, licenses, etc.) or in the case of setuptools are outright painful to patch using upstream patches (see https://github.com/pypa/setuptools/issues/3672).

> I do understand that your workflow is built on signatures, but PyPI has stopped supporting them for reasons as announced in https://blog.pypi.org/posts/2023-05-23-removing-pgp/, also outlined in https://blog.yossarian.net/2023/05/21/PGP-signatures-on-PyPI-worse-than-useless

Additionally the platform seems not very interested in the use-cases of downstream packagers, which becomes evident in e.g. demoting unique/expectable download links for sources (by turning their existence into "tribal knowledge"), making PGP signatures invisible on the website and eventually outright removing links to existing signature files (without announcement), breaking downstream build processes (reproducibility and chain of trust).
FWIW, I am not sure I agree with all assertions made in the blog post (2nd link). I agree that there are *many* useless certificates and certifications out there (as well as extremely outdated or outright dead projects), but when it comes to trust this is down to the downstream consumer (distributions usually) to point out problems, as the Python-native package tooling does not make use of those signatures at all.

For the above reasons I have created an Arch Linux RFC to strongly discourage the use of PyPI sdist tarballs for the thousands of python packages we maintain: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/20

> While we have published releases in the past also here on Launchpad, we are strongly considering to stop that.

For the reasons outlined above, I'd kindly ask you to reconsider that! So far, auto-generated tarballs usually work out-of-the-box, while sdist tarballs most often do not.

> I assume that you have a workflow set up which also would work without signatures.

Yes, but it would break the chain of trust established with the previous releases.

In the case you will want to stop providing signed tarballs (which IMHO would be a bit sad, but it is of course completely up to you), it would be super awesome if you could provide a (clear-signed: https://www.gnupg.org/gph/en/manual/x135.html#clearsigned_documents) text block stating that going forward you are not going to sign releases anymore (basically to end the chain of trust).

> If you have ideas how to improve the security aspect for PyPI, please reach out to Seth, who is the new security developer in residence (https://sethmlarson.dev/security-developer-in-residence).

Seth has already been made aware of my "screams into the void" on mastodon a few days ago and promised to look into better ways of introducing change in the future (which unfortunately didn't translate into fixing the issue at hand).

At this point I am mostly disappointed with how the change has been handled and the work introduced for downstreams (which in many cases could have been prevented), but alas, it is what it is.