curl Issue Reports Git Crash After HTTPS Proxy 407 Retry on OpenWrt

A curl issue opened on September 13, 2026 reports that git-remote-https reproducibly terminated with signal 11 after an authenticated HTTPS proxy returned 407 Proxy Authentication Required in one OpenWrt-based environment. According to the report, forcing Basic proxy authentication preemptively avoided the challenge-and-retry path and allowed the Git request to complete.

The issue is open and carries an “outdated” label. There is no maintainer-confirmed root cause, patch or general regression conclusion. The evidence applies to the reporter’s specific package and platform combination, not to every curl, Git, OpenWrt or proxy deployment.

The reported environment

The report identifies iStoreOS 24.10.8 on AArch64, Git 2.50.1, curl and libcurl 8.19.0 packages, OpenSSL 3.0.21 and nghttp2 1.63.0. The proxy was an HTTPS CONNECT gateway requiring HTTP Basic authentication, and the target used GitHub HTTPS smart HTTP.

Trace output reportedly showed an unauthenticated CONNECT, a 407 response advertising Basic, a reconnect attempt and then the helper crash before the second authenticated CONNECT was emitted.

Source note: curl project issue “git-remote-https segfaults after HTTPS proxy 407 challenge with libcurl 8.19.0 on OpenWrt; preemptive Basic works,” opened September 13, 2026; open at review time and labeled TLS, connecting and proxies, and outdated.

Why this is not a basic connectivity result

The reporter described three useful comparisons:

• Without credentials, Git received the expected 407 and exited normally rather than crashing.
• With Basic proxy authentication forced preemptively, the Git operation completed.
• Plain curl used the same authenticated HTTPS proxy successfully.

These observations narrow the reported failure to the challenge, reconnect or authentication-retry path exercised by that Git and libcurl combination. They do not prove which component is defective, and they do not show that the proxy itself is unavailable.

Operators should preserve this distinction. A gateway can be reachable, TLS can succeed and credentials can be valid while one client integration fails during a 407 transition.

Reproduce with a controlled A/B matrix

Use a repository and proxy account you are authorized to test. Keep the target, gateway, client host, credentials and network path fixed, then compare:

1. Git without proxy credentials, expecting a clean 407 failure.
2. Git with normal challenge-based authentication.
3. Git with the approved authentication method explicitly selected.
4. Standalone curl through the same gateway.
5. A second Git and libcurl package build on the same device.
6. The same package build on a reference operating system, if available.

Do not place passwords on the command line or paste them into traces. Use the operating system’s approved credential mechanism and redact proxy authorization headers, user names, gateway addresses, repository tokens and private paths before sharing evidence.

Scope any workaround narrowly

The reporter’s preemptive Basic configuration is an observation from one environment, not a universal recommendation. Before adopting it, confirm that Basic authentication is approved for the proxy-side TLS boundary and that credentials are never sent over an unprotected connection.

Prefer a repository- or host-scoped Git setting over a global change. Record the original configuration, test a rollback and verify that unrelated destinations do not inherit the change. A successful workaround should not end the investigation; it may hide a crash path that returns during an image or package update.

For a systematic view of 407 responses, use the curl proxy authentication troubleshooting guide. If authentication succeeds inconsistently across clients, also run the proxy credential encoding validation.

Test current supported packages

Because the issue is labeled outdated, reproduce on the newest supported Git, curl and libcurl packages available for the device before escalating. Do not replace production binaries blindly. Build a test image, preserve the same proxy and repository matrix, and compare the first failing phase.

Record Git version, curl version, libcurl feature list, TLS backend, CPU architecture, C library, HTTP/2 library, package source and exact proxy scheme. Git may load a different libcurl build from the standalone curl binary, so “curl works” does not guarantee both programs use identical libraries or options.

The HTTPS proxy TLS and cipher compatibility test can verify that both the proxy-side and destination-side TLS boundaries meet policy before attention shifts to authentication retry behavior.

Capture a safe crash package

Collect only what is necessary:

• Sanitized Git and curl trace from the failing boundary.
• Exit signal and a symbolized backtrace when policy permits.
• Package versions and dependency linkage.
• The expected 407 headers with credentials removed.
• Result of every A/B case and its timestamp.
• Whether the second authenticated CONNECT was sent.
• Whether the crash survives a clean process and device restart.

Do not publish core dumps until they have been reviewed for credentials, URLs, environment variables, memory contents and customer data. Store diagnostics under access control and define a retention period.

Operational response checklist

• Stop automatic retries if the helper process repeatedly crashes.
• Confirm the proxy works with an independent approved client.
• Separate proxy TLS, 407 authentication and destination TLS outcomes.
• Reproduce with challenge-based and explicitly selected authentication.
• Verify the actual libcurl loaded by Git.
• Test a current supported package set in staging.
• Scope any temporary configuration to the intended host or repository.
• Redact traces and inspect crash artifacts before sharing.
• Keep the original failure visible in metrics rather than counting workaround retries as first-attempt success.

FAQ

Does this issue prove curl 8.19.0 crashes with every authenticated proxy?

No. It is one open report for a specific OpenWrt-based package combination. No general root cause has been confirmed.

Does a successful standalone curl request clear the proxy?

It confirms that one client path can use the gateway. Git may use different libcurl linkage, options and retry behavior, so the comparison narrows the fault domain but does not settle it.

Should teams force Basic proxy authentication globally?

No. Treat that as a narrowly tested temporary option only when approved. Scope it to the necessary destination, require proxy-side TLS and keep a rollback plan.

Compliance note

Test only proxy accounts, repositories and systems you own or are authorized to assess. Protect credentials and crash artifacts, respect provider and destination limits, and do not weaken TLS verification to make a test pass.