On May 12, 2016 4:41 AM, "Donald Stufft" <donald@stufft.io> wrote:
> All in all, I think that there is not a whole lot of point to having this
> feature in PyPI, it is predicated a bunch of invalid assumptions (as detailed
> above) and I do not believe end users are actually even using the keys that
> are being uploaded. Last time I looked, pip, easy_install, and bandersnatch
> represented something like 99% of all download traffic on PyPI and none of
> those will do anything with the .asc files being uploaded to PyPI (other than
> bandersnatch just blindly mirroring it). When looking at the number of projects
> actively using this feature on PyPI, I can see that 27931/591919 files on PyPI
> have the ``has_signature`` database field set to true, or roughly 4% of all
> files on PyPI, which roughly holds up when you look at the number of distinct
> projects that have ever uploaded a signature as well (3559/80429).

Numpy is one of those projects that signs uploads, and it's utterly useless like you say -- we switch release managers on a regular basis, we don't have any communication of what the key is supposed to be... there are a few edge cases where I guess it could help a little (I actually would trust a version of requests signed by your key more than I would trust one signed by a just-invented key to no provenance, and there probably are a few people out there who check keys manually), but I agree it's almost pure cargo cult security.

My main concern when implementing this is how to communicate it to users, given that almost none of them understand security either, and that if this ends up on news sites like "pypi is dropping package security" then that hurts long term good will plus means confused folk showing up with pitchforks and eating up everyone's time. And honestly they would kind of have a point -- "we're getting rid of this thing that only kinda works now in favor of something amazing that doesn't exist yet" is just not a popular move. I guess the maximally time-efficient approach would be to be to just not mention gpg signatures or touch the relevant code again until TUF is ready, and then we can frame it as "we're switching to something better". Not sure how viable that is in practice though!

Maybe one way to kick this down the road a bit until there's time to deal with it properly would be to leave signature upload off on warehouse and tell people that for now that's still an imported legacy pypi only feature, you can continue uploading them there but we're still evaluating what we want to do with warehouse. I guess at some point this would become the last blocker to turning off legacy pypi and then some decision will have to be made, but maybe by that point things will be clearer?

Obviously you should do whatever you think will make the transition as fast and easy as possible though!