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]

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

Concerns:

• communicating username mismatches (Propose the concept of a crates.io username for identity #3946 (comment))
• disambiguation with cargo owner could leak info (Propose the concept of a crates.io username for identity #3946 (comment))
• privacy of linked accounts (Propose the concept of a crates.io username for identity #3946 (comment))

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.

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[tbu-]

I don't see the alternative mentioned or discussed, that one could simply not have crates.io usernames, but only service-scoped ones.

E.g. no username tbu- on crates.io, but rather gh/tbu-, github/tbu- or github.com/tbu-. This would entirely get rid of the problem that usernames would need to be moderated on crates.io side, and it'd stop us from needing to manage squatting in yet another namespace.

View changes since the review

[juleskers]

While an interesting approach, how would this scale to multiple auth-providers for the same account?

For example: I am both:

1. https://github.com/juleskers
2. https://gitlab.com/kerssema/
3. The way Github is going, codeberg or gitea is also a likely future candidate.

Which one of those would be displayed in the owners list?
Both? That might suggest maintenance is a group-effort where it isn't.

[Turbo87]

also, how would this work in terms of backward-compatibility?

[tbu-]

While an interesting approach, how would this scale to multiple auth-providers for the same account?

Might be chosen globally for an account or locally for a crate. I haven't thought about this.

also, how would this work in terms of backward-compatibility?

E.g. phase out mentioning the bare usernames but keep them an alias for the github ones for now.

[carols10cents]

I feel like people shouldn't need to care whether the user carols10cents has decided to add GitLab and remove GitHub.

[juleskers]

Documenting this for future consideration: Gravatar's design of using {md5,sha256} hash-of-email can have terribly harmful side-effects. Please don't go down this path.

• privacy: web tracking by the third-party
  • each gravatar is effectively a stable, user-bound tracking pixel, that the user cannot reset.
• loss of anonymity: cross-linking identities between unexpected sites.
  • I once came across the example of user leaving comment on a lgbtqi-site, leaving an "anonymous" email-adress that "will never be shown"; years later, the user registers the same email with gravatar; later again the lgbtqi-site adds gravatar support -> suddenly the user's face is next to the "anonymous", sensitive post.
    Sadly, I lost the link; the principle remains valid.
• stalking: avatar-hashes are publicly visible (fetch-url in the served HTML), and thus cached in search engines, enabling stalkers to follow their target across multiple sites by searching for the hash.
• in practice, the hashes can be re-linked/decoded to their email address, since the search-space is constrained.
  • e.g. 10% of stackoverflow users, already in 2009;
  • Gravatar itself suffered a data-breach in 2020, exposing user emails and the hashes they were tied to.

These problems lead at least two big platforms (that I know of) to drop gravatar:

• in 2013 Stackoverflow made Gravatar optional for this reason
  • motivated by this SO-META discussion
• Ars Technica reports that Disquss dropped gravatar in 2013 after Swedish journalists re-identified local politicians participating in 'anonymous' far-right forums.

The same concerns apply to any such third-party that uses a stably-derived pseudonym, since it is a protocol-level issue.
As such, I would counsel against even FOSS-alternatives like Libravatar.

The same risk applies in a to avatars "hosted by [a] linked service", depending on the scale of the service.

View changes since the review

[carols10cents]

I'm OK not providing a gravatar option, so the only options would be the avatar with a linked account or a default avatar provided by crates.io (the same URL/image for everyone who chooses this option). If we go with the idea in your other comment about being able to change the linked accounts to be private, it seems like a good default would be to not allow the user to choose to use avatars from private linked accounts as that would potentially leak information, does that sound correct?

[juleskers]

to clarify: this risk is not exclusive to only gravatar.
While gravatar-the-company doesn't enjoy my personal vote of confidence, the underlying issue is the decision to publicly expose (via URL) a derived token (here, md5(email)/sha256(email)) derived from a non-public token.

Exposing "derivative-of-secret" unfortunately gets one 70% of the stalker-nightmare of exposing the secret directly.

---

I totally get not wanting to host avatars.
It is however, the only way to keep browsing data fully out of third-party hands.
However, that doesn't have to be the goal unless you want it to be (and have the maintainer capacity and bandwidth for it).

---

"avatars from private linked accounts [...] would [..] leak information"

That indeed sounds correct!
I myself serve as a bad example: I (knowingly) use the same picture on both gitlab and github, so my accounts could be tied together from that, even if I tried to hide one of them on my crates-profile.

---

not allow the user to choose to use avatars from private linked accounts

Yet another implementation complexity stemming from the concept of private-linked accounts.
To be honest, the more I think about it, the more I'm leaning towards "screw it, all linked identities are public".
As I mentioned in another thread: not-linking accounts one wants to keep separate is the most principled stance, since it also avoids trusting crates-io admins (and potential crates-io-DB-hackers).

[carols10cents]

@rust-rfcbot concern privacy of linked accounts

[carols10cents]

@rust-rfcbot concern communicating username mismatches

[carols10cents]

@rust-rfcbot concern disambiguation with cargo owner could leak info

[juleskers]

As offered and accepted, I've split my concern-thread into per-topic threads for easier discussion.

While thinking on this topic, I also realised the additional concern of account-selling becoming (more of) an option.

View changes since this review

[juleskers]

Concern: Information leak via disambiguation / linked-identities

This opens up an obvious information disclosure vector: "owner --add foo" -> "did you mean github:foo or gitlab:foo" -->

• discloses existence of two accounts on other services, which may or may not be set to private/non-visible on their respective service.
• discloses that there exists a crates-io user for these two specific external services (regardless of name), which increases the value of hacking those accounts on the external platform.

---

This issue becomes more complex, should crates.io decide to implement privacy-preserving settings, to hide linked accounts.

The disambiguation page (or any other identity-accepting API) must not inadvertently disclose the existence of a linked-but-private account.

This reduces the disambiguation-usefulnes, and imposes an endless upkeep-burden: Every future API will need to be implemented carefully to avoid accidentally accepting or emitting hidden-identities.

This can be as subtle as a timing attack: if "doesn´t exist in DB" returns in 13ms, but "exists in DB, but additional check of the privacy-flag hides it" returns in 20ms, that's information-disclosure, even if the error message is byte-for-byte identical.

Such lookups can be implemented in constant-time, but that is an additional technical burden that doesn't exist if APIs only accept crates-io identities.

This also makes the experience inconsistent if a connection is known to the person using the API, but marked as private/login-only:
couldn't add owner gitlab.com:kerssema; no such account is known to crates.io -> "but I know that's Jules!?!?"

---

depending on the exact API accepting or emitting linked aliases, it may also need to consider:

• enumeration attacks:
  • iterating through crates-id 1-999.999 to see which github-usernames fall out of the responses.
• credential-stuffing: trying a set of github/gitlab/whatever usernames (potentially from a recent breach database, perhaps dictionary lists) to see if they have a linked crates-account
  • confirming the existence of such a link "enriches" the stuffing-dataset, and can prioritise the external account for compromise
• de-anonimisation: trying all gitlab-accounts to see with which github-accounts they may correlate.
  (if "github:foo" and "gitlab:foo" don't yield disambiguation pages, this confirms that those two external accounts are tied to the same crates-account)

---

All of these are an endless ocean of potential trip-ups with each new API-endpoin needs to consider, handle, and handle correctly despite a lot of subtlety involved.

[Turbo87]

it might be worth being aware of the current situation, where crates.io shares a public daily database dump (https://crates.io/data-access#database-dumps) which includes all user accounts and their GitHub association. in other words, in the current setting there is nothing that would be leaked because all of that is already public and changing anything to private would be a bigger task.

[juleskers]

Concern: communicating username mismatches ("⚠️")

I am reminded of the (original) twitter-blue-checkmark: deciding on whom to apply a status-conveying icon is socially fraught (relevant XKCD: 1914: Twitter Verification).

• It is immaterial to the complexity if the charge is positive (blue "verified" check), vs. negative ("⚠️")

A specific technical concern against the ⚠️-icon is that's binary, it works only for a single service.
It's not future-proof for a multi-provider situation:
Would I be forever-doomed to a mismatch-⚠️ since my crates-name can never simultaneously match both "kerssema" (gitlab) and "juleskers" (github)?

---

A more semantically neutral option could be to display the other-services' icon next to the crates-username, if-and-only-if the usernames match: So, depending on my crates-io name, I would be shown as:

• "best-rust-user-ever 📦"
• "juleskers 📦
• "kerssema 📦🦊"

This has no ambiguity, is works in a multi-provider future, and avoids any "branding the heretic" implications of bad/alarming symbology.

Transferring trust for accounts without matching usernames can be done by listing them on the profile page. (example below)

---

Applying this idiom to the present situation: all users have a "show publicly"-provider for GitHub.
Since there is no name-sync until rust-lang/crates.io#13143, some users may have outdated names, so may show as either "former-github-username 📦", or "current-github-username 📦 "

[Turbo87]

• we are planning to display all linked accounts on the user details page
• the warning icon is mostly for places where there is not enough space to display all of the usernames of an account
• the warning icon is only applied to GitHub/crates.io mismatches, not to other providers, because the current assumption of users is that they are identical, which would no longer be the case. there was never an assumption of e.g. Codeberg username being identical to crates.io username.
• once people are aware of the account name split we might remove this explicit warning again in 1-2 years or so but that is a dedicated discussion when the time comes

[juleskers]

concern: privacy of linked identities / "outing" our users

When considering a multi-provider future, there is an nuance that I think is currently overlooked, but which I feel is worth documenting and discussing explicitly:

"Supplying an oAuth-provider for the purpose of logging in" is not automatically the same as "desiring to publicly disclose that these identities are the same".

Choosing a one-to-one correspondence github<->crates.io is a simple choice. Desiring to add multiple providers opens up the entire can of worms, and I think the future possibilities already need to impact current API design.

---

For the record: I see great value in identity-linking for the purposes of supply-chain auditing.
Knowing that crates-io-BurntSushi is the same as the github-BurntSushi is a positive, and establishes trust, as already called out in the RFC.

On the other extreme, even though qDot isn't shy about uploading Crate: Buttplug, not everyone desires (some even cannot afford) that same association.
Thus, there is also (context-dependent) value on NOT (at least not publicly) making this trust-transference.

As I mention under "Gravatar", linking identities can have unforeseen, far-reaching side-effects, such as de-anonimisation.
Several religions would frown on their flock contributing to the buttplug-crate. Some would "frown" violently..

Other groups may have other hangups, but at least involvement in cryptocurrency and AI seem like contentious topics from today's perspective.

Lets not forget the lessons from the "sad day for rust" when actix-web got brigaded for cavalier unsafe-usage.
That is to say: association with specific crates may be something users want to keep separate from their "other" online-identities for impossibly-to-predict reasons.

---

Technical solutions exist on both ends of the spectrum:

• Keybase.io is expressly designed to enable ID-linking, cryptographically verifiably.
• Firefox Relay is explicitly built to separate identities (as are thousands of similar email maskers).

I point this out to show there is a spectrum of correct-but-opposite answers, and crates.io needs to (intentionally, with foresight) pick a spot on this spectrum in order to make consistent design decisions.
I do NOT think this choice can be postponed to "whenever we add a second provider", since in effect the uncoupled crates.io-identity is the first "additional" ID-provider.

---

To respect the users' wishes / avoid outing them, we should allow them explicit control over which login-providers are listed publicly.
In effect: each connected login-identity would need a flag "shown publicly" vs "private, only for login"
To avoid accidentally outing-by-default users, this flag-choice should be explicitly made by the user when setting up the provider-link.

This flag should also affect the "username matches"-icons.

• I think this is not a performance concern, since it can be pre-calculated/memoized when the name is changed (Wheter by the user, or by other-service-sync applying a name-change).

Alternative

Rather than implementing such a flag, and all the associated complexity, we could simply advise the user to not-link accounts they want to keep separate, and create multiple crates-io accounts instead.
Thus choosing to come down on the Keybase side of the choice-spectrum: linking is always intended to be public; that this linking also enables the other-service as a login-provider becomes more of a 'nice to have' bonus.

This is a sensible, defensible choice, both considering technical implementation burden and considering OpSec.

• Implementation burden: If all linked accounts are intentionally public, the "information disclosure" discussion becomes moot.
• OpSec: To the person keeping their identities separate, not-trusting crates-io admins (and any DB-hackers) with this (apparently sensitive) identity-link is a consistent answer, even if it involves more hassle maintaining multiple OAth-accounts on other providers.
  • I could, and perhaps should have crates-accounts for "JulesAtWork", "JulesFreeTime" and, for the risque work, "SomeoneSniffsButtplugs" (of course referring to wiresharking the device's Bluetooth packets for the Buttplug-crate ), rather than relying on crates-io to successfully keep the secret that "github:juleskers" is the same person as "codeberg:buttplugger". It also reduces the chances of me accidentally publishing a crate to the wrong login, and thus inadvertently disclosing the link myself.

[Turbo87]

IMHO this is orthogonal to this RFC, or rather an extension, or maybe call it out of scope :D

whether to support private linked accounts too can be another RFC and built on top if we choose to do so. it's worth keeping in mind as a future possibility and I don't think anything in this RFC is currently blocking such a future extension, but I don't think it needs to be in scope for this RFC.

[juleskers]

I fully agree that "just don't link accounts you want kept private" is a very valid solution, certainly for the initial implementation.
The possibility of private-linking should definitely be a separate RFC.

However, I do think the shape of the API we are designing here would be constrained if we want to keep open the possibility of adding private accounts in the future.
In short: I don't want us to paint ourselves into a corner.

For example: The discussion on allowing external identity specifiers for cargo owners --add ... currently makes the assumption that all such identifiers are publicly known.

I also feel the risk of accidental information disclosure in a private-linking world, especially via side-channels, and the added implementation burden to prevent those is a factor worth weighing now, since it weighs towards "YAGNI".

"Always public, now and forever" is a valid choice (which removes the constraints on API design).
I would prefer if that choice were made intentionally, rather than by accident.

[Turbo87]

The discussion on allowing external identity specifiers for cargo owners --add ... currently makes the assumption that all such identifiers are publicly known.

hmm, I'm not sure that's true. AFAICT we could restrict cargo owners --add ... to only work for public linked accounts in the future without breaking changes since private linking would just be an additional feature. but I also think cargo owners --add ... should only support crates.io and github specifiers to disambiguate from the current assumptions that the account names match, but I don't think we need to add support for other providers to this API.

[juleskers]

As an alternative way to support the purposeful, intended trust-transfer, linked login-identities could be listed on the users profile page, completely orthogonal from the matching/non-matching of the usernames.

For example:

best-rust-user-ever 📦
confirmed public aliases on other services:

• juleskers
• kerssema 🦊

or

juleskers 📦
confirmed public aliases on other services:

• juleskers
• kerssema 🦊

I think the profile page is sufficient for establishing such ID-links for the purpose of trust-transfer.
It's not a dominant concern everywhere that the username is shown, whereas attaching alarmist-⚠️ to a username would be distracting in many contexts.

---

In the scenario where identity providers can be linked privately, were I to desire to hide my association with github for any reason, the listing would instead look as follows

**juleskers 📦 ** <-- no octocat, even though username matches
confirmed aliases on other services:

• kerssema 🦊
• github username omitted from listing, but still available for me as login option

[Turbo87]

yes, we are planning on displaying the linked identities on the user details pages

[juleskers]

future-proofing: should this be a per-service boolean (concern: field explosion), or a list of matching-providers, that is:

{ "user": {
  "id": 396,
  "login": "carols10cents"
  "username_matches": ["github", "codeberg", "atlassian"], // alternatively: perhaps directly encode the services as a nerd-font character? less bytes, more visual goodness.
}

The latter design can add additional identity providers without changing the API-type.
Downstream users would not have to deal with the json-equivalent of #[non-exhaustive].

[Turbo87]

no, as mentioned above, we only need this to warn about cases that disagree with the current assumption that crates.io and GitHub account names are identical. IMHO there is no need to expand this to other providers.

[juleskers]

This is a good example for the added complexity that would come from having privately-linked identities, and why I can definitely see "all links are public" as a valid choice.

• the implementation could forget to inspect the public/private flag, accidentally disclosing hidden accounts
• the implementation could take different amounts of time deserialising N items from the database, potentially disclosing the amount of linked accounts. This is problematic if a subset is subsequently not-displayed due to the private-flag (disclosing the amount of privately-linked identities, which may even disclose the specific services by where the "holes" are in the known-supported list)

[juleskers]

Concern: viability of account-selling / admin-cost of cleanup thereafter.

re: "deleted":
Allowing to add and delete ID links opens crates-io up to account-selling, a not-uncommon problem in online multiplayer games.
I posit that crates-io accounts can easily have the same real-world value as a level-80 warlock with full adamantium armour.
(More valuable if we consider how foundational certain rust-crates are for supply chain attacks.)

For those who are perhaps unfamiliar with the practice, the general scheme is as follows:

1. an account is registered using provider-A:user-A
2. account gathers "value"/"trust"/"gold"/whatever, even if that is only passively by existing for a long time without doing anything bad. Perhaps activity is simulated, or even real activity is done.
3. owner-A decides to cash in (perhaps it was the goal all along, perhaps a legitimate user decides they'd rather be a goose-farmer) and organises a sale via outside channels.
4. identity for provider-B:user-B (potentially also provider-A:user-B) is added by user-A to honor the sale.
5. provider-A:user-A is unlinked by user-B.
6. user-B now owns the trust invested in User-A.

While this risk also exists in the current situation where an entire github account can be sold, the costs/benefits tradeoff shifts if I can sell my crates-account without losing my github-account in the same package-deal.
These changed incentives shift the threat model.

---

Note that this can also happen unintentionally. Imagine BurntSushi's github account were compromised, the linked crates-io account could be quickly transferred to github:evil-hacker.

---

As a secondary concern: This means additional triage and sleuthing workload for the crates-io admins, which is currently handled by githubs accounts-team.

[Turbo87]

so what are you suggesting here? I don't think not being able to change linked accounts after creation is viable

[tbu-]

Pointing out a problem does not require you to have an answer. ^^

Note that this can also happen unintentionally. Imagine BurntSushi's github account were compromised, the linked crates-io account could be quickly transferred to github:evil-hacker.

This particular scenario could be avoided by not allowing removal of old connections for some time after adding new ones, maybe a month?