Bugzilla – Full Text Bug Listing
| Summary: | Error validating settings: Must specify two-factor authentication OTP code | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Matthias Mailänder <matthias.mailaender> |
| Component: | GitHub | Assignee: | Project Inbox <egit.github-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | honza.hron, liora, matthias.sohn, raffi.khatchadourian, steve, twolf |
| Version: | 3.2 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Matthias Mailänder
+1 It's more than six years later and this still does not work. Meanwhile, the situation in the wild has changed - GitHub has become way more popular and many companies including the one I work at now use GitHub as their primary code repository and enforce 2FA. Good integration with widespread tools is important for the continuous survival of the Eclipse platform. However it was a large annoyance to even find how to add the Mylyn connector. This should be considered higher priority. Or possibly replaced with any other mechanism to integrate GitHub's pull requests with Eclipse for code review. We welcome contributions. The egit-github library had been originally developed by Github people, but they've left long ago, and the regular active EGit contributors only have time for minimal maintenance. So if someone can provide a working implementation for this it'd be appreciated. (In reply to Thomas Wolf from comment #3) > We welcome contributions. > > The egit-github library had been originally developed by Github people, but > they've left long ago, and the regular active EGit contributors only have > time for minimal maintenance. So if someone can provide a working > implementation for this it'd be appreciated. I looked at how it works to see if I could make a simple fix and at the GitHub API and it seems we have a somewhat bigger problem - egit-github will stop working altogether on 2020-11-13 because GitHub is deprecating HTTP Basic authentication. See https://developer.github.com/changes/2020-02-14-deprecating-password-auth/ for details. (In reply to Jan Hron from comment #4) > (In reply to Thomas Wolf from comment #3) > > We welcome contributions. > > > > The egit-github library had been originally developed by Github people, but > > they've left long ago, and the regular active EGit contributors only have > > time for minimal maintenance. So if someone can provide a working > > implementation for this it'd be appreciated. > > I looked at how it works to see if I could make a simple fix and at the > GitHub API and it seems we have a somewhat bigger problem - egit-github will > stop working altogether on 2020-11-13 because GitHub is deprecating HTTP > Basic authentication. See > https://developer.github.com/changes/2020-02-14-deprecating-password-auth/ > for details. Why is that a bigger problem ? Basically this means that instead of setting the Authorization header to Authorization: Basic base64(<user>:<password>) it needs to be set to Authorization: token <token> If github also discontinues basic authentication for the git smart-http protocol someone has to implement token based authentication or oauth also in native git. AFAIK this isn't available so far. https://public-inbox.org/git/4eb22ffc-77a1-4cd7-2277-bdc57d31186b@protonmail.com/ https://public-inbox.org/git/CAENte7iUYcLX1ym1rdiYT2L8yLSWforf8kUvfHKLvhi_GhKQvg@mail.gmail.com/ (In reply to Matthias Sohn from comment #5) > Why is that a bigger problem ? > > Basically this means that instead of setting the Authorization header to > > Authorization: Basic base64(<user>:<password>) > > it needs to be set to > > Authorization: token <token> > > If github also discontinues basic authentication for the git smart-http > protocol someone has to implement token based authentication or oauth also > in native git. AFAIK this isn't available so far. > > https://public-inbox.org/git/4eb22ffc-77a1-4cd7-2277-bdc57d31186b@protonmail. > com/ > https://public-inbox.org/git/ > CAENte7iUYcLX1ym1rdiYT2L8yLSWforf8kUvfHKLvhi_GhKQvg@mail.gmail.com/ I thought it would be necessary to implement the OAuth workflow within Eclipse, but if users are required to obtain the token themselves, all that would remain would be some dialog tweaking. If this is the case, I could probably give it a shot. Do you know about a good resource on how to go around running and debugging these plugins from Eclipse? Would it be about installing the modified plugin from a 'target' folder of the plugin project and attaching a second Eclipse instance to the other one using remote debugger, or is there some OSGi trickery involved? Also, what about upgrade paths? And is there anyone who would review the changes and test this to make sure the changes are okay? I'm not an active user of Mylyn, I only found this issue while trying to figure out how to integrate GitHub's code review workflow with Eclipse. I would be willing to test any fixes for this. I'm closing this; there is now bug 567557 for implementing token auth in EGit-Github (the Mylyn connector for PRs, issues, and gists). Token auth for git smart-http should be possible via the http.extraHeader git config, right? Or would JGit or EGit need more? If so, please open a bug against JGit or EGit/Core or EGit/UI. An alternative bypassing all this 2FA/token business for git or JGit/EGit is to use ssh and have an ssh public key set up on the GitHub account. Personally I use that all the time; I even have a git config [url "git@github.com:"] insteadOf = https://github.com/ which turns all https GitHub repo URLs into ssh URLs for git. Together with an ssh config that defines the private key to use for github.com that works like a charm. *** This bug has been marked as a duplicate of bug 567557 *** (In reply to Thomas Wolf from comment #8) > I'm closing this; there is now bug 567557 for implementing token auth in > EGit-Github (the Mylyn connector for PRs, issues, and gists). > > Token auth for git smart-http should be possible via the http.extraHeader > git config, right? Or would JGit or EGit need more? If so, please open a bug > against JGit or EGit/Core or EGit/UI. We are currently using http.extraheader internally to implement 2 factor authentication via oauth. It has the disadvantage that this is a single global option which disturbs authentication with other git services. This means if you are using multiple git services you will have to reconfigure http.extraHeader frequently. We will replace that internally by storing the oauth tokens as cookies which are stored per domain similar to what Google is doing for gerrit-review.googlesource.com. The cookie file persisting tokens can be configured in git via http.cookieFile. I think in jgit we should implement direct support for OAuth and directly set the Authorization: Bearer header. > An alternative bypassing all this 2FA/token business for git or JGit/EGit is > to use ssh and have an ssh public key set up on the GitHub account. > Personally I use that all the time; I even have a git config > > [url "git@github.com:"] > insteadOf = https://github.com/ > > which turns all https GitHub repo URLs into ssh URLs for git. Together with > an ssh config that defines the private key to use for github.com that works > like a charm. > > *** This bug has been marked as a duplicate of bug 567557 *** (In reply to Matthias Sohn from comment #9) > We are currently using http.extraheader internally to implement 2 factor > authentication via oauth. It has the disadvantage that this is a single > global option which disturbs authentication with other git services. Really? What about http."https://someurl".extraHeader? We did implement it that way in JGit because the git docu says "Any of the http.* options above can be applied selectively to some URLs."[1] It's a bit unclear to me whether extraHeaders from http.extraHeader would be included if you have specific http.<url>.extraHeader configs; in JGit they're not. [1] https://git-scm.com/docs/git-config#Documentation/git-config.txt-httplturlgt (In reply to Thomas Wolf from comment #10) > (In reply to Matthias Sohn from comment #9) > > We are currently using http.extraheader internally to implement 2 factor > > authentication via oauth. It has the disadvantage that this is a single > > global option which disturbs authentication with other git services. > > Really? What about http."https://someurl".extraHeader? We did implement it > that way in JGit because the git docu says "Any of the http.* options above > can be applied selectively to some URLs."[1] It's a bit unclear to me > whether extraHeaders from http.extraHeader would be included if you have > specific http.<url>.extraHeader configs; in JGit they're not. > > [1] > https://git-scm.com/docs/git-config#Documentation/git-config.txt-httplturlgt seems I missed this part of the git config documentation so my comment seems wrong and we can adopt this for our internal usage :-) |