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

[Andrew Hughes]

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/
>

There seems to be an issue with this webrev.

https://cr.openjdk.java.net/~abakhtin/8256682/webrev.v0/jdk.changeset just has a header and no body.

> 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]

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.

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.

> [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,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222