Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow passing a credentials.toml file path as a CLI arg for cargo login and cargo publish #13932

Closed
DeflateAwning opened this issue May 19, 2024 · 7 comments
Labels
A-registry-authentication Area: registry authentication and authorization (authn authz) C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-login S-propose-close Status: A team member has nominated this for closing, pending further input from the team

Comments

@DeflateAwning
Copy link

Problem

Publishing crates with multiple accounts is a common-enough practice. It would be nice if one could run cargo publish --cred ~/account1/cargo_cred.toml to use account1's credentials.

This feature should be added for both cargo login and cargo publish (and any other subcommands I'm forgetting).

Proposed Solution

Python's PyPI supports this functionality via the --config <path> arg (but --config is already in use for cargo). --cred <path.toml> is probably the next best option.

Notes

No response

@DeflateAwning DeflateAwning added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels May 19, 2024
@epage epage added Command-login A-registry-authentication Area: registry authentication and authorization (authn authz) labels May 19, 2024
@epage
Copy link
Contributor

epage commented May 19, 2024

We support credentials from multiple sources, not just credentials.toml and I think there is a preference for deprecating cargo:token as it stores the credential in plain text.

@DeflateAwning
Copy link
Author

Good to know! Unless there's a solid plan and a deprecation date picked for removing credentials.toml support, I still think that there should be a way to pick the credential storage file via an arg.

All those other methods seem very good once they're implemented, but they seem like a pain to get right, and a pain to make sure the right credentials are used for the job.

@epage
Copy link
Contributor

epage commented May 20, 2024

Unless there's a solid plan and a deprecation date picked for removing credentials.toml support,

The plain text credential is all but deprecated. Tote that deprecation is separate from removal. This isn't so bad that we expect to break compatibility. However, i see it unlikely for us to add new features specific to plain text token management. The finishing of the deprecation is dependent on a documentation audit (and improving small workflow issues found along the way).

All those other methods seem very good once they're implemented, but they seem like a pain to get right, and a pain to make sure the right credentials are used for the job.

We have other credential managers today.

@weihanglo
Copy link
Member

See also #13623 for some possible approaches we might want for de-emphasizing plain text login.

@weihanglo
Copy link
Member

Since we tend to deprecate and discourage the usage, for me I wouldn't add more features for plaintext credentials.

For implementing custom credential providers, the protocol accepts additional arguments so shouldn't be too complicated to roll out out something like cargo login -- --cred <path> by hands.

@ehuss
Copy link
Contributor

ehuss commented May 20, 2024

Credentials like token are just regular config files. The --config CLI option should work to specify a file that has your token values.

However, as stated above, it is probably not a good idea to store your credentials in an unencrypted plain file.

@ehuss ehuss added S-propose-close Status: A team member has nominated this for closing, pending further input from the team and removed S-triage Status: This issue is waiting on initial triage. labels May 20, 2024
@weihanglo
Copy link
Member

Second. Close.

@weihanglo weihanglo closed this as not planned Won't fix, can't repro, duplicate, stale May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-registry-authentication Area: registry authentication and authorization (authn authz) C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-login S-propose-close Status: A team member has nominated this for closing, pending further input from the team
Projects
None yet
Development

No branches or pull requests

4 participants