cargo (original) (raw)

Problem

When using Asymmetric Tokens RFC 3231, cargo stores a secret key for use with the registry. In order to register that key the registry needs the public key. It would be nice for cargo to provide good ways to read the configurations it has. There are several related use cases.

The user is operating on commandline. After creating the key-pair they will need to interact with the website of the registry. The best interface here is probably to have the public key imbedded in instructions on how to use it.
The user is operating on the command line, but created the key-pair a long time ago. They only want to read the value that was previously set.
This is being run in some kind of automated process, in which the public key (and some other form of authorization) is provided to the registries API. Specifically, I would love if registries had integration with github OIDC. Github provides a token proving that the call comes from a workflow on a particular repository. It would be lovely to register a short-lived key-pair as being valid to work on behalf of a particular user while running on workflows for that repository. I don't think we want to hardcode integration with github, but we should add the building blocks to allow these workflows.

Proposed Solution

As currently implemented in #10771 cargo login prints the public key without any context or explanation. This is not ideal for any of these cases. It does not have enough context for 1, it is not intuitive to run after the fact for 2, and sometimes cargo login waits for the user which makes it not ideal for 3.

We should probably design a separate command for retrieving this information, and possibly even a command for registering the public key.

Notes

Noted in #10771 (comment)