Having had some time to think this over, I will attempt to explain what the current process is, and how I believe I should change it. It's worth noting that I'm the only person who handles support issues for PyPI (years ago Martin von Lowis also did this, and Donald Stufft has handled one or two cases over the years). There's various reasons for this, not the least of which is that direct ssh/database access is often required to investigate ownership issues.
When someone requests to take over a listing on PyPI, the process is:
* If the request comes in through some means other than the sf.net support tracker, I require the requestor to make the request through that tracker so there is a record, * I ask whether they have contact the current owner, * I personally contact the owner through whatever means I have (sometimes this means using the address listed for the user in PyPI, sometimes that address is not valid so I use other means where possible), * If contact is made, I ask the current owner to grant the requestor ownership if they feel it is appropriate, * If contact is not made after one month, I add the requestor as an owner.
Between the support tracker and PyPI's audit log, all those actions are recorded.
However, in this instance, two things did not happen:
* I did not record that I had attempted to contact James in the tracker, and * I did not use the listed contact address for James in my attempt to contact him, rather using the address I had in my personal address book.
I cannot definitively explain why I didn't do the first step. On the second count though, I can only claim laziness combined with my usually handling these requests in a bunch at 5pm or later after a work day (basically, when I can find a few moments to deal with the backlog). Actually, I think I might have been in an airport transit lounge in that particular instance. It was just easier to use the address I knew than to go through the hoops to find out the correct address to use. Not trying to excuse myself, just explain.
There's been some suggestions made:
* Publicly announcing the intention to make the change is a good one, though again finding an appropriate forum that enough people would actually read is tricky. * Implement some sort of automated process. Given that we've struggled to produce Warehouse over *years* of development, I don't see this happening any time soon.
In light of this specific case, I have an additional change that I think I'll implement to attempt to prevent it again: In the instances where the current owner is unresponsive to my attempts to contact them, *and* the project has releases in the index, I will not transfer ownership. In the cases where no releases have been made I will continue to transfer ownership.
Your thoughts, as always, are welcome. Thanks to Danny for bringing the issue up, and to James and Alex for presenting their security concerns so clearly.
On 20 September 2014 04:47, Daniel Greenfeld firstname.lastname@example.org wrote:
In order to claim a package as being abandoned it should undergo a formal process that includes:
- Placement on a PUBLIC list of packages under review for a grace
period to be determined by this discussion
- Formal attempts via email and social media (twitter, github, et al)
to contact the maintainer.
- Investigation of the claimant for the rights to the package. The
parties attempting to claim a package may not be the best representatives of the community behind that package, or the Python community in general.
- Non-reply does not equal consent.
- Access to a commonly (or uncommonly) used package poses security and
I could claim ownership of the redis package, providing a certain-to-fail email for the maintainers of PyPI to investigate? Right now the process leads me to think I would succeed in gaining access. If successful, I would gain complete access to a package used by hundreds of projects for persistence storage.
I could claim ownership of the redis package, while Andy McCurdy (maintainer) was on vacation for two weeks, or sabbatical for six weeks. Again, I would gain access because under the current system non-reply equals consent.
In ticket #407 (https://sourceforge.net/p/pypi/support-requests/407/) someone who does not appear to be vetted managed to gain control of the (arguably) abandoned but still extremely popular django-registration on PyPI. They run one of several HUNDRED forks of django-registration, one that is arguably not the most commonly used.
My concern is that as django-registration is the leading package for handling system registration for Python's most popular web framework, handing it over without a full investigation of not just the current maintainer but also the candidate maintainer is risky.
Daniel Greenfeld email@example.com _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig