Remove access from inactive maintainers

[Donald Stufft]

Hi!

I was talking to some people today about some attack vectors, and one thing that got surfaced in that there are a few people able to cut a release to PyPI for pip/virtualenv/etc who have stepped back from being involved in the project. What I would like to do is remove access from these people *not* because we’d be “kicking them out”, but simply as an effort to reduce the accounts that are possible targets for compromising pip. I think the ideal way of doing this is to simply say that if they decide to come back, they can have their access reinstated without question.

I also think it’d make sense to extend this same policy to Github teams (not the organization itself, being a member of the organization doesn’t grant any special privileges).

With that in mind, my proposal is to remove:

* From pip on PyPI: Jannis Leidel, Brian Rosner, Carl Meyer, Ian Backing, Marcus Smith

* From virtualenv on PyPI: Jannis Leidel, Brian Rosner, Carl Meyer, Ian Backing, Marcus Smith

* From packaging: Marcus Smith

That leaves able to do releases being me on all 3, and Matt Iverson (Ivoz) on virtualenv. It’s not great to have a single bus factor on these projects in case something happens to me, so I’d like to add Paul Moore and Xavier Fernandez on all three projects as releasers as well (I’m fine actually continuing to do the releases generally, just as a backup) assuming they’re both agreeable.

Then On Github I’d like to remove:

* From the pip team: Brian Rosner, Ian Bicking, Hugo Lopes Tavares, Carl Meyer, Marcus Smith, 

* From the virtualenv team: Brian Rosner, Ian Bicking, Carl Meyer, Marcus Smith

Then there are currently 4 Owners of the Github Org PyPA, Myself, Brian Rosner, Carl Meyer, and Marcus Smith. For this I’d like to remove all but myself, and similarly to PyPI I’d like to add Paul and Xavier as owners so it’s not just me (also assuming both are agreeable).

This should remove access from anyone who hasn’t (that I could find) been an active participant in > 1 year, with the stipulation that if they decide to come back they will be granted their previous access back— so this is merely just a technical solution to limit access. If anyone has any problems with this, please speak up!

I’ve also made sure I’ve BCC’d anyone who I’ve mentioned as losing some kind of access to this email in case they’re not subscribed to pypa-dev so that they will be aware and can speak up themselves (BCC instead of CC so they don’t get spammed with any replies if they don’t care).

Absent any objections, I’ll take these actions in the next couple of days (and I’ll need PyPI usernames for Paul and Xavier).

—
Donald Stufft

[Paul Moore]

On 5 June 2017 at 23:05, Donald Stufft <don...@stufft.io> wrote:
> Absent any objections, I’ll take these actions in the next couple of days
> (and I’ll need PyPI usernames for Paul and Xavier).

Fine with me (my PyPI username is pf_moore).
Paul

[Carl Meyer]

Fine by me! Thanks Donald.

Carl

[Xavier Fernandez]

Fine with me also and xafer is my username.

[Jason R. Coombs]

All fine by me.

Any reason I shouldn’t be an owner of PyPA and Setuptools shouldn’t inherit similar permissions to the other projects? I really don’t want it to be a special snowflake.

[Donald Stufft]

On Jun 6, 2017, at 2:53 PM, Jason R. Coombs <jar...@jaraco.com> wrote:

All fine by me.

Any reason I shouldn’t be an owner of PyPA and Setuptools shouldn’t inherit similar permissions to the other projects? I really don’t want it to be a special snowflake.

I don’t have a problem with you being an owner on the GH org. PyPA has always been in a bit of a weird place that it started out as a pip/virtualenv only org that got expanded out to covering the whole spectrum. In that vein, I was still thinking of who was active within pip for managing that.

So yea, totally fine with you being an owner. It doesn’t really affect the project itself much, being an owner mostly just gives you the rights/responsibility of managing teams/repos/etc when a new project gets added.

—
Donald Stufft