* git clone with basic auth in url directly returns authentication failure after 401 received under some git versions
@ 2022-08-20 2:51 王小建
2022-08-20 8:44 ` Jeff King
0 siblings, 1 reply; 9+ messages in thread
From: 王小建 @ 2022-08-20 2:51 UTC (permalink / raw)
To: git
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
I want to git clone with basic auth in url, such as git clone
http://xxx:xxx@xxx.xxx/xxx/xxx
What did you expect to happen? (Expected behavior)
Clone successfully
What happened instead? (Actual behavior)
fatal: Authentication failed
What's different between what you expected and what actually happened?
When I use git v2.36.2 (docker image is alpine/git:v2.36.2) to clone
with basic auth in url, when receiving the 401, it directly returns
authentication failure, even recv head has www-authenticate: Basic
realm=Restricted,
and no request is send again. I think it should send request with
authorization: Basic header after receive 401.
And use git v2.34.2 (docker image is alpine/git:v2.34.1) to clone it works well.
Anything else you want to add:
$ server git version: git version 2.30.2
Below is the GIT_CURL_VERBOSE information between 2 versions
GIT_CURL_VERBOSE info with v2.36.2 (docker image is alpine/git:v2.36.2) Output:
$ docker run -it -e GIT_CURL_VERBOSE=1 5de1a96efc49 clone
http://xxx:xxx@xxx.xxx/xxx/xxx
Cloning into 'xxx'...
10:54:06.204996 http.c:664 == Info: Trying xxx.xxx.xxx.xxx:80...
10:54:06.235057 http.c:664 == Info: Connected to xxx.xxx
(xxx.xxx.xxx.xxx) port 80 (#0)
10:54:06.235347 http.c:611 => Send header, 0000000221
bytes (0x000000dd)
10:54:06.235406 http.c:623 => Send header: GET
/xxx/xxx/info/refs?service=git-upload-pack HTTP/1.1
10:54:06.235665 http.c:623 => Send header: Host: xxx.xxx
10:54:06.235677 http.c:623 => Send header: User-Agent: git/2.36.2
10:54:06.235687 http.c:623 => Send header: Accept: */*
10:54:06.235701 http.c:623 => Send header:
Accept-Encoding: deflate, gzip, br
10:54:06.235712 http.c:623 => Send header: Pragma: no-cache
10:54:06.235727 http.c:623 => Send header: Git-Protocol: version=2
10:54:06.235779 http.c:623 => Send header:
10:54:06.240590 http.c:664 == Info: Mark bundle as not
supporting multiuse
10:54:06.240658 http.c:611 <= Recv header, 0000000020
bytes (0x00000014)
10:54:06.240677 http.c:623 <= Recv header: HTTP/1.1 302 Found
10:54:06.240692 http.c:611 <= Recv header, 0000000037
bytes (0x00000025)
10:54:06.240700 http.c:623 <= Recv header: Date: Fri, 19
Aug 2022 10:54:06 GMT
10:54:06.240713 http.c:611 <= Recv header, 0000000025
bytes (0x00000019)
10:54:06.240723 http.c:623 <= Recv header: Content-Type: text/html
10:54:06.240737 http.c:611 <= Recv header, 0000000021
bytes (0x00000015)
10:54:06.240753 http.c:623 <= Recv header: Content-Length: 154
10:54:06.240801 http.c:611 <= Recv header, 0000000024
bytes (0x00000018)
10:54:06.240812 http.c:623 <= Recv header: Connection: keep-alive
10:54:06.240828 http.c:611 <= Recv header, 0000000100
bytes (0x00000064)
10:54:06.240839 http.c:623 <= Recv header: Location:
https://xxx.xxx/xxx/xxx/info/refs?service=git-upload-pack
10:54:06.240847 http.c:611 <= Recv header, 0000000022
bytes (0x00000016)
10:54:06.240857 http.c:623 <= Recv header: Via: HTTP/1.1 SLB.25
10:54:06.240868 http.c:611 <= Recv header, 0000000002
bytes (0x00000002)
10:54:06.240876 http.c:623 <= Recv header:
10:54:06.240884 http.c:664 == Info: Ignoring the response-body
10:54:06.241141 http.c:664 == Info: Connection #0 to host
xxx.xxx left intact
10:54:06.241331 http.c:664 == Info: Clear auth, redirects
to port from 80 to 443
10:54:06.241350 http.c:664 == Info: Issue another request
to this URL: 'https://xxx.xxx/xxx/xxx/info/refs?service=git-upload-pack'
10:54:06.241480 http.c:664 == Info: NTLM-proxy picked AND
auth done set, clear picked
10:54:06.248582 http.c:664 == Info: Trying xxx.xxx.xxx.xxx:443...
10:54:06.254035 http.c:664 == Info: Connected to xxx.xxx
(xxx.xxx.xxx.xxx) port 443 (#1)
10:54:06.254672 http.c:664 == Info: ALPN: offers h2
10:54:06.254723 http.c:664 == Info: ALPN: offers http/1.1
10:54:06.267498 http.c:664 == Info: CAfile:
/etc/ssl/certs/ca-certificates.crt
10:54:06.267561 http.c:664 == Info: CApath: none
10:54:06.267838 http.c:664 == Info: TLSv1.3 (OUT), TLS
handshake, Client hello (1):
10:54:06.277311 http.c:664 == Info: TLSv1.3 (IN), TLS
handshake, Server hello (2):
10:54:06.277427 http.c:664 == Info: TLSv1.2 (IN), TLS
handshake, Certificate (11):
10:54:06.278079 http.c:664 == Info: TLSv1.2 (IN), TLS
handshake, Server key exchange (12):
10:54:06.278272 http.c:664 == Info: TLSv1.2 (IN), TLS
handshake, Server finished (14):
10:54:06.278609 http.c:664 == Info: TLSv1.2 (OUT), TLS
handshake, Client key exchange (16):
10:54:06.278685 http.c:664 == Info: TLSv1.2 (OUT), TLS
change cipher, Change cipher spec (1):
10:54:06.278797 http.c:664 == Info: TLSv1.2 (OUT), TLS
handshake, Finished (20):
10:54:06.284962 http.c:664 == Info: TLSv1.2 (IN), TLS
handshake, Finished (20):
10:54:06.285064 http.c:664 == Info: SSL connection using
TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
10:54:06.285082 http.c:664 == Info: ALPN: server accepted h2
10:54:06.285101 http.c:664 == Info: Server certificate:
10:54:06.285116 http.c:664 == Info: subject: CN=*.xxx.xxx
10:54:06.285133 http.c:664 == Info: start date: Apr 8
00:00:00 2022 GMT
10:54:06.285254 http.c:664 == Info: expire date: Apr 9
23:59:59 2023 GMT
10:54:06.285317 http.c:664 == Info: subjectAltName: host
"xxx.xxx" matched cert's "*.xxx.xxx"
10:54:06.285364 http.c:664 == Info: issuer: C=US;
O=DigiCert Inc; CN=RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
10:54:06.285374 http.c:664 == Info: SSL certificate verify ok.
10:54:06.285460 http.c:664 == Info: Using HTTP2, server
supports multiplexing
10:54:06.285508 http.c:664 == Info: Copying HTTP/2 data
in stream buffer to connection buffer after upgrade: len=0
10:54:06.285902 http.c:664 == Info: h2h3 [:method: GET]
10:54:06.285956 http.c:664 == Info: h2h3 [:path:
/xxx/xxx/info/refs?service=git-upload-pack]
10:54:06.285977 http.c:664 == Info: h2h3 [:scheme: https]
10:54:06.285996 http.c:664 == Info: h2h3 [:authority: xxx.xxx]
10:54:06.286011 http.c:664 == Info: h2h3 [user-agent: git/2.36.2]
10:54:06.286019 http.c:664 == Info: h2h3 [accept: */*]
10:54:06.286029 http.c:664 == Info: h2h3
[accept-encoding: deflate, gzip, br]
10:54:06.286039 http.c:664 == Info: h2h3 [pragma: no-cache]
10:54:06.286048 http.c:664 == Info: h2h3 [git-protocol: version=2]
10:54:06.286075 http.c:664 == Info: Using Stream ID: 1
(easy handle 0x7f4673e9e210)
10:54:06.286401 http.c:611 => Send header, 0000000219
bytes (0x000000db)
10:54:06.286459 http.c:623 => Send header: GET
/xxx/xxx/info/refs?service=git-upload-pack HTTP/2
10:54:06.286473 http.c:623 => Send header: Host: xxx.xxx
10:54:06.286481 http.c:623 => Send header: user-agent: git/2.36.2
10:54:06.286495 http.c:623 => Send header: accept: */*
10:54:06.286562 http.c:623 => Send header:
accept-encoding: deflate, gzip, br
10:54:06.286604 http.c:623 => Send header: pragma: no-cache
10:54:06.286647 http.c:623 => Send header: git-protocol: version=2
10:54:06.286694 http.c:623 => Send header:
10:54:06.286835 http.c:664 == Info: Connection state
changed (MAX_CONCURRENT_STREAMS == 128)!
10:54:06.296853 http.c:611 <= Recv header, 0000000013
bytes (0x0000000d)
10:54:06.296907 http.c:623 <= Recv header: HTTP/2 401
10:54:06.296924 http.c:611 <= Recv header, 0000000037
bytes (0x00000025)
10:54:06.296939 http.c:623 <= Recv header: date: Fri, 19
Aug 2022 10:54:06 GMT
10:54:06.296952 http.c:611 <= Recv header, 0000000047
bytes (0x0000002f)
10:54:06.296964 http.c:623 <= Recv header: content-type:
application/json; charset=UTF-8
10:54:06.297008 http.c:611 <= Recv header, 0000000020
bytes (0x00000014)
10:54:06.297023 http.c:623 <= Recv header: content-length: 69
10:54:06.297035 http.c:611 <= Recv header, 0000000070
bytes (0x00000046)
10:54:06.297043 http.c:623 <= Recv header: traceparent:
00-ad497b554e2addf5b0a94937024187c4-138a06a14cd9ed47-01
10:54:06.297083 http.c:611 <= Recv header, 0000000042
bytes (0x0000002a)
10:54:06.297099 http.c:623 <= Recv header:
www-authenticate: Basic realm=Restricted
10:54:06.297116 http.c:611 <= Recv header, 0000000002
bytes (0x00000002)
10:54:06.297125 http.c:623 <= Recv header:
10:54:06.297313 http.c:664 == Info: Connection #1 to host
xxx.xxx left intact
fatal: Authentication failed for 'http://xxx.xxx/xxx/xxx/'
GIT_CURL_VERBOSE info with v2.34.2 (docker image is alpine/git:v2.34.1) Output:
$ docker run -it -e GIT_CURL_VERBOSE=1 aaee7a44d8d4 clone
http://xxx:xxx@xxx.xxx/xxx/xxx
Cloning into 'xxx'...
11:11:10.183612 http.c:664 == Info: Trying xxx.xxx.xxx:80...
11:11:10.190536 http.c:664 == Info: Connected to xxx.xxx
(xxx.xxx.xxx) port 80 (#0)
11:11:10.190719 http.c:611 => Send header, 0000000221
bytes (0x000000dd)
11:11:10.190798 http.c:623 => Send header: GET
/xxx/xxx/info/refs?service=git-upload-pack HTTP/1.1
11:11:10.190815 http.c:623 => Send header: Host: xxx.xxx
11:11:10.190828 http.c:623 => Send header: User-Agent: git/2.34.2
11:11:10.190836 http.c:623 => Send header: Accept: */*
11:11:10.190844 http.c:623 => Send header:
Accept-Encoding: deflate, gzip, br
11:11:10.190875 http.c:623 => Send header: Pragma: no-cache
11:11:10.190883 http.c:623 => Send header: Git-Protocol: version=2
11:11:10.190891 http.c:623 => Send header:
11:11:10.196034 http.c:664 == Info: Mark bundle as not
supporting multiuse
11:11:10.196086 http.c:611 <= Recv header, 0000000020
bytes (0x00000014)
11:11:10.196104 http.c:623 <= Recv header: HTTP/1.1 302 Found
11:11:10.196120 http.c:611 <= Recv header, 0000000037
bytes (0x00000025)
11:11:10.196133 http.c:623 <= Recv header: Date: Fri, 19
Aug 2022 11:11:10 GMT
11:11:10.196272 http.c:611 <= Recv header, 0000000025
bytes (0x00000019)
11:11:10.196289 http.c:623 <= Recv header: Content-Type: text/html
11:11:10.196305 http.c:611 <= Recv header, 0000000021
bytes (0x00000015)
11:11:10.196318 http.c:623 <= Recv header: Content-Length: 154
11:11:10.196362 http.c:611 <= Recv header, 0000000024
bytes (0x00000018)
11:11:10.196396 http.c:623 <= Recv header: Connection: keep-alive
11:11:10.196413 http.c:611 <= Recv header, 0000000100
bytes (0x00000064)
11:11:10.196429 http.c:623 <= Recv header: Location:
https://xxx.xxx/xxx/xxx/info/refs?service=git-upload-pack
11:11:10.196463 http.c:611 <= Recv header, 0000000022
bytes (0x00000016)
11:11:10.196504 http.c:623 <= Recv header: Via: HTTP/1.1 SLB.27
11:11:10.196544 http.c:611 <= Recv header, 0000000002
bytes (0x00000002)
11:11:10.196555 http.c:623 <= Recv header:
11:11:10.196564 http.c:664 == Info: Ignoring the response-body
11:11:10.196649 http.c:664 == Info: Connection #0 to host
xxx.xxx left intact
11:11:10.196718 http.c:664 == Info: Issue another request
to this URL: 'https://xxx.xxx/xxx/xxx/info/refs?service=git-upload-pack'
11:11:10.196869 http.c:664 == Info: NTLM-proxy picked AND
auth done set, clear picked!
11:11:10.202506 http.c:664 == Info: Trying xxx.xxx.xxx:443...
11:11:10.208418 http.c:664 == Info: Connected to xxx.xxx
(xxx.xxx.xxx) port 443 (#1)
11:11:10.208923 http.c:664 == Info: ALPN, offering h2
11:11:10.208964 http.c:664 == Info: ALPN, offering http/1.1
11:11:10.221901 http.c:664 == Info: CAfile:
/etc/ssl/certs/ca-certificates.crt
11:11:10.221963 http.c:664 == Info: CApath: none
11:11:10.222300 http.c:664 == Info: TLSv1.3 (OUT), TLS
handshake, Client hello (1):
11:11:10.233108 http.c:664 == Info: TLSv1.3 (IN), TLS
handshake, Server hello (2):
11:11:10.233296 http.c:664 == Info: TLSv1.2 (IN), TLS
handshake, Certificate (11):
11:11:10.233803 http.c:664 == Info: TLSv1.2 (IN), TLS
handshake, Server key exchange (12):
11:11:10.233952 http.c:664 == Info: TLSv1.2 (IN), TLS
handshake, Server finished (14):
11:11:10.234129 http.c:664 == Info: TLSv1.2 (OUT), TLS
handshake, Client key exchange (16):
11:11:10.234311 http.c:664 == Info: TLSv1.2 (OUT), TLS
change cipher, Change cipher spec (1):
11:11:10.234429 http.c:664 == Info: TLSv1.2 (OUT), TLS
handshake, Finished (20):
11:11:10.240556 http.c:664 == Info: TLSv1.2 (IN), TLS
handshake, Finished (20):
11:11:10.240640 http.c:664 == Info: SSL connection using
TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
11:11:10.240655 http.c:664 == Info: ALPN, server accepted to use h2
11:11:10.240705 http.c:664 == Info: Server certificate:
11:11:10.240724 http.c:664 == Info: subject: CN=*.xxx.xxx
11:11:10.240743 http.c:664 == Info: start date: Apr 8
00:00:00 2022 GMT
11:11:10.240751 http.c:664 == Info: expire date: Apr 9
23:59:59 2023 GMT
11:11:10.240769 http.c:664 == Info: subjectAltName: host
"xxx.xxx" matched cert's "*.xxx.xxx"
11:11:10.240792 http.c:664 == Info: issuer: C=US;
O=DigiCert Inc; CN=RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
11:11:10.240807 http.c:664 == Info: SSL certificate verify ok.
11:11:10.240873 http.c:664 == Info: Using HTTP2, server
supports multiplexing
11:11:10.240912 http.c:664 == Info: Connection state
changed (HTTP/2 confirmed)
11:11:10.240926 http.c:664 == Info: Copying HTTP/2 data
in stream buffer to connection buffer after upgrade: len=0
11:11:10.241310 http.c:664 == Info: Using Stream ID: 1
(easy handle 0x7ff7c6f93ab0)
11:11:10.241507 http.c:611 => Send header, 0000000219
bytes (0x000000db)
11:11:10.241539 http.c:623 => Send header: GET
/xxx/xxx/info/refs?service=git-upload-pack HTTP/2
11:11:10.241593 http.c:623 => Send header: Host: xxx.xxx
11:11:10.241612 http.c:623 => Send header: user-agent: git/2.34.2
11:11:10.241623 http.c:623 => Send header: accept: */*
11:11:10.241632 http.c:623 => Send header:
accept-encoding: deflate, gzip, br
11:11:10.241642 http.c:623 => Send header: pragma: no-cache
11:11:10.241653 http.c:623 => Send header: git-protocol: version=2
11:11:10.241662 http.c:623 => Send header:
11:11:10.241944 http.c:664 == Info: Connection state
changed (MAX_CONCURRENT_STREAMS == 128)!
11:11:10.252717 http.c:611 <= Recv header, 0000000013
bytes (0x0000000d)
11:11:10.252792 http.c:623 <= Recv header: HTTP/2 401
11:11:10.252811 http.c:611 <= Recv header, 0000000037
bytes (0x00000025)
11:11:10.252829 http.c:623 <= Recv header: date: Fri, 19
Aug 2022 11:11:10 GMT
11:11:10.252849 http.c:611 <= Recv header, 0000000047
bytes (0x0000002f)
11:11:10.252863 http.c:623 <= Recv header: content-type:
application/json; charset=UTF-8
11:11:10.252874 http.c:611 <= Recv header, 0000000020
bytes (0x00000014)
11:11:10.252887 http.c:623 <= Recv header: content-length: 69
11:11:10.252938 http.c:611 <= Recv header, 0000000070
bytes (0x00000046)
11:11:10.252956 http.c:623 <= Recv header: traceparent:
00-f423b7618abb5590f143da20b2febda1-e63b3c81e9e9dd7b-01
11:11:10.252973 http.c:611 <= Recv header, 0000000042
bytes (0x0000002a)
11:11:10.252984 http.c:623 <= Recv header:
www-authenticate: Basic realm=Restricted
11:11:10.253028 http.c:611 <= Recv header, 0000000002
bytes (0x00000002)
11:11:10.253036 http.c:623 <= Recv header:
11:11:10.253050 http.c:664 == Info: Ignoring the response-body
11:11:10.253439 http.c:664 == Info: Connection #1 to host
xxx.xxx left intact
11:11:10.253504 http.c:664 == Info: Issue another request
to this URL: 'https://xxx.xxx/xxx/xxx/info/refs?service=git-upload-pack'
11:11:10.253611 http.c:664 == Info: Found bundle for host
xxx.xxx: 0x7ff7c6fbb590 [can multiplex]
11:11:10.253679 http.c:664 == Info: Re-using existing
connection! (#1) with host xxx.xxx
11:11:10.253783 http.c:664 == Info: Connected to xxx.xxx
(xxx.xxx.xxx) port 443 (#1)
11:11:10.253856 http.c:664 == Info: Server auth using
Basic with user 'git'
11:11:10.253893 http.c:664 == Info: Using Stream ID: 3
(easy handle 0x7ff7c6f93ab0)
11:11:10.254109 http.c:611 => Send header, 0000000290
bytes (0x00000122)
11:11:10.254171 http.c:623 => Send header: GET
/xxx/xxx/info/refs?service=git-upload-pack HTTP/2
11:11:10.254184 http.c:623 => Send header: Host: xxx.xxx
11:11:10.254276 http.c:623 => Send header: authorization: Basic
11:11:10.254302 http.c:623 => Send header: user-agent: git/2.34.2
11:11:10.254313 http.c:623 => Send header: accept: */*
11:11:10.254325 http.c:623 => Send header:
accept-encoding: deflate, gzip, br
11:11:10.254343 http.c:623 => Send header: pragma: no-cache
11:11:10.254356 http.c:623 => Send header: git-protocol: version=2
11:11:10.254366 http.c:623 => Send header:
11:11:10.326732 http.c:611 <= Recv header, 0000000013
bytes (0x0000000d)
11:11:10.326883 http.c:623 <= Recv header: HTTP/2 200
11:11:10.326918 http.c:611 <= Recv header, 0000000037
bytes (0x00000025)
11:11:10.326943 http.c:623 <= Recv header: date: Fri, 19
Aug 2022 11:11:10 GMT
11:11:10.326954 http.c:611 <= Recv header, 0000000059
bytes (0x0000003b)
11:11:10.326973 http.c:623 <= Recv header: content-type:
application/x-git-upload-pack-advertisement
11:11:10.327000 http.c:611 <= Recv header, 0000000053
bytes (0x00000035)
11:11:10.327023 http.c:623 <= Recv header: cache-control:
no-cache, max-age=0, must-revalidate
11:11:10.327088 http.c:611 <= Recv header, 0000000040
bytes (0x00000028)
11:11:10.327114 http.c:623 <= Recv header: expires: Fri,
01 Jan 1980 00:00:00 GMT
11:11:10.327138 http.c:611 <= Recv header, 0000000018
bytes (0x00000012)
11:11:10.327149 http.c:623 <= Recv header: pragma: no-cache
11:11:10.327164 http.c:611 <= Recv header, 0000000002
bytes (0x00000002)
11:11:10.327176 http.c:623 <= Recv header:
11:11:10.327501 http.c:664 == Info: Connection #1 to host
xxx.xxx left intact
warning: redirecting to https://xxx.xxx/xxx/xxx/
11:11:10.328628 http.c:664 == Info: Found bundle for host
xxx.xxx: 0x7ff7c6fbb590 [can multiplex]
11:11:10.328730 http.c:664 == Info: Re-using existing
connection! (#1) with host xxx.xxx
11:11:10.328845 http.c:664 == Info: Connected to xxx.xxx
(xxx.xxx.xxx) port 443 (#1)
11:11:10.328899 http.c:664 == Info: Server auth using
Basic with user 'git'
11:11:10.328956 http.c:664 == Info: Using Stream ID: 5
(easy handle 0x7ff7c6f93ab0)
11:11:10.329168 http.c:611 => Send header, 0000000362
bytes (0x0000016a)
11:11:10.329286 http.c:623 => Send header: POST
/xxx/xxx/git-upload-pack HTTP/2
11:11:10.329305 http.c:623 => Send header: Host: xxx.xxx
11:11:10.329313 http.c:623 => Send header: authorization: Basic
11:11:10.329326 http.c:623 => Send header: user-agent: git/2.34.2
11:11:10.329340 http.c:623 => Send header:
accept-encoding: deflate, gzip, br
11:11:10.329365 http.c:623 => Send header: content-type:
application/x-git-upload-pack-request
11:11:10.329444 http.c:623 => Send header: accept:
application/x-git-upload-pack-result
11:11:10.329485 http.c:623 => Send header: git-protocol: version=2
11:11:10.329583 http.c:623 => Send header: content-length: 164
11:11:10.329594 http.c:623 => Send header:
11:11:10.329819 http.c:664 == Info: We are completely
uploaded and fine
11:11:10.447431 http.c:611 <= Recv header, 0000000013
bytes (0x0000000d)
11:11:10.447496 http.c:623 <= Recv header: HTTP/2 200
11:11:10.447516 http.c:611 <= Recv header, 0000000037
bytes (0x00000025)
11:11:10.447524 http.c:623 <= Recv header: date: Fri, 19
Aug 2022 11:11:10 GMT
11:11:10.447574 http.c:611 <= Recv header, 0000000052
bytes (0x00000034)
11:11:10.447591 http.c:623 <= Recv header: content-type:
application/x-git-upload-pack-result
11:11:10.447639 http.c:611 <= Recv header, 0000000053
bytes (0x00000035)
11:11:10.447649 http.c:623 <= Recv header: cache-control:
no-cache, max-age=0, must-revalidate
11:11:10.447660 http.c:611 <= Recv header, 0000000040
bytes (0x00000028)
11:11:10.447670 http.c:623 <= Recv header: expires: Fri,
01 Jan 1980 00:00:00 GMT
11:11:10.447679 http.c:611 <= Recv header, 0000000018
bytes (0x00000012)
11:11:10.447687 http.c:623 <= Recv header: pragma: no-cache
11:11:10.447701 http.c:611 <= Recv header, 0000000070
bytes (0x00000046)
11:11:10.447717 http.c:623 <= Recv header: traceparent:
00-3134d9583a00d714098ad8db7a2f7777-10b2626d4765359f-01
11:11:10.447727 http.c:611 <= Recv header, 0000000002
bytes (0x00000002)
11:11:10.447736 http.c:623 <= Recv header:
11:11:10.662595 http.c:664 == Info: Connection #1 to host
xxx.xxx left intact
11:11:10.684884 http.c:664 == Info: Found bundle for host
xxx.xxx: 0x7ff7c6fbb590 [can multiplex]
11:11:10.684972 http.c:664 == Info: Re-using existing
connection! (#1) with host xxx.xxx
11:11:10.685045 http.c:664 == Info: Connected to xxx.xxx
(xxx.xxx.xxx) port 443 (#1)
11:11:10.685122 http.c:664 == Info: Server auth using
Basic with user 'git'
11:11:10.685194 http.c:664 == Info: Using Stream ID: 7
(easy handle 0x7ff7c6f93ab0)
11:11:10.685431 http.c:611 => Send header, 0000000388
bytes (0x00000184)
11:11:10.685462 http.c:623 => Send header: POST
/xxx/xxx/git-upload-pack HTTP/2
11:11:10.685528 http.c:623 => Send header: Host: xxx.xxx
11:11:10.685579 http.c:623 => Send header: authorization: Basic
11:11:10.685597 http.c:623 => Send header: user-agent: git/2.34.2
11:11:10.685636 http.c:623 => Send header:
accept-encoding: deflate, gzip, br
11:11:10.685671 http.c:623 => Send header: content-type:
application/x-git-upload-pack-request
11:11:10.685685 http.c:623 => Send header: accept:
application/x-git-upload-pack-result
11:11:10.685695 http.c:623 => Send header: git-protocol: version=2
11:11:10.685704 http.c:623 => Send header: content-encoding: gzip
11:11:10.685741 http.c:623 => Send header: content-length: 19678
11:11:10.685945 http.c:623 => Send header:
11:11:10.686431 http.c:664 == Info: We are completely
uploaded and fine
11:11:11.165227 http.c:611 <= Recv header, 0000000013
bytes (0x0000000d)
11:11:11.165334 http.c:623 <= Recv header: HTTP/2 200
11:11:11.165358 http.c:611 <= Recv header, 0000000037
bytes (0x00000025)
11:11:11.165370 http.c:623 <= Recv header: date: Fri, 19
Aug 2022 11:11:11 GMT
11:11:11.165391 http.c:611 <= Recv header, 0000000052
bytes (0x00000034)
11:11:11.165403 http.c:623 <= Recv header: content-type:
application/x-git-upload-pack-result
11:11:11.165414 http.c:611 <= Recv header, 0000000053
bytes (0x00000035)
11:11:11.165430 http.c:623 <= Recv header: cache-control:
no-cache, max-age=0, must-revalidate
11:11:11.165490 http.c:611 <= Recv header, 0000000040
bytes (0x00000028)
11:11:11.165501 http.c:623 <= Recv header: expires: Fri,
01 Jan 1980 00:00:00 GMT
11:11:11.165518 http.c:611 <= Recv header, 0000000018
bytes (0x00000012)
11:11:11.165537 http.c:623 <= Recv header: pragma: no-cache
11:11:11.165553 http.c:611 <= Recv header, 0000000070
bytes (0x00000046)
11:11:11.165582 http.c:623 <= Recv header: traceparent:
00-8526084c5ce698fc4aaa4cd887c14e04-1ff731d1925ebf82-01
11:11:11.165591 http.c:611 <= Recv header, 0000000002
bytes (0x00000002)
11:11:11.165628 http.c:623 <= Recv header:
remote: Enumerating objects: 165, done.
remote: Counting objects: 100% (165/165), done.
remote: Compressing objects: 100% (162/162), done.
remote: Total 45555 (delta 77), reused 0 (delta 0), pack-reused 45390
11:11:17.236374 http.c:664 == Info: Connection #1 to host
xxx.xxx left intact
Receiving objects: 100% (45555/45555), 29.04 MiB | 4.85 MiB/s, done.
Resolving deltas: 100% (35362/35362), done.
Look forward to your favourable reply！
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git clone with basic auth in url directly returns authentication failure after 401 received under some git versions
2022-08-20 2:51 git clone with basic auth in url directly returns authentication failure after 401 received under some git versions 王小建
@ 2022-08-20 8:44 ` Jeff King
2022-08-20 11:59 ` 王小建
2022-08-20 22:32 ` Daniel Stenberg
0 siblings, 2 replies; 9+ messages in thread
From: Jeff King @ 2022-08-20 8:44 UTC (permalink / raw)
To: 王小建; +Cc: Daniel Stenberg, git
On Sat, Aug 20, 2022 at 10:51:16AM +0800, 王小建 wrote:
> What's different between what you expected and what actually happened?
>
> When I use git v2.36.2 (docker image is alpine/git:v2.36.2) to clone
> with basic auth in url, when receiving the 401, it directly returns
> authentication failure, even recv head has www-authenticate: Basic
> realm=Restricted,
> and no request is send again. I think it should send request with
> authorization: Basic header after receive 401.
> And use git v2.34.2 (docker image is alpine/git:v2.34.1) to clone it works well.
I think the problem here is not the difference in Git versions, but
rather in libcurl versions. I can reproduce your problem using the
docker containers. But if I build locally, using the same version of
curl, then I see the issue with both git versions.
The problem is how curl handles cross-protocol redirects. From Git's
perspective, we hand the credentials to libcurl, and ask it to fetch the
requested URL, including following redirects. If it comes back with a
401, then we assume our credentials were bad.
But what changed in curl is that it will now discard credentials during
a redirect. And in your example, there's a redirect from http to https
(uninteresting bits snipped from the output):
> Info: Connected to xxx.xxx (xxx.xxx.xxx.xxx) port 80 (#0)
> Send header: GET /xxx/xxx/info/refs?service=git-upload-pack HTTP/1.1
> Recv header: HTTP/1.1 302 Found
> Recv header: Location: https://xxx.xxx/xxx/xxx/info/refs?service=git-upload-pack
In the older version, after the redirect we see a 401 and curl (not git)
resends with the stored credentials.
But in the newer version, we see this right after the redirect:
> Info: Connection #0 to host xxx.xxx left intact
> Info: Clear auth, redirects to port from 80 to 443
So it is dropping the credential that Git gave it.
The curl change seems to be from 620ea2141 (transfer: redirects to other
protocols or ports clear auth, 2022-04-25). The goal is to avoid leaking
credentials between ports: https://curl.se/docs/CVE-2022-27774.html
So that makes sense, though I wonder if curl ought to make an exception
for moving from 80 to 443 and http to https?
I don't think there's otherwise much Git can do here. We thought we gave
curl a username and password, but they weren't ultimately used. But Git
won't reissue the request, because it assumes the auth was rejected.
I guess we can ask curl if it saw a redirect, and assume if so that the
auth was cleared. That feels a bit hacky. And it's subverting curl's
attempt not to leak the credentials. In general, I'd like to defer as
much as possible to curl's ideas of how to handle things, because
they're much better at implementing http best practices than we are. :)
Another option is to allow the user to set CURLOPT_UNRESTRICTED_AUTH,
but that seems like a bad idea for the same reason.
Hopefully that explains what's going on. The short answer for your case
is: use an https url directly, and it should work. But there's an open
question of whether curl ought to handle this limited redirect case more
gracefully.
-Peff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git clone with basic auth in url directly returns authentication failure after 401 received under some git versions
2022-08-20 8:44 ` Jeff King
@ 2022-08-20 11:59 ` 王小建
2022-08-20 22:32 ` Daniel Stenberg
1 sibling, 0 replies; 9+ messages in thread
From: 王小建 @ 2022-08-20 11:59 UTC (permalink / raw)
To: Jeff King; +Cc: Daniel Stenberg, git
Thank you very much for your answer！
Now I have a clear picture of what has been bothering me for a day.
Indeed, use an https url directly, and it works well.
Now I'm going to look into curl.
Jeff King <peff@peff.net> 于2022年8月20日周六 16:44写道：
>
> On Sat, Aug 20, 2022 at 10:51:16AM +0800, 王小建 wrote:
>
> > What's different between what you expected and what actually happened?
> >
> > When I use git v2.36.2 (docker image is alpine/git:v2.36.2) to clone
> > with basic auth in url, when receiving the 401, it directly returns
> > authentication failure, even recv head has www-authenticate: Basic
> > realm=Restricted,
> > and no request is send again. I think it should send request with
> > authorization: Basic header after receive 401.
> > And use git v2.34.2 (docker image is alpine/git:v2.34.1) to clone it works well.
>
> I think the problem here is not the difference in Git versions, but
> rather in libcurl versions. I can reproduce your problem using the
> docker containers. But if I build locally, using the same version of
> curl, then I see the issue with both git versions.
>
> The problem is how curl handles cross-protocol redirects. From Git's
> perspective, we hand the credentials to libcurl, and ask it to fetch the
> requested URL, including following redirects. If it comes back with a
> 401, then we assume our credentials were bad.
>
> But what changed in curl is that it will now discard credentials during
> a redirect. And in your example, there's a redirect from http to https
> (uninteresting bits snipped from the output):
>
> > Info: Connected to xxx.xxx (xxx.xxx.xxx.xxx) port 80 (#0)
> > Send header: GET /xxx/xxx/info/refs?service=git-upload-pack HTTP/1.1
> > Recv header: HTTP/1.1 302 Found
> > Recv header: Location: https://xxx.xxx/xxx/xxx/info/refs?service=git-upload-pack
>
> In the older version, after the redirect we see a 401 and curl (not git)
> resends with the stored credentials.
>
> But in the newer version, we see this right after the redirect:
>
> > Info: Connection #0 to host xxx.xxx left intact
> > Info: Clear auth, redirects to port from 80 to 443
>
> So it is dropping the credential that Git gave it.
>
> The curl change seems to be from 620ea2141 (transfer: redirects to other
> protocols or ports clear auth, 2022-04-25). The goal is to avoid leaking
> credentials between ports: https://curl.se/docs/CVE-2022-27774.html
>
> So that makes sense, though I wonder if curl ought to make an exception
> for moving from 80 to 443 and http to https?
>
> I don't think there's otherwise much Git can do here. We thought we gave
> curl a username and password, but they weren't ultimately used. But Git
> won't reissue the request, because it assumes the auth was rejected.
>
> I guess we can ask curl if it saw a redirect, and assume if so that the
> auth was cleared. That feels a bit hacky. And it's subverting curl's
> attempt not to leak the credentials. In general, I'd like to defer as
> much as possible to curl's ideas of how to handle things, because
> they're much better at implementing http best practices than we are. :)
>
> Another option is to allow the user to set CURLOPT_UNRESTRICTED_AUTH,
> but that seems like a bad idea for the same reason.
>
> Hopefully that explains what's going on. The short answer for your case
> is: use an https url directly, and it should work. But there's an open
> question of whether curl ought to handle this limited redirect case more
> gracefully.
>
> -Peff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git clone with basic auth in url directly returns authentication failure after 401 received under some git versions
2022-08-20 8:44 ` Jeff King
2022-08-20 11:59 ` 王小建
@ 2022-08-20 22:32 ` Daniel Stenberg
2022-08-22 3:35 ` 王小建
2022-08-22 9:04 ` Jeff King
1 sibling, 2 replies; 9+ messages in thread
From: Daniel Stenberg @ 2022-08-20 22:32 UTC (permalink / raw)
To: Jeff King; +Cc: 王小建, git
On Sat, 20 Aug 2022, Jeff King wrote:
> The curl change seems to be from 620ea2141 (transfer: redirects to other
> protocols or ports clear auth, 2022-04-25). The goal is to avoid leaking
> credentials between ports: https://curl.se/docs/CVE-2022-27774.html
>
> So that makes sense, though I wonder if curl ought to make an exception
> for moving from 80 to 443 and http to https?
Nice research there Jeff, and yes this seems entirely correct.
We stopped curl from following such redirects because of the reasons stated in
the security advisory for that CVE. We quite simply realized that when curl
previously did that, it was actually doing more than what was documented and
what can be considered reasonably safe.
Following a redirect to another protocol and another port, even if it is still
on the same host name, might very well connect and use another server run by
someone else than the one reached first. We therefore now consider that second
host+port+protocol combo a different host.
Setting CURLOPT_UNRESTRICTED_AUTH is then the only way to make libcurl send
the credentials again after such a redirect.
I would not mind having a discussion in the curl project to see if we should
possibly consider adding a middle-ground where we allow sending credentials to
another port for the same host name, but I am personally NOT sold on the idea.
I think such redirects should rather be fixed and avoided - since I believe
users will not understand the security implications of doing them.
--
/ daniel.haxx.se
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git clone with basic auth in url directly returns authentication failure after 401 received under some git versions
2022-08-20 22:32 ` Daniel Stenberg
@ 2022-08-22 3:35 ` 王小建
2022-08-22 9:07 ` Jeff King
2022-08-22 9:04 ` Jeff King
1 sibling, 1 reply; 9+ messages in thread
From: 王小建 @ 2022-08-22 3:35 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: Jeff King, git, lj167647
Thank you very much for your answer！
And now I tried to add CURLOPT_UNRESTRICTED_AUTH but it failed.
Here are a few examples of what I've tried.
1. docker run -it -e CURLOPT_UNRESTRICTED_AUTH=1 5de1a96efc49 clone
http://xxx:xxx@xxx/xxx/xxx
2. echo CURLOPT_UNRESTRICTED_AUTH=1 > $HOME/.curlrc
I wonder if it's the way I'm trying to do it wrong
Daniel Stenberg <daniel@haxx.se> 于2022年8月21日周日 06:32写道：
>
> On Sat, 20 Aug 2022, Jeff King wrote:
>
> > The curl change seems to be from 620ea2141 (transfer: redirects to other
> > protocols or ports clear auth, 2022-04-25). The goal is to avoid leaking
> > credentials between ports: https://curl.se/docs/CVE-2022-27774.html
> >
> > So that makes sense, though I wonder if curl ought to make an exception
> > for moving from 80 to 443 and http to https?
>
> Nice research there Jeff, and yes this seems entirely correct.
>
> We stopped curl from following such redirects because of the reasons stated in
> the security advisory for that CVE. We quite simply realized that when curl
> previously did that, it was actually doing more than what was documented and
> what can be considered reasonably safe.
>
> Following a redirect to another protocol and another port, even if it is still
> on the same host name, might very well connect and use another server run by
> someone else than the one reached first. We therefore now consider that second
> host+port+protocol combo a different host.
>
> Setting CURLOPT_UNRESTRICTED_AUTH is then the only way to make libcurl send
> the credentials again after such a redirect.
>
> I would not mind having a discussion in the curl project to see if we should
> possibly consider adding a middle-ground where we allow sending credentials to
> another port for the same host name, but I am personally NOT sold on the idea.
> I think such redirects should rather be fixed and avoided - since I believe
> users will not understand the security implications of doing them.
>
> --
>
> / daniel.haxx.se
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git clone with basic auth in url directly returns authentication failure after 401 received under some git versions
2022-08-20 22:32 ` Daniel Stenberg
2022-08-22 3:35 ` 王小建
@ 2022-08-22 9:04 ` Jeff King
2022-08-22 22:11 ` brian m. carlson
1 sibling, 1 reply; 9+ messages in thread
From: Jeff King @ 2022-08-22 9:04 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: 王小建, git
On Sun, Aug 21, 2022 at 12:32:54AM +0200, Daniel Stenberg wrote:
> I would not mind having a discussion in the curl project to see if we should
> possibly consider adding a middle-ground where we allow sending credentials
> to another port for the same host name, but I am personally NOT sold on the
> idea. I think such redirects should rather be fixed and avoided - since I
> believe users will not understand the security implications of doing them.
I'm not 100% on it either. When it comes to security restrictions,
sometimes simple-and-stupid is the best way. I was literally thinking of
something as basic and restricted as:
if (from_port == 80 && to_port == 443 &&
from_protocol == HTTP && to_protocol == HTTPS)
/* ok, allow it */
just because https upgrade is such a common (and presumably harmless)
redirect. But possibly even that leaves wiggle room for bad things to
happen. I'm happy to defer to you and other curl folks there.
I think the worst thing about the user experience from Git here is that
it says "authentication failed", which is indistinguishable from a bogus
credential. We don't even mention the redirect, because we don't warn
about them unless the request ends up successful!
So I was thinking that curl could tell us "hey, I cleared the auth due
to a redirect" via some curl_easy_getinfo() call. But maybe just
noticing there was a redirect would be sufficient. This seems to work:
diff --git a/http.c b/http.c
index 5d0502f51f..0fe8a906e5 100644
--- a/http.c
+++ b/http.c
@@ -1934,7 +1934,7 @@ static int http_request_reauth(const char *url,
{
int ret = http_request(url, result, target, options);
- if (ret != HTTP_OK && ret != HTTP_REAUTH)
+ if (ret != HTTP_OK && ret != HTTP_REAUTH && ret != HTTP_NOAUTH)
return ret;
if (options && options->effective_url && options->base_url) {
diff --git a/remote-curl.c b/remote-curl.c
index b8758757ec..d462077a97 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -501,6 +501,12 @@ static struct discovery *discover_refs(const char *service, int for_push)
transport_anonymize_url(url.buf));
case HTTP_NOAUTH:
show_http_message(&type, &charset, &buffer);
+ if (LIBCURL_VERSION_NUM >= 0x075300 &&
+ strcmp(refs_url.buf, effective_url.buf)) {
+ char *u = transport_anonymize_url(url.buf);
+ warning(_("request redirected to %s"), u);
+ warning(_("authentication information may have been discarded"));
+ }
die(_("Authentication failed for '%s'"),
transport_anonymize_url(url.buf));
case HTTP_NOMATCHPUBLICKEY:
Though I wonder if there is a cleaner way to determine what happened
than string comparisons.
-Peff
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: git clone with basic auth in url directly returns authentication failure after 401 received under some git versions
2022-08-22 3:35 ` 王小建
@ 2022-08-22 9:07 ` Jeff King
0 siblings, 0 replies; 9+ messages in thread
From: Jeff King @ 2022-08-22 9:07 UTC (permalink / raw)
To: 王小建; +Cc: Daniel Stenberg, git, lj167647
On Mon, Aug 22, 2022 at 11:35:10AM +0800, 王小建 wrote:
> Thank you very much for your answer！
> And now I tried to add CURLOPT_UNRESTRICTED_AUTH but it failed.
> Here are a few examples of what I've tried.
> 1. docker run -it -e CURLOPT_UNRESTRICTED_AUTH=1 5de1a96efc49 clone
> http://xxx:xxx@xxx/xxx/xxx
> 2. echo CURLOPT_UNRESTRICTED_AUTH=1 > $HOME/.curlrc
> I wonder if it's the way I'm trying to do it wrong
That won't work. CURLOPT_UNRESTRICTED_AUTH isn't an environment
variable, but rather a flag that Git could pass to libcurl via
curl_easy_setopt(). So we'd probably wire it up in Git to a config
option. I'd prefer not to unless there is a compelling reason, though.
The documentation would have to come with a big warning/disclaimer,
which is a good sign that we may be better off without the option
entirely. :)
-Peff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git clone with basic auth in url directly returns authentication failure after 401 received under some git versions
2022-08-22 9:04 ` Jeff King
@ 2022-08-22 22:11 ` brian m. carlson
2022-08-23 20:16 ` Jeff King
0 siblings, 1 reply; 9+ messages in thread
From: brian m. carlson @ 2022-08-22 22:11 UTC (permalink / raw)
To: Jeff King; +Cc: Daniel Stenberg, 王小建, git
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
On 2022-08-22 at 09:04:34, Jeff King wrote:
> On Sun, Aug 21, 2022 at 12:32:54AM +0200, Daniel Stenberg wrote:
>
> > I would not mind having a discussion in the curl project to see if we should
> > possibly consider adding a middle-ground where we allow sending credentials
> > to another port for the same host name, but I am personally NOT sold on the
> > idea. I think such redirects should rather be fixed and avoided - since I
> > believe users will not understand the security implications of doing them.
>
> I'm not 100% on it either. When it comes to security restrictions,
> sometimes simple-and-stupid is the best way. I was literally thinking of
> something as basic and restricted as:
>
> if (from_port == 80 && to_port == 443 &&
> from_protocol == HTTP && to_protocol == HTTPS)
> /* ok, allow it */
>
> just because https upgrade is such a common (and presumably harmless)
> redirect. But possibly even that leaves wiggle room for bad things to
> happen. I'm happy to defer to you and other curl folks there.
I think it's actually better to fail in this case, and here's why. If
someone is using HTTP and getting redirected to HTTPS, there's no
security if an attacker intercepts the HTTP connection. Anyone who
knows how a captive portal works will recognize this immediately, and
it's why we have Strict Transport Security in browsers.
If we fail when a user redirects, then they'll fix their URL to use
HTTPS, at which point their connection is prevented from tampering
effectively forever. If we redirect, then when they make a connection,
they'll be vulnerable to tampering every time, possibly sending
credentials over the wire in plaintext or being redirected to a rogue
site.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git clone with basic auth in url directly returns authentication failure after 401 received under some git versions
2022-08-22 22:11 ` brian m. carlson
@ 2022-08-23 20:16 ` Jeff King
0 siblings, 0 replies; 9+ messages in thread
From: Jeff King @ 2022-08-23 20:16 UTC (permalink / raw)
To: brian m. carlson; +Cc: Daniel Stenberg, 王小建, git
On Mon, Aug 22, 2022 at 10:11:29PM +0000, brian m. carlson wrote:
> > I'm not 100% on it either. When it comes to security restrictions,
> > sometimes simple-and-stupid is the best way. I was literally thinking of
> > something as basic and restricted as:
> >
> > if (from_port == 80 && to_port == 443 &&
> > from_protocol == HTTP && to_protocol == HTTPS)
> > /* ok, allow it */
> >
> > just because https upgrade is such a common (and presumably harmless)
> > redirect. But possibly even that leaves wiggle room for bad things to
> > happen. I'm happy to defer to you and other curl folks there.
>
> I think it's actually better to fail in this case, and here's why. If
> someone is using HTTP and getting redirected to HTTPS, there's no
> security if an attacker intercepts the HTTP connection. Anyone who
> knows how a captive portal works will recognize this immediately, and
> it's why we have Strict Transport Security in browsers.
>
> If we fail when a user redirects, then they'll fix their URL to use
> HTTPS, at which point their connection is prevented from tampering
> effectively forever. If we redirect, then when they make a connection,
> they'll be vulnerable to tampering every time, possibly sending
> credentials over the wire in plaintext or being redirected to a rogue
> site.
I agree redirecting is less secure, but in this case the credentials are
cleared unless it's an http->https upgrade on the same hostname (not
shown in my example above is the implication that curl would still be
doing the hostname check).
We also follow redirects in general, so this is just about clearing
in-url credentials. We'll still prompt for credentials in the more usual
case, though we do properly say "password for $REDIRECTED_URL" when
doing so.
All that said, I agree that failing and asking the user to adjust their
URL is a fine outcome, as long as we do that. The problem now is just
that Git's output is misleading at best. The diff I showed earlier would
help with that. I think it could use a little polish, but I'll see if I
can do that in the next few days.
-Peff
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-08-23 20:36 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-20 2:51 git clone with basic auth in url directly returns authentication failure after 401 received under some git versions 王小建
2022-08-20 8:44 ` Jeff King
2022-08-20 11:59 ` 王小建
2022-08-20 22:32 ` Daniel Stenberg
2022-08-22 3:35 ` 王小建
2022-08-22 9:07 ` Jeff King
2022-08-22 9:04 ` Jeff King
2022-08-22 22:11 ` brian m. carlson
2022-08-23 20:16 ` Jeff King
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).