Git resolver looses custom registry url

[rlejeune74]

Problem

When depending on custom registries over Git, the URL to the registry is lost, forcing the user to redefine it in its own .cargo/config.toml.
This put the responsibility on the consumer to know about the custom registries of its Git dependencies.
This also allow some "man on the middle" trick by providing another second level dependency by defining same registry name with different URL in the consumer .cargo/config.toml.

Steps

1. crate-a containing:

$ cat Cargo.toml
[package]
name = "crate-a"
version = "0.1.0"
edition = "2021"

[dependencies]
some-crate = { version = "0.1", registry = "some-registry" }

$ cat .cargo/config.toml
[registries]
some-registry = { index = "ssh://registry.x.com/path/to/some-registry" }

2. crate-b containing:

$ cat Cargo.toml
[package]
name = "crate-b"
version = "0.1.0"
edition = "2021"

[dependencies]
crate-a = { version = "0.1", git = "https://git.x.com/path/to/crate-a" }

$ cat .cargo/config.toml
cat: .cargo/config.toml: No such file or directory

3. Compiling crate-b gives the cryptic error:

error: no matching package named `crate-a` found
location searched: https://git.x.com/path/to/crate-a

Possible Solution(s)

One possible solution will be to resolve dependency url using the .cargo/config.toml at the level the dependency is defined.

Notes

If crate-b -> crate-a -> some-crate only involves Git resolver or custom registry there is no issue.
Only happens when Git and Custom registry are mixed.

Version

cargo 1.86.0 (adf9b6ad1 2025-02-28)
release: 1.86.0
commit-hash: adf9b6ad14cfa10ff680d5806741a144f7163698
commit-date: 2025-02-28
host: x86_64-unknown-linux-gnu
libgit2: 1.9.0 (sys:0.20.0 vendored)
libcurl: 8.12.0-DEV (sys:0.4.79+curl-8.12.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Debian 12.0.0 (bookworm) [64-bit]

[epage]

I can understand that it can be frustrating to have to propagate out the definition of custom registries to all relevant repo. However, config files are loaded based on your current environment (with an exception for cargo install and cargo scripts which only load the users environment).

See also

• Cargo does not always search for .cargo/config file in project root #2930
• cargo install [--git?] ignores .cargo/config.toml, making packages publishable-but-unbuildable, allthewhile they work when built normally #14001

This also allow some "man on the middle" trick by providing another second level dependency by defining same registry name with different URL in the consumer .cargo/config.toml.

I'm not quite seeing this as a man-in-the-middle as the config has to be on your local system which puts it in your control. Relying on configs in remote repos which you have no control over and not easy visibility for auditing seems like it would make this problem worse.

[xetqL]

I don't think it is sound fetch the registry by "name" rather than URL. A name is by definition local and should only concern my local crate, it should not be the burden of the consumer of my library to know whatever registry name me or my downstream dependencies are using.

Imagine if we have 20 dependencies each of them defining their own registry name, as a top-level binary I would have to put each of them in my config.toml despite they all have the same URL (= poiting to the same registry in reality). This does not sound optimal at all.

[epage]

In that case, the most likely path forward would be to evaluate having the URL in Cargo.toml (which aligns with #12738). On #12738, we note the use case. Linked from that is an issue that mentions a registry-index field. Note that that is only an implementation detail of cargo package and is not documented for package authors for use. We should probably close that hole so people don't rely on it unintentionally.

[xetqL]

Also, do you know why it only happens when using a git dependency ? If a dependency is directly fetched from a registry there is no issue and it is not needed to have all the registries named correctly in config.toml.

I am not familiar at all with the cargo code base, but is there a world where cargo could always fetch by URL? Just keeping the name for convenience intra-crate?

[epage]

Cargo has an internal-only field it sets when generating a .crate file to resolve the registry name to a URL (#14500).

[xetqL]

@epage do you think that this could be tackled by a newcomer in the codebase? I would be happy to do it provided the right guidance.

[epage]

The first step is finding out why things work this way, in particular, what is split with the name in manifests and url in config. I wasn't around for that decision so someone will need to dig into the issues, prs, or maybe source history to uncover that.