Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub authorization requested permissions #191

Closed
mintern opened this issue Sep 2, 2015 · 6 comments
Closed

GitHub authorization requested permissions #191

mintern opened this issue Sep 2, 2015 · 6 comments

Comments

@mintern
Copy link

mintern commented Sep 2, 2015

When I "Log in with GitHub", it requests permission for "Organizations and teams: Read-only access". According to GitHub:

This application will be able to read your organization and team membership.

There is no explanation on crates.io about why this permission is necessary.

My particular concern is that I use a single account for my (public) personal organizations and repositories and also for my (private) employer's organization, as GitHub encouraged me to do.

I am contributing to Rust on a personal basis, and I am uncomfortable (as an employee) with exposing private, proprietary information to an external entity without authorization from my employer, and I would prefer to avoid asking for that authorization.

@steveklabnik
Copy link
Member

The reason is that entire teams can own crates: #177

@mintern
Copy link
Author

mintern commented Sep 2, 2015

Thanks for the sharing the reason and the context!

GitHub has clarified that this allows crates.io to read membership and repository information of all the Organizations that I am part of. One of those is a private Organization owned by a private company operating in the legal sector; we are security-conscious, and it wouldn't really be appropriate for me to grant that access to our company's organization.

Is there a more fine-grained way to request the necessary permissions? Can the permissions be requested later on, if someone actually has a team-owned crate they are trying to publish?

Since crates.io currently only supports logging in via GitHub (AFAICT), this is currently blocking me from creating an account and publishing a crate. My only options seem to be to share information that I'm uncomfortable sharing, or to create a new GitHub account that is completely unaffiliated with my employer.

I'm working with GitHub to see if it would be possible to offer more fine-grained permissions on the user side. The authorization UI shows the list of organizations that you will gain access to, and it seems like it should be possible to uncheck the ones that I don't care to share. :fingers_crossed:

@alexcrichton
Copy link
Member

Yeah we only need organizations read access to be able to add teams to crates. You should, in theory, be able to deny us that permission and still be able to log in though. I thought the GitHub auth UI would allow you to do this, but maybe not? Or did you deny us access and then we generated a bug?

@mintern
Copy link
Author

mintern commented Sep 2, 2015

The GitHub auth UI doesn't seem to provide any ways to deny access. This is the screen I see when I click "Log in with GitHub":

auth

@mintern
Copy link
Author

mintern commented Sep 3, 2015

I wouldn't have a problem with closing this. I'm working with my employer to enable third-party restrictions (this unfortunately requires half of us to regenerate our SSH keys, but oh well). I was able to confirm using mintern-java that when an Organization has third-party restrictions enabled, the page above includes a button for choosing whether or not to grant access to that Organization.

IMO, it's a GitHub bug that the button is only present when third-party restrictions are enabled. Separately, I think it would be nice if GitHub allowed requested permissions to be rejected. The crates.io team shouldn't have to work around these shortcomings.

Thanks for your attention and information in this matter! It was much appreciated.

@alexcrichton
Copy link
Member

Ok, sounds like once those restrictions are enabled you should be good to go, and otherwise things should work as one would expect, so closing. Thanks for the report again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants