(Presenter: M Hickford, Notetaker: Lessley Dennington) (Slides: https://docs.google.com/presentation/d/127xue1Sr19J1m6wk1KwY9-5G1lPxbyHOgaIi2Ro12ts/edit?usp=sharing) * (Hickford) I interact with many Git "hosts" (GitHub, GitLab, gitlab.freedesktop.org, etc.). I had 15 Personal Access Tokens (PATs) around, which was tedious. I was using Git Credential Manager, which has an option to authenticate via web browser which creates a token. I released git-credential-oauth with this feature which you can use with a storage helper. I'm going to show an example of authenticating to a host I've never used before (Gitea). Demonstrates signing into Gitea via web browser and cloning his fork of project xorm/xorm. Since the repo is public, no authentication is necessary. Makes a commit and pushes. Auth flow is triggered, provides consent. Authentication was successful. There was no need for PATs or shell keys. Git-credential-oauth supports GitHub, GitLab, Gitea, and Gitee out of the box. Works using new(ish) password_expiry_utc attribute and wwwauth[] headers. * (brian) Thinks it's a great idea because it's convenient. github.com/github requires SAML/SSO and the browser, and this should work just fine. It wouldn't be great to have in C, but as a helper it's super convenient. * (Hickford) Ruled out a C implementation due to the challenges. Goal was to remove a barrier to entry for contributors to OSS trying to make bug fixes and having to set up/deal with PATs/SSH keys. * (Jakub) Still work to do with creating a fork, pushing. * (brian) GCM does this but represents a greater barrier to entry for less Git literate users. Less beneficial for Git power users. * Edit: Lessley and brian spoke after the meeting, and Lessley realized the above was not recorded correctly. git-credential-oauth and GCM both remove the need for users to manually set up PATs/SSH keys (which was what was being considered as the high barrier to entry).
