Auth failure in Win10/Cygwin environment, Cygwin bash shell #509
Labels
auth-issue
An issue authenticating to a host
Comments
|
Hello @bakoontz2,
From the trace logs you've included (thanks by the way!) I cannot see where the subsequent failure occurs. The logs show the following:
One thing of note that I see is that this is for github.com (not a GitHub Enterprise Server or GitHub AE) and you have a setting set to force the use of PATs, rather than allowing OAuth tokens: Is this intentional? |
|
Good catch! Let me see what's up with that, might be the problem. |
|
You'll probably want to look for the Git configuration entry |
|
OK, apparently that setting was copied over inadvertently from someone else's config. I've removed it, as the docs indicate the appropriate authentication mode should be detected (oauth in this case). And yes, this is not a github enterprise account, corrected my initial comment. I can see in the log below where the credential is found (line 17), but I'm still being presented with a username/password prompt (lines 28-31). |
Hmm.. strange. Can you please try again, and as well as Also a few questions/things to try and help diagnose the problem further:
Thanks! |
gcm-diagnose.log git.log |
Just to understand correctly: this user name prompt, is it in the terminal window, or is it a GUI window? |
|
Can you include a screenshot and the exact wording of the prompt please? Might help narrow down where it's coming from. Can I also ask what method you used to install GCM Core? Was it via extracting the |
|
I debugged a bit further and can confirm that this is a Cygwin-only issue. In fact, it looks as if a So I just had a hunch that this might be a regression in Cygwin v3.3.1, and it looks as if indeed, this still works as intended when I replace @bakoontz2 could you replace your |
|
@dscho @mjcheetham You all are geniuses. That fixed the problem. I feel badly I put you all through this to debug a Cygwin issue. I wish I had been able to catch this before taking up your time. Much appreciated! I will close this out and take this up with the cygwin folks. |
Oh, don't feel bad about this! I need to make sure that Cygwin's runtime works well anyway, as part of my work on Git for Windows (which uses a fork of that runtime to drive its Bash, Perl, SSH, etc).
Would you mind leaving a link here once you do? |
cygwin email list thread starts here: https://cygwin.com/pipermail/cygwin/2021-November/249777.html |
|
Of course!
|
|
Reporting back that in https://cygwin.com/pipermail/cygwin/2021-November/249790.html a workaround was found: |
|
And confirmed as working. Thanks for looking into this! |
|
Update from Cygwin list: https://cygwin.com/pipermail/cygwin/2021-November/249818.html Fix the issue that pipe reader falsely detects EOF if the output of |
|
It's already in Cygwin v3.3.2. |
|
Thanks I confirm |
dscho
added a commit
to dscho/msys2-runtime
that referenced
this issue
May 16, 2023
…rtup." When Git for Windows upgraded its MSYS2 runtime from v3.3.* to v3.4.* at long last, the t3701-add-interactive test of Git's test suite started to hang consistently, timing out. The culprit is a `git add -p` call that wants to read from a diff filter. This diff filter is `cat.exe`, i.e. nothing special, but that diff filter gets input that is larger than the pipe buffer, and therefore must not block. Yet that is exactly what it does. This was a regression that introduced by upgrading from MSYS2 runtime v3.3.*. After a tedious, multi-day bisection session, the commit introducing that regression was identified as 9078882 (Cygwin: pipe: Restore blocking mode for cygwin process at startup., 2021-11-17), which we hereby revert. So what bug does this reversion reintroduce? The commit seems to have been in response to https://inbox.sourceware.org/cygwin/CAEv6GOB8PXHgHoz7hdJy6Bia2GWEmUDnTd252gTGinz2vuv=hA@mail.gmail.com/ which reported a bug when a C# program writes 0-byte content to a Cygwin pipe. (Irony of ironies, this report originated from Git's realm, over at git-ecosystem/git-credential-manager#509.) The analysis revealed, back in December '21, that a `CYGWIN=pipe_byte` would work around the bug, too, but that did not fix the regression in Git's test suite. That leaves us with the somewhat unsatisfying conclusion that we _might_ reintroduce a regression when Git Credential Manager tries to talk to an _MSYS_ `git.exe`. But since we do not need that in Git for Windows, and since we need to have CI builds that do not time out after 6h causing failures, it is better to revert that commit, and in the hopefully unlikely event that this causes _other_ problems in Git for Windows' ecosystem, we will simply have to revisit this issue in more depth. This fixes git-for-windows/git#4422. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this issue
Jun 16, 2023
…rtup." When Git for Windows upgraded its MSYS2 runtime from v3.3.* to v3.4.* at long last, the t3701-add-interactive test of Git's test suite started to hang consistently, timing out. The culprit is a `git add -p` call that wants to read from a diff filter. This diff filter is `cat.exe`, i.e. nothing special, but that diff filter gets input that is larger than the pipe buffer, and therefore must not block. Yet that is exactly what it does. This was a regression that introduced by upgrading from MSYS2 runtime v3.3.*. After a tedious, multi-day bisection session, the commit introducing that regression was identified as 9078882 (Cygwin: pipe: Restore blocking mode for cygwin process at startup., 2021-11-17), which we hereby revert. So what bug does this reversion reintroduce? The commit seems to have been in response to https://inbox.sourceware.org/cygwin/CAEv6GOB8PXHgHoz7hdJy6Bia2GWEmUDnTd252gTGinz2vuv=hA@mail.gmail.com/ which reported a bug when a C# program writes 0-byte content to a Cygwin pipe. (Irony of ironies, this report originated from Git's realm, over at git-ecosystem/git-credential-manager#509.) The analysis revealed, back in December '21, that a `CYGWIN=pipe_byte` would work around the bug, too, but that did not fix the regression in Git's test suite. That leaves us with the somewhat unsatisfying conclusion that we _might_ reintroduce a regression when Git Credential Manager tries to talk to an _MSYS_ `git.exe`. But since we do not need that in Git for Windows, and since we need to have CI builds that do not time out after 6h causing failures, it is better to revert that commit, and in the hopefully unlikely event that this causes _other_ problems in Git for Windows' ecosystem, we will simply have to revisit this issue in more depth. This fixes git-for-windows/git#4422. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this issue
Jun 19, 2023
…rtup." When Git for Windows upgraded its MSYS2 runtime from v3.3.* to v3.4.* at long last, the t3701-add-interactive test of Git's test suite started to hang consistently, timing out. The culprit is a `git add -p` call that wants to read from a diff filter. This diff filter is `cat.exe`, i.e. nothing special, but that diff filter gets input that is larger than the pipe buffer, and therefore must not block. Yet that is exactly what it does. This was a regression that introduced by upgrading from MSYS2 runtime v3.3.*. After a tedious, multi-day bisection session, the commit introducing that regression was identified as 9078882 (Cygwin: pipe: Restore blocking mode for cygwin process at startup., 2021-11-17), which we hereby revert. So what bug does this reversion reintroduce? The commit seems to have been in response to https://inbox.sourceware.org/cygwin/CAEv6GOB8PXHgHoz7hdJy6Bia2GWEmUDnTd252gTGinz2vuv=hA@mail.gmail.com/ which reported a bug when a C# program writes 0-byte content to a Cygwin pipe. (Irony of ironies, this report originated from Git's realm, over at git-ecosystem/git-credential-manager#509.) The analysis revealed, back in December '21, that a `CYGWIN=pipe_byte` would work around the bug, too, but that did not fix the regression in Git's test suite. That leaves us with the somewhat unsatisfying conclusion that we _might_ reintroduce a regression when Git Credential Manager tries to talk to an _MSYS_ `git.exe`. But since we do not need that in Git for Windows, and since we need to have CI builds that do not time out after 6h causing failures, it is better to revert that commit, and in the hopefully unlikely event that this causes _other_ problems in Git for Windows' ecosystem, we will simply have to revisit this issue in more depth. This fixes git-for-windows/git#4422. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this issue
Sep 6, 2023
…rtup." When Git for Windows upgraded its MSYS2 runtime from v3.3.* to v3.4.* at long last, the t3701-add-interactive test of Git's test suite started to hang consistently, timing out. The culprit is a `git add -p` call that wants to read from a diff filter. This diff filter is `cat.exe`, i.e. nothing special, but that diff filter gets input that is larger than the pipe buffer, and therefore must not block. Yet that is exactly what it does. This was a regression that introduced by upgrading from MSYS2 runtime v3.3.*. After a tedious, multi-day bisection session, the commit introducing that regression was identified as 9078882 (Cygwin: pipe: Restore blocking mode for cygwin process at startup., 2021-11-17), which we hereby revert. So what bug does this reversion reintroduce? The commit seems to have been in response to https://inbox.sourceware.org/cygwin/CAEv6GOB8PXHgHoz7hdJy6Bia2GWEmUDnTd252gTGinz2vuv=hA@mail.gmail.com/ which reported a bug when a C# program writes 0-byte content to a Cygwin pipe. (Irony of ironies, this report originated from Git's realm, over at git-ecosystem/git-credential-manager#509.) The analysis revealed, back in December '21, that a `CYGWIN=pipe_byte` would work around the bug, too, but that did not fix the regression in Git's test suite. That leaves us with the somewhat unsatisfying conclusion that we _might_ reintroduce a regression when Git Credential Manager tries to talk to an _MSYS_ `git.exe`. But since we do not need that in Git for Windows, and since we need to have CI builds that do not time out after 6h causing failures, it is better to revert that commit, and in the hopefully unlikely event that this causes _other_ problems in Git for Windows' ecosystem, we will simply have to revisit this issue in more depth. This fixes git-for-windows/git#4422. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this issue
Nov 29, 2023
…rtup." When Git for Windows upgraded its MSYS2 runtime from v3.3.* to v3.4.* at long last, the t3701-add-interactive test of Git's test suite started to hang consistently, timing out. The culprit is a `git add -p` call that wants to read from a diff filter. This diff filter is `cat.exe`, i.e. nothing special, but that diff filter gets input that is larger than the pipe buffer, and therefore must not block. Yet that is exactly what it does. This was a regression that introduced by upgrading from MSYS2 runtime v3.3.*. After a tedious, multi-day bisection session, the commit introducing that regression was identified as 9078882 (Cygwin: pipe: Restore blocking mode for cygwin process at startup., 2021-11-17), which we hereby revert. So what bug does this reversion reintroduce? The commit seems to have been in response to https://inbox.sourceware.org/cygwin/CAEv6GOB8PXHgHoz7hdJy6Bia2GWEmUDnTd252gTGinz2vuv=hA@mail.gmail.com/ which reported a bug when a C# program writes 0-byte content to a Cygwin pipe. (Irony of ironies, this report originated from Git's realm, over at git-ecosystem/git-credential-manager#509.) The analysis revealed, back in December '21, that a `CYGWIN=pipe_byte` would work around the bug, too, but that did not fix the regression in Git's test suite. That leaves us with the somewhat unsatisfying conclusion that we _might_ reintroduce a regression when Git Credential Manager tries to talk to an _MSYS_ `git.exe`. But since we do not need that in Git for Windows, and since we need to have CI builds that do not time out after 6h causing failures, it is better to revert that commit, and in the hopefully unlikely event that this causes _other_ problems in Git for Windows' ecosystem, we will simply have to revisit this issue in more depth. This fixes git-for-windows/git#4422. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/Cygwin-msys2-fork
that referenced
this issue
Dec 2, 2023
…rtup." When Git for Windows upgraded its MSYS2 runtime from v3.3.* to v3.4.* at long last, the t3701-add-interactive test of Git's test suite started to hang consistently, timing out. The culprit is a `git add -p` call that wants to read from a diff filter. This diff filter is `cat.exe`, i.e. nothing special, but that diff filter gets input that is larger than the pipe buffer, and therefore must not block. Yet that is exactly what it does. This was a regression that introduced by upgrading from MSYS2 runtime v3.3.*. After a tedious, multi-day bisection session, the commit introducing that regression was identified as 9078882 (Cygwin: pipe: Restore blocking mode for cygwin process at startup., 2021-11-17), which we hereby revert. So what bug does this reversion reintroduce? The commit seems to have been in response to https://inbox.sourceware.org/cygwin/CAEv6GOB8PXHgHoz7hdJy6Bia2GWEmUDnTd252gTGinz2vuv=hA@mail.gmail.com/ which reported a bug when a C# program writes 0-byte content to a Cygwin pipe. (Irony of ironies, this report originated from Git's realm, over at git-ecosystem/git-credential-manager#509.) The analysis revealed, back in December '21, that a `CYGWIN=pipe_byte` would work around the bug, too, but that did not fix the regression in Git's test suite. That leaves us with the somewhat unsatisfying conclusion that we _might_ reintroduce a regression when Git Credential Manager tries to talk to an _MSYS_ `git.exe`. But since we do not need that in Git for Windows, and since we need to have CI builds that do not time out after 6h causing failures, it is better to revert that commit, and in the hopefully unlikely event that this causes _other_ problems in Git for Windows' ecosystem, we will simply have to revisit this issue in more depth. This fixes git-for-windows/git#4422. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this issue
Aug 30, 2024
…rtup." When Git for Windows upgraded its MSYS2 runtime from v3.3.* to v3.4.* at long last, the t3701-add-interactive test of Git's test suite started to hang consistently, timing out. The culprit is a `git add -p` call that wants to read from a diff filter. This diff filter is `cat.exe`, i.e. nothing special, but that diff filter gets input that is larger than the pipe buffer, and therefore must not block. Yet that is exactly what it does. This was a regression that introduced by upgrading from MSYS2 runtime v3.3.*. After a tedious, multi-day bisection session, the commit introducing that regression was identified as 9078882 (Cygwin: pipe: Restore blocking mode for cygwin process at startup., 2021-11-17), which we hereby revert. So what bug does this reversion reintroduce? The commit seems to have been in response to https://inbox.sourceware.org/cygwin/CAEv6GOB8PXHgHoz7hdJy6Bia2GWEmUDnTd252gTGinz2vuv=hA@mail.gmail.com/ which reported a bug when a C# program writes 0-byte content to a Cygwin pipe. (Irony of ironies, this report originated from Git's realm, over at git-ecosystem/git-credential-manager#509.) The analysis revealed, back in December '21, that a `CYGWIN=pipe_byte` would work around the bug, too, but that did not fix the regression in Git's test suite. That leaves us with the somewhat unsatisfying conclusion that we _might_ reintroduce a regression when Git Credential Manager tries to talk to an _MSYS_ `git.exe`. But since we do not need that in Git for Windows, and since we need to have CI builds that do not time out after 6h causing failures, it is better to revert that commit, and in the hopefully unlikely event that this causes _other_ problems in Git for Windows' ecosystem, we will simply have to revisit this issue in more depth. This fixes git-for-windows/git#4422. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this issue
Sep 5, 2024
…rtup." When Git for Windows upgraded its MSYS2 runtime from v3.3.* to v3.4.* at long last, the t3701-add-interactive test of Git's test suite started to hang consistently, timing out. The culprit is a `git add -p` call that wants to read from a diff filter. This diff filter is `cat.exe`, i.e. nothing special, but that diff filter gets input that is larger than the pipe buffer, and therefore must not block. Yet that is exactly what it does. This was a regression that introduced by upgrading from MSYS2 runtime v3.3.*. After a tedious, multi-day bisection session, the commit introducing that regression was identified as 9078882 (Cygwin: pipe: Restore blocking mode for cygwin process at startup., 2021-11-17), which we hereby revert. So what bug does this reversion reintroduce? The commit seems to have been in response to https://inbox.sourceware.org/cygwin/CAEv6GOB8PXHgHoz7hdJy6Bia2GWEmUDnTd252gTGinz2vuv=hA@mail.gmail.com/ which reported a bug when a C# program writes 0-byte content to a Cygwin pipe. (Irony of ironies, this report originated from Git's realm, over at git-ecosystem/git-credential-manager#509.) The analysis revealed, back in December '21, that a `CYGWIN=pipe_byte` would work around the bug, too, but that did not fix the regression in Git's test suite. That leaves us with the somewhat unsatisfying conclusion that we _might_ reintroduce a regression when Git Credential Manager tries to talk to an _MSYS_ `git.exe`. But since we do not need that in Git for Windows, and since we need to have CI builds that do not time out after 6h causing failures, it is better to revert that commit, and in the hopefully unlikely event that this causes _other_ problems in Git for Windows' ecosystem, we will simply have to revisit this issue in more depth. This fixes git-for-windows/git#4422. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this issue
Sep 18, 2024
…rtup." When Git for Windows upgraded its MSYS2 runtime from v3.3.* to v3.4.* at long last, the t3701-add-interactive test of Git's test suite started to hang consistently, timing out. The culprit is a `git add -p` call that wants to read from a diff filter. This diff filter is `cat.exe`, i.e. nothing special, but that diff filter gets input that is larger than the pipe buffer, and therefore must not block. Yet that is exactly what it does. This was a regression that introduced by upgrading from MSYS2 runtime v3.3.*. After a tedious, multi-day bisection session, the commit introducing that regression was identified as 9078882 (Cygwin: pipe: Restore blocking mode for cygwin process at startup., 2021-11-17), which we hereby revert. So what bug does this reversion reintroduce? The commit seems to have been in response to https://inbox.sourceware.org/cygwin/CAEv6GOB8PXHgHoz7hdJy6Bia2GWEmUDnTd252gTGinz2vuv=hA@mail.gmail.com/ which reported a bug when a C# program writes 0-byte content to a Cygwin pipe. (Irony of ironies, this report originated from Git's realm, over at git-ecosystem/git-credential-manager#509.) The analysis revealed, back in December '21, that a `CYGWIN=pipe_byte` would work around the bug, too, but that did not fix the regression in Git's test suite. That leaves us with the somewhat unsatisfying conclusion that we _might_ reintroduce a regression when Git Credential Manager tries to talk to an _MSYS_ `git.exe`. But since we do not need that in Git for Windows, and since we need to have CI builds that do not time out after 6h causing failures, it is better to revert that commit, and in the hopefully unlikely event that this causes _other_ problems in Git for Windows' ecosystem, we will simply have to revisit this issue in more depth. This fixes git-for-windows/git#4422. Signed-off-by: Johannes Schindelin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
GCM 2.0.567
From a terminal, run
git-credential-manager-core --versionand paste the output.2.0.567+3047faf390
Which Git host provider are you trying to connect to?
Can you access the remote repository directly in the browser using the remote URL? Yes
From a terminal, run
git remote -vto see your remote URL.Expected behavior
I am authenticated and my Git operation completes successfully.
Actual behavior
Authentication fails; falls back to username/PAT authentication (which is successful). New git credential observed in WCM; subsequent authentication attempts fail with fallback to username/PAT authentication (which is successful).
Logs
Set the environment variables
GCM_TRACE=1andGIT_TRACE=1and re-run your Git command. Review and redact any private information and attach the log.The text was updated successfully, but these errors were encountered: