镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

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

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

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.
@AgraVator
AgraVator marked this pull request as ready for review September 23, 2026 09:33
@AgraVator AgraVator closed this Oct 14, 2026
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