Can't download Cargo packages from private owner #10676

New Issue

GiteaMirror · 2025-11-02T09:15:13-06:00

GiteaMirror commented

2025-11-02 09:15:13 -06:00

Originally created by @KN4CK3R on GitHub (Apr 18, 2023).

@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 https://github.com/go-gitea/gitea/issues/21888#issuecomment-1512487715

Originally created by @KN4CK3R on GitHub (Apr 18, 2023). @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 https://github.com/go-gitea/gitea/issues/21888#issuecomment-1512487715_

GiteaMirror added the topic/packages type/bug labels 2025-11-02 09:15:13 -06:00

GiteaMirror commented

2025-11-02 09:15:14 -06:00

@KN4CK3R commented on GitHub (Apr 23, 2023):

@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 , https://github.com/rust-lang/cargo/issues/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.

@KN4CK3R commented on GitHub (Apr 23, 2023): @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 , https://github.com/rust-lang/cargo/issues/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.

GiteaMirror commented

2025-11-02 09:15:14 -06:00

@lmaotrigine commented on GitHub (Dec 25, 2023):

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.

@lmaotrigine commented on GitHub (Dec 25, 2023): 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.

GiteaMirror commented

2025-11-02 09:15:14 -06:00

@KN4CK3R commented on GitHub (Dec 25, 2023):

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.

@KN4CK3R commented on GitHub (Dec 25, 2023): Initializing the index will recreate the `config.json`: ![grafik](https://github.com/go-gitea/gitea/assets/1666336/83c17652-7521-4295-ade7-bc66e1261f6a) 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.

GiteaMirror commented

2025-11-02 09:15:15 -06:00

@lmaotrigine commented on GitHub (Dec 25, 2023):

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.

@lmaotrigine commented on GitHub (Dec 25, 2023): > 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](https://github.com/go-gitea/gitea/pull/26729), 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.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10676