[tc] Assuming control of GitHub organizations

Sorin Sbarnea ssbarnea at redhat.com
Fri Jun 28 09:33:29 UTC 2019

I think I could write a script that loops over all repos and activates branch restrictions to allow only our sync-bot to push.

Running this daily should avoid the case where a new repo is added and someone forgets to add the restriction.

In the future we can use the same bot for other maintenance tasks.

* in python, obviously.

> On 28 Jun 2019, at 09:43, Thierry Carrez <thierry at openstack.org> wrote:
> James E. Blair wrote:
>> Thierry Carrez <thierry at openstack.org> writes:
>>> I'd do a limited number of personal accounts, all with 2FA.
>> One thing I would encourage folks to consider is that GitHub makes it
>> remarkably easy to do something "administrative" accidentally.  Any of
>> these accounts can easily accidentally push a commit, tag, etc., to the
>> mirrored repos.  It's not going to be destructive to the project in the
>> long term, since it's merely a mirror of the authoritative code in
>> Gerrit, but if we think it's important to protect the accounts with 2FA
>> to reduce the chance of a malicious actor pushing a commit to a
>> widely-used mirror, then we should similarly consider preventing an
>> accidental push from a good actor.  This is the principal reason that
>> the Infra team developed its secondary-or-shared account policy.
>> Especially if the folks who manage this are also folks who work on these
>> repos, we're one "git push" away from having egg on our collective face.
>> If the folks managing the GitHub presence are also developers, I would
>> encourage the use of a shared or secondary account.
> That is a fair point that I had not considered.
> That said, wouldn't the risk be relatively limited if the "admins" never checkout or clone from GitHub itself ?
> -- 
> Thierry Carrez (ttx)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190628/2cf55893/attachment.html>

More information about the openstack-discuss mailing list