Hi Norman,
The enhancement request has been moved to JDK and can be referred at :
https://bugs.openjdk.java.net/browse/JDK-8210843 .
Thanks,
Pallavi Sonal
-----------------------------------
Date: Mon, 17 Sep 2018 19:11:10 +0200
From: Norman Maurer <norman.mau...@googlemail.com>
To: Xuelei Fan <xuelei....@oracle.com>
Cc: security-dev@openjdk.java.net
Subject: Re: Expose SSLContextImpl#AbstractTrustManagerWrapper so it
can be used with custom SSLEngine / SSLContextSPI implementations as
well
Message-ID: <87281e2b-caa4-49de-86ec-eb1eb878d...@googlemail.com>
Content-Type: text/plain; charset="us-ascii"
Done..
ID: 9057278
Thanks
Norman
> On 17. Sep 2018, at 18:51, Xuelei Fan <xuelei....@oracle.com> wrote:
>
> Hi Norman,
>
> Please file an issue for the tracking.
>
> Thanks,
> Xuelei
>
> On 9/17/2018 5:57 AM, Norman Maurer wrote:
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.openjdk.java.net/pipermail/security-dev/attachments/20180917/673b80f0/attachment-0001.html>
