-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Regression: 2.20.1 git-upload-pack SPNEGO transaction breakage #2027
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The package difference between v2.20.0 and v2.20.1 can be seen by calling diff --git a/./versions/package-versions-2.20.0.txt b/./versions/package-versions-2.20.1.txt
index 86123906b..ad61304a2 100644
--- a/./versions/package-versions-2.20.0.txt
+++ b/./versions/package-versions-2.20.1.txt
@@ -11,7 +11,7 @@ expat 2.2.6-1
file 5.35-1
findutils 4.6.0-1
gawk 4.2.1-1
-gcc-libs 7.3.0-3
+gcc-libs 7.4.0-1
gettext 0.19.8.1-1
git-extra 1.1.327.10b58d8-1
git-flow 1.11.0-1
@@ -24,10 +24,10 @@ heimdal-libs 7.5.0-3
icu 62.1-1
less 530-1
libasprintf 0.19.8.1-1
-libassuan 2.5.1-1
+libassuan 2.5.2-1
libbz2 1.0.6-2
libcrypt 2.1-2
-libcurl 7.62.0-3
+libcurl 7.63.0-1
libedit 3.1-20170329
libexpat 2.2.6-1
libffi 3.2.1-3
@@ -51,10 +51,10 @@ libpcre 8.42-1
libpcre2_8 10.32-1
libpsl 0.20.2-1
libreadline 7.0.005-1
-libsasl 2.1.27rc8-1
-libserf 1.3.9-2
+libsasl 2.1.27-1
+libserf 1.3.9-3
libsqlite 3.21.0-4
-libssh2 1.8.0-1
+libssh2 1.8.0-2
libtasn1 4.13-1
libunistring 0.9.10-1
libutil-linux 2.32.1-1
@@ -65,13 +65,13 @@ mingw-w64-x86_64-bzip2 1.0.6-6
mingw-w64-x86_64-ca-certificates 20180409-1
mingw-w64-x86_64-c-ares 1.15.0-1
mingw-w64-x86_64-connect 1.105-1
-mingw-w64-x86_64-curl 7.62.0-3
+mingw-w64-x86_64-curl 7.63.0-1
mingw-w64-x86_64-expat 2.2.6-1
mingw-w64-x86_64-gcc-libs 7.3.0-2
mingw-w64-x86_64-gettext 0.19.8.1-7
-mingw-w64-x86_64-git 2.20.0.1.9515583416-1
+mingw-w64-x86_64-git 2.20.1.1.7c9fbc07db-1
mingw-w64-x86_64-git-credential-manager 1.18.3-1
-mingw-w64-x86_64-git-doc-html 2.20.0.1.9515583416-1
+mingw-w64-x86_64-git-doc-html 2.20.1.1.7c9fbc07db-1
mingw-w64-x86_64-git-lfs 2.6.1-1
mingw-w64-x86_64-gmp 6.1.2-1
mingw-w64-x86_64-gnutls 3.6.5-1
@@ -91,13 +91,13 @@ mingw-w64-x86_64-libzip 1.5.1-1
mingw-w64-x86_64-mpc 1.1.0-1
mingw-w64-x86_64-mpfr 4.0.1-2
mingw-w64-x86_64-nettle 3.4.1-1
-mingw-w64-x86_64-nghttp2 1.35.0-1
+mingw-w64-x86_64-nghttp2 1.35.1-1
mingw-w64-x86_64-odt2txt 0.5-2
mingw-w64-x86_64-openssl 1.1.1.a-1
mingw-w64-x86_64-pcre 8.42-1
mingw-w64-x86_64-pcre2 10.23-1
-mingw-w64-x86_64-tcl 8.6.8-1
-mingw-w64-x86_64-tk 8.6.8-1
+mingw-w64-x86_64-tcl 8.6.9-2
+mingw-w64-x86_64-tk 8.6.9.1-1
mingw-w64-x86_64-wineditline 2.205-1
mingw-w64-x86_64-wintoast 1.0.0.181.9b0663d-1
mingw-w64-x86_64-xz 5.2.4-1 The one thing that sticks out is the |
I can confirm that this problem is not windows specific. Git 2.20.1 on linux also breaks when doing SPNEGO, but only if libcurl has been compiled with http2 support. The same version of libcurl on 2.18 does not have this problem. |
Interesting. Can you bisect further? The commit graph distance between 2.18 and 2.20.1 is rather large. |
I was about to start this, however the problem goes away in 2.21.0. |
Really...? that's fantastic. Can you also verify that it is solved in the latest snapshot (which will hopefully be identical to Git for Windows v2.21.0 modulo a Git LFS update that is blocking that release)? |
Looks like the latest snapshot works. 2.20.1:
Portable snapshot from https://wingit.blob.core.windows.net/files/PortableGit-prerelease-2.21.0.rc2.windows.1.707.gf6431ebcae-64-bit.7z.exe:
Phew! Looks like we are on a solid ground again! :-) @georgyo, thanks for the heads-up. I'll watch for the broken version on Linux, too. I'd also appreciate if you double-confirm after me that the issue has been fixed. I'm not paranoid, I just have been using computers for quite a while... |
Excellent! |
Setup
The issue reproduces with GfW either installed or Portable.
Details
A developer upgraded to GfW 2.20.1 (from an unknown version) and reported that he was unable to push to most, but not all, of his repositories. The error happened consistently with certain repositories: if it failed, it always failed. Upon examination, a fetch from most (but not all) repositories on the same server also failed:
A downgrade to 2.18.0 fixed his problem. Back on my machine, I tried to reproduce the issue. It seems that it occurs only when there is actual data to fetch; a repo that has been successfully fetched with 2.20.0 does not expose this behavior, but when Git actually wants some commits from the server, the error occurs.
I am not yet sure if 2.20.0 not broken, but it seems that it is out in the clean. I am going to bite the bullet and upgrade to it, and see if the same thing happens. But GfW 2.20.1 is certainly unhealthy.
Trace analysis
Here is the important part of traces (let me know if this is not enough). Domain name, IP addresses and repository name have been redacted. Long
Authorization:
headers have been truncated for readability. Also, I trimmed non-essential nearly identical repeating log lines, clearly marked.First, there is a successful
GET
request for the remote's refs.The error happens on the
POST
request to the/git-upload-pack
endpoint. TheContent-Length:
header is set to a non-zero length on the initial request (responded to with a 401), but is zero in the second, authenticating request.Let's pause here for a sec.
Content-Length:
is set to 625.Oops.
Content-Length:
is now 0!Not surprising. We sent an empty request.
With GfW 2.20.0, the
Content-Length:
is set correctly in the authenticated leg of the POST request. At the same point in the log, I seeetc. The fetch then succeeds.
#2012 likely reports the same bug. The same error is apparent in the log file
gitOutput_redacted.txt
attached to that issue (see lines 109 and 134).The text was updated successfully, but these errors were encountered: