Re: Do we have any policy for disabling inactive users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux