I there any idea when the patch will be merged and a release will be cut so we 
can enable testing with JDK11 again for netty ?


> On 31. Jul 2018, at 07:19, Norman Maurer <norman.mau...@googlemail.com> wrote:
> 
> After digging more this morning I noticed the test code did made some wrong 
> assumptions which just worked out of luck before. After fixing the test 
> everything passes now.
> 
> So +1 from me on the patch :)
> 
> Also sorry for the false-alarm.
> 
> Niorman
> 
> 
>> On 30. Jul 2018, at 22:23, Xuelei Fan <xuelei....@oracle.com> wrote:
>> 
>> Would you mind send me the debug log (-Djavax.net.debug=all) and the 
>> exception stacks?  The "renegotiation" in TLS 1.3 is different from TLS 1.2 
>> and prior specifications.  It would be helpful to me to find the cause of 
>> the test failure.
>> 
>> Thanks,
>> Xuelei
>> 
>> On 7/30/2018 1:11 PM, Norman Maurer wrote:
>>> Sorry but I just noticed we still have a another integration test failing 
>>> which tests that client SSL renegotiation is failing. This seems to be not 
>>> the case anymore with java11 + your patch (it was in ea20 tho).
>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/testsuite/src/main/java/io/netty/testsuite/transport/socket/SocketSslClientRenegotiateTest.java
>>> Let me know if I need to dig more into it.
>>> Bye
>>> Norman
>>>> On 30. Jul 2018, at 21:54, Norman Maurer <norman.mau...@googlemail.com 
>>>> <mailto:norman.mau...@googlemail.com>> wrote:
>>>> 
>>>> Hey Xuelei,
>>>> 
>>>> I just re-ran our testsuite with your patch and everything pass except two 
>>>> tests. After digging a bit I found that we needed to add explicit calls to 
>>>> `SSLEngine.setUSeClientMode(false)` now in these test where we did not 
>>>> need to do this before.
>>>> 
>>>> The tests in question are:
>>>> 
>>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L400
>>>> https://github.com/netty/netty/blob/netty-4.1.28.Final/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java#L418
>>>> 
>>>> Here we use SslContext.getDefault().createSSLEngine() and did not set the 
>>>> mode explicitly before. With the following patch to netty all works when 
>>>> using your patch:
>>>> 
>>>> diff --git 
>>>> a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java 
>>>> b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
>>>> index e982b6a63..40d6e7b59 100644
>>>> --- a/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
>>>> +++ b/handler/src/test/java/io/netty/handler/ssl/SslHandlerTest.java
>>>> @@ -398,7 +398,9 @@ public class SslHandlerTest {
>>>>     @Test
>>>>     public void testCloseFutureNotified() throws Exception {
>>>> -        SslHandler handler = new 
>>>> SslHandler(SSLContext.getDefault().createSSLEngine());
>>>> +        SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>>>> +        engine.setUseClientMode(false);
>>>> +        SslHandler handler = new SslHandler(engine);
>>>>         EmbeddedChannel ch = new EmbeddedChannel(handler);
>>>>         ch.close();
>>>> @@ -417,6 +419,7 @@ public class SslHandlerTest {
>>>>     @Test(timeout = 5000)
>>>>     public void testEventsFired() throws Exception {
>>>>         SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>>>> +        engine.setUseClientMode(false);
>>>>         final BlockingQueue<SslCompletionEvent> events = new 
>>>> LinkedBlockingQueue<SslCompletionEvent>();
>>>>         EmbeddedChannel channel = new EmbeddedChannel(new 
>>>> SslHandler(engine), new ChannelInboundHandlerAdapter() {
>>>>             @Override
>>>> 
>>>> 
>>>> The exception we see without the patch is:
>>>> 
>>>> java.lang.IllegalStateException: Client/Server mode has not yet been set.
>>>> at 
>>>> java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:98)
>>>> at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1731)
>>>> at 
>>>> io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1644)
>>>> at io.netty.handler.ssl.SslHandler.handlerAdded(SslHandler.java:1634)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:235)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:409)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.addLast(DefaultChannelPipeline.java:396)
>>>> at 
>>>> io.netty.channel.embedded.EmbeddedChannel$2.initChannel(EmbeddedChannel.java:203)
>>>> at 
>>>> io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:115)
>>>> at 
>>>> io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:107)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:637)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.access$000(DefaultChannelPipeline.java:46)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1487)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1161)
>>>> at 
>>>> io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:686)
>>>> at 
>>>> io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:510)
>>>> at 
>>>> io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:476)
>>>> at 
>>>> io.netty.channel.embedded.EmbeddedChannel$EmbeddedUnsafe$1.register(EmbeddedChannel.java:773)
>>>> at 
>>>> io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:130)
>>>> at 
>>>> io.netty.channel.embedded.EmbeddedEventLoop.register(EmbeddedEventLoop.java:124)
>>>> at 
>>>> io.netty.channel.embedded.EmbeddedChannel.setup(EmbeddedChannel.java:208)
>>>> at 
>>>> io.netty.channel.embedded.EmbeddedChannel.<init>(EmbeddedChannel.java:167)
>>>> at 
>>>> io.netty.channel.embedded.EmbeddedChannel.<init>(EmbeddedChannel.java:148)
>>>> at 
>>>> io.netty.channel.embedded.EmbeddedChannel.<init>(EmbeddedChannel.java:135)
>>>> at 
>>>> io.netty.channel.embedded.EmbeddedChannel.<init>(EmbeddedChannel.java:100)
>>>> at 
>>>> io.netty.handler.ssl.SslHandlerTest.testCloseFutureNotified(SslHandlerTest.java:404)
>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
>>>> Method)
>>>> at 
>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>> at 
>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>>> at 
>>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>>> at 
>>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>>> at 
>>>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>>>> at 
>>>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>>> at 
>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>>> at 
>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>>> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>>>> at 
>>>> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>>>> at 
>>>> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>>>> at 
>>>> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>>>> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
>>>> 
>>>> 
>>>> So I have no problem to patch our test-case but I wondered if this may 
>>>> break others in other cases and so is a regression.
>>>> 
>>>> Let me know what you think.
>>>> Norman
>>>> 
>>>>> On 30. Jul 2018, at 20:06, Norman Maurer <norman.mau...@googlemail.com 
>>>>> <mailto:norman.mau...@googlemail.com>> wrote:
>>>>> 
>>>>> Will do and report back as soon as possible.
>>>>> 
>>>>> Thanks
>>>>> Norman
>>>>> 
>>>>> 
>>>>>> On 30. Jul 2018, at 19:57, Xuelei Fan <xuelei....@oracle.com 
>>>>>> <mailto:xuelei....@oracle.com>> wrote:
>>>>>> 
>>>>>> Hi Norman,
>>>>>> 
>>>>>> Would you mind look at the code I posted in the following thread:
>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html
>>>>>> 
>>>>>> I appreciate if you could have a test by the end of this week.
>>>>>> 
>>>>>> Note that with this update, a complete TLS connection should close both 
>>>>>> inbound and outbound explicitly.  However, existing applications may not 
>>>>>> did this way.  If the source code update is not available, please 
>>>>>> consider to use the "jdk.tls.acknowledgeCloseNotify" as a workaround.
>>>>>> 
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>> 
>>>>>> On 7/25/2018 11:22 PM, Norman Maurer wrote:
>>>>>>> Just FYI… I tested this patch via the netty ssl tests and we no longer 
>>>>>>> see the class-cast-exception problems I reported before dso I think 
>>>>>>> this solves the issue.
>>>>>>> That said we still encounter a few test-failures for tests that test 
>>>>>>> behaviour of closing outbound of the SSLEngine but I think these are 
>>>>>>> more related to 
>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017633.html
>>>>>>>  and 
>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017566.html
>>>>>>>  .
>>>>>>> Bye
>>>>>>> Norman
>>>>>>>> On 25. Jul 2018, at 20:30, Xuelei Fan <xuelei....@oracle.com 
>>>>>>>> <mailto:xuelei....@oracle.com> <mailto:xuelei....@oracle.com>> wrote:
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Please review the update for JDK-8208166:
>>>>>>>> http://cr.openjdk.java.net/~xuelei/8208166/webrev.00/ 
>>>>>>>> <http://cr.openjdk.java.net/%7Exuelei/8208166/webrev.00/> 
>>>>>>>> <http://cr.openjdk.java.net/%7Exuelei/8208166/webrev.00/>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8208166
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Xuelei
>>>>> 
>>>> 
> 

Reply via email to