Open Stack

My personal take on this is that it would be safer to use personal account with 2FA to manage these and also to make mandatory 2FA for all org members.

Use of shared accounts is more risky as they are not as traceable as personal ones.

Overall I salute the idea as I think that there are few projects that would love to be able to use github issue tracker.

-- sorin
On 26 Jun 2019, 19:41 +0100, Jim Rollenhagen <jim at jimrollenhagen.com>, wrote:
> Hi,
>
> The opendev team reached out to me about handing off administrative access of
> the "openstack" and related organizations on GitHub. They think it would be
> best if the TC took control of that, or at least took control of delegating
> that access. In general, the goal here is to support OpenStack's presence and
> visibility on GitHub.
>
> Per Jim Blair:
>
> > In the long run, this shouldn't entail a lot of work, generally creating new
> > repos on GitHub to accept mirroring from opendev systems, performing renames,
> > handling transfer requests when repos move out of the openstack namespace,
> > setting and updating descriptions, and curating the list of pinned
> > repositories.
>
> In the short term, we have some archiving and moving to do.[0]
>
> Do TC members want to manage this, or should we delegate?
>
> One thing to figure out is how to grant that access. The opendev team uses a
> shared account with two-factor authentication provided by a shared shell
> account. This mitigates accidental pushes or settings changes when an admin is
> using their usual GitHub account. The TC (or its delegates) probably doesn't
> have a shared shell account to do this with. Some options:
>
> * each admin creates a second GitHub account for this purpose use a shared
> * account without 2FA use a shared account with 2FA, share the one time secret
> * with everyone to configure their own token generator use personal accounts
> * but be very careful
>
> Thoughts on these options?
>
> [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006829.html
>
> // jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190627/0c7d6d3c/attachment.html>