Package Signing in PIP

A few days ago, I made this DEV.to post about how Python's PIP lacks GPG package signing. Well, it turns out that I'm wrong! It does have a package signing process after all. Except it's one of the most manual, archaic, and cumbersome security practices I've seen to date.

I discovered this method when I landed on this blog post by a core python developer yesterday. To test package signing in the way described, I created a test package called siterank, a small script to fetch Alexa ranking of given websites.

Firstly, it's essential that you use only twine to upload a signed package to PyPi because only twine has that feature. Secondly, their documentation seems to be outdated because some arguments don't seem to work. For example, the --sign argument for specifying signed files explicitly didn't work for me:

-s, --sign            Sign files to upload using GPG

Uploading the package file and the generated signature file (*.asc) in succession like this did work.

twine upload siterank-0.2.tar.gz siterank-0.2.tar.gz.asc

Also, note that you won't see the uploaded signature file on your package page on PyPi. However, there are two different ways to verify the signature:

1. You can use the PyPi JSON API. It contains all the uploaded versions in JSON format. Notice that in the second package version, the has_sig attribute has been set to true.
2. You can also dd the .asc extension to the link to your setup file. In my case it is: https://files.pythonhosted.org/packages/16/f9/1dfce544610b9dcbbfcb4095c8e143c6cfd54b4371ccedc3f73df0a99926/siterank-0.2.tar.gz.asc.

So, someone who wants to verify if this package was indeed created by me can pull this .asc file and match it with my GPG public key (ID E12979BA15FDE7FD — which can be also found by running gpg --search-keys [email protected]).

This roundabout way of verification is needless to mention, tedious, and cumbersome. This process should be seamless, automated, and included in the pip work-flow itself like apt and dnf have done. The only probable issue is that millions of developers upload their packages to PyPi and everyone may not want to use GPG keys. So, signing could continue to be optional (as it is now), but a verification option ought to be there for signed packages, as it ensures the security and integrity of packages.

Another issue is that of adoption. I've noticed from that JSON API that several popular projects like requests, nltk, flask, etc. haven't signed their packages at all. It's important that more and more developers push signed packages and thus contribute to making PyPi a more secure environment to install and distribute packages.