Summary of authentication discussion

Cargo currently only sends the user's token to an index when doing a mutation (publish, yank, owners, …) and does not send the token for read operations (getting an index file, getting a package artifact, search, …). This works for crates.io, but encourages truly awful hacks for private registries. The current hacks for private registries are awful and unacceptable and need to go away as soon as possible! RFC#3139 solves this by allowing a registry to request that tokens get sent for all endpoints.

Sending a plaintext token can be a component in a secure workflow, but is most easily implemented insecurely. Even crates.io had an incident where mishandling tokens required reissuing all tokens. Crates.io needs to move to something better. Token theft is an actively exploited problem in other package ecosystems. The reductio ad absurdum authentication mechanism is if the password is "admin" let them in. Unfortunately, this is not absurd. Systems with credentials hardcoded gets companies owned every day. RFC#3231 suggests a new authentication scheme that Cargo can support without adding significant user friction.

Many registry providers have existing authentication solutions that are well thought through and secure. None of which are RFC#3231. It should be possible for whatever we stabilize to work with these existing solutions. (How comfortably is one of the things up for debate.) Github is now pushing a well-designed system called GitHub OIDC. (Naming things is hard, the connection to the rest of OIDC is tangential.) It would be very nice if Cargo did not get in the way of the use of this system. The GitHub OIDC system uses a short-lived JWT signed by a well-known key that proves it's running in a specific GitHub Action. This could allow a GHA to publish a crate without storing any secrets at all in GHA.

Cargo (and Rust) generally have goals that we strive for that end up being in conflict about what to do next:

  • Cargo (and Rust) generally strive to make it easier to do things correctly then incorrectly. This usually involves some amount of syntactic salt for the "obvious but incorrect" solution.
  • Cargo (and Rust) generally strive to make it possible to do all reasonable things.

RFC#3139 is ready, and RFC#3231 is not.
What we could do next:

  1. Stabilize sending symmetric tokens to a registry. We can stabilize a supported asymmetric scheme when it's ready. It will probably not get much testing from the large registry providers, but now that crates.io has a full-time person we can start its experimentation there. Pro: fast and evry registry happy. Con: smaller registries will do insecure things.
  2. When RFC#3231 is ready, stabilize requiring its use to use RFC#3139. Pro: does not encourage insecure implementation. Con: large registry providers unhappy, not great support for GitHub OIDC.
  3. When RFC#3231 is ready, stabilize requiring it or GitHub OIDC-like things to use RFC#3139. Pro: does not encourage insecure implementation. Con: design more than one supported authentication scheme.
  4. Redesign RFC#3231 to be similar and compatible with GitHub OIDC. Con: a not small project, and it's not clear who has time to do the redesign.
Select a repo