[8u] RFR: 8256682: JDK-8202343 is incomplete

Severin Gehwolf sgehwolf at redhat.com
Thu Feb 11 17:21:10 UTC 2021


Hi Andrew,

On Thu, 2021-02-11 at 05:05 +0000, Andrew Hughes wrote:
> On 10:00 Wed 10 Feb     , Alexey Bakhtin wrote:
> > Hi,
> > Please review the backport of JDK-8256682 to 8u:
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8256682
> > Original change: https://github.com/openjdk/jdk/commit/b9db002f
> > 8u webrev: http://cr.openjdk.java.net/~abakhtin/8256682/webrev.v0/
> 
> > Original fix does not apply cleanly because of
> > NullHostnameCheck.java test was not updated as part of JDK-8202343
> > 8u backport [1]. This patch includes missed parts of the original
> > fix for JDK-8202343 [2].
> > 
> 
> This appears to have been deliberate:
> 
> " * test/sun/security/util/HostnameMatcher/NullHostnameCheck.java
>   * JDK-8228967 is not in 8u so there is a context conflict while adding
> the import. JDK-8228967 also causes a context conflict when adding the
> line that re-enables TLS 1.0 and 1.1. However, these changes are not
> needed in 8u as the test works for TLS 1.2 only (so there is no need to
> re-enable TLS 1.0 and 1.1). If JDK-8228967 is ever backported to 8u,
> this test will fail until TLS 1.0 and 1.1 are enabled." [0]

Coming back to this, I'm not 100% sure what Martin meant with this.
Status quo in 8u-dev is that NullHostnameCheck.java fails for runs with
'TLSv1' and 'TLSv1.1', passes with 'TLSv1.2' and 'TLSv1.3'.

I believe it's because this reasoning was *before* JDK-8234728 got
backported. With that backported it now also runs for TLSv1, TLSv1.1
and TLSv1.3.

> I must admit it doesn't make sense to me why it would be TLS 1.2 only,
> but have runs that pass a TLSv1, TLSv1.1 and TLSv1.3 argument to it.

See above.

> Are you seeing test failures due to the lack of this block? It would
> be good to know why we need to revisit the original decision on
> including this block.

I can confirm the proposed patch fixes the test. As to the reason, the
referenced mailing list thread's argument was prior Martin's decision
to backport JDK-8234728[i]. That backport was done rendering this
(original) argument wrong. Martin, please correct me if I'm wrong here.

This seems good to go.

Thanks,
Severin

[i] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013353.html


> [1]    
> https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/f2f0ceec19fb
> [2] https://github.com/openjdk/jdk/commit/3a4b90f0
> 
> Regards
> Alexey
> 

[0]    https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013341.html

Thanks,




More information about the jdk8u-dev mailing list