git-remote-https not sending BASIC auth to a proxy, when given HTTP_PROXY env vars containing a username:password pair and challenged with a 407.

Good afternoon:

I'm using git behind a authenticated HTTP proxy which uses basic auth.
I have the common HTTP[S]_PROXY ENV vars set properly with a standard
`http://user:pass@host` URL for the proxy.  When I `git clone` the clone
fails immediately with a `Proxy CONNECT` aborted error I've tracked
down to git-remote-https:

$ echo -e "capabilities\nlist" | GIT_CURL_VERBOSE=1 GIT_TRACE=1 /usr/lib/git-core/git-remote-https origin https://github.com/terraform-aws-modules/terraform-aws-eks.git
stateless-connect
fetch
get
option
push
check-connectivity
object-format

17:39:50.167960 http.c:913              == Info: Couldn't find host github.com in the .netrc file; using defaults
17:39:50.168253 http.c:913              == Info:   Trying 192.168.128.1:3128...
17:39:50.172400 http.c:913              == Info: CONNECT tunnel: HTTP/1.1 negotiated
17:39:50.172424 http.c:913              == Info: allocate connect buffer
17:39:50.172549 http.c:913              == Info: Establish HTTP proxy tunnel to github.com:443
17:39:50.172799 http.c:860              => Send header, 0000000111 bytes (0x0000006f)
17:39:50.172809 http.c:872              => Send header: CONNECT github.com:443 HTTP/1.1
17:39:50.172812 http.c:872              => Send header: Host: github.com:443
17:39:50.172813 http.c:872              => Send header: User-Agent: git/2.47.3
17:39:50.172815 http.c:872              => Send header: Proxy-Connection: Keep-Alive
17:39:50.172816 http.c:872              => Send header:
17:39:52.403232 http.c:860              <= Recv header, 0000000044 bytes (0x0000002c)
17:39:52.403249 http.c:872              <= Recv header: HTTP/1.1 407 Proxy Authentication Required
17:39:52.403265 http.c:860              <= Recv header, 0000000020 bytes (0x00000014)
17:39:52.403267 http.c:872              <= Recv header: Server: squid/6.13
17:39:52.403277 http.c:860              <= Recv header, 0000000019 bytes (0x00000013)
17:39:52.403278 http.c:872              <= Recv header: Mime-Version: 1.0
17:39:52.403694 http.c:860              <= Recv header, 0000000037 bytes (0x00000025)
17:39:52.403704 http.c:872              <= Recv header: Date: Tue, 11 Aug 2026 21:39:52 GMT
17:39:52.403724 http.c:860              <= Recv header, 0000000039 bytes (0x00000027)
17:39:52.403726 http.c:872              <= Recv header: Content-Type: text/html;charset=utf-8
17:39:52.403736 http.c:860              <= Recv header, 0000000022 bytes (0x00000016)
17:39:52.403738 http.c:872              <= Recv header: Content-Length: 1325
17:39:52.403755 http.c:860              <= Recv header, 0000000042 bytes (0x0000002a)
17:39:52.403756 http.c:872              <= Recv header: X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
17:39:52.403766 http.c:860              <= Recv header, 0000000023 bytes (0x00000017)
17:39:52.403768 http.c:872              <= Recv header: Vary: Accept-Language
17:39:52.403777 http.c:860              <= Recv header, 0000000022 bytes (0x00000016)
17:39:52.403779 http.c:872              <= Recv header: Content-Language: en
17:39:52.403804 http.c:860              <= Recv header, 0000000066 bytes (0x00000042)
17:39:52.403806 http.c:872              <= Recv header: Proxy-Authenticate: Basic realm="<Redacted>"
<Snip identifying headers>
17:39:52.403879 http.c:860              <= Recv header, 0000000019 bytes (0x00000013)
17:39:52.403881 http.c:872              <= Recv header: Connection: close
17:39:52.403886 http.c:860              <= Recv header, 0000000002 bytes (0x00000002)
17:39:52.403888 http.c:872              <= Recv header:
17:39:52.403891 http.c:913              == Info: Ignore 1325 bytes of response-body
17:39:52.403894 http.c:913              == Info: Proxy CONNECT aborted
17:39:52.403904 http.c:913              == Info: closing connection #0
fatal: unable to access 'https://github.com/terraform-aws-modules/terraform-aws-eks.git/': Proxy CONNECT aborted

As I understand it not sending credentials initially is expected.
However, my understanding is it should retry with auth when it receives
the 407, which it is not doing.  I'm unable to determine if this is
expected or a bug.

If I set GIT_HTTP_PROXY_AUTHMETHOD=basic it works as expected:

$ echo -e "capabilities\nlist" | GIT_CURL_VERBOSE=1 GIT_TRACE=1 GIT_HTTP_PROXY_AUTHMETHOD=basic /usr/lib/git-core/git-remote-https origin https://github.com/terraform-aws-modules/terraform-aws-eks.git
stateless-connect
fetch
get
option
push
check-connectivity
object-format

17:42:30.323214 http.c:913              == Info: Couldn't find host github.com in the .netrc file; using defaults
17:42:30.323494 http.c:913              == Info:   Trying 192.168.128.1:3128...
17:42:30.324493 http.c:913              == Info: CONNECT tunnel: HTTP/1.1 negotiated
17:42:30.324595 http.c:913              == Info: allocate connect buffer
17:42:30.324657 http.c:913              == Info: Proxy auth using Basic with user '<redacted>'
17:42:30.324683 http.c:913              == Info: Establish HTTP proxy tunnel to github.com:443
17:42:30.324763 http.c:860              => Send header, 0000000172 bytes (0x000000ac)
17:42:30.324787 http.c:872              => Send header: CONNECT github.com:443 HTTP/1.1
17:42:30.324797 http.c:872              => Send header: Host: github.com:443
17:42:30.324802 http.c:872              => Send header: Proxy-Authorization: Basic <redacted>
17:42:30.324803 http.c:872              => Send header: User-Agent: git/2.47.3
17:42:30.324814 http.c:872              => Send header: Proxy-Connection: Keep-Alive
17:42:30.324820 http.c:872              => Send header:
17:42:32.440551 http.c:860              <= Recv header, 0000000037 bytes (0x00000025)
17:42:32.440578 http.c:872              <= Recv header: HTTP/1.1 200 Connection established
17:42:32.440601 http.c:860              <= Recv header, 0000000002 bytes (0x00000002)
17:42:32.440612 http.c:872              <= Recv header:
17:42:32.440620 http.c:913              == Info: CONNECT phase completed
17:42:32.440624 http.c:913              == Info: CONNECT tunnel established, response 200
17:42:32.440888 http.c:913              == Info: GnuTLS priority: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0
17:42:32.440962 http.c:913              == Info: ALPN: curl offers h2,http/1.1
17:42:32.454273 http.c:913              == Info: found 151 certificates in /etc/ssl/certs/ca-certificates.crt
17:42:32.492571 http.c:913              == Info: found 453 certificates in /etc/ssl/certs
17:42:32.588790 http.c:913              == Info: SSL connection using TLS1.3 / ECDHE_RSA_AES_128_GCM_SHA256
17:42:32.592774 http.c:913              == Info:   server certificate verification OK
17:42:32.592859 http.c:913              == Info:   server certificate status verification SKIPPED
17:42:32.596435 http.c:913              == Info:   common name: github.com (matched)
17:42:32.596453 http.c:913              == Info:   server certificate expiration date OK
17:42:32.596460 http.c:913              == Info:   server certificate activation date OK
17:42:32.596503 http.c:913              == Info:   certificate public key: EC/ECDSA
17:42:32.596514 http.c:913              == Info:   certificate version: #3
17:42:32.596543 http.c:913              == Info:   subject: CN=github.com
17:42:32.596592 http.c:913              == Info:   start date: Fri, 03 Jul 2026 00:00:00 GMT
17:42:32.596611 http.c:913              == Info:   expire date: Wed, 30 Sep 2026 23:59:59 GMT
17:42:32.596633 http.c:913              == Info:   issuer: C=GB,O=Sectigo Limited,CN=Sectigo Public Server Authentication CA DV E36
17:42:32.596738 http.c:913              == Info: ALPN: server accepted h2
17:42:32.596925 http.c:913              == Info: Connected to 192.168.128.1 (192.168.128.1) port 3128
17:42:32.596945 http.c:913              == Info: using HTTP/2
17:42:32.597008 http.c:913              == Info: [HTTP/2] [1] OPENED stream for https://github.com/terraform-aws-modules/terraform-aws-eks.git/info/refs?service=git-upload-pack
<Snip remaining successful log lines>

So, is the initial connection not using auth expected?
Is it not trying auth on 407 also expected?  If not, is this a known bug?

--Tom Noonan II