Provide method of authentication for crate downloads

[nastevens]

With the stabilization of alternative registries in Rust 1.34, it's now possible to connect to an alternative registry to provide an index. Since the alternative registry is a git repo, authentication can be handled in all the normal ways like SSH keypairs, git credential helpers, etc.

However, there doesn't currently seem to be a way to authenticate the downloads of the .crate files themselves. Once a download location is pulled from the "dl" key in the config.json provided by the index, Cargo makes a request to a URL constructed from that key. But as far as I can tell there is no way to inject any authentication information into that request. This means I need to either keep all my private .crate artifacts on a local LAN or behind some other security like VPN.

I've thought of a few workaround, but all seem hacky or have security concerns:

• Based on authentication with the initial index provider, inject a long random string into the returned "dl" URL that is time-bound and unique per user. This isn't great because it requires modifying the returned index for every user.
• Use git+ssh for all crate downloads and rely on keypair auth This actually wouldn't work because the download step requires https, http, or file URLs.
• Require a second command that syncs private registry .crate files to the local filesystem and then have config.json specify a file:// URL. This isn't good because now syncing dependencies isn't an automatic action on cargo build, etc, it's a manual and forgettable step.

I think an ideal solution would extend the usage of a token obtained through cargo login to also be sent during crate download requests. This would need to be handled carefully so the token is only sent over secure connections and only to download URLs for the specific registry using the token.

[tustvold]

Is there any update on this? Including the token in the request is a relatively minor change and I can't envisage it breaking anything, crates.io just ignores extraneous authorization tokens.

[ehuss]

@tustvold There is an RFC proposal at rust-lang/rfcs#2719.

[ehuss]

#9494 includes some more ideas and discussion, see also https://internals.rust-lang.org/t/pre-rfc-cargo-alternative-registry-authentication/14794 and https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/registry.20authentication

[9999years]

New RFC: rust-lang/rfcs#3139

[ehuss]

The RFC is now accepted. Closing in favor of the tracking issue at #10474.