Should I open an issue somewhere to keep track of it or will you take care of it ?
Bye Norman > On 11. Sep 2018, at 17:01, Norman Maurer <norman.mau...@googlemail.com> wrote: > > This sounds great. > > I have no idea how many people still use X509TrustManager, sorry. > > It may be a good idea to add something to the java docs to tell people to > prefer X509ExtendedTrustManager as well. > > Bye > Norman > >> Am 11.09.2018 um 16:44 schrieb Xuelei Fan <xuelei....@oracle.com>: >> >> Hi Norman, >> >> >> It may be doable by adding a delegation mode to public TrustManagerFactory: >> TrustManagerFactory.init(X509TrustManager proxy) >> >> However, the X509ExtendedTrustManager should be recommended for now since >> its introducing in JDK 7. >> >> Do you know how many users are still using the X509TrustManager >> implementation? >> >> Thanks, >> Xuelei >> >>> On 9/11/2018 3:32 AM, Norman Maurer wrote: >>> Hi all, >>> Would it be possible to consider exposing >>> SSLContextImpl#AbstractTrustManagerWrapper somehow so it would be possible >>> to reuse it when a custom SSLEngine / SSLContextSpi is provided ? >>> I am asking because it provides really nice extra functionality by wrapping >>> for X509TrustManager implementation and do extra hostname checks etc. At >>> the moment we can not make use of this extra functionality in netty with >>> our custom SSLEngine implementation as there is no way to access this. >>> Which means depending on if the user use our implementation or the default >>> implementation the behaviour if quite different when using a >>> X509TrustManager in the sense that when using the default implementation a >>> lot of extra checks are done. >>> As the extra checks done in AbstractTrustManagerWrapper is not really >>> depending on the underlying SSLContextSpi implementation (at least as far >>> as I was able to understand it so far) it would be nice to be able to make >>> use of it. >>> Bye >>> Norman
