Hi Ghanshyam and TC, This process seems a bit uncomfortable to me and I think we should have a wider discussion on this topic. Full disclosure: I am the creator and maintainer of some projects on PyPi that openstackci releases packages to. Over the years since I created those projects and added openstackci to them, there have been multiple occasions where maintenance was required directly on PyPi (or via twine). This includes updating product descriptions, links, and as of last year enabling mandatory 2FA. As you probably know, not all of that has been possible (or just worked) via the setup.cfg/Readme in the code repository. Historically, I don't think anyone in infra or the release team has monitored the PyPi projects and maintained those settings on a regular basis. We pretty much leave it to the automated release tools and poke at it if something goes wrong. Historically part of the project creation steps required us to already have the PyPi projects setup[1] prior to attempting to become an OpenStack project. The "Project Creator Guide" (Which is no longer part of or linked from the OpenStack documentation[2], so maybe we aren't accepting new projects to OpenStack?) then had us add "openstackci" to the project if we were opting to have the release team release our packages. This is not a documented requirement that I am aware of and may be a gap caused by the openinfra split. It also seems odd that we would remove the project creator from their own project just for contributing it to OpenStack. We don't celebrate the effort and history of contributors or projects much anymore. I think there is value in having more than one account have access to the projects on PyPi. For one, if the openstackci account is compromised (via an insider or other), there is another account that can quickly disable the compromised account and yank a compromised release. Likewise, given the limited availability of folks with access to the openstackci account, there is value in having the project owner be able to yank a compromised release without waiting for folks to return from vacation, etc. All of that said, I see the security implications of having abandoned accounts or excessively wide access (the horizon case) to projects published on PyPi. I'm just not sure removing the project creator's access will really solve all of the issues around software traceability and OpenStack. Releases can still be pushed to PyPi maliciously via openstackci or PyPi compromise. I think we should also discuss the following improvements: 1. We PGP sign these releases with an OpenStack key, but we don't upload the .asc file with the packages to PyPi. Why don't we do this to help folks have an easy way to validate that the package came from the OpenStack releases process? 2. With these signatures, we can automate tools to validate that releases were signed by the OpenStack release process and raise an alert if they are invalid. 3. Maybe we should have a system that subscribes to the PyPi release history RSS feed for each managed OpenStack project and validates the RSS list against the releases repository information. This could then notify a release-team email list that an unexpected release has been posted to PyPi. Anyone should be able to subscribe to this list. 4. If we decide that removing maintainer access to projects is a barrier to adding them to OpenStack, we should document this clearly. I think we have some options to consider beyond the "remove everyone but openstackci from the project" or "kick the project out of OpenStack"[3]. Michael [1] https://github.com/openstack-archive/infra-manual/blob/caa430c1345f1c1aef179... [2] https://docs.openstack.org/zed/ [3] https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L17 On Fri, Jan 20, 2023 at 3:36 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
Hi PTLs,
As you might know or have seen for your project package on PyPi, OpenStack deliverables on PyPi have additional maintainers, For example, https://pypi.org/project/murano/, https://pypi.org/project/glance/
We should keep only 'openstackci' as a maintainer in PyPi so that releases of OpenStack deliverables can be managed in a single place. Otherwise, we might face the two sets of maintainers' places and packages might get released in PyPi by additional maintainers without the OpenStack project team knowing about it. One such case is in Horizon repo 'xstatic-font-awesome' where a new maintainer is added by an existing additional maintainer and this package was released without the Horizon team knowing about the changes and release. - https://github.com/openstack/xstatic-font-awesome/pull/2
To avoid the 'xstatic-font-awesome' case for other packages, TC discussed it in their weekly meetings[1] and agreed to audit all the OpenStack packages and then clean up the additional maintainers in PyPi (keep only 'openstackci' as maintainers).
To help in this task, TC requests project PTL to perform the audit for their project's repo and add comments in the below etherpad.
- https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Thanks to knikolla to automate the listing of the OpenStack packages with additional maintainers in PyPi which you can find the result in output.txt at the bottom of this link. I have added the project list of who needs to check their repo in etherpad.
- https://gist.github.com/knikolla/7303a65a5ddaa2be553fc6e54619a7a1
Please complete the audit for your project before March 15 so that TC can discuss the next step in vPTG.
[1] https://meetings.opendev.org/meetings/tc/2023/tc.2023-01-11-16.00.log.html#l...
-gmann