Open Stack

On Mon, Jan 23, 2023, at 5:18 PM, 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.
>
> 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.

It is probably worth describing the two possible roles an account can have on a Pypi package: Owner and Maintainer [4]. Owners have full control, they can add and remove other owners/maintainers, publish and delete releases, and delete the project itself. Maintainers can only upload packages. What this means is that depending on whether or not openstackci is an owner it may not be able to remove files or releases. In those cases we would depend on the owner(s) to do so. For example openstackci cannot do these actions against octavia packages as openstackci is only a maintainer now.

Having backup accounts seems reasonable, but you need to configure them properly to be able to do what you describe.

This also means that for some packages openstackci cannot remove the other owners as proposed as it may not have sufficient permissions to do so.

Side note the pypi web UI seems to call both owners and maintainers "maintainers" when you view the main package page.

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

Maybe there is a middle ground where active maintainers can/should keep their pypi package permissions, but we clean up those who have moved on and aren't paying attention?

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

My main concern with doing this is that it requires users to opt into checking it because pip itself is never going to check the gpg signatures. It is better than nothing, but the vast majority of people running a pip install and pulling in random libraries from openstack as dependencies will never validate the signatures.

Another incomplete, but complementary tool, may be to use lockfiles that enforce more than our current constraints system does. I believe you can require specific package hashes on top of the versions. I'm not sure what is involved in converting from constraints to a lockfile though.

> 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

[4] https://pypi.org/help/#collaborator-roles