[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