Skip to content

fix(auth): pass an explicit protocol to ssl.SSLContext() in tests - #18187

Open
skippdot wants to merge 1 commit into
googleapis:mainfrom
skippdot:auth-sslcontext-protocol
Open

fix(auth): pass an explicit protocol to ssl.SSLContext() in tests#18187
skippdot wants to merge 1 commit into
googleapis:mainfrom
skippdot:auth-sslcontext-protocol

Conversation

@skippdot

Copy link
Copy Markdown
Contributor

Fixes #17760

Constructing ssl.SSLContext() without a protocol argument is deprecated since Python 3.10. tests/transport/test__custom_tls_signer.py does this ten times, so every run of the module emits 20 DeprecationWarnings (two per call site on 3.14).

Change

Replace each bare ssl.SSLContext() with ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT). One file, +10/−10.

Why PROTOCOL_TLS_CLIENT is the right protocol

  • It is what the library actually receives in production: transport/requests.py and transport/urllib3.py obtain their contexts from urllib3.util.ssl_.create_urllib3_context(), which builds them with PROTOCOL_TLS_CLIENT. The tests now exercise attach_to_ssl_context() with the same kind of context the real code passes in.
  • The tests never inspect check_hostname, verify_mode or protocol; they only hand the context to mocked native libraries via _cast_ssl_ctx_to_void_p_stdlib. So the stricter defaults of a client context (check_hostname=True, verify_mode=CERT_REQUIRED) do not affect any assertion.

Verification

  • tests/transport/test__custom_tls_signer.py on Python 3.10 and 3.14: 22 passed; without protocol warnings 20 → 0.
  • Full google-auth unit suite on 3.10 and 3.14: all passing apart from two pre-existing test_id_token failures caused by a missing optional jwt module in the local environment (identical on an unmodified main).
  • black --check and flake8 --import-order-style=google clean.

- Replace the ten bare `ssl.SSLContext()` calls in
  tests/transport/test__custom_tls_signer.py with
  `ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)`
- Constructing an SSLContext without a protocol argument is deprecated since
  Python 3.10 and emits a DeprecationWarning on every run of this module
- PROTOCOL_TLS_CLIENT matches what the library receives in production, where
  contexts come from `urllib3.util.ssl_.create_urllib3_context()`; the tests
  only hand the context to mocked native libraries and never inspect its
  verification settings, so no assertion depends on the bare-context defaults

Fixes googleapis#17760
@skippdot
skippdot requested review from a team as code owners August 21, 2026 09:11

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates several test cases in test__custom_tls_signer.py to instantiate ssl.SSLContext with ssl.PROTOCOL_TLS_CLIENT instead of using the default constructor. There are no review comments to evaluate, and I have no feedback to provide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

google-auth: Fix Python 3.13 deprecation warnings for ssl.SSLContext in test suite

2 participants