[ptl][tc] OpenStack packages PyPi additional external maintainers audit & cleanup
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
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.
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.
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.
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
On 2023-01-23 17:18:27 -0800 (-0800), Michael Johnson wrote: [...]
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 was removed because it became increasingly impossible to describe reliably. The maintainers for Warehouse (the software which currently implements PyPI) removed the old registration Web form and API methods which allowed pre-creation of projects in order to try to curb name squatting, but also made it so new projects are created automatically at initial upload. This means that in order to pre-create a project on PyPI these days, you have to manually create a minimal package and upload it. This became a significant blocker to people trying to add release jobs, so we made the decision to rely on release automation for project creation and advise new projects to tag or request an alpha release as early as possible in their formation.
- 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?
[...]
I wanted to do this from the very beginning, but the (then Cheeseshop, later Warehouse) maintainers repeatedly insisted that their opinion was the signature uploads provided no security benefit and they kept saying they were planning to remove that feature any day. Also during the transition from Cheeseshop to Warehouse, there was a span of several years where you could upload signatures but the WebUI didn't link to them anywhere so users couldn't easily find them anyway. When it became clear that work on PEP 458 had stalled out, they relented and made signatures accessible through Warehouse, but kept saying that was only a temporary measure which would be removed as soon as TUF was in place.
- 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.
[...]
We already upload them to tarballs.openstack.org and link them from the pages on releases.openstack.org, which should be sufficient to enable what you describe anyway without needing to also publish signatures to PyPI (the insistence that PyPI was removing signature uploading was a primary factor in our choice to continue hosting our own copies of release artifacts in the first place, for precisely this purpose).
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].
[...]
In the case of the project which triggered this discussion, it wasn't so much kicked out of OpenStack as the people in OpenStack with joint access to upload releases for it acknowledged that not everyone who was publishing releases wanted to do so from within OpenStack, so it's being relinquished to the other maintainers and OpenStack will carry a fork instead if it becomes necessary to do so in order to not have two different "official" sources of truth for one package.
---- 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:
- 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/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.
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.
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.
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
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:
- 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.
- 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 2023-01-25 16:46:03 -0800 (-0800), Clark Boylan wrote:
On Mon, Jan 23, 2023, at 5:18 PM, Michael Johnson wrote:
[...]
I think we should also discuss the following improvements:
- 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?
- 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.
[...]
I read this suggestion as having automation or some periodic task performed by the release managers or similar group, whereby our community checks new releases against available signatures rather than at install time.
Worth noting, the release team already periodically runs a script which audits all project tags to make sure we have all intended packages and signatures in the expected locations. It would theoretically be possible to just double check that there aren't any extra packages/releases on PyPI that don't correspond to release tags in our repositories or are otherwise anomalous (extra platform wheels, post versions, et cetera) or which differ from the ones on our tarballs site in some way. That should be sufficient to catch most possibilities without needing to actually retrieve every package so that the signatures for them can be validated directly.
I'm going to be honest, I'm a little frustrated that this isn't being treated as a severe security issue; because it is. Regardless of what people anecdotally say, there are a large number of operators who are installing and running openstack from pypi. Even larger still are developers -- like you and I -- installing openstack packages as our user anytime we run tox tests.
I'm not personally worried too much about the cases where an existing core or PTL is listed. I'm happy to have a policy argument in that context. That's not what's happening in the vast majority of these cases. For Ironic, of the 18 pypi artifacts we have; 14 have maintainers who are not currently core reviewers or openstack contributors on them -- and a handful of them have maintainers who I personally have never even heard of (we even have a `login.launchpad.net_154` as a maintainer on IPA). At any point in time, one of these people could[1] upload a malicious version of the package up to pypi and compromise any one of us who are unlucky enough to run `tox -r` locally before it's caught and rolled back.
I don't think packages that are managed by the OpenStack governance process should ever have a backdoor open to humans of any kind; but that's not the case we're arguing here. Right now, we have a large group of untrusted people with the ability to compromise our developers and users if they are not securing their pypi accounts well. This is especially true in an open source climate that is becoming more and more focused on supply chain risks. That is where my focus lies, and voting to remove those erroneous maintainers hastily is exactly the sort of decision I'd expect to be made by the Technical Committee -- even before I was elected to it (and if you disagree; I'm happy to only serve one term). We have to protect our users and our contributors.
Our focus must remain on closing this security hole. It does raise policy questions, but right now I'd rather us put out the fire rather than arguing about fire prevention tactics.
Thanks, Jay Faulkner TC Member Ironic PTL
Footnote: 1 - Arguably this has already happened once, in the case of xstatic-font-awesome -- we were just lucky that it was a good-faith release and not an actual compromised.
On Wed, Jan 25, 2023 at 7:12 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2023-01-25 16:46:03 -0800 (-0800), Clark Boylan wrote:
On Mon, Jan 23, 2023, at 5:18 PM, Michael Johnson wrote:
[...]
I think we should also discuss the following improvements:
- 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?
- 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.
[...]
I read this suggestion as having automation or some periodic task performed by the release managers or similar group, whereby our community checks new releases against available signatures rather than at install time.
Worth noting, the release team already periodically runs a script which audits all project tags to make sure we have all intended packages and signatures in the expected locations. It would theoretically be possible to just double check that there aren't any extra packages/releases on PyPI that don't correspond to release tags in our repositories or are otherwise anomalous (extra platform wheels, post versions, et cetera) or which differ from the ones on our tarballs site in some way. That should be sufficient to catch most possibilities without needing to actually retrieve every package so that the signatures for them can be validated directly. -- Jeremy Stanley
I agree with Jay's summary below wholeheartedly.
It is good that this issue has also highlighted other issues with the current maintainers&owners lists. The bottom line anyways is that the current state of affairs *must* change and a policy be created and kept in check going forward.
Radek -yoctozepto
On Thu, 26 Jan 2023 at 18:53, Jay Faulkner jay@gr-oss.io wrote:
I'm going to be honest, I'm a little frustrated that this isn't being treated as a severe security issue; because it is. Regardless of what people anecdotally say, there are a large number of operators who are installing and running openstack from pypi. Even larger still are developers -- like you and I -- installing openstack packages as our user anytime we run tox tests.
I'm not personally worried too much about the cases where an existing core or PTL is listed. I'm happy to have a policy argument in that context. That's not what's happening in the vast majority of these cases. For Ironic, of the 18 pypi artifacts we have; 14 have maintainers who are not currently core reviewers or openstack contributors on them -- and a handful of them have maintainers who I personally have never even heard of (we even have a `login.launchpad.net_154` as a maintainer on IPA). At any point in time, one of these people could[1] upload a malicious version of the package up to pypi and compromise any one of us who are unlucky enough to run `tox -r` locally before it's caught and rolled back.
I don't think packages that are managed by the OpenStack governance process should ever have a backdoor open to humans of any kind; but that's not the case we're arguing here. Right now, we have a large group of untrusted people with the ability to compromise our developers and users if they are not securing their pypi accounts well. This is especially true in an open source climate that is becoming more and more focused on supply chain risks. That is where my focus lies, and voting to remove those erroneous maintainers hastily is exactly the sort of decision I'd expect to be made by the Technical Committee -- even before I was elected to it (and if you disagree; I'm happy to only serve one term). We have to protect our users and our contributors.
Our focus must remain on closing this security hole. It does raise policy questions, but right now I'd rather us put out the fire rather than arguing about fire prevention tactics.
Thanks, Jay Faulkner TC Member Ironic PTL
Footnote: 1 - Arguably this has already happened once, in the case of xstatic-font-awesome -- we were just lucky that it was a good-faith release and not an actual compromised.
Thank you to everyone that has participated in this discussion. My hope was that the community could have a discussion around the issues and come up with some ideas beyond the "single maintainer" or "out of OpenStack" specified in the etherpad[1].
As I mentioned, and was highlighted by a few responses, removing additional maintainers from the projects doesn't fully solve the problem for our community. In fact it raises some new problems that were not previously discussed.
Let me summarize some of the issues/proposals for easier comment/discussion (please add/correct if I missed something):
1. Issue: There is currently no way to validate packages on PyPi (tar or wheel) are official OpenStack packages. a) PEP 458[2][3] - TUF for PyPi/pip does not exist yet. Development has slowed. b) PyPi has removed the capability to associate signatures with packages(beyond uploading an asc file) and does not display them in any way via the web UI. c) Some packagers include the pgp signature as ".asc" files associated with each package file uploaded. i) OpenStack does not do this today. Currently OpenStack only publishes pgp signatures on tarballs.opendev.org. ii) The tooling for working with PyPi doesn't use these signature files, so they are of minimal value. d) Question raised: Should we as the OpenStack community get involved in the PEP458 development to help move this forward? e) Question raised: Should we stop using PyPi as it does not provide software traceability? PyPi has had a lot of press recently about issues with look-alike packes, etc.[4][5][6] f) Question raised: Should we develop some OpenStack tooling that provides the required packaged validation? Either via pulling signatures from tarballs.o.o or pulling OpenStack packages from tarballs.o.o directly. g) Question raised: Should we use lockfiles (pipfile/pipfile.lock)[4] to provide hash validation of packages? h) Question raised: Should we start providing hashes in requirements.txt to allow "hash-checking mode"[5]?
2. Issue: There is no documentation for how to add a service to OpenStack on the OpenStack website any longer and no policy on what it means for artifacts transitioning to OpenStack management. a) Historically not all OpenStack services were required to be managed via the release team process. It was not a problem for PTLs to push tags and publish releases via alternate processes. b) Question raised: Should this change and all OpenStack services be required to use the release process? c) Question raised: Should we clearly call out all associated services (PyPi, github, snyk, twitter, grafana, docker hub, quay, etc.) will become solely managed by OpenStack? d) Question raised: Should we bring back a link to the "project creator" section of the docs.opendev.org or do we need an OpenStack specific guide?
3. Issue: Current and historical documentation[9] for project teams management of PyPi projects has stated that "openstackci" should not have "Owner" access to the project, just "Maintainer". a) The "Maintainer" role allows "openstackci" to publish packages.[10[ b) The "Maintainer" role does not allow the deletion of packages, the project, or the removal of other maintainers.[10] c) Question raised: Does "openstackci" even have the required permission to remove the other maintainers? d) Question raised: Do we need to create/correct proper documentation for project management on PyPi?
4. Issue: Removing maintainers other than "openstackci" creates a single point of management. a) Resources available in OpenStack are declining and response times for infrastructure issues are rising[11][12]. b) Even with current openstackci access, many of these PyPi projects have not been maintained by "openstackci" resources, but at least some have been maintained by the other maintainers. i) Some projects still have "openstackjenkins" maintainers[13] that were never cleaned up. ii) Have all projects with "openstackci" access been updated to require 2FA? (I turned this on for the Octavia projects I maintain long ago) iii) The issue with another group having access to the project highlights that we might not have resources to actively manage all of these projects[14]. c) If (when if you are a security person) the "openstackci" account is compromised (insider or other), we would be locked out of all of these projects. d) In OpenStack we distribute the work and responsibility to trusted parties (PTLs, core reviews, liaisons, etc.), moving to a single account for PyPi would not allow this pattern. e) Question raised: Could we provide an option 3 where we leave access for active maintainers if the PTL approves? f) Question raised: Should we have secondary accounts for services like this that are held in escrow in case we have a compromise of the primary account? g) Question raised: Can we setup an automated system where the current PTL can get access to the project on PyPi for a period of time? h) Why isn't the release/"openstackci" account a lower permission account used for the release process only instead of a "root" style account? (related to question "f") above. i) The good news is, even with the above issues, someone did see a notification of a maintainer list change to one of these projects. We don't get notifications of releases, but we do get notifications of maintainer list changes.
5. Issue: We have no audit checks in place to identify rogue releases on PyPi. a) Even with the change to only allowing "openstackci" as a maintainer, a compromised "openstackci" or PyPi could still release compromised packages. b) Proposal: Update the existing release team audit script to also audit the PyPi packages for unexpected packages (tar, wheel, etc.).
There are a lot of questions here to work through and I hope they are a topic for future TC/community discussion.
Here is what I would do: 1. Give the PTLs the option to leave some maintainers on the packages as appropriate until we have additional infrastructure in place. Remove the other "maintainers/owners" from the projects. 2. Immediately audit the "openstackci" access to see what level of permission we have on the projects. We may need to find people or escalate with the PyPi admins to fix this. It's not a simple "maintainer" or not. 3. Create OpenStack documentation for how access to PyPi projects is expected to work (either in the release team docs, or a new section to replace the project creator guide). If we want to use the opendev.org docs, we need to relink those into the OpenStack docs and correct the issues with the instructions. 4. We should create another account in all of the OpenStack managed projects that will assume the "owner" role. Access to this account should be separate (escrowed?) from the other maintainer accounts. 5. The "openstackci" accounts should all be dropped to "maintainer" level permissions, allowing releases, but no destructive actions. 6. Create a documented action plan for who/how a package can be pulled from PyPi in the case of a compromised package was released or the automated release process had a failure. 7. Update the release team audit script to also check PyPi for rogue releases, preferably by also checking the hash. This may uncover existing problem releases we do not know about yet. 8. Automate the above audit script to run regularly or document a schedule it will be run by the release team. 9. Audit that all of the OpenStack projects on PyPi have 2FA required. This is a per-project setting on PyPi. 10. Start work on developing an automated system where PTLs can get owner level access, for a period of time, to address the issues the individual maintainers have done historically. This would at least provide an audit log and allow us to spread the work. 11. Form a task team to evaluate if we should get involved in the PEP 458 work or if using one of the hash validation tools would be feasible as part of our requirements process.
Michael
[1] https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L17 [2] https://peps.python.org/pep-0458/ [3] https://github.com/pypi/warehouse/issues/10672 [4] https://thenewstack.io/poisoned-lolip0p-pypi-packages/ [5] https://www.theregister.com/2023/01/09/pypi_aws_malware_key/ [6] https://www.securityweek.com/security-firms-find-over-20-malicious-pypi-pack... [7] https://pypi.org/project/pipfile/ [8] https://pip.pypa.io/en/stable/topics/secure-installs/#hash-checking-mode [9] https://docs.opendev.org/opendev/infra-manual/latest/creators.html#give-open... [10] https://pypi.org/help/#collaborator-roles [11] https://review.opendev.org/c/opendev/system-config/+/795596 [12] https://review.opendev.org/c/openinfra/openstack-map/+/840774 [13] https://pypi.org/user/openstackjenkins/ [14] https://github.com/openstack/xstatic-font-awesome/pull/2
On Thu, Jan 26, 2023 at 10:31 AM Radosław Piliszek radoslaw.piliszek@gmail.com wrote:
I agree with Jay's summary below wholeheartedly.
It is good that this issue has also highlighted other issues with the current maintainers&owners lists. The bottom line anyways is that the current state of affairs *must* change and a policy be created and kept in check going forward.
Radek -yoctozepto
On Thu, 26 Jan 2023 at 18:53, Jay Faulkner jay@gr-oss.io wrote:
I'm going to be honest, I'm a little frustrated that this isn't being treated as a severe security issue; because it is. Regardless of what people anecdotally say, there are a large number of operators who are installing and running openstack from pypi. Even larger still are developers -- like you and I -- installing openstack packages as our user anytime we run tox tests.
I'm not personally worried too much about the cases where an existing core or PTL is listed. I'm happy to have a policy argument in that context. That's not what's happening in the vast majority of these cases. For Ironic, of the 18 pypi artifacts we have; 14 have maintainers who are not currently core reviewers or openstack contributors on them -- and a handful of them have maintainers who I personally have never even heard of (we even have a `login.launchpad.net_154` as a maintainer on IPA). At any point in time, one of these people could[1] upload a malicious version of the package up to pypi and compromise any one of us who are unlucky enough to run `tox -r` locally before it's caught and rolled back.
I don't think packages that are managed by the OpenStack governance process should ever have a backdoor open to humans of any kind; but that's not the case we're arguing here. Right now, we have a large group of untrusted people with the ability to compromise our developers and users if they are not securing their pypi accounts well. This is especially true in an open source climate that is becoming more and more focused on supply chain risks. That is where my focus lies, and voting to remove those erroneous maintainers hastily is exactly the sort of decision I'd expect to be made by the Technical Committee -- even before I was elected to it (and if you disagree; I'm happy to only serve one term). We have to protect our users and our contributors.
Our focus must remain on closing this security hole. It does raise policy questions, but right now I'd rather us put out the fire rather than arguing about fire prevention tactics.
Thanks, Jay Faulkner TC Member Ironic PTL
Footnote: 1 - Arguably this has already happened once, in the case of xstatic-font-awesome -- we were just lucky that it was a good-faith release and not an actual compromised.
Michael Johnson wrote:
[...] 2. Issue: There is no documentation for how to add a service to OpenStack on the OpenStack website any longer and no policy on what it means for artifacts transitioning to OpenStack management. a) Historically not all OpenStack services were required to be managed via the release team process. It was not a problem for PTLs to push tags and publish releases via alternate processes. b) Question raised: Should this change and all OpenStack services be required to use the release process?
It is actually a documented requirement for OpenStack projects that "releases of OpenStack deliverables are handled by the OpenStack Release Management team through the openstack/releases repository. Official projects are expected to relinquish direct tagging (and branch creation) rights in their Gerrit ACLs once their release jobs are functional."
See https://governance.openstack.org/tc/reference/new-projects-requirements.html
The release team delegates release management for some deliverables that use different toolchains (tagged "release-management: external" in governance) like for example OpenStack Charms. And some deliverables are just not released (tagged "release-management: none"). But the default is already to have all services follow the release management process.
---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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.
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.
Hello Everyone,
To update, there is an extra step for project PTLs in this task:
* Step 1.1: Project PTL/team needs to communicate to the additional maintainers about removing themselves and transferring ownership to 'openstackci' - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L23
Initially, TC thought we could do a cleanup with the help of openstackci admin for all repo. But, to avoid any issue or misunderstanding/panic among additional maintainers on removal, it is better that projects communicate with additional maintainers and ask them to remove themself. JayF sent the email format to communicate to additional maintainers[1]. Please use that and let TC know if any queries/issues you are facing.
[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.ht...
-gmann
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.
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
Hi Everyone,
Posting top of the email.
I am listing the projects that have not updated the status in etherpad; if you have any progress, please write in etherpad. If not request you to plan the same while in vPTG?
- https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L43
* adjutant * barbican * cloudkitty * cyborg * designate * ec2-api * freezer * heat * kuryr * mistral * monasca * murano * octavia * OpenStackSDK * oslo * rally * Release Management * requirements * sahara * senlin * skyline * solum * storlets * swift * tacker * Telemetry * trove * vitrage * watcher * winstackers * zaqar * zun
-gmann
---- On Wed, 22 Mar 2023 08:45:49 -0700 Ghanshyam Mann wrote ---
---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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.
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.
Hello Everyone,
To update, there is an extra step for project PTLs in this task:
- Step 1.1: Project PTL/team needs to communicate to the additional maintainers about removing themselves
and transferring ownership to 'openstackci'
Initially, TC thought we could do a cleanup with the help of openstackci admin for all repo. But, to avoid any issue or misunderstanding/panic among additional maintainers on removal, it is better that projects communicate with additional maintainers and ask them to remove themself. JayF sent the email format to communicate to additional maintainers[1]. Please use that and let TC know if any queries/issues you are facing.
[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.ht...
-gmann
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.
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
Hello Everyone,
It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these.
- barbican - blazar - cinder - cloudkitty - cyborg - designate - ec2-api - freezer - glance - heat - horizon - ironic - keystone - kolla - kuryr - magnum - manila - mistral - monasca - murano - neutron - OpenStackSDK - oslo - Quality Assurance - rally - sahara - senlin - skyline - solum - storlets - swift - tacker - Telemetry - trove - vitrage - watcher - zaqar - zun
-gmann
---- On Wed, 29 Mar 2023 08:15:33 -0700 Ghanshyam Mann wrote ---
Hi Everyone,
Posting top of the email.
I am listing the projects that have not updated the status in etherpad; if you have any progress, please write in etherpad. If not request you to plan the same while in vPTG?
- adjutant
- barbican
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- heat
- kuryr
- mistral
- monasca
- murano
- octavia
- OpenStackSDK
- oslo
- rally
- Release Management
- requirements
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- winstackers
- zaqar
- zun
-gmann
---- On Wed, 22 Mar 2023 08:45:49 -0700 Ghanshyam Mann wrote ---
---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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.
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.
Hello Everyone,
To update, there is an extra step for project PTLs in this task:
- Step 1.1: Project PTL/team needs to communicate to the additional maintainers about removing themselves
and transferring ownership to 'openstackci'
Initially, TC thought we could do a cleanup with the help of openstackci admin for all repo. But, to avoid any issue or misunderstanding/panic among additional maintainers on removal, it is better that projects communicate with additional maintainers and ask them to remove themself. JayF sent the email format to communicate to additional maintainers[1]. Please use that and let TC know if any queries/issues you are facing.
[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.ht...
-gmann
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.
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
Hi,
For Cinder, we have 7 repos out of which 5 have been cleaned up. The ones that require cleanup are:
1. os-brick Maintainer: thingee (Mike Perez)
2. python-brick-cinderclient-ext Maintainer: e0ne (Ivan Kolodyazhny)
Both are not active cinder project members and haven't been around for years. I tried reaching out but didn't get any response. If possible, the TC can go ahead and remove them since the second maintainer is openstackci.
Thanks Rajat Dhasmana
On Sat, Mar 16, 2024 at 10:27 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
Hello Everyone,
It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these.
- barbican
- blazar
- cinder
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- glance
- heat
- horizon
- ironic
- keystone
- kolla
- kuryr
- magnum
- manila
- mistral
- monasca
- murano
- neutron
- OpenStackSDK
- oslo
- Quality Assurance
- rally
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- zaqar
- zun
-gmann
---- On Wed, 29 Mar 2023 08:15:33 -0700 Ghanshyam Mann wrote ---
Hi Everyone,
Posting top of the email.
I am listing the projects that have not updated the status in etherpad;
if you have any progress, please write in etherpad. If not
request you to plan the same while in vPTG?
- adjutant
- barbican
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- heat
- kuryr
- mistral
- monasca
- murano
- octavia
- OpenStackSDK
- oslo
- rally
- Release Management
- requirements
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- winstackers
- zaqar
- zun
-gmann
---- On Wed, 22 Mar 2023 08:45:49 -0700 Ghanshyam Mann wrote ---
---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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.
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
Hello Everyone,
To update, there is an extra step for project PTLs in this task:
- Step 1.1: Project PTL/team needs to communicate to the additional
maintainers about removing themselves
and transferring ownership to 'openstackci'
https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L23
Initially, TC thought we could do a cleanup with the help of
openstackci admin for all repo. But, to avoid any issue
or misunderstanding/panic among additional maintainers on removal,
it is better that projects communicate with
additional maintainers and ask them to remove themself. JayF sent
the email format to communicate to additional
maintainers[1]. Please use that and let TC know if any
queries/issues you are facing.
[1]
https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.ht...
-gmann
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
---- On Sun, 17 Mar 2024 23:33:30 -0700 Rajat Dhasmana wrote ---
Hi, For Cinder, we have 7 repos out of which 5 have been cleaned up.The ones that require cleanup are: 1. os-brickMaintainer: thingee (Mike Perez) 2. python-brick-cinderclient-extMaintainer: e0ne (Ivan Kolodyazhny) Both are not active cinder project members and haven't been around for years.I tried reaching out but didn't get any response.If possible, the TC can go ahead and remove them since the second maintainer is openstackci. ThanksRajat Dhasmana On Sat, Mar 16, 2024 at 10:27 AM Ghanshyam Mann gmann@ghanshyammann.com> wrote: Hello Everyone,
It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these.
Ack Rajat, thanks for the cleanup and response. I will make a note of it and if openstackci has required right on removing them then we will do it.
-gmann
- barbican
- blazar
- cinder
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- glance
- heat
- horizon
- ironic
- keystone
- kolla
- kuryr
- magnum
- manila
- mistral
- monasca
- murano
- neutron
- OpenStackSDK
- oslo
- Quality Assurance
- rally
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- zaqar
- zun
-gmann
---- On Wed, 29 Mar 2023 08:15:33 -0700 Ghanshyam Mann wrote --- > Hi Everyone, > > Posting top of the email. > > I am listing the projects that have not updated the status in etherpad; if you have any progress, please write in etherpad. If not > request you to plan the same while in vPTG? > > - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L43 > > * adjutant > * barbican > * cloudkitty > * cyborg > * designate > * ec2-api > * freezer > * heat > * kuryr > * mistral > * monasca > * murano > * octavia > * OpenStackSDK > * oslo > * rally > * Release Management > * requirements > * sahara > * senlin > * skyline > * solum > * storlets > * swift > * tacker > * Telemetry > * trove > * vitrage > * watcher > * winstackers > * zaqar > * zun > > -gmann > > ---- On Wed, 22 Mar 2023 08:45:49 -0700 Ghanshyam Mann wrote --- > > ---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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 > > > > Hello Everyone, > > > > To update, there is an extra step for project PTLs in this task: > > > > * Step 1.1: Project PTL/team needs to communicate to the additional maintainers about removing themselves > > and transferring ownership to 'openstackci' > > - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L23 > > > > Initially, TC thought we could do a cleanup with the help of openstackci admin for all repo. But, to avoid any issue > > or misunderstanding/panic among additional maintainers on removal, it is better that projects communicate with > > additional maintainers and ask them to remove themself. JayF sent the email format to communicate to additional > > maintainers[1]. Please use that and let TC know if any queries/issues you are facing. > > > > [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.ht... > > > > -gmann > > > > > > > > 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 > > > > > > > > > > > >
Hi,
On 3/16/24 12:52 AM, Ghanshyam Mann wrote:
Hello Everyone,
It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these.
<snip>
- neutron
From reading the etherpad notes and looking at the pypi pages, it seems there are some projects where the additional maintainers have not responded and/or removed themselves, so I am fine with the TC doing it manually.
- neutron-lib: Ok to remove additional maintainers --> Mantainers to be removed: dougw
- neutron-vpnaas (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: login.launchpad.net_179
- networking-bagpipe (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: tmmorin
- networking-odl (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: asomya, mkolesni and yamahata
- networking-sfc (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: cathy.h.zhang
Thanks,
-Brian, Neutron PTL
---- On Mon, 18 Mar 2024 07:52:34 -0700 Brian Haley wrote ---
Hi,
On 3/16/24 12:52 AM, Ghanshyam Mann wrote:
Hello Everyone,
It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these.
- neutron
From reading the etherpad notes and looking at the pypi pages, it seems there are some projects where the additional maintainers have not responded and/or removed themselves, so I am fine with the TC doing it manually.
neutron-lib: Ok to remove additional maintainers --> Mantainers to be removed: dougw
neutron-vpnaas (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: login.launchpad.net_179
networking-bagpipe (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: tmmorin
networking-odl (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: asomya, mkolesni and yamahata
networking-sfc (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: cathy.h.zhang
Ack Brian, Thanks for the updates and for reaching out to them. I will make a note of it and see if we can cleanup those repo.
-gmann
Thanks,
-Brian, Neutron PTL
Hi, For the above networking projects where I was able to find an email address I sent out mail to ask them to remove themselves from pypi maintainer list.
Lajos Katona (lajoskatona)
Ghanshyam Mann gmann@ghanshyammann.com ezt írta (időpont: 2024. márc. 18., H, 19:19):
---- On Mon, 18 Mar 2024 07:52:34 -0700 Brian Haley wrote ---
Hi,
On 3/16/24 12:52 AM, Ghanshyam Mann wrote:
Hello Everyone,
It has been a long time since I followed up on this. You might
remember the effort to cleanup the
additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos.
I have added the
data to etherpad also -
https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need
maintainers' cleanup. I will
appreciate if you can give another try to cleanup these.
- neutron
From reading the etherpad notes and looking at the pypi pages, it
seems
there are some projects where the additional maintainers have not responded and/or removed themselves, so I am fine with the TC doing it manually.
neutron-lib: Ok to remove additional maintainers --> Mantainers to be removed: dougw
neutron-vpnaas (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: login.launchpad.net_179
networking-bagpipe (Neutron Stadium): Ok to remove additional
maintainers
--> Mantainers to be removed: tmmorin
networking-odl (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: asomya, mkolesni and yamahata
networking-sfc (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: cathy.h.zhang
Ack Brian, Thanks for the updates and for reaching out to them. I will make a note of it and see if we can cleanup those repo.
-gmann
Thanks,
-Brian, Neutron PTL
Hi,
For Glance we have 4 repos out of which only glance_store needs cleanup. I tried reaching out to the additional maintainer but didn't get any response. So I am fine with the TC doing it manually.
Thanks, Pranali Deore
On Wed, Mar 20, 2024 at 3:50 PM Lajos Katona katonalala@gmail.com wrote:
Hi, For the above networking projects where I was able to find an email address I sent out mail to ask them to remove themselves from pypi maintainer list.
Lajos Katona (lajoskatona)
Ghanshyam Mann gmann@ghanshyammann.com ezt írta (időpont: 2024. márc. 18., H, 19:19):
---- On Mon, 18 Mar 2024 07:52:34 -0700 Brian Haley wrote ---
Hi,
On 3/16/24 12:52 AM, Ghanshyam Mann wrote:
Hello Everyone,
It has been a long time since I followed up on this. You might
remember the effort to cleanup the
additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos.
I have added the
data to etherpad also -
https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need
maintainers' cleanup. I will
appreciate if you can give another try to cleanup these.
- neutron
From reading the etherpad notes and looking at the pypi pages, it
seems
there are some projects where the additional maintainers have not responded and/or removed themselves, so I am fine with the TC doing it manually.
neutron-lib: Ok to remove additional maintainers --> Mantainers to be removed: dougw
neutron-vpnaas (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: login.launchpad.net_179
networking-bagpipe (Neutron Stadium): Ok to remove additional
maintainers
--> Mantainers to be removed: tmmorin
networking-odl (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: asomya, mkolesni and yamahata
networking-sfc (Neutron Stadium): Ok to remove additional maintainers --> Mantainers to be removed: cathy.h.zhang
Ack Brian, Thanks for the updates and for reaching out to them. I will make a note of it and see if we can cleanup those repo.
-gmann
Thanks,
-Brian, Neutron PTL
---- On Mon, 25 Mar 2024 22:51:24 -0700 Pranali Deore wrote ---
Hi, For Glance we have 4 repos out of which only glance_store needs cleanup. I tried reaching out to the additional maintainer but didn't get any response. So I am fine with the TC doing it manually.
Ack, Thanks Pranali for checking.
-gmann
Thanks,Pranali Deore On Wed, Mar 20, 2024 at 3:50 PM Lajos Katona katonalala@gmail.com> wrote: Hi,For the above networking projects where I was able to find an email address I sent out mail to ask them to remove themselvesfrom pypi maintainer list. Lajos Katona (lajoskatona) Ghanshyam Mann gmann@ghanshyammann.com> ezt írta (időpont: 2024. márc. 18., H, 19:19): ---- On Mon, 18 Mar 2024 07:52:34 -0700 Brian Haley wrote --- > Hi, > > On 3/16/24 12:52 AM, Ghanshyam Mann wrote: > > Hello Everyone, > > > > It has been a long time since I followed up on this. You might remember the effort to cleanup the > > additional external maintainers from OpenStack PyPi packages. > > > > We are still left with 110 maintainers to be removed from 232 repos. I have added the > > data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup > > > > Below is the latest project list where one or more repos need maintainers' cleanup. I will > > appreciate if you can give another try to cleanup these. > > > > > > - neutron > > From reading the etherpad notes and looking at the pypi pages, it seems > there are some projects where the additional maintainers have not > responded and/or removed themselves, so I am fine with the TC doing it > manually. > > - neutron-lib: Ok to remove additional maintainers > --> Mantainers to be removed: dougw > > - neutron-vpnaas (Neutron Stadium): Ok to remove additional maintainers > --> Mantainers to be removed: login.launchpad.net_179 > > - networking-bagpipe (Neutron Stadium): Ok to remove additional maintainers > --> Mantainers to be removed: tmmorin > > - networking-odl (Neutron Stadium): Ok to remove additional maintainers > --> Mantainers to be removed: asomya, mkolesni and yamahata > > - networking-sfc (Neutron Stadium): Ok to remove additional maintainers > --> Mantainers to be removed: cathy.h.zhang
Ack Brian, Thanks for the updates and for reaching out to them. I will make a note of it and see if we can cleanup those repo.
-gmann
> > Thanks, > > -Brian, Neutron PTL >
On Fri, 2024-03-15 at 21:52 -0700, Ghanshyam Mann wrote:
Hello Everyone,
It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these.
- barbican
- blazar
- cinder
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- glance
- heat
- horizon
- ironic
- keystone
- kolla
- kuryr
- magnum
- manila
- mistral
- monasca
- murano
- neutron
- OpenStackSDK
I noted all this on the Etherpad when this last came up, but to repeat: please remove anyone != openstackci from the projects owned by the OpenstackSDK team.
- oslo
As above, please remove everyone != openstackci en masse from the oslo-owned projects.
(tbh, I'd adopt a position of EAFP and remove non-openstackci maintainers from _all_ official OpenStack projects that openstackci is a maintainer of but I'm assuming there's a good reason for jumping through these hoops).
Cheers, Stephen
- Quality Assurance
- rally
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- zaqar
- zun
-gmann
---- On Wed, 29 Mar 2023 08:15:33 -0700 Ghanshyam Mann wrote ---
Hi Everyone,
Posting top of the email.
I am listing the projects that have not updated the status in etherpad; if you have any progress, please write in etherpad. If not request you to plan the same while in vPTG?
- adjutant
- barbican
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- heat
- kuryr
- mistral
- monasca
- murano
- octavia
- OpenStackSDK
- oslo
- rally
- Release Management
- requirements
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- winstackers
- zaqar
- zun
-gmann
---- On Wed, 22 Mar 2023 08:45:49 -0700 Ghanshyam Mann wrote ---
---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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.
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.
Hello Everyone,
To update, there is an extra step for project PTLs in this task:
- Step 1.1: Project PTL/team needs to communicate to the additional maintainers about removing themselves
and transferring ownership to 'openstackci'
Initially, TC thought we could do a cleanup with the help of openstackci admin for all repo. But, to avoid any issue or misunderstanding/panic among additional maintainers on removal, it is better that projects communicate with additional maintainers and ask them to remove themself. JayF sent the email format to communicate to additional maintainers[1]. Please use that and let TC know if any queries/issues you are facing.
[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.ht...
-gmann
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.
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
---- On Tue, 19 Mar 2024 10:14:40 -0700 Stephen Finucane wrote ---
On Fri, 2024-03-15 at 21:52 -0700, Ghanshyam Mann wrote:
Hello Everyone,
It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these.
- barbican
- blazar
- cinder
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- glance
- heat
- horizon
- ironic
- keystone
- kolla
- kuryr
- magnum
- manila
- mistral
- monasca
- murano
- neutron
- OpenStackSDK
I noted all this on the Etherpad when this last came up, but to repeat: please remove anyone != openstackci from the projects owned by the OpenstackSDK team.
- oslo
As above, please remove everyone != openstackci en masse from the oslo-owned projects.
ack.
(tbh, I'd adopt a position of EAFP and remove non-openstackci maintainers from _all_ official OpenStack projects that openstackci is a maintainer of but I'm assuming there's a good reason for jumping through these hoops).
That is going to be the next step at least where openstackci is the owner and we can do the cleanup but the main purpose of doing it via external maintainers/PTL/project leaders' email communication/self-cleanup was to avoid any chaos.
But as we have done that, it should be ok to do the rest of the cleanup directly. We will discuss it in PTG to check if any objection to that approach.
-gmann
Cheers, Stephen
- Quality Assurance
- rally
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- zaqar
- zun
-gmann
---- On Wed, 29 Mar 2023 08:15:33 -0700 Ghanshyam Mann wrote ---
Hi Everyone,
Posting top of the email.
I am listing the projects that have not updated the status in etherpad; if you have any progress, please write in etherpad. If not request you to plan the same while in vPTG?
- adjutant
- barbican
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- heat
- kuryr
- mistral
- monasca
- murano
- octavia
- OpenStackSDK
- oslo
- rally
- Release Management
- requirements
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- winstackers
- zaqar
- zun
-gmann
---- On Wed, 22 Mar 2023 08:45:49 -0700 Ghanshyam Mann wrote ---
---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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.
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.
Hello Everyone,
To update, there is an extra step for project PTLs in this task:
- Step 1.1: Project PTL/team needs to communicate to the additional maintainers about removing themselves
and transferring ownership to 'openstackci'
Initially, TC thought we could do a cleanup with the help of openstackci admin for all repo. But, to avoid any issue or misunderstanding/panic among additional maintainers on removal, it is better that projects communicate with additional maintainers and ask them to remove themself. JayF sent the email format to communicate to additional maintainers[1]. Please use that and let TC know if any queries/issues you are facing.
[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.ht...
-gmann
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.
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
On 16/3/2024 3:52 pm, Ghanshyam Mann wrote:
Hello Everyone,
It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages.
Thanks for doing this work. Often times security is thankless nagging, but it is still important. :)
Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these.
<snip> - magnum <snip>
From etherpad
https://pypi.org/project/magnum/ State on 2024-03-18: Only openstackci https://pypi.org/project/magnum-ui/ State on 2024-03-18: bradjones and openstackci -> Please remove bradjones https://pypi.org/project/python-magnumclient/ State on 2024-03-18: aotto and openstackci -> Please remove aotto https://pypi.org/project/openstack-magnum/ State on 2024-03-18: aotto and openstackci -> Please remove aotto
We've previously managed to contact aotto who is fine with us removing. bradjones hasn't been active for a while, so they can be removed too. If TC can help to remove them that would be great.
(in addition to that there's openstack-magnum pypi package with openstackci as maintainer not updated since 2016, maybe we shoud clean up?)
Yes this is an old unmaintained clone which should be removed too, given the types of attacks via PyPi nowadays.
Once again, thanks!
Regards, Jake (Magnum PTL)
For Kolla we have two repos with sdake (original project creator/maintainer) having access to kolla and kolla-ansible pypi packages.
I tried reaching out three times already - no response - therefore I think his access should be just removed.
Best regards,
Michał Nasiadka mnasiadka@gmail.com
W dniu sob., 16.03.2024 o 05:58 Ghanshyam Mann gmann@ghanshyammann.com napisał(a):
Hello Everyone,
It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these.
- barbican
- blazar
- cinder
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- glance
- heat
- horizon
- ironic
- keystone
- kolla
- kuryr
- magnum
- manila
- mistral
- monasca
- murano
- neutron
- OpenStackSDK
- oslo
- Quality Assurance
- rally
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- zaqar
- zun
-gmann
---- On Wed, 29 Mar 2023 08:15:33 -0700 Ghanshyam Mann wrote ---
Hi Everyone,
Posting top of the email.
I am listing the projects that have not updated the status in etherpad;
if you have any progress, please write in etherpad. If not
request you to plan the same while in vPTG?
- adjutant
- barbican
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- heat
- kuryr
- mistral
- monasca
- murano
- octavia
- OpenStackSDK
- oslo
- rally
- Release Management
- requirements
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- winstackers
- zaqar
- zun
-gmann
---- On Wed, 22 Mar 2023 08:45:49 -0700 Ghanshyam Mann wrote ---
---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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.
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
Hello Everyone,
To update, there is an extra step for project PTLs in this task:
- Step 1.1: Project PTL/team needs to communicate to the additional
maintainers about removing themselves
and transferring ownership to 'openstackci'
https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L23
Initially, TC thought we could do a cleanup with the help of
openstackci admin for all repo. But, to avoid any issue
or misunderstanding/panic among additional maintainers on removal,
it is better that projects communicate with
additional maintainers and ask them to remove themself. JayF sent
the email format to communicate to additional
maintainers[1]. Please use that and let TC know if any
queries/issues you are facing.
[1]
https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.ht...
-gmann
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
For blazar/blazar-nova/python-blazarclient, I managed to contact Sergei Lukianov, but I think he misunderstood my request and only confirmed that openstackci is the owner. For blazar-dashboard, Masahito Muroi (previously PTL) has lost his credentials.
I believe both are OK to be removed from PyPI for these packages.
On Sat, 16 Mar 2024 at 05:53, Ghanshyam Mann gmann@ghanshyammann.com wrote:
Hello Everyone,
It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages.
We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these.
- barbican
- blazar
- cinder
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- glance
- heat
- horizon
- ironic
- keystone
- kolla
- kuryr
- magnum
- manila
- mistral
- monasca
- murano
- neutron
- OpenStackSDK
- oslo
- Quality Assurance
- rally
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- zaqar
- zun
-gmann
---- On Wed, 29 Mar 2023 08:15:33 -0700 Ghanshyam Mann wrote ---
Hi Everyone,
Posting top of the email.
I am listing the projects that have not updated the status in etherpad;
if you have any progress, please write in etherpad. If not
request you to plan the same while in vPTG?
- adjutant
- barbican
- cloudkitty
- cyborg
- designate
- ec2-api
- freezer
- heat
- kuryr
- mistral
- monasca
- murano
- octavia
- OpenStackSDK
- oslo
- rally
- Release Management
- requirements
- sahara
- senlin
- skyline
- solum
- storlets
- swift
- tacker
- Telemetry
- trove
- vitrage
- watcher
- winstackers
- zaqar
- zun
-gmann
---- On Wed, 22 Mar 2023 08:45:49 -0700 Ghanshyam Mann wrote ---
---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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.
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
Hello Everyone,
To update, there is an extra step for project PTLs in this task:
- Step 1.1: Project PTL/team needs to communicate to the additional
maintainers about removing themselves
and transferring ownership to 'openstackci'
https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L23
Initially, TC thought we could do a cleanup with the help of
openstackci admin for all repo. But, to avoid any issue
or misunderstanding/panic among additional maintainers on removal,
it is better that projects communicate with
additional maintainers and ask them to remove themself. JayF sent
the email format to communicate to additional
maintainers[1]. Please use that and let TC know if any
queries/issues you are facing.
[1]
https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.ht...
-gmann
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
Hi,
For tacker/python-tackerclient/tacker-horizon, srramasw was remained as an maintainer, but I haven't had no response for a long time since I requested. So, I think it's OK to remove him from the maintainers.
Thanks, Yasufumi
On 2024/04/03 21:06, Pierre Riteau wrote:
For blazar/blazar-nova/python-blazarclient, I managed to contact Sergei Lukianov, but I think he misunderstood my request and only confirmed that openstackci is the owner. For blazar-dashboard, Masahito Muroi (previously PTL) has lost his credentials.
I believe both are OK to be removed from PyPI for these packages.
On Sat, 16 Mar 2024 at 05:53, Ghanshyam Mann <gmann@ghanshyammann.com mailto:gmann@ghanshyammann.com> wrote:
Hello Everyone, It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages. We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup <https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup> Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these. - barbican - blazar - cinder - cloudkitty - cyborg - designate - ec2-api - freezer - glance - heat - horizon - ironic - keystone - kolla - kuryr - magnum - manila - mistral - monasca - murano - neutron - OpenStackSDK - oslo - Quality Assurance - rally - sahara - senlin - skyline - solum - storlets - swift - tacker - Telemetry - trove - vitrage - watcher - zaqar - zun -gmann ---- On Wed, 29 Mar 2023 08:15:33 -0700 Ghanshyam Mann wrote --- > Hi Everyone, > > Posting top of the email. > > I am listing the projects that have not updated the status in etherpad; if you have any progress, please write in etherpad. If not > request you to plan the same while in vPTG? > > - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L43 <https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L43> > > * adjutant > * barbican > * cloudkitty > * cyborg > * designate > * ec2-api > * freezer > * heat > * kuryr > * mistral > * monasca > * murano > * octavia > * OpenStackSDK > * oslo > * rally > * Release Management > * requirements > * sahara > * senlin > * skyline > * solum > * storlets > * swift > * tacker > * Telemetry > * trove > * vitrage > * watcher > * winstackers > * zaqar > * zun > > -gmann > > ---- On Wed, 22 Mar 2023 08:45:49 -0700 Ghanshyam Mann wrote --- > > ---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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/murano/>, https://pypi.org/project/glance/ <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 <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 <https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup> > > > > Hello Everyone, > > > > To update, there is an extra step for project PTLs in this task: > > > > * Step 1.1: Project PTL/team needs to communicate to the additional maintainers about removing themselves > > and transferring ownership to 'openstackci' > > - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L23 <https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L23> > > > > Initially, TC thought we could do a cleanup with the help of openstackci admin for all repo. But, to avoid any issue > > or misunderstanding/panic among additional maintainers on removal, it is better that projects communicate with > > additional maintainers and ask them to remove themself. JayF sent the email format to communicate to additional > > maintainers[1]. Please use that and let TC know if any queries/issues you are facing. > > > > [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.html <https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.html> > > > > -gmann > > > > > > > > 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 <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 <https://meetings.opendev.org/meetings/tc/2023/tc.2023-01-11-16.00.log.html#l-41> > > > > > > > > > -gmann > > > > > > > > > > > >
I have no means to remove maintainers for Vitrage, but feel free to clean it up!
пт, 5 апр. 2024 г. в 13:11, Yasufumi Ogawa yasufum.o@gmail.com:
Hi,
For tacker/python-tackerclient/tacker-horizon, srramasw was remained as an maintainer, but I haven't had no response for a long time since I requested. So, I think it's OK to remove him from the maintainers.
Thanks, Yasufumi
On 2024/04/03 21:06, Pierre Riteau wrote:
For blazar/blazar-nova/python-blazarclient, I managed to contact Sergei Lukianov, but I think he misunderstood my request and only confirmed that openstackci is the owner. For blazar-dashboard, Masahito Muroi (previously PTL) has lost his credentials.
I believe both are OK to be removed from PyPI for these packages.
On Sat, 16 Mar 2024 at 05:53, Ghanshyam Mann <gmann@ghanshyammann.com mailto:gmann@ghanshyammann.com> wrote:
Hello Everyone, It has been a long time since I followed up on this. You might remember the effort to cleanup the additional external maintainers from OpenStack PyPi packages. We are still left with 110 maintainers to be removed from 232 repos. I have added the data to etherpad also - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup <https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup> Below is the latest project list where one or more repos need maintainers' cleanup. I will appreciate if you can give another try to cleanup these. - barbican - blazar - cinder - cloudkitty - cyborg - designate - ec2-api - freezer - glance - heat - horizon - ironic - keystone - kolla - kuryr - magnum - manila - mistral - monasca - murano - neutron - OpenStackSDK - oslo - Quality Assurance - rally - sahara - senlin - skyline - solum - storlets - swift - tacker - Telemetry - trove - vitrage - watcher - zaqar - zun -gmann ---- On Wed, 29 Mar 2023 08:15:33 -0700 Ghanshyam Mann wrote --- > Hi Everyone, > > Posting top of the email. > > I am listing the projects that have not updated the status in etherpad; if you have any progress, please write in etherpad. If not > request you to plan the same while in vPTG? > > - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L43 <https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L43> > > * adjutant > * barbican > * cloudkitty > * cyborg > * designate > * ec2-api > * freezer > * heat > * kuryr > * mistral > * monasca > * murano > * octavia > * OpenStackSDK > * oslo > * rally > * Release Management > * requirements > * sahara > * senlin > * skyline > * solum > * storlets > * swift > * tacker > * Telemetry > * trove > * vitrage > * watcher > * winstackers > * zaqar > * zun > > -gmann > > ---- On Wed, 22 Mar 2023 08:45:49 -0700 Ghanshyam Mann wrote --- > > ---- On Fri, 20 Jan 2023 15:36:08 -0800 Ghanshyam Mann 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/murano/>, https://pypi.org/project/glance/ <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 <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 <https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup> > > > > Hello Everyone, > > > > To update, there is an extra step for project PTLs in this task: > > > > * Step 1.1: Project PTL/team needs to communicate to the additional maintainers about removing themselves > > and transferring ownership to 'openstackci' > > - https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L23 <https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L23> > > > > Initially, TC thought we could do a cleanup with the help of openstackci admin for all repo. But, to avoid any issue > > or misunderstanding/panic among additional maintainers on removal, it is better that projects communicate with > > additional maintainers and ask them to remove themself. JayF sent the email format to communicate to additional > > maintainers[1]. Please use that and let TC know if any queries/issues you are facing. > > > > [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.html <https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032780.html> > > > > -gmann > > > > > > > > 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 <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 <https://meetings.opendev.org/meetings/tc/2023/tc.2023-01-11-16.00.log.html#l-41> > > > > > > > > > -gmann > > > > > > > > > > > >
participants (17)
-
Brian Haley
-
Clark Boylan
-
Dmitriy Rabotyagov
-
Ghanshyam Mann
-
Jake Yip
-
Jay Faulkner
-
Jeremy Stanley
-
Lajos Katona
-
Michael Johnson
-
Michał Nasiadka
-
Pierre Riteau
-
Pranali Deore
-
Radosław Piliszek
-
Rajat Dhasmana
-
Stephen Finucane
-
Thierry Carrez
-
Yasufumi Ogawa