threads / bug / 62972

[Bug] git-http-push authentication fails using netrc-file since v2.46

Subject: [Bug] git-http-push authentication fails using netrc-file since v2.46

## tl;dr

7 messages between Feb 18, 2025 and Feb 26, 2025.

replies: 6people: 3as markdown or json

Peter Georg· Feb 18, 2025, 21:34 UTC · lore

When pushing to a https remote git used to use the credentials specified in netrc-file. I have not configured any other credential stores. Since Git 2.46, in particular since commit

610cbc1dfb4ad947b82d7312c54c7987177f979f http: allow authenticating proactively

this is not the case anymore. With http.proactiveAuth not set or set to none git uses the credentials provided in netrc-file at first correctly, but at later connections uses empty credentials and fails with:

error: Cannot access URL https://<redacted>, return code 22 
fatal: git-http-push failed

With http.proactiveAuth set to auto or basic Git asks for credentials on prompt. Should it use the credentials specified in netrc-file?

With http.proactiveAuth not set or set to none and no credential specified in .netrc a git-push asks me twice for my credentials and then fails with the same error as with credentials specified in netrc-file.

When reverting commit 610cbc1dfb4ad947b82d7312c54c7987177f979f all works as it used to in previous versions again.

Running with GIT_CURL_VERBOSE=1 I was able to obtain the attached log (personal information has been replaced by <redacted>).

Please note that I have also tested newer Git versions, but I specifically looked at 2.46 as this is the first version affected by this issue.

Please let me know in case further information is required. Also happy to test patches to fix this issue.

[System Info]
git version:
git version 2.46.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
libcurl: 7.76.1
OpenSSL: OpenSSL 3.2.2 4 Jun 2024
zlib: 1.2.11
uname: Linux 6.13.2-1.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Feb  8 
21:10:29 UTC 2025 x86_64
compiler info: gnuc: 11.5
libc info: glibc: 2.34
$SHELL (typically, interactive shell): /bin/bash

