Conan: Use same artifactory credential to download sources in conan recipes

[derived-coder]

Conan stores the credentials of artifactory in order to download recipes.
My use case is, that I have source code in artifactory that the conan recipes is downloading via tools.get
The artifactory needs also credentials for downloading the stuff. It would be nice, if conan can reuse these credentials in order to get these artifacts.

[uilianries]

Hi @derived-coder !

I'm curious, how are you dealing with this?

[memsharded]

Yes, this seems to be a valid use case.

It might be a difficult feature to implement, because what conan stores is not the credentials, but stores the user and a JWT token that works with the Conan API. I have no idea if this token could also work for other repository types, so this deserves some investigation first.

[uilianries]

I think it can be implemented by Conan client ...

The tools.get has the parameter auth which can receive CONAN_LOGIN_USERNAME and CONAN_PASSWORD. However, we could pass the conan user instance to re-use both username and password IF the remote address matches, e.g. using the same Artifactory instance for source downloading and package uploading.

We could add a new parameter:

tools.get(url, sha256, ..., remote_credentials="bincrafters")

I'm saying, to download this source, if an authentication is required, then use the same that for the remote "bincrafters", which was computed by conan user command early.

The current option is not far from this approach, but requires a few steps more:

username = os.getenv("CONAN_LOGIN_USERNAME", "user")
password = os.getenv("CONAN_PASSWORD", None)
tools.get(url, sha256, auth=(username, password))

[memsharded]

The problem I see with this approach is that there is no guarantee that the access tokens of the Artifactory Conan repo would be valid for another repo, specially if the other repo is another type, like a generic repo. Yes, in many cases the permissions might be good, but security policies in companies might differ. What the solution would look like for this case?

[uilianries]

The problem I see with this approach is that there is no guarantee that the access tokens of the Artifactory Conan repo would be valid for another repo, specially if the other repo is another type, like a generic repo.

I see. As generic repo can't be added as Conan remote, it won't work for this approach.

in many cases the permissions might be good, but security policies in companies might differ

Do you mean sniffing passwords? Even auth is not safe, which is the regular approach.

What the solution would look like for this case?

New repo category? Add support for generic repo, for Artifactory and Bintray only, by a new argument:

conan remote add sources --generic http://192.168.0.24/api/generic/company/sources
conan user -r sources -p password user

[memsharded]

New repo category? Add support for generic repo, for Artifactory and Bintray only, by a new argument

That is an interesting idea worth exploring.

[derived-coder]

Any update here? It is quite important

[memsharded]

No, this is not going to be fast. We know about the use case, but a correct solution will require a bunch of big changes, like defining new infrastructure, a new table in the credentials DB? How to pass and inject that into the tools without breaking? Implementing this correctly will take some time, and right now the team is over capacity, so this cannot be prioritize.

At the moment there is the above workaround:

username = os.getenv("CONAN_LOGIN_USERNAME", "user")
password = os.getenv("CONAN_PASSWORD", None)
tools.get(url, sha256, auth=(username, password))

This works fine, and it is not that much different than neededing to specify on the command line:

conan remote add sources --generic http://192.168.0.24/api/generic/company/sources
conan user -r sources -p password user

Please note that what it is NOT possible is to use the current credentials for a Conan Artifactory remote for other type of repos (like generic repos), because these credentials are not the same in the general case, and this will easily break and block users that don't share the credentials. So in any case, it will be necessary to provide credentials for those other repos. Providing them as env-vars is still a best practice even for conan repos, because we don't want a text password in the scripts for conan user command. So it will be not much different than just providing env-vars for all cases.

If you want to have a nice message for developers (not CI) you can always do:

try:
     username = os.environ["MY_SOURCES_USER"]
except KeyError:
     raise ConanException("MY_SOURCES_USER env-var not defined. You need to define it to access sources")
...
tools.get(url, sha256, auth=(username, password))

We will work on this when it is possible, sorry that at this moment it needs to wait a bit.

[derived-coder]

The problem is, in some shells (e.g. oh my zshell) everything is stored what you input, i.e. the password is stored when I do an export.... It would help when I input the password and store it somewhere.

[derived-coder]

Any update here?
Can you not implement at least the same credentials support you have when uploading the package to artifactory? So that the credentials are need to input from the user and stored somewhere on disk and then reused?