RFR 8170732: GssKrb5Client sends non-zero buffer size when qop is "auth"

[Wang Weijun]

Please take a review at

  http://cr.openjdk.java.net/~weijun/8170732/webrev.00/

According to https://tools.ietf.org/html/rfc4752#section-3.1:

   The client then constructs data, with the first octet containing the
   bit-mask specifying the selected security layer, the second through
   fourth octets containing in network byte order the maximum size
   output_message the client is able to receive (which MUST be 0 if the
   client does not support any security layer),

A test is modified to check this case. Please note that when there is no 
security layer, you cannot call wrap/unwrap anymore.

Thanks
Max

Re: Code Review Request, 6972386 issues with String.toLowerCase/toUpperCase

[Wang Weijun]

Change looks fine.

Thanks for taking care of CtrDrbg.java. I've make quite some changes like this 
and it's a shame I missed it in my own code.

--Max

> On Dec 22, 2016, at 4:05 AM, Xuelei Fan  wrote:
> 
> Hi,
> 
> Please review the fix:
> 
>   http://cr.openjdk.java.net/~xuelei/6972386/webrev.00/
> 
> Change to use the language/country neutral locale for the locale sensitive 
> operations.
> 
> Thanks,
> Xuelei

Re: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-)

[Wang Weijun]

> On Dec 22, 2016, at 8:12 AM, Xuelei Fan  wrote:
> 
> I think the note is an example, may not need an additional CCC.

That's always my understanding.

> 
> For easier reading, I may use a contrast example.  For example, "Note that 
> this means "/-" implies "/foo" but not "foo".".

Good advice.

Thanks
Max

> 
> Use the one you like, I'm OK with the either.
> 
> Xuelei
> 
> On 12/21/2016 3:58 PM, Wang Weijun wrote:
>> 
>>> On Dec 22, 2016, at 4:39 AM, Xuelei Fan  wrote:
>>> 
>>> I'm trying to understand this update.  Does "/-" imply "/foo"?
>> 
>> Yes.
>> 
>>> 
>>> Does the following spec can be used to explain the new added note?
>>> 
>>>* if the wildcard flag is "-", the simple pathname's path
>>>* must be recursively inside the wildcard pathname's path.
>> 
>> Yes.
>> 
>> But the precise meaning of "recursively inside" is different between the 
>> pre-jdk9 and jdk9 behaviors. The @implNote explains more.
>> 
>> --Max
>> 
>>> 
>>> Xuelei
>>> 
>>> On 12/19/2016 11:25 PM, Wang Weijun wrote:
 Ping again.
 
> On Dec 14, 2016, at 1:53 PM, Wang Weijun  wrote:
> 
> An clarification is added to FilePermission::implies:
> 
>* @implNote
>  
>* a simple {@code npath} is recursively inside a wildcard {@code npath}
>* if and only if {@code simple_npath.relativize(wildcard_npath)}
> - * is a series of one or more "..". An invalid {@code 
> FilePermission} does
> + * is a series of one or more "..". Note that this means "/-" does 
> not
> + * imply "foo". An invalid {@code FilePermission} does
>* not imply any object except for itself.
> 
> The newly added sentence is
> 
> Note that this means "/-" does not imply "foo".
> 
> JCK has agreed to update their test.
> 
> Since this is just a clarification inside an @implNote and no spec is 
> updated, I suppose no CCC is needed. Please confirm.
> 
> Thanks
> Max
> 
 
>> 

Re: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-)

[Xuelei Fan]

I think the note is an example, may not need an additional CCC.

For easier reading, I may use a contrast example.  For example, "Note 
that this means "/-" implies "/foo" but not "foo".".


Use the one you like, I'm OK with the either.

Xuelei

On 12/21/2016 3:58 PM, Wang Weijun wrote:



On Dec 22, 2016, at 4:39 AM, Xuelei Fan  wrote:

I'm trying to understand this update.  Does "/-" imply "/foo"?


Yes.



Does the following spec can be used to explain the new added note?

* if the wildcard flag is "-", the simple pathname's path
* must be recursively inside the wildcard pathname's path.


Yes.

But the precise meaning of "recursively inside" is different between the 
pre-jdk9 and jdk9 behaviors. The @implNote explains more.

--Max



Xuelei

On 12/19/2016 11:25 PM, Wang Weijun wrote:

Ping again.


On Dec 14, 2016, at 1:53 PM, Wang Weijun  wrote:

An clarification is added to FilePermission::implies:

* @implNote
  
* a simple {@code npath} is recursively inside a wildcard {@code npath}
* if and only if {@code simple_npath.relativize(wildcard_npath)}
- * is a series of one or more "..". An invalid {@code FilePermission} does
+ * is a series of one or more "..". Note that this means "/-" does not
+ * imply "foo". An invalid {@code FilePermission} does
* not imply any object except for itself.

The newly added sentence is

Note that this means "/-" does not imply "foo".

JCK has agreed to update their test.

Since this is just a clarification inside an @implNote and no spec is updated, 
I suppose no CCC is needed. Please confirm.

Thanks
Max

An Unexpected I/O exception with AsyncHttpClient while performing SSL requests

[Shlomi Abramoviz]

Hi everyone,
I was referred to this group and I hope this is the right place and would
really appreciate if you could share your opinion with me.

My company works with Play framework and Scala as our backend server.
Lately we've been having problems with the server. While making a secured
(SSL) request to a remote API, we're getting the exception below. Seems to
be a problem regarding to the SSL, but I'm not sure. We had a similar
problem a month ago, and setting the flag:

-J-XX:-UseAESIntrinsics -DXX:-UseAESIntrinsics

seemed to help. Now the problem is back.

Some more information: - Play 2.5.9 - Scala 2.11.8 - Server OS: Centos 6.8
- JVM 1.8.0_25

The Exception:

   - AsyncHttpClient-2-4 - 2016-12-21 03:59:17,434 - [debug] - from
   org.asynchttpclient.netty.handler.HttpHandler - Unexpected I/O exception on
   channel [id: 0x9ad15e31, L:/[IP_ADDRESS:PORT - R:SERVER/IP_ADDRESS:443]
   java.lang.NullPointerException: null at java.lang.System.arraycopy(Native
   Method) at com.sun.crypto.provider.GCTR.reset(GCTR.java:125) at
   com.sun.crypto.provider.GCTR.doFinal(GCTR.java:116) at
   
com.sun.crypto.provider.GaloisCounterMode.doLastBlock(GaloisCounterMode.java:343)
   at
   
com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:511)
   at com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1023)
   at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:960) at
   com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:479) at
   javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:830) at
   javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730) at
   javax.crypto.Cipher.doFinal(Cipher.java:2416) at
   sun.security.ssl.CipherBox.decrypt(CipherBox.java:535) at
   sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:200) at
   sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:968) at
   sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:901) at
   sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:775) at
   javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) at
   io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1094) at
   io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:966) at
   io.netty.handler.ssl.SslHandler.decode(SslHandler.java:900) at
   
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
   at
   
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
   at
   
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
   at
   
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
   at
   
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
   at
   
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1294)
   at
   
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
   at
   
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
   at
   
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:911)
   at
   
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
   at
   io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:611)
   at
   
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:552)
   at
   io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:466)
   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438) at
   
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:140)
   at
   
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
   at java.lang.Thread.run(Thread.java:745)

Does anyone have an idea what the problem could be and how can we fix it?

Also, is there any other place you know where I could get help about this
topic?

Thanks in advance,

Shlomi.

Re: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-)

[Xuelei Fan]

I'm trying to understand this update.  Does "/-" imply "/foo"?

Does the following spec can be used to explain the new added note?

 * if the wildcard flag is "-", the simple pathname's path
 * must be recursively inside the wildcard pathname's path.

Xuelei

On 12/19/2016 11:25 PM, Wang Weijun wrote:

Ping again.


On Dec 14, 2016, at 1:53 PM, Wang Weijun  wrote:

An clarification is added to FilePermission::implies:

 * @implNote
   
 * a simple {@code npath} is recursively inside a wildcard {@code npath}
 * if and only if {@code simple_npath.relativize(wildcard_npath)}
- * is a series of one or more "..". An invalid {@code FilePermission} does
+ * is a series of one or more "..". Note that this means "/-" does not
+ * imply "foo". An invalid {@code FilePermission} does
 * not imply any object except for itself.

The newly added sentence is

 Note that this means "/-" does not imply "foo".

JCK has agreed to update their test.

Since this is just a clarification inside an @implNote and no spec is updated, 
I suppose no CCC is needed. Please confirm.

Thanks
Max

Code Review Request, 6972386 issues with String.toLowerCase/toUpperCase

[Xuelei Fan]

Hi,

Please review the fix:

   http://cr.openjdk.java.net/~xuelei/6972386/webrev.00/

Change to use the language/country neutral locale for the locale 
sensitive operations.


Thanks,
Xuelei

Re: [9] RFR 8161232: AsyncSSLSocketClose.java test fails timeout.

[Xuelei Fan]

Looks good to me.

Thanks,
Xuelei

On 12/20/2016 11:34 PM, Sibabrata Sahoo wrote:

Hi,



Please review the following patch,



JBS: https://bugs.openjdk.java.net/browse/JDK-8161232

Webrev: http://cr.openjdk.java.net/~ssahoo/8161232/webrev.00/



Description:

It was reported the Test was failing with timeout consistently on macOS.
There is no log available anymore and the issue is not reproducible
after several trial. It also seems that the actual issue has been fixed
by JDK-8075484. I believe it will be appropriate for now to remove the
Test from problem list and re-open if the issue persist again.



Thanks,

Siba