Make support for libsecret and other credential providers more discoverable

[nazar-pc]

Problem

Storing sensitive tokens in plaintext files is not great. It is quite bad I'd argue, especially since crates.io doesn't even support 2FA yet, so anyone who gets their hands on the token can publish whatever.

While cargo supports things like libsecret on Linux, I had no idea about it and even if I tried, it doesn't seem to work unless I read the docs and add this to the configuration file:

[registry]
global-credential-providers = ["cargo:libsecret"]

Proposed Solution

Support for canonical credential providers on various platforms should, ideally, be the default way with plaintext file being the fallback.

Otherwise, at least ask the user where they want to store the token rather than silently storing it in a plaintext file.

Notes

No response

[epage]

We have them specified as part of a recommended config at https://doc.rust-lang.org/cargo/reference/registry-authentication.html#recommended-configuration

As part of #13343, I was considering whether we should deprecate falling back to the default credential provider.

Solutions around prompting the user or extending the default would have to be evaluated for end-user impact to make sure we don't make a breaking change.

[nazar-pc]

Very interesting, I'm pretty sure it doesn't actually work that way, meaning that is not the default.

From my testing (multiple times, including just now) cargo didn't attempt to use libsecret until I added [registry] global-credential-providers = ["cargo:libsecret"] to the config file explicitly.

[epage]

I just edited my comment. I didn't mean "default config" as in what the defaults are but more of "recommended config".

[nazar-pc]

#13343 looks like the opposite problem from what I have. I'm confused now. Or is it about secret reading specifically?