22:03:25.056673 http.c:913 == Info: Trying <redacted>:443... 22:03:25.086207 http.c:913 == Info: Connected to <redacted> (<redacted>) port 443 (#0) 22:03:25.088718 http.c:913 == Info: ALPN, offering h2 22:03:25.088730 http.c:913 == Info: ALPN, offering http/1.1 22:03:25.092587 http.c:913 == Info: CAfile: /etc/pki/tls/certs/ca-bundle.crt 22:03:25.092746 http.c:913 == Info: TLSv1.0 (OUT), TLS header, Certificate Status (22): 22:03:25.092751 http.c:913 == Info: TLSv1.3 (OUT), TLS handshake, Client hello (1): 22:03:25.127797 http.c:913 == Info: TLSv1.2 (IN), TLS header, Certificate Status (22): 22:03:25.127886 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Server hello (2): 22:03:25.128353 http.c:913 == Info: TLSv1.2 (IN), TLS header, Finished (20): 22:03:25.128365 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:25.128398 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): 22:03:25.128408 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:25.128457 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Certificate (11): 22:03:25.129051 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:25.156387 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, CERT verify (15): 22:03:25.156769 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:25.156807 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Finished (20): 22:03:25.156890 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Finished (20): 22:03:25.156897 http.c:913 == Info: TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): 22:03:25.156946 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Unknown (23): 22:03:25.156952 http.c:913 == Info: TLSv1.3 (OUT), TLS handshake, Finished (20): 22:03:25.157124 http.c:913 == Info: SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 22:03:25.157129 http.c:913 == Info: ALPN, server did not agree to a protocol 22:03:25.157135 http.c:913 == Info: Server certificate: 22:03:25.157152 http.c:913 == Info: subject: <redacted> 22:03:25.157160 http.c:913 == Info: start date: Oct 1 00:00:00 2024 GMT 22:03:25.157162 http.c:913 == Info: expire date: Sep 26 23:59:59 2025 GMT 22:03:25.157188 http.c:913 == Info: subjectAltName: host "<redacted>" matched cert's "<redacted>" 22:03:25.157200 http.c:913 == Info: issuer: <redacted> 22:03:25.157202 http.c:913 == Info: SSL certificate verify ok. 22:03:25.157232 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Unknown (23): 22:03:25.157249 http.c:860 => Send header, 0000000223 bytes (0x000000df) 22:03:25.157253 http.c:872 => Send header: GET /proj/info/refs?service=git-receive-pack HTTP/1.1 22:03:25.157255 http.c:872 => Send header: Host: <redacted> 22:03:25.157256 http.c:872 => Send header: User-Agent: git/2.47.1 22:03:25.157258 http.c:872 => Send header: Accept: */* 22:03:25.157259 http.c:872 => Send header: Accept-Encoding: deflate, gzip, br 22:03:25.157260 http.c:872 => Send header: Accept-Language: en-DK, *;q=0.9 22:03:25.157261 http.c:872 => Send header: Pragma: no-cache 22:03:25.157263 http.c:872 => Send header: 22:03:25.185163 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:25.185308 http.c:913 == Info: Mark bundle as not supporting multiuse 22:03:25.185321 http.c:860 <= Recv header, 0000000027 bytes (0x0000001b) 22:03:25.185329 http.c:872 <= Recv header: HTTP/1.1 401 Unauthorized 22:03:25.185356 http.c:860 <= Recv header, 0000000037 bytes (0x00000025) 22:03:25.185360 http.c:872 <= Recv header: Date: Tue, 18 Feb 2025 21:03:25 GMT 22:03:25.185363 http.c:860 <= Recv header, 0000000016 bytes (0x00000010) 22:03:25.185367 http.c:872 <= Recv header: Server: Apache 22:03:25.185372 http.c:860 <= Recv header, 0000000043 bytes (0x0000002b) 22:03:25.185376 http.c:872 <= Recv header: WWW-Authenticate: Basic realm="User Auth" 22:03:25.185381 http.c:860 <= Recv header, 0000000021 bytes (0x00000015) 22:03:25.185385 http.c:872 <= Recv header: Content-Length: 381 22:03:25.185390 http.c:860 <= Recv header, 0000000045 bytes (0x0000002d) 22:03:25.185393 http.c:872 <= Recv header: Content-Type: text/html; charset=iso-8859-1 22:03:25.185397 http.c:860 <= Recv header, 0000000027 bytes (0x0000001b) 22:03:25.185400 http.c:872 <= Recv header: X-STG-FE: 10.4.1.50:10481 22:03:25.185404 http.c:860 <= Recv header, 0000000064 bytes (0x00000040) 22:03:25.185407 http.c:872 <= Recv header: Strict-Transport-Security: max-age=31536000; includeSubDomains 22:03:25.185413 http.c:860 <= Recv header, 0000000002 bytes (0x00000002) 22:03:25.185417 http.c:872 <= Recv header: 22:03:25.185420 http.c:913 == Info: Ignoring the response-body 22:03:25.185442 http.c:913 == Info: Connection #0 to host <redacted> left intact 22:03:25.185467 http.c:913 == Info: Issue another request to this URL: 'https://<redacted>/proj/info/refs?service=git-receive-pack' 22:03:25.185564 http.c:913 == Info: Found bundle for host <redacted>: 0x555555665ca0 [serially] 22:03:25.185570 http.c:913 == Info: Can not multiplex, even if we wanted to! 22:03:25.185587 http.c:913 == Info: Re-using existing connection! (#0) with host <redacted> 22:03:25.185594 http.c:913 == Info: Connected to <redacted> (<redacted>) port 443 (#0) 22:03:25.185610 http.c:913 == Info: Server auth using Basic with user '<redacted>' 22:03:25.185649 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Unknown (23): 22:03:25.185758 http.c:860 => Send header, 0000000286 bytes (0x0000011e) 22:03:25.185764 http.c:872 => Send header: GET /proj/info/refs?service=git-receive-pack HTTP/1.1 22:03:25.185767 http.c:872 => Send header: Host: <redacted> 22:03:25.185770 http.c:872 => Send header: Authorization: Basic <redacted> 22:03:25.185773 http.c:872 => Send header: User-Agent: git/2.47.1 22:03:25.185777 http.c:872 => Send header: Accept: */* 22:03:25.185780 http.c:872 => Send header: Accept-Encoding: deflate, gzip, br 22:03:25.185783 http.c:872 => Send header: Accept-Language: en-DK, *;q=0.9 22:03:25.185786 http.c:872 => Send header: Pragma: no-cache 22:03:25.185789 http.c:872 => Send header: 22:03:25.218075 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:25.218312 http.c:913 == Info: Mark bundle as not supporting multiuse 22:03:25.218327 http.c:860 <= Recv header, 0000000017 bytes (0x00000011) 22:03:25.218334 http.c:872 <= Recv header: HTTP/1.1 200 OK 22:03:25.218342 http.c:860 <= Recv header, 0000000037 bytes (0x00000025) 22:03:25.218346 http.c:872 <= Recv header: Date: Tue, 18 Feb 2025 21:03:25 GMT 22:03:25.218350 http.c:860 <= Recv header, 0000000016 bytes (0x00000010) 22:03:25.218353 http.c:872 <= Recv header: Server: Apache 22:03:25.218357 http.c:860 <= Recv header, 0000000046 bytes (0x0000002e) 22:03:25.218360 http.c:872 <= Recv header: Last-Modified: Tue, 18 Feb 2025 19:46:37 GMT 22:03:25.218363 http.c:860 <= Recv header, 0000000026 bytes (0x0000001a) 22:03:25.218390 http.c:872 <= Recv header: ETag: "51-62e6fe61f1b01" 22:03:25.218394 http.c:860 <= Recv header, 0000000022 bytes (0x00000016) 22:03:25.218397 http.c:872 <= Recv header: Accept-Ranges: bytes 22:03:25.218402 http.c:860 <= Recv header, 0000000020 bytes (0x00000014) 22:03:25.218405 http.c:872 <= Recv header: Content-Length: 81 22:03:25.218408 http.c:860 <= Recv header, 0000000020 bytes (0x00000014) 22:03:25.218411 http.c:872 <= Recv header: MS-Author-Via: DAV 22:03:25.218415 http.c:860 <= Recv header, 0000000033 bytes (0x00000021) 22:03:25.218418 http.c:872 <= Recv header: Content-Disposition: attachment 22:03:25.218422 http.c:860 <= Recv header, 0000000027 bytes (0x0000001b) 22:03:25.218425 http.c:872 <= Recv header: X-STG-FE: 10.4.1.50:10481 22:03:25.218428 http.c:860 <= Recv header, 0000000064 bytes (0x00000040) 22:03:25.218431 http.c:872 <= Recv header: Strict-Transport-Security: max-age=31536000; includeSubDomains 22:03:25.218436 http.c:860 <= Recv header, 0000000002 bytes (0x00000002) 22:03:25.218439 http.c:872 <= Recv header: 22:03:25.218461 http.c:913 == Info: Connection #0 to host <redacted> left intact 22:03:25.218606 http.c:913 == Info: Found bundle for host <redacted>: 0x555555665ca0 [serially] 22:03:25.218612 http.c:913 == Info: Can not multiplex, even if we wanted to! 22:03:25.218631 http.c:913 == Info: Re-using existing connection! (#0) with host <redacted> 22:03:25.218639 http.c:913 == Info: Connected to <redacted> (<redacted>) port 443 (#0) 22:03:25.218654 http.c:913 == Info: Server auth using Basic with user '<redacted>' 22:03:25.218703 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Unknown (23): 22:03:25.218810 http.c:860 => Send header, 0000000256 bytes (0x00000100) 22:03:25.218816 http.c:872 => Send header: GET /proj/HEAD HTTP/1.1 22:03:25.218820 http.c:872 => Send header: Host: <redacted> 22:03:25.218823 http.c:872 => Send header: Authorization: Basic <redacted> 22:03:25.218826 http.c:872 => Send header: User-Agent: git/2.47.1 22:03:25.218829 http.c:872 => Send header: Accept: */* 22:03:25.218833 http.c:872 => Send header: Accept-Encoding: deflate, gzip, br 22:03:25.218836 http.c:872 => Send header: Accept-Language: en-DK, *;q=0.9 22:03:25.218839 http.c:872 => Send header: Pragma: no-cache 22:03:25.218842 http.c:872 => Send header: 22:03:25.249948 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:25.250055 http.c:913 == Info: Mark bundle as not supporting multiuse 22:03:25.250064 http.c:860 <= Recv header, 0000000017 bytes (0x00000011) 22:03:25.250068 http.c:872 <= Recv header: HTTP/1.1 200 OK 22:03:25.250072 http.c:860 <= Recv header, 0000000037 bytes (0x00000025) 22:03:25.250073 http.c:872 <= Recv header: Date: Tue, 18 Feb 2025 21:03:25 GMT 22:03:25.250075 http.c:860 <= Recv header, 0000000016 bytes (0x00000010) 22:03:25.250076 http.c:872 <= Recv header: Server: Apache 22:03:25.250078 http.c:860 <= Recv header, 0000000046 bytes (0x0000002e) 22:03:25.250079 http.c:872 <= Recv header: Last-Modified: Sun, 19 Jan 2025 00:35:21 GMT 22:03:25.250081 http.c:860 <= Recv header, 0000000026 bytes (0x0000001a) 22:03:25.250083 http.c:872 <= Recv header: ETag: "15-62c0451a06b79" 22:03:25.250120 http.c:860 <= Recv header, 0000000022 bytes (0x00000016) 22:03:25.250121 http.c:872 <= Recv header: Accept-Ranges: bytes 22:03:25.250123 http.c:860 <= Recv header, 0000000020 bytes (0x00000014) 22:03:25.250145 http.c:872 <= Recv header: Content-Length: 21 22:03:25.250147 http.c:860 <= Recv header, 0000000020 bytes (0x00000014) 22:03:25.250148 http.c:872 <= Recv header: MS-Author-Via: DAV 22:03:25.250150 http.c:860 <= Recv header, 0000000033 bytes (0x00000021) 22:03:25.250151 http.c:872 <= Recv header: Content-Disposition: attachment 22:03:25.250152 http.c:860 <= Recv header, 0000000027 bytes (0x0000001b) 22:03:25.250154 http.c:872 <= Recv header: X-STG-FE: 10.4.1.50:10481 22:03:25.250155 http.c:860 <= Recv header, 0000000064 bytes (0x00000040) 22:03:25.250156 http.c:872 <= Recv header: Strict-Transport-Security: max-age=31536000; includeSubDomains 22:03:25.250159 http.c:860 <= Recv header, 0000000002 bytes (0x00000002) 22:03:25.250160 http.c:872 <= Recv header: 22:03:25.250177 http.c:913 == Info: Connection #0 to host <redacted> left intact 22:03:27.794427 http.c:913 == Info: Trying <redacted>:443... 22:03:27.823405 http.c:913 == Info: Connected to <redacted> (<redacted>) port 443 (#0) 22:03:27.825857 http.c:913 == Info: ALPN, offering h2 22:03:27.825876 http.c:913 == Info: ALPN, offering http/1.1 22:03:27.829660 http.c:913 == Info: CAfile: /etc/pki/tls/certs/ca-bundle.crt 22:03:27.829819 http.c:913 == Info: TLSv1.0 (OUT), TLS header, Certificate Status (22): 22:03:27.829823 http.c:913 == Info: TLSv1.3 (OUT), TLS handshake, Client hello (1): 22:03:27.865042 http.c:913 == Info: TLSv1.2 (IN), TLS header, Certificate Status (22): 22:03:27.865215 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Server hello (2): 22:03:27.865527 http.c:913 == Info: TLSv1.2 (IN), TLS header, Finished (20): 22:03:27.865531 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:27.865554 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): 22:03:27.865560 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:27.865578 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Certificate (11): 22:03:27.865986 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:27.892867 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, CERT verify (15): 22:03:27.893168 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:27.893194 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Finished (20): 22:03:27.893256 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Finished (20): 22:03:27.893261 http.c:913 == Info: TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): 22:03:27.893290 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Unknown (23): 22:03:27.893293 http.c:913 == Info: TLSv1.3 (OUT), TLS handshake, Finished (20): 22:03:27.893394 http.c:913 == Info: SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 22:03:27.893397 http.c:913 == Info: ALPN, server did not agree to a protocol 22:03:27.893403 http.c:913 == Info: Server certificate: 22:03:27.893420 http.c:913 == Info: subject: <redacted> 22:03:27.893428 http.c:913 == Info: start date: Oct 1 00:00:00 2024 GMT 22:03:27.893431 http.c:913 == Info: expire date: Sep 26 23:59:59 2025 GMT 22:03:27.893456 http.c:913 == Info: subjectAltName: host "<redacted>" matched cert's "<redacted>" 22:03:27.893467 http.c:913 == Info: issuer: <redacted> 22:03:27.893471 http.c:913 == Info: SSL certificate verify ok. 22:03:27.893513 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Unknown (23): 22:03:27.893525 http.c:860 => Send header, 0000000184 bytes (0x000000b8) 22:03:27.893529 http.c:872 => Send header: PROPFIND /proj/ HTTP/1.1 22:03:27.893531 http.c:872 => Send header: Host: <redacted> 22:03:27.893532 http.c:872 => Send header: User-Agent: git/2.47.1 22:03:27.893533 http.c:872 => Send header: Accept: */* 22:03:27.893535 http.c:872 => Send header: Depth: 0 22:03:27.893536 http.c:872 => Send header: Content-Type: text/xml 22:03:27.893537 http.c:872 => Send header: Content-Length: 178 22:03:27.893538 http.c:872 => Send header: Expect: 100-continue 22:03:27.893539 http.c:872 => Send header: 22:03:27.922120 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:27.922254 http.c:913 == Info: Mark bundle as not supporting multiuse 22:03:27.922270 http.c:860 <= Recv header, 0000000027 bytes (0x0000001b) 22:03:27.922280 http.c:872 <= Recv header: HTTP/1.1 401 Unauthorized 22:03:27.922288 http.c:860 <= Recv header, 0000000037 bytes (0x00000025) 22:03:27.922292 http.c:872 <= Recv header: Date: Tue, 18 Feb 2025 21:03:27 GMT 22:03:27.922297 http.c:860 <= Recv header, 0000000016 bytes (0x00000010) 22:03:27.922302 http.c:872 <= Recv header: Server: Apache 22:03:27.922309 http.c:860 <= Recv header, 0000000043 bytes (0x0000002b) 22:03:27.922314 http.c:872 <= Recv header: WWW-Authenticate: Basic realm="User Auth" 22:03:27.922319 http.c:860 <= Recv header, 0000000021 bytes (0x00000015) 22:03:27.922324 http.c:872 <= Recv header: Content-Length: 381 22:03:27.922329 http.c:860 <= Recv header, 0000000019 bytes (0x00000013) 22:03:27.922333 http.c:872 <= Recv header: Connection: close 22:03:27.922339 http.c:860 <= Recv header, 0000000045 bytes (0x0000002d) 22:03:27.922343 http.c:872 <= Recv header: Content-Type: text/html; charset=iso-8859-1 22:03:27.922348 http.c:860 <= Recv header, 0000000027 bytes (0x0000001b) 22:03:27.922353 http.c:872 <= Recv header: X-STG-FE: 10.4.1.50:10481 22:03:27.922359 http.c:860 <= Recv header, 0000000002 bytes (0x00000002) 22:03:27.922364 http.c:872 <= Recv header: 22:03:27.922390 http.c:913 == Info: Closing connection 0 22:03:27.922411 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Unknown (23): 22:03:27.922536 http.c:913 == Info: TLSv1.3 (OUT), TLS alert, close notify (256): 22:03:27.924348 http.c:913 == Info: Issue another request to this URL: 'https://<redacted>/proj/' 22:03:27.924478 http.c:913 == Info: NTLM-proxy picked AND auth done set, clear picked! 22:03:27.924483 http.c:913 == Info: Hostname <redacted> was found in DNS cache 22:03:27.924513 http.c:913 == Info: Trying <redacted>:443... 22:03:27.984070 http.c:913 == Info: Connected to <redacted> (<redacted>) port 443 (#1) 22:03:27.984655 http.c:913 == Info: ALPN, offering h2 22:03:27.984660 http.c:913 == Info: ALPN, offering http/1.1 22:03:27.988803 http.c:913 == Info: CAfile: /etc/pki/tls/certs/ca-bundle.crt 22:03:27.989030 http.c:913 == Info: TLSv1.0 (OUT), TLS header, Certificate Status (22): 22:03:27.989036 http.c:913 == Info: TLSv1.3 (OUT), TLS handshake, Client hello (1): 22:03:28.060771 http.c:913 == Info: TLSv1.2 (IN), TLS header, Certificate Status (22): 22:03:28.060850 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Server hello (2): 22:03:28.061047 http.c:913 == Info: TLSv1.2 (IN), TLS header, Finished (20): 22:03:28.061051 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:28.061125 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): 22:03:28.061134 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:28.061146 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Certificate (11): 22:03:28.061530 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:28.061537 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, CERT verify (15): 22:03:28.061622 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:28.123680 http.c:913 == Info: TLSv1.3 (IN), TLS handshake, Finished (20): 22:03:28.123827 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Finished (20): 22:03:28.123833 http.c:913 == Info: TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): 22:03:28.123853 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Unknown (23): 22:03:28.123856 http.c:913 == Info: TLSv1.3 (OUT), TLS handshake, Finished (20): 22:03:28.123958 http.c:913 == Info: SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 22:03:28.123962 http.c:913 == Info: ALPN, server did not agree to a protocol 22:03:28.123967 http.c:913 == Info: Server certificate: 22:03:28.123984 http.c:913 == Info: subject: <redacted> 22:03:28.123992 http.c:913 == Info: start date: Oct 1 00:00:00 2024 GMT 22:03:28.123996 http.c:913 == Info: expire date: Sep 26 23:59:59 2025 GMT 22:03:28.124029 http.c:913 == Info: subjectAltName: host "<redacted>" matched cert's "<redacted>" 22:03:28.124038 http.c:913 == Info: issuer: <redacted> 22:03:28.124041 http.c:913 == Info: SSL certificate verify ok. 22:03:28.124055 http.c:913 == Info: Server auth using Basic with user '' 22:03:28.124074 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Unknown (23): 22:03:28.124117 http.c:860 => Send header, 0000000211 bytes (0x000000d3) 22:03:28.124124 http.c:872 => Send header: PROPFIND /proj/ HTTP/1.1 22:03:28.124126 http.c:872 => Send header: Host: <redacted> 22:03:28.124128 http.c:872 => Send header: Authorization: Basic <redacted> 22:03:28.124129 http.c:872 => Send header: User-Agent: git/2.47.1 22:03:28.124131 http.c:872 => Send header: Accept: */* 22:03:28.124132 http.c:872 => Send header: Depth: 0 22:03:28.124134 http.c:872 => Send header: Content-Type: text/xml 22:03:28.124135 http.c:872 => Send header: Content-Length: 178 22:03:28.124137 http.c:872 => Send header: Expect: 100-continue 22:03:28.124138 http.c:872 => Send header: 22:03:28.184033 http.c:913 == Info: TLSv1.2 (IN), TLS header, Unknown (23): 22:03:28.184386 http.c:913 == Info: Mark bundle as not supporting multiuse 22:03:28.184407 http.c:860 <= Recv header, 0000000027 bytes (0x0000001b) 22:03:28.184417 http.c:872 <= Recv header: HTTP/1.1 401 Unauthorized 22:03:28.184425 http.c:860 <= Recv header, 0000000037 bytes (0x00000025) 22:03:28.184430 http.c:872 <= Recv header: Date: Tue, 18 Feb 2025 21:03:28 GMT 22:03:28.184436 http.c:860 <= Recv header, 0000000016 bytes (0x00000010) 22:03:28.184441 http.c:872 <= Recv header: Server: Apache 22:03:28.184448 http.c:913 == Info: Authentication problem. Ignoring this. 22:03:28.184454 http.c:860 <= Recv header, 0000000043 bytes (0x0000002b) 22:03:28.184459 http.c:872 <= Recv header: WWW-Authenticate: Basic realm="User Auth" 22:03:28.184464 http.c:860 <= Recv header, 0000000021 bytes (0x00000015) 22:03:28.184469 http.c:872 <= Recv header: Content-Length: 381 22:03:28.184502 http.c:860 <= Recv header, 0000000019 bytes (0x00000013) 22:03:28.184506 http.c:872 <= Recv header: Connection: close 22:03:28.184512 http.c:860 <= Recv header, 0000000045 bytes (0x0000002d) 22:03:28.184516 http.c:872 <= Recv header: Content-Type: text/html; charset=iso-8859-1 22:03:28.184521 http.c:860 <= Recv header, 0000000027 bytes (0x0000001b) 22:03:28.184526 http.c:872 <= Recv header: X-STG-FE: 10.4.1.50:10481 22:03:28.184534 http.c:913 == Info: The requested URL returned error: 401 22:03:28.184560 http.c:913 == Info: Closing connection 1 22:03:28.184582 http.c:913 == Info: TLSv1.2 (OUT), TLS header, Unknown (23): 22:03:28.184683 http.c:913 == Info: TLSv1.3 (OUT), TLS alert, close notify (256): error: Cannot access URL https://<redacted>/proj/, return code 22 fatal: git-http-push failed error: failed to push some refs to 'https://<redacted>/proj'

brian m. carlson· Feb 18, 2025, 22:53 UTC · re: Peter Georg · lore

Re: [Bug] git-http-push authentication fails using netrc-file since v2.46

On 2025-02-18 at 21:34:59, Peter Georg wrote:
Show 14 quoted lines
> When pushing to a https remote git used to use the credentials specified in
> netrc-file. I have not configured any other credential stores.
> Since Git 2.46, in particular since commit
> 
> 610cbc1dfb4ad947b82d7312c54c7987177f979f
> http: allow authenticating proactively
> 
> this is not the case anymore. With http.proactiveAuth not set or set to none
> git uses the credentials provided in netrc-file at first correctly, but at
> later connections uses empty credentials and fails with:
> 
> error: Cannot access URL https://<redacted>, return code 22
> 
> fatal: git-http-push failed

This does sound like a problem. We've long had code to use the netrc but absolutely zero tests or documentation for it. I must admit that I'm not even sure how it works, so I'll need to do some testing.

> With http.proactiveAuth set to auto or basic Git asks for credentials on
> prompt. Should it use the credentials specified in netrc-file?

I hadn't intended `http.proactiveAuth` to work that way. It's specifically designed to call the credential helper because it may get credentials back which are not a username and password (say, a Bearer token), which it can't do with a netrc file.

Also, from the documentation, it specifically looks like the netrc file is only used if no credentials are provided, and since we can't query libcurl to tell us if we would have credentials from the netrc file, I don't see how we could support the netrc file since we'd have to take the risk that there are no credentials and we'd get a 401 (which is exactly what the feature intends to avoid).

> With http.proactiveAuth not set or set to none and no credential specified
> in .netrc a git-push asks me twice for my credentials and then fails with
> the same error as with credentials specified in netrc-file.

I'll start taking a look at this tonight, but it may be later this week before I get time to write and send a patch.

In the meantime, you can use the git-credential-netrc helper from the contrib directory, which will probably let you get back to normal.

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
brian m. carlson· Feb 23, 2025, 01:53 UTC · re: brian m. carlson · lore

[PATCH 0/1] Fix netrc usage with WebDAV-based HTTP protocol

For a long time, we've enabled the automatic usage of netrc if the user doesn't provide any credentials. Unfortunately, in 2.46, this broke for the WebDAV-based HTTP protocol, which this series fixes.

In looking at this issue, I discovered that we have (before this series) zero tests for the netrc functionality and zero documentation for it, which obviously is suboptimal. In this series, I am adding one test, which is for this particular bug.

However, I think we need to either decide that we're going to support this as a fully-fledged feature and add documentation and sufficient tests, or remove it, since it's not reasonable to have undocumented, untested features that people rely on. Our HTTP code is quite subtle and complex and we can't expect future developers not to break things in this state[0]. I will note, as an argument in favour of removal, that we have git-credential-netrc helper in contrib that users can enable if they want to retain this functionality, and we could even ship it by default without much difficulty. For those reasons, I am not planning to add more tests and documentation here, but of course I welcome interested parties to do so.

[0] Personally, I had some vague knowledge this feature existed and I feel like I'm reasonably familiar with the HTTP code, and I still accidentally introduced a bug, so that doesn't bode well for contributors who are less familiar with it.

brian m. carlson (1):
  http: allow using netrc for WebDAV-based HTTP protocol
 http.c                      |  3 +--
 t/t5540-http-push-webdav.sh | 10 ++++++++++
 2 files changed, 11 insertions(+), 2 deletions(-)
brian m. carlson· Feb 23, 2025, 01:53 UTC · re: brian m. carlson · lore

[PATCH 1/1] http: allow using netrc for WebDAV-based HTTP protocol

For an extended period of time, we've enabled libcurl's netrc functionality, which will read credentials from the netrc file if none are provided. Unfortunately, we have also not documented this fact or written any tests for it, but people have come to rely on it.

In 610cbc1dfb ("http: allow authenticating proactively", 2024-07-10), we accidentally broke the ability of users to use the netrc file for the WebDAV-based HTTP protocol. Notably, it works on the initial request but does not work on subsequent requests, which causes failures because that version of the protocol will necessarily make multiple requests.

This happens because curl_empty_auth_enabled never returns -1, only 0 or 1, and so if http.proactiveAuth is not enabled, the username and password are always set to empty credentials, which prevents libcurl's fallback to netrc from working. However, in other cases, the server continues to get a 401 response and the credential helper is invoked, which is the normal behavior, so this was not noticed earlier.

To fix this, change the condition to check for enabling empty auth and also not having proactive auth enabled, which should result in the username and password not being set to a single colon in the typical case, and thus the netrc file being used.

Reported-by: Peter Georg <peter.georg@physik.uni-regensburg.de>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
 http.c                      |  3 +--
 t/t5540-http-push-webdav.sh | 10 ++++++++++
 2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/http.c b/http.c
index f4504133e8..0c9a872809 100644
--- a/http.c
+++ b/http.c
@@ -598,8 +598,7 @@ static void init_curl_http_auth(CURL *result)
 {
 	if ((!http_auth.username || !*http_auth.username) &&
 	    (!http_auth.credential || !*http_auth.credential)) {
-		int empty_auth = curl_empty_auth_enabled();
-		if ((empty_auth != -1 && !always_auth_proactively()) || empty_auth == 1) {
+		if (!always_auth_proactively() && curl_empty_auth_enabled()) {
 			curl_easy_setopt(result, CURLOPT_USERPWD, ":");
 			return;
 		} else if (!always_auth_proactively()) {
diff --git a/t/t5540-http-push-webdav.sh b/t/t5540-http-push-webdav.sh
index 37db3dec0c..3fa05ff185 100755
--- a/t/t5540-http-push-webdav.sh
+++ b/t/t5540-http-push-webdav.sh
@@ -201,4 +201,14 @@ test_expect_failure 'push to password-protected repository (no user in URL)' '
 	test_cmp expect actual
 '
 
+test_expect_success 'push to password-protected repository (netrc)' '
+	test_commit pw-netrc &&
+	echo "default login user@host password pass@host" >"$HOME/.netrc" &&
+	GIT_TRACE=1 GIT_CURL_VERBOSE=1 git push "$HTTPD_URL/auth/dumb/test_repo.git" HEAD &&
+	git rev-parse --verify HEAD >expect &&
+	git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH/auth/dumb/test_repo.git" \
+		rev-parse --verify HEAD >actual &&
+	test_cmp expect actual
+'
+
 test_done
Junio C Hamano· Feb 24, 2025, 16:46 UTC · re: brian m. carlson · lore

Re: [PATCH 0/1] Fix netrc usage with WebDAV-based HTTP protocol

"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> However, I think we need to either decide that we're going to support
> this as a fully-fledged feature and add documentation and sufficient
> tests, or remove it, since it's not reasonable to have undocumented,
> untested features that people rely on.

Does "this" refer to "use of netrc in HTTP code paths", or "HTTP walker"? I am kind of surprised that anybody is still using the latter, regardless of where the credential is locally stored.

> I will note, as an argument in favour of removal, that we have
> git-credential-netrc helper in contrib that users can enable if
> they want to retain this functionality, and we could even ship it
> by default without much difficulty.
I am fine with the approach.
Thanks.
brian m. carlson· Feb 24, 2025, 22:09 UTC · re: Junio C Hamano · lore

Re: [PATCH 0/1] Fix netrc usage with WebDAV-based HTTP protocol

On 2025-02-24 at 16:46:29, Junio C Hamano wrote:
Show 10 quoted lines
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > However, I think we need to either decide that we're going to support
> > this as a fully-fledged feature and add documentation and sufficient
> > tests, or remove it, since it's not reasonable to have undocumented,
> > untested features that people rely on.
> 
> Does "this" refer to "use of netrc in HTTP code paths", or "HTTP
> walker"?  I am kind of surprised that anybody is still using the
> latter, regardless of where the credential is locally stored.
It refers to netrc in HTTP code paths.

There are definitely people using the WebDAV-based HTTP protocol still, but after reading the comment in the code that implies that we don't read packed-refs, I'm less and less inclined to say that's a good idea. It's probably going to die pretty quickly when we move to reftable, though, since that protocol only works with the files backend.

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
Peter Georg· Feb 26, 2025, 12:38 UTC · re: brian m. carlson · lore

Re: [PATCH 0/1] Fix netrc usage with WebDAV-based HTTP protocol

On 23/02/2025 02.53, brian m. carlson wrote:
Show 6 quoted lines
> I will note, as an argument in favour of removal, that
> we have git-credential-netrc helper in contrib that users can enable if
> they want to retain this functionality, and we could even ship it by
> default without much difficulty.  For those reasons, I am not planning
> to add more tests and documentation here, but of course I welcome
> interested parties to do so.

This approach seems reasonable to me. I personally, for example, did not even know that the git-credential-netrc helper exists, but it obviously works for me. Thus it would probably make sense to somehow document this, at least once the undocumented feature of directly using credentials specified in netrc is not working anymore.

← back to recent threads