Add auth feature to manage download crates

[Stargateur]

I wanted to try out a private registry in the company where I work to allow better way than submodules and https clone for internal dependencies. But it seems that there is no way to limit crates download thus the crates are totally public.

I found out there is talk about this feature since a year and a RFC have been accepted about it rust-lang/cargo#10474.

So this issue is about tracking the implementation of this feature in ktra.

[jbeaurivage]

@Stargateur, check out #30. It might be close to what you're looking for.

[gagbo]

To be more precise: the openid feature doesn't prevent from downloading crates, nothing can prevent it as far as I know. It only allows to a specific list of users to publish packages on the registry. The difference might matter for your use case.

A cargo registry has basically 2 locations where you might control read access:

• The URL of the backing repository that you put in your .cargo/config.toml. Basically what we do at my company is that we set the http url to the ktra-managed repo, and let git manage authentication (with the use git with cli flag or something) to that repo. That means you can control access to the registry with your org's git control.
• The URL listed in the config file within the repo you pointed in your cargo config. This is trickier to use, we used to use this URL (pointing to .crate files that are build artifacts behind GitLab API), but to support this flow, we had to patch Cargo to add support for adding arbitrary HTTP headers to the requests made to the dl endpoint. This was a chore to maintain, and not using this patched Cargo means that we need to make the crates fully public if you happen to know the URL, which was not acceptable for us.

The openid thing only controls push/ownership access, which is currently useful for us to have our own technical CI user to push crates, and to make it easier for anyone in the company to publish and use private package when hacking on some PoCs

[Stargateur]

Thx for the detailed inside, I see the link I guess limit the user creation / limit on who can upload crates would be nice too, thus it would be funny to see who would use a "public" registry with a private git repository index ^^. But that indeed not what I need for now, you confirm that until the implementation of the RFC is done and release there no simple way to do what I need.

Can't wait.

[fMeow]

I have create a PR #50 to require authorization for public APIs. I will start testing after the RFC #3139 implementation merge into cargo.