Release artifacts missing for 0.3.0

[David Runge]

Hi! I package this project for Arch Linux.

The current release on PyPI is 0.3.0, which unfortunately has no respective artifacts on launchpad.
Could you please add them?

Also, since PyPI just silently removed the OpenPGP signature files for existing releases, they broke our reproducibility and trust path [1].
Can you therefore please also attach a signature file for a release tarball, signed by either AC0A4FF12611B6FCCF01C111393587D97D86500B or 760D8F2C93E9CA8562E4A00E75D673C2DD1FB761?
This would allow us to use launchpad as trusted upstream going forward.

Thank you! :)

[1] https://archlinux.org/todo/fix-reproducibility-of-packages-broken-by-pypi-removing-signature-files/

[Jürgen Gmach (jugmac00)]

Hey David,

We quickly discussed this issue in our team.

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

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

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

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

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).

Jürgen Gmach
Launchpad team

[David Runge (dvzrv)]

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 int...

[David Runge (dvzrv)]

The aforementioned RFC is now in effect and Arch Linux will be switching away from PyPI sdist tarballs.

Would it be possible for you to configure https://git.launchpad.net/lazr.config/ in such a way, that it auto-generates tarballs as well?

Have you had a chance to discuss ending the support for OpenPGP signatures sensibly with your team?

[David Runge (dvzrv)]

Hi Jürgen,

did you have a chance to further work on this topic?

I am currently blocked by this ticket and would like to no longer have this TODO open: https://archlinux.org/todo/fix-reproducibility-of-packages-broken-by-pypi-removing-signature-files/