`cargo info` requires login

[ehuss]

Problem

Running cargo info foo seems to require a login to crates.io. I would not expect a simple information command to require authentication (or for those with a hardware token, a hardware key) to access it.

Steps

1. Set up config.toml with:

[registry]
global-credential-providers = ["false"]

2. Run cargo info syn
3. See that it fails:

    Updating crates.io index
error: credential provider `false` failed action `get`

Caused by:
  failed to deserialize hello

Caused by:
  EOF while parsing a value at line 1 column 0

Possible Solution(s)

I'm guessing this is because of the call to try_list_owners. I do not think cargo info should be trying to access API endpoints that require authentication.

Notes

No response

Version

commit-hash: ff6df29857a5fc5f6bb0b9da8436cb501ee5894c

[0xPoe]

@rustbot claim

I will take a look.

[0xPoe]

I can reproduce it.

[0xPoe]

I do not think cargo info should be trying to access API endpoints that require authentication.

From the current design, if we can access the owner list, then we will display it; otherwise, it will skip the missing token error.

I think the bug from here:

cargo/src/cargo/ops/registry/info/mod.rs

Line 238 in c76c8fd

(AuthorizationErrorReason::TokenMissing)

We only checked the missing token error, maybe we should ignore all errors here.

The reason we introduced this information is that sometimes knowing who maintained the crate should be helpful.

[ehuss]

We only checked the missing token error, maybe we should ignore all errors here.

It's not an issue of checking for errors. Credentials can pop up requests for passwords, biometrics, or hardware keys. I do not think it would be good if cargo info pops up a password request every time you try to use it.

AFAIK, the owners list API endpoint does not require authentication on crates.io. Does the call to registry() require the Operation::Read entitlement?

[0xPoe]

It's not an issue of checking for errors. Credentials can pop up requests for passwords, biometrics, or hardware keys. I do not think it would be good if cargo info pops up a password request every time you try to use it.

I see. I didn't consider that. You are right. It doesn't make sense at all.

AFAIK, the owners list API endpoint does not require authentication on crates.io. Does the call to registry() require the Operation::Read entitlement?

Good point. The owners list API from crates.io does not require any authentication.

Yes, we passed the 'Operation::Read' entitlement. However, I found that even if we do not pass it, the 'crates-io' crate will still require us to pass a token.

I believe that whenever we send a request, we simply pass Auth::Authorized to the req function.

cargo/crates/crates-io/lib.rs

Line 388 in 2d17280

fn req(&mut self, path: &str, body: Option<&[u8]>, authorized: Auth) -> Result<String> {

I will dig a little deeper to see why we are forcing it.

[0xPoe]

Since this commit 0c25226, authentication is required for this API.

[0xPoe]

I guess we shouldn't "fix" this problem because our registry specification states that this API requires authentication.

So there are two ways to fix it:

1. Add a special case for crates.io.
2. Remove this feature at all.

@ehuss @epage What do you think?

[epage]

Let's just remove it for now and we can always re-evaluate it later.

[0xPoe]

Let's just remove it for now and we can always re-evaluate it later.

I agree, I will go head to remove it tomorrow.