LibGit2 user/password authentication with ENV variables#20769
LibGit2 user/password authentication with ENV variables#20769
Conversation
|
Note that originally I was hoping to have #20725 get merged before the feature freeze (that work also solves this problem) but the introduction of a new test framework and refactoring work make it appear unlikely that the necessary work will be merged before the freeze. |
|
|
||
| if isset(allowed_types, Cuint(Consts.CREDTYPE_USERPASS_PLAINTEXT)) | ||
| defaultcreds = reset!(UserPasswordCredentials(true), -1) | ||
| defaultcreds = reset!(UserPasswordCredentials(true), 1) |
There was a problem hiding this comment.
Was set to -1 to trigger a prompt right away. Setting it to 1 allows the ENV variables (also cached creds) be attempted before a prompt occurs
| username, userpass = Base.get(res) | ||
| end | ||
| elseif isusedcreds | ||
| elseif isempty(username) || isempty(userpass) || isusedcreds |
There was a problem hiding this comment.
Make a prompt occur right away if the cached credentials are empty
That PR really should have been opened at the latest in December if you wanted to be sure of that, there's been a huge amount of advance notice. (not to be mean, I hate that this isn't working as much as you do and we'll need to fix it, but these things take time and rushing anything in last-second isn't ideal) Does gitlab support setting https remotes like (edited because I can never spell oauth correctly) |
|
I believe GitLab supports that URL syntax. Unfortunately Julia's Maybe I'm not understanding what you're suggesting? |
|
If you set the remote url in a way that has the token in it, why would it need to go through the credential callback at all? |
| username = creds.user | ||
| userpass = creds.pass | ||
| username = Base.get(ENV, "AUTH_USER", creds.user) | ||
| userpass = Base.get(ENV, "AUTH_PASS", creds.pass) |
There was a problem hiding this comment.
are these standard / common names? should the option here be documented? seems like there's potential for collision with other applications if these are always favored/tried by default
There was a problem hiding this comment.
I've found some examples of these being used in other applications. Mostly I was following the naming conventions set by authenticate_ssh which uses SSL_KEY_PATH, SSH_PUB_KEY_PATH and SSH_KEY_PASS. I'm fine with making these Julia specific: JULIA_AUTH_USER and JULIA_AUTH_PASS.
I agree it isn't ideal. It was overly optimistic of me to think I could get that PR in so close to the freeze. These changes only became necessary as of #17057 which is why I started on this work so late. |
Ah, I see what you're getting at. When running a GitLab CI job I'm given a CI_BUILD_TOKEN which is only valid for the duration of build/run. In order to use that with |
|
|
|
Too bad for |
|
Doing the in-place replacement does work: find $(julia -e 'println(Pkg.dir("METADATA"))') -maxdepth 2 -name url | xargs sed -i "s;https://gitlab-hostname/;https://gitlab-ci-token:$CI_BUILD_TOKEN@gitlab-hostname/;"It's definitely a suboptimal solution but it is a solution. This PR is no longer a requirement for me for Julia 0.6 and I'll close this PR in favor of eventually getting the features added in #20725. |
2 participants
I'm working with a custom METADATA.jl repo that includes packages which are hosted on a private server. I have a GitLab CI setup working but in order to have Julia's
Pkg.resolve()work with private packages I need some way of providing automated authentication. The GitLab CI setup provides a temporary token which can be used for HTTPS access to the private packages but currently Julia provides no way for me to use this token in an automated way.I hope that this PR can make it in before the 0.6 feature freeze as without this I may have to manually have to resolve package dependencies without it.