Tracking Issue for credential-process RFC 2730

[ehuss]

Summary

RFC: rust-lang/rfcs#2730
Implementation: #8934
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#credential-process
Issues: A-credential-provider Area: credential provider for storing and retreiving credentials

This feature provides a configuration option to specify a process to fetch a token to authenticate with a registry.

Unresolved issues

• Is this approach useful enough? Things like macos keychain don't protect against being executed to extract tokens (and I don't see a way to require a password, or force the process to be untrusted). The lack of signatures also cause issues (each update of the toolchain will cause it to become untrusted again).
  • Making the built-in providers like cargo:macos-keychain part of the cargo binary improves security here, since only the Cargo binary is accessing the Keychain. If we get Cargo signed by Apple, then it would be further improved.
• Should the login API be changed? Providers that need to be interactive need to be able to read from stdin.
  • This is worked around by having the credential-provider re-open stdin from /dev/tty or $CONIN
• Should the storage key off the registry name? RFC 3139 discusses problems with this. RESOLVED: credential helpers are now keying off the index url via Implement RFC 3139: alternative registry authentication support #10592.
• Should it be possible to pass additional arguments on the command line for cargo login that would be sent to the provider? E.g. cargo login -- --extra-arg-for-provider
  • Implemented in login: allow passing additional args to provider #12499
• Figure out the name for cargo:basic: cargo:token-from-stdout
• Remove cargo-1password as a built-in (add the fn main so it can be published separately).
• Create a new -Z flag for cargo:paseto.
  • Publish cargo-credential-1password to crates.io
• Figure out MSRV support. fix: Set MSRV for internal packages #12381 is proposing to set MSRV for all packages in the repo. I think it will be important that the credential provider libraries have a relatively relaxed requirement (like stable-2 or something). I think this will be important to figure out before stabilization. This may be complicated with CI costs, so I'm wondering if cargo-credential could grow a few independent tests on its own so we could test just the library with an older rust? Add MSRV validation GitHub Action for cargo-credential #12623
• Testing of forwards-compatibility support. It is important that when a user installs a new credential provider that it does not necessarily cause older cargos to fail. There is a version field when we need to do breaking changes, but we need tests that are actually verifying that is working. cargo-credential: change serialization of cache expiration #12622
  • A test with some manually generated JSON with an invalid version file fed into a credential provider should provide the correct error message.
  • A test with some manually generated JSON with the current V1 format that is fed into a credential provider, and validate that it behaves correctly. This will make sure that if any changes to the credential provider are made that are not compatible with the old format that the test will fail.
• Resolve Cargo suggests _TOKEN environment variable even when it would not be applicable #12642
• Stabilization PR - feat: stabilize credential-process and registry-auth #12649
• Publish cargo-credential v0.4 to crates.io
• Publish cargo-credential-1password v0.4 to crates.io

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[jethrogb]

Also see the discussion in https://internals.rust-lang.org/t/securing-cargo-publishing-credentials/14050

[Eh2406]

There's still a lot of unanswered questions in this tracking issue. But to make it clear basic functionality from the RFC is implemented and available for testing. The questions are all about comparatively small details.

[ehuss]

I have posted a proposal to stabilize just the cargo logout portion at #11910.