On Thu, 2022-02-17 at 19:22 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Feb 16, 2022 at 12:51:13PM -0500, Stephen Snow wrote: > > On Wed, 2022-02-16 at 09:13 -0800, Adam Williamson wrote: > > > On Wed, 2022-02-16 at 11:21 -0500, Stephen Snow wrote: > > > > Hello, > > > > I don't mean to jump in the midle here, and I am just tossing > > > > out > > > > an > > > > idea for consideration that doesn't address security issues > > > > pointed > > > > out > > > > really, but does discuss the non-responsive main maintainer. > > > > I note there is a difficulty in defining the criteria for > > > > determining > > > > when an (apparently) inactive packager should be removed from > > > > the > > > > packager group. Perhaps a different POV is required. What is > > > > the > > > > problem trying to be solved? Removal of inactive packagers? Or > > > > the > > > > demotion of said packager in favour for the one(s) who are > > > > supporting > > > > the package to be promoted to main. > > > > > > The former. The main issue here is a security concern: that the > > > accounts of dormant packagers could be taken over and used for > > > evil. > > > So > > > just shuffling the deckchairs of whether someone is a 'primary' > > > or > > > 'co' > > > maintainer on a given package doesn't help. As long as they are > > > allowed > > > to submit official builds of the package, the problem remains > > But wouldn't be possible to move their deckchair into a sandbox? > > That is what we are effectively doing. By removing them from > @packager, > they lose write access to packages. It is also very easy to undo. > In your approach, we'd do this package-by-package. That'd be more > complicated and harder to undo, and wouldn't really help with > the security concerns. > Thanks for the explanation, and I appreciate that I was naive potentially with my simplistic question and the complexity of doing packager rights on a per package basis does seem onerous. So if I understand it correctly this is a @packager group level demotion, so no longer a packager at all, but could be easily promoted to that status if need be in the future. That would seem to be a sensible approach.
I would assume there is already a process to deal with accounts that may have been compromised. Stephen > Zbyszek > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
