[Distutils] Create formal process for claiming 'abandoned' packages

[Toshio Kuratomi]

On Fri, Sep 19, 2014 at 9:26 PM, Richard Jones <richard at python.org> wrote:

> When someone requests to take over a listing on PyPI, the process is:
>i
> * 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,ard
> * 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),

This seems like the step where change would be most fruitful.  The
idea of a public list mentioned before allows a variety of feedback:

1) The maintainer themselves
2) People who know the maintainer and have an alternate method to contact them
3) Other people who know the project and can raise an objection to the
exact person who is being added as a new owner

Another thought here is that it's often best to use every means of
contacting someone that you reasonably have available.   So if there's
a valid mail in pypi and a valid email in your contacts, use both.
The public list idea essentially lets you crowdsource additional
methods of contacting the maintainer.

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

If there's no appropriate forum, starting a new one might be the best.
"Uploaders to pypi" could certainly be seen as an audience that
doesn't match well with any other existing mailing list.

>
> 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.
>
This is tricky.  There are certainly security issues with allowing
just anyone to take over a popular package at any time.  But there are
also security concerns with letting a package bitrot on pypi.  Say
that the 4 pypi maintainers of Django or the 6 pypi maintainers of pip
became unresponsive (it doesn't even have to be forever... that 6
month sabbatical could correspond with something happening to your
co-maintainers as well).  And the still active upstream project makes
a new security fix that they need to get into the hands of their users
ASAP.  We don't want pypi to block that update from going out.  Even
if the project creates a new pypi package name and uploads there,
would we really want the last package on pypi that all sorts of old
documentation and blog posts on the internet is pointing to to be the
insecure one?

So I don't think an absolute "we will never transfer ownership once
code is released" is a good idea here.  It's a good idea to increase
the means used to determine if the current maintainer can be reached
and it's a good idea to throw extra eyes at vetting whether a transfer
is warranted.  It may be a good idea to add more criteria around what
makes for an allowable transfer (for instance, in my examples, there's
still a large, well known canonical upstream even though the specific
members of that upstream responsible for uploading to pypi have gone
unresponsive.  That might be a valid criteria whereas one-coder
projects being replaced by other one-coder forks might be a case where
you simply say "rename please").

It could help to have other people involved in the decision making for
this.  At the least, having other people involved will spread
responsibility.  At best it gives the group additional man-hours to
research the facts in the case.


One final thought in regards to ticket 407.  My impression from
reading the notes is that this was not a complete invalidation of the
current process.  In the end, the current owner was alerted to the
takeover attempt and also was in a position to do something about it
since they disagreed with what was happening.  Those are both points
in favor of some pieces of the process (adding the new owner instead
of replacing the owner).  This might not be sufficient for a malicious
attack on a project but it does show that the process does have some
good features in terms of dealing with mistakes in communication.

-Toshio