Propose the concept of a crates.io username for identity

[carols10cents]

View all comments

This RFC introduces the concept of a crates.io username separate from GitHub (or any potential future OAuth provider) usernames to be able to support multiple OAuth providers someday and adequately handle potential username collisions.

Introducing the concept of a crates.io username in the back end of crates.io and in the user experience is a prerequisite to eventually offering multiple OAuth providers.

Important

Since RFCs involve many conversations at once that can be difficult to follow, please use review comment threads on the text changes instead of direct comments on the RFC.

If you don't have a particular section of the RFC to comment on, you can click on the "Comment on this file" button on the top-right corner of the diff, to the right of the "Viewed" checkbox. This will create a separate thread even if others have commented on the file too.

Rendered

[Diggsey]

Looks very well thought out.

Should there be a limit to how frequently one can change one's username? (Considering the old name will be reserved from some period of time)

Also I think there should be some way to revert a change of name if it's within the reservation window (ie. the old name hasn't been freed up yet) in case the rename was a mistake or the account was compromised.

[DrFrugalOfficial]

Second thing that came to my mind:

It might make sense to run the script to initialize the new login user name in at least 2 batches.
The first one targeting active users which maintain a crate, or have logged in with in the last year, or....
The second one everyone else.

There is probably no 100% clean and correct solution for the name collision dilemma.
It would give people the chance to take their proper user name, if their intended one was taken due to GitHub/crates.io name squatting.

The downside being that it would de-prioritize accounts without crates, or which have not been online in a certain time.
You can decide yourself, where the priorities lie.

[Mark-Simulacrum]

View changes since the review

Does it seem useful to flag prominently that a username was renamed, even if we don't show the before/after names? Relatedly, perhaps we can prevent adding users that were renamed to/from for a holding period (e.g., 1 day), to give time for us to detect impersonation and slow down attacks of that nature?

[carols10cents]

Does it seem useful to flag prominently that a username was renamed, even if we don't show the before/after names?

Hmmm maybe! I'm adding that as an unresolved question for now.

Relatedly, perhaps we can prevent adding users that were renamed to/from for a holding period (e.g., 1 day), to give time for us to detect impersonation and slow down attacks of that nature?

Hmm, perhaps. I wonder how often this would happen, and how often it would be a false positive/annoyance. Also adding as an unresolved question!

[Mark-Simulacrum]

View changes since the review

Maybe related point: it would be worth considering if GitHub:1233 should be accepted, to allow unambiguous addition/removal of GitHub users without a race condition against renames

(E.g., rust-lang/team could conceptually use this for its syncing, though we're moving away from having any users other than the bot rust-lang-owner account on our crates).

[kennytm]

GitHub user name can be pure numbers, so supporting github:1 would be confusing, for instance we knew @mojombo has GitHub user ID "1", but the GitHub user name @1 is currently taken by someone actually with GitHub user ID "1825798"

[Turbo87]

it would be worth considering if GitHub:1233 should be accepted, to allow unambiguous addition/removal of GitHub users without a race condition against renames

I think id:396 would already prevent the race condition, no? but tbh I'm not too worried about this specific scenario. a lot of factors would have to come together to make this exploitable IMHO.

[carols10cents]

Yeah I think to support this we'd have to disambiguate somehow, potentially offering all of these variants:

cargo owner --add github:carols10cents

cargo owner --add github_id:1234556789

cargo owner --add cratesio:carolcrates

cargo owner --add cratesio_id:396

and then I'd worry about confusion between GitHub ID and crates.io ID.

While rust-lang/team (and rust itself) currently assumes each person has a GitHub account, are there project members who would potentially want to drop their GitHub account but maintain crates.io publishing privileges on the crates they maintain? If so, then I think that would push me towards only supporting specification with a crates.io user ID (with id: or cratesio_id: or whatever prefix we decide) and not github_id, if we wanted to potentially reduce confusion.

I'll add this as an unresolved question here, though!

[Turbo87]

@DrFrugalOfficial please use threads in the diff in the future, so that we can group the discussion topics a bit better 🙏

It might make sense to run the script to initialize the new login user name in at least 2 batches.

I don't think this makes much of a difference. If a user is actively publishing then we will have their current GitHub username and there shouldn't be any conflicts. I don't remember if we specified it in the RFC text, but most likely we would run a GitHub username sync right before we assign the crates.io usernames during the migration.

[carols10cents]

Since there is already a refactoring happening, it might be quite beneficial to switch profile URLs to use the ID instead of the username. Because renaming is a feature that is already planned, this would make links safe against link-rot.

From your example in the markdown, this would mean this old URL crates.io/users/carols10cents would become crates.io/users/396

@DrFrugalOfficial I see you resolved this comment and found the unresolved question; I still wanted to address this. We haven't made a firm decision, but one reason I didn't include this in the RFC was that we could decide to make a URL such as crates.io/users/396 (and display peoples' user IDs somewhere) work today, completely independently of this RFC. Then there's a question of whether a user ID url or a username url should be "canonical", whether one should redirect to the other, etc, which again seems somewhat orthogonal to the issues in this RFC.

Now, this RFC may make a user-id-based URL more useful, but to me I don't think URLs like this are essential to this RFC being implemented. I'd be interested to hear thoughts from people who think user ID URLs are required though!

[carols10cents]

It might make sense to run the script to initialize the new login user name in at least 2 batches. The first one targeting active users which maintain a crate, or have logged in with in the last year, or.... The second one everyone else.

There is probably no 100% clean and correct solution for the name collision dilemma. It would give people the chance to take their proper user name, if their intended one was taken due to GitHub/crates.io name squatting.

The downside being that it would de-prioritize accounts without crates, or which have not been online in a certain time. You can decide yourself, where the priorities lie.

Yes, in the process of writing up this RFC I convinced myself that we should be periodically checking GitHub for renamed/deleted accounts, independently of this RFC's acceptance.

I've started a PR for this here: rust-lang/crates.io#13143 and the current implementation would update both users.gh_login and oauth_github.username (currently users.gh_login is the source of truth and oauth_github.username is a replica). If this RFC is accepted, we would make sure we had checked all current users with GitHub and then we would change that background job to only update oauth_github.username.

[carols10cents]

@rfcbot fcp merge crates-io

[rust-rfcbot]

Team member @carols10cents has proposed to merge this. The next step is review by the rest of the tagged team members:

• @LawnGnome
• @Turbo87
• @carols10cents
• @eth3lbert
• @jtgeibel
• @mdtro

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.