[8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3

[Alexey Bakhtin]

Hello Martin,

You are right. We have two options:
1. backport JDK-8038893 to all packages
2. revert JDK-8038893 from X509TrustManagerImpl

I decided to backport JDK-803889 because of :
1. I decided this functionality valuable for server certificate validation
2. Without JDK-8038893 X509TrustManagerImpl should be significantly modified.
It could causes issues in subsequent backports from JDK11 to JDK8.

You are right, the first patch includes unnecessary changes from 8201815 and
does not include required changes in the SocketPermission class.

I’ve fixed it.
Please verify updated webrev at:
http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245472/webrev.v1/

If you think this functionality still should be reverted and backported separately - it’s OK, I’ll do it

Regards
Alexey

> On 3 Jun 2020, at 22:11, Martin Balao <mbalao at redhat.com> wrote:
> 
> On 5/21/20 10:54 AM, Alexey Bakhtin wrote:
>> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u
> 
> Hi,
> 
> I've some concerns regarding this proposal.
> 
> My understanding is that the need for a JDK-8 backport of 8038893
> derives -originally- from the fact that the file
> sun/security/ssl/X509TrustManagerImpl.java (imported to JDK-8 by 'file
> replacement') includes some changes from it. So this crosses the
> sun/security/ssl boundary and has to be handled either by removing
> 8038893 traces from X509TrustManagerImpl.java or backporting it fully.
> 
> You've taken the decision of backporting 8038893 instead of removing it
> from X509TrustManagerImpl.java. What are the reasons behind that? And
> what would be the cons of the opposite approach? I'm still trying to
> understand that but your input would be appreciated.
> 
> I don't want to get into the patch specifics before being clear on the
> previous. However, at first glance, looks to me that the patch is taking
> changes from 8201815 and omitting changes in 8038893. This leads to the
> existence of two RegisteredDomain.java files in JDK-8. This may not be a
> problem on its own but reveals that there can be unintended and
> overlooked consequences. Given that we are out of sun/security/ssl, we
> would probably want full and independent backports if we decide to go
> that way.
> 
> Thanks,
> Martin.-
>