gix fails to read credential store in ~/.git-credentials #1103
Comments
|
Thanks for reporting! I'd definitely appreciate if you could try if it truly works with a public overleaf instance, and if it's related to Windows as you think it might be. In general, Please also run It will be interesting to see if the involvement of a proxy matters here, but I think not. What could also be an issue is the usage of per-URL credential helper configuration, even though this simple case should work. With your help, I am sure we will figure this out though - thanks in advance. |
|
On my laptop |
|
Thanks! Can you help me to see how this relates to the issue here? Accessing a public GitHub repository won't trigger authentication, and even if it would it's probably different from an overleaf instance with a token (and comparably complex configuration). |
|
Ohh I was just trying to help to see if I can provide any information regarding the helper. I ran I'm using the MacOS keychain, so it also uses MacOS specific helper program. |
I did run I forgot how to ask git to provide the trace, I will do that soon (by Monday) |
This should make it easier to understand what's going on in case something isn't working as expected.
|
Thanks, I saw, and realised that indeed it won't print git credential invocations anyway. This has been addressed in bc44497 though so you probably want to re-run with a locally compiled version of the latest In any case, it will be most helpful if this can be made reproducible on something that's publicly accessible. Also it will be interesting to see if this issue is platform dependent for some reason. |
|
On Linux using
It also works properly when you use the credentials store ( $ gix --trace fetch
11:13:59 tracing INFO run [ 393ms | 99.42% / 100.00% ]
11:13:59 tracing INFO ┝━ ThreadSafeRepository::discover() [ 1.92ms | 0.04% / 0.49% ]
11:13:59 tracing INFO │ ┕━ open_from_paths() [ 1.78ms | 0.08% / 0.45% ]
11:13:59 tracing INFO │ ┝━ gix_path::git::install_config_path() [ 1.41ms | 0.36% ]
11:13:59 tracing INFO │ ┕━ gix_odb::Store::at() [ 53.5µs | 0.01% ]
11:13:59 tracing INFO ┕━ fetch::Prepare::receive() [ 354µs | 0.01% / 0.09% ]
11:13:59 tracing INFO ┕━ negotiate [ 324µs | 0.01% / 0.08% ]
11:13:59 tracing DEBUG ┝━ mark_complete_and_common_ref [ 132µs | 0.03% ] mappings: 1
11:13:59 tracing DEBUG ┕━ update_refs() [ 150µs | 0.01% / 0.04% ] mappings: 1
11:13:59 tracing DEBUG ┕━ apply [ 108µs | 0.03% ] edits: 1
+refs/heads/*:refs/remotes/origin/*
c06d7715706f3dc6a3cef8237a62f57246772ebd refs/heads/master -> refs/remotes/origin/master [up-to-date]
server sent 2 tips, 1 were filtered due to 1 refspec(s).
no negotiation was necessaryMy guess is either the proxy or the windows stuff is messing this up, next try will be windows without the proxy. It could also be from the mismatched versions.
Next Steps
feel free to add more steps It feels like I'm becoming an expert at hitting all the authentication edgecases c: |
Wow you are fast c: I have some chores to do so I'll start testing in an hour or two. As always, happy to work with you! |
I am sure you have your reason, but I'd recommend building your own from the latest
It's strange to say, but I do appreciate it 😅. It's a major plus for |
No issues, it is either windows or the proxy.
I don't know how good my |
|
Successful fetch with gix gix --trace fetch$ gix --trace fetch
14:10:15 tracing TRACE 📍 [trace]: checkout waiting for idle connection: ("https", sharelatex.tum.de)
14:10:15 tracing TRACE 📍 [trace]: Http::connect; scheme=Some("https"), host=Some("sharelatex.tum.de"), port=None
14:10:15 tracing DEBUG 🐛 [debug]: resolving host="sharelatex.tum.de"
14:10:15 tracing DEBUG 🐛 [debug]: connecting to 131.159.108.1:443
14:10:15 tracing DEBUG 🐛 [debug]: connected to 131.159.108.1:443
14:10:15 tracing TRACE 📍 [trace]: client handshake Http1
14:10:15 tracing TRACE 📍 [trace]: handshake complete, spawning background dispatcher task
14:10:15 tracing TRACE 📍 [trace]: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Busy }
14:10:15 tracing TRACE 📍 [trace]: checkout dropped for ("https", sharelatex.tum.de)
14:10:15 tracing TRACE encode_headers [ 6.99µs | 100.00% ]
14:10:15 tracing TRACE ┕━ 📍 [trace]: Client::encode method=GET, body=None
14:10:15 tracing DEBUG 🐛 [debug]: flushed 204 bytes
14:10:15 tracing TRACE 📍 [trace]: flushed({role=client}): State { reading: Init, writing: KeepAlive, keep_alive: Busy }
14:10:15 tracing TRACE 📍 [trace]: Conn::read_head
14:10:15 tracing TRACE 📍 [trace]: received 332 bytes
14:10:15 tracing TRACE parse_headers [ 8.15µs | 100.00% ]
14:10:15 tracing TRACE ┝━ 📍 [trace]: Response.parse | bytes: 332
14:10:15 tracing TRACE ┕━ 📍 [trace]: Response.parse Complete(171)
14:10:15 tracing DEBUG 🐛 [debug]: parsed 5 headers
14:10:15 tracing DEBUG 🐛 [debug]: incoming body is content-length (161 bytes)
14:10:15 tracing TRACE 📍 [trace]: decode; state=Length(161)
14:10:15 tracing DEBUG 🐛 [debug]: incoming body completed
14:10:15 tracing TRACE 📍 [trace]: maybe_notify; read_from_io blocked
14:10:15 tracing TRACE 📍 [trace]: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
14:10:15 tracing TRACE 📍 [trace]: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
14:10:15 tracing TRACE 📍 [trace]: put; add idle connection for ("https", sharelatex.tum.de)
14:10:15 tracing DEBUG 🐛 [debug]: pooling idle connection for ("https", sharelatex.tum.de)
14:10:15 tracing TRACE 📍 [trace]: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
14:10:15 tracing TRACE 📍 [trace]: idle interval checking for expired
14:10:15 tracing TRACE 📍 [trace]: take? ("https", sharelatex.tum.de): expiration = Some(90s)
14:10:15 tracing DEBUG 🐛 [debug]: reuse idle connection for ("https", sharelatex.tum.de)
14:10:15 tracing TRACE encode_headers [ 2.48µs | 100.00% ]
14:10:15 tracing TRACE ┕━ 📍 [trace]: Client::encode method=GET, body=None
14:10:15 tracing DEBUG 🐛 [debug]: flushed 256 bytes
14:10:15 tracing TRACE 📍 [trace]: flushed({role=client}): State { reading: Init, writing: KeepAlive, keep_alive: Busy }
14:10:15 tracing TRACE 📍 [trace]: Conn::read_head
14:10:15 tracing TRACE 📍 [trace]: received 727 bytes
14:10:15 tracing TRACE parse_headers [ 7.10µs | 100.00% ]
14:10:15 tracing TRACE ┝━ 📍 [trace]: Response.parse | bytes: 727
14:10:15 tracing TRACE ┕━ 📍 [trace]: Response.parse Complete(413)
14:10:15 tracing DEBUG 🐛 [debug]: parsed 11 headers
14:10:15 tracing DEBUG 🐛 [debug]: incoming body is content-length (314 bytes)
14:10:15 tracing TRACE 📍 [trace]: decode; state=Length(314)
14:10:15 tracing DEBUG 🐛 [debug]: incoming body completed
14:10:15 tracing TRACE 📍 [trace]: maybe_notify; read_from_io blocked
14:10:15 tracing TRACE 📍 [trace]: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
14:10:15 tracing TRACE 📍 [trace]: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
14:10:15 tracing TRACE 📍 [trace]: put; add idle connection for ("https", sharelatex.tum.de)
14:10:15 tracing DEBUG 🐛 [debug]: pooling idle connection for ("https", sharelatex.tum.de)
14:10:15 tracing TRACE 📍 [trace]: flushed({role=client}): State { reading: Init, writing: Init, keep_alive: Idle }
14:10:15 tracing INFO run [ 276ms | 0.10% / 100.00% ]
14:10:15 tracing INFO ┝━ ThreadSafeRepository::discover() [ 1.99ms | 0.06% / 0.72% ]
14:10:15 tracing INFO │ ┕━ open_from_paths() [ 1.82ms | 0.13% / 0.66% ]
14:10:15 tracing INFO │ ┝━ gix_path::git::install_config_path() [ 1.40ms | 0.51% ]
14:10:15 tracing DEBUG │ │ ┕━ 🐛 [debug]: invoking git for installation config path | cmd: "git" "config" "-l" "--show-origin"
14:10:15 tracing INFO │ ┕━ gix_odb::Store::at() [ 65.3µs | 0.02% ]
14:10:15 tracing INFO ┝━ remote::Connection::ref_map() [ 274ms | 0.01% / 99.04% ]
14:10:15 tracing INFO │ ┕━ remote::Connection::fetch_refs() [ 274ms | 0.01% / 99.03% ]
14:10:15 tracing DEBUG │ ┕━ gix_protocol::handshake() [ 274ms | 99.02% ] service: UploadPack | extra_parameters: []
14:10:15 tracing DEBUG │ ┝━ 🐛 [debug]: launching credential helper | cmd: "/bin/sh" "-c" "git credential-store \"$@\"" "--" "get"
14:10:15 tracing DEBUG │ ┕━ 🐛 [debug]: launching credential helper | cmd: "/bin/sh" "-c" "git credential-store \"$@\"" "--" "store"
14:10:15 tracing INFO ┕━ fetch::Prepare::receive() [ 387µs | 0.01% / 0.14% ]
14:10:15 tracing DEBUG ┕━ negotiate [ 353µs | 0.02% / 0.13% ] protocol_version: 1
14:10:15 tracing DEBUG ┝━ mark_complete_and_common_ref [ 127µs | 0.05% ] mappings: 1
14:10:15 tracing DEBUG ┕━ update_refs() [ 179µs | 0.02% / 0.06% ] mappings: 1
14:10:15 tracing DEBUG ┕━ apply [ 138µs | 0.05% ] edits: 1
+refs/heads/*:refs/remotes/origin/*
c06d7715706f3dc6a3cef8237a62f57246772ebd refs/heads/master -> refs/remotes/origin/master [up-to-date]
server sent 2 tips, 1 were filtered due to 1 refspec(s).
no negotiation was necessarySuccessful GIT_TRACE=1 git fetch$ GIT_TRACE=1 git fetch
14:16:09.432203 git.c:463 trace: built-in: git fetch
14:16:09.432645 run-command.c:659 trace: run_command: git remote-https origin https://[email protected]/git/652e8a160217f4be93b0ac82
14:16:09.433734 git.c:749 trace: exec: git-remote-https origin https://[email protected]/git/652e8a160217f4be93b0ac82
14:16:09.433762 run-command.c:659 trace: run_command: git-remote-https origin https://[email protected]/git/652e8a160217f4be93b0ac82
14:16:09.652356 run-command.c:659 trace: run_command: 'git credential-store get'
14:16:09.655997 git.c:463 trace: built-in: git credential-store get
14:16:09.799312 run-command.c:659 trace: run_command: 'git credential-store store'
14:16:09.802910 git.c:463 trace: built-in: git credential-store store
14:16:09.803525 run-command.c:659 trace: run_command: git rev-list --objects --stdin --not --exclude-hidden=fetch --all --quiet --alternate-refs
14:16:09.808071 run-command.c:1523 run_processes_parallel: preparing to run up to 1 tasks
14:16:09.808091 run-command.c:1551 run_processes_parallel: done
14:16:09.808100 run-command.c:659 trace: run_command: git maintenance run --auto --no-quiet
14:16:09.809343 git.c:463 trace: built-in: git maintenance run --auto --no-quietThese are to compare against the Windows runs and hopefully see where it fails. |
|
Great to hear, and we also clearly see the credential helper invocations match up. Curious to see the other results - I will wait :). |
Windows (git works, gix fails)
|
|
Removing the I don't know how to invoke I am guessing that is the problem as Linux uses I will try removing the proxy later today, but it seems to be working properly? Scratch that, proxy uses a self-signed ssl cert so I need to turn ssl checking off bu gix does not support that? And trying to add the CA path to |
|
Windows with gix version v0.30.0 (from the releases page) also doesn't work (max-pure-msvc) |
|
Thanks for testing! Is it possible for you to run On my installation, I don't have it for example, but I also don't have It is my feeling that Can you try to find the I probably am on a pretty old version, maybe that's why it's called differently in my installation. In any case, once we figure out why
With |
|
That's great, but also doesn't explain why it fails with Thinking about it, it's a bit of a problem that But the question remains: Why can't it find `'the program'? What is the program anyway? The credential manager is configured like this: This means it's supposed to be run through a shell. Thus it launches Can it be that it's a command-prompt? Can you execute So maybe, ultimately, this a windows issue and the solution would be to avoid going through I will try implementing that. |
…mpts on Windows (#1103) On prompts, typically only `git.exe` is available, but no shell (i.e. `sh`), wo we have to prefer going through `git.exe` to launch credential helpers.
|
So, two problems here:
For 1 you could do the shell escaping for git-credential-manager that you need to do for "$@" inside Rust, and just ignore the For 2 you'd need to find the git install ( |
|
Is |
Yes and yes c: |
#1103) Note that for a moment, there was the idea about using `shell-words` split certain invocations ourselves to avoid having to use a shell. This is great on windows, where a shell might not be available. On linux though this also means that some shell-builtins might not be not be found if this is used, which limits the approach to windows, and even there it might reduce compatibility. Thus, let's not do it.
…-prompts on Windows (#1103) On prompts, typically only `git.exe` is available, but no shell (i.e. `sh`). Thus, we have to prefer going through `git.exe` to launch credential helpers and possibly split simple arguments ourselves.
|
Please do try the version from #1111 as I think it will fix the problem. DetailsNow such a shell simply won't be used for cases like these, which is the same that |
#1103) Note that for a moment, there was the idea about using `shell-words` split certain invocations ourselves to avoid having to use a shell. This is great on windows, where a shell might not be available. On linux though this also means that some shell-builtins might not be not be found if this is used, which limits the approach to windows, and even there it might reduce compatibility. Thus, let's not do it.
…-prompts on Windows (#1103) On prompts, typically only `git.exe` is available, but no shell (i.e. `sh`). Thus, we have to prefer going through `git.exe` to launch credential helpers and possibly split simple arguments ourselves.
|
Fixed by #1111 🎉 |
#1103) Note that for a moment, there was the idea about using `shell-words` split certain invocations ourselves to avoid having to use a shell. This is great on windows, where a shell might not be available. On linux though this also means that some shell-builtins might not be not be found if this is used, which limits the approach to windows, and even there it might reduce compatibility. Thus, let's not do it.
…-prompts on Windows (#1103) On prompts, typically only `git.exe` is available, but no shell (i.e. `sh`). Thus, we have to prefer going through `git.exe` to launch credential helpers and possibly split simple arguments ourselves.
…-prompts on Windows (#1103) On prompts, typically only `git.exe` is available, but no shell (i.e. `sh`). Thus, we have to prefer going through `git.exe` to launch credential helpers and possibly split simple arguments ourselves.
|
#1111 has been merged and the issue is thus fixed 🎉 |
Current behavior 😯
gix fetchfails on a repository using a Token for authentication. The token is stored in~/.git-credentials:~/.git-credentials
The config is not minimal
gix config
I am behind a corporate proxy using a windows computer. So I have to be kinda careful about what logs I post :c.
I am using
gitoxide-max-pure-v0.31.1-x86_64-pc-windows-msvcfrom the GitHub releases.gix --trace fetch
Expected behavior 🤔
gix fetchshould use the credentials in~/.git-credentialsand successfully establish the connection.Git behavior
git fetchjust works.Steps to reproduce 🕹
I will try to reproduce it in the public Overleaf instance instead of my University's but this are the steps:
git credentials store(in~/.git-credentials)gix(no updates to the repo required) (maybe you need to be behind an http proxy(?))As far as I can tell this only happens on windows(?), but I didn't use the git credentials store within linux. I will try that ASAP, but I'm filing the issue while I'm still behind the proxy.
Performed tests (Results in the comments)
GIT_TRACE=1 git fetchmainv0.30.0GIT_TRACE=1 git fetchmainv0.31.1The text was updated successfully, but these errors were encountered: