Understanding GitHub permissions

[consideRatio]

There are two times that the end user via a GitHub website, and I don't yet understand what roles they have etc. To understand that is quite relevant for anyone being an admin of a hub that provides this if the admin gets questions from users.

I don't clearly understand the parts here. I've typically been very afraid of whenever I've accepted "act on behalf of you". But, I guess perhaps it's just "act on behalf of me" with restricted permissions based on how the application is installed for various repos.

Task to complete

• Clarify the role of various steps taken somewhere in this project's documentation
• BONUS: Include some screenshots
• BONUS: Include references to verify what's said in official github documentation

---

Overview of procedure to understand better

Step 1 - An end-user installs the github application

This can be triggered by visiting https://github.com/apps/hub-jupytearth-org-github-integ.

Step 2 - An end-user authorize the application as initiated by github-app-auth-user CLI

This can be triggered by running github-app-auth-user, getting a device code, and opening https://github.com/login/device

[yuvipanda]

So the actual permissions granted are specified by the admin when they create the app itself. Step 1 grants permissions to the app to act on the repos, while step 2 grants permission for the app to act on behalf of the user on those particular repos - if they users don't have access to the repo they still can't push. So the effective permission requires that:

1. GitHub app is created with correct scopes (push, pull)
2. GitHub app is installed in the repos where we want end users to eventually push / pull
3. Users authorize the app to act on their behalf, so users still need to (independently) have permissions to these repos.

I hope this helps! Should also be more clearly documented

[consideRatio]

Thanks @yuvipanda I think you summarized it as comprehensible as something this complex can be summarized!

Hmmm, so there is like two separate distinctions:

• Does the user trust the app to act with your credentials?
• Does the github repo owners trust the app to make changes for users who trusts the app?

I don't yet understand this as clearly as I hope to, but I do understand it better thanks to your help @yuvipanda!

I think what I look to understand more clearly are the security implications in various scenarios, for example if a GitHub app developer is malicious, and what steps then are needed for that malicious GitHub app developer needs to get done to do harm - and how great that harm will be - and such questions.

[yuvipanda]

@consideRatio oooh, great question. I think the developer of the app could possibly write to the repos even without user authentication :| https://github.com/yuvipanda/git-credential-helpers relies on that to work with nbgitpuller on private repositories. We should make that clear.

[consideRatio]

Ah now i understand that project:
1 create an app
2 create a key (in app settings) to act as the app
3 declare permissions for app
4 install app on org/repo
5 use app credentials (via git cred. helper) to do what you want

Okay, so the app has permissions by itself.

Hmmmm, but in this case (github-app-user-auth) a user knowing the client-id (public) can use the app to generate credentials which is the intersection of the app credentials and the user credentials, and with github-app-user-auth, those stay with the end user rather than to be used by some server doing automation etc?

[yuvipanda]

@consideRatio yeah, so if you just know the client id, you can use it only in conjugation with user credentials to get access to repos with intersection of these permissions. You need access to the GitHub app's private key (not used in this repo) to get access without user authorization. So the presence of the github app ID acts purely as a constraint on what scopes the user's permissions are reduced to.

[yuvipanda]

No key is created here - only the (public) client ID is used.