Open Stack

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