Non-Github account creation

[ntninja]

http://doc.crates.io/crates-io.html says:

Acquiring an API token

First thing’s first, you’ll need an account on crates.io to acquire an API token. To do so, visit the home page and log in via a GitHub account (required for now).

Any plans to change this? Not publishing on crates.io meanwhile…

---

Current status

The team consensus is summarized in this comment:

Yes there's no particular reason that we don't have anything other than GitHub yet beyond that no one's actually implemented it. It was always the intent to have a variety of login options, and then you could link multiple login varieties to the same account (e.g. you can log in via oauth from either Twitter or GitHub)

That is, we are in favor of adding additional login methods, and we do not need any further discussion or 👍🏻 s on this issue so it is locked.

But there are a number of hurdles to get there:

• crates.io usernames currently match the GitHub usernames, so if we allow a different provider we will need a way to avoid conflicts
• the current system for assigning teams as crate owners is unfortunately directly tied to GitHub teams
• from what I was told, GitHub is somewhat good at preventing spam accounts and other malicious activity, which we can't handle ourselves with the existing resources of the project
• the code and database are quite tied to the assumption that GitHub is the only login (the users table has column gh_login and gh_id for example), so significant refactorings need to take place to enable adding other services

The way forward is to find solutions for all of these, writing RFCs as neccessary to propose these solutions, then implementing the necessary changes.

If you are interested in helping with this work, please feel free to get started!

[steveklabnik]

I don't know of anyone working on additional logins.

Given that you already have a github account, what specifically is the issue? I can think of a few, I'm interested in yours, specifically.

[ntninja]

Particularly my problem is that I don't have crates.io account and that I don't think GitHub has, or should have, anything to do with publishing Rust crates. How is there any (not artificially induced) overlap between what crates.io does and what GitHub does?
There is practicality none, except for the fact that crates.io developers seem to really have taken a liking in using GitHub for everything and one thing more. Using GitHub as public git file storage is similar to this, but in a much less worrying way: GitHub remains a strictly swappable component. Don't like GitHub anymore one day? Just adapt @bors to something else and within a day or two you're done migrating. Also that's something that can easily done by a core developer; switching the user backend? Not so much…

@steveklabnik Is there any benefit to using GitHub Account API, aside from the fact that it happened to be the first user database that attracted some developer's eye?

[steveklabnik]

except for the fact that crates.io developers seem to really have taken a liking in using GitHub for everything and one thing more

The only things dealing with github are the index, which is a plain git repository, and therefore easy to swap, and the login system, which is the usual oauth based thing. Publishing crates, other than oauth being the only way to get a crates.io account at the moment, has nothing to do with github.

The reasons for choosing GitHub for logins was the same as any site that enables OAuth: new users don't have to trust us with storing passwords, nor making Yet Another Account on another website. There's no inherent reason that it has to stay GitHub only, other than nobody has bothered to actually implement it.

[ntninja]

… except that crates.io really isn't a lot more than an index with per-login management.
But we're actually not disagreeing on anything, so let's not argue over what each of us considers a lot in this context.

Since you seem to not be not very fond of the idea of "normal" logins (correct me if I'm wrong). Have you considered an OpenID login option instead?

[steveklabnik]

Well, there's also the hosting of all of the crates' source code, permissions around who and what is exactly allowed to publish, validating that Cargo.toml is filled out correctly......

I'm not opposed to a 'normal' login. I wouldn't be particularly pro-OpenID though, personally. But it's @alexcrichton 's opinion that matters most.

[alexcrichton]

Yes there's no particular reason that we don't have anything other than GitHub yet beyond that no one's actually implemented it. It was always the intent to have a variety of login options, and then you could link multiple login varieties to the same account (e.g. you can log in via oauth from either Twitter or GitHub)

[ntninja]

@alexcrichton: So if I were to come along with an OpenID Auth implementation you'd probably merge it (aside from the usual getting-to-know-the-codebase-mistakes of course)?
Could you give me some pointers to were it'd be a good idea to implement this in the current codebase?

[alexcrichton]

@Alexander255 certainly! Github authorization is currently handled around here, and I suspect that something like OpenID would be similar and we'd just want a landing page to pick which one you want ahead of time (instead of always going to github first)

[grawlinson]

So what's actually required to implement alternative logins? Just hooking into Gitlab's OAuth provider?

Would anyone be willing to mentor me if I choose to work on this?

[jtgeibel]

@grawlinson here are some of the places we have code that interacts with GitHub:

• src/app.rs - configuration of the OAuth client
• src/controllers/user/session.rs - endpoints so that the frontend can obtain the authorization URL to open in a popup, and to verify the code provided by the completed authorization
• src/github.rs - interaction with the GitHub API, mainly for determining team membership
• src/models/team.rs - If the login contains a ":" it is a GitHub team. (A team member can publish and yank owned crates, but cannot add/remove other owners.)
• src/models/owner.rs - If the owner is not a team, then they have full access to the crate.
• src/models/user.rs - The user model includes fields such as: gh_id, gh_login, gh_avatar, gh_access_token

There are several tricky things to keep in mind. It's been a while since I've looked at the details, but there is logic to handle renamed users and teams. If I recall correctly, we use the gh_id field for users and update the gh_login if the user has renamed themselves on GitHub. Teams are handled differently, so that if a team is deleted and a new one with the same name is added, then we pick up the new ID number for the team. I expect that there would be similar issues when dealing with GitLab users and groups and that we would want to extract this somehow to be as generic as possible.

In addition to the backend work, there would also need to be a frontend interface to select the appropriate login provider.

Since this looks like a fairly large amount of work, I think we would want to split this up into multiple PRs, incrementally adding functionality and enabling the frontend interface in the last one. A good place to start might be to see if there is a reasonable way to extract the GitHub specific fields from the user/owner/team models to abstract over multiple OAuth providers.

[grawlinson]

OK, I'll have a look at the models and get started on a PR.

[maghoff]

@grawlinson, did you get anywhere with this? :) Now that login (again?) is required for publishing, I think there's renewed interest in this. From the comment history it looks like you are working on it, but it's been a while since the last update. Can you confirm if you're still on the case? :)

[grawlinson]

I'm still interested in implementing this, but real life takes up all my free time at the moment.

I can probably spare a day or two per week, if anyone's willing to mentor/guide.

[tarcieri]

This really feels to me like something that should go through the RFC process. Identity and its relationship to access control are touchy topics, and ones which should, IMO, get proper design and security review before implementation work starts.

[grawlinson]

Agreed. I’ll start drafting and submit a RFC over at the rust-lang/rfcs repository.

…

On 31/03/2019, at 04:47, Tony Arcieri ***@***.***> wrote: This really feels to me like something that should go through the RFC process. Identity and its relationship to access control are touchy topics (and also an area of personal expertise for me), and ones which should, IMO, get proper design and security review before implementation work starts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jolhoeft]

Last month I added OAuth support for several providers to my nickel.rs based site (https://virtuarasa.com/), so a lot of these issues are fresh in my mind, although I've not yet looked at the crates.io code yet. @jtgeibel 's outline of the issues above maps to much of what I needed to deal with. If it won't step on anyone's toes, I'd like to take a swing at this. My oauth identity module may generalize for this application (if so I'll make a separate crate of it).

I would treat linking accounts, e.g. having a login with Google the same as a login with Github, as a completely separate issue after multiple providers are supported.

Is there a desire to support local accounts, i.e. users create a username and password on crates.io?

[carols10cents]

Is there a desire to support local accounts, i.e. users create a username and password on crates.io?

Not at this time, no.

[tarcieri]

@jolhoeft perhaps you could help @grawlinson work on an RFC?

[jolhoeft]

I've got some time to focus on this. Should I just draft an RFC and create a PR, or would it be better to post it here for discussion first? Also, is there a good example of a crates.io RFC to look at? There seem to be mostly language RFCs, which seem to be looking for somewhat different things than this would.

[grawlinson]

Looking at the RFC process, it may be more desirable to discuss it some more on this issue. Plus, this issue does have all the related links/issues/etc posted on it so far.

Would you say that "support for alternative OAuth providers" is a good starting point, @jolhoeft?

[jolhoeft]

Yes, maybe "Support Configurable OAuth providers". Sadly, login with OAuth is not particularly standardized, with most providers rolling their own identity schema. There is OpenIDConnect, which Google and I think PayPal support, but most others supply some custom defined Json blob. That said, I think we could manage to cover most providers with just configuration values, so providers could be enabled and disabled at startup or even while running.

Some question I need to go through the code to find out:

• What information are we getting from Github? I just needed the provider's user id, email address, and display name, which have always been available with a single api call.
  • Annoyingly, Google recently stopped providing the display name
• What struct are we using for users and where are we storing it, presumably a database table?
  • Can we extend the table for the OAuth, or is it better to add another table? I suspect the latter.
• (Not the code) What providers are important to support?
  • I initially supported five, and I fear I may have opened myself up for some operational headache, as they periodically change or break. Fewer may be less burden.

We are using diesel for persistence, conduit as a web framework, and a rather old version of oauth2. I may create a PR to upgrade oauth2 before I get too deep into this.

[jolhoeft]

BTW, how does crates.io interact with the private cargo repositories? That seems like that would impact this.

[tarcieri]

Also, is there a good example of a crates.io RFC to look at?

@jolhoeft one example is the RFC for signing registry index commits: rust-lang/rfcs#2474

[ghost]

Waiting for GitLab login or email login!

[jolhoeft]

I need a week free to code this up, but that doesn't look likely before late January. I stalled out on the RFC initially. I should probably have just create a pull request and let the discussion go from there.

[carols10cents]

@recapitalverb nope, this issue is still up for grabs if you'd like to work on it!

[Xaeroxe]

This really feels to me like something that should go through the RFC process.

Has anyone written an RFC yet or is that step still needed?

[AaronM04]

I would be happy to beta test such a solution when it's dev complete!

[prnam]

Will there be other ways to sign up?

I use GitLab and want access without needing to mirror my repo to GitHub or make it public.

[trevyn]

Will there be other ways to sign up?

I use GitLab and want access without needing to mirror my repo to GitHub or make it public.

You need a GitHub account to get a publishing token, but it’s not otherwise connected; you don’t need to push any code to GitHub at all.

[carols10cents]

Will there be other ways to sign up?

There will be other ways to sign up when someone has time to implement it.

[prnam]

Will there be other ways to sign up?

I use GitLab and want access without needing to mirror my repo to GitHub or make it public.

You need a GitHub account to get a publishing token, but it’s not otherwise connected; you don’t need to push any code to GitHub at all.

I want to push the crates with org(GitHub) and group name (GitLab). For example: acme/project. How to achieve that?

[WhyNotHugo]

@prnam That's unrelated to this topic; see #8292.