Repository navigation
A bot to manage the members of the Org #22
Description
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.
Activity
jasnell commentedon Mar 11, 2017
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 commentedon Mar 11, 2017
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 commentedon Mar 11, 2017
@williamkapke could you add me to the test org and give me write access to some repo (e.g. a new one), please?
ChALkeR commentedon Mar 11, 2017
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 commentedon Mar 11, 2017
@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 commentedon Mar 12, 2017
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 commentedon Mar 12, 2017
williamkapke commentedon Mar 12, 2017
@ChALkeR there is already a bot running on the Node.js Organization that is working under the exact same conditions.
williamkapke commentedon Mar 12, 2017
@jasnell you had over a year to express these concerns- and didn't. What changed?
jasnell commentedon Mar 12, 2017
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 commentedon Mar 12, 2017
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 commentedon Mar 12, 2017
@williamkapke
Which one?
williamkapke commentedon Mar 12, 2017
ChALkeR commentedon Mar 12, 2017
@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 commentedon Mar 12, 2017
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.
13 remaining items
williamkapke commentedon Aug 23, 2017
@RichardLitt @rachelnicole Yup- the NodeSchool bot is what spawned this project (See nodejs/TSC#51).
The bot is already written. (See OP)
It just needs to get set up within the GH infra.
phillipj commentedon Aug 23, 2017
gibfahn commentedon Sep 10, 2017
@williamkapke regarding the events the bot responds to, specifically this:
Does this mean that if someone pushes directly to the branch without raising a PR then the bot will still take the action?
It would be good for the bot to only take action if the change came from an approved PR. I guess we could maybe achieve that by using protected branches with required reviews for Pull Requests.
gibfahn commentedon Sep 10, 2017
Also reading through this it sounds like you were looking at logging bot activity somewhere, is that still something that needs to be implemented?
williamkapke commentedon Sep 11, 2017
@gibfahn
Yup. It seemed like that'd be desired. But maybe this behavior needs to be different depending on the action? For instance- we MAY want to block a user immediately by pushing directly. But it seems unlikely we would manage teams in an immediate way like that. Yeah, we could have protected branches- but it's not hard to adjust the rules of when the script is fired either.
The main idea is that the bot should only react to what it sees committed to GitHub- making PRs and Commits a log on their own. However, yes, I'd like to see some kind of log file like we'd expect to see for any application. My preference, however, is that those logs are public. I've pondered ideas like making a repo where the bot could just append to issue comments or something (creating a new issue daily maybe?). I don't know- open to ideas.
gibfahn commentedon Sep 11, 2017
Actually having the commit history for the file be the log is a pretty neat idea. You'd probably want some debugging logs somewhere in case the bot ever didn't do what it told Git that it did, but otherwise that's probably sufficient.
bnb commentedon Dec 4, 2017
@williamkapke does this issue need to remain open? The Automation WG repos may be a better place for it at this point. Happy to leave it open if there's further discussion to be had 👍
williamkapke commentedon Dec 4, 2017
This issue is specific to CommComm and is ongoing.
bnb commentedon Dec 4, 2017
@williamkapke awesome. Are there any explicit next steps or updates to surface?
ChALkeR commentedon Jan 29, 2018
@williamkapke Sorry, I missed most of this discussion from some point…
Am I correct that
admin:orgscope can manage admins in the org?That's enough to delete repos, override history, and do anything else in the org.
williamkapke commentedon Jan 30, 2018
Yes, you are correct. The token could be used to make another account an admin- which could then allow that person to do bad things.
Thank you @ChALkeR for pointing this out. It is important to find and acknowledge the attack surfaces we create. My understanding is that we have similar scenarios already that are protected by the build team. Since I'm not on the build team I can't speak to how strong or weak their processes/systems are - but I've gotten the sense they're 💯 %. None-the-less, it is still an attack vector.
Here's my overall status on this:
I built the proof of concept for whatever it's worth in maybe advancing this forward... & I'm happy to have contributed that much. I'm unavailable to take on additional debates required though. While I do believe its the right thing to do, I do not believe we will achieve org-wide consensus. Without consensus, it would require a TSC vote (maybe CommComm too now?).
Also FYI: this was once voted on and approved by the TSC- but it still didn't happen.
ChALkeR commentedon Jan 30, 2018
Could you unpack that, please? I am not sure that I understood that.
williamkapke commentedon Jan 30, 2018
I was just saying that the build team already has a few apps/processes/scripts, with elevated access, that run in their environment(s) that they keep shielded. So, from my understanding, they're all set to add a new bot if needed.
But- I could be wrong... & I defer to the @nodejs/build team to say for certain.
bnb commentedon Jan 2, 2019
Going to close this issue for a few reasons:
Thanks everyone for your time and effort on the GitHub bot. The two repos mentioned (nodejs/github-bot and nodejs/automation are going to be more productive locations for continuing this discussion in a way that can be resolved by people who are focused on this specific work ❤️