Can't download Cargo packages from private owner

[KN4CK3R]

@KN4CK3R The Cargo package registry packages seem not to be downloadable when the organization holding the package is private. The token field doesn't help here. Is this expected behavior?

Originally posted by @NOBLES5E in #21888 (comment)

[KN4CK3R]

@NOBLES5E This is a known limitation of Cargo. There is a RFC to support authenticated downloads: https://rust-lang.github.io/rfcs/3139-cargo-alternative-registry-auth.html , rust-lang/cargo#10474

If you install the current nightly, change to content of your _cargo-index.git/config.json to include ... ,"auth-required": true and use cargo -Z registry-auth install ... it works like expected. But I don't know if I should implement this RFC at the moment because there is an alternative listed which would easier to use:

Don't add a configuration option to config.json and rely only on the local configuration in the [registries] table. This avoids the auto-detection, but requires configuration from the user, which could be set up incorrectly or missed.

Adding "auth-required" to the config.json would require to regenerate this file every time the visibility of the owner changed.

[lmaotrigine]

The linked RFC has been implemented and stabilized and unfortunately does not include the alternative. Are there plans to regenerate config.json instead?

Working on any collaborative projects requires that everyone involved routinely patches config.json locally. This feels iffy, so as a stopgap I've patched gitea to always set auth-required to true, because it was the quickest fix I could think of without spending too much time source-diving. And it only works properly in my case because my instance enforces logging in to view anything at all.

Would be great if proper support for this is added.

I would also like to note that the only sane-ish alternative to the above hack is to always use the git index and just edit config.json in the _cargo-index repository.

This might be a solution for you if the index isn't updated very often so the "resolving deltas" phase of the git checkout wouldn't take too long.

But if you want to continue using the sparse protocol, then the response returned by /api/packages/<org-or-user>/cargo/config.json should be changed based on access restrictions.

[KN4CK3R]

Initializing the index will recreate the config.json:

The sparse index config endpoint is already dynamic. Don't know if it's a problem but if the owner is private that endpoint is login protected too.

[lmaotrigine]

The sparse index config endpoint is already dynamic.

Ah, my apologies for not noticing this earlier. It turns out that was only added in 1.21, and that PR wasn't referenced in any changelogs (in fact, no mention of such a bug fix was made at all)

Having to reinitialize manually after changing the visibility seems like a needless extra step given that the sparse index does it dynamically, but at least I'm now aware that an upgrade will solve my specific problem, because I have no use for the Git index protocol.

I don't want to speak for OP but I think that problem, too, is solved by this.

Don't know if it's a problem but if the owner is private that endpoint is login protected too.

It isn't. Cargo retries the request with authentication if the server returns 401.

The fact that I'm able to reproduce this on Forgejo Next is either user error or a downstream issue (which, I believe, you have been notified of).

I would think, therefore, that this issue may be closed, unless OP can somehow still reproduce it.