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

Get a Asymmetric Public key from credentials/config #11518

Open
Tracked by #10519
Eh2406 opened this issue Dec 29, 2022 · 0 comments
Open
Tracked by #10519

Get a Asymmetric Public key from credentials/config #11518

Eh2406 opened this issue Dec 29, 2022 · 0 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` S-triage Status: This issue is waiting on initial triage. Z-asymmetric-token Nightly: asymmetric-token authentication

Comments

@Eh2406
Copy link
Contributor

Eh2406 commented Dec 29, 2022

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.

  1. 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.
  2. 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.
  3. 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)

@Eh2406 Eh2406 added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` A-registry-authentication Area: registry authentication and authorization (authn authz) labels Dec 29, 2022
@ehuss ehuss added the Z-asymmetric-token Nightly: asymmetric-token authentication label Jan 3, 2023
@epage epage added the S-triage Status: This issue is waiting on initial triage. label Nov 20, 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` S-triage Status: This issue is waiting on initial triage. Z-asymmetric-token Nightly: asymmetric-token authentication
Projects
None yet
Development

No branches or pull requests

3 participants