Following up on a discussion on #pypa-dev, re: https://pypi.org/project/twine/:

Personally, it'd be nice to be listed as a maintainer. It might also be nice to remove folks who have moved on.
It seems that only owners can do that. @di or @sigmavirus24 is that one of you?
Here's the breakdown between Maintainer/Owner:

@bhrutledge Happy to add you as a Maintainer as long as I can get a 2nd from another maintainer here.
Seems like we should remove @brainwane (who does not currently have the commit bit on this repo) and @theacodes (who has stepped back from the PyPA). I'm not sure what @dstufft considers his status to be, but I'm guessing he'd like to remain active.
Yes, please remove me - thanks!
Yes, please remove me - thanks!
I've removed you from PyPI and TestPyPI -- sorry to see you go!
Thanks. I know we'll all keep collaborating in different configurations over the decades. :-)
As firecat says in a different analogy, volunteers maintaining open source software are
like a chorus of people singing a continuous tone. If enough people sing, the tone will be continuous even though each of the singers will be stopping singing to take a breath every now and then. The way to change things is for more people to sing rather than for the same small group of people to try to sing louder and never breathe.
I'm very grateful to @bhrutledge for stepping up, and I hope someday we'll have more new co-maintainers so he and anyone else here will also be able to step away for a breath when he needs it too.
I would question the necessity of having the ability to push a PyPI package given that it's automated via Travis CI at this point. The list of "maintainers" (really an inaccurate term) on PyPI has no bearing on the actual maintainers of the project. What things need to be done in PyPI that require us to have terribly many people being able to access the package and its releases? That's N attack vectors with no way for a package owner to enforce policies (i.e., 2FA)
@sigmavirus24 That point does make sense to me as well. And I want to extend my appreciation to you, too, for welcoming me when I joined this project, and for your past work on it.
I agree, there's no real reason to add anyone as a Maintainer (with only the ability to upload new releases) aside from the fact that it's one of the few bits of recognition we can give to maintainers in exchange for their volunteer work.
That said, I propose we just make @bhrutledge an Owner on PyPI instead. If he's able to make releases, he should also be able to yank those releases if something has gone wrong. Same for @jaraco.
Feel free to remove me. I haven't completely renounced the PyPA, but I am
largely away from large open source stuff for mental health for a while.
On Mon, Jun 1, 2020 at 3:23 PM Dustin Ingram notifications@github.com
wrote:
I agree, there's no real reason to add anyone as a Maintainer (with only
the ability to upload new releases) aside from the fact that it's one of
the few bits of recognition we can give to maintainers in exchange for
their volunteer work.That said, I propose we just make @bhrutledge
https://github.com/bhrutledge an Owner on PyPI instead. If he's able to
make releases, he should also be able to yank those releases if something
has gone wrong. Same for @jaraco https://github.com/jaraco.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pypa/twine/issues/647#issuecomment-637156770, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5I46PCW46RYTZNMXVS7TRUQS4LANCNFSM4NPWQDJQ
.
Feel free to remove me. I haven't completely renounced the PyPA, but I am
largely away from large open source stuff for mental health for a while.
I've removed you for now, and I'm sorry to see you as well!
That said, I propose we just make @bhrutledge an Owner on PyPI instead. If he's able to make releases, he should also be able to yank those releases if something has gone wrong. Same for @jaraco.
There's a security principle (and this is somewhat security sensitive software) that there should be the principle of least privilege access for folks. We need to be far more conservative in who is an "owner" and "maintainer" etc.
Thinking about this frankly, and with no offense intended, I think we need to shrink ownership/maintainership to people actively working on Twine:
All of these people must be required (to verify since we can't enforce it) that they have 2FA enabled.
And remove the people who are tangentially involved or not involved at all who really don't need this access:
Dustin wrote:
I agree, there's no real reason to add anyone as a Maintainer (with only the ability to upload new releases) aside from the fact that it's one of the few bits of recognition we can give to maintainers in exchange for their volunteer work.
I've therefore opened #648 - let's hive off the recognition part from the PyPI privileges part, if that makes sense.
FWIW, if my or Donald's PyPI accounts are compromised, all projects on PyPI are compromised -- not just Twine. So it's kind of a moot point to remove us from any project in order to reduce the vulnerable "footprint" for that project.
To confirm - I have 2FA enabled on my PyPI account.
To confirm - I have 2FA enabled on my PyPI account.
Likewise.
Thanks for considering this (though I admit that my initial ask was partially out of vanity).
Should one outcome of this be updating the contributing instructions for adding a maintainer?
https://twine.readthedocs.io/en/latest/contributing.html#adding-a-maintainer
@bhrutledge Yes, I think that's a good idea.
@di There's maybe some possible compromises that isn't true for, I think user scoped tokens can only access uploads, so if one of those leaks it would be more secure, though that's a fairly niche case (particularly since I don't even use user scoped tokens).
That being said, feel free to remove me, I don't have any plans to release Twine.
That's true (I also don't use user-scoped tokens, though).