corobo security hardening

[meetmangukiya]

• Make all labhub commands except invite require being a member of the org , so that corobo isnt a way around bans.
• Prevent all labhub commands in private chat with the bot, optionally re-adding access for maintainers to issue labhub commands in private chat. 794be48
• Add ability to ban from all gitter rooms at once (otherwise it is very tedious) [this can be done by using api keys]
• Have corobo changes land in a staging instance before deploying to production (what keys will be different in staging? If none, this is useless. If some, the staging wont be testable unless labhub is connected to a different ‘dummy’ org, and then nobody will use it.) Moved to Introducing a stage environment #653
• Prevent corobo being used to spam a room. Limit test commands to only operate in test rooms #359
• Potentially remove auto-invite, replacing with developer invite Allow developers to invite newcomers if they are a member of the room #322
• Slow down newcomers; force them to finish one issue first Newcomer shouldn't be able to assign to more than one newcomer issue #184
• Require newcomers to find a newcomer issue to work on before they are invited to join the org, lowing our risk profile

Created from security hardening docs created by maintainers.

[nvzard]

Make all labhub commands except invite require being a member of the org -> d697e18

Add ability to ban from all gitter rooms at once ->e24d461

Prevent corobo being used to spam a room ->fc9ba1e

Remove auto-invite and invite me, replacing with developer invite ->ef885b0

Slow down newcomers; force them to finish one issue first ->6c192f4

[Makman2]

A staging system is imo a separate issue and is not necessarily tied to security hardenings. Also I don't see major security benefits due to introducing a staging system, nobody really wants to do manual tests anyway so the effectiveness is rather limited. In any case, I extracted that point into a separate issue: #653

Since all other points are done, closing the issue.