Skip to content

okhttp: avoid sharing KeyManager/TrustManager across threads in mTLS test - #13062

Draft
AgraVator wants to merge 1 commit into
grpc:masterfrom
AgraVator:fix-tsan-okhttp-mtls
Draft

AgraVator wants to merge 1 commit into
grpc:masterfrom
AgraVator:fix-tsan-okhttp-mtls

Conversation

@AgraVator

Copy link
Copy Markdown
Contributor

In OkHttpChannelBuilderTest.sslSocketFactoryFrom_tls_mtls(), passing the same KeyManager[] and TrustManager[] instances to both the server SSLContext and client TlsChannelCredentials causes concurrent client and server TLS handshake threads to share underlying X509Certificate/X500Name instances. Under TSAN, this triggers a data race on DerValue.getDataBytes() inside X500Name.getRFC2253CanonicalName().

Create separate KeyManager[] and TrustManager[] instances for the server and client contexts.

…test

In OkHttpChannelBuilderTest.sslSocketFactoryFrom_tls_mtls(), passing the same KeyManager[] and TrustManager[] instances to both the server SSLContext and client TlsChannelCredentials causes concurrent client and server TLS handshake threads to share underlying X509Certificate/X500Name instances. Under TSAN, this triggers a data race on DerValue.getDataBytes() inside X500Name.getRFC2253CanonicalName().

Create separate KeyManager[] and TrustManager[] instances for the server and client contexts.
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.

1 participant