I think there is no reason we *couldn’t* allow uploads of signatures after the fact, although it sort of makes an already tenuous security claim even more tenuous I think. Since distutils/setuptools don’t have reproducible “builds” of sdists if you wanted to after the fact upload a signature your choices are: * Hope you still have the original files you uploaded still laying around, sign *them* and then upload just the signature. * Download the files, open them up and inspect all of the files to ensure they match the correct state. * Download the files, blindly sign them. Of those options, the first one is no more or less “secure” than uploading alongside the original file, but the problem is that it’s impossible to differentiate that from the second two, and that could genuinely be worse (for example, compromised PyPI gives author a bad file, they sign it and upload the signature thus making everyone feel it is a “safe” file). Both the second options are kind of bad because it is incredibly easy to smuggle something bad into a tarball that a human being would miss. The larger reason why I personally haven’t implemented it is because I believe the GPG signatures on PyPI are largely useless from a practical standpoint and I’m not really interested in doing anything to improve them and I would personally much rather just disable them completely.
Um, I think you can set something in setup.cfg for ``setup.py upload``. I don’t think there is anything like that for Twine. I can’t speak for Ian but I don’t personally see anything inherently wrong with adding a environment variable or config option to twine that allows it to always sign by default. Ian may feel differently though! — Donald Stufft |