OpenJDK11u: Backward incompatible behavior
Xuelei Fan
xuelei.fan at oracle.com
Tue Feb 25 16:42:55 UTC 2020
> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/
Maybe, the getSession() could throw InterruptedIOException as well.
I may try to catch the InterruptedIOException, rather than handle it in
the IOException catching block.
Thanks,
Xuelei
On 2/24/2020 11:04 AM, Alexey Bakhtin wrote:
> Hi Xuelei,
>
> Thank you. It would be glad if you can review this fix.
> The patch almost cleanly applied to JDK15.
> Also, As Kumar mentioned, the patch does not include regression test.
> I’m going to add regression test and patch for JDK15 tomorrow.
>
> Thank you.
> Alexey
>
>> On 24 Feb 2020, at 21:41, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> Hi Alexey,
>>
>> Thanks for working on this issue. Do you plan to fix it for JDK 15, the current JDK reposiroty?
>>
>> I need more time for evaluate the fix. For example, I'm not sure if we could always throw InterruptedIOException to applications, even for getSession().
>>
>> Regards,
>> Xuelei
>>
>> On 2/24/2020 7:58 AM, Alexey Bakhtin wrote:
>>> Hello,
>>> I have been working on this issue for some time already.
>>> The patch below adds java.net.SocketTimeoutException handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 )
>>> Tested with JDK11 and higher.
>>> JDK11 webrev: http://cr.openjdk.java.net/~yan/8239788/webrev.0/
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8239798 and https://bugs.openjdk.java.net/browse/JDK-8239788
>>> Thank you,
>>> Alexey
>>>> On 22 Feb 2020, at 15:00, security-dev-request at openjdk.java.net <mailto:security-dev-request at openjdk.java.net> wrote:
>>>>
>>>> I will look into the issue.
>>>>
>>>> BTW, I closed JDK-8239788 as duplicate of JDK-8239798.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 2/21/2020 9:24 AM, Kumar Srinivasan wrote:
>>>>> Hi security-folk,
>>>>>
>>>>> At VMware while upgrading our application to OpenJDK11u, we have
>>>>> encountered what seems to be a serious behavior issue.
>>>>> The issue AFAICT seems to have stemmed from the work for TLS1.3 and
>>>>> JDK-8196584 <https://bugs.openjdk.java.net/browse/JDK-8196584>.
>>>>>
>>>>> Overview:
>>>>> With OpenJDK11 the end-points are closed immediately with TLS alerts
>>>>> raised when an exception is received.
>>>>> This is not the case with JDK8 the socket is not closed allowing retries.
>>>>>
>>>>> I have filed: JDK-8239798 (with a reproducer), this issue was also
>>>>> reported ?to Azul and they have filed: JDK-8239788.
>>>>>
>>>>> Can you please evaluate this at the earliest, this is a serious show
>>>>> stopper for VMware.
>>>>>
>>>>> Thank
>>>>> Kumar Srinivasan
>>>>> VMware
>>>>
>
More information about the security-dev
mailing list