Allow the use of crates.io without giving away GitHub organization membership

[john01dav]

Is your feature request related to a problem? Please describe. It seems like crates.io has no way to sign in to publish crates without giving away a list of Github organizations. Since the fact that I'm a member in some organizations is private, I don't want to give crates.io this information unless it is shown to be necessary.

Describe the solution you'd like I can think of three solutions, in this order of preference: 1) Let people sign up to crates.io with a crates.io account. I have a crate in the works that will make it easy to provide robust security for this option, so let me know if you're interested. It's code is for actix-web only, but it should be pretty easy to adapt. 2) Add other SSO providers (as many as possible), with minimum information requested from each one. 3) Turn off the request for organization access with Github SSO.

Describe alternatives you've considered Right now, the only way to sign up seems to be to create and manage a second Github account. While it's possible, this is obviously not ideal since it creates administrative overhead.

Additional context I don't think that more information would be useful to add at this point, but if there's anything more I can clarify please let me know.

[Turbo87]

this appears to be a duplicate of https://github.com/rust-lang/crates.io/issues/326. thanks for sharing your thoughts though :)

[tshauck]

I'm not sure this is a duplicate, though related. As I read #326, it's for an alternative login mechanism (i.e github vs gitlab, which would be great), but this is about the scope github uses. I'm also not keen to use cargo while this is required...

[Turbo87]

@tshauck this is necessary to determine if you're part of an org/team that has owner access of a crate

[TerryRPatterson]

@Turbo87 It would be nice to be able to choice what orgs we grant read access for. I belong to my companies org, and don't want to risk leaking proprietary information.

[bjorn-ove]

This is indeed a problem. Giving access to private project boards that has nothing to do with crates.io is quite insecure and bad practice.

[bjorn-ove]

This is indeed a problem. Giving access to private project boards that has nothing to do with crates.io is quite insecure and bad practice.

I wanted to release a crate today, but found out I can't without creating a new github account as it would give away access to private information.

[Turbo87]

we are aware of the problem and have a few ideas on how to improve the situation. unfortunately, the implementation will take a while though. the only short term workaround is indeed to create a second user account :-/

[nathan-at-least]

Checking for updates. @Turbo87 can you share any of the potential ideas or what trade-offs or blockers they have?

I have two distinct concerns about this issue:

• First, like others above, I do not want private org membership exposed to crates.io. (It feels like the "right / cleanest" solution to this is for Github to offer an OAuth option that does not reveal any private info about the user.)
• Second, I do not want crates.io to authorize my crates.io user account to manage or control crates that are "owned or managed" by other people in Github orgs I happen to belong to.

Should this second issue be a distinct ticket?

It sounds like this statement implies that crates.io makes authorization decisions based on Github org membership, and I want to request a way to opt-out of that. Doesn't cargo owner allow users to explicitly manage crate-scoped authorizations completely separate from github?

If I am authorized to manage crates on behalf of all of the github orgs I belong to, this gives me a capability (thus liability) I do not need or want and presents a security risk to all of those orgs. I'm not sure if each of those orgs know that I have the ability to control their releases, so I would want to double check with each of them if that's an acceptable risk. If it's not acceptable risk, then I would need to potentially be removed from multiple github orgs, which disrupts the other (non-release) ways I collaborate with them. Is there a place I can read about how crates.io uses github info for authorization decisions so I can decide how to proceed?

Having a completely separate policy from github for multi-owner crate authorizations seems like the right way to go, and I had thought cargo owner already provides this.

[nathan-at-least]

Also, can we re-open this ticket?

This is very distinct from #326 since that ticket is about non-Github authentication, whereas this ticket is about existing Github users continuing to authenticate with Github, but distinct from #326 this is about privacy and authorization issues specific to Github authentication.

[LawnGnome]

Also, can we re-open this ticket?

We can!

To be clear, the crates.io team has no immediate plans to work on this, but we're definitely open to ideas and/or PRs if there's a simple fix for this that hasn't been suggested thus far.

[Gunni]

Isn't the simple way to move orgs management over to crates.io db, have it managed there, instead of on github?

Helps implementing https://github.com/rust-lang/crates.io/issues/326 i'd think.

[Turbo87]

@Gunni yes, that is roughly the long term plan, plus a way to sync GitHub teams to crates.io teams.

[carols10cents]

Isn't the simple way to move orgs management over to crates.io db, have it managed there, instead of on github?

I would not describe that as "simple" 😅

[achristmascarl]

as a temporary workaround, I deleted the &scope=read%3Aorg part of the url (near the end of the url) at the https://github.com/login/oauth/authorize step, refreshed, and was able to login using GitHub without having to grant read access to any orgs