Github is moving to SSH authentication nov 13

[lwasser]

I think i finally understand what is goin gon

https://github.blog/2020-07-30-token-authentication-requirements-for-api-and-git-operations/
github will be moving ALL API requests to ssh authentication starting nov 13... it sounds like eventually ssh use of GH will also be required for command line tasks ... but that may come later.

We just need to check HOW abc classroom handles some of the tasks include the template repo.
i know that abc-clone required me to setup ssh locally and via github. but abc-template did not.

this issue is somewhat time sensitive so we should plan to move to SSH by the end of october.

[jedbrown]

I don't read this as using SSH for API requests. It's just that you won't be able to use your GH login password for API auth. This is already the case if you've enabled 2FA -- you must create personal access tokens for API auth. Having just checked the code, I think even the current abc-init strategy will continue to work after this change.

[lwasser]

thank you @jedbrown !! I just started to read about this and was trying to make sense of it. it appears as if github auth was going to slowly move away from username / password authentication and move towards what i'm calling ssh (this may be incorrect terminology) but essentially using:

git@github.com:earthlab/abc-classroom.git

to clone and then having an ssh key stored locally and also on github as a token to support all operations at the CLI. i keep getting emails about this deprecation coming up for the API in November so we want to ensure things will still work here!!

[kcranston]

I still need to read more, but I think that our current workflow will need to change. For a new user, we ask for GitHub username and password, and then authenticate using that username + password to get a personal access token. Subsequent actions then just look for the token, which we store locally.

The ability to authenticate using the username + password via the API is being deprecated in favour of either a web-based workflow or a device flow.

So I do think we need to change the way we do authentication. Even the users that have 2FA, the current workflow relies on the deprecated authorization API.

[kcranston]

This is thornier, since the python library that we currently use is no longer active (see also issue #72 ). We couldn't figure out how to implement our current workflow with the more active pygithub library (PyGithub/PyGithub#1230), maybe because they are designing around this planned deprecation?

[lwasser]

huh - maybe it's worth revisiting pygithub again @kcranston ... eeks. worse case scenario we can provide instructions for creating the correct token or authentication process?? maybe we can chat more about it as i will be honest - i'm just getting up to speed on authentication. moving myself over to the preferred GH authentication, etc... i'll have to update our lessons as well!!

[jedbrown]

Okay, the abc-init may be problematic now (using username+password/2FA via the API to create a token), but everything should work once the token has been created (no need to use ssh git@github.com:user/repo). Although I'm fond of ssh for interactive purposes, I think the token is better for a tool like this, and avoids fragmentation between API requests and clone/push.

Worst case scenario is that the user is just directed to the page to create a token, and then paste it back in their terminal. I use a password manager and prefer that because it's an extra step for me to get the GitHub password (long random string) and 2FA code from that device, where as the password manager is integrated in my browser, which already has a cookie so I don't need to re-up my 2FA. It's also a bit simpler trust model in that the user doesn't have to trust that this random Python script will not store or leak their password (which can be used to impersonate, where as a PAT is decoupled from identity-related functionality).

[lwasser]

Thank you @jedbrown !! We just had a discussion about this and agree that we will have to move away from how the token is created!

Let's chat a bit more about how authentication works. @kcranston is going to look into options. We definitely need to move away from our currently github.3py tool and likely migrate over to pygithub! We were thinking that it would be best to have all authentication work the same way as you say to a void fragmentation and such between commands.

BUT if you have other thoughts we'd love to hear them. Karen will report back with notes regarding what she thinks will work best so perhaps we can have a follow conversation once she has some more info! I am learning a lot about authentication through this process!!

[lwasser]

just to note this issue also relates to #72

[cvega]

@lwasser if it's helpful I have an example that uses pygithub and the github app (versus using a PAT) to make API calls. This is typically what I recommend to our enterprise customers at GitHub.

https://github.com/cvega/githubapp-token-refresh

If you want to learn more about GitHub App: TL;DR it's an authentication layer for the api using policy of least privilege and short lived tokens using JWT:
https://docs.github.com/en/developers/apps/creating-a-github-app

[kcranston]

Thanks, @cvega ! We have indeed moved to GitHub App-based authentication.

[lwasser]

it's also helpful to hear pygithub is what we should be using and is what github suggests. thank you for the reference repo @cvega and welcome to abc-classroom!! i am really enjoying abc-classroom and github actions for teaching.

[lwasser]

i think we can close t his when we merge #335

[lwasser]

OMG @kcranston are you working on abc-classroom and not the hub?!!!! can we celebrate and only talk about python this week? :) :) 🎆