Propose the concept of a crates.io username for identity#3946
Propose the concept of a crates.io username for identity#3946carols10cents wants to merge 13 commits into
Conversation
Regardless of OAuth connections.
carols10cents
added
the
T-crates-io
|
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. |
This comment was marked as resolved.
This comment was marked as resolved.
|
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. There is probably no 100% clean and correct solution for the name collision dilemma. The downside being that it would de-prioritize accounts without crates, or which have not been online in a certain time. |
|
@DrFrugalOfficial please use threads in the diff in the future, so that we can group the discussion topics a bit better 🙏
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. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as off-topic.
This comment was marked as off-topic.
rustbot
added
the
T-cargo
This comment was marked as off-topic.
This comment was marked as off-topic.
rustbot
removed
the
T-cargo
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
rust-rfcbot
added
the
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rust-rfcbot
removed
the
proposed-final-comment-period
|
@rust-rfcbot concern privacy of linked accounts |
rust-rfcbot
added
proposed-final-comment-period
|
@rust-rfcbot concern communicating username mismatches |
|
@rust-rfcbot concern disambiguation with |
Gravatar and similar services can unintentionally leak personal information, which we don't want to do. I don't think avatar hosting is something crates.io should take on at this time, but I've noted that it's the most privacy preserving option. We may want to consider hosting avatars in the future.
…ublic But note a future possibility that we could add the possibility of making an account association private.
|
@rust-rfcbot resolve privacy of linked accounts |
|
@rust-rfcbot resolve disambiguation with I believe I have now addressed all concerns; if you disagree or have any other concerns, please re-raise! |
rust-rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
I'm not too sure how to use the mile long markdown RFC page thing so sorry for another comment. Has the issue of account username moderation been mentioned? I looked and saw mention of avatars being offloaded to avoid having to moderate those, but I did not see mention of usernames. GitHub already deals with usernames containing slurs, profanity, etc. Would crates.io now have to deal with that problem themselves and moderate bad usernames? |
Yes, that is discussed here in the crates.io username requirements section. |
| `carols10cents` username to appear to be that person to users who don't know about the rename or | ||
| deletion. We plan to limit the re-use of usernames, using a similar mechanism that we have today | ||
| that prevents re-use of a deleted crate name, so that no one could claim an abandonded username | ||
| for, say, 30 days. We will allow the person who changed away from a username to reclaim/"revert to" |
There was a problem hiding this comment.
30 days
Is it useful to make the waiting time for username reuse so short (outside exceptional cases such as impersonation)? Does allowing username reuse within a period shorter than, say, "2 years", or "forever", offer enough benefit (e.g., not requiring "Someone" to appear as "Someone_2") to outweigh the risk (supply chain attacks)?
There was a problem hiding this comment.
Right now, when someone deletes a crate in the limited cases owners are allowed to delete, crate names are available again 24 hours after deletion. This has seemed to work well, in that people who see that a name isn't in use are able to legitimately use it, and I'm not aware of any attacks happening because the reuse window was this short.
If we don't allow username reuse, I guarantee we'll have people complaining that they can't use the username they want, and that it's not fair because that username isn't being used. There is a crate name that, because of an incident of harassment (and not because the name itself was inappropriate. I will not be going into further detail on the incident, nor will I tell you the crate name). We added the name to the reserved crate list so that no one can have that name. This incident happened about a year ago, and in that time we have had 6 people ask why the name could not be used because they were trying to use it.
So from the experience we have, I do think allowing reuse of usernames after 30 days offers enough benefit to outweigh the risks. Ultimately, I think we need some experience with username reuse to know what the "right" time interval is. This will be implemented as a database field for each username, much as the deleted crates table is implemented today, so we can change the value at any point.
|
Could we maybe implement something like the AUR where crates could be flagged for abandonment or abuse and handled? Then that way deleted users wouldn't have crates that are deleted, instead waiting for another user to request ownership of them?.. May be way too out of scopr for this thread ngl... 😭 |
Sorry, what's the AUR? And yes, I agree that crate ownership is out of scope for this RFC about usernames. |
I'd assume they mean https://aur.archlinux.org/ |
19 participants
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