Code Review Request, JDK-8207029 Unable to use custom SSLEngine with default TrustManagerFactory after updating to JDK 11 b21

[Xuelei Fan]

On 7/12/2018 5:06 PM, Bradford Wetmore wrote:
> The code itself looks good, but I didn't see a regression tests.  Is 
> this what JDK-8207174 will be for?
> 
No, I did not have a regression test in this update.  I asked the bug 
reporter helped for the testing, and passed.  However, we definitely 
need a regression test as it is likely to happen again in the future. 
JDK-8207174 is used for the following up test development.

Thanks,
Xuelei

> On 7/11/2018 11:53 PM, Alan Bateman wrote:
>> On 12/07/2018 05:47, Xuelei Fan wrote:
> 
>>> It's an interesting user case of the TrustManagerFactory and 
>>> KeyManagerFactory.  The KeyManager or TrustManager implementation may 
>>> be not implemented in the same provider as SSLSocket/SSLEngine.
>>>
>>> See also 
>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017536.html. 
>>>
>> Xuelei - is there follow-up work to develop some tests that use custom 
>> KeyManager or TrustManager implementations that are in different 
>> providers to the SSLEngine. I realize not many will do that but it 
>> seems easy to break these type of scenarios if we don't have tests.
> 
> If I understand your question correctly, custom KM/TM are quite common. 
> I routinely write custom impls to wrap functionality around the behavior 
> of the stock TM/KM.  e.g. outputting debug information.
> 
> class MyTM extends X509TrustManager {
>      private final X509TrustManager tm;
>      MyTM(X509TrustManager tm) {
>          theTM = tm;
>      }
>      checkTrusted(args)
>          System.out.println(args);
>          tm.checkTrusts(args)
>      }
> }
> 
> Brad
>