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

Alexey Bakhtin alexey at azul.com
Thu Feb 11 09:15:27 UTC 2021


Hi Andrew,

Original test fails with :
“javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)”
It happens for TLSv protocol version (as defined in the @run section). So, the test is not limited to TLS 1.2 protocol only

The test passed with suggested fix.

I have reuploaded the jdk.changeset to the same place. Not sure, Why it was truncated before.

Regards
Alexey

> On 11 Feb 2021, at 08:05, Andrew Hughes <gnu.andrew at redhat.com> 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/
>> 
> 
> 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



More information about the jdk8u-dev mailing list