ECP offload support broke in latest release

[nolanleastin]

Determine this is the right repository

• I determined this is the correct repository in which to report this bug.

Summary of the issue

Context
I am trying to use gcloud with ECP offload engine, on a macbook.

I am fairly certain this was caused by 247e2ad

CLOUDSDK_CONTEXT_AWARE_USE_ECP_HTTP_PROXY=false gcloud storage ls

Expected Behavior:
I expect that gcloud will correctly load SSL context with pyOpenSSL

Actual Behavior:

Instead it fails:

ERROR: (gcloud.storage.ls) There was a problem refreshing your current auth tokens: HTTPSConnectionPool(host='oauth2.mtls.googleapis.com', port=443): Max retries exceeded with url: /token (Caused by SSLError(SSLError(1, '[EVP: UNKNOWN_MAX_SIZE] unknown max size (_ssl.c:2711)')))

API client name and version

gcloud version
Google Cloud SDK 576.0.0

Reproduction steps

1. Make sure you're running gcloud version 576+
2. Make sure you're running on a mac.
3. Run the followign command:CLOUDSDK_CONTEXT_AWARE_USE_ECP_HTTP_PROXY=false gcloud storage ls

Reproduction steps: supporting files

[agrawalradhika-cell]

can help in rootcausing -

ECP tests are failing because of a highly fragile memory hack introduced to replace pyOpenSSL with the standard Python ssl library for mTLS connections.

Here is the exact breakdown of what is breaking the tests:

1. Removal of pyOpenSSL Injection

In the PR, the dependency on pyOpenSSL is removed (source). Specifically, in google/auth/transport/requests.py, the code removes the call to urllib3.contrib.pyopenssl.inject_into_urllib3(). This switches the underlying TLS context for the Google Cloud SDK's mTLS adapters from a PyOpenSSL context to the standard library's ssl.SSLContext.

2. Fragile Pointer Extraction Hack

Google Cloud CLI uses a C++ offload library (libtls_offload.dylib) to securely sign mTLS payloads using Enterprise Certificate Providers (ECP). To pass the OpenSSL context to this C++ library, the Python code needs the raw SSL_CTX* memory pointer.

Since the standard ssl module doesn't expose this pointer natively (unlike pyOpenSSL), the PR authors introduced a dangerous memory layout hack in google/auth/transport/_custom_tls_signer.py:

def _cast_ssl_ctx_to_void_p_stdlib(context):
    ...
    offset = sys.getsizeof(object())
    return ctypes.c_void_p.from_address(id(context) + offset)

This assumes that the SSL_CTX* pointer is always located exactly 16 bytes (the size of PyObject_HEAD) after the start of the ssl.SSLContext object in memory.

3. OpenSSL ABI Mismatch / Memory Corruption

When this guessed pointer is passed to the C++ offload library via ConfigureSslContext, the tests fail. The Sponge logs reveal the exact point of failure within the C++ library:

tls_offload.cpp: Creating engine.......
created custom_key at: 0x600000c9aa90
tls_offload.cpp: failed to call SSL_CTX_set1_sigalgs_list....
deleting custom_key at: 0x600000c9aa90

The OpenSSL function SSL_CTX_set1_sigalgs_list is failing gracefully (source). This happens for one of two reasons:

1. Memory Layout Changes: On the macOS test environment running Python 3.14, the memory layout of ssl.SSLContext might differ, causing from_address() to read a garbage pointer rather than a valid OpenSSL structure.
2. ABI Incompatibility: Python's built-in ssl module is dynamically linked against OpenSSL 3.0.20, while the libtls_offload.dylib shipped with the SDK might be compiled against a different version of OpenSSL (like BoringSSL or OpenSSL 1.1.1). Passing an SSL_CTX struct allocated by one version of OpenSSL into functions of another version causes a structural mismatch, failing internal validations.

4. The Resulting Crash

Because the offload library fails to attach to the SSL context, the Python code catches the False return value and raises an exception (source). This bubbles up as google.auth.exceptions.MutualTLSChannelError during the auth token refresh phase, causing standard CLI commands like gcloud pubsub topics list and gcloud compute instances list to instantly crash.