Multiple identities on the same registry for `cargo login` and `cargo publish`

[cyqsimon]

Problem

I have multiple distinct accounts on crates.io for which I publish crates. I would prefer to be able to stay logged in to all these accounts simultaneously.

Proposed Solution

Perhaps namespace support in git-credential-manager is a good reference. Currently this is how I handle my multiple git identities.

But on second thought, maybe namespace support leads to too many edge cases and orthogonality concerns with multiple registries, and is frankly overkill for what I want. So perhaps a registry.identities (and the corresponding registries.<name>.identities) table? It would look something like this:

[registry.identities]
alice = { token = "TOKEN_ALICE" }
bob = { token = "TOKEN_BOB" }

So this would be an opt-in "named identity" feature, and the current system would be then known as "unnamed identity". Everything right now would work the same because "unnamed identity" would still be the default mode of operation. But now with an additional CLI option --identity <who> (for cargo login, cargo logout, and cargo publish), cargo would read and write these "named identity" fields instead.

Notes

Previously I have been saving the tokens to local files, and then using cargo publish --token to dynamically select which one I use. I had this all written in a script. But more recently cargo publish --token has been marked as deprecated, so now I'm looking elsewhere.

The easiest thing for me to do right now to "just make it work" would be to switch to the CARGO_REGISTRY_TOKEN environment variable. Or I can create multiple named registries that each represent an identity, but are all in fact crates.io, thereby coaxing the current multiple registry support to act as multiple identity support. But at this point the amount of gymnastics I'm doing plus my presumption that this may be a common need would warrant asking for proper upstream support.

[weihanglo]

Thanks for the proposal! The Git Credential Manager approach does look interesting. As an external plugin, it leverages the Git credential helper mechanism.

Actually, Cargo also supports the similar mechanism via credential provider (see https://doc.rust-lang.org/cargo/reference/registry-authentication.html#credential-plugins). I wonder if you have tried to implement a similar one, or have seen any in the wild. If it cannot achieve what GCM does, what is missing in our protocol then.

[weihanglo]

See also

• https://doc.rust-lang.org/cargo/reference/config.html#registrycredential-provider
• https://doc.rust-lang.org/cargo/reference/config.html#registryglobal-credential-providers
• https://doc.rust-lang.org/cargo/reference/credential-provider-protocol.html

[cyqsimon]

I wonder if you have tried to implement a similar one, or have seen any in the wild.

None that I am aware of. Granted I haven't looked into it too much.

If it cannot achieve what GCM does, what is missing in our protocol then.

The thing about Git and GCM, is that:

1. GCM is free to define custom configuration fields in git config
2. GCM is free to take over standard IO to perform arbitrary interactive authentication

Neither of which is true for cargo's credential providers, I don't think, which makes cargo's credential providers more restricted on extensibility.

Specifically in this case, Git has no notion of "namespace" or "identity" at all, but GCM is able to introduce these concepts without explicit cooperation from upstream. But I don't think a cargo credential provider can do such thing so easily. Within the current protocol design, cargo really needs to understand identities and include that info in the messages it passes to the provider.

[cyqsimon]

hey @cyqsimon is anyone working on this issue? if not I want to take it and start working on this.

Feel free to go ahead! Thanks in advance. ❤️

[epage]

Note that at this stage, "working on" is exploring requirements, high level designs, and getting cargo team buy-in, see https://doc.crates.io/contrib/process/working-on-cargo.html#before-hacking-on-cargo