Open Stack

 ---- On Mon, 23 Jan 2023 17:18:27 -0800  Michael Johnson  wrote --- 
 > 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.

Thanks, Michael for all those good points. This will be great if we can automate
those manual updates. But for now, I will say we can have PTL can manage such
updates if needed by pinging 'openstackci' which is handled by opendev team.

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

We do appreciate their effort whether it is for the initial setup of PyPi or any
previous PTL/contributors who helped in OpenStack in anyways. I do not think
cleanup and centralizing the PyPi maintainer for all OpenStack packages will
delete/forget their work/effort.

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

Well, it can happen but having additional maintainers in PyPi is riskier
and we have encountered this for xstatic-font-awesome[1]. The horizon
team was not at all aware of changes and new releases of this package.

The challenge in maintaining additional maintainers is that we as the OpenStack
project governance, TC, release team, and infra team might lose control of
deliverables releases which are supposed to be handled by OpenStack. Those
additional maintainers who are active in OpenStack might not be in future and
we always forget to change the PyPi maintainers to someone actively maintaining
it in OpenStack. One option is to add PTL there but again this needs updates in
every cycle and also the same risk when PTL moves out of OpenStack.

To avoid those risks, we should centralize the PyPi maintainers list too
like other things (ML, code, release management 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].

"kick the project out of OpenStack", This is not like this. 2nd option means the project team
can discuss it with the additional maintainers to join the OpenStack team to maintain the
package in a single place. But if those additional maintainers are not ready to join
OpenStack for any reason we do not want to steal their effort and handover maintenance
outside of OpenStack is the right way to proceed in the open-source ecosystem. It needs to
be done with mutual understanding of the project team and those additional maintainers.
That way we can respect their effort and decision and build a good relationship in the
open-source world.

I think it is clear that nobody wants to keep any software package maintenance/release
in two different places and this is what we are trying to solve for OpenStack.

[1] https://github.com/openstack/xstatic-font-awesome/pull/2

-gmann


 > 
 > Michael
 > 
 > [1] https://github.com/openstack-archive/infra-manual/blob/caa430c1345f1c1aef17919f1c8d228dc652758b/doc/source/creators.rst#give-openstack-permission-to-publish-releases
 > [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 at 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-41
 > >
 > >
 > > -gmann
 > >
 > 
 >