Enable authentication against a disabled remote

[AbrilRBS]

Changelog: Fix: Enable authentication against disabled remotes.
Docs: Omit

There's no need to force a remote to be enabled for it to be able to be authenticated against, as disabling a remote should only affect if they are used for dependency resolving
Part 1 of 2 for #12909

[prince-chrismc]

Test code please :) 🙏

[AbrilRBS]

Yes! Sorry @prince-chrismc I didn't leave a message in the PR. Got into a rabbit-hole while writing tests for this PR which turned into #12915 and it delayed them a bit, but I've got them now, thanks for noticing :)

[prince-chrismc]

Usage makes sense 👍

[memsharded]

Just a quick note, this doesn't fully close #12909 (but it will be automatically closed when this is merged, because of the comment above). The missing bit is the conan remote list displaying all remotes.

[franramirez688]

It looks good! For me, it's only missing a new test to check that we're really listing both remotes now. Good job! 👍

[SSE4]

that looks suspicious. if remote is disabled, then no traffic should be sent to/from it. why does conan need to authenticate against explicitly disabled remote in the first place? seems to be a security issue IMO.

[memsharded]

that looks suspicious. if remote is disabled, then no traffic should be sent to/from it. why does conan need to authenticate against explicitly disabled remote in the first place? seems to be a security issue IMO.

This works only for the explicit conan remote login command. If the user is actively issuing a command, why would be a security issue? Why requesting the user to conan remote enable + conan remote login + conan remote disable? It looks good.

[SSE4]

This works only for the explicit conan remote login command. If the user is actively issuing a command, why would be a security issue? Why requesting the user to conan remote enable + conan remote login + conan remote disable? It looks good.

that might be exploited via similarly looking remote names, like similar characters or just minor typos in words.
e.g. good luck distinguishing conan from сonan or conаn. and in this case, you can easily send your credentials to the wrong remote, so they will be stolen or leaked. very easy to exploit via simple social engineering by sending a bit differently looking commands.
if user decided to disable remote, it should remain to be disabled IMO, it was disabled for reason, and it should be respected.

[memsharded]

that might be exploited via similarly looking remote names, like similar characters or just minor typos in words.
e.g. good look distinguishing conan from сonan or conаn. and in this case, you can easily send your credentials to the wrong remote, so they will be stolen or leaked. very easy to exploit via simple social engineering by sending a bit differently looking commands.

All of that can already happen with enabled remotes, if you add some remote to your existing remotes and that remote is malicious, then good luck, I don't think not allowing the authenticate for the reason it is disabled will save you from anything. conan remote disable cannot be a security measurement, it was always decided to avoid fetching packages from it, not as a security thing, as it doesn't make sense from the security point of view.