You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to #656 and grpc/grpc-java#6684 (comment), Conscrypt uses Platform's default HostNameVerifier if not explicitly set, which in OpenJDK it is a deny-all implementation. This is problematic as mentioned in #656 (comment) and letting users implement a custom HostNameVerifier is also infeasible (discussed in grpc/grpc-java#6684 (comment)). While there is an option to work around this, which is not to use Conscrypt's TrustManagerImpl. Conscrypt provides API ProviderBuilder#provideTrustManager(boolean provide) to do so. However, its default value of true in OpenJDK is awkward, given that it's default HostNameVerifier is unable to be used. Should it be changed to false?
According to #656 and grpc/grpc-java#6684 (comment), Conscrypt uses Platform's default
HostNameVerifierif not explicitly set, which in OpenJDK it is a deny-all implementation. This is problematic as mentioned in #656 (comment) and letting users implement a customHostNameVerifieris also infeasible (discussed in grpc/grpc-java#6684 (comment)). While there is an option to work around this, which is not to use Conscrypt'sTrustManagerImpl. Conscrypt provides APIProviderBuilder#provideTrustManager(boolean provide)to do so. However, its default value oftruein OpenJDK is awkward, given that it's defaultHostNameVerifieris unable to be used. Should it be changed tofalse?/cc @ejona86