Use tahoe-lafs GitHub org for Discourse instance's GitHub login

[sajith]

This is a convoluted and confusing issue title. Sorry. :-)

Once GitHub login is enabled for Discourse, folks will not have to create a separate account for yet another discourse instance. To that end, we have enabled GitHub login on https://tahoe-lafs.discourse.group, but it uses a github_client_id and github_client_secret that your humble correspondent has created, so the login screen on GitHub side will look a bit odd. It will look like the Discourse instance is run by your humble correspondent, whose connection with Tahoe-LAFS project is not immediately clear.

To make it appear a little more official, we should rather be using @tahoe-lafs organization's github_client_id and github_client_secret. I have initiated transfer of the OAuth app I created to the @tahoe-lafs organization. The transfer is still in "pending" status.

Someone who is an GitHub org admin has to accept the transfer. The button to click that accepts/authorizes the transfer will be presumably somewhere under tahoe-lafs GitHub org's developer settings.

Please accept the transfer, and relieve my GitHub account of gatekeeping duties!

[exarkun]

Which entities have read access to the github_client_secret?

[sajith]

At the org-level, I don't know. Presumably the organizations' admins?

From the setting page that I see, I cannot read github_client_secret once it is created (it is obfuscated), I can only re-generate it. My GitHub account cannot find out who those three users are, at least not directly from the settings page. Discourse is only asking for email address, in any case.

It is also not clear if the github_client_secret I created will remain the same once it is transferred. GitHub's documentation is not clear about this. I can only assure everyone that I have not saved it anywhere else. :-)

[exarkun]

Can Discourse see the secret?

It is also not clear if the github_client_secret I created will remain the same once it is transferred. GitHub's documentation is not clear about this. I can only assure everyone that I have not saved it anywhere else. :-)

In all cases where I've transferred ownership between a user and an organization, the secret has remained the same.

[exarkun]

Can Discourse see the secret?

I looked at the "admin" page with my Discourse account and it will show me the secret.

[exarkun]

This isn't necessarily a problem ... but I do worry about it a little. At the very least, it seems like anyone we make a Discourse admin gains access to the secret. What can they do with the secret? Well, they can pretend to be https://tahoe-lafs.discourse.group/ - but they have to do so at https://tahoe-lafs.discourse.group/. And what they get out of it is the email addresses known to github of anyone who falls for it. It's not much of an attack. Did I miss something else they could do with the secret, though?

[sajith]

Can Discourse see the secret?

Ah, now I understand! Yes, Discourse has the secret. As a Discourse admin, I can view it, so my assurance about not having the secret saved somewhere means naught.

In all cases where I've transferred ownership between a user and an organization, the secret has remained the same.

We can perhaps do this:

1. Remove admin rights from my Discourse account; and
2. Create a new OAuth Application from https://github.com/organizations/tahoe-lafs/settings/applications/new, and then
3. Use the new github_client_id and github_client_secret on Discourse.
4. In addition, limit access to Discourse and GitHub settings to the same set of trusted people.

Not sure if the above is a reasonable approach, but it is an approach...

[sajith]

And what they get out of it is the email addresses known to github of anyone who falls for it. It's not much of an attack. Did I miss something else they could do with the secret, though?

I can't think of any other use of the token. But I guess I am assuming that Discourse will remain trustworthy and only ever ask for email, and anyone that uses GitHub login will stay alert to Discourse asking for too many permissions.