Why are the Github plugin's required scopes so broad?


An organization I work with wants to enable the Github plugin on their Mattermost, tied to their Github organization.

I am looking at the scopes required as part of authorizing the app, and don’t understand why the app needs the ability to do things such as write deploy keys or even have ‘write’ access to code or ‘settings’.

We don’t want, for example, the plugin to have the ability to change a setting, such as modifying branch protection rules or other security settings.

Is there no way to have the plugin merely:

  1. Be able to ‘subscribe’ to repositories or unsubscribe from them, like Slack’s Github integration
  2. react to things it ‘sees’ in a passive sense, and report them as messages into Mattermost (without having to add individual webhooks in Github that hit Mattermost endpoints, I guess)? I don’t imagine I’m the first to require that basic functionality e.g no write access.

Thanks in advance!

Hi @mig5 ,

good question, I saw you already asked it also in the repo so I’m leaving the link to your other question here. I think the GitHub repository might be a good place for this question, additionally I’ve also posted a link to it in the community server’s Integration channel.

I personally am unable to answer this question, so let’s hope someone can and will answer here :slight_smile:

Crosslink: Clarification about the scopes required for the Github plugin's access to Github organization · Issue #646 · mattermost/mattermost-plugin-github · GitHub

The answer has been provided in the GitHub issue and follow-up questions should also be asked there, hence I’m marking this topic as resolved now.

1 Like