(WARNING) IRC discussion [[https://meta.wikimedia.org/wiki/IRC_office_hours|(?)]]: [[https://www.timeanddate.com/worldclock/fixedtime.html?msg=MediaWiki+RfC+discussion%3A+Use+GitHub+login+for+mediawiki.org&iso=20190214T07&p1=1440&ah=1|Thursday, 2019-02-14, 7-8 AM]], on [[https://webchat.freenode.net/?channels=#wikimedia-office|#wikimedia-office]]
//(This is not particularly hard to undo and only borderline cross-cutting or strategic, so not clearly TechCom RfC material. But it does need some kind of high-level, participative decision-making process and I don't think we have any other, so I'm proposing it as a TechCom RfC for lack of better alternatives.)//
Practically all developers today have a Github account. Most developers who work a little but not much with MediaWiki (and that's a lot more people than who work a lot with MediaWiki) do not have a Wikimedia SUL account. It's not hard to set one up but even a little friction is friction. We should provide the option to log on mediawiki.org with your Github account.
* The primary objective is to improve recruitment of new developers; you need a wiki account to use Phabricator and report bugs, the support desk is hard to use without a wiki account, you need a wiki account to propose OAuth apps, etc. Letting you use your existing Github account which you probably use for everything else development-related means less distraction (we can skip registration, email confirmation, and probably can immediately make the account autoconfirmed). It also means we can connect Github accounts to wiki accounts, which can be used for a number of interesting things, especially once the linking of Wikimedia LDAP and SUL accounts happens (e.g. pulling Github pull requests into Gerrit while preserving authorship info).
* The secondary objective is to have an active but not super high-profile (and consequently not high-risk) use case where we can evaluate external logins. External logins with some major identity provider such as Google are interesting for the other wikis [[https://www.mediawiki.org/wiki/User:Tgr_(WMF)/external_login|for a number of reasons]] and a key feature for third-party MediaWiki installations in a corporate environment; mediawiki.org seems like the ideal place to polish MediaWiki's external login provider support as its userbase is good at identifying and reporting workflow or usability imperfections.
== Technical details
Since the [[https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager|AuthManager rewrite]], MediaWiki has first-class support for remote identity providers. They display a button on the login form, on clicking it you get redirected to the external site, on return you get logged into your linked wiki account; if you have a wiki account but it's not linked, you can do a normal password login and link it; if you don't have a wiki account at all, you get the option to create one that's immediately linked. (There are some UI and workflow bits related to this in AuthManager which are unfinished, but what needs to be done is well understood). Multiple external accounts can be linked to the same wiki account. There is a special page for inspecting and removing links. If you have used external login to create your account, you can set up a password via the normal password change process.
Existing MediaWiki extensions providing Github authentication include [[https://www.mediawiki.org/wiki/Extension:OAuth2Github|OAuth2Github]] and [[https://www.mediawiki.org/wiki/Extension:OAuth2_Client|OAuth2 Client]], although both seem dated. Probably the easiest way is to clone [[https://www.mediawiki.org/wiki/Extension:GoogleLogin|GoogleLogin]], which is well-maintained and fully utilizes AuthManager, and only differs from Github auth in some implementation details of the OAuth process that both sides use for authentication. Maybe even split GoogleLogin into a generic (or generic OAuth-based) external login support layer and provider-specific layer.
== Security & privacy details
Security-wise the only effect is that one could steal a Wikimedia account by stealing the linked Github account, but Wikimedia accounts are probably a significantly easier target. Secondary authentication providers such as OATH (2FA) still get applied when you try to login with a Github account.
Recovering stolen accounts, lost 2FA etc. becomes slightly easier since there is another identity to go by.
Privacy-wise, when someone with no mediawiki.org account logs in / creates an account this way, Github could tie their Wikimedia identity to their Github identity, and an attacker who can monitor their web traffic could identify their Wikimedia account, in both cases based on account creation log timings that we make publicly available. Mediawiki.org users are unlikely surveillance targets, but we should probably have some kind of warning or rethink how much information we publish in account creation logs.
== Comparison of GitHub with other alternatives
GitHub is the largest code forge, with 31M developers (8M of whom joined last year) according to its [[https://octoverse.github.com/|annual report]]. It is closed source but mainly focusing on supporting opensource projects. The next largest is BitBucket (6M users, part of the Atlassian suite, not specifically opensource-focused). The largest code forge running on opensource software is GitLab (they don't give a user count but their organization count is 5% of GitHub's so at a wild guess about 1-2M users? They have a wider focus, trying to cover the entire DevOps field from planning to writing code to monitoring). To avoid the [[https://indieweb.org/NASCAR_problem|NASCAR problem]] we want to minimize the number of external login providers we use, so the more interesting question would be, what is the extent of overlap between these user bases? (No point in adding GitLab if almost every GitLab user also has a GitHub account.) Not sure how we could guesstimate that, though... surveys maybe?
Given all the fear, uncertainty and doubt around external login, I'd like to get consensus on the basic idea before trying to get commitment from budget owners or committing volunteer time. I think the AuthManager side is a few weeks work at most for someone familiar with the codebase, writing the extension is a similar amount of time, plus a long tail of potential usability improvements for which there is no time pressure.