A bot to manage the members of the Org

[williamkapke]

Fellow CommComm-ers: Managing the members of a GitHub Org has been a challenge. Soon we'll start adding sub groups around here and we'll want to manage the Teams.

The TSC recently closed my long standing issue to do this with a bot on there end. That's ok. I've kinda been on an island with my efforts. A bot was started that has been handling many other tasks, but not the ones I set out to do. I still believe this is the proper way to avoid burdening the TSC for these requests.

SO- I offer CommComm this: https://github.com/williamkapke/orgbot

It is purposely not specific to the Node.js GitHub Organization. My hope is that other Organizations could use it and it will gather more contributors focused on solving this problem.

This is only an offering. We can choose to go a different route. BUT,I'm just happy that I finally have this solution out there so we can no longer say "IF we had a bot for this" 😄

I have it running on my test Org. If you would like to play around with it, just let me know and I'll add you to the Org!

Let me know your thoughts. If positive, we'll pursue putting this in production.

[jasnell]

Just a quick point, not commenting on the work itself, but the @nodejs/tsc will need to be consulted in order to enable this on the Node.js Github organization. Please make sure to brief the TSC on the intent and purpose.

[ChALkeR]

It would be more convenvient, sure, but from the security point of view I am not totally convinced that having such a bot would be more secure than just having several people doing that.

[ChALkeR]

@williamkapke could you add me to the test org and give me write access to some repo (e.g. a new one), please?

[ChALkeR]

Well, if I understand things correctly, this potentially makes things less secure and let me explain why.

Situation A: the org SomeOrg has 20 owners, who basically could do anything, other members have limited access, e.g. write access to some repos, and most of them don't have the ability to break things badly.

Situation B: the org SomeOrg has a bot with full permissions, 5 real owners, and 600 members (including outside collaborators), each of whom who can interact with the bot in some way in their repo.

Situation B is worse than Situation A if the estimated probability of any potential vulnerability in the bot or its dependencies (or the server it operates on) that would allow some member to do arbitrary things from the bot user is higher than 2.5%. For Situation B to be better, we should estimate that probability as lower than 2.5%. I wouldn't count on that atm.

Note that those 2.5% should be estimated regardless of someone willing to exploit that vulnerability and do malicious things, it doesn't include that, it just includes the technical possibility and discovering such a vulnerability.

Also note that the above calculations were performed under an assumption that all members of SomeOrg, including owners in Situation A, have an equal chance of going crazy. If the org SomeOrg has some filter and chooses owners not randomly from its members but through some more complex procedure, than that could significantly lower the borderline for the vulnerability probability in the bot, and it would become significantly lower than 2.5%.

---

Note: I could be wrong, I did not dig the details about this bot, and this is just a quick assumption.
If I am wrong, please explain me why =).

[williamkapke]

@jasnell Of course- there just isn't a reason to bother the TSC if I find people don't want it. Right?

@ChALkeR I added you by using the bot! I added you to the pretend https://github.com/noduh/evangelism team 😄

[ChALkeR]

TL;DR: I am worrying about giving a bot too much power in the org with a lot of users that could interact with the bot — that could be worse, because the bot, or its deps, or its server, or its platform could have vulnerabilities.

[jasnell]

I tend to agree. I'm afraid that it introduces additional risk and complexity without adequate justification. Are there specific issues that have come up that would be alleviated or fixed by this? (If it isn't broken.....)

…

On Sat, Mar 11, 2017 at 4:09 PM Сковорода Никита Андреевич < ***@***.***> wrote: TL;DR: I am worrying about giving a bot too much power in the org with a lot of users that could interact with the bot could be worse, because the bot, or its deps, or its server, or its platform could have vulnerabilities. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAa2ecaDG82dBvjb1FOMHp6mdlXhkzT7ks5rkzfDgaJpZM4MaUqL> .

[williamkapke]

@ChALkeR there is already a bot running on the Node.js Organization that is working under the exact same conditions.

[williamkapke]

@jasnell you had over a year to express these concerns- and didn't. What changed?

[jasnell]

I have expressed such concerns before on several occasions. What's changed is that you just now opened this thread today and I am responding to your request for feedback. I'm simply not and haven't been convinced there is a justifying need for an owner-bot, particularly with the risks involved.

The other bot that is operational does not have owner permissions and is therefore a bit less of a risk.

That said, I've given my thoughts and I'd like to hear what others have to say about it.

[williamkapke]

The TSC approved the permissions and were enabled on Sept 24th.

In the 2016-09-08 TSC meeting, you approved of having a bot like just like this. Again, I'm really curious what changed?

[ChALkeR]

@williamkapke

@ChALkeR there is already a bot running on the Node.js Organization that is working under the exact same conditions.

Which one?

[williamkapke]

https://github.com/nodejs/github-bot There are great folks on the bot team working on it!

…

On Mar 11, 2017, at 10:55 PM, Сковорода Никита Андреевич ***@***.***> wrote: @williamkapke @ChALkeR there is already a bot running on the Node.js Organization that is working under the exact same conditions. Which one? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ChALkeR]

@williamkapke The access level for that one differs — it's not org-wide (correct me if I'm wrong).
Also, which repos is it enabled on? If that's only the core one, then only Node.js core collaborators could interact with it there.

Btw, I am not confident that it's such a good idea, as that one is used as a user and GitHub doesn't provide means of restricting the API usage to only issues/prs actions.

But if it's enabled only on the core repo (and perhaps on others with a limited number of collaborators who are also trusted in the core repo) — it looks fine. The key question is — which and how many org members could interact with the bot?

If not — the nodejs-github-bot account should probably be split in separate ones, each of which should have access to each own repo and will be running inside an isolated kvm container.

I will try to take a closer look on both bots this month.

[bnoordhuis]

I've commented on it before but a script that runs unsupervised makes me uncomfortable.

Humans can evaluate a request to block/ban/add/etc but a bot simply does what it's told, no questions asked. The potential for mayhem in case of a bug or compromised environment is considerable.