Using Alexandrie as private

[MarcAntoine-Arnaud]

Hello,

Thanks for this initiative, very usefull project !!!
I wanna to deploy in my company but I have some issues to deploy as a private crate repository.

• does the UI can show nothing if the user is not authorized (no logged) to see crates ?
• for the API, if we use a private git, disable the UI, does peoples can see and access to my crates ? (Is it possible to configure a hack git repository to access to an Alexandrie endpoint ?)
• If not do you have an idea to serve Alexandrie for private companies is a safe mode ? Behind a VPN ? Something else ?

I maybe possible for us to contribute ☺️
Thank you a lot,
Marc-Antoine

[techninja1008]

@Hirevo I'm willing to contribute code to make this use case possible. Specifically, I'm thinking about two separate features each represented by a default-disabled configuration option:

• Disable registration
• Require user to be logged in to access all API endpoints. One thing I'm not sure of here is whether cargo sends a token with search and download requests, as these aren't listed as authenticated in the alternative registries spec.

[Hirevo]

Hello !

Sorry for my long absence about this.
I agree that this is a feature that is indeed desirable to have.
@techninja1008, Thanks for showing interest in helping with this.

In the current state of affairs, it is possible to have the index be private by passing an SSH link to it in Cargo's config.
This makes it impossible for Cargo to fetch the index without the required SSH keys being present on the machine when doing cargo build.
But it is true that the frontend and the API makes searching crates public.
To answer @techninja1008's question, Cargo doesn't send any credentials when doing cargo search and cargo download, which kinda forced these endpoints to be public as well in Alexandrie.

Within the implementation of cargo search from rust-lang/cargo:
https://github.com/rust-lang/cargo/blob/ccf781ab902d53ab80d76aa0e34f91df0d49e4b3/crates/crates-io/lib.rs#L338-L348

I think we can indeed at least do:

• disabling registrations
• require being logged in for all frontend endpoints and most of the API (except for Cargo-related search and download endpoints)

The rest of Cargo-related endpoints (like those related to owners and publication) are already authenticated.

That said, I don't know if the Cargo team is planning anything regarding this.

[Hirevo]

Also, we can maybe do it as an option within the config, rather than it being a cargo feature-flag, because it doesn't make us save on dependencies when not used, and having to recompile just to change an option could be annoying.

[lucypero]

How is this going?

If the registry cannot be made private, then why is it being advertised as such? If anyone can do cargo search and cargo download, then it isn't private, right?

@Hirevo

I don't understand how in the cargo's RFC, cargo search/download are not authenticated at all... What were they thinking?

I think for now i'll try to disable registrations, disable the frontend, and disable cargo search/download. Maybe I can still make it work.

[Hirevo]

Hi,

I've now created PR #164 to allow disallowing anonymous browsing in the frontend (by setting a login_required configuration option).

I am not exactly sure why this issue of the unauthenticated Cargo endpoint is still unaddressed, I am not aware of what is the Cargo team rationale on not sending the configured authorization token for all endpoints, and let the registries decide whether to ignore it (to make it public) or not (to make it private) when responding.
I don't know if it is some identified backwards compatibility issue that is preventing them from making that change or not.

Although, to be fair, they have accepted and implemented an RFC (rust-lang/rfcs#3139) to address this, but issues around how it interacts with how registries are uniquely identified (by the git repo URL of the crate index for git registries and by the base endpoint of the registry for sparse registries) prevents this from becoming stable right now.

When I used the word "private" in the README, it was more in the sense of "self-operated" than in the "confidential" (or "privacy") sense.
A bit similar to how a "private" company doesn't necessarily mean the company is "secret" but rather that it is "owned and managed by some individuals" rather than by some kind of public entity, if that makes sense.

But the fact that it is "self-operated" means it is also possible to hide it from the outside using techniques like private networks and SSH tunnels.

While disabling the endpoint used by cargo search could maybe be not too disrupting for most development workflows, disabling the endpoint used by cargo fetch would prevent cargo build and cargo check from working correctly, so I am afraid to not be able to give you a simple solution to this problem on my own right now.