Very bad diagnostics when git fetching using SSH #5035
Comments
|
Just to confirm, you think Cargo was using the SSH url, right? Locally at least using So I'm not actually sure if there's anything we can do with the |
|
Yea, I have this in my And the error message indicated that ssh-agent authentication failed (which is incorrect, but wouldn't make sense if it were over HTTPS). |
alexcrichton
added
A-git
|
I took a little look at this. It seems like part of the problem is that "Internal" errors are not displayed by default unless you pass The code here maps most git errors to an Internal error. Looking through the past, it looks like Cargo has a long history of differentiating "human" vs internal errors, and these git errors have always been hidden this way. I'm not sure what the correct course would be since I'm unfamiliar with why they are differentiated this way. |
|
Oh wow, thanks for looking into this @ehuss! I've often though that our internal/human distinction for errors has not worked out well for us so this seems like clearly a case where basically any and all network errors should not be listed as internal! Want to send a patch for this? |
Yea, I'll give it a shot. I might be busy this week so it may be delayed. |
Display git errors during authentication. Certain git errors during authentication were being converted to internal errors which meant that they are only seen if you pass `--verbose`. This may not be obvious, and many of these messages are helpful for diagnosing git errors. This change makes these errors always be displayed. Fixes #5035. Note: Some of the git errors are currently unhelpful. Once Cargo has updated git2-rs to include alexcrichton/git2-rs#298, these errors will improve. (@alexcrichton, I can make a PR to update Cargo for the changes in git2 if you'd like). I'm uncertain if this is a good solution, since the error messages in some cases are a little verbose (such as showing `class=...`). Here is a sample of what some of the messages look like: <details><summary>Error Message Examples</summary> <p> Example of the git message shown below the "attempted yadda yadda" message. Scenario | Message ---------|-------- No ssh-agent, multiple usernames | `error authenticating: ; class=Ssh (23)` | | †`error authenticating: no auth sock variable; class=Ssh (23)` No ssh-agent, one username | `an unknown git error occurred` | | †`error authenticating: no auth sock variable; class=Ssh (23)` Incorrect ssh-agent setup | `error authenticating: failed connecting with agent; class=Ssh (23)` ssh-agent no keys, one username | `an unknown git error occurred` | | †`failed to acquire username/password from local configuration` ssh-agent no keys, multiple usernames | `error authenticating: ; class=Ssh (23)` | | †`no authentication available` auth success, bad path | `fatal: '/path/to/repo/' does not appear to be a git repository; class=Ssh (23); code=Eof (-20)` | | ‡`ERROR: Repository not found.; class=Ssh (23); code=Eof (-20)` bad username | `an unknown git error occurred` | | †`failed to acquire username/password from local configuration` | | ‡`error authenticating: Username/PublicKey combination invalid; class=Ssh (23)` † - Messages once git2-rs is updated. ‡ - Github message </p> </details>
For reasons unrelated to cargo, I have
gitset to always use ssh URLs instead of https URLs. This has unfortunately meant a world of pain for me for a variety of reasons.I had gotten very used to seeing this error message, which indicated that somewhere in the ridiculous contraption that bound together ssh-agent, git, and my shell, something had gone wrong:
I was especially baffled this time, because
gitwas using SSH auth fine, and the error only appeared to be incargo.After about 20 minutes of confused debugging, I figured out the problem: I was attempting to fetch
withoutboats/anchor-experiment, but the repo is namedwithoutboats/anchor_experiment.It would be nice if we could present a better error message that would distinguish between not having access rights to a repository (possibly because it doesn't exist) from not being able to authenticate at all.
The text was updated successfully, but these errors were encountered: