From xuelei.fan at oracle.com  Thu Sep  1 00:34:46 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 1 Sep 2016 08:34:46 +0800
Subject: RFR: 8164846: CertificateException missing cause of underlying
	exception
In-Reply-To: <57C6F4F2.6070508@oracle.com>
References: <57C6F4F2.6070508@oracle.com>
Message-ID: <4b6c9b7f-fa26-af8a-2ebe-0ed35a7c6e2d@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 8/31/2016 11:17 PM, Se?n Coffey wrote:
> bug ID : https://bugs.openjdk.java.net/browse/JDK-8164846
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8164846.jdk9/webrev/
>
> A CertificateException in SSLContextImpl doesn't include information
> about the cause of the exception. This can often contain a valuable
> snippet of information about the exact reason for the exception (like a
> constraint failure).
>
> --
> Regards,
> Sean.
>

From weijun.wang at oracle.com  Thu Sep  1 14:25:40 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 1 Sep 2016 22:25:40 +0800
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
In-Reply-To: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
References: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
	<6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
Message-ID: <e0a45d9e-6c54-f956-098e-d03f2b1e1c4a@oracle.com>

Webrev updated at

    http://cr.openjdk.java.net/~weijun/8164705/webrev.01

Most suggestions from Alan accepted, including:

1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead of 
public functions.

2. jdk.io.permissionsUseCanonicalPath=<boolean>.

3. samepath.sh rewritten in ReadFileOnPath.java.

Still using "ugly" method names. Thinking they are clear enough.

Thanks
Max

On 8/29/2016 20:18, Alan Bateman wrote:
> On 25/08/2016 04:55, Weijun Wang wrote:
>
>> Hi All
>>
>> Please take a look at
>>
>>    http://cr.openjdk.java.net/~weijun/8164705/webrev.00
>>
>> From the beginning of JDK, FilePermission canonicalizes the input path
>> and use the result in implies() and equals(). This has been a big
>> performance hurt and leads to confusing results when symlinks are
>> involved.
>>
>> The code change above removes the canonicalization.
>>
>> This means FilePermission on "/the/current/working/directory/x" no
>> longer implies that on "x". Since this might bring quite some
>> compatibility risk, the code change includes some tweaks in permission
>> checking to make sure an app is still able to read "x" when the
>> FilePermission granted is on "/the/current/working/directory/x".
>> However, we still hope the policy to be updated to be consistent of
>> how a file is actually accessed.
>>
>> No tweak is devoted to make granting "/this/is/a/symlink" to imply
>> reading of "/the/actual/target/file", because we think it should not.
>>
>> This is quite a big behavior change. If it breaks your app/lib, or
>> does not work with your customized security manager or policy
>> implementation, please let us know.
>>
>> Feel free to provide any feedback.
>>
>> Finally, a new system property "jdk.filepermission.canonicalize" is
>> introduced and it can be "true", "false", or "compat". The out-of-box
>> default is "compat", which means no canonicalization with check tweaks.
> I've taken a first pass over this. A general comment then it's great to
> see FilePermission changed to not do canonicalization. The "new
> behavior" approach to match paths and support absolute => relative and
> relative => absolute all makes sense.
>
> I agree that having a property to revert to legacy behavior make sense.
> Is there any way to reduce this down to just current and legacy
> behavior, it's otherwise too complicated to describe the subtle
> differences between "false" and "compat". If it can be reduced to two
> settings then a name such as
> jdk.io.permissionsUseCanonicalPath=<boolean> could be better than the
> prototype name.
>
> For the implementation then I think it will cleanup before this is ready
> to push. FilePermCompat is a ugly, particularly FilePermission changing
> its public fields. Also method names like impliesWithAltFP,
> newPermPlusAltPath, ... could be re-visited to make them much clearer.
>
> For the test then it would be good if samepath.sh could be replaced with
> a non-shell test.
>
> -Alan

From brian.burkhalter at oracle.com  Fri Sep  2 00:18:50 2016
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 1 Sep 2016 17:18:50 -0700
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
In-Reply-To: <e0a45d9e-6c54-f956-098e-d03f2b1e1c4a@oracle.com>
References: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
	<6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
	<e0a45d9e-6c54-f956-098e-d03f2b1e1c4a@oracle.com>
Message-ID: <E573F934-9E39-4AA7-A663-526C1B472932@oracle.com>

At the API level and conceptually this all appears reasonable. I am going to need to take a deeper pass over it all however to comprehend the implementation at any kind of detailed level. The changes mentioned in response to Alan?s comments all appear good.

Thanks,

Brian

On Sep 1, 2016, at 7:25 AM, Weijun Wang <weijun.wang at oracle.com> wrote:

> Webrev updated at
> 
>   http://cr.openjdk.java.net/~weijun/8164705/webrev.01
> 
> Most suggestions from Alan accepted, including:
> 
> 1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead of public functions.
> 
> 2. jdk.io.permissionsUseCanonicalPath=<boolean>.
> 
> 3. samepath.sh rewritten in ReadFileOnPath.java.
> 
> Still using "ugly" method names. Thinking they are clear enough.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160901/57946bc4/attachment-0001.html>

From ivan.gerasimov at oracle.com  Sat Sep  3 19:30:50 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sat, 3 Sep 2016 22:30:50 +0300
Subject: [jdk9] (XXS) RFR: 8165413: A few typos in javadoc
Message-ID: <ef24ad5e-4bef-2c94-0499-f7133ab4b4ff@oracle.com>

Hello!

Just a few minor typos found across the security-lib javadoc.

Please help review.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165413
WEBREV: http://cr.openjdk.java.net/~igerasim/8165413/00/webrev/

With kind regards,
Ivan


From weijun.wang at oracle.com  Sun Sep  4 00:37:11 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sun, 4 Sep 2016 08:37:11 +0800
Subject: [jdk9] (XXS) RFR: 8165413: A few typos in javadoc
In-Reply-To: <ef24ad5e-4bef-2c94-0499-f7133ab4b4ff@oracle.com>
References: <ef24ad5e-4bef-2c94-0499-f7133ab4b4ff@oracle.com>
Message-ID: <9e6f3343-0f56-5ab4-a2b9-739afe13b7ea@oracle.com>

- * three modulus sizes mentioned above. Still others might not have a 
list of
+ * four modulus sizes mentioned above. Still others might not have a 
list of

Is it possible we just remove the number so we don't make this mistake 
anymore?

Thanks
Max

On 9/4/2016 3:30, Ivan Gerasimov wrote:
> Hello!
>
> Just a few minor typos found across the security-lib javadoc.
>
> Please help review.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165413
> WEBREV: http://cr.openjdk.java.net/~igerasim/8165413/00/webrev/
>
> With kind regards,
> Ivan
>

From ivan.gerasimov at oracle.com  Sun Sep  4 06:04:11 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sun, 4 Sep 2016 09:04:11 +0300
Subject: [jdk9] (XXS) RFR: 8165413: A few typos in javadoc
In-Reply-To: <9e6f3343-0f56-5ab4-a2b9-739afe13b7ea@oracle.com>
References: <ef24ad5e-4bef-2c94-0499-f7133ab4b4ff@oracle.com>
	<9e6f3343-0f56-5ab4-a2b9-739afe13b7ea@oracle.com>
Message-ID: <d94eb61b-c711-fb16-3982-deb0b55a0c5e@oracle.com>

Thank you Max for looking at this!


On 04.09.2016 3:37, Weijun Wang wrote:
> - * three modulus sizes mentioned above. Still others might not have a 
> list of
> + * four modulus sizes mentioned above. Still others might not have a 
> list of
>
> Is it possible we just remove the number so we don't make this mistake 
> anymore?
>
Good point.  Let's remove it!

With kind regards,
Ivan

> Thanks
> Max
>
> On 9/4/2016 3:30, Ivan Gerasimov wrote:
>> Hello!
>>
>> Just a few minor typos found across the security-lib javadoc.
>>
>> Please help review.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165413
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8165413/00/webrev/
>>
>> With kind regards,
>> Ivan
>>
>


From ivan.gerasimov at oracle.com  Mon Sep  5 19:53:24 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 5 Sep 2016 22:53:24 +0300
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi should
	use operator new (nothrow) for allocations
Message-ID: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>

Hello!

In the native layer of sunmscapi provider, for memory allocations the 
::operator new() is used.
In (a very unlikely) case of failure, it will raise a C++ exception of 
type bad_alloc, which is bad, as we don't have handling code.

One simple way to improve the situation would be to use ::operator new 
(std::nothrow), which will just return zero to indicate a failure 
instead of throwing an exception.
Then we can (try to) throw a Java exception of type OutOfMemoryError.

Would you please help review the fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165463
WEBREV: http://cr.openjdk.java.net/~igerasim/8165463/00/webrev/

Comments/suggestions are very welcome.

With kind regards,
Ivan



From christoph.langer at sap.com  Mon Sep  5 20:52:27 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 5 Sep 2016 20:52:27 +0000
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
	should	use operator new (nothrow) for allocations
In-Reply-To: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
Message-ID: <c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>

Hi Ivan,

this looks like a good idea.

Maybe the pattern to do new (std::nothrow), then check for 0 and throw OOM is a good candidate for a Macro which would keep the code a bit more compact?

Best regards
Christoph

> -----Original Message-----
> From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf
> Of Ivan Gerasimov
> Sent: Montag, 5. September 2016 21:53
> To: security-dev at openjdk.java.net
> Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi should
> use operator new (nothrow) for allocations
> 
> Hello!
> 
> In the native layer of sunmscapi provider, for memory allocations the
> ::operator new() is used.
> In (a very unlikely) case of failure, it will raise a C++ exception of
> type bad_alloc, which is bad, as we don't have handling code.
> 
> One simple way to improve the situation would be to use ::operator new
> (std::nothrow), which will just return zero to indicate a failure
> instead of throwing an exception.
> Then we can (try to) throw a Java exception of type OutOfMemoryError.
> 
> Would you please help review the fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165463
> WEBREV: http://cr.openjdk.java.net/~igerasim/8165463/00/webrev/
> 
> Comments/suggestions are very welcome.
> 
> With kind regards,
> Ivan
> 


From ivan.gerasimov at oracle.com  Tue Sep  6 09:54:57 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 6 Sep 2016 12:54:57 +0300
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
	should use operator new (nothrow) for allocations
In-Reply-To: <c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>
References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
	<c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>
Message-ID: <82695145-098c-4707-1012-49b468a2221e@oracle.com>

Thank you Christoph for looking into this!


On 05.09.2016 23:52, Langer, Christoph wrote:
> Hi Ivan,
>
> this looks like a good idea.
>
> Maybe the pattern to do new (std::nothrow), then check for 0 and throw OOM is a good candidate for a Macro which would keep the code a bit more compact?

Yes, I agree that this code needs some refactoring.
Let's use the overloaded 'operator new':

http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/

With kind regards,
Ivan

> Best regards
> Christoph
>
>> -----Original Message-----
>> From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf
>> Of Ivan Gerasimov
>> Sent: Montag, 5. September 2016 21:53
>> To: security-dev at openjdk.java.net
>> Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi should
>> use operator new (nothrow) for allocations
>>
>> Hello!
>>
>> In the native layer of sunmscapi provider, for memory allocations the
>> ::operator new() is used.
>> In (a very unlikely) case of failure, it will raise a C++ exception of
>> type bad_alloc, which is bad, as we don't have handling code.
>>
>> One simple way to improve the situation would be to use ::operator new
>> (std::nothrow), which will just return zero to indicate a failure
>> instead of throwing an exception.
>> Then we can (try to) throw a Java exception of type OutOfMemoryError.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165463
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8165463/00/webrev/
>>
>> Comments/suggestions are very welcome.
>>
>> With kind regards,
>> Ivan
>>


From christoph.langer at sap.com  Tue Sep  6 12:12:37 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 6 Sep 2016 12:12:37 +0000
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
	should use operator new (nothrow) for allocations
In-Reply-To: <82695145-098c-4707-1012-49b468a2221e@oracle.com>
References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
	<c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>
	<82695145-098c-4707-1012-49b468a2221e@oracle.com>
Message-ID: <16124837f5da493ba3df8267baaa9e99@DEWDFE13DE11.global.corp.sap>

Hi Ivan,

looks good to me - but I'm no reviewer...

Best regards
Christoph

> -----Original Message-----
> From: Ivan Gerasimov [mailto:ivan.gerasimov at oracle.com]
> Sent: Dienstag, 6. September 2016 11:55
> To: Langer, Christoph <christoph.langer at sap.com>; security-
> dev at openjdk.java.net
> Subject: Re: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
> should use operator new (nothrow) for allocations
> 
> Thank you Christoph for looking into this!
> 
> 
> On 05.09.2016 23:52, Langer, Christoph wrote:
> > Hi Ivan,
> >
> > this looks like a good idea.
> >
> > Maybe the pattern to do new (std::nothrow), then check for 0 and throw
> OOM is a good candidate for a Macro which would keep the code a bit more
> compact?
> 
> Yes, I agree that this code needs some refactoring.
> Let's use the overloaded 'operator new':
> 
> http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/
> 
> With kind regards,
> Ivan
> 
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On
> Behalf
> >> Of Ivan Gerasimov
> >> Sent: Montag, 5. September 2016 21:53
> >> To: security-dev at openjdk.java.net
> >> Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi should
> >> use operator new (nothrow) for allocations
> >>
> >> Hello!
> >>
> >> In the native layer of sunmscapi provider, for memory allocations the
> >> ::operator new() is used.
> >> In (a very unlikely) case of failure, it will raise a C++ exception of
> >> type bad_alloc, which is bad, as we don't have handling code.
> >>
> >> One simple way to improve the situation would be to use ::operator new
> >> (std::nothrow), which will just return zero to indicate a failure
> >> instead of throwing an exception.
> >> Then we can (try to) throw a Java exception of type OutOfMemoryError.
> >>
> >> Would you please help review the fix?
> >>
> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165463
> >> WEBREV: http://cr.openjdk.java.net/~igerasim/8165463/00/webrev/
> >>
> >> Comments/suggestions are very welcome.
> >>
> >> With kind regards,
> >> Ivan
> >>


From artem.smotrakov at oracle.com  Tue Sep  6 17:45:44 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 6 Sep 2016 10:45:44 -0700
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
	should use operator new (nothrow) for allocations
In-Reply-To: <82695145-098c-4707-1012-49b468a2221e@oracle.com>
References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
	<c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>
	<82695145-098c-4707-1012-49b468a2221e@oracle.com>
Message-ID: <8f715576-c0bd-fe64-5033-0c0c50c2fd0f@oracle.com>

Hi Ivan,

It's not really about your changes, but I am wondering if "delete [] 
pszNameString" should be called before "continue" in line 1414? Looks 
like a potential memory leak.

Artem


On 09/06/2016 02:54 AM, Ivan Gerasimov wrote:
> Thank you Christoph for looking into this!
>
>
> On 05.09.2016 23:52, Langer, Christoph wrote:
>> Hi Ivan,
>>
>> this looks like a good idea.
>>
>> Maybe the pattern to do new (std::nothrow), then check for 0 and 
>> throw OOM is a good candidate for a Macro which would keep the code a 
>> bit more compact?
>
> Yes, I agree that this code needs some refactoring.
> Let's use the overloaded 'operator new':
>
> http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/
>
> With kind regards,
> Ivan
>
>> Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On 
>>> Behalf
>>> Of Ivan Gerasimov
>>> Sent: Montag, 5. September 2016 21:53
>>> To: security-dev at openjdk.java.net
>>> Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi 
>>> should
>>> use operator new (nothrow) for allocations
>>>
>>> Hello!
>>>
>>> In the native layer of sunmscapi provider, for memory allocations the
>>> ::operator new() is used.
>>> In (a very unlikely) case of failure, it will raise a C++ exception of
>>> type bad_alloc, which is bad, as we don't have handling code.
>>>
>>> One simple way to improve the situation would be to use ::operator new
>>> (std::nothrow), which will just return zero to indicate a failure
>>> instead of throwing an exception.
>>> Then we can (try to) throw a Java exception of type OutOfMemoryError.
>>>
>>> Would you please help review the fix?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165463
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8165463/00/webrev/
>>>
>>> Comments/suggestions are very welcome.
>>>
>>> With kind regards,
>>> Ivan
>>>
>


From sean.mullan at oracle.com  Tue Sep  6 19:25:28 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 6 Sep 2016 15:25:28 -0400
Subject: [jdk9] (XXS) RFR: 8165413: A few typos in javadoc
In-Reply-To: <d94eb61b-c711-fb16-3982-deb0b55a0c5e@oracle.com>
References: <ef24ad5e-4bef-2c94-0499-f7133ab4b4ff@oracle.com>
	<9e6f3343-0f56-5ab4-a2b9-739afe13b7ea@oracle.com>
	<d94eb61b-c711-fb16-3982-deb0b55a0c5e@oracle.com>
Message-ID: <52a1c524-601f-9074-eeff-b2d49a111236@oracle.com>

Looks fine, but can you change the bug synopsis to something more 
specific than "A few typos in javadoc"?

Thanks,
Sean

On 09/04/2016 02:04 AM, Ivan Gerasimov wrote:
> Thank you Max for looking at this!
>
>
> On 04.09.2016 3:37, Weijun Wang wrote:
>> - * three modulus sizes mentioned above. Still others might not have a
>> list of
>> + * four modulus sizes mentioned above. Still others might not have a
>> list of
>>
>> Is it possible we just remove the number so we don't make this mistake
>> anymore?
>>
> Good point.  Let's remove it!
>
> With kind regards,
> Ivan
>
>> Thanks
>> Max
>>
>> On 9/4/2016 3:30, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> Just a few minor typos found across the security-lib javadoc.
>>>
>>> Please help review.
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165413
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8165413/00/webrev/
>>>
>>> With kind regards,
>>> Ivan
>>>
>>
>

From ivan.gerasimov at oracle.com  Tue Sep  6 20:07:21 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 6 Sep 2016 23:07:21 +0300
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
	should use operator new (nothrow) for allocations
In-Reply-To: <8f715576-c0bd-fe64-5033-0c0c50c2fd0f@oracle.com>
References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
	<c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>
	<82695145-098c-4707-1012-49b468a2221e@oracle.com>
	<8f715576-c0bd-fe64-5033-0c0c50c2fd0f@oracle.com>
Message-ID: <5d9731ca-0e74-5f24-57bb-65d179e7c3a5@oracle.com>

Hi Artem!

On 06.09.2016 20:45, Artem Smotrakov wrote:
> Hi Ivan,
>
> It's not really about your changes, but I am wondering if "delete [] 
> pszNameString" should be called before "continue" in line 1414? Looks 
> like a potential memory leak.
>
I assume you mean "continue" at the line 1430, not 1414?
Yes, that caught my eye too :)
Actually, this particular case seems to be benign.
If the first call to CertGetNameString() at 1413 returned > 1 then 
_most_likely_ the second call at 1426 should be Okay as well.
But I agree that this should be rewritten to make the deallocation logic 
more clear.

There seems to be another, more promising memleak in 
loadKeysOrCertificateChains(), which I'm investigating at the moment.
I think these two leaks can be fixed together.

With kind regards,
Ivan

> Artem
>
>
> On 09/06/2016 02:54 AM, Ivan Gerasimov wrote:
>> Thank you Christoph for looking into this!
>>
>>
>> On 05.09.2016 23:52, Langer, Christoph wrote:
>>> Hi Ivan,
>>>
>>> this looks like a good idea.
>>>
>>> Maybe the pattern to do new (std::nothrow), then check for 0 and 
>>> throw OOM is a good candidate for a Macro which would keep the code 
>>> a bit more compact?
>>
>> Yes, I agree that this code needs some refactoring.
>> Let's use the overloaded 'operator new':
>>
>> http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/
>>
>> With kind regards,
>> Ivan
>>
>>> Best regards
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: security-dev [mailto:security-dev-bounces at openjdk.java.net] 
>>>> On Behalf
>>>> Of Ivan Gerasimov
>>>> Sent: Montag, 5. September 2016 21:53
>>>> To: security-dev at openjdk.java.net
>>>> Subject: [jdk9] (S) RFR: 8165463: Native implementation of 
>>>> sunmscapi should
>>>> use operator new (nothrow) for allocations
>>>>
>>>> Hello!
>>>>
>>>> In the native layer of sunmscapi provider, for memory allocations the
>>>> ::operator new() is used.
>>>> In (a very unlikely) case of failure, it will raise a C++ exception of
>>>> type bad_alloc, which is bad, as we don't have handling code.
>>>>
>>>> One simple way to improve the situation would be to use ::operator new
>>>> (std::nothrow), which will just return zero to indicate a failure
>>>> instead of throwing an exception.
>>>> Then we can (try to) throw a Java exception of type OutOfMemoryError.
>>>>
>>>> Would you please help review the fix?
>>>>
>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165463
>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8165463/00/webrev/
>>>>
>>>> Comments/suggestions are very welcome.
>>>>
>>>> With kind regards,
>>>> Ivan
>>>>
>>
>
>


From artem.smotrakov at oracle.com  Tue Sep  6 20:20:24 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 6 Sep 2016 13:20:24 -0700
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
	should use operator new (nothrow) for allocations
In-Reply-To: <5d9731ca-0e74-5f24-57bb-65d179e7c3a5@oracle.com>
References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
	<c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>
	<82695145-098c-4707-1012-49b468a2221e@oracle.com>
	<8f715576-c0bd-fe64-5033-0c0c50c2fd0f@oracle.com>
	<5d9731ca-0e74-5f24-57bb-65d179e7c3a5@oracle.com>
Message-ID: <7049d308-59d1-32e1-4d3e-f6bfb7701202@oracle.com>

I think we are talking about the same "continue", but in different 
webrevs :) I meant this:

http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp.html

...

1410             if (::CertGetNameString(pCertContext,
1411                 CERT_NAME_FRIENDLY_DISPLAY_TYPE, 0, NULL, 
pszNameString,
1412                 cchNameString) == 1) {
1413
1414                 continue; // not found
1415             }

...

Thanks!


Artem

On 09/06/2016 01:07 PM, Ivan Gerasimov wrote:
> Hi Artem!
>
> On 06.09.2016 20:45, Artem Smotrakov wrote:
>> Hi Ivan,
>>
>> It's not really about your changes, but I am wondering if "delete [] 
>> pszNameString" should be called before "continue" in line 1414? Looks 
>> like a potential memory leak.
>>
> I assume you mean "continue" at the line 1430, not 1414?
> Yes, that caught my eye too :)
> Actually, this particular case seems to be benign.
> If the first call to CertGetNameString() at 1413 returned > 1 then 
> _most_likely_ the second call at 1426 should be Okay as well.
> But I agree that this should be rewritten to make the deallocation 
> logic more clear.
>
> There seems to be another, more promising memleak in 
> loadKeysOrCertificateChains(), which I'm investigating at the moment.
> I think these two leaks can be fixed together.
>
> With kind regards,
> Ivan
>
>> Artem
>>
>>
>> On 09/06/2016 02:54 AM, Ivan Gerasimov wrote:
>>> Thank you Christoph for looking into this!
>>>
>>>
>>> On 05.09.2016 23:52, Langer, Christoph wrote:
>>>> Hi Ivan,
>>>>
>>>> this looks like a good idea.
>>>>
>>>> Maybe the pattern to do new (std::nothrow), then check for 0 and 
>>>> throw OOM is a good candidate for a Macro which would keep the code 
>>>> a bit more compact?
>>>
>>> Yes, I agree that this code needs some refactoring.
>>> Let's use the overloaded 'operator new':
>>>
>>> http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/
>>>
>>> With kind regards,
>>> Ivan
>>>
>>>> Best regards
>>>> Christoph
>>>>
>>>>> -----Original Message-----
>>>>> From: security-dev [mailto:security-dev-bounces at openjdk.java.net] 
>>>>> On Behalf
>>>>> Of Ivan Gerasimov
>>>>> Sent: Montag, 5. September 2016 21:53
>>>>> To: security-dev at openjdk.java.net
>>>>> Subject: [jdk9] (S) RFR: 8165463: Native implementation of 
>>>>> sunmscapi should
>>>>> use operator new (nothrow) for allocations
>>>>>
>>>>> Hello!
>>>>>
>>>>> In the native layer of sunmscapi provider, for memory allocations the
>>>>> ::operator new() is used.
>>>>> In (a very unlikely) case of failure, it will raise a C++ 
>>>>> exception of
>>>>> type bad_alloc, which is bad, as we don't have handling code.
>>>>>
>>>>> One simple way to improve the situation would be to use ::operator 
>>>>> new
>>>>> (std::nothrow), which will just return zero to indicate a failure
>>>>> instead of throwing an exception.
>>>>> Then we can (try to) throw a Java exception of type OutOfMemoryError.
>>>>>
>>>>> Would you please help review the fix?
>>>>>
>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165463
>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8165463/00/webrev/
>>>>>
>>>>> Comments/suggestions are very welcome.
>>>>>
>>>>> With kind regards,
>>>>> Ivan
>>>>>
>>>
>>
>>
>


From ivan.gerasimov at oracle.com  Tue Sep  6 20:33:04 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 6 Sep 2016 23:33:04 +0300
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
	should use operator new (nothrow) for allocations
In-Reply-To: <7049d308-59d1-32e1-4d3e-f6bfb7701202@oracle.com>
References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
	<c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>
	<82695145-098c-4707-1012-49b468a2221e@oracle.com>
	<8f715576-c0bd-fe64-5033-0c0c50c2fd0f@oracle.com>
	<5d9731ca-0e74-5f24-57bb-65d179e7c3a5@oracle.com>
	<7049d308-59d1-32e1-4d3e-f6bfb7701202@oracle.com>
Message-ID: <76f45e64-2994-abb1-7a2e-b82465a6d84f@oracle.com>

Ah, yes, right.

I forgot to close the previous webrev in the browser.

With kind regards,
Ivan

On 06.09.2016 23:20, Artem Smotrakov wrote:
> I think we are talking about the same "continue", but in different 
> webrevs :) I meant this:
>
> http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp.html 
>
>
> ...
>
> 1410             if (::CertGetNameString(pCertContext,
> 1411                 CERT_NAME_FRIENDLY_DISPLAY_TYPE, 0, NULL, 
> pszNameString,
> 1412                 cchNameString) == 1) {
> 1413
> 1414                 continue; // not found
> 1415             }
>
> ...
>
> Thanks!
>
>
> Artem
>
> On 09/06/2016 01:07 PM, Ivan Gerasimov wrote:
>> Hi Artem!
>>
>> On 06.09.2016 20:45, Artem Smotrakov wrote:
>>> Hi Ivan,
>>>
>>> It's not really about your changes, but I am wondering if "delete [] 
>>> pszNameString" should be called before "continue" in line 1414? 
>>> Looks like a potential memory leak.
>>>
>> I assume you mean "continue" at the line 1430, not 1414?
>> Yes, that caught my eye too :)
>> Actually, this particular case seems to be benign.
>> If the first call to CertGetNameString() at 1413 returned > 1 then 
>> _most_likely_ the second call at 1426 should be Okay as well.
>> But I agree that this should be rewritten to make the deallocation 
>> logic more clear.
>>
>> There seems to be another, more promising memleak in 
>> loadKeysOrCertificateChains(), which I'm investigating at the moment.
>> I think these two leaks can be fixed together.
>>
>> With kind regards,
>> Ivan
>>
>>> Artem
>>>
>>>
>>> On 09/06/2016 02:54 AM, Ivan Gerasimov wrote:
>>>> Thank you Christoph for looking into this!
>>>>
>>>>
>>>> On 05.09.2016 23:52, Langer, Christoph wrote:
>>>>> Hi Ivan,
>>>>>
>>>>> this looks like a good idea.
>>>>>
>>>>> Maybe the pattern to do new (std::nothrow), then check for 0 and 
>>>>> throw OOM is a good candidate for a Macro which would keep the 
>>>>> code a bit more compact?
>>>>
>>>> Yes, I agree that this code needs some refactoring.
>>>> Let's use the overloaded 'operator new':
>>>>
>>>> http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/
>>>>
>>>> With kind regards,
>>>> Ivan
>>>>
>>>>> Best regards
>>>>> Christoph
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: security-dev [mailto:security-dev-bounces at openjdk.java.net] 
>>>>>> On Behalf
>>>>>> Of Ivan Gerasimov
>>>>>> Sent: Montag, 5. September 2016 21:53
>>>>>> To: security-dev at openjdk.java.net
>>>>>> Subject: [jdk9] (S) RFR: 8165463: Native implementation of 
>>>>>> sunmscapi should
>>>>>> use operator new (nothrow) for allocations
>>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> In the native layer of sunmscapi provider, for memory allocations 
>>>>>> the
>>>>>> ::operator new() is used.
>>>>>> In (a very unlikely) case of failure, it will raise a C++ 
>>>>>> exception of
>>>>>> type bad_alloc, which is bad, as we don't have handling code.
>>>>>>
>>>>>> One simple way to improve the situation would be to use 
>>>>>> ::operator new
>>>>>> (std::nothrow), which will just return zero to indicate a failure
>>>>>> instead of throwing an exception.
>>>>>> Then we can (try to) throw a Java exception of type 
>>>>>> OutOfMemoryError.
>>>>>>
>>>>>> Would you please help review the fix?
>>>>>>
>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165463
>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8165463/00/webrev/
>>>>>>
>>>>>> Comments/suggestions are very welcome.
>>>>>>
>>>>>> With kind regards,
>>>>>> Ivan
>>>>>>
>>>>
>>>
>>>
>>
>
>


From christoph.langer at sap.com  Wed Sep  7 09:14:21 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 7 Sep 2016 09:14:21 +0000
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
	should use operator new (nothrow) for allocations
In-Reply-To: <5d9731ca-0e74-5f24-57bb-65d179e7c3a5@oracle.com>
References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
	<c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>
	<82695145-098c-4707-1012-49b468a2221e@oracle.com>
	<8f715576-c0bd-fe64-5033-0c0c50c2fd0f@oracle.com>
	<5d9731ca-0e74-5f24-57bb-65d179e7c3a5@oracle.com>
Message-ID: <0bd21ac9c0bf4f6e87ae15e3adc47962@DEWDFE13DE11.global.corp.sap>

Hi Ivan,

I agree that the code around 1414 should be rewritten and I can also see the potential leak in loadKeysOrCertificateChains() which should definitely be fixed.

However, I have further comments for your current change:
In line 100 you should probably reduce the indent to 4 characters instead of 8 compared to the " ThrowExceptionWithMessage ..." from the line before to align with the rest of the file

99         ThrowExceptionWithMessage(env, OUT_OF_MEMORY_ERROR,
100                 "native memory allocation failed");

Also, I'm still wondering if you could define a little macro like:

#define CHECKED_NEW_ARRAY(_pointer, _type, _size) \
        _pointer = new (env) _type[_size]; \
        if (_pointer == NULL) { \
            __leave; \
        }

Then you could have a compact line at the allocation place like: 
CHECKED_NEW_ARRAY(pszNameString, char, cchNameString)

But if you want to leave it like it is and don't use macros, I guess it's ok, too..

Best regards
Christoph

> -----Original Message-----
> From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf
> Of Ivan Gerasimov
> Sent: Dienstag, 6. September 2016 22:07
> To: Artem Smotrakov <artem.smotrakov at oracle.com>; security-
> dev at openjdk.java.net
> Subject: Re: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
> should use operator new (nothrow) for allocations
> 
> Hi Artem!
> 
> On 06.09.2016 20:45, Artem Smotrakov wrote:
> > Hi Ivan,
> >
> > It's not really about your changes, but I am wondering if "delete []
> > pszNameString" should be called before "continue" in line 1414? Looks
> > like a potential memory leak.
> >
> I assume you mean "continue" at the line 1430, not 1414?
> Yes, that caught my eye too :)
> Actually, this particular case seems to be benign.
> If the first call to CertGetNameString() at 1413 returned > 1 then
> _most_likely_ the second call at 1426 should be Okay as well.
> But I agree that this should be rewritten to make the deallocation logic
> more clear.
> 
> There seems to be another, more promising memleak in
> loadKeysOrCertificateChains(), which I'm investigating at the moment.
> I think these two leaks can be fixed together.
> 
> With kind regards,
> Ivan
> 
> > Artem
> >
> >
> > On 09/06/2016 02:54 AM, Ivan Gerasimov wrote:
> >> Thank you Christoph for looking into this!
> >>
> >>
> >> On 05.09.2016 23:52, Langer, Christoph wrote:
> >>> Hi Ivan,
> >>>
> >>> this looks like a good idea.
> >>>
> >>> Maybe the pattern to do new (std::nothrow), then check for 0 and
> >>> throw OOM is a good candidate for a Macro which would keep the code
> >>> a bit more compact?
> >>
> >> Yes, I agree that this code needs some refactoring.
> >> Let's use the overloaded 'operator new':
> >>
> >> http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/
> >>
> >> With kind regards,
> >> Ivan
> >>
> >>> Best regards
> >>> Christoph
> >>>
> >>>> -----Original Message-----
> >>>> From: security-dev [mailto:security-dev-bounces at openjdk.java.net]
> >>>> On Behalf
> >>>> Of Ivan Gerasimov
> >>>> Sent: Montag, 5. September 2016 21:53
> >>>> To: security-dev at openjdk.java.net
> >>>> Subject: [jdk9] (S) RFR: 8165463: Native implementation of
> >>>> sunmscapi should
> >>>> use operator new (nothrow) for allocations
> >>>>
> >>>> Hello!
> >>>>
> >>>> In the native layer of sunmscapi provider, for memory allocations the
> >>>> ::operator new() is used.
> >>>> In (a very unlikely) case of failure, it will raise a C++ exception of
> >>>> type bad_alloc, which is bad, as we don't have handling code.
> >>>>
> >>>> One simple way to improve the situation would be to use ::operator new
> >>>> (std::nothrow), which will just return zero to indicate a failure
> >>>> instead of throwing an exception.
> >>>> Then we can (try to) throw a Java exception of type OutOfMemoryError.
> >>>>
> >>>> Would you please help review the fix?
> >>>>
> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165463
> >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8165463/00/webrev/
> >>>>
> >>>> Comments/suggestions are very welcome.
> >>>>
> >>>> With kind regards,
> >>>> Ivan
> >>>>
> >>
> >
> >


From ivan.gerasimov at oracle.com  Wed Sep  7 09:40:15 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 7 Sep 2016 12:40:15 +0300
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
	should use operator new (nothrow) for allocations
In-Reply-To: <0bd21ac9c0bf4f6e87ae15e3adc47962@DEWDFE13DE11.global.corp.sap>
References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
	<c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>
	<82695145-098c-4707-1012-49b468a2221e@oracle.com>
	<8f715576-c0bd-fe64-5033-0c0c50c2fd0f@oracle.com>
	<5d9731ca-0e74-5f24-57bb-65d179e7c3a5@oracle.com>
	<0bd21ac9c0bf4f6e87ae15e3adc47962@DEWDFE13DE11.global.corp.sap>
Message-ID: <9b049419-8d5a-0aa3-7cf4-95767ea908fc@oracle.com>

Thank you Christoph for the comments!


On 07.09.2016 12:14, Langer, Christoph wrote:
> Hi Ivan,
>
> I agree that the code around 1414 should be rewritten and I can also see the potential leak in loadKeysOrCertificateChains() which should definitely be fixed.
>
> However, I have further comments for your current change:
> In line 100 you should probably reduce the indent to 4 characters instead of 8 compared to the " ThrowExceptionWithMessage ..." from the line before to align with the rest of the file
>
> 99         ThrowExceptionWithMessage(env, OUT_OF_MEMORY_ERROR,
> 100                 "native memory allocation failed");
Thanks, I'll fix the indentation.

> Also, I'm still wondering if you could define a little macro like:
>
> #define CHECKED_NEW_ARRAY(_pointer, _type, _size) \
>          _pointer = new (env) _type[_size]; \
>          if (_pointer == NULL) { \
>              __leave; \
>          }
>
> Then you could have a compact line at the allocation place like:
> CHECKED_NEW_ARRAY(pszNameString, char, cchNameString)
If there's no strong objection, I would prefer to keep it the way it is now.
I think, it is important to see that the code contains the `jump` 
instruction without a need to unroll the macro.
And this is also consistent with the way the rest of the code is organized.

With kind regards,
Ivan

> But if you want to leave it like it is and don't use macros, I guess it's ok, too..
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf
>> Of Ivan Gerasimov
>> Sent: Dienstag, 6. September 2016 22:07
>> To: Artem Smotrakov <artem.smotrakov at oracle.com>; security-
>> dev at openjdk.java.net
>> Subject: Re: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
>> should use operator new (nothrow) for allocations
>>
>> Hi Artem!
>>
>> On 06.09.2016 20:45, Artem Smotrakov wrote:
>>> Hi Ivan,
>>>
>>> It's not really about your changes, but I am wondering if "delete []
>>> pszNameString" should be called before "continue" in line 1414? Looks
>>> like a potential memory leak.
>>>
>> I assume you mean "continue" at the line 1430, not 1414?
>> Yes, that caught my eye too :)
>> Actually, this particular case seems to be benign.
>> If the first call to CertGetNameString() at 1413 returned > 1 then
>> _most_likely_ the second call at 1426 should be Okay as well.
>> But I agree that this should be rewritten to make the deallocation logic
>> more clear.
>>
>> There seems to be another, more promising memleak in
>> loadKeysOrCertificateChains(), which I'm investigating at the moment.
>> I think these two leaks can be fixed together.
>>
>> With kind regards,
>> Ivan
>>
>>> Artem
>>>
>>>
>>> On 09/06/2016 02:54 AM, Ivan Gerasimov wrote:
>>>> Thank you Christoph for looking into this!
>>>>
>>>>
>>>> On 05.09.2016 23:52, Langer, Christoph wrote:
>>>>> Hi Ivan,
>>>>>
>>>>> this looks like a good idea.
>>>>>
>>>>> Maybe the pattern to do new (std::nothrow), then check for 0 and
>>>>> throw OOM is a good candidate for a Macro which would keep the code
>>>>> a bit more compact?
>>>> Yes, I agree that this code needs some refactoring.
>>>> Let's use the overloaded 'operator new':
>>>>
>>>> http://cr.openjdk.java.net/~igerasim/8165463/01/webrev/
>>>>
>>>> With kind regards,
>>>> Ivan
>>>>
>>>>> Best regards
>>>>> Christoph
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: security-dev [mailto:security-dev-bounces at openjdk.java.net]
>>>>>> On Behalf
>>>>>> Of Ivan Gerasimov
>>>>>> Sent: Montag, 5. September 2016 21:53
>>>>>> To: security-dev at openjdk.java.net
>>>>>> Subject: [jdk9] (S) RFR: 8165463: Native implementation of
>>>>>> sunmscapi should
>>>>>> use operator new (nothrow) for allocations
>>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> In the native layer of sunmscapi provider, for memory allocations the
>>>>>> ::operator new() is used.
>>>>>> In (a very unlikely) case of failure, it will raise a C++ exception of
>>>>>> type bad_alloc, which is bad, as we don't have handling code.
>>>>>>
>>>>>> One simple way to improve the situation would be to use ::operator new
>>>>>> (std::nothrow), which will just return zero to indicate a failure
>>>>>> instead of throwing an exception.
>>>>>> Then we can (try to) throw a Java exception of type OutOfMemoryError.
>>>>>>
>>>>>> Would you please help review the fix?
>>>>>>
>>>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8165463
>>>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8165463/00/webrev/
>>>>>>
>>>>>> Comments/suggestions are very welcome.
>>>>>>
>>>>>> With kind regards,
>>>>>> Ivan
>>>>>>
>>>


From christoph.langer at sap.com  Wed Sep  7 09:42:41 2016
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 7 Sep 2016 09:42:41 +0000
Subject: [jdk9] (S) RFR: 8165463: Native implementation of sunmscapi
	should use operator new (nothrow) for allocations
In-Reply-To: <9b049419-8d5a-0aa3-7cf4-95767ea908fc@oracle.com>
References: <7cf96073-2df2-a72d-cd9c-931b079e6f51@oracle.com>
	<c049882b70c24c8a80b4638aa37f8a1b@DEWDFE13DE11.global.corp.sap>
	<82695145-098c-4707-1012-49b468a2221e@oracle.com>
	<8f715576-c0bd-fe64-5033-0c0c50c2fd0f@oracle.com>
	<5d9731ca-0e74-5f24-57bb-65d179e7c3a5@oracle.com>
	<0bd21ac9c0bf4f6e87ae15e3adc47962@DEWDFE13DE11.global.corp.sap>
	<9b049419-8d5a-0aa3-7cf4-95767ea908fc@oracle.com>
Message-ID: <d87d97591086463d9268b4b9c243b83d@DEWDFE13DE11.global.corp.sap>

Hi Ivan,

> > Also, I'm still wondering if you could define a little macro like:
> >
> > #define CHECKED_NEW_ARRAY(_pointer, _type, _size) \
> >          _pointer = new (env) _type[_size]; \
> >          if (_pointer == NULL) { \
> >              __leave; \
> >          }
> >
> > Then you could have a compact line at the allocation place like:
> > CHECKED_NEW_ARRAY(pszNameString, char, cchNameString)
> If there's no strong objection, I would prefer to keep it the way it is now.
> I think, it is important to see that the code contains the `jump`
> instruction without a need to unroll the macro.
> And this is also consistent with the way the rest of the code is organized.
Ok, sounds good to me :)

Best regards
Christoph


From artem.smotrakov at oracle.com  Wed Sep  7 19:28:47 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 7 Sep 2016 12:28:47 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
Message-ID: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>

Hello,

Please review the following patch for 
sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java

The test has been observed to fail a couple of times, but it's still not 
clear why it failed because there is not much info in logs. The patch 
updates the test to enable additional debug output, so that we have more 
info if it fails next time.

While looking at the test, I notices a couple of issues, but they don't 
seem to cause these intermittent failures:
- The test sets system properties for JSSE in a loop, but JSSE provider 
reads them only once while initialization. As a result, only values 
which were set in the first iteration are actually used.
- The test doesn't close files and sockets sometimes.

The patch also fixed the issues above, and there are a couple cosmetic 
changes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/

Artem

From artem.smotrakov at oracle.com  Wed Sep  7 21:58:10 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 7 Sep 2016 14:58:10 -0700
Subject: [9] RFR: 8163924: SSLEngineBadBufferArrayAccess.java fails
	intermittently with Unrecognized SSL message
Message-ID: <3c45c05b-1da2-7e5d-1099-7b314f40bd5e@oracle.com>

Hello,

Please review the following patch for SSLEngineBadBufferArrayAccess.java 
test.

The test has been observed to fail intermittently with "Unrecognized SSL 
message" error. I couldn't reproduce it, and it's currently not clear 
what caused the test to fail. One guess is that something else might 
connect to the server which caused this error. The patch enables 
additional debug output, so that we have more info if it fails next 
time. JTREG truncates logs, but it's fine since we are interested only 
in last handshaking.

The patch also updates the test to report unexpected exceptions, and 
close files and sockets.

Any other suggestions are very welcome.

Bug: https://bugs.openjdk.java.net/browse/JDK-8163924
Webrev: http://cr.openjdk.java.net/~asmotrak/8163924/webrev.00/

Artem


From artem.smotrakov at oracle.com  Wed Sep  7 22:17:17 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 7 Sep 2016 15:17:17 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
Message-ID: <6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>

Sending to net-dev at openjdk.java.net as well.

Artem


On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
> Hello,
>
> Please review the following patch for 
> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>
> The test has been observed to fail a couple of times, but it's still 
> not clear why it failed because there is not much info in logs. The 
> patch updates the test to enable additional debug output, so that we 
> have more info if it fails next time.
>
> While looking at the test, I notices a couple of issues, but they 
> don't seem to cause these intermittent failures:
> - The test sets system properties for JSSE in a loop, but JSSE 
> provider reads them only once while initialization. As a result, only 
> values which were set in the first iteration are actually used.
> - The test doesn't close files and sockets sometimes.
>
> The patch also fixed the issues above, and there are a couple cosmetic 
> changes.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>
> Artem


From sergei.kovalev at oracle.com  Thu Sep  8 14:03:33 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Thu, 8 Sep 2016 17:03:33 +0300
Subject: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/*
	tests
Message-ID: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>

Hello team,

Could you please review the fix for below CR:

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/

Goal: make test possible to run with "--limit-modules" flag.
Summary: added @modules tag into jtreg header if applicable.

-- 
With best regards,
Sergei


From sergei.kovalev at oracle.com  Thu Sep  8 14:30:19 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Thu, 8 Sep 2016 17:30:19 +0300
Subject: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/*
	tests
In-Reply-To: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
References: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
Message-ID: <b3014167-b43f-d553-f0dc-a76927b5b8be@oracle.com>

Hello team,

Could you please review the fix for below CR:

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/

Goal: make test possible to run with "--limit-modules" flag.
Summary: added @modules tag into jtreg header if applicable.

-- 
With best regards,
Sergei


From joe.darcy at oracle.com  Thu Sep  8 18:16:18 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 8 Sep 2016 11:16:18 -0700
Subject: JDK 9 RFR of JDK-8039854: Broken link in java.lang.RuntimePermission
Message-ID: <8827cd6d-e792-ca82-8a2b-41f625a4779a@oracle.com>

Hello,

Please review the patch below to address

     JDK-8039854: Broken link in java.lang.RuntimePermission

Two broken links are replaced by a live link to the deployment guide.

Thanks,

-Joe


--- a/src/java.base/share/classes/java/lang/RuntimePermission.java Thu 
Sep 08 16:16:44 2016 +0100
+++ b/src/java.base/share/classes/java/lang/RuntimePermission.java Thu 
Sep 08 10:35:10 2016 -0700
@@ -323,11 +323,9 @@
   *   <td>usePolicy</td>
   *   <td>Granting this permission disables the Java Plug-In's default
   *   security prompting behavior.</td>
- *   <td>For more information, refer to Java Plug-In's guides, <a href=
- * "../../../technotes/guides/plugin/developer_guide/security.html">
- *   Applet Security Basics</a> and <a href=
- * "../../../technotes/guides/plugin/developer_guide/rsa_how.html#use">
- *   usePolicy Permission</a>.</td>
+ *   <td>For more information, refer to the <a href=
+ *   "../../../technotes/guides/deploy/index.html">deployment guide</a>.
+ *   </td>
   * </tr>
   * <tr>
   *   <td>manageProcess</td>


From lance.andersen at oracle.com  Thu Sep  8 18:17:26 2016
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 8 Sep 2016 14:17:26 -0400
Subject: JDK 9 RFR of JDK-8039854: Broken link in
	java.lang.RuntimePermission
In-Reply-To: <8827cd6d-e792-ca82-8a2b-41f625a4779a@oracle.com>
References: <8827cd6d-e792-ca82-8a2b-41f625a4779a@oracle.com>
Message-ID: <795B335D-E0E5-4D78-A256-012FA24443A0@oracle.com>

all good Joe
> On Sep 8, 2016, at 2:16 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Please review the patch below to address
> 
>    JDK-8039854: Broken link in java.lang.RuntimePermission
> 
> Two broken links are replaced by a live link to the deployment guide.
> 
> Thanks,
> 
> -Joe
> 
> 
> --- a/src/java.base/share/classes/java/lang/RuntimePermission.java Thu Sep 08 16:16:44 2016 +0100
> +++ b/src/java.base/share/classes/java/lang/RuntimePermission.java Thu Sep 08 10:35:10 2016 -0700
> @@ -323,11 +323,9 @@
>  *   <td>usePolicy</td>
>  *   <td>Granting this permission disables the Java Plug-In's default
>  *   security prompting behavior.</td>
> - *   <td>For more information, refer to Java Plug-In's guides, <a href=
> - * "../../../technotes/guides/plugin/developer_guide/security.html">
> - *   Applet Security Basics</a> and <a href=
> - * "../../../technotes/guides/plugin/developer_guide/rsa_how.html#use">
> - *   usePolicy Permission</a>.</td>
> + *   <td>For more information, refer to the <a href=
> + *   "../../../technotes/guides/deploy/index.html">deployment guide</a>.
> + *   </td>
>  * </tr>
>  * <tr>
>  *   <td>manageProcess</td>
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160908/4e98a360/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160908/4e98a360/oracle_sig_logo.gif>

From sean.mullan at oracle.com  Thu Sep  8 19:55:24 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 8 Sep 2016 15:55:24 -0400
Subject: JDK 9 RFR of JDK-8039854: Broken link in
	java.lang.RuntimePermission
In-Reply-To: <795B335D-E0E5-4D78-A256-012FA24443A0@oracle.com>
References: <8827cd6d-e792-ca82-8a2b-41f625a4779a@oracle.com>
	<795B335D-E0E5-4D78-A256-012FA24443A0@oracle.com>
Message-ID: <22c06f4a-400b-fbce-dfff-40e47ba27f34@oracle.com>

Actually, I don't really think this permission target belongs in 
RuntimePermission since it is specific to Oracle's Java Plugin. I would 
be in favor of removing it and only documenting it in the deployment guides.

--Sean

On 09/08/2016 02:17 PM, Lance Andersen wrote:
> all good Joe
>> On Sep 8, 2016, at 2:16 PM, joe darcy <joe.darcy at oracle.com
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>> Hello,
>>
>> Please review the patch below to address
>>
>>    JDK-8039854: Broken link in java.lang.RuntimePermission
>>
>> Two broken links are replaced by a live link to the deployment guide.
>>
>> Thanks,
>>
>> -Joe
>>
>>
>> --- a/src/java.base/share/classes/java/lang/RuntimePermission.java Thu
>> Sep 08 16:16:44 2016 +0100
>> +++ b/src/java.base/share/classes/java/lang/RuntimePermission.java Thu
>> Sep 08 10:35:10 2016 -0700
>> @@ -323,11 +323,9 @@
>>  *   <td>usePolicy</td>
>>  *   <td>Granting this permission disables the Java Plug-In's default
>>  *   security prompting behavior.</td>
>> - *   <td>For more information, refer to Java Plug-In's guides, <a href=
>> - * "../../../technotes/guides/plugin/developer_guide/security.html">
>> - *   Applet Security Basics</a> and <a href=
>> - * "../../../technotes/guides/plugin/developer_guide/rsa_how.html#use">
>> - *   usePolicy Permission</a>.</td>
>> + *   <td>For more information, refer to the <a href=
>> + *   "../../../technotes/guides/deploy/index.html">deployment guide</a>.
>> + *   </td>
>>  * </tr>
>>  * <tr>
>>  *   <td>manageProcess</td>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>

From joe.darcy at oracle.com  Thu Sep  8 21:20:09 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 8 Sep 2016 14:20:09 -0700
Subject: JDK 9 RFR of JDK-8039854: Broken link in
	java.lang.RuntimePermission
In-Reply-To: <22c06f4a-400b-fbce-dfff-40e47ba27f34@oracle.com>
References: <8827cd6d-e792-ca82-8a2b-41f625a4779a@oracle.com>
	<795B335D-E0E5-4D78-A256-012FA24443A0@oracle.com>
	<22c06f4a-400b-fbce-dfff-40e47ba27f34@oracle.com>
Message-ID: <de3f9b9a-ac62-38ca-bbb2-66ea2317c1aa@oracle.com>

Hi Sean,

I'm going to push the fix to get a valid link in the table, but I don't 
oppose if someone else files a follow-up bug to change the spec and 
remove the row if that is appropriate course of action.

Thanks,

-Joe


On 9/8/2016 12:55 PM, Sean Mullan wrote:
> Actually, I don't really think this permission target belongs in 
> RuntimePermission since it is specific to Oracle's Java Plugin. I 
> would be in favor of removing it and only documenting it in the 
> deployment guides.
>
> --Sean
>
> On 09/08/2016 02:17 PM, Lance Andersen wrote:
>> all good Joe
>>> On Sep 8, 2016, at 2:16 PM, joe darcy <joe.darcy at oracle.com
>>> <mailto:joe.darcy at oracle.com>> wrote:
>>>
>>> Hello,
>>>
>>> Please review the patch below to address
>>>
>>>    JDK-8039854: Broken link in java.lang.RuntimePermission
>>>
>>> Two broken links are replaced by a live link to the deployment guide.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>>
>>> --- a/src/java.base/share/classes/java/lang/RuntimePermission.java Thu
>>> Sep 08 16:16:44 2016 +0100
>>> +++ b/src/java.base/share/classes/java/lang/RuntimePermission.java Thu
>>> Sep 08 10:35:10 2016 -0700
>>> @@ -323,11 +323,9 @@
>>>  *   <td>usePolicy</td>
>>>  *   <td>Granting this permission disables the Java Plug-In's default
>>>  *   security prompting behavior.</td>
>>> - *   <td>For more information, refer to Java Plug-In's guides, <a 
>>> href=
>>> - * "../../../technotes/guides/plugin/developer_guide/security.html">
>>> - *   Applet Security Basics</a> and <a href=
>>> - * 
>>> "../../../technotes/guides/plugin/developer_guide/rsa_how.html#use">
>>> - *   usePolicy Permission</a>.</td>
>>> + *   <td>For more information, refer to the <a href=
>>> + * "../../../technotes/guides/deploy/index.html">deployment guide</a>.
>>> + *   </td>
>>>  * </tr>
>>>  * <tr>
>>>  *   <td>manageProcess</td>
>>>
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> 
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
>> Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>
>>
>>


From weijun.wang at oracle.com  Mon Sep 12 07:23:43 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 12 Sep 2016 15:23:43 +0800
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
In-Reply-To: <e0a45d9e-6c54-f956-098e-d03f2b1e1c4a@oracle.com>
References: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
	<6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
	<e0a45d9e-6c54-f956-098e-d03f2b1e1c4a@oracle.com>
Message-ID: <e4391932-d96f-a543-43ca-c20597b1db4e@oracle.com>

BTW, please also review the release note at

    https://bugs.openjdk.java.net/browse/JDK-8165836

Thanks
Max

On 9/1/2016 22:25, Weijun Wang wrote:
> Webrev updated at
>
>    http://cr.openjdk.java.net/~weijun/8164705/webrev.01


From brian.burkhalter at oracle.com  Mon Sep 12 18:13:06 2016
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 12 Sep 2016 11:13:06 -0700
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
In-Reply-To: <e4391932-d96f-a543-43ca-c20597b1db4e@oracle.com>
References: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
	<6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
	<e0a45d9e-6c54-f956-098e-d03f2b1e1c4a@oracle.com>
	<e4391932-d96f-a543-43ca-c20597b1db4e@oracle.com>
Message-ID: <D37F53D2-6139-4A66-A7CB-4660F67E6345@oracle.com>

Only picky comments: not sure but maybe change:

1) vice versa -> and vice versa
2) When it?s set to true -> When true
3) just like before -> as before

Brian

On Sep 12, 2016, at 12:23 AM, Weijun Wang <weijun.wang at oracle.com> wrote:

> BTW, please also review the release note at
> 
>   https://bugs.openjdk.java.net/browse/JDK-8165836
> 
> Thanks
> Max

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160912/28919988/attachment-0001.html>

From weijun.wang at oracle.com  Tue Sep 13 02:41:35 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 13 Sep 2016 10:41:35 +0800
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
In-Reply-To: <D37F53D2-6139-4A66-A7CB-4660F67E6345@oracle.com>
References: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
	<6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
	<e0a45d9e-6c54-f956-098e-d03f2b1e1c4a@oracle.com>
	<e4391932-d96f-a543-43ca-c20597b1db4e@oracle.com>
	<D37F53D2-6139-4A66-A7CB-4660F67E6345@oracle.com>
Message-ID: <61453466-05aa-f799-f7ed-55ceec507504@oracle.com>



On 9/13/2016 2:13, Brian Burkhalter wrote:
> Only picky comments: not sure but maybe change:
>
> 1) vice versa -> and vice versa
> 2) When it?s set to true -> When true
> 3) just like before -> as before

All accepted.

Thanks
Max

>
> Brian
>
> On Sep 12, 2016, at 12:23 AM, Weijun Wang <weijun.wang at oracle.com
> <mailto:weijun.wang at oracle.com>> wrote:
>
>> BTW, please also review the release note at
>>
>>   https://bugs.openjdk.java.net/browse/JDK-8165836
>>
>> Thanks
>> Max
>

From weijun.wang at oracle.com  Tue Sep 13 03:34:38 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 13 Sep 2016 11:34:38 +0800
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
In-Reply-To: <E573F934-9E39-4AA7-A663-526C1B472932@oracle.com>
References: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
	<6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
	<e0a45d9e-6c54-f956-098e-d03f2b1e1c4a@oracle.com>
	<E573F934-9E39-4AA7-A663-526C1B472932@oracle.com>
Message-ID: <aeb87b49-58e7-04dd-5449-e8abbacfbed4@oracle.com>

Have you finished the deeper pass? :-)

Thanks
Max

On 9/2/2016 8:18, Brian Burkhalter wrote:
> At the API level and conceptually this all appears reasonable. I am
> going to need to take a deeper pass over it all however to comprehend
> the implementation at any kind of detailed level. The changes mentioned
> in response to Alan?s comments all appear good.
>
> Thanks,
>
> Brian
>
> On Sep 1, 2016, at 7:25 AM, Weijun Wang <weijun.wang at oracle.com
> <mailto:weijun.wang at oracle.com>> wrote:
>
>> Webrev updated at
>>
>>   http://cr.openjdk.java.net/~weijun/8164705/webrev.01
>>
>> Most suggestions from Alan accepted, including:
>>
>> 1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead
>> of public functions.
>>
>> 2. jdk.io.permissionsUseCanonicalPath=<boolean>.
>>
>> 3. samepath.sh rewritten in ReadFileOnPath.java.
>>
>> Still using "ugly" method names. Thinking they are clear enough.
>

From sha.jiang at oracle.com  Tue Sep 13 09:43:32 2016
From: sha.jiang at oracle.com (John Jiang)
Date: Tue, 13 Sep 2016 17:43:32 +0800
Subject: RFR[9] JDK-8077138: Some PKCS11 tests fail because NSS library is not
	initialized
Message-ID: <861f8983-6342-ddb5-b504-77e8752fc73d@oracle.com>

Hi,
Please review this patch for fixing JDK-8077138.
The solution is re-building NSS libraries with VS2013, and then the new 
NSS DLLs can depend on msvcr120.dll, which is already distributed with 
JDK 9.

And please note that, this patch also removes the PKCS11 tests from 
ProblemList.txt, though these tests have another issue JDK-8023434.
JDK-8023434 is related to Solaris, but the PKCS11 tests are marked with 
windows-all. So, I think it's no meaning to keep such items. Then, these 
tests will really be executed on Windows platforms.

Webrev: http://cr.openjdk.java.net/~jjiang/8077138/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8077138

Best regards,
John Jiang


From sibabrata.sahoo at oracle.com  Tue Sep 13 10:14:04 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Tue, 13 Sep 2016 03:14:04 -0700 (PDT)
Subject: [9] RFR: 8156054: Test Task: Develop new tests for JEP C155: Remove
	FilePermission Pathname Canonicalization
Message-ID: <fbd80ba6-8b64-49c0-bc89-6db6ba72027d@default>

Hi,

 

Please review the patch for,

 

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

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

 

Description: 

It checks equals(), implies() and hashCode () of FilePermission when "jdk.io.permissionsUseCanonicalPath" set and un-set. Along with, it also verify compatibility with previous JDK version.

 

 

Thanks,

Siba

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160913/58f35f8d/attachment.html>

From vincent.x.ryan at oracle.com  Tue Sep 13 10:16:43 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Tue, 13 Sep 2016 11:16:43 +0100
Subject: RFR[9] JDK-8077138: Some PKCS11 tests fail because NSS library is
	not initialized
In-Reply-To: <861f8983-6342-ddb5-b504-77e8752fc73d@oracle.com>
References: <861f8983-6342-ddb5-b504-77e8752fc73d@oracle.com>
Message-ID: <21F53FAC-08CA-4A5C-8953-AD3B3E6B8B5F@oracle.com>

The code changes look fine (but your webrev shows zero lines changed throughout).


> On 13 Sep 2016, at 10:43, John Jiang <sha.jiang at oracle.com> wrote:
> 
> Hi,
> Please review this patch for fixing JDK-8077138.
> The solution is re-building NSS libraries with VS2013, and then the new NSS DLLs can depend on msvcr120.dll, which is already distributed with JDK 9.
> 
> And please note that, this patch also removes the PKCS11 tests from ProblemList.txt, though these tests have another issue JDK-8023434.
> JDK-8023434 is related to Solaris, but the PKCS11 tests are marked with windows-all. So, I think it's no meaning to keep such items. Then, these tests will really be executed on Windows platforms.
> 
> Webrev: http://cr.openjdk.java.net/~jjiang/8077138/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8077138
> 
> Best regards,
> John Jiang
> 


From sibabrata.sahoo at oracle.com  Tue Sep 13 10:43:41 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Tue, 13 Sep 2016 03:43:41 -0700 (PDT)
Subject: [9] RFR: 8165825: Remove the intermittent keyword from
	sun/security/krb5/auto/Unreachable.java
Message-ID: <a182272b-d346-409c-a35e-952ec744aded@default>

Hi,

 

Please review the patch for,

 

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

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

 

Description:

This is a simple fix for removing  intermittent keyword from sun/security/krb5/auto/Unreachable.java file.

 

Thanks,

Siba

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160913/79cd52ac/attachment.html>

From weijun.wang at oracle.com  Tue Sep 13 10:52:55 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 13 Sep 2016 18:52:55 +0800
Subject: [9] RFR: 8165825: Remove the intermittent keyword from
	sun/security/krb5/auto/Unreachable.java
In-Reply-To: <a182272b-d346-409c-a35e-952ec744aded@default>
References: <a182272b-d346-409c-a35e-952ec744aded@default>
Message-ID: <aef15e51-4e4c-fb13-afbe-eb1e5eafa68c@oracle.com>

Change looks fine. Hopefully the test does not fail again. :-)

Thanks
Max

On 9/13/2016 18:43, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Please review the patch for,
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8165825
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8165825/webrev.00/
>
>
>
> Description:
>
> This is a simple fix for removing  intermittent keyword from
> sun/security/krb5/auto/Unreachable.java file.
>
>
>
> Thanks,
>
> Siba
>
>
>

From weijun.wang at oracle.com  Tue Sep 13 10:54:47 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 13 Sep 2016 18:54:47 +0800
Subject: [9] RFR: 8156054: Test Task: Develop new tests for JEP C155:
	Remove FilePermission Pathname Canonicalization
In-Reply-To: <fbd80ba6-8b64-49c0-bc89-6db6ba72027d@default>
References: <fbd80ba6-8b64-49c0-bc89-6db6ba72027d@default>
Message-ID: <0df80b87-cbfa-ef58-fd93-0bb61b71a4e2@oracle.com>

   44         final String current = ".";
   45         final File realFile = new File(current, "exist.file");

I suggest we just use new File("exist.file").

No other comment.

Thanks
Max

On 9/13/2016 18:14, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Please review the patch for,
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8156054
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8156054/webrev.00/
>
>
>
> Description:
>
> It checks equals(), implies() and hashCode () of FilePermission when
> ?jdk.io.permissionsUseCanonicalPath? set and un-set. Along with, it also
> verify compatibility with previous JDK version.
>
>
>
>
>
> Thanks,
>
> Siba
>
>
>

From sibabrata.sahoo at oracle.com  Tue Sep 13 10:56:19 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Tue, 13 Sep 2016 03:56:19 -0700 (PDT)
Subject: [9] RFR: 8165660: Remove the intermittent keyword from
	sun/security/krb5/auto/MaxRetries.java
Message-ID: <2dce0da9-5a98-4bc6-8d08-94f03a5dc130@default>

Hi,

 

Please review the patch for,

 

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

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

 

Description:

This is a simple fix for removing  intermittent keyword from sun/security/krb5/auto/MaxRetries.java file.

 

 

Thanks,

Siba

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160913/bd80059c/attachment.html>

From weijun.wang at oracle.com  Tue Sep 13 11:11:00 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 13 Sep 2016 19:11:00 +0800
Subject: [9] RFR: 8165660: Remove the intermittent keyword from
	sun/security/krb5/auto/MaxRetries.java
In-Reply-To: <2dce0da9-5a98-4bc6-8d08-94f03a5dc130@default>
References: <2dce0da9-5a98-4bc6-8d08-94f03a5dc130@default>
Message-ID: <bf72ded8-535f-0cbf-296a-d5d2510e6358@oracle.com>

Is there a criteria on when to add and when to remove this keyword? Due 
to the characteristics (timeout, ICMP) of these tests, they still have a 
chance to fail.

If we keep the keyword there, will it be any bad?

Thanks
Max

On 9/13/2016 18:56, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Please review the patch for,
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8165660
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8165660/webrev.00/
>
>
>
> Description:
>
> This is a simple fix for removing  intermittent keyword from
> sun/security/krb5/auto/MaxRetries.java file.
>
>
>
>
>
> Thanks,
>
> Siba
>
>
>

From sergei.kovalev at oracle.com  Tue Sep 13 12:34:18 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Tue, 13 Sep 2016 15:34:18 +0300
Subject: RFR(S): 8165689: Fix module dependencies for
	sun/security/pkcs11/* tests
In-Reply-To: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
References: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
Message-ID: <def25644-a6d3-1c38-7c6c-d38b13e35d84@oracle.com>

Hello team,

This is re-request for review of very small changes. Could somebody take 
a look?


08.09.16 17:03, Sergei Kovalev wrote:
> Hello team,
>
> Could you please review the fix for below CR:
>
> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
> WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/
>
> Goal: make test possible to run with "--limit-modules" flag.
> Summary: added @modules tag into jtreg header if applicable.
>

-- 
With best regards,
Sergei


From sibabrata.sahoo at oracle.com  Tue Sep 13 13:53:42 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Tue, 13 Sep 2016 06:53:42 -0700 (PDT)
Subject: [9] RFR: 8156054: Test Task: Develop new tests for JEP C155:
	Remove FilePermission Pathname Canonicalization
In-Reply-To: <0df80b87-cbfa-ef58-fd93-0bb61b71a4e2@oracle.com>
References: <fbd80ba6-8b64-49c0-bc89-6db6ba72027d@default>
	<0df80b87-cbfa-ef58-fd93-0bb61b71a4e2@oracle.com>
Message-ID: <d9b29a3d-8a88-48a7-b8d0-52786fb28916@default>

Hi Max,

Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8156054/webrev.01/

Thanks,
Siba

-----Original Message-----
From: Weijun Wang 
Sent: Tuesday, September 13, 2016 4:25 PM
To: Sibabrata Sahoo; security-dev at openjdk.java.net
Subject: Re: [9] RFR: 8156054: Test Task: Develop new tests for JEP C155: Remove FilePermission Pathname Canonicalization

   44         final String current = ".";
   45         final File realFile = new File(current, "exist.file");

I suggest we just use new File("exist.file").

No other comment.

Thanks
Max

On 9/13/2016 18:14, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Please review the patch for,
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8156054
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8156054/webrev.00/
>
>
>
> Description:
>
> It checks equals(), implies() and hashCode () of FilePermission when 
> "jdk.io.permissionsUseCanonicalPath" set and un-set. Along with, it 
> also verify compatibility with previous JDK version.
>
>
>
>
>
> Thanks,
>
> Siba
>
>
>

From weijun.wang at oracle.com  Tue Sep 13 14:04:09 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 13 Sep 2016 22:04:09 +0800
Subject: [9] RFR: 8156054: Test Task: Develop new tests for JEP C155:
	Remove FilePermission Pathname Canonicalization
In-Reply-To: <d9b29a3d-8a88-48a7-b8d0-52786fb28916@default>
References: <fbd80ba6-8b64-49c0-bc89-6db6ba72027d@default>
	<0df80b87-cbfa-ef58-fd93-0bb61b71a4e2@oracle.com>
	<d9b29a3d-8a88-48a7-b8d0-52786fb28916@default>
Message-ID: <ab855a21-bed5-ff63-57a3-8dcd9191b71c@oracle.com>

Good!

Thanks
Max

On 9/13/2016 21:53, Sibabrata Sahoo wrote:
> Hi Max,
>
> Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8156054/webrev.01/
>
> Thanks,
> Siba
>
> -----Original Message-----
> From: Weijun Wang
> Sent: Tuesday, September 13, 2016 4:25 PM
> To: Sibabrata Sahoo; security-dev at openjdk.java.net
> Subject: Re: [9] RFR: 8156054: Test Task: Develop new tests for JEP C155: Remove FilePermission Pathname Canonicalization
>
>    44         final String current = ".";
>    45         final File realFile = new File(current, "exist.file");
>
> I suggest we just use new File("exist.file").
>
> No other comment.
>
> Thanks
> Max
>
> On 9/13/2016 18:14, Sibabrata Sahoo wrote:
>> Hi,
>>
>>
>>
>> Please review the patch for,
>>
>>
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8156054
>>
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8156054/webrev.00/
>>
>>
>>
>> Description:
>>
>> It checks equals(), implies() and hashCode () of FilePermission when
>> "jdk.io.permissionsUseCanonicalPath" set and un-set. Along with, it
>> also verify compatibility with previous JDK version.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Siba
>>
>>
>>

From jamil.j.nimeh at oracle.com  Tue Sep 13 14:47:13 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 13 Sep 2016 07:47:13 -0700
Subject: RFR: 8132926 - PKIXParameters built with public key form of
	TrustAnchor causes NPE during cert path building/validation
Message-ID: <26af8909-dd01-6e02-cd7c-ef7e12578531@oracle.com>

Hello all,

This fixes an issue in OCSP response verification during CertPath 
building/verification.  This issue happens when trust anchors are used 
that were built using constructor forms other than a certificate.

Bug: https://bugs.openjdk.java.net/browse/JDK-8132926
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132926/webrev.01/

Thanks,
--Jamil

From brian.burkhalter at oracle.com  Tue Sep 13 15:09:06 2016
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 13 Sep 2016 08:09:06 -0700
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
In-Reply-To: <aeb87b49-58e7-04dd-5449-e8abbacfbed4@oracle.com>
References: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
	<6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
	<e0a45d9e-6c54-f956-098e-d03f2b1e1c4a@oracle.com>
	<E573F934-9E39-4AA7-A663-526C1B472932@oracle.com>
	<aeb87b49-58e7-04dd-5449-e8abbacfbed4@oracle.com>
Message-ID: <0AB49214-E670-42A6-88C7-9761D3C652DA@oracle.com>

Not really. Will continue with it. I?m not sure whether Alan is done with it either.

Brian

On Sep 12, 2016, at 8:34 PM, Weijun Wang <weijun.wang at oracle.com> wrote:

> Have you finished the deeper pass? :-)
> 
> Thanks
> Max
> 
> On 9/2/2016 8:18, Brian Burkhalter wrote:
>> At the API level and conceptually this all appears reasonable. I am
>> going to need to take a deeper pass over it all however to comprehend
>> the implementation at any kind of detailed level. The changes mentioned
>> in response to Alan?s comments all appear good.
>> 
>> Thanks,
>> 
>> Brian
>> 
>> On Sep 1, 2016, at 7:25 AM, Weijun Wang <weijun.wang at oracle.com
>> <mailto:weijun.wang at oracle.com>> wrote:
>> 
>>> Webrev updated at
>>> 
>>>  http://cr.openjdk.java.net/~weijun/8164705/webrev.01
>>> 
>>> Most suggestions from Alan accepted, including:
>>> 
>>> 1. Using SharedSecrets.getJavaIOFilePermissionAccess() style instead
>>> of public functions.
>>> 
>>> 2. jdk.io.permissionsUseCanonicalPath=<boolean>.
>>> 
>>> 3. samepath.sh rewritten in ReadFileOnPath.java.
>>> 
>>> Still using "ugly" method names. Thinking they are clear enough.
>> 


From artem.smotrakov at oracle.com  Tue Sep 13 17:15:44 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 13 Sep 2016 10:15:44 -0700
Subject: RFR[9] JDK-8077138: Some PKCS11 tests fail because NSS library is
	not initialized
In-Reply-To: <861f8983-6342-ddb5-b504-77e8752fc73d@oracle.com>
References: <861f8983-6342-ddb5-b504-77e8752fc73d@oracle.com>
Message-ID: <dbaf16c6-a293-6a76-875c-a7c01158bdde@oracle.com>

I am wondering if we really need to put nss-3.16-with-nspr-4.10.4.tar.gz 
in to the repository. Would it be better just to provide a link to this 
archive?

Artem

On 09/13/2016 02:43 AM, John Jiang wrote:
> Hi,
> Please review this patch for fixing JDK-8077138.
> The solution is re-building NSS libraries with VS2013, and then the 
> new NSS DLLs can depend on msvcr120.dll, which is already distributed 
> with JDK 9.
>
> And please note that, this patch also removes the PKCS11 tests from 
> ProblemList.txt, though these tests have another issue JDK-8023434.
> JDK-8023434 is related to Solaris, but the PKCS11 tests are marked 
> with windows-all. So, I think it's no meaning to keep such items. 
> Then, these tests will really be executed on Windows platforms.
>
> Webrev: http://cr.openjdk.java.net/~jjiang/8077138/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8077138
>
> Best regards,
> John Jiang
>


From artem.smotrakov at oracle.com  Tue Sep 13 17:24:09 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 13 Sep 2016 10:24:09 -0700
Subject: [9] RFR: 8156054: Test Task: Develop new tests for JEP C155:
	Remove FilePermission Pathname Canonicalization
In-Reply-To: <fbd80ba6-8b64-49c0-bc89-6db6ba72027d@default>
References: <fbd80ba6-8b64-49c0-bc89-6db6ba72027d@default>
Message-ID: <b029311b-2f95-2bc6-aac9-ecce623b70bd@oracle.com>

Hi Siba,

I see that the test expects only true or false. You can just pass these 
boolean values, and check() can make sure that everything returns the 
expected boolean value without building a string. That would be clearer 
to me. Not an issue, it's up to you to change it or not.

Artem


On 09/13/2016 03:14 AM, Sibabrata Sahoo wrote:
>
> Hi,
>
> Please review the patch for,
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8156054
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8156054/webrev.00/ 
> <http://cr.openjdk.java.net/%7Essahoo/8156054/webrev.00/>
>
> Description:
>
> It checks equals(), implies() and hashCode () of FilePermission when 
> ?jdk.io.permissionsUseCanonicalPath? set and un-set. Along with, it 
> also verify compatibility with previous JDK version.
>
> Thanks,
>
> Siba
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160913/99f159b0/attachment.html>

From artem.smotrakov at oracle.com  Wed Sep 14 01:31:03 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 13 Sep 2016 18:31:03 -0700
Subject: [9] RFR: 8163924: SSLEngineBadBufferArrayAccess.java fails
	intermittently with Unrecognized SSL message
In-Reply-To: <3c45c05b-1da2-7e5d-1099-7b314f40bd5e@oracle.com>
References: <3c45c05b-1da2-7e5d-1099-7b314f40bd5e@oracle.com>
Message-ID: <746499ff-4b8b-15ef-e4fe-d66ca72363e1@oracle.com>

Hello,

Not urgent, but I would appreciate if somebody can take a look at the 
webrev below and webvev for 8164591. Thank you!

Artem

On 09/07/2016 02:58 PM, Artem Smotrakov wrote:
> Hello,
>
> Please review the following patch for 
> SSLEngineBadBufferArrayAccess.java test.
>
> The test has been observed to fail intermittently with "Unrecognized 
> SSL message" error. I couldn't reproduce it, and it's currently not 
> clear what caused the test to fail. One guess is that something else 
> might connect to the server which caused this error. The patch enables 
> additional debug output, so that we have more info if it fails next 
> time. JTREG truncates logs, but it's fine since we are interested only 
> in last handshaking.
>
> The patch also updates the test to report unexpected exceptions, and 
> close files and sockets.
>
> Any other suggestions are very welcome.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163924
> Webrev: http://cr.openjdk.java.net/~asmotrak/8163924/webrev.00/
>
> Artem
>


From xuelei.fan at oracle.com  Wed Sep 14 01:34:32 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 14 Sep 2016 09:34:32 +0800
Subject: RFR: 8132926 - PKIXParameters built with public key form of
	TrustAnchor causes NPE during cert path building/validation
In-Reply-To: <26af8909-dd01-6e02-cd7c-ef7e12578531@oracle.com>
References: <26af8909-dd01-6e02-cd7c-ef7e12578531@oracle.com>
Message-ID: <802a750a-b7f3-5bbc-23c7-048b00e3b823@oracle.com>

Looks fine to me.

Xuelei

On 9/13/2016 10:47 PM, Jamil Nimeh wrote:
> Hello all,
>
> This fixes an issue in OCSP response verification during CertPath
> building/verification.  This issue happens when trust anchors are used
> that were built using constructor forms other than a certificate.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8132926
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132926/webrev.01/
>
> Thanks,
> --Jamil

From xuelei.fan at oracle.com  Wed Sep 14 01:39:30 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 14 Sep 2016 09:39:30 +0800
Subject: [9] RFR: 8163924: SSLEngineBadBufferArrayAccess.java fails
	intermittently with Unrecognized SSL message
In-Reply-To: <746499ff-4b8b-15ef-e4fe-d66ca72363e1@oracle.com>
References: <3c45c05b-1da2-7e5d-1099-7b314f40bd5e@oracle.com>
	<746499ff-4b8b-15ef-e4fe-d66ca72363e1@oracle.com>
Message-ID: <414130c7-6d1f-f3e7-e50c-215b5b2f03a1@oracle.com>

I think the failure may caused by using free port by other test cases. 
As you were already there, would you mind update to use the 
SSLSocketSample.java template under the folder test/javax/net/ssl/templates?

Thanks,
Xuelei

On 9/14/2016 9:31 AM, Artem Smotrakov wrote:
> Hello,
>
> Not urgent, but I would appreciate if somebody can take a look at the
> webrev below and webvev for 8164591. Thank you!
>
> Artem
>
> On 09/07/2016 02:58 PM, Artem Smotrakov wrote:
>> Hello,
>>
>> Please review the following patch for
>> SSLEngineBadBufferArrayAccess.java test.
>>
>> The test has been observed to fail intermittently with "Unrecognized
>> SSL message" error. I couldn't reproduce it, and it's currently not
>> clear what caused the test to fail. One guess is that something else
>> might connect to the server which caused this error. The patch enables
>> additional debug output, so that we have more info if it fails next
>> time. JTREG truncates logs, but it's fine since we are interested only
>> in last handshaking.
>>
>> The patch also updates the test to report unexpected exceptions, and
>> close files and sockets.
>>
>> Any other suggestions are very welcome.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163924
>> Webrev: http://cr.openjdk.java.net/~asmotrak/8163924/webrev.00/
>>
>> Artem
>>
>

From weijun.wang at oracle.com  Wed Sep 14 06:59:22 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 14 Sep 2016 14:59:22 +0800
Subject: RFR[9] JDK-8077138: Some PKCS11 tests fail because NSS library is
	not initialized
In-Reply-To: <861f8983-6342-ddb5-b504-77e8752fc73d@oracle.com>
References: <861f8983-6342-ddb5-b504-77e8752fc73d@oracle.com>
Message-ID: <c3c2f247-d926-7144-9349-741b10ccdee5@oracle.com>

Hi John

I just noticed this webrev request.

After syncing with jdk9/dev, the PKCS11 tests still fail on my 64-bit 
Windows 10 machine. I had always thought [1] the failure is due to the 
DLLs without the executable bit. In fact, after I chmod a+x them, the 
tests pass.

How did you confirm your change works? Did the test fail with the old 
DLLs on your test machine and succeed with the new ones?

Thanks
Max

[1] 
https://bugs.openjdk.java.net/browse/JDK-8023434?focusedCommentId=13860118&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13860118

On 9/13/2016 17:43, John Jiang wrote:
> Hi,
> Please review this patch for fixing JDK-8077138.
> The solution is re-building NSS libraries with VS2013, and then the new
> NSS DLLs can depend on msvcr120.dll, which is already distributed with
> JDK 9.
>
> And please note that, this patch also removes the PKCS11 tests from
> ProblemList.txt, though these tests have another issue JDK-8023434.
> JDK-8023434 is related to Solaris, but the PKCS11 tests are marked with
> windows-all. So, I think it's no meaning to keep such items. Then, these
> tests will really be executed on Windows platforms.
>
> Webrev: http://cr.openjdk.java.net/~jjiang/8077138/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8077138
>
> Best regards,
> John Jiang
>

From sha.jiang at oracle.com  Wed Sep 14 07:12:37 2016
From: sha.jiang at oracle.com (John Jiang)
Date: Wed, 14 Sep 2016 15:12:37 +0800
Subject: RFR[9] JDK-8077138: Some PKCS11 tests fail because NSS library is
	not initialized
In-Reply-To: <c3c2f247-d926-7144-9349-741b10ccdee5@oracle.com>
References: <861f8983-6342-ddb5-b504-77e8752fc73d@oracle.com>
	<c3c2f247-d926-7144-9349-741b10ccdee5@oracle.com>
Message-ID: <a9c32871-1142-614e-a4ac-537b69e44444@oracle.com>

Hi,

On 2016/9/14 14:59, Weijun Wang wrote:
> Hi John
>
> I just noticed this webrev request.
>
> After syncing with jdk9/dev, the PKCS11 tests still fail on my 64-bit 
> Windows 10 machine. I had always thought [1] the failure is due to the 
> DLLs without the executable bit. In fact, after I chmod a+x them, the 
> tests pass.
>
> How did you confirm your change works? Did the test fail with the old 
> DLLs on your test machine and succeed with the new ones?
I did run JPRT on PKCS11 tests with/without the patch. And the results 
are expected.
Exactly, the tests failed without the patch, and they passed with the patch.
And Mach5 have run the tests after the patch was pushed, no PKCS11 test 
failure was found.

Best regards,
John Jiang
>
> Thanks
> Max
>
> [1] 
> https://bugs.openjdk.java.net/browse/JDK-8023434?focusedCommentId=13860118&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13860118
>
> On 9/13/2016 17:43, John Jiang wrote:
>> Hi,
>> Please review this patch for fixing JDK-8077138.
>> The solution is re-building NSS libraries with VS2013, and then the new
>> NSS DLLs can depend on msvcr120.dll, which is already distributed with
>> JDK 9.
>>
>> And please note that, this patch also removes the PKCS11 tests from
>> ProblemList.txt, though these tests have another issue JDK-8023434.
>> JDK-8023434 is related to Solaris, but the PKCS11 tests are marked with
>> windows-all. So, I think it's no meaning to keep such items. Then, these
>> tests will really be executed on Windows platforms.
>>
>> Webrev: http://cr.openjdk.java.net/~jjiang/8077138/webrev.00/
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8077138
>>
>> Best regards,
>> John Jiang
>>
>


From weijun.wang at oracle.com  Wed Sep 14 07:56:08 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 14 Sep 2016 15:56:08 +0800
Subject: [9] RFR: 8165660: Remove the intermittent keyword from
	sun/security/krb5/auto/MaxRetries.java
In-Reply-To: <bf72ded8-535f-0cbf-296a-d5d2510e6358@oracle.com>
References: <2dce0da9-5a98-4bc6-8d08-94f03a5dc130@default>
	<bf72ded8-535f-0cbf-296a-d5d2510e6358@oracle.com>
Message-ID: <0e285017-a895-446e-9cd7-1b3fc7cd2e9f@oracle.com>

After some thinking, I am OK with the change now. Please remove the keyword.

Thanks
Max

On 9/13/2016 19:11, Weijun Wang wrote:
> Is there a criteria on when to add and when to remove this keyword? Due
> to the characteristics (timeout, ICMP) of these tests, they still have a
> chance to fail.
>
> If we keep the keyword there, will it be any bad?
>
> Thanks
> Max
>
> On 9/13/2016 18:56, Sibabrata Sahoo wrote:
>> Hi,
>>
>>
>>
>> Please review the patch for,
>>
>>
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8165660
>>
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8165660/webrev.00/
>>
>>
>>
>> Description:
>>
>> This is a simple fix for removing  intermittent keyword from
>> sun/security/krb5/auto/MaxRetries.java file.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Siba
>>
>>
>>

From weijun.wang at oracle.com  Wed Sep 14 08:52:44 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 14 Sep 2016 16:52:44 +0800
Subject: Do your NSS DLLs on Windows have execute permission?
Message-ID: <bf2383a3-ad36-1f1c-2078-fe7e38090b7d@oracle.com>

I see PKCS11 tests fail on my Windows 10 after JDK-8165946 [1]. After 
discussing with John (who worked on the bug) I found my NSS DLLs do not 
have the execute permission bit and his have.

Mine is -rw-r--r--, and his is -rwxrwx---+.

I am using cygwin on Windows 10 64-bit, and I use hg inside cygwin to 
clone the repo. My umask is 0022.

Do you have that x? If yes, what's wrong with my environment? If no, do 
the tests run fine on your machine? For example, I just tried 
sun/security/pkcs11/Cipher/TestSymmCiphers.java and it fails.

Thanks
Max

[1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/15badd72caae

From sergei.kovalev at oracle.com  Wed Sep 14 12:22:41 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Wed, 14 Sep 2016 15:22:41 +0300
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
Message-ID: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>

Hello Team,

Could you please review below fix for

Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/

Issue: The test should be able to pass or skipped by JTreg test suite if 
required modules have not been included in custom JRE.
Solution: added '@modules' tags and appropriate module list to tests header.
Testing done locally using JTregt test suite.

-- 
With best regards,
Sergei


From xuelei.fan at oracle.com  Wed Sep 14 12:54:46 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 14 Sep 2016 20:54:46 +0800
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
In-Reply-To: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
References: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
Message-ID: <664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>

Hi Sergei,

Thanks for the update.  The fix looks fine to me.  However, I'm not sure 
why some tests need the "/sun/security/krb5/auto" libraries and the 
related modules.  As you were already there, would you mind help to test 
whether the "/sun/security/krb5/auto" library can be removed for some tests?

Thanks,
Xuelei

On 9/14/2016 8:22 PM, Sergei Kovalev wrote:
> Hello Team,
>
> Could you please review below fix for
>
> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
> Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/
>
> Issue: The test should be able to pass or skipped by JTreg test suite if
> required modules have not been included in custom JRE.
> Solution: added '@modules' tags and appropriate module list to tests
> header.
> Testing done locally using JTregt test suite.
>

From weijun.wang at oracle.com  Wed Sep 14 13:56:35 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 14 Sep 2016 21:56:35 +0800
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
In-Reply-To: <664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
References: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
	<664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
Message-ID: <F6EE79D1-496C-4168-942E-8BA5073450E2@oracle.com>

I also have no idea why these are needed:

+ * @modules java.security.jgss
+ *          jdk.security.auth

Do the test uses KRB5-related cipher suites?

Thanks
Max

> On Sep 14, 2016, at 8:54 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Hi Sergei,
> 
> Thanks for the update.  The fix looks fine to me.  However, I'm not sure why some tests need the "/sun/security/krb5/auto" libraries and the related modules.  As you were already there, would you mind help to test whether the "/sun/security/krb5/auto" library can be removed for some tests?
> 
> Thanks,
> Xuelei
> 
> On 9/14/2016 8:22 PM, Sergei Kovalev wrote:
>> Hello Team,
>> 
>> Could you please review below fix for
>> 
>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
>> Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/
>> 
>> Issue: The test should be able to pass or skipped by JTreg test suite if
>> required modules have not been included in custom JRE.
>> Solution: added '@modules' tags and appropriate module list to tests
>> header.
>> Testing done locally using JTregt test suite.
>> 


From sergei.kovalev at oracle.com  Wed Sep 14 13:58:27 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Wed, 14 Sep 2016 16:58:27 +0300
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
In-Reply-To: <664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
References: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
	<664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
Message-ID: <4b1b170f-105b-5d61-0ec0-7365af46f17c@oracle.com>

Hi Xuelei,

I discovered 53 tests in javax/net/ssl folder that refer to 
/sun/security/krb5/auto. In general it is about 10 unique tests. All the 
tests depends on KDC class. In other places the tests repeated with 
different set of environment variable. e.g. 
"-Dtest.security.protocol=TLSv1.1", etc.

So I cannot remove reference to the library.


14.09.16 15:54, Xuelei Fan wrote:
> Hi Sergei,
>
> Thanks for the update.  The fix looks fine to me.  However, I'm not 
> sure why some tests need the "/sun/security/krb5/auto" libraries and 
> the related modules.  As you were already there, would you mind help 
> to test whether the "/sun/security/krb5/auto" library can be removed 
> for some tests?
>
> Thanks,
> Xuelei
>
> On 9/14/2016 8:22 PM, Sergei Kovalev wrote:
>> Hello Team,
>>
>> Could you please review below fix for
>>
>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
>> Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/
>>
>> Issue: The test should be able to pass or skipped by JTreg test suite if
>> required modules have not been included in custom JRE.
>> Solution: added '@modules' tags and appropriate module list to tests
>> header.
>> Testing done locally using JTregt test suite.
>>

-- 
With best regards,
Sergei


From sergei.kovalev at oracle.com  Wed Sep 14 14:00:12 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Wed, 14 Sep 2016 17:00:12 +0300
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
In-Reply-To: <F6EE79D1-496C-4168-942E-8BA5073450E2@oracle.com>
References: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
	<664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
	<F6EE79D1-496C-4168-942E-8BA5073450E2@oracle.com>
Message-ID: <bfce866f-8332-3008-583f-8df6f3f8a3d7@oracle.com>



14.09.16 16:56, Wang Weijun wrote:
> I also have no idea why these are needed:
>
> + * @modules java.security.jgss
> + *          jdk.security.auth
>
> Do the test uses KRB5-related cipher suites?
The tests using /sun/security/krb5/auto. Looks like it is the root cause.
>
> Thanks
> Max
>
>> On Sep 14, 2016, at 8:54 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> Hi Sergei,
>>
>> Thanks for the update.  The fix looks fine to me.  However, I'm not sure why some tests need the "/sun/security/krb5/auto" libraries and the related modules.  As you were already there, would you mind help to test whether the "/sun/security/krb5/auto" library can be removed for some tests?
>>
>> Thanks,
>> Xuelei
>>
>> On 9/14/2016 8:22 PM, Sergei Kovalev wrote:
>>> Hello Team,
>>>
>>> Could you please review below fix for
>>>
>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
>>> Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/
>>>
>>> Issue: The test should be able to pass or skipped by JTreg test suite if
>>> required modules have not been included in custom JRE.
>>> Solution: added '@modules' tags and appropriate module list to tests
>>> header.
>>> Testing done locally using JTregt test suite.
>>>

-- 
With best regards,
Sergei


From xuelei.fan at oracle.com  Wed Sep 14 14:11:54 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 14 Sep 2016 22:11:54 +0800
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
In-Reply-To: <4b1b170f-105b-5d61-0ec0-7365af46f17c@oracle.com>
References: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
	<664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
	<4b1b170f-105b-5d61-0ec0-7365af46f17c@oracle.com>
Message-ID: <9a6a6e85-1027-31d9-5995-dcf927ea3df1@oracle.com>

OK.  Looks fine to me.

Thanks,
Xuelei

On 9/14/2016 9:58 PM, Sergei Kovalev wrote:
> Hi Xuelei,
>
> I discovered 53 tests in javax/net/ssl folder that refer to
> /sun/security/krb5/auto. In general it is about 10 unique tests. All the
> tests depends on KDC class. In other places the tests repeated with
> different set of environment variable. e.g.
> "-Dtest.security.protocol=TLSv1.1", etc.
>
> So I cannot remove reference to the library.
>
>
> 14.09.16 15:54, Xuelei Fan wrote:
>> Hi Sergei,
>>
>> Thanks for the update.  The fix looks fine to me.  However, I'm not
>> sure why some tests need the "/sun/security/krb5/auto" libraries and
>> the related modules.  As you were already there, would you mind help
>> to test whether the "/sun/security/krb5/auto" library can be removed
>> for some tests?
>>
>> Thanks,
>> Xuelei
>>
>> On 9/14/2016 8:22 PM, Sergei Kovalev wrote:
>>> Hello Team,
>>>
>>> Could you please review below fix for
>>>
>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
>>> Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/
>>>
>>> Issue: The test should be able to pass or skipped by JTreg test suite if
>>> required modules have not been included in custom JRE.
>>> Solution: added '@modules' tags and appropriate module list to tests
>>> header.
>>> Testing done locally using JTregt test suite.
>>>
>

From sean.mullan at oracle.com  Wed Sep 14 15:20:09 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 14 Sep 2016 11:20:09 -0400
Subject: RFR(S): 8165689: Fix module dependencies for
	sun/security/pkcs11/* tests
In-Reply-To: <def25644-a6d3-1c38-7c6c-d38b13e35d84@oracle.com>
References: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
	<def25644-a6d3-1c38-7c6c-d38b13e35d84@oracle.com>
Message-ID: <f6ed057a-b458-768e-8006-5c9c6489ab7a@oracle.com>

Looks fine to me, but can you explain in more detail why the extra 
dependencies are needed, or an example using --limit-modules? These 
tests are not failing regularly now, so when do the missing dependencies 
cause failures?

Thanks,
Sean

On 09/13/2016 08:34 AM, Sergei Kovalev wrote:
> Hello team,
>
> This is re-request for review of very small changes. Could somebody take
> a look?
>
>
> 08.09.16 17:03, Sergei Kovalev wrote:
>> Hello team,
>>
>> Could you please review the fix for below CR:
>>
>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
>> WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/
>>
>> Goal: make test possible to run with "--limit-modules" flag.
>> Summary: added @modules tag into jtreg header if applicable.
>>
>

From sergei.kovalev at oracle.com  Wed Sep 14 15:26:07 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Wed, 14 Sep 2016 18:26:07 +0300
Subject: RFR(S): 8165689: Fix module dependencies for
	sun/security/pkcs11/* tests
In-Reply-To: <f6ed057a-b458-768e-8006-5c9c6489ab7a@oracle.com>
References: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
	<def25644-a6d3-1c38-7c6c-d38b13e35d84@oracle.com>
	<f6ed057a-b458-768e-8006-5c9c6489ab7a@oracle.com>
Message-ID: <670c85b1-905a-7e5e-0a66-7d240b8cd713@oracle.com>

Hi Sean,

I'm working for testing minimal JRE image. If I create custom JRE with 
java.base only - the tests fail. To emulate such behavior we can use 
"--limit-modules java.base" option. In case if we have no module 
declaration in tests header the test fails with, e.g. ClassNotFound 
exception (see example in attached log). In case we declare appropriate 
modules in jtreg header then jtreg suite skip the test and mark it "not 
run" in final report. This help me to clean out all "false positive" 
error during testing and reduce time that I spend to failures analysis.


14.09.16 18:20, Sean Mullan wrote:
> Looks fine to me, but can you explain in more detail why the extra 
> dependencies are needed, or an example using --limit-modules? These 
> tests are not failing regularly now, so when do the missing 
> dependencies cause failures?
>
> Thanks,
> Sean
>
> On 09/13/2016 08:34 AM, Sergei Kovalev wrote:
>> Hello team,
>>
>> This is re-request for review of very small changes. Could somebody take
>> a look?
>>
>>
>> 08.09.16 17:03, Sergei Kovalev wrote:
>>> Hello team,
>>>
>>> Could you please review the fix for below CR:
>>>
>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
>>> WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/
>>>
>>> Goal: make test possible to run with "--limit-modules" flag.
>>> Summary: added @modules tag into jtreg header if applicable.
>>>
>>

-- 
With best regards,
Sergei

-------------- next part --------------
#Test Results (version 2)
#Fri Sep 09 04:42:50 MSK 2016
#-----testdescription-----
$file=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher/ReinitCipher.java
$root=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test
author=Andreas Sterbenz
keywords=bug4856966 randomness othervm
library=..
run=USER_SPECIFIED main/othervm ReinitCipher\nUSER_SPECIFIED main/othervm ReinitCipher sm\n
source=ReinitCipher.java
title=

#-----environment-----

#-----testresult-----
description=file\:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher/ReinitCipher.java
elapsed=1878 0\:00\:01.878
end=Fri Sep 09 04\:42\:50 MSK 2016
environment=regtest
execStatus=Failed. Execution failed\: `main' threw exception\: java.security.NoSuchProviderException\: No PKCS11 provider available
harnessLoaderMode=Classpath Loader
harnessVariety=Full Bundle
hostname=slowpoke.ru.oracle.com
javatestOS=Linux 3.2.0-38-generic (amd64)
javatestVersion=4.6
jtregVersion=jtreg 4.2 fcs b03
script=com.sun.javatest.regtest.RegressionScript
sections=script_messages build compile main
start=Fri Sep 09 04\:42\:48 MSK 2016
test=sun/security/pkcs11/Cipher/ReinitCipher.java
testJDK=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk
totalTime=1882
user.name=hudson
work=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/sun/security/pkcs11/Cipher

#section:script_messages
----------messages:(8/585)----------
JDK under test: /var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk
java version "9-internal"
Java(TM) SE Runtime Environment (build 9-internal+0-2016-09-08-021245.hudson.jake)
Java HotSpot(TM) 64-Bit Server VM (build 9-internal+0-2016-09-08-021245.hudson.jake, mixed mode)

Library ..; kind: packages
   source directory: /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11
   class directory: /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11

#section:build
----------messages:(5/137)----------
command: build ReinitCipher
reason: Named class compiled on demand
Test directory:
  compile: ReinitCipher
elapsed time (seconds): 1.299
result: Passed. Build successful

#section:compile
----------messages:(4/214)----------
command: compile /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher/ReinitCipher.java
reason: .class file out of date or does not exist
Mode: othervm
elapsed time (seconds): 1.291
----------configuration:(6/485)----------
javac compilation environment
  limit modules: java.base 
  class path:    /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher 
                 /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11/Cipher 
                 /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11 

----------rerun:(20/2314)*----------
HOME=/var/lib/hudson \\
JTREG_HOME=/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg \\
LANG=en_US.UTF-8 \\
PATH=/bin:/usr/bin \\
    /var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk/bin/javac \\
        -J-Dtest.src=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher \\
        -J-Dtest.src.path=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11 \\
        -J-Dtest.classes=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11/Cipher \\
        -J-Dtest.class.path=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11/Cipher:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11 \\
        -J-Dtest.vm.opts= \\
        -J-Dtest.tool.vm.opts= \\
        -J-Dtest.compiler.opts='-limitmods java.base' \\
        -J-Dtest.java.opts='-limitmods java.base' \\
        -J-Dtest.jdk=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk \\
        -J-Dcompile.jdk=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk \\
        -J-Dtest.timeout.factor=1.0 \\
        --limit-modules java.base \\
        -d /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11/Cipher \\
        --source-path /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11 \\
        --class-path /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11/Cipher:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11 /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher/ReinitCipher.java
----------System.out:(0/0)----------
----------System.err:(4/377)----------
Note: /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/PKCS11Test.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/PKCS11Test.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
result: Passed. Compilation successful

#section:main
----------messages:(4/154)----------
command: main ReinitCipher
reason: User specified action: run main/othervm ReinitCipher 
Mode: othervm [/othervm specified]
elapsed time (seconds): 0.444
----------configuration:(3/40)----------
Boot Layer
  limit modules: java.base 

----------System.out:(2/75)----------
libsoftokn3 version = 3.21.  ECC Basic.
Beginning test run ReinitCipher...
----------System.err:(29/2120)----------
java.lang.ClassNotFoundException: sun.security.pkcs11.SunPKCS11
	at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-internal/BuiltinClassLoader.java:481)
	at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-internal/ClassLoaders.java:185)
	at java.lang.ClassLoader.loadClass(java.base at 9-internal/ClassLoader.java:419)
	at java.lang.Class.forName0(java.base at 9-internal/Native Method)
	at java.lang.Class.forName(java.base at 9-internal/Class.java:291)
	at PKCS11Test.<clinit>(PKCS11Test.java:124)
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-internal/Native Method)
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-internal/NativeMethodAccessorImpl.java:62)
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-internal/DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(java.base at 9-internal/Method.java:535)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
	at java.lang.Thread.run(java.base at 9-internal/Thread.java:843)
java.security.NoSuchProviderException: No PKCS11 provider available
	at PKCS11Test.getSunPKCS11(PKCS11Test.java:149)
	at PKCS11Test.testNSS(PKCS11Test.java:518)
	at PKCS11Test.main(PKCS11Test.java:203)
	at ReinitCipher.main(ReinitCipher.java:43)
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-internal/Native Method)
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-internal/NativeMethodAccessorImpl.java:62)
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-internal/DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(java.base at 9-internal/Method.java:535)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
	at java.lang.Thread.run(java.base at 9-internal/Thread.java:843)

JavaTest Message: Test threw exception: java.security.NoSuchProviderException: No PKCS11 provider available
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.security.NoSuchProviderException: No PKCS11 provider available
----------rerun:(19/2256)*----------
HOME=/var/lib/hudson \\
JTREG_HOME=/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg \\
LANG=en_US.UTF-8 \\
PATH=/bin:/usr/bin \\
CLASSPATH=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11/Cipher:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11:/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg/lib/javatest.jar:/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg/lib/jtreg.jar \\
    /var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk/bin/java \\
        -Dtest.src=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher \\
        -Dtest.src.path=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11/Cipher:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/sun/security/pkcs11 \\
        -Dtest.classes=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11/Cipher \\
        -Dtest.class.path=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11/Cipher:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/classes/sun/security/pkcs11 \\
        -Dtest.vm.opts= \\
        -Dtest.tool.vm.opts= \\
        -Dtest.compiler.opts='-limitmods java.base' \\
        -Dtest.java.opts='-limitmods java.base' \\
        -Dtest.jdk=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk \\
        -Dcompile.jdk=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk \\
        -Dtest.timeout.factor=1.0 \\
        --limit-modules java.base \\
        com.sun.javatest.regtest.agent.MainWrapper /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-sun-security-pkcs11-Cipher-ReinitCipher-java_0/sun/security/pkcs11/Cipher/ReinitCipher.d/main.0.jta
result: Failed. Execution failed: `main' threw exception: java.security.NoSuchProviderException: No PKCS11 provider available


test result: Failed. Execution failed: `main' threw exception: java.security.NoSuchProviderException: No PKCS11 provider available

From weijun.wang at oracle.com  Wed Sep 14 15:44:58 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 14 Sep 2016 23:44:58 +0800
Subject: RFR(S): 8165689: Fix module dependencies for
	sun/security/pkcs11/* tests
In-Reply-To: <670c85b1-905a-7e5e-0a66-7d240b8cd713@oracle.com>
References: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
	<def25644-a6d3-1c38-7c6c-d38b13e35d84@oracle.com>
	<f6ed057a-b458-768e-8006-5c9c6489ab7a@oracle.com>
	<670c85b1-905a-7e5e-0a66-7d240b8cd713@oracle.com>
Message-ID: <8F357096-3F1E-44C5-ACB1-209C919879BD@oracle.com>

The example shows jdk.crypto.pkcs11 is needed, but I still don't know why java.security.jgss is. Can you give another example where jgss must be present?

Thanks
Max

> ? 2016?9?14??23:26?Sergei Kovalev <sergei.kovalev at oracle.com> ???
> 
> Hi Sean,
> 
> I'm working for testing minimal JRE image. If I create custom JRE with java.base only - the tests fail. To emulate such behavior we can use "--limit-modules java.base" option. In case if we have no module declaration in tests header the test fails with, e.g. ClassNotFound exception (see example in attached log). In case we declare appropriate modules in jtreg header then jtreg suite skip the test and mark it "not run" in final report. This help me to clean out all "false positive" error during testing and reduce time that I spend to failures analysis.
> 
> 
> 14.09.16 18:20, Sean Mullan wrote:
>> Looks fine to me, but can you explain in more detail why the extra dependencies are needed, or an example using --limit-modules? These tests are not failing regularly now, so when do the missing dependencies cause failures?
>> 
>> Thanks,
>> Sean
>> 
>>> On 09/13/2016 08:34 AM, Sergei Kovalev wrote:
>>> Hello team,
>>> 
>>> This is re-request for review of very small changes. Could somebody take
>>> a look?
>>> 
>>> 
>>> 08.09.16 17:03, Sergei Kovalev wrote:
>>>> Hello team,
>>>> 
>>>> Could you please review the fix for below CR:
>>>> 
>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
>>>> WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/
>>>> 
>>>> Goal: make test possible to run with "--limit-modules" flag.
>>>> Summary: added @modules tag into jtreg header if applicable.
>>>> 
>>> 
> 
> -- 
> With best regards,
> Sergei
> 
> <ReinitCipher.jtr.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160914/83cbb103/attachment.html>

From weijun.wang at oracle.com  Wed Sep 14 15:54:01 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 14 Sep 2016 23:54:01 +0800
Subject: RFR(S): 8165689: Fix module dependencies for
	sun/security/pkcs11/* tests
In-Reply-To: <8F357096-3F1E-44C5-ACB1-209C919879BD@oracle.com>
References: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
	<def25644-a6d3-1c38-7c6c-d38b13e35d84@oracle.com>
	<f6ed057a-b458-768e-8006-5c9c6489ab7a@oracle.com>
	<670c85b1-905a-7e5e-0a66-7d240b8cd713@oracle.com>
	<8F357096-3F1E-44C5-ACB1-209C919879BD@oracle.com>
Message-ID: <5474E087-E825-40FA-847C-AACC6EDEEA5C@oracle.com>

Sorry I was thinking about another bug on TLS tests -- 8166032. What exception is thrown there if the jgss module is missing?

Thanks
Max

> ? 2016?9?14??23:44?Wang Weijun <weijun.wang at oracle.com> ???
> 
> The example shows jdk.crypto.pkcs11 is needed, but I still don't know why java.security.jgss is. Can you give another example where jgss must be present?
> 
> Thanks
> Max
> 
>> ? 2016?9?14??23:26?Sergei Kovalev <sergei.kovalev at oracle.com> ???
>> 
>> Hi Sean,
>> 
>> I'm working for testing minimal JRE image. If I create custom JRE with java.base only - the tests fail. To emulate such behavior we can use "--limit-modules java.base" option. In case if we have no module declaration in tests header the test fails with, e.g. ClassNotFound exception (see example in attached log). In case we declare appropriate modules in jtreg header then jtreg suite skip the test and mark it "not run" in final report. This help me to clean out all "false positive" error during testing and reduce time that I spend to failures analysis.
>> 
>> 
>> 14.09.16 18:20, Sean Mullan wrote:
>>> Looks fine to me, but can you explain in more detail why the extra dependencies are needed, or an example using --limit-modules? These tests are not failing regularly now, so when do the missing dependencies cause failures?
>>> 
>>> Thanks,
>>> Sean
>>> 
>>>> On 09/13/2016 08:34 AM, Sergei Kovalev wrote:
>>>> Hello team,
>>>> 
>>>> This is re-request for review of very small changes. Could somebody take
>>>> a look?
>>>> 
>>>> 
>>>> 08.09.16 17:03, Sergei Kovalev wrote:
>>>>> Hello team,
>>>>> 
>>>>> Could you please review the fix for below CR:
>>>>> 
>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
>>>>> WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/
>>>>> 
>>>>> Goal: make test possible to run with "--limit-modules" flag.
>>>>> Summary: added @modules tag into jtreg header if applicable.
>>>>> 
>>>> 
>> 
>> -- 
>> With best regards,
>> Sergei
>> 
>> <ReinitCipher.jtr.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160914/43112928/attachment-0001.html>

From sergei.kovalev at oracle.com  Wed Sep 14 15:57:51 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Wed, 14 Sep 2016 18:57:51 +0300
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
In-Reply-To: <F6EE79D1-496C-4168-942E-8BA5073450E2@oracle.com>
References: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
	<664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
	<F6EE79D1-496C-4168-942E-8BA5073450E2@oracle.com>
Message-ID: <faab25f2-88f1-c8e5-a39f-bc5f04df4f95@oracle.com>

here it is an example

  jtreg -verbose:all -jdk /home/skovalev/TRASH/jdk-9 
-javaoptions:"--limit-modules java.base" 
/home/skovalev/repos/jdk9-dev/jdk/test/javax/net/ssl/TLSv11/TLSHandshakeTest.java


STDOUT:
Error occurred during initialization of VM
java.lang.module.ResolutionException: Module java.naming not found, 
required by java.security.jgss
         at java.lang.module.Resolver.fail(java.base at 9-ea/Resolver.java:790)
         at 
java.lang.module.Resolver.resolve(java.base at 9-ea/Resolver.java:138)
         at 
java.lang.module.Resolver.resolveRequires(java.base at 9-ea/Resolver.java:108)
         at 
java.lang.module.Configuration.resolveRequiresAndUses(java.base at 9-ea/Configuration.java:370)
         at 
java.lang.module.ModuleDescriptor$1.resolveRequiresAndUses(java.base at 9-ea/ModuleDescriptor.java:1986)
         at 
jdk.internal.module.ModuleBootstrap.boot(java.base at 9-ea/ModuleBootstrap.java:263)
         at java.lang.System.initPhase2(java.base at 9-ea/System.java:1927)

> Sorry I was thinking about another bug on TLS tests -- 8166032. What 
> exception is thrown there if the jgss module is missing?
>
> Thanks
> Max
>
> ? 2016?9?14??23:44?Wang Weijun <weijun.wang at oracle.com 
> <mailto:weijun.wang at oracle.com>> ???
>
> The example shows jdk.crypto.pkcs11 is needed, but I still don't know 
> why java.security.jgss is. Can you give another example where jgss 
> must be present?
>
> Thanks
> Max

14.09.16 16:56, Wang Weijun wrote:
> I also have no idea why these are needed:
>
> + * @modules java.security.jgss
> + *          jdk.security.auth
>
> Do the test uses KRB5-related cipher suites?
>
> Thanks
> Max
>
>> On Sep 14, 2016, at 8:54 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> Hi Sergei,
>>
>> Thanks for the update.  The fix looks fine to me.  However, I'm not sure why some tests need the "/sun/security/krb5/auto" libraries and the related modules.  As you were already there, would you mind help to test whether the "/sun/security/krb5/auto" library can be removed for some tests?
>>
>> Thanks,
>> Xuelei
>>
>> On 9/14/2016 8:22 PM, Sergei Kovalev wrote:
>>> Hello Team,
>>>
>>> Could you please review below fix for
>>>
>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8166032
>>> Code review: http://cr.openjdk.java.net/~skovalev/8166032/webrev.00/
>>>
>>> Issue: The test should be able to pass or skipped by JTreg test suite if
>>> required modules have not been included in custom JRE.
>>> Solution: added '@modules' tags and appropriate module list to tests
>>> header.
>>> Testing done locally using JTregt test suite.
>>>

-- 
With best regards,
Sergei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160914/52847b18/attachment.html>

From sergei.kovalev at oracle.com  Wed Sep 14 15:58:09 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Wed, 14 Sep 2016 18:58:09 +0300
Subject: RFR(S): 8165689: Fix module dependencies for
	sun/security/pkcs11/* tests
In-Reply-To: <5474E087-E825-40FA-847C-AACC6EDEEA5C@oracle.com>
References: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
	<def25644-a6d3-1c38-7c6c-d38b13e35d84@oracle.com>
	<f6ed057a-b458-768e-8006-5c9c6489ab7a@oracle.com>
	<670c85b1-905a-7e5e-0a66-7d240b8cd713@oracle.com>
	<8F357096-3F1E-44C5-ACB1-209C919879BD@oracle.com>
	<5474E087-E825-40FA-847C-AACC6EDEEA5C@oracle.com>
Message-ID: <d2e4c626-6e7c-4f83-2df2-cba44a85b128@oracle.com>

Answered in other thread


14.09.16 18:54, Wang Weijun wrote:
> Sorry I was thinking about another bug on TLS tests -- 8166032. What 
> exception is thrown there if the jgss module is missing?
>
> Thanks
> Max
>
> ? 2016?9?14??23:44?Wang Weijun <weijun.wang at oracle.com 
> <mailto:weijun.wang at oracle.com>> ???
>
>> The example shows jdk.crypto.pkcs11 is needed, but I still don't know 
>> why java.security.jgss is. Can you give another example where jgss 
>> must be present?
>>
>> Thanks
>> Max

-- 
With best regards,
Sergei

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160914/acc6ee63/attachment.html>

From sean.mullan at oracle.com  Wed Sep 14 16:57:54 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 14 Sep 2016 12:57:54 -0400
Subject: RFR(S): 8165689: Fix module dependencies for
	sun/security/pkcs11/* tests
In-Reply-To: <670c85b1-905a-7e5e-0a66-7d240b8cd713@oracle.com>
References: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
	<def25644-a6d3-1c38-7c6c-d38b13e35d84@oracle.com>
	<f6ed057a-b458-768e-8006-5c9c6489ab7a@oracle.com>
	<670c85b1-905a-7e5e-0a66-7d240b8cd713@oracle.com>
Message-ID: <b0f8f0be-23cd-e3e7-4ef7-3bdcb0191c8f@oracle.com>

Thanks for the information. It would be very useful if you could add 
that additional information as an example into the bug report for future 
reference.

--Sean

On 09/14/2016 11:26 AM, Sergei Kovalev wrote:
> Hi Sean,
>
> I'm working for testing minimal JRE image. If I create custom JRE with
> java.base only - the tests fail. To emulate such behavior we can use
> "--limit-modules java.base" option. In case if we have no module
> declaration in tests header the test fails with, e.g. ClassNotFound
> exception (see example in attached log). In case we declare appropriate
> modules in jtreg header then jtreg suite skip the test and mark it "not
> run" in final report. This help me to clean out all "false positive"
> error during testing and reduce time that I spend to failures analysis.
>
>
> 14.09.16 18:20, Sean Mullan wrote:
>> Looks fine to me, but can you explain in more detail why the extra
>> dependencies are needed, or an example using --limit-modules? These
>> tests are not failing regularly now, so when do the missing
>> dependencies cause failures?
>>
>> Thanks,
>> Sean
>>
>> On 09/13/2016 08:34 AM, Sergei Kovalev wrote:
>>> Hello team,
>>>
>>> This is re-request for review of very small changes. Could somebody take
>>> a look?
>>>
>>>
>>> 08.09.16 17:03, Sergei Kovalev wrote:
>>>> Hello team,
>>>>
>>>> Could you please review the fix for below CR:
>>>>
>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
>>>> WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/
>>>>
>>>> Goal: make test possible to run with "--limit-modules" flag.
>>>> Summary: added @modules tag into jtreg header if applicable.
>>>>
>>>
>

From weijun.wang at oracle.com  Wed Sep 14 22:21:20 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 15 Sep 2016 06:21:20 +0800
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
In-Reply-To: <faab25f2-88f1-c8e5-a39f-bc5f04df4f95@oracle.com>
References: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
	<664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
	<F6EE79D1-496C-4168-942E-8BA5073450E2@oracle.com>
	<faab25f2-88f1-c8e5-a39f-bc5f04df4f95@oracle.com>
Message-ID: <CB9B59BB-0E7D-4A23-8783-6C18612B29CC@oracle.com>

Confusing. This does not show why jgss is needed. I'll do some investigation. 

Thanks
Max

> ? 2016?9?14??23:57?Sergei Kovalev <sergei.kovalev at oracle.com> ???
> 
> java.lang.module.ResolutionException: Module java.naming not found, required by java.security.jgss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160915/5935421f/attachment.html>

From xuelei.fan at oracle.com  Wed Sep 14 23:39:47 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 Sep 2016 07:39:47 +0800
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
In-Reply-To: <CB9B59BB-0E7D-4A23-8783-6C18612B29CC@oracle.com>
References: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
	<664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
	<F6EE79D1-496C-4168-942E-8BA5073450E2@oracle.com>
	<faab25f2-88f1-c8e5-a39f-bc5f04df4f95@oracle.com>
	<CB9B59BB-0E7D-4A23-8783-6C18612B29CC@oracle.com>
Message-ID: <8253caf2-3f9f-344d-b946-662e6c49b151@oracle.com>

I did some research yesterday.  The "/javax/net/ssl/TLSCommon" lib 
depends on krb5.  For example, BufferOverflowUnderflowTest need to set 
up KDC and test krb5 cipher suites.

Xuelei

On 9/15/2016 6:21 AM, Wang Weijun wrote:
> Confusing. This does not show why jgss is needed. I'll do some
> investigation.
>
> Thanks
> Max
>
> ? 2016?9?14??23:57?Sergei Kovalev <sergei.kovalev at oracle.com
> <mailto:sergei.kovalev at oracle.com>> ???
>
>> java.lang.module.ResolutionException: Module java.naming not found,
>> required by java.security.jgss

From xuelei.fan at oracle.com  Thu Sep 15 00:09:42 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 Sep 2016 08:09:42 +0800
Subject: Code Review Request, JDK-8146600 AVA Normalizer.Form issue
Message-ID: <f6aaa6a7-e930-43d2-0ba8-b01a74534b97@oracle.com>

Hi,

Please review this fix:
     http://cr.openjdk.java.net/~xuelei/8146600/webrev.00/

The Normalizer.Form.NFKD is used to normalize attribute-value assertion 
in X.509 certificate processing.  The normalizer may convert some UTF-8 
character into ASCII code.  For example, "?"(two bytes) will be 
converted to ","(one byte), and "Hello? world!" is normalize to "Hello, 
world!".  However, "Hello, world!" and "Hello? world!" should be 
different because of the comma code.  This conversion may result in 
unexpected weird behaviors for name comparing and conversions.

This fix will update to use "Normalizer.Form.NFD".

Thanks,
Xuelei

From artem.smotrakov at oracle.com  Thu Sep 15 00:47:30 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 14 Sep 2016 17:47:30 -0700
Subject: [9] RFR: 8163924: SSLEngineBadBufferArrayAccess.java fails
	intermittently with Unrecognized SSL message
In-Reply-To: <414130c7-6d1f-f3e7-e50c-215b5b2f03a1@oracle.com>
References: <3c45c05b-1da2-7e5d-1099-7b314f40bd5e@oracle.com>
	<746499ff-4b8b-15ef-e4fe-d66ca72363e1@oracle.com>
	<414130c7-6d1f-f3e7-e50c-215b5b2f03a1@oracle.com>
Message-ID: <5cd19c99-f5e7-33e9-b6f7-385cfc004563@oracle.com>

Hi Xuelei,

Sure, I am fine to use the approach which is implemented in 
SSLSocketSample.java. But please note that 
SSLEngineBadBufferArrayAccess.java test uses ServerSocket+SSEngine on 
server side, so I applied the approach from SSLSocketSample.java to the 
test:

http://cr.openjdk.java.net/~asmotrak/8163924/webrev.01/

If everything is okay, I am going to apply this approach to other test 
bugs we have.

I am wondering if we could move some common code from 
SSLSocketSample.java to a helper class, so that it could be re-used by 
other tests (not for all of them because tests may be different). It 
might reduce some duplicate code.

Artem


On 09/13/2016 06:39 PM, Xuelei Fan wrote:
> I think the failure may caused by using free port by other test cases. 
> As you were already there, would you mind update to use the 
> SSLSocketSample.java template under the folder 
> test/javax/net/ssl/templates?
>
> Thanks,
> Xuelei
>
> On 9/14/2016 9:31 AM, Artem Smotrakov wrote:
>> Hello,
>>
>> Not urgent, but I would appreciate if somebody can take a look at the
>> webrev below and webvev for 8164591. Thank you!
>>
>> Artem
>>
>> On 09/07/2016 02:58 PM, Artem Smotrakov wrote:
>>> Hello,
>>>
>>> Please review the following patch for
>>> SSLEngineBadBufferArrayAccess.java test.
>>>
>>> The test has been observed to fail intermittently with "Unrecognized
>>> SSL message" error. I couldn't reproduce it, and it's currently not
>>> clear what caused the test to fail. One guess is that something else
>>> might connect to the server which caused this error. The patch enables
>>> additional debug output, so that we have more info if it fails next
>>> time. JTREG truncates logs, but it's fine since we are interested only
>>> in last handshaking.
>>>
>>> The patch also updates the test to report unexpected exceptions, and
>>> close files and sockets.
>>>
>>> Any other suggestions are very welcome.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163924
>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8163924/webrev.00/
>>>
>>> Artem
>>>
>>


From artem.smotrakov at oracle.com  Thu Sep 15 01:13:11 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 14 Sep 2016 18:13:11 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
Message-ID: <5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>

Not urgent, but I would appreciate if someone can get a chance to look 
at this.

Artem


On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
> Sending to net-dev at openjdk.java.net as well.
>
> Artem
>
>
> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>> Hello,
>>
>> Please review the following patch for 
>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>
>> The test has been observed to fail a couple of times, but it's still 
>> not clear why it failed because there is not much info in logs. The 
>> patch updates the test to enable additional debug output, so that we 
>> have more info if it fails next time.
>>
>> While looking at the test, I notices a couple of issues, but they 
>> don't seem to cause these intermittent failures:
>> - The test sets system properties for JSSE in a loop, but JSSE 
>> provider reads them only once while initialization. As a result, only 
>> values which were set in the first iteration are actually used.
>> - The test doesn't close files and sockets sometimes.
>>
>> The patch also fixed the issues above, and there are a couple 
>> cosmetic changes.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>
>> Artem
>


From xuelei.fan at oracle.com  Thu Sep 15 01:19:36 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 Sep 2016 09:19:36 +0800
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
Message-ID: <20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>

As you were already there, I would suggest to consider the 
SSLSocketSample.java template as the comment in JDK-8163924 review thread.

Thanks,
Xuelei

On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
> Not urgent, but I would appreciate if someone can get a chance to look
> at this.
>
> Artem
>
>
> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>> Sending to net-dev at openjdk.java.net as well.
>>
>> Artem
>>
>>
>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>> Hello,
>>>
>>> Please review the following patch for
>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>
>>> The test has been observed to fail a couple of times, but it's still
>>> not clear why it failed because there is not much info in logs. The
>>> patch updates the test to enable additional debug output, so that we
>>> have more info if it fails next time.
>>>
>>> While looking at the test, I notices a couple of issues, but they
>>> don't seem to cause these intermittent failures:
>>> - The test sets system properties for JSSE in a loop, but JSSE
>>> provider reads them only once while initialization. As a result, only
>>> values which were set in the first iteration are actually used.
>>> - The test doesn't close files and sockets sometimes.
>>>
>>> The patch also fixed the issues above, and there are a couple
>>> cosmetic changes.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>
>>> Artem
>>
>

From artem.smotrakov at oracle.com  Thu Sep 15 01:23:09 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 14 Sep 2016 18:23:09 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
Message-ID: <80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>

Hi Xuelei,

For this one, I am not sure that it would help here since the test 
failed after it already had started handshaking. I would prefer to have 
it as a separate enhancement.

Artem


On 09/14/2016 06:19 PM, Xuelei Fan wrote:
> As you were already there, I would suggest to consider the 
> SSLSocketSample.java template as the comment in JDK-8163924 review 
> thread.
>
> Thanks,
> Xuelei
>
> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>> Not urgent, but I would appreciate if someone can get a chance to look
>> at this.
>>
>> Artem
>>
>>
>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>> Sending to net-dev at openjdk.java.net as well.
>>>
>>> Artem
>>>
>>>
>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>> Hello,
>>>>
>>>> Please review the following patch for
>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>
>>>> The test has been observed to fail a couple of times, but it's still
>>>> not clear why it failed because there is not much info in logs. The
>>>> patch updates the test to enable additional debug output, so that we
>>>> have more info if it fails next time.
>>>>
>>>> While looking at the test, I notices a couple of issues, but they
>>>> don't seem to cause these intermittent failures:
>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>> provider reads them only once while initialization. As a result, only
>>>> values which were set in the first iteration are actually used.
>>>> - The test doesn't close files and sockets sometimes.
>>>>
>>>> The patch also fixed the issues above, and there are a couple
>>>> cosmetic changes.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>
>>>> Artem
>>>
>>


From weijun.wang at oracle.com  Thu Sep 15 01:36:54 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 15 Sep 2016 09:36:54 +0800
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
In-Reply-To: <8253caf2-3f9f-344d-b946-662e6c49b151@oracle.com>
References: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
	<664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
	<F6EE79D1-496C-4168-942E-8BA5073450E2@oracle.com>
	<faab25f2-88f1-c8e5-a39f-bc5f04df4f95@oracle.com>
	<CB9B59BB-0E7D-4A23-8783-6C18612B29CC@oracle.com>
	<8253caf2-3f9f-344d-b946-662e6c49b151@oracle.com>
Message-ID: <6883EFCF-8873-4F45-98DB-61E36ABAF6BF@oracle.com>

I see. But krb5 cipher suites is just a very small part of TLS. Maybe we can tweak the tests a little so that they can work without JGSS.

I am fine with the change at the moment.

Thanks
Max

> On Sep 15, 2016, at 7:39 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> I did some research yesterday.  The "/javax/net/ssl/TLSCommon" lib depends on krb5.  For example, BufferOverflowUnderflowTest need to set up KDC and test krb5 cipher suites.
> 
> Xuelei
> 
> On 9/15/2016 6:21 AM, Wang Weijun wrote:
>> Confusing. This does not show why jgss is needed. I'll do some
>> investigation.
>> 
>> Thanks
>> Max
>> 
>> ? 2016?9?14??23:57?Sergei Kovalev <sergei.kovalev at oracle.com
>> <mailto:sergei.kovalev at oracle.com>> ???
>> 
>>> java.lang.module.ResolutionException: Module java.naming not found,
>>> required by java.security.jgss


From xuelei.fan at oracle.com  Thu Sep 15 01:39:58 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 Sep 2016 09:39:58 +0800
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
Message-ID: <8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>

On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
> Hi Xuelei,
>
> For this one, I am not sure that it would help here since the test
> failed after it already had started handshaking.
It has the same issue as a free-port is used.  We don't actually know 
the handshake is coming from the right client.

Xuelei

> I would prefer to have it as a separate enhancement.
>
> Artem
>
>
> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>> As you were already there, I would suggest to consider the
>> SSLSocketSample.java template as the comment in JDK-8163924 review
>> thread.
>>
>> Thanks,
>> Xuelei
>>
>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>> Not urgent, but I would appreciate if someone can get a chance to look
>>> at this.
>>>
>>> Artem
>>>
>>>
>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>> Sending to net-dev at openjdk.java.net as well.
>>>>
>>>> Artem
>>>>
>>>>
>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following patch for
>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>
>>>>> The test has been observed to fail a couple of times, but it's still
>>>>> not clear why it failed because there is not much info in logs. The
>>>>> patch updates the test to enable additional debug output, so that we
>>>>> have more info if it fails next time.
>>>>>
>>>>> While looking at the test, I notices a couple of issues, but they
>>>>> don't seem to cause these intermittent failures:
>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>> provider reads them only once while initialization. As a result, only
>>>>> values which were set in the first iteration are actually used.
>>>>> - The test doesn't close files and sockets sometimes.
>>>>>
>>>>> The patch also fixed the issues above, and there are a couple
>>>>> cosmetic changes.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>
>>>>> Artem
>>>>
>>>
>

From xuelei.fan at oracle.com  Thu Sep 15 01:42:16 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 Sep 2016 09:42:16 +0800
Subject: RFR(M): 8166032: Fix module dependencies for javax.SSL tests
In-Reply-To: <6883EFCF-8873-4F45-98DB-61E36ABAF6BF@oracle.com>
References: <baf4998a-18c0-0ce2-16c6-55a135ef78d1@oracle.com>
	<664a532a-d8aa-4614-d2d5-ccdaab6e9270@oracle.com>
	<F6EE79D1-496C-4168-942E-8BA5073450E2@oracle.com>
	<faab25f2-88f1-c8e5-a39f-bc5f04df4f95@oracle.com>
	<CB9B59BB-0E7D-4A23-8783-6C18612B29CC@oracle.com>
	<8253caf2-3f9f-344d-b946-662e6c49b151@oracle.com>
	<6883EFCF-8873-4F45-98DB-61E36ABAF6BF@oracle.com>
Message-ID: <36206bfe-f330-a56d-2288-698efedd63ad@oracle.com>



On 9/15/2016 9:36 AM, Wang Weijun wrote:
> I see. But krb5 cipher suites is just a very small part of TLS. Maybe we can tweak the tests a little so that they can work without JGSS.
>
Agreed.  I don't like the dependence, too.  Let's consider an 
enhancement later in a separate enhancement.

Xuelei

> I am fine with the change at the moment.
>
> Thanks
> Max
>
>> On Sep 15, 2016, at 7:39 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> I did some research yesterday.  The "/javax/net/ssl/TLSCommon" lib depends on krb5.  For example, BufferOverflowUnderflowTest need to set up KDC and test krb5 cipher suites.
>>
>> Xuelei
>>
>> On 9/15/2016 6:21 AM, Wang Weijun wrote:
>>> Confusing. This does not show why jgss is needed. I'll do some
>>> investigation.
>>>
>>> Thanks
>>> Max
>>>
>>> ? 2016?9?14??23:57?Sergei Kovalev <sergei.kovalev at oracle.com
>>> <mailto:sergei.kovalev at oracle.com>> ???
>>>
>>>> java.lang.module.ResolutionException: Module java.naming not found,
>>>> required by java.security.jgss
>

From artem.smotrakov at oracle.com  Thu Sep 15 01:45:10 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 14 Sep 2016 18:45:10 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
Message-ID: <4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>

Well, in this particular case it's not clear that it has the same issue 
with free port (at least to me). The exception occurred on client side, 
so it's not the case where we don't know where the handshake came from.

I can make this enhancement, but like I said I don't think it's going to 
help, so I would like to keep debug output on.

Artem


On 09/14/2016 06:39 PM, Xuelei Fan wrote:
> On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
>> Hi Xuelei,
>>
>> For this one, I am not sure that it would help here since the test
>> failed after it already had started handshaking.
> It has the same issue as a free-port is used.  We don't actually know 
> the handshake is coming from the right client.
>
> Xuelei
>
>> I would prefer to have it as a separate enhancement.
>>
>> Artem
>>
>>
>> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>>> As you were already there, I would suggest to consider the
>>> SSLSocketSample.java template as the comment in JDK-8163924 review
>>> thread.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>>> Not urgent, but I would appreciate if someone can get a chance to look
>>>> at this.
>>>>
>>>> Artem
>>>>
>>>>
>>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>>> Sending to net-dev at openjdk.java.net as well.
>>>>>
>>>>> Artem
>>>>>
>>>>>
>>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following patch for
>>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>>
>>>>>> The test has been observed to fail a couple of times, but it's still
>>>>>> not clear why it failed because there is not much info in logs. The
>>>>>> patch updates the test to enable additional debug output, so that we
>>>>>> have more info if it fails next time.
>>>>>>
>>>>>> While looking at the test, I notices a couple of issues, but they
>>>>>> don't seem to cause these intermittent failures:
>>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>>> provider reads them only once while initialization. As a result, 
>>>>>> only
>>>>>> values which were set in the first iteration are actually used.
>>>>>> - The test doesn't close files and sockets sometimes.
>>>>>>
>>>>>> The patch also fixed the issues above, and there are a couple
>>>>>> cosmetic changes.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>>
>>>>>> Artem
>>>>>
>>>>
>>


From xuelei.fan at oracle.com  Thu Sep 15 01:55:56 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 15 Sep 2016 09:55:56 +0800
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
	<4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
Message-ID: <ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>

On 9/15/2016 9:45 AM, Artem Smotrakov wrote:
> Well, in this particular case it's not clear that it has the same issue
> with free port (at least to me). The exception occurred on client side,
> so it's not the case where we don't know where the handshake came from.
>
;-) Yeh, you catch the point.  But there is a free-port issue although 
the exception stack in the bug description may be not that case.

Let's look at a scenarios:
1. server open a server socket and listen.
2. other test case connect to the server socket.
3. this test case try to connect to server socket.
4. this test case would fail as the server only accept one connections.

I did not check it very carefully, I think for #4, the exception stack 
can be similar to the one in the bug description.

Anyway, as a free port is used, there are free-port issues.  Please 
consider to make the enhancement in the fix.  Otherwise, you cannot 
avoid the intermittent failure for this test case in the current testing 
environment.

Xuelei

> I can make this enhancement, but like I said I don't think it's going to
> help, so I would like to keep debug output on.
>
> Artem
>
>
> On 09/14/2016 06:39 PM, Xuelei Fan wrote:
>> On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
>>> Hi Xuelei,
>>>
>>> For this one, I am not sure that it would help here since the test
>>> failed after it already had started handshaking.
>> It has the same issue as a free-port is used.  We don't actually know
>> the handshake is coming from the right client.
>>
>> Xuelei
>>
>>> I would prefer to have it as a separate enhancement.
>>>
>>> Artem
>>>
>>>
>>> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>>>> As you were already there, I would suggest to consider the
>>>> SSLSocketSample.java template as the comment in JDK-8163924 review
>>>> thread.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>>>> Not urgent, but I would appreciate if someone can get a chance to look
>>>>> at this.
>>>>>
>>>>> Artem
>>>>>
>>>>>
>>>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>>>> Sending to net-dev at openjdk.java.net as well.
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>>
>>>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the following patch for
>>>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>>>
>>>>>>> The test has been observed to fail a couple of times, but it's still
>>>>>>> not clear why it failed because there is not much info in logs. The
>>>>>>> patch updates the test to enable additional debug output, so that we
>>>>>>> have more info if it fails next time.
>>>>>>>
>>>>>>> While looking at the test, I notices a couple of issues, but they
>>>>>>> don't seem to cause these intermittent failures:
>>>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>>>> provider reads them only once while initialization. As a result,
>>>>>>> only
>>>>>>> values which were set in the first iteration are actually used.
>>>>>>> - The test doesn't close files and sockets sometimes.
>>>>>>>
>>>>>>> The patch also fixed the issues above, and there are a couple
>>>>>>> cosmetic changes.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>>>
>>>>>>> Artem
>>>>>>
>>>>>
>>>
>

From sibabrata.sahoo at oracle.com  Thu Sep 15 06:39:46 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Wed, 14 Sep 2016 23:39:46 -0700 (PDT)
Subject: [9] RFR: 8156054: Test Task: Develop new tests for JEP C155:
	Remove FilePermission Pathname Canonicalization
In-Reply-To: <b029311b-2f95-2bc6-aac9-ecce623b70bd@oracle.com>
References: <fbd80ba6-8b64-49c0-bc89-6db6ba72027d@default>
	<b029311b-2f95-2bc6-aac9-ecce623b70bd@oracle.com>
Message-ID: <9ad733cd-3269-4f2d-965a-976d8f1b6729@default>

Hi Artem,

 

I think building a String value from the actual result and displaying it against expected in the Log output will be more convenient here. 

 

Thanks,

Siba

 

From: Artem Smotrakov 
Sent: Tuesday, September 13, 2016 10:54 PM
To: Sibabrata Sahoo; Weijun Wang; security-dev at openjdk.java.net
Subject: Re: [9] RFR: 8156054: Test Task: Develop new tests for JEP C155: Remove FilePermission Pathname Canonicalization

 

Hi Siba,

I see that the test expects only true or false. You can just pass these boolean values, and check() can make sure that everything returns the expected boolean value without building a string. That would be clearer to me. Not an issue, it's up to you to change it or not.

Artem

 

On 09/13/2016 03:14 AM, Sibabrata Sahoo wrote:

Hi,

 

Please review the patch for,

 

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Essahoo/8156054/webrev.00/"http://cr.openjdk.java.net/~ssahoo/8156054/webrev.00/

 

Description: 

It checks equals(), implies() and hashCode () of FilePermission when "jdk.io.permissionsUseCanonicalPath" set and un-set. Along with, it also verify compatibility with previous JDK version.

 

 

Thanks,

Siba

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160914/3331558a/attachment.html>

From chris.hegarty at oracle.com  Thu Sep 15 07:53:17 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 15 Sep 2016 08:53:17 +0100
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
	failed with SSLHandshakeException
In-Reply-To: <ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
	<4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
	<ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>
Message-ID: <1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>

On 15 Sep 2016, at 02:55, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 9/15/2016 9:45 AM, Artem Smotrakov wrote:
>> Well, in this particular case it's not clear that it has the same issue
>> with free port (at least to me). The exception occurred on client side,
>> so it's not the case where we don't know where the handshake came from.
>> 
> ;-) Yeh, you catch the point.  But there is a free-port issue although the exception stack in the bug description may be not that case.
> 
> Let's look at a scenarios:
> 1. server open a server socket and listen.
> 2. other test case connect to the server socket.
> 3. this test case try to connect to server socket.
> 4. this test case would fail as the server only accept one connections.
> 
> I did not check it very carefully, I think for #4, the exception stack can be similar to the one in the bug description.
> 
> Anyway, as a free port is used, there are free-port issues.  Please consider to make the enhancement in the fix.  Otherwise, you cannot avoid the intermittent failure for this test case in the current testing environment.

+1.   Please remove any use of the free-port anti-pattern.

-Chris.

> Xuelei
> 
>> I can make this enhancement, but like I said I don't think it's going to
>> help, so I would like to keep debug output on.
>> 
>> Artem
>> 
>> 
>> On 09/14/2016 06:39 PM, Xuelei Fan wrote:
>>> On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
>>>> Hi Xuelei,
>>>> 
>>>> For this one, I am not sure that it would help here since the test
>>>> failed after it already had started handshaking.
>>> It has the same issue as a free-port is used.  We don't actually know
>>> the handshake is coming from the right client.
>>> 
>>> Xuelei
>>> 
>>>> I would prefer to have it as a separate enhancement.
>>>> 
>>>> Artem
>>>> 
>>>> 
>>>> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>>>>> As you were already there, I would suggest to consider the
>>>>> SSLSocketSample.java template as the comment in JDK-8163924 review
>>>>> thread.
>>>>> 
>>>>> Thanks,
>>>>> Xuelei
>>>>> 
>>>>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>>>>> Not urgent, but I would appreciate if someone can get a chance to look
>>>>>> at this.
>>>>>> 
>>>>>> Artem
>>>>>> 
>>>>>> 
>>>>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>>>>> Sending to net-dev at openjdk.java.net as well.
>>>>>>> 
>>>>>>> Artem
>>>>>>> 
>>>>>>> 
>>>>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> Please review the following patch for
>>>>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>>>> 
>>>>>>>> The test has been observed to fail a couple of times, but it's still
>>>>>>>> not clear why it failed because there is not much info in logs. The
>>>>>>>> patch updates the test to enable additional debug output, so that we
>>>>>>>> have more info if it fails next time.
>>>>>>>> 
>>>>>>>> While looking at the test, I notices a couple of issues, but they
>>>>>>>> don't seem to cause these intermittent failures:
>>>>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>>>>> provider reads them only once while initialization. As a result,
>>>>>>>> only
>>>>>>>> values which were set in the first iteration are actually used.
>>>>>>>> - The test doesn't close files and sockets sometimes.
>>>>>>>> 
>>>>>>>> The patch also fixed the issues above, and there are a couple
>>>>>>>> cosmetic changes.
>>>>>>>> 
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>>>> 
>>>>>>>> Artem
>>>>>>> 
>>>>>> 
>>>> 
>> 


From daniel.fuchs at oracle.com  Thu Sep 15 09:18:46 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 15 Sep 2016 10:18:46 +0100
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
	<4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
	<ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>
	<1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>
Message-ID: <59f8ca00-cd53-3a9e-698a-401556213343@oracle.com>

On 15/09/16 08:53, Chris Hegarty wrote:
>> Anyway, as a free port is used, there are free-port issues.  Please consider to make the enhancement in the fix.  Otherwise, you cannot avoid the intermittent failure for this test case in the current testing environment.
> +1.   Please remove any use of the free-port anti-pattern.
>

Hi guys,

What is the issue of opening a server socket on port 0?
This is what the test does, I thought that was the recommended
way.

best regards,

-- daniel

> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>


From sergei.kovalev at oracle.com  Thu Sep 15 09:50:23 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Thu, 15 Sep 2016 12:50:23 +0300
Subject: RFR(S): 8165689: Fix module dependencies for
	sun/security/pkcs11/* tests
In-Reply-To: <b0f8f0be-23cd-e3e7-4ef7-3bdcb0191c8f@oracle.com>
References: <196d5f17-2de5-d044-535e-ed2cdcd96aff@oracle.com>
	<def25644-a6d3-1c38-7c6c-d38b13e35d84@oracle.com>
	<f6ed057a-b458-768e-8006-5c9c6489ab7a@oracle.com>
	<670c85b1-905a-7e5e-0a66-7d240b8cd713@oracle.com>
	<b0f8f0be-23cd-e3e7-4ef7-3bdcb0191c8f@oracle.com>
Message-ID: <0a0bd2d9-c6be-287f-2c7b-769b8da719ea@oracle.com>

Hi Sean,

Thank you for feedback. I've updated the bug report.


14.09.16 19:57, Sean Mullan wrote:
> Thanks for the information. It would be very useful if you could add 
> that additional information as an example into the bug report for 
> future reference.
>
> --Sean
>
> On 09/14/2016 11:26 AM, Sergei Kovalev wrote:
>> Hi Sean,
>>
>> I'm working for testing minimal JRE image. If I create custom JRE with
>> java.base only - the tests fail. To emulate such behavior we can use
>> "--limit-modules java.base" option. In case if we have no module
>> declaration in tests header the test fails with, e.g. ClassNotFound
>> exception (see example in attached log). In case we declare appropriate
>> modules in jtreg header then jtreg suite skip the test and mark it "not
>> run" in final report. This help me to clean out all "false positive"
>> error during testing and reduce time that I spend to failures analysis.
>>
>>
>> 14.09.16 18:20, Sean Mullan wrote:
>>> Looks fine to me, but can you explain in more detail why the extra
>>> dependencies are needed, or an example using --limit-modules? These
>>> tests are not failing regularly now, so when do the missing
>>> dependencies cause failures?
>>>
>>> Thanks,
>>> Sean
>>>
>>> On 09/13/2016 08:34 AM, Sergei Kovalev wrote:
>>>> Hello team,
>>>>
>>>> This is re-request for review of very small changes. Could somebody 
>>>> take
>>>> a look?
>>>>
>>>>
>>>> 08.09.16 17:03, Sergei Kovalev wrote:
>>>>> Hello team,
>>>>>
>>>>> Could you please review the fix for below CR:
>>>>>
>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8165689
>>>>> WebRev: http://cr.openjdk.java.net/~skovalev/8165689/webrev.00/
>>>>>
>>>>> Goal: make test possible to run with "--limit-modules" flag.
>>>>> Summary: added @modules tag into jtreg header if applicable.
>>>>>
>>>>
>>

-- 
With best regards,
Sergei


From muuang at gmail.com  Thu Sep 15 15:53:29 2016
From: muuang at gmail.com (Michael Wang)
Date: Thu, 15 Sep 2016 11:53:29 -0400
Subject: Intended behavior of the -providerName option of keytool
Message-ID: <CAA9zaO4hhCJPhGr1iF=uQUqRbmNYFwQwG+YHVz2z=1c416o_Lw@mail.gmail.com>

Hi,

I'm trying to understand what the -providerName option of keytool does. The
documentation for -providerName just says:

"Used to identify a cryptographic service provider's name when listed in
the security properties file."

Which doesn't really say anything about how it should be used and the
resulting behavior.

I looked at the latest Java 9 source code for keytool, the only 2 places
that I see that uses providerName are

a. Getting an instance of the keystore, with:
KeyStore.getInstance(storetype, providerName);

b. Getting an instance of key pair generator, with:
new CertAndKeyGen(keyAlgName, sigAlgName, providerName);

It looks like all other calls in keytool that requires the services of a
provider does not use providerName, so it defaults to looking up the
matching provider from the providers list.

This behavior doesn't seem very clear cut to me.
I think -providerName should used to either:

1. Specify the provider of the keystore only. All other services used by
keytool that requires a provider will look up the provider using the
default providers list.

2. Specify the provider of all services used by keytool that requires a
provider, including keystore.

I just want to understand what the intended behavior should be.

Thanks,
Michael Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160915/82564051/attachment.html>

From bradford.wetmore at oracle.com  Thu Sep 15 18:30:42 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 15 Sep 2016 11:30:42 -0700
Subject: Do your NSS DLLs on Windows have execute permission?
In-Reply-To: <bf2383a3-ad36-1f1c-2078-fe7e38090b7d@oracle.com>
References: <bf2383a3-ad36-1f1c-2078-fe7e38090b7d@oracle.com>
Message-ID: <1bca38e2-9c01-89cd-de39-99c6df7d87fe@oracle.com>

Max,

This is a known problem.  We had a discussion on this a couple years 
ago, but I don't know if there's been any additional work on this. 
Perhaps Jon Gibbons might know?  cc'ing him.

 
http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011316.html
 
http://mail.openjdk.java.net/pipermail/build-dev/2013-December/011302.html

As of today's JDK 9 code, look at the "prep" target" in the 
jdk/test/Makefile test directory.  The "prep" target updates the DLLs as 
needed if this is not a repository (which I think is how our build/test 
system JPRT works).

To answer your question, running jtreg directly on that test also fails 
for me, due to:

Caused by: java.io.IOException: Access is denied.
D:\java\ws\dev\jdk\test\sun\security\pkcs11\nss\lib\windows-amd64\softokn3.dll

 > after JDK-8165946[1]
 > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/15badd72caae

I don't have either of JDK-8165946[text] or JDK-8077138[the bug id in 
the http link above] in my workspace.

Brad




On 9/14/2016 1:52 AM, Weijun Wang wrote:
> I see PKCS11 tests fail on my Windows 10 after JDK-8165946 [1]. After
> discussing with John (who worked on the bug) I found my NSS DLLs do not
> have the execute permission bit and his have.
>
> Mine is -rw-r--r--, and his is -rwxrwx---+.
>
> I am using cygwin on Windows 10 64-bit, and I use hg inside cygwin to
> clone the repo. My umask is 0022.
>
> Do you have that x? If yes, what's wrong with my environment? If no, do
> the tests run fine on your machine? For example, I just tried
> sun/security/pkcs11/Cipher/TestSymmCiphers.java and it fails.
>
> Thanks
> Max
>
> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/15badd72caae

From artem.smotrakov at oracle.com  Thu Sep 15 18:49:05 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Thu, 15 Sep 2016 11:49:05 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
	<4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
	<ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>
	<1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>
Message-ID: <6a63c9ae-0d7c-c470-2c25-2b746e1fa34b@oracle.com>

Hi Xuelei, Chris,

Thank you for looking into it. Please see inline.


On 09/15/2016 12:53 AM, Chris Hegarty wrote:
> On 15 Sep 2016, at 02:55, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> On 9/15/2016 9:45 AM, Artem Smotrakov wrote:
>>> Well, in this particular case it's not clear that it has the same issue
>>> with free port (at least to me). The exception occurred on client side,
>>> so it's not the case where we don't know where the handshake came from.
>>>
>> ;-) Yeh, you catch the point.  But there is a free-port issue although the exception stack in the bug description may be not that case.
>>
>> Let's look at a scenarios:
>> 1. server open a server socket and listen.
>> 2. other test case connect to the server socket.
>> 3. this test case try to connect to server socket.
>> 4. this test case would fail as the server only accept one connections.
>>
>> I did not check it very carefully, I think for #4, the exception stack can be similar to the one in the bug description.
Looks like a rare, but valid case.
>>
>> Anyway, as a free port is used, there are free-port issues.  Please consider to make the enhancement in the fix.  Otherwise, you cannot avoid the intermittent failure for this test case in the current testing environment.
> +1.   Please remove any use of the free-port anti-pattern.
Just to be clear, this is not an issue with getting a free port with 
ServerSocket.getLocalPort() and them re-using it to create a new 
ServerSocket. It's more tricky (for example, please see the scenario above).

Okay, let me update it to follow the approach which is implemented in 
SSLSocketSample.java

Artem
>
> -Chris.
>
>> Xuelei
>>
>>> I can make this enhancement, but like I said I don't think it's going to
>>> help, so I would like to keep debug output on.
>>>
>>> Artem
>>>
>>>
>>> On 09/14/2016 06:39 PM, Xuelei Fan wrote:
>>>> On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
>>>>> Hi Xuelei,
>>>>>
>>>>> For this one, I am not sure that it would help here since the test
>>>>> failed after it already had started handshaking.
>>>> It has the same issue as a free-port is used.  We don't actually know
>>>> the handshake is coming from the right client.
>>>>
>>>> Xuelei
>>>>
>>>>> I would prefer to have it as a separate enhancement.
>>>>>
>>>>> Artem
>>>>>
>>>>>
>>>>> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>>>>>> As you were already there, I would suggest to consider the
>>>>>> SSLSocketSample.java template as the comment in JDK-8163924 review
>>>>>> thread.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>>>>>> Not urgent, but I would appreciate if someone can get a chance to look
>>>>>>> at this.
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>>
>>>>>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>>>>>> Sending to net-dev at openjdk.java.net as well.
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review the following patch for
>>>>>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>>>>>
>>>>>>>>> The test has been observed to fail a couple of times, but it's still
>>>>>>>>> not clear why it failed because there is not much info in logs. The
>>>>>>>>> patch updates the test to enable additional debug output, so that we
>>>>>>>>> have more info if it fails next time.
>>>>>>>>>
>>>>>>>>> While looking at the test, I notices a couple of issues, but they
>>>>>>>>> don't seem to cause these intermittent failures:
>>>>>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>>>>>> provider reads them only once while initialization. As a result,
>>>>>>>>> only
>>>>>>>>> values which were set in the first iteration are actually used.
>>>>>>>>> - The test doesn't close files and sockets sometimes.
>>>>>>>>>
>>>>>>>>> The patch also fixed the issues above, and there are a couple
>>>>>>>>> cosmetic changes.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>>>>>
>>>>>>>>> Artem


From milton.smith at oracle.com  Thu Sep 15 23:19:21 2016
From: milton.smith at oracle.com (Milton Smith)
Date: Thu, 15 Sep 2016 16:19:21 -0700
Subject: X.509 Certificate Testing...
Message-ID: <F32C1F62-BF17-4FB8-91F3-F44BE271168B@oracle.com>

Hi All,

I'm looking for a set of certificates, self-signed certs, cross-signed 
certs, small chains, large chains, different critical and non-critical 
sections, revoked certs, blacklisted certs, invalid, not yet valid, time 
stamped, etc.  I realize it's difficult to be comprehensive but is there 
anything anyone can recommend for unit tests or CD/CI builds?  Trying to 
avoid creating all this if it exists already.  Thanks!

Regards,
Milton

From weijun.wang at oracle.com  Fri Sep 16 04:59:05 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 16 Sep 2016 12:59:05 +0800
Subject: X.509 Certificate Testing...
In-Reply-To: <F32C1F62-BF17-4FB8-91F3-F44BE271168B@oracle.com>
References: <F32C1F62-BF17-4FB8-91F3-F44BE271168B@oracle.com>
Message-ID: <B37BA8CE-C45E-4EA5-85EB-6E1EDABE6234@oracle.com>

I don't know a single place including all these things. In fact, in most cases we avoid including a certificate directly in a test if it can be created on the fly.

--Max

> On Sep 16, 2016, at 7:19 AM, Milton Smith <milton.smith at oracle.com> wrote:
> 
> Hi All,
> 
> I'm looking for a set of certificates, self-signed certs, cross-signed certs, small chains, large chains, different critical and non-critical sections, revoked certs, blacklisted certs, invalid, not yet valid, time stamped, etc.  I realize it's difficult to be comprehensive but is there anything anyone can recommend for unit tests or CD/CI builds?  Trying to avoid creating all this if it exists already.  Thanks!
> 
> Regards,
> Milton


From weijun.wang at oracle.com  Fri Sep 16 05:10:22 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 16 Sep 2016 13:10:22 +0800
Subject: Do your NSS DLLs on Windows have execute permission?
In-Reply-To: <1bca38e2-9c01-89cd-de39-99c6df7d87fe@oracle.com>
References: <bf2383a3-ad36-1f1c-2078-fe7e38090b7d@oracle.com>
	<1bca38e2-9c01-89cd-de39-99c6df7d87fe@oracle.com>
Message-ID: <2577697D-7842-44D0-BCC6-7946950AA98E@oracle.com>


> On Sep 16, 2016, at 2:30 AM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote:
> 
> As of today's JDK 9 code, look at the "prep" target" in the jdk/test/Makefile test directory.  The "prep" target updates the DLLs as needed if this is not a repository (which I think is how our build/test system JPRT works).

I didn't noticed that before. This explains everything.

Thanks
Max


From weijun.wang at oracle.com  Fri Sep 16 06:25:29 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 16 Sep 2016 14:25:29 +0800
Subject: Intended behavior of the -providerName option of keytool
In-Reply-To: <CAA9zaO4hhCJPhGr1iF=uQUqRbmNYFwQwG+YHVz2z=1c416o_Lw@mail.gmail.com>
References: <CAA9zaO4hhCJPhGr1iF=uQUqRbmNYFwQwG+YHVz2z=1c416o_Lw@mail.gmail.com>
Message-ID: <26DB4598-629A-41F1-961E-519DEB96D143@oracle.com>


> On Sep 15, 2016, at 11:53 PM, Michael Wang <muuang at gmail.com> wrote:
> 
> Hi,
> 
> I'm trying to understand what the -providerName option of keytool does. The documentation for -providerName just says:
> 
> "Used to identify a cryptographic service provider's name when listed in the security properties file."
> 
> Which doesn't really say anything about how it should be used and the resulting behavior.
> 
> I looked at the latest Java 9 source code for keytool, the only 2 places that I see that uses providerName are
> 
> a. Getting an instance of the keystore, with:
> KeyStore.getInstance(storetype, providerName);
> 
> b. Getting an instance of key pair generator, with:
> new CertAndKeyGen(keyAlgName, sigAlgName, providerName);
> 
> It looks like all other calls in keytool that requires the services of a provider does not use providerName, so it defaults to looking up the matching provider from the providers list.
> 
> This behavior doesn't seem very clear cut to me.
> I think -providerName should used to either:
> 
> 1. Specify the provider of the keystore only. All other services used by keytool that requires a provider will look up the provider using the default providers list.
> 
> 2. Specify the provider of all services used by keytool that requires a provider, including keystore.

This is the intended behavior. However, we only use providerName when it's necessary:

The reason why you see it is not used everywhere can be due to several reasons:

1. storetype is already different for different providers so it's not necessary.

2. some object is smart enough to switch provider even after getInstance. For example, if you call sig = Signature.getInstance("SHA1withRSA") to get a signature object it is not actually fully initialized. Next when you call sig.initSign(key), it will use the provider of key as its provider if necessary.

Thanks
Max


> 
> I just want to understand what the intended behavior should be.
> 
> Thanks,
> Michael Wang


From sean.mullan at oracle.com  Fri Sep 16 12:02:28 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 16 Sep 2016 08:02:28 -0400
Subject: X.509 Certificate Testing...
In-Reply-To: <F32C1F62-BF17-4FB8-91F3-F44BE271168B@oracle.com>
References: <F32C1F62-BF17-4FB8-91F3-F44BE271168B@oracle.com>
Message-ID: <69baf9ef-25e0-237a-3a8f-1a67724f162c@oracle.com>

The NIST PKITS test suite is a good one and contains a whole bunch of 
certificates/CRLs for testing compliance with RFC 3280: 
http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html

--Sean

On 09/15/2016 07:19 PM, Milton Smith wrote:
> Hi All,
>
> I'm looking for a set of certificates, self-signed certs, cross-signed
> certs, small chains, large chains, different critical and non-critical
> sections, revoked certs, blacklisted certs, invalid, not yet valid, time
> stamped, etc.  I realize it's difficult to be comprehensive but is there
> anything anyone can recommend for unit tests or CD/CI builds?  Trying to
> avoid creating all this if it exists already.  Thanks!
>
> Regards,
> Milton

From weijun.wang at oracle.com  Mon Sep 19 01:46:12 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 19 Sep 2016 09:46:12 +0800
Subject: Code Review Request, JDK-8146600 AVA Normalizer.Form issue
In-Reply-To: <f6aaa6a7-e930-43d2-0ba8-b01a74534b97@oracle.com>
References: <f6aaa6a7-e930-43d2-0ba8-b01a74534b97@oracle.com>
Message-ID: <3825142E-9AAC-46EF-864E-CD11F5C04922@oracle.com>

I am not sure of this change for several reasons:

1. I cannot find anywhere in RFC 2253 (or its new versions) mentioning normalizations. Do you know elsewhere?

2. It's not obvious to say "Hello, world!" and "Hello? world!" should be different if NFKD thinks they are.

3. Why not NFC? Although I did't find normalization on X500 names in RFC 5280, I do see in several other cases NFV is used.

4. Is it possible to perform normalization before escaping special characters?

5. Why is normalization necessary? At least in RFC 5280 4.1.2.6, it says

           When the subject of the certificate is a CA, the subject
           field MUST be encoded in the same way as it is encoded in the
           issuer field (Section 4.1.2.4 ) in all certificates issued by
           the subject CA.

which implies comparison should be on encoding instead of toString.

Thanks
Max

> On Sep 15, 2016, at 8:09 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Hi,
> 
> Please review this fix:
>    http://cr.openjdk.java.net/~xuelei/8146600/webrev.00/
> 
> The Normalizer.Form.NFKD is used to normalize attribute-value assertion in X.509 certificate processing.  The normalizer may convert some UTF-8 character into ASCII code.  For example, "?"(two bytes) will be converted to ","(one byte), and "Hello? world!" is normalize to "Hello, world!".  However, "Hello, world!" and "Hello? world!" should be different because of the comma code.  This conversion may result in unexpected weird behaviors for name comparing and conversions.
> 
> This fix will update to use "Normalizer.Form.NFD".
> 
> Thanks,
> Xuelei


From xuelei.fan at oracle.com  Mon Sep 19 02:32:49 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 19 Sep 2016 10:32:49 +0800
Subject: Code Review Request, JDK-8146600 AVA Normalizer.Form issue
In-Reply-To: <3825142E-9AAC-46EF-864E-CD11F5C04922@oracle.com>
References: <f6aaa6a7-e930-43d2-0ba8-b01a74534b97@oracle.com>
	<3825142E-9AAC-46EF-864E-CD11F5C04922@oracle.com>
Message-ID: <ff7f5977-ad2d-f58a-1f20-bce8d984859e@oracle.com>



On 9/19/2016 9:46 AM, Wang Weijun wrote:
> I am not sure of this change for several reasons:
>
> 1. I cannot find anywhere in RFC 2253 (or its new versions) mentioning normalizations. Do you know elsewhere?
>
Normalization is not a part of RFC 2253.  The spec is described in 
Unicode standards.
    http://www.unicode.org/reports/tr15/tr15-23.html

> 2. It's not obvious to say "Hello, world!" and "Hello? world!" should be different if NFKD thinks they are.
>
ASN.1 and RFC 2253 require UTF-8 encoding.  "Hello, world!" is encoded 
as "Hello%2C%20world%21".  "Hello? world!" is encoded as 
"Hello%EF%BC%8C%20world%21".   The encoded code should be different. 
When signing a certificate, "?" is not converted to ",",  I don't think 
it is fine to convert it while parsing the field.

> 3. Why not NFC? Although I did't find normalization on X500 names in RFC 5280, I do see in several other cases NFV is used.
>
Actually, I'm not sure why normalization is required here.  So I don't 
want to update the code too much.  The previous form is NFKD.  If 
removing the "compatibility" impact part, the form is NFD, then.

What's the form of NFV?  Any typo?

> 4. Is it possible to perform normalization before escaping special characters?
>
Yes.  I though about this case.  The current fix comes from the fact 
that UTF-8 "Hello, world!" and "Hello? world!" should be different. 
Parsing them as the same thing may result in unexpected serious issues.

> 5. Why is normalization necessary? At least in RFC 5280 4.1.2.6, it says
>
>            When the subject of the certificate is a CA, the subject
>            field MUST be encoded in the same way as it is encoded in the
>            issuer field (Section 4.1.2.4 ) in all certificates issued by
>            the subject CA.
>
> which implies comparison should be on encoding instead of toString.
>
I have to say I agree with this point.  I don't see the point to use 
normalization.  But I'm not sure I get the full information to remove 
the normalization.  I don't want to fix it until it is broken.

Xuelei


> Thanks
> Max
>
>> On Sep 15, 2016, at 8:09 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review this fix:
>>    http://cr.openjdk.java.net/~xuelei/8146600/webrev.00/
>>
>> The Normalizer.Form.NFKD is used to normalize attribute-value assertion in X.509 certificate processing.  The normalizer may convert some UTF-8 character into ASCII code.  For example, "?"(two bytes) will be converted to ","(one byte), and "Hello? world!" is normalize to "Hello, world!".  However, "Hello, world!" and "Hello? world!" should be different because of the comma code.  This conversion may result in unexpected weird behaviors for name comparing and conversions.
>>
>> This fix will update to use "Normalizer.Form.NFD".
>>
>> Thanks,
>> Xuelei
>

From sha.jiang at oracle.com  Mon Sep 19 08:10:31 2016
From: sha.jiang at oracle.com (John Jiang)
Date: Mon, 19 Sep 2016 16:10:31 +0800
Subject: RFR[9]: JDK-8165566:
	sun/security/ssl/SocketCreation/SocketCreation.java fails
	intermittently: Address already in use
Message-ID: <123446fd-8f66-e1c2-99b8-fb91bedcf4a0@oracle.com>

Hi,
Please review this fix for JDK-8165566 on test 
sun/security/ssl/SocketCreation/SocketCreation.java.
This test takes multiple servers to use one port in sequence, but the 
port may not be released by previous server.
This patch takes every server to be allocated a free port.

Webrev: http://cr.openjdk.java.net/~jjiang/8165566/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8165566

Best regards,
John Jiang


From chris.hegarty at oracle.com  Mon Sep 19 09:00:08 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 19 Sep 2016 10:00:08 +0100
Subject: RFR[9]: JDK-8165566:
	sun/security/ssl/SocketCreation/SocketCreation.java fails
	intermittently: Address already in use
In-Reply-To: <123446fd-8f66-e1c2-99b8-fb91bedcf4a0@oracle.com>
References: <123446fd-8f66-e1c2-99b8-fb91bedcf4a0@oracle.com>
Message-ID: <337f02ab-bd26-13bb-1cd5-db08acc99799@oracle.com>

On 19/09/16 09:10, John Jiang wrote:
> Hi,
> Please review this fix for JDK-8165566 on test
> sun/security/ssl/SocketCreation/SocketCreation.java.
> This test takes multiple servers to use one port in sequence, but the
> port may not be released by previous server.
> This patch takes every server to be allocated a free port.
>
> Webrev: http://cr.openjdk.java.net/~jjiang/8165566/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8165566

Looks good John.

-Chris.

From weijun.wang at oracle.com  Mon Sep 19 15:03:33 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 19 Sep 2016 23:03:33 +0800
Subject: Code Review Request, JDK-8146600 AVA Normalizer.Form issue
In-Reply-To: <ff7f5977-ad2d-f58a-1f20-bce8d984859e@oracle.com>
References: <f6aaa6a7-e930-43d2-0ba8-b01a74534b97@oracle.com>
	<3825142E-9AAC-46EF-864E-CD11F5C04922@oracle.com>
	<ff7f5977-ad2d-f58a-1f20-bce8d984859e@oracle.com>
Message-ID: <2F9EC815-4202-4988-92B1-F8AC612DF667@oracle.com>

After some thinking, my current opinion is.

1. Maybe NFC is better than NFKD, but I am not a Unicode expert.

2. I think the real bug is the order of escaping and normalization. The normalization (if a must) should be performed earlier right after valStr is created and only performed on valStr. Otherwise the NFKD normalization would generate new chars that need to be escaped. Again I am not a Unicode expert and I don't know if NFC will also do the same.

If 2) is fixed, whatever is correct in 1) does not matter much.

Thanks
Max

> On Sep 19, 2016, at 10:32 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
>> 4. Is it possible to perform normalization before escaping special characters?
>> 
> Yes.  I though about this case.  The current fix comes from the fact that UTF-8 "Hello, world!" and "Hello? world!" should be different. Parsing them as the same thing may result in unexpected serious issues.


From xuelei.fan at oracle.com  Mon Sep 19 15:16:35 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 19 Sep 2016 23:16:35 +0800
Subject: Code Review Request, JDK-8146600 AVA Normalizer.Form issue
In-Reply-To: <2F9EC815-4202-4988-92B1-F8AC612DF667@oracle.com>
References: <f6aaa6a7-e930-43d2-0ba8-b01a74534b97@oracle.com>
	<3825142E-9AAC-46EF-864E-CD11F5C04922@oracle.com>
	<ff7f5977-ad2d-f58a-1f20-bce8d984859e@oracle.com>
	<2F9EC815-4202-4988-92B1-F8AC612DF667@oracle.com>
Message-ID: <7ac26f3e-0560-aa36-e77c-bb83ab900a0c@oracle.com>

On 9/19/2016 11:03 PM, Wang Weijun wrote:
> After some thinking, my current opinion is.
>
> 1. Maybe NFC is better than NFKD, but I am not a Unicode expert.
>
It is updated from NFKD to NFD.  I did not get the point.  Do you mean 
NFC is better than NFD?

> 2. I think the real bug is the order of escaping and normalization. The normalization (if a must) should be performed earlier right after valStr is created and only performed on valStr. Otherwise the NFKD normalization would generate new chars that need to be escaped. Again I am not a Unicode expert and I don't know if NFC will also do the same.
>
I don't get the point.  The update is moving from NFKD to NFD.  No NFKD 
normalization any more.

> If 2) is fixed, whatever is correct in 1) does not matter much.
>
If we continue to use NFKD, normalization before escaping would result 
in unexpected string as we talked for the hello-world example.  It is 
something I want to avoid, so that it is fixed to use NFD instead.  I 
think if we are moving to use NFD, it is does not matter to escaping 
first or normalization first if I understand the UTF-8 correctly.

Thanks,
Xuelei

> Thanks
> Max
>
>> On Sep 19, 2016, at 10:32 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>>> 4. Is it possible to perform normalization before escaping special characters?
>>>
>> Yes.  I though about this case.  The current fix comes from the fact that UTF-8 "Hello, world!" and "Hello? world!" should be different. Parsing them as the same thing may result in unexpected serious issues.
>

From valerie.peng at oracle.com  Mon Sep 19 21:06:31 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 19 Sep 2016 14:06:31 -0700
Subject: [9]RFR 8149802: Signature.verify() doesn't reset the signature object
	on exception
Message-ID: <06e19f2a-439f-f760-c3d0-0449ff071a0a@oracle.com>


Can someone help review this fix?
Besides the obvious fixes, I ran into an intermittent 
CKR_OPERATION_ACTIVE error which went away with the updated Secmod.java.

Bug: https://bugs.openjdk.java.net/browse/JDK-8149802
Webrev: http://cr.openjdk.java.net/~valeriep/8149802/webrev.00/

Thanks,
Valerie




From valerie.peng at oracle.com  Mon Sep 19 21:11:54 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 19 Sep 2016 14:11:54 -0700
Subject: [9]RFR 6946830: javax.crypto.Cipher.doFinal behavior differs
	depending on platform
Message-ID: <8bad70f8-8f08-6d51-279f-325e95ddb94f@oracle.com>


Anyone has time to review this trivial fix? This is a corner case of 
decrypting with 0-length data. Some provider throws exception but some 
just returns (no-op). For less impact, I changed all to match SunJCE 
provider's behavior which just returns.

Bug: https://bugs.openjdk.java.net/browse/JDK-6946830
Webrev: http://cr.openjdk.java.net/~valeriep/6946830/webrev.00/

Thanks,
Valerie

From chris at christopherschultz.net  Mon Sep 19 21:28:25 2016
From: chris at christopherschultz.net (Christopher Schultz)
Date: Mon, 19 Sep 2016 17:28:25 -0400
Subject: Obtaining TLS handshake details e.g. server key exchange bits
Message-ID: <72ee4d26-c260-501f-0c10-4063cc17bfb2@christopherschultz.net>

All,

I apologize if this isn't the right place to post this. Please let me
know if I should post elsewhere and I'll be happy to do so.

For the past few years, I've been maintaining a Java-based TLS server
tester mostly for my own use, but also shared with the Apache Tomcat
user community. It does the usual things like checking to see which
cipher suites and protocols a server will support.

Recently, I decided I wanted to emulate ssllabs's "weak DH" detection
which requires the ability to look at the server's key exchange messages
which are send during the TLS handshake(s) in order to get information
about the ephemeral keys exchanged.

Unfortunately, it doesn't look like the public Java API exposes this
level of detail to client code. I've plumbed everything I can find in
the SSLSocket, SSLSession, SSLParameters, and HandshakeCompletedEvent
and I can't find what I'm looking for. If I'm missing some part of the
API, please let me know where I've neglected to look.

When enabling debug logging, the stderr stream does in fact have
information about the server key exchange:

*** ECDH ServerKeyExchange
Signature Algorithm SHA1withRSA
Server key: Sun EC public key, 256 bits
  public x coord:
110012472572673270259963200120939499588744004832860744957480311193127985892474
  public y coord:
52644710749477935701151970482569895235781257631749844762926109323061108920137
  parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
*** ServerHelloDone
*** ECDHClientKeyExchange
ECDH Public value:  { 4, 79, 42, 152, 110, 20, 54, 113, 102, 98, 154,
229, 169, 168, 248, 134, 190, 20, 10, 233, 39, 44, 67, 158, 215, 13,
248, 134, 228, 65, 174, 5, 139, 154, 212, 79, 238, 177, 31, 240, 189,
185, 129, 24, 175, 37, 177, 149, 138, 15, 141, 183, 134, 243, 15, 185,
60, 24, 67, 7, 172, 48, 133, 222, 85 }
main, WRITE: TLSv1.2 Handshake, length = 70

So, all the information I see is there... just not through the API it seems.

If such information is in fact not currently exposed, I'd like to
propose that the API be extended in order to expose that information. At
this point, I'm only interested in the ephemeral Diffie-Hellman keys
used to negotiate the session key, but it might be nice to be able to
get at the symmetric session key as well to support debugging similar to
how Mozilla Firefox can dump the symmetric key to a file on the dist
specified by the SSLKEYLOGFILE environment variable.

I'm not too picky about the style of the API (e.g.
callback-during-handshake versus direct-call-after-handshake), I just
want to be able to sniff this stuff.

Please let me know if I should provide any additional information.

Thanks,
-chris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 906 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160919/cc7ebe88/signature.asc>

From weijun.wang at oracle.com  Mon Sep 19 21:53:46 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 20 Sep 2016 05:53:46 +0800
Subject: Code Review Request, JDK-8146600 AVA Normalizer.Form issue
In-Reply-To: <7ac26f3e-0560-aa36-e77c-bb83ab900a0c@oracle.com>
References: <f6aaa6a7-e930-43d2-0ba8-b01a74534b97@oracle.com>
	<3825142E-9AAC-46EF-864E-CD11F5C04922@oracle.com>
	<ff7f5977-ad2d-f58a-1f20-bce8d984859e@oracle.com>
	<2F9EC815-4202-4988-92B1-F8AC612DF667@oracle.com>
	<7ac26f3e-0560-aa36-e77c-bb83ab900a0c@oracle.com>
Message-ID: <065D5B0E-D220-4410-882A-610E36C45E34@oracle.com>

Sorry. Whenever I wrote NFC, I meant NFD. Typo. 

> ? 2016?9?19??23:16?Xuelei Fan <xuelei.fan at oracle.com> ???
> 
>> On 9/19/2016 11:03 PM, Wang Weijun wrote:
>> After some thinking, my current opinion is.
>> 
>> 1. Maybe NFC is better than NFKD, but I am not a Unicode expert.
>> 
> It is updated from NFKD to NFD.  I did not get the point.  Do you mean NFC is better than NFD?
> 
>> 2. I think the real bug is the order of escaping and normalization. The normalization (if a must) should be performed earlier right after valStr is created and only performed on valStr. Otherwise the NFKD normalization would generate new chars that need to be escaped. Again I am not a Unicode expert and I don't know if NFC will also do the same.
>> 
> I don't get the point.  The update is moving from NFKD to NFD.  No NFKD normalization any more.
> 
>> If 2) is fixed, whatever is correct in 1) does not matter much.
>> 
> If we continue to use NFKD, normalization before escaping would result in unexpected string as we talked for the hello-world example.  

I this case, a comma appears but then it is escaped. You might say it is unexpected, but at least after escaping, it becomes a legal string. 

> It is something I want to avoid, so that it is fixed to use NFD instead.  I think if we are moving to use NFD, it is does not matter to escaping first or normalization first if I understand the UTF-8 correctly.

Maybe, but IMO this is not the correct fix. The ultimate reason of the bug is not the form chosen, but the order. 

--Max

> 
> Thanks,
> Xuelei
> 
>> Thanks
>> Max
>> 
>>>> On Sep 19, 2016, at 10:32 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>> 
>>>> 4. Is it possible to perform normalization before escaping special characters?
>>>> 
>>> Yes.  I though about this case.  The current fix comes from the fact that UTF-8 "Hello, world!" and "Hello? world!" should be different. Parsing them as the same thing may result in unexpected serious issues.
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160920/e6afb228/attachment.html>

From valerie.peng at oracle.com  Tue Sep 20 00:31:23 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 19 Sep 2016 17:31:23 -0700
Subject: [9]RFR 8136355: CKM_SSL3_KEY_AND_MAC_DERIVE no longer available by
	default on Solaris 12
Message-ID: <09d79499-0ba2-6af1-c9b4-1667878e879f@oracle.com>

Xuelei,

Could you please help reviewing this change?

There are quite a few test failures on Solaris 12 due to the removal of 
Solaris PKCS11 SSL3 mechanisms which SunPKCS11 provider assume to be 
always present. I updated relevant classes as well as regression tests 
to skip SSL3 testing when the support isn't there.

Bug: https://bugs.openjdk.java.net/browse/JDK-8136355
Webrev: http://cr.openjdk.java.net/~valeriep/8136355/webrev.00/

Thanks,
Valerie

From xuelei.fan at oracle.com  Tue Sep 20 00:58:34 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 20 Sep 2016 08:58:34 +0800
Subject: Code Review Request, JDK-8146600 AVA Normalizer.Form issue
In-Reply-To: <065D5B0E-D220-4410-882A-610E36C45E34@oracle.com>
References: <f6aaa6a7-e930-43d2-0ba8-b01a74534b97@oracle.com>
	<3825142E-9AAC-46EF-864E-CD11F5C04922@oracle.com>
	<ff7f5977-ad2d-f58a-1f20-bce8d984859e@oracle.com>
	<2F9EC815-4202-4988-92B1-F8AC612DF667@oracle.com>
	<7ac26f3e-0560-aa36-e77c-bb83ab900a0c@oracle.com>
	<065D5B0E-D220-4410-882A-610E36C45E34@oracle.com>
Message-ID: <a5b12dbd-290a-7c87-efcc-e31f5a983bd3@oracle.com>

On 9/20/2016 5:53 AM, Wang Weijun wrote:
> Sorry. Whenever I wrote NFC, I meant NFD. Typo.
>
> ? 2016?9?19??23:16?Xuelei Fan <xuelei.fan at oracle.com
> <mailto:xuelei.fan at oracle.com>> ???
>
>> On 9/19/2016 11:03 PM, Wang Weijun wrote:
>>> After some thinking, my current opinion is.
>>>
>>> 1. Maybe NFC is better than NFKD, but I am not a Unicode expert.
>>>
>> It is updated from NFKD to NFD.  I did not get the point.  Do you mean
>> NFC is better than NFD?
>>
>>> 2. I think the real bug is the order of escaping and normalization.
>>> The normalization (if a must) should be performed earlier right after
>>> valStr is created and only performed on valStr. Otherwise the NFKD
>>> normalization would generate new chars that need to be escaped. Again
>>> I am not a Unicode expert and I don't know if NFC will also do the same.
>>>
>> I don't get the point.  The update is moving from NFKD to NFD.  No
>> NFKD normalization any more.
>>
>>> If 2) is fixed, whatever is correct in 1) does not matter much.
>>>
>> If we continue to use NFKD, normalization before escaping would result
>> in unexpected string as we talked for the hello-world example.
>
> I this case, a comma appears but then it is escaped. You might say it is
> unexpected, but at least after escaping, it becomes a legal string.
>
I did not get the point.  A comma (",") should be escaped and it does 
get escaped and the string is legal.  Do you mean "?" (double bytes 
comma) should be converted to ","?  Can you have more details?

>> It is something I want to avoid, so that it is fixed to use NFD
>> instead.  I think if we are moving to use NFD, it is does not matter
>> to escaping first or normalization first if I understand the UTF-8
>> correctly.
>
> Maybe, but IMO this is not the correct fix. The ultimate reason of the
> bug is not the form chosen, but the order.
>
I'm not with you for this bug. The bug is complain about the escaping 
issue, but actually the character should not be escaped.  So it is not 
an issue of escaping.  So this fix is not trying to fix the escaping 
issue, but trying to fix the normalization issue.

Thanks,
Xuelei

> --Max
>
>>
>> Thanks,
>> Xuelei
>>
>>> Thanks
>>> Max
>>>
>>>> On Sep 19, 2016, at 10:32 AM, Xuelei Fan <xuelei.fan at oracle.com
>>>> <mailto:xuelei.fan at oracle.com>> wrote:
>>>>
>>>>> 4. Is it possible to perform normalization before escaping special
>>>>> characters?
>>>>>
>>>> Yes.  I though about this case.  The current fix comes from the fact
>>>> that UTF-8 "Hello, world!" and "Hello? world!" should be different.
>>>> Parsing them as the same thing may result in unexpected serious issues.
>>>

From weijun.wang at oracle.com  Tue Sep 20 01:09:10 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 20 Sep 2016 09:09:10 +0800
Subject: Code Review Request, JDK-8146600 AVA Normalizer.Form issue
In-Reply-To: <a5b12dbd-290a-7c87-efcc-e31f5a983bd3@oracle.com>
References: <f6aaa6a7-e930-43d2-0ba8-b01a74534b97@oracle.com>
	<3825142E-9AAC-46EF-864E-CD11F5C04922@oracle.com>
	<ff7f5977-ad2d-f58a-1f20-bce8d984859e@oracle.com>
	<2F9EC815-4202-4988-92B1-F8AC612DF667@oracle.com>
	<7ac26f3e-0560-aa36-e77c-bb83ab900a0c@oracle.com>
	<065D5B0E-D220-4410-882A-610E36C45E34@oracle.com>
	<a5b12dbd-290a-7c87-efcc-e31f5a983bd3@oracle.com>
Message-ID: <F280416F-E69D-4EA7-9C4F-8F2A6AF24035@oracle.com>


> On Sep 20, 2016, at 8:58 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> 
>> I this case, a comma appears but then it is escaped. You might say it is
>> unexpected, but at least after escaping, it becomes a legal string.
>> 
> I did not get the point.  A comma (",") should be escaped and it does get escaped and the string is legal.  Do you mean "?" (double bytes comma) should be converted to ","?  Can you have more details?

I'll write double bytes comma as ,, below.

Current code, "Hello,,world" is not modified at escaping, and becomes "Hello,world" after normalization. This is illegal.

With my fix, "Hello,,world" becomes "Hello,world" after normalization, and then "Hello\,world" after escaping. This is legal.

With your fix, "Hello,,world" is not modified after both steps, and it's legal.

So both your and my fixes will make it legal and the test will succeed.

> 
>>> It is something I want to avoid, so that it is fixed to use NFD
>>> instead.  I think if we are moving to use NFD, it is does not matter
>>> to escaping first or normalization first if I understand the UTF-8
>>> correctly.
>> 
>> Maybe, but IMO this is not the correct fix. The ultimate reason of the
>> bug is not the form chosen, but the order.
>> 
> I'm not with you for this bug. The bug is complain about the escaping issue, but actually the character should not be escaped.  So it is not an issue of escaping.  So this fix is not trying to fix the escaping issue, but trying to fix the normalization issue.

Yes it is complaining about escaping, but there are 2 ways to amend it. 1) escape it. 2) make it not necessary to escape.

I just prefer my fix, because I think that's where the bug is. Even if we switch to NFD, I would still like to put normalization before escaping, even if practically it makes no difference.

Thanks
Max

> 
> Thanks,
> Xuelei
> 
>> --Max
>> 
>>> 
>>> Thanks,
>>> Xuelei
>>> 
>>>> Thanks
>>>> Max
>>>> 
>>>>> On Sep 19, 2016, at 10:32 AM, Xuelei Fan <xuelei.fan at oracle.com
>>>>> <mailto:xuelei.fan at oracle.com>> wrote:
>>>>> 
>>>>>> 4. Is it possible to perform normalization before escaping special
>>>>>> characters?
>>>>>> 
>>>>> Yes.  I though about this case.  The current fix comes from the fact
>>>>> that UTF-8 "Hello, world!" and "Hello? world!" should be different.
>>>>> Parsing them as the same thing may result in unexpected serious issues.
>>>> 


From xuelei.fan at oracle.com  Tue Sep 20 01:12:24 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 20 Sep 2016 09:12:24 +0800
Subject: [9]RFR 8149802: Signature.verify() doesn't reset the signature
	object on exception
In-Reply-To: <06e19f2a-439f-f760-c3d0-0449ff071a0a@oracle.com>
References: <06e19f2a-439f-f760-c3d0-0449ff071a0a@oracle.com>
Message-ID: <90a2cdef-6bb9-2730-5a65-9415e615ddb2@oracle.com>

Safe update to me.  Looks fine.

Xuelei

On 9/20/2016 5:06 AM, Valerie Peng wrote:
>
> Can someone help review this fix?
> Besides the obvious fixes, I ran into an intermittent
> CKR_OPERATION_ACTIVE error which went away with the updated Secmod.java.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8149802
> Webrev: http://cr.openjdk.java.net/~valeriep/8149802/webrev.00/
>
> Thanks,
> Valerie
>
>
>

From xuelei.fan at oracle.com  Tue Sep 20 01:20:08 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 20 Sep 2016 09:20:08 +0800
Subject: [9]RFR 6946830: javax.crypto.Cipher.doFinal behavior differs
	depending on platform
In-Reply-To: <8bad70f8-8f08-6d51-279f-325e95ddb94f@oracle.com>
References: <8bad70f8-8f08-6d51-279f-325e95ddb94f@oracle.com>
Message-ID: <4ac1ee9c-4851-39e4-1ae5-3b2ba12dd47d@oracle.com>

P11Cipher.java
--------------
line 775 and 850:
The code looks special to me.  Is it possible/better to check the range 
before the call to PKCS11 decryption function?

Xuelei

On 9/20/2016 5:11 AM, Valerie Peng wrote:
>
> Anyone has time to review this trivial fix? This is a corner case of
> decrypting with 0-length data. Some provider throws exception but some
> just returns (no-op). For less impact, I changed all to match SunJCE
> provider's behavior which just returns.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6946830
> Webrev: http://cr.openjdk.java.net/~valeriep/6946830/webrev.00/
>
> Thanks,
> Valerie

From sergei.kovalev at oracle.com  Tue Sep 20 13:32:14 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Tue, 20 Sep 2016 16:32:14 +0300
Subject: RFR(s): 8166378: Missing dependencies in several java/security tests
Message-ID: <99bccefa-b844-f16a-6244-196dcab0852d@oracle.com>

Hello team,

Please review very small fix for several regression tests.

BugID: https://bugs.openjdk.java.net/browse/JDK-8166378
WebReview: http://cr.openjdk.java.net/~skovalev/8166378/webrev.00

Issue: The tests has no declared dependencies on jdk.security modules. 
This leads the tests to fail in case of usage "--limit-modules" java 
command line option.

Solution: add missed dependencies if required.

-- 
With best regards,
Sergei


From artem.smotrakov at oracle.com  Tue Sep 20 21:50:05 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 20 Sep 2016 14:50:05 -0700
Subject: [9] RFR: 8164591:
	sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed
	with SSLHandshakeException
In-Reply-To: <6a63c9ae-0d7c-c470-2c25-2b746e1fa34b@oracle.com>
References: <9ec64925-1e16-0a31-1c26-1cd3416b0f22@oracle.com>
	<6ead341e-bdcf-1806-93ed-de88783b9932@oracle.com>
	<5877f1ea-bf4d-b8db-b28f-411b48f5ac29@oracle.com>
	<20d74884-dc05-93b8-da5d-e03a35c6e19d@oracle.com>
	<80a670d8-1047-ad76-d0a9-a591216a02e4@oracle.com>
	<8fb7fddf-e936-2234-5ffb-4370a256e305@oracle.com>
	<4ecc13fb-60cd-6cfb-5822-57b5689a02a8@oracle.com>
	<ff008ed1-45d8-2a90-9509-04afe85f859d@oracle.com>
	<1C3195A7-EAA9-41BC-AE3C-136C5C2E148B@oracle.com>
	<6a63c9ae-0d7c-c470-2c25-2b746e1fa34b@oracle.com>
Message-ID: <41b8c228-1652-7b5a-ecf9-765e2e95afb8@oracle.com>

Hello,

If you don't mind, I moved some common code from SSLSocketTemplate.java 
to SSLTest.java, so that it can be re-used by other tests. It may help 
to avoid duplicate code.

http://cr.openjdk.java.net/~asmotrak/8164591/webrev.01/

Please take a look.

Artem


On 09/15/2016 11:49 AM, Artem Smotrakov wrote:
> Hi Xuelei, Chris,
>
> Thank you for looking into it. Please see inline.
>
>
> On 09/15/2016 12:53 AM, Chris Hegarty wrote:
>> On 15 Sep 2016, at 02:55, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>> On 9/15/2016 9:45 AM, Artem Smotrakov wrote:
>>>> Well, in this particular case it's not clear that it has the same 
>>>> issue
>>>> with free port (at least to me). The exception occurred on client 
>>>> side,
>>>> so it's not the case where we don't know where the handshake came 
>>>> from.
>>>>
>>> ;-) Yeh, you catch the point.  But there is a free-port issue 
>>> although the exception stack in the bug description may be not that 
>>> case.
>>>
>>> Let's look at a scenarios:
>>> 1. server open a server socket and listen.
>>> 2. other test case connect to the server socket.
>>> 3. this test case try to connect to server socket.
>>> 4. this test case would fail as the server only accept one connections.
>>>
>>> I did not check it very carefully, I think for #4, the exception 
>>> stack can be similar to the one in the bug description.
> Looks like a rare, but valid case.
>>>
>>> Anyway, as a free port is used, there are free-port issues. Please 
>>> consider to make the enhancement in the fix. Otherwise, you cannot 
>>> avoid the intermittent failure for this test case in the current 
>>> testing environment.
>> +1.   Please remove any use of the free-port anti-pattern.
> Just to be clear, this is not an issue with getting a free port with 
> ServerSocket.getLocalPort() and them re-using it to create a new 
> ServerSocket. It's more tricky (for example, please see the scenario 
> above).
>
> Okay, let me update it to follow the approach which is implemented in 
> SSLSocketSample.java
>
> Artem
>>
>> -Chris.
>>
>>> Xuelei
>>>
>>>> I can make this enhancement, but like I said I don't think it's 
>>>> going to
>>>> help, so I would like to keep debug output on.
>>>>
>>>> Artem
>>>>
>>>>
>>>> On 09/14/2016 06:39 PM, Xuelei Fan wrote:
>>>>> On 9/15/2016 9:23 AM, Artem Smotrakov wrote:
>>>>>> Hi Xuelei,
>>>>>>
>>>>>> For this one, I am not sure that it would help here since the test
>>>>>> failed after it already had started handshaking.
>>>>> It has the same issue as a free-port is used.  We don't actually know
>>>>> the handshake is coming from the right client.
>>>>>
>>>>> Xuelei
>>>>>
>>>>>> I would prefer to have it as a separate enhancement.
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>>
>>>>>> On 09/14/2016 06:19 PM, Xuelei Fan wrote:
>>>>>>> As you were already there, I would suggest to consider the
>>>>>>> SSLSocketSample.java template as the comment in JDK-8163924 review
>>>>>>> thread.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Xuelei
>>>>>>>
>>>>>>> On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
>>>>>>>> Not urgent, but I would appreciate if someone can get a chance 
>>>>>>>> to look
>>>>>>>> at this.
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/07/2016 03:17 PM, Artem Smotrakov wrote:
>>>>>>>>> Sending to net-dev at openjdk.java.net as well.
>>>>>>>>>
>>>>>>>>> Artem
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09/07/2016 12:28 PM, Artem Smotrakov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review the following patch for
>>>>>>>>>> sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
>>>>>>>>>>
>>>>>>>>>> The test has been observed to fail a couple of times, but 
>>>>>>>>>> it's still
>>>>>>>>>> not clear why it failed because there is not much info in 
>>>>>>>>>> logs. The
>>>>>>>>>> patch updates the test to enable additional debug output, so 
>>>>>>>>>> that we
>>>>>>>>>> have more info if it fails next time.
>>>>>>>>>>
>>>>>>>>>> While looking at the test, I notices a couple of issues, but 
>>>>>>>>>> they
>>>>>>>>>> don't seem to cause these intermittent failures:
>>>>>>>>>> - The test sets system properties for JSSE in a loop, but JSSE
>>>>>>>>>> provider reads them only once while initialization. As a result,
>>>>>>>>>> only
>>>>>>>>>> values which were set in the first iteration are actually used.
>>>>>>>>>> - The test doesn't close files and sockets sometimes.
>>>>>>>>>>
>>>>>>>>>> The patch also fixed the issues above, and there are a couple
>>>>>>>>>> cosmetic changes.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164591
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8164591/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Artem
>


From jamil.j.nimeh at oracle.com  Wed Sep 21 00:57:04 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 20 Sep 2016 17:57:04 -0700
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
Message-ID: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>

Hello all,

This fixes a bug found in stress testing where on faster CPUs the latch 
can overflow resulting in a negative array index.  The fix avoids the 
overflow by resetting the latch to 0 when it reaches Integer.MAX_VALUE - 
1 and will continue increasing from there.

Bug: https://bugs.openjdk.java.net/browse/JDK-8049516
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8049516/webrev.01/

Thanks,
--Jamil

From xuelei.fan at oracle.com  Wed Sep 21 01:58:11 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 21 Sep 2016 09:58:11 +0800
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
Message-ID: <555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>

   359   while (System.nanoTime() - startTime < 250000000) {
   360       synchronized(this){};
- 361       latch++;
+ 361       latch = (latch + 1) % Integer.MAX_VALUE;
   362   }

This block may be not CPU friendly as it may loop a large amount of 
times in a very short period (250milli).

What's the usage of line 360?  Just for some computation?

367   counter += latch;
The counter variable may be overflow too.

Xuelei

On 9/21/2016 8:57 AM, Jamil Nimeh wrote:
> Hello all,
>
> This fixes a bug found in stress testing where on faster CPUs the latch
> can overflow resulting in a negative array index.  The fix avoids the
> overflow by resetting the latch to 0 when it reaches Integer.MAX_VALUE -
> 1 and will continue increasing from there.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8049516
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8049516/webrev.01/
>
> Thanks,
> --Jamil

From weijun.wang at oracle.com  Wed Sep 21 02:52:06 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 21 Sep 2016 10:52:06 +0800
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
	<555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
Message-ID: <9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>


> On Sep 21, 2016, at 9:58 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
>  359   while (System.nanoTime() - startTime < 250000000) {
>  360       synchronized(this){};
> - 361       latch++;
> + 361       latch = (latch + 1) % Integer.MAX_VALUE;
>  362   }
> 
> This block may be not CPU friendly as it may loop a large amount of times in a very short period (250milli).

To get a <255 index I think we only need to loop for <66536 times.

How about we stop at every millisecond and see if it's enough? Something like this:

    long next = startTime + 1000000;
    while (next < startTime + 250000000) {
        while (System.nanoTime() < next) {
            synchronized(this){};
            latch++;
        }
        if (latch > 65535 || latch < 0) break;
        next += 1000000;
    }

> 
> What's the usage of line 360?  Just for some computation?
> 
> 367   counter += latch;
> The counter variable may be overflow too.

I find this strange. Were computers so slow in 1996 that within 250ms latch cannot exceed 64000?

--Max

> 
> Xuelei
> 
> On 9/21/2016 8:57 AM, Jamil Nimeh wrote:
>> Hello all,
>> 
>> This fixes a bug found in stress testing where on faster CPUs the latch
>> can overflow resulting in a negative array index.  The fix avoids the
>> overflow by resetting the latch to 0 when it reaches Integer.MAX_VALUE -
>> 1 and will continue increasing from there.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049516
>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8049516/webrev.01/
>> 
>> Thanks,
>> --Jamil


From xuelei.fan at oracle.com  Wed Sep 21 03:11:30 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 21 Sep 2016 11:11:30 +0800
Subject: [9]RFR 8136355: CKM_SSL3_KEY_AND_MAC_DERIVE no longer available
	by default on Solaris 12
In-Reply-To: <09d79499-0ba2-6af1-c9b4-1667878e879f@oracle.com>
References: <09d79499-0ba2-6af1-c9b4-1667878e879f@oracle.com>
Message-ID: <f7fdd15c-35aa-ea59-00fa-dae1b3a037dc@oracle.com>

P11TlsKeyMaterialGenerator.java
102-106:
There is a bug in the previous code. "&&" should be replaced with "||".
-   (version < 0x0300) && (version > 0x0302)
+   (version < 0x0300) || (version > 0x0302)

The other two have the same issues.  Otherwise, looks fine to me.

BTW, if client request to negotiate SSLv3, the server may not be able to 
select other crypto provider that supports SSLv3 at present.  We may 
want a further enhancement later.  As SSLv3 is fading out, this 
enhancement may be not our priority.  I filed a P3 RFE (JDK-8166425) for 
the tracking.

Xuelei


On 9/20/2016 8:31 AM, Valerie Peng wrote:
> Xuelei,
>
> Could you please help reviewing this change?
>
> There are quite a few test failures on Solaris 12 due to the removal of
> Solaris PKCS11 SSL3 mechanisms which SunPKCS11 provider assume to be
> always present. I updated relevant classes as well as regression tests
> to skip SSL3 testing when the support isn't there.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8136355
> Webrev: http://cr.openjdk.java.net/~valeriep/8136355/webrev.00/
>
> Thanks,
> Valerie

From jamil.j.nimeh at oracle.com  Wed Sep 21 05:32:40 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 20 Sep 2016 22:32:40 -0700
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
	<555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
	<9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>
Message-ID: <1e504198-104b-e0f4-2b82-db47d5774e95@oracle.com>

Hi Max and Xuelei, thanks for the feedback.


On 09/20/2016 07:52 PM, Wang Weijun wrote:
>> On Sep 21, 2016, at 9:58 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>>   359   while (System.nanoTime() - startTime < 250000000) {
>>   360       synchronized(this){};
>> - 361       latch++;
>> + 361       latch = (latch + 1) % Integer.MAX_VALUE;
>>   362   }
>>
>> This block may be not CPU friendly as it may loop a large amount of times in a very short period (250milli).
You asked about the empty synchronized block also: From what I've been 
reading on this topic it looks like the use of the empty synchronized 
block can be used to force cache coherency between multiple threads.  In 
terms of it being CPU intensive, has seed generation ever pegged a 
processor in the past?

There were cases in the past where it would hang, but that was fixed 
back when Max changed things in the inner loop to use System.nanoTime()  
(see JDK-8157318) but at that point (only 3 months ago) we didn't feel 
the need to restructure the loop.  I don't know that we do at this point 
either.  But we certainly can fix the overflow of the latch easily enough.
> To get a <255 index I think we only need to loop for <66536 times.
>
> How about we stop at every millisecond and see if it's enough? Something like this:
>
>      long next = startTime + 1000000;
>      while (next < startTime + 250000000) {
>          while (System.nanoTime() < next) {
>              synchronized(this){};
>              latch++;
>          }
>          if (latch > 65535 || latch < 0) break;
>          next += 1000000;
>      }
>
>> What's the usage of line 360?  Just for some computation?
>>
>> 367   counter += latch;
>> The counter variable may be overflow too.
> I find this strange. Were computers so slow in 1996 that within 250ms latch cannot exceed 64000?
1996?  You're talking about pentium and pentium 2 machines so at best 
you're talking 450MHz.  I don't know if the latch wouldn't pop under 
those conditions.

As for the counter, a potential overflow I don't think is that bad given 
the way the loop control is written.  At worst it just means another 
spin around the outer loop and another byte dropped in the pool.  And 
that loop can only iterate 6 times at the most so it's not like things 
can run away.


>
> --Max
>
>> Xuelei
>>
>> On 9/21/2016 8:57 AM, Jamil Nimeh wrote:
>>> Hello all,
>>>
>>> This fixes a bug found in stress testing where on faster CPUs the latch
>>> can overflow resulting in a negative array index.  The fix avoids the
>>> overflow by resetting the latch to 0 when it reaches Integer.MAX_VALUE -
>>> 1 and will continue increasing from there.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049516
>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8049516/webrev.01/
>>>
>>> Thanks,
>>> --Jamil


From sha.jiang at oracle.com  Wed Sep 21 09:48:58 2016
From: sha.jiang at oracle.com (John Jiang)
Date: Wed, 21 Sep 2016 17:48:58 +0800
Subject: RFR[9] JDK-8166439: Test sun/security/tools/jarsigner/nameclash.sh
	needs to output more details
Message-ID: <4ab36546-2f63-4b5b-82ad-4e297a59e5cb@oracle.com>

Hi,
I'm looking into JDK-8164827: sun/security/tools/jarsigner/nameclash.sh 
timeout
But I cannot reproduce this issue, and the test didn't display any 
useful info.
This patch takes this test to output more details.

Webrev: http://cr.openjdk.java.net/~jjiang/8166439/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8166439

Best regards,
John Jiang


From sergei.kovalev at oracle.com  Wed Sep 21 12:08:18 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Wed, 21 Sep 2016 15:08:18 +0300
Subject: RFR(s): 8166450: SMARTCARDIO related tests failed on compilation
Message-ID: <458b5e35-592a-3121-b188-4a4766378121@oracle.com>

Hello team,

Could you please review small fix for regression tests related to 
smartcardio API?

BugID: https://bugs.openjdk.java.net/browse/JDK-8166450
WebRev: http://cr.openjdk.java.net/~skovalev/8166450/webrev.00/

Issue: unable to run smartcardio related tests bu jtreg by default.
Root cause: missed module declaration in the tests header.
Solution: Adding missed module declaration.
Testing done: Fix tested locally using jtreg and "--limit-modules" 
command line option.

-- 
With best regards,
Sergei


From weijun.wang at oracle.com  Wed Sep 21 14:04:13 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 21 Sep 2016 22:04:13 +0800
Subject: RFR(s): 8166450: SMARTCARDIO related tests failed on compilation
In-Reply-To: <458b5e35-592a-3121-b188-4a4766378121@oracle.com>
References: <458b5e35-592a-3121-b188-4a4766378121@oracle.com>
Message-ID: <867B0F12-5972-43AA-B3DC-727EFBCE9162@oracle.com>

Change looks fine.

One question: When you say the --limit-modules option, is it a new option for jtreg that allows it to automatically choose modules described in the @modules tags? Or it's just the standard VM option and you still need to provide the module names yourself?

Thanks
Max

> On Sep 21, 2016, at 8:08 PM, Sergei Kovalev <sergei.kovalev at oracle.com> wrote:
> 
> Hello team,
> 
> Could you please review small fix for regression tests related to smartcardio API?
> 
> BugID: https://bugs.openjdk.java.net/browse/JDK-8166450
> WebRev: http://cr.openjdk.java.net/~skovalev/8166450/webrev.00/
> 
> Issue: unable to run smartcardio related tests bu jtreg by default.
> Root cause: missed module declaration in the tests header.
> Solution: Adding missed module declaration.
> Testing done: Fix tested locally using jtreg and "--limit-modules" command line option.
> 
> -- 
> With best regards,
> Sergei
> 


From sergei.kovalev at oracle.com  Wed Sep 21 14:06:14 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Wed, 21 Sep 2016 17:06:14 +0300
Subject: RFR(s): 8166450: SMARTCARDIO related tests failed on compilation
In-Reply-To: <867B0F12-5972-43AA-B3DC-727EFBCE9162@oracle.com>
References: <458b5e35-592a-3121-b188-4a4766378121@oracle.com>
	<867B0F12-5972-43AA-B3DC-727EFBCE9162@oracle.com>
Message-ID: <838d98a4-6b83-ea49-a17b-ac2ce4e600ec@oracle.com>

Hi Max,

This is standard VM option. To emulate minimal JRE I'm using 
"--limit-modules java.base" option.


21.09.16 17:04, Wang Weijun wrote:
> Change looks fine.
>
> One question: When you say the --limit-modules option, is it a new option for jtreg that allows it to automatically choose modules described in the @modules tags? Or it's just the standard VM option and you still need to provide the module names yourself?
>
> Thanks
> Max
>
>> On Sep 21, 2016, at 8:08 PM, Sergei Kovalev <sergei.kovalev at oracle.com> wrote:
>>
>> Hello team,
>>
>> Could you please review small fix for regression tests related to smartcardio API?
>>
>> BugID: https://bugs.openjdk.java.net/browse/JDK-8166450
>> WebRev: http://cr.openjdk.java.net/~skovalev/8166450/webrev.00/
>>
>> Issue: unable to run smartcardio related tests bu jtreg by default.
>> Root cause: missed module declaration in the tests header.
>> Solution: Adding missed module declaration.
>> Testing done: Fix tested locally using jtreg and "--limit-modules" command line option.
>>
>> -- 
>> With best regards,
>> Sergei
>>

-- 
With best regards,
Sergei


From jamil.j.nimeh at oracle.com  Wed Sep 21 15:57:22 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 21 Sep 2016 08:57:22 -0700
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <1e504198-104b-e0f4-2b82-db47d5774e95@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
	<555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
	<9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>
	<1e504198-104b-e0f4-2b82-db47d5774e95@oracle.com>
Message-ID: <2299a533-6291-18b4-3595-9318a598b056@oracle.com>

Hi Max and Xuelei,

Yesterday I also reached out to the SQE engineer who submitted the bug, 
asking if this is an issue he's seen going forward from the original 
instance in 8u20.  He said that he hasn't seen this issue come up since 
the original bug submission.  Since the simple overflow condition is 
easily solved with my fix, and the code has been otherwise stable I'd 
like to suggest that we keep the fix as-is.  The loop timing as it 
stands now is not the source of the bug, other than that latch can 
overflow and that is solved in one line.  If we want to revisit this and 
improve the overall performance (though I haven't seen evidence that 
there is a perf issue with this at all) then maybe an RFE is in order.  
What do you think?

--Jamil


On 09/20/2016 10:32 PM, Jamil Nimeh wrote:
> Hi Max and Xuelei, thanks for the feedback.
>
>
> On 09/20/2016 07:52 PM, Wang Weijun wrote:
>>> On Sep 21, 2016, at 9:58 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>
>>>   359   while (System.nanoTime() - startTime < 250000000) {
>>>   360       synchronized(this){};
>>> - 361       latch++;
>>> + 361       latch = (latch + 1) % Integer.MAX_VALUE;
>>>   362   }
>>>
>>> This block may be not CPU friendly as it may loop a large amount of 
>>> times in a very short period (250milli).
> You asked about the empty synchronized block also: From what I've been 
> reading on this topic it looks like the use of the empty synchronized 
> block can be used to force cache coherency between multiple threads.  
> In terms of it being CPU intensive, has seed generation ever pegged a 
> processor in the past?
>
> There were cases in the past where it would hang, but that was fixed 
> back when Max changed things in the inner loop to use 
> System.nanoTime()  (see JDK-8157318) but at that point (only 3 months 
> ago) we didn't feel the need to restructure the loop.  I don't know 
> that we do at this point either.  But we certainly can fix the 
> overflow of the latch easily enough.
>> To get a <255 index I think we only need to loop for <66536 times.
>>
>> How about we stop at every millisecond and see if it's enough? 
>> Something like this:
>>
>>      long next = startTime + 1000000;
>>      while (next < startTime + 250000000) {
>>          while (System.nanoTime() < next) {
>>              synchronized(this){};
>>              latch++;
>>          }
>>          if (latch > 65535 || latch < 0) break;
>>          next += 1000000;
>>      }
>>
>>> What's the usage of line 360?  Just for some computation?
>>>
>>> 367   counter += latch;
>>> The counter variable may be overflow too.
>> I find this strange. Were computers so slow in 1996 that within 250ms 
>> latch cannot exceed 64000?
> 1996?  You're talking about pentium and pentium 2 machines so at best 
> you're talking 450MHz.  I don't know if the latch wouldn't pop under 
> those conditions.
>
> As for the counter, a potential overflow I don't think is that bad 
> given the way the loop control is written.  At worst it just means 
> another spin around the outer loop and another byte dropped in the 
> pool.  And that loop can only iterate 6 times at the most so it's not 
> like things can run away.
>
>
>>
>> --Max
>>
>>> Xuelei
>>>
>>> On 9/21/2016 8:57 AM, Jamil Nimeh wrote:
>>>> Hello all,
>>>>
>>>> This fixes a bug found in stress testing where on faster CPUs the 
>>>> latch
>>>> can overflow resulting in a negative array index.  The fix avoids the
>>>> overflow by resetting the latch to 0 when it reaches 
>>>> Integer.MAX_VALUE -
>>>> 1 and will continue increasing from there.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049516
>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8049516/webrev.01/
>>>>
>>>> Thanks,
>>>> --Jamil
>


From weijun.wang at oracle.com  Wed Sep 21 16:05:58 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 22 Sep 2016 00:05:58 +0800
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <2299a533-6291-18b4-3595-9318a598b056@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
	<555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
	<9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>
	<1e504198-104b-e0f4-2b82-db47d5774e95@oracle.com>
	<2299a533-6291-18b4-3595-9318a598b056@oracle.com>
Message-ID: <E4711695-FDAF-4802-AA76-718BD47C6B38@oracle.com>

I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a little difficult to understand. Does rndTab[latch & 0xff] also work?

Thanks
Max


> On Sep 21, 2016, at 11:57 PM, Jamil Nimeh <jamil.j.nimeh at oracle.com> wrote:
> 
> Hi Max and Xuelei,
> 
> Yesterday I also reached out to the SQE engineer who submitted the bug, asking if this is an issue he's seen going forward from the original instance in 8u20.  He said that he hasn't seen this issue come up since the original bug submission.  Since the simple overflow condition is easily solved with my fix, and the code has been otherwise stable I'd like to suggest that we keep the fix as-is.  The loop timing as it stands now is not the source of the bug, other than that latch can overflow and that is solved in one line.  If we want to revisit this and improve the overall performance (though I haven't seen evidence that there is a perf issue with this at all) then maybe an RFE is in order.  What do you think?
> 
> --Jamil


From jamil.j.nimeh at oracle.com  Wed Sep 21 16:54:55 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 21 Sep 2016 09:54:55 -0700
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <E4711695-FDAF-4802-AA76-718BD47C6B38@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
	<555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
	<9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>
	<1e504198-104b-e0f4-2b82-db47d5774e95@oracle.com>
	<2299a533-6291-18b4-3595-9318a598b056@oracle.com>
	<E4711695-FDAF-4802-AA76-718BD47C6B38@oracle.com>
Message-ID: <67065457-5da8-16c4-f8e3-8fb350117496@oracle.com>

Unfortunately not just with a straight "latch & 0xff" because the rndTab 
array is 255 bytes, so every time latch is a multiple of 255 you end up 
out of bounds.  It would work if we could add a 256th byte to the 
array.  The comments suggest that there is an even statistical 
distribution of the values in the s-box (rndTab) so I'm not sure I can 
just pick a byte and drop it in there.

Let me see if there's another way to update latch that will be less cryptic.

--Jamil


On 09/21/2016 09:05 AM, Wang Weijun wrote:
> I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a little difficult to understand. Does rndTab[latch & 0xff] also work?
>
> Thanks
> Max
>
>
>> On Sep 21, 2016, at 11:57 PM, Jamil Nimeh <jamil.j.nimeh at oracle.com> wrote:
>>
>> Hi Max and Xuelei,
>>
>> Yesterday I also reached out to the SQE engineer who submitted the bug, asking if this is an issue he's seen going forward from the original instance in 8u20.  He said that he hasn't seen this issue come up since the original bug submission.  Since the simple overflow condition is easily solved with my fix, and the code has been otherwise stable I'd like to suggest that we keep the fix as-is.  The loop timing as it stands now is not the source of the bug, other than that latch can overflow and that is solved in one line.  If we want to revisit this and improve the overall performance (though I haven't seen evidence that there is a perf issue with this at all) then maybe an RFE is in order.  What do you think?
>>
>> --Jamil


From valerie.peng at oracle.com  Wed Sep 21 17:28:51 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 21 Sep 2016 10:28:51 -0700
Subject: [9]RFR 8136355: CKM_SSL3_KEY_AND_MAC_DERIVE no longer available
	by default on Solaris 12
In-Reply-To: <f7fdd15c-35aa-ea59-00fa-dae1b3a037dc@oracle.com>
References: <09d79499-0ba2-6af1-c9b4-1667878e879f@oracle.com>
	<f7fdd15c-35aa-ea59-00fa-dae1b3a037dc@oracle.com>
Message-ID: <ba9a3565-4623-95ff-7e30-c88277476a90@oracle.com>

Good catch, I have fixed all three and updated the webrev:
http://cr.openjdk.java.net/~valeriep/8136355/webrev.01

Thanks for the prompt review~
Valerie

On 9/20/2016 8:11 PM, Xuelei Fan wrote:
> P11TlsKeyMaterialGenerator.java
> 102-106:
> There is a bug in the previous code. "&&" should be replaced with "||".
> -   (version < 0x0300) && (version > 0x0302)
> +   (version < 0x0300) || (version > 0x0302)
>
> The other two have the same issues.  Otherwise, looks fine to me.
>
> BTW, if client request to negotiate SSLv3, the server may not be able 
> to select other crypto provider that supports SSLv3 at present.  We 
> may want a further enhancement later.  As SSLv3 is fading out, this 
> enhancement may be not our priority.  I filed a P3 RFE (JDK-8166425) 
> for the tracking.
>
> Xuelei
>
>
> On 9/20/2016 8:31 AM, Valerie Peng wrote:
>> Xuelei,
>>
>> Could you please help reviewing this change?
>>
>> There are quite a few test failures on Solaris 12 due to the removal of
>> Solaris PKCS11 SSL3 mechanisms which SunPKCS11 provider assume to be
>> always present. I updated relevant classes as well as regression tests
>> to skip SSL3 testing when the support isn't there.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136355
>> Webrev: http://cr.openjdk.java.net/~valeriep/8136355/webrev.00/
>>
>> Thanks,
>> Valerie


From sean.coffey at oracle.com  Wed Sep 21 17:49:04 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 21 Sep 2016 18:49:04 +0100
Subject: [9]RFR 8136355: CKM_SSL3_KEY_AND_MAC_DERIVE no longer available
	by default on Solaris 12
In-Reply-To: <ba9a3565-4623-95ff-7e30-c88277476a90@oracle.com>
References: <09d79499-0ba2-6af1-c9b4-1667878e879f@oracle.com>
	<f7fdd15c-35aa-ea59-00fa-dae1b3a037dc@oracle.com>
	<ba9a3565-4623-95ff-7e30-c88277476a90@oracle.com>
Message-ID: <57E2C810.8060901@oracle.com>

Hey Valerie,

There are a few calls in this code where an exception is thrown if a bad 
version is received. It's code that already existed, but would you mind 
enhancing the exceptions to print the version while editing the code there ?
e.g. P11TlsKeyMaterialGenerator.java
> +             throw new InvalidAlgorithmParameterException
> +                    ("Only" + (supportSSLv3? " SSL 3.0,": "") +
> +                     " TLS 1.0, and TLS 1.1 are supported");

Regards,
Sean.

On 21/09/16 18:28, Valerie Peng wrote:
> Good catch, I have fixed all three and updated the webrev:
> http://cr.openjdk.java.net/~valeriep/8136355/webrev.01
>
> Thanks for the prompt review~
> Valerie
>
> On 9/20/2016 8:11 PM, Xuelei Fan wrote:
>> P11TlsKeyMaterialGenerator.java
>> 102-106:
>> There is a bug in the previous code. "&&" should be replaced with "||".
>> -   (version < 0x0300) && (version > 0x0302)
>> +   (version < 0x0300) || (version > 0x0302)
>>
>> The other two have the same issues.  Otherwise, looks fine to me.
>>
>> BTW, if client request to negotiate SSLv3, the server may not be able 
>> to select other crypto provider that supports SSLv3 at present.  We 
>> may want a further enhancement later.  As SSLv3 is fading out, this 
>> enhancement may be not our priority.  I filed a P3 RFE (JDK-8166425) 
>> for the tracking.
>>
>> Xuelei
>>
>>
>> On 9/20/2016 8:31 AM, Valerie Peng wrote:
>>> Xuelei,
>>>
>>> Could you please help reviewing this change?
>>>
>>> There are quite a few test failures on Solaris 12 due to the removal of
>>> Solaris PKCS11 SSL3 mechanisms which SunPKCS11 provider assume to be
>>> always present. I updated relevant classes as well as regression tests
>>> to skip SSL3 testing when the support isn't there.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136355
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8136355/webrev.00/
>>>
>>> Thanks,
>>> Valerie
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160921/75ced79e/attachment.html>

From jamil.j.nimeh at oracle.com  Wed Sep 21 23:29:39 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 21 Sep 2016 16:29:39 -0700
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <E4711695-FDAF-4802-AA76-718BD47C6B38@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
	<555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
	<9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>
	<1e504198-104b-e0f4-2b82-db47d5774e95@oracle.com>
	<2299a533-6291-18b4-3595-9318a598b056@oracle.com>
	<E4711695-FDAF-4802-AA76-718BD47C6B38@oracle.com>
Message-ID: <9adc03da-2522-4529-1346-6c690a7baf87@oracle.com>

So here are a couple ideas related to your suggestion.

We can leave a simple increment on latch and let it overflow, then in 
the array access do this:

v ^= rndTab[(latch & 0x7FFFFFFF) % 255];

That clears the high order bit and the mod will keep it in the range of 
0-254.  the lvalue for the mod operation will never go negative.  The 
downside of that is counter will still get assigned a large negative 
value (which as I said earlier could cause another iteration of the main 
loop...not the end of the world since it can only happen 6 times max).

The other approach would be to increment latch and mask off the high 
order bit:

latch = (latch + 1) & 0x7FFFFFFF;  // Mask the sign bit

Then the v^=[latch % 255] is safe as-is and counter doesn't get some 
massively negative value (though it can still overflow across multiple 
iterations of the outer loop).

I like the second approach a little better, personally.  Up-front use of 
the bitwise-and is a little more clear that we're forcing the value to 
be non-negative before we use it as an array index input.  Let me know 
what you think and I'll update the webrev accordingly.

Thanks,
--Jamil

On 09/21/2016 09:05 AM, Wang Weijun wrote:
> I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a little difficult to understand. Does rndTab[latch & 0xff] also work?
>
> Thanks
> Max
>
>
>> On Sep 21, 2016, at 11:57 PM, Jamil Nimeh <jamil.j.nimeh at oracle.com> wrote:
>>
>> Hi Max and Xuelei,
>>
>> Yesterday I also reached out to the SQE engineer who submitted the bug, asking if this is an issue he's seen going forward from the original instance in 8u20.  He said that he hasn't seen this issue come up since the original bug submission.  Since the simple overflow condition is easily solved with my fix, and the code has been otherwise stable I'd like to suggest that we keep the fix as-is.  The loop timing as it stands now is not the source of the bug, other than that latch can overflow and that is solved in one line.  If we want to revisit this and improve the overall performance (though I haven't seen evidence that there is a perf issue with this at all) then maybe an RFE is in order.  What do you think?
>>
>> --Jamil


From valerie.peng at oracle.com  Wed Sep 21 23:40:15 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 21 Sep 2016 16:40:15 -0700
Subject: [9]RFR 8136355: CKM_SSL3_KEY_AND_MAC_DERIVE no longer available
	by default on Solaris 12
In-Reply-To: <57E2C810.8060901@oracle.com>
References: <09d79499-0ba2-6af1-c9b4-1667878e879f@oracle.com>
	<f7fdd15c-35aa-ea59-00fa-dae1b3a037dc@oracle.com>
	<ba9a3565-4623-95ff-7e30-c88277476a90@oracle.com>
	<57E2C810.8060901@oracle.com>
Message-ID: <72388807-ccae-0b71-0753-43ea26fe0f33@oracle.com>

Alright, I included the hex value of the version to the exception message.
In addition, one of the regression test was using 0x400 as the version 
value and that has to be removed now that the version check has been 
corrected.
http://cr.openjdk.java.net/~valeriep/8136355/webrev.02/

Thanks,
Valerie

On 9/21/2016 10:49 AM, Se?n Coffey wrote:
> Hey Valerie,
>
> There are a few calls in this code where an exception is thrown if a 
> bad version is received. It's code that already existed, but would you 
> mind enhancing the exceptions to print the version while editing the 
> code there ?
> e.g. P11TlsKeyMaterialGenerator.java
>> +             throw new InvalidAlgorithmParameterException
>> +                    ("Only" + (supportSSLv3? " SSL 3.0,": "") +
>> +                     " TLS 1.0, and TLS 1.1 are supported");
> Regards,
> Sean.
> On 21/09/16 18:28, Valerie Peng wrote:
>> Good catch, I have fixed all three and updated the webrev:
>> http://cr.openjdk.java.net/~valeriep/8136355/webrev.01
>>
>> Thanks for the prompt review~
>> Valerie
>>
>> On 9/20/2016 8:11 PM, Xuelei Fan wrote:
>>> P11TlsKeyMaterialGenerator.java
>>> 102-106:
>>> There is a bug in the previous code. "&&" should be replaced with "||".
>>> -   (version < 0x0300) && (version > 0x0302)
>>> +   (version < 0x0300) || (version > 0x0302)
>>>
>>> The other two have the same issues.  Otherwise, looks fine to me.
>>>
>>> BTW, if client request to negotiate SSLv3, the server may not be 
>>> able to select other crypto provider that supports SSLv3 at 
>>> present.  We may want a further enhancement later.  As SSLv3 is 
>>> fading out, this enhancement may be not our priority.  I filed a P3 
>>> RFE (JDK-8166425) for the tracking.
>>>
>>> Xuelei
>>>
>>>
>>> On 9/20/2016 8:31 AM, Valerie Peng wrote:
>>>> Xuelei,
>>>>
>>>> Could you please help reviewing this change?
>>>>
>>>> There are quite a few test failures on Solaris 12 due to the 
>>>> removal of
>>>> Solaris PKCS11 SSL3 mechanisms which SunPKCS11 provider assume to be
>>>> always present. I updated relevant classes as well as regression tests
>>>> to skip SSL3 testing when the support isn't there.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136355
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8136355/webrev.00/
>>>>
>>>> Thanks,
>>>> Valerie
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160921/6375f460/attachment.html>

From xuelei.fan at oracle.com  Thu Sep 22 00:23:15 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 22 Sep 2016 08:23:15 +0800
Subject: [9]RFR 8136355: CKM_SSL3_KEY_AND_MAC_DERIVE no longer available
	by default on Solaris 12
In-Reply-To: <72388807-ccae-0b71-0753-43ea26fe0f33@oracle.com>
References: <09d79499-0ba2-6af1-c9b4-1667878e879f@oracle.com>
	<f7fdd15c-35aa-ea59-00fa-dae1b3a037dc@oracle.com>
	<ba9a3565-4623-95ff-7e30-c88277476a90@oracle.com>
	<57E2C810.8060901@oracle.com>
	<72388807-ccae-0b71-0753-43ea26fe0f33@oracle.com>
Message-ID: <fb2a65c0-c61e-3a0b-b3ce-7d6512f82c59@oracle.com>

Looks fine to me.

Xuelei

On 9/22/2016 7:40 AM, Valerie Peng wrote:
> Alright, I included the hex value of the version to the exception message.
> In addition, one of the regression test was using 0x400 as the version
> value and that has to be removed now that the version check has been
> corrected.
> http://cr.openjdk.java.net/~valeriep/8136355/webrev.02/
>
> Thanks,
> Valerie
>
> On 9/21/2016 10:49 AM, Se?n Coffey wrote:
>> Hey Valerie,
>>
>> There are a few calls in this code where an exception is thrown if a
>> bad version is received. It's code that already existed, but would you
>> mind enhancing the exceptions to print the version while editing the
>> code there ?
>> e.g. P11TlsKeyMaterialGenerator.java
>>> +             throw new InvalidAlgorithmParameterException
>>> +                    ("Only" + (supportSSLv3? " SSL 3.0,": "") +
>>> +                     " TLS 1.0, and TLS 1.1 are supported");
>> Regards,
>> Sean.
>> On 21/09/16 18:28, Valerie Peng wrote:
>>> Good catch, I have fixed all three and updated the webrev:
>>> http://cr.openjdk.java.net/~valeriep/8136355/webrev.01
>>>
>>> Thanks for the prompt review~
>>> Valerie
>>>
>>> On 9/20/2016 8:11 PM, Xuelei Fan wrote:
>>>> P11TlsKeyMaterialGenerator.java
>>>> 102-106:
>>>> There is a bug in the previous code. "&&" should be replaced with "||".
>>>> -   (version < 0x0300) && (version > 0x0302)
>>>> +   (version < 0x0300) || (version > 0x0302)
>>>>
>>>> The other two have the same issues.  Otherwise, looks fine to me.
>>>>
>>>> BTW, if client request to negotiate SSLv3, the server may not be
>>>> able to select other crypto provider that supports SSLv3 at
>>>> present.  We may want a further enhancement later.  As SSLv3 is
>>>> fading out, this enhancement may be not our priority.  I filed a P3
>>>> RFE (JDK-8166425) for the tracking.
>>>>
>>>> Xuelei
>>>>
>>>>
>>>> On 9/20/2016 8:31 AM, Valerie Peng wrote:
>>>>> Xuelei,
>>>>>
>>>>> Could you please help reviewing this change?
>>>>>
>>>>> There are quite a few test failures on Solaris 12 due to the
>>>>> removal of
>>>>> Solaris PKCS11 SSL3 mechanisms which SunPKCS11 provider assume to be
>>>>> always present. I updated relevant classes as well as regression tests
>>>>> to skip SSL3 testing when the support isn't there.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136355
>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8136355/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Valerie
>>>
>>
>

From xuelei.fan at oracle.com  Thu Sep 22 00:34:13 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 22 Sep 2016 08:34:13 +0800
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <9adc03da-2522-4529-1346-6c690a7baf87@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
	<555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
	<9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>
	<1e504198-104b-e0f4-2b82-db47d5774e95@oracle.com>
	<2299a533-6291-18b4-3595-9318a598b056@oracle.com>
	<E4711695-FDAF-4802-AA76-718BD47C6B38@oracle.com>
	<9adc03da-2522-4529-1346-6c690a7baf87@oracle.com>
Message-ID: <f98e3e01-afb6-a740-ad27-c0b61412dd20@oracle.com>

 > latch = (latch + 1) & 0x7FFFFFFF;  // Mask the sign bit
I'm fine with it.

BTW, if you like, I may suggest to use a little bit small number for the 
mask, for example 0x1FFFFFFF, so that the counter variable does not 
overflow either.  It works if counter overflow, but better not if we 
want the counter meaningful.

Xuelei


On 9/22/2016 7:29 AM, Jamil Nimeh wrote:
> So here are a couple ideas related to your suggestion.
>
> We can leave a simple increment on latch and let it overflow, then in
> the array access do this:
>
> v ^= rndTab[(latch & 0x7FFFFFFF) % 255];
>
> That clears the high order bit and the mod will keep it in the range of
> 0-254.  the lvalue for the mod operation will never go negative.  The
> downside of that is counter will still get assigned a large negative
> value (which as I said earlier could cause another iteration of the main
> loop...not the end of the world since it can only happen 6 times max).
>
> The other approach would be to increment latch and mask off the high
> order bit:
>
> latch = (latch + 1) & 0x7FFFFFFF;  // Mask the sign bit
>
> Then the v^=[latch % 255] is safe as-is and counter doesn't get some
> massively negative value (though it can still overflow across multiple
> iterations of the outer loop).
>
> I like the second approach a little better, personally.  Up-front use of
> the bitwise-and is a little more clear that we're forcing the value to
> be non-negative before we use it as an array index input.  Let me know
> what you think and I'll update the webrev accordingly.
>
> Thanks,
> --Jamil
>
> On 09/21/2016 09:05 AM, Wang Weijun wrote:
>> I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a
>> little difficult to understand. Does rndTab[latch & 0xff] also work?
>>
>> Thanks
>> Max
>>
>>
>>> On Sep 21, 2016, at 11:57 PM, Jamil Nimeh <jamil.j.nimeh at oracle.com>
>>> wrote:
>>>
>>> Hi Max and Xuelei,
>>>
>>> Yesterday I also reached out to the SQE engineer who submitted the
>>> bug, asking if this is an issue he's seen going forward from the
>>> original instance in 8u20.  He said that he hasn't seen this issue
>>> come up since the original bug submission.  Since the simple overflow
>>> condition is easily solved with my fix, and the code has been
>>> otherwise stable I'd like to suggest that we keep the fix as-is.  The
>>> loop timing as it stands now is not the source of the bug, other than
>>> that latch can overflow and that is solved in one line.  If we want
>>> to revisit this and improve the overall performance (though I haven't
>>> seen evidence that there is a perf issue with this at all) then maybe
>>> an RFE is in order.  What do you think?
>>>
>>> --Jamil
>

From weijun.wang at oracle.com  Thu Sep 22 01:18:49 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 22 Sep 2016 09:18:49 +0800
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <f98e3e01-afb6-a740-ad27-c0b61412dd20@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
	<555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
	<9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>
	<1e504198-104b-e0f4-2b82-db47d5774e95@oracle.com>
	<2299a533-6291-18b4-3595-9318a598b056@oracle.com>
	<E4711695-FDAF-4802-AA76-718BD47C6B38@oracle.com>
	<9adc03da-2522-4529-1346-6c690a7baf87@oracle.com>
	<f98e3e01-afb6-a740-ad27-c0b61412dd20@oracle.com>
Message-ID: <B631C9AD-B523-4D21-BB5E-C5D7EAB3A665@oracle.com>


> On Sep 22, 2016, at 8:34 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> > latch = (latch + 1) & 0x7FFFFFFF;  // Mask the sign bit
> I'm fine with it.
> 
> BTW, if you like, I may suggest to use a little bit small number for the mask, for example 0x1FFFFFFF, so that the counter variable does not overflow either.  It works if counter overflow, but better not if we want the counter meaningful.

Good idea.

--Max


From sean.coffey at oracle.com  Thu Sep 22 07:53:54 2016
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 22 Sep 2016 08:53:54 +0100
Subject: [9]RFR 8136355: CKM_SSL3_KEY_AND_MAC_DERIVE no longer available
	by default on Solaris 12
In-Reply-To: <72388807-ccae-0b71-0753-43ea26fe0f33@oracle.com>
References: <09d79499-0ba2-6af1-c9b4-1667878e879f@oracle.com>
	<f7fdd15c-35aa-ea59-00fa-dae1b3a037dc@oracle.com>
	<ba9a3565-4623-95ff-7e30-c88277476a90@oracle.com>
	<57E2C810.8060901@oracle.com>
	<72388807-ccae-0b71-0753-43ea26fe0f33@oracle.com>
Message-ID: <4A3381AC-7D83-412A-9A32-E386544D45CD@oracle.com>

Thanks!

Regards,
Sean.

On 22 September 2016 00:40:15 GMT+01:00, Valerie Peng <valerie.peng at oracle.com> wrote:
>Alright, I included the hex value of the version to the exception
>message.
>In addition, one of the regression test was using 0x400 as the version 
>value and that has to be removed now that the version check has been 
>corrected.
>http://cr.openjdk.java.net/~valeriep/8136355/webrev.02/
>
>Thanks,
>Valerie
>
>On 9/21/2016 10:49 AM, Se?n Coffey wrote:
>> Hey Valerie,
>>
>> There are a few calls in this code where an exception is thrown if a 
>> bad version is received. It's code that already existed, but would
>you 
>> mind enhancing the exceptions to print the version while editing the 
>> code there ?
>> e.g. P11TlsKeyMaterialGenerator.java
>>> +             throw new InvalidAlgorithmParameterException
>>> +                    ("Only" + (supportSSLv3? " SSL 3.0,": "") +
>>> +                     " TLS 1.0, and TLS 1.1 are supported");
>> Regards,
>> Sean.
>> On 21/09/16 18:28, Valerie Peng wrote:
>>> Good catch, I have fixed all three and updated the webrev:
>>> http://cr.openjdk.java.net/~valeriep/8136355/webrev.01
>>>
>>> Thanks for the prompt review~
>>> Valerie
>>>
>>> On 9/20/2016 8:11 PM, Xuelei Fan wrote:
>>>> P11TlsKeyMaterialGenerator.java
>>>> 102-106:
>>>> There is a bug in the previous code. "&&" should be replaced with
>"||".
>>>> -   (version < 0x0300) && (version > 0x0302)
>>>> +   (version < 0x0300) || (version > 0x0302)
>>>>
>>>> The other two have the same issues.  Otherwise, looks fine to me.
>>>>
>>>> BTW, if client request to negotiate SSLv3, the server may not be 
>>>> able to select other crypto provider that supports SSLv3 at 
>>>> present.  We may want a further enhancement later.  As SSLv3 is 
>>>> fading out, this enhancement may be not our priority.  I filed a P3
>
>>>> RFE (JDK-8166425) for the tracking.
>>>>
>>>> Xuelei
>>>>
>>>>
>>>> On 9/20/2016 8:31 AM, Valerie Peng wrote:
>>>>> Xuelei,
>>>>>
>>>>> Could you please help reviewing this change?
>>>>>
>>>>> There are quite a few test failures on Solaris 12 due to the 
>>>>> removal of
>>>>> Solaris PKCS11 SSL3 mechanisms which SunPKCS11 provider assume to
>be
>>>>> always present. I updated relevant classes as well as regression
>tests
>>>>> to skip SSL3 testing when the support isn't there.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136355
>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8136355/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Valerie
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160922/cb0dc357/attachment-0001.html>

From jamil.j.nimeh at oracle.com  Thu Sep 22 08:05:18 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 22 Sep 2016 01:05:18 -0700
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <f98e3e01-afb6-a740-ad27-c0b61412dd20@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
	<555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
	<9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>
	<1e504198-104b-e0f4-2b82-db47d5774e95@oracle.com>
	<2299a533-6291-18b4-3595-9318a598b056@oracle.com>
	<E4711695-FDAF-4802-AA76-718BD47C6B38@oracle.com>
	<9adc03da-2522-4529-1346-6c690a7baf87@oracle.com>
	<f98e3e01-afb6-a740-ad27-c0b61412dd20@oracle.com>
Message-ID: <079f21b8-0aa8-c62a-e586-a8f9e2dbf7d4@oracle.com>

That's a very good suggestion.  I've made that change and updated the 
webrev:

http://cr.openjdk.java.net/~jnimeh/reviews/8049516/webrev.02/

Thanks again,
--Jamil

On 09/21/2016 05:34 PM, Xuelei Fan wrote:
> > latch = (latch + 1) & 0x7FFFFFFF;  // Mask the sign bit
> I'm fine with it.
>
> BTW, if you like, I may suggest to use a little bit small number for 
> the mask, for example 0x1FFFFFFF, so that the counter variable does 
> not overflow either.  It works if counter overflow, but better not if 
> we want the counter meaningful.
>
> Xuelei
>
>
> On 9/22/2016 7:29 AM, Jamil Nimeh wrote:
>> So here are a couple ideas related to your suggestion.
>>
>> We can leave a simple increment on latch and let it overflow, then in
>> the array access do this:
>>
>> v ^= rndTab[(latch & 0x7FFFFFFF) % 255];
>>
>> That clears the high order bit and the mod will keep it in the range of
>> 0-254.  the lvalue for the mod operation will never go negative.  The
>> downside of that is counter will still get assigned a large negative
>> value (which as I said earlier could cause another iteration of the main
>> loop...not the end of the world since it can only happen 6 times max).
>>
>> The other approach would be to increment latch and mask off the high
>> order bit:
>>
>> latch = (latch + 1) & 0x7FFFFFFF;  // Mask the sign bit
>>
>> Then the v^=[latch % 255] is safe as-is and counter doesn't get some
>> massively negative value (though it can still overflow across multiple
>> iterations of the outer loop).
>>
>> I like the second approach a little better, personally. Up-front use of
>> the bitwise-and is a little more clear that we're forcing the value to
>> be non-negative before we use it as an array index input.  Let me know
>> what you think and I'll update the webrev accordingly.
>>
>> Thanks,
>> --Jamil
>>
>> On 09/21/2016 09:05 AM, Wang Weijun wrote:
>>> I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a
>>> little difficult to understand. Does rndTab[latch & 0xff] also work?
>>>
>>> Thanks
>>> Max
>>>
>>>
>>>> On Sep 21, 2016, at 11:57 PM, Jamil Nimeh <jamil.j.nimeh at oracle.com>
>>>> wrote:
>>>>
>>>> Hi Max and Xuelei,
>>>>
>>>> Yesterday I also reached out to the SQE engineer who submitted the
>>>> bug, asking if this is an issue he's seen going forward from the
>>>> original instance in 8u20.  He said that he hasn't seen this issue
>>>> come up since the original bug submission.  Since the simple overflow
>>>> condition is easily solved with my fix, and the code has been
>>>> otherwise stable I'd like to suggest that we keep the fix as-is.  The
>>>> loop timing as it stands now is not the source of the bug, other than
>>>> that latch can overflow and that is solved in one line.  If we want
>>>> to revisit this and improve the overall performance (though I haven't
>>>> seen evidence that there is a perf issue with this at all) then maybe
>>>> an RFE is in order.  What do you think?
>>>>
>>>> --Jamil
>>


From xuelei.fan at oracle.com  Thu Sep 22 08:11:26 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 22 Sep 2016 16:11:26 +0800
Subject: RFR: JDK-8049516: sun.security.provider.SeedGenerator throws
	ArrayIndexOutOfBoundsException
In-Reply-To: <079f21b8-0aa8-c62a-e586-a8f9e2dbf7d4@oracle.com>
References: <b2b64339-3ec0-dfcf-07f4-6672a36c6026@oracle.com>
	<555882df-2cfa-a555-95d6-a96c98081a2c@oracle.com>
	<9A26AC9C-5D24-4429-83D8-F7691936C62C@oracle.com>
	<1e504198-104b-e0f4-2b82-db47d5774e95@oracle.com>
	<2299a533-6291-18b4-3595-9318a598b056@oracle.com>
	<E4711695-FDAF-4802-AA76-718BD47C6B38@oracle.com>
	<9adc03da-2522-4529-1346-6c690a7baf87@oracle.com>
	<f98e3e01-afb6-a740-ad27-c0b61412dd20@oracle.com>
	<079f21b8-0aa8-c62a-e586-a8f9e2dbf7d4@oracle.com>
Message-ID: <50dc6f83-8f2e-705e-3678-d2199c3b86a0@oracle.com>

Looks fine to me.  Thanks!

Xuelei

On 9/22/2016 4:05 PM, Jamil Nimeh wrote:
> That's a very good suggestion.  I've made that change and updated the
> webrev:
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8049516/webrev.02/
>
> Thanks again,
> --Jamil
>
> On 09/21/2016 05:34 PM, Xuelei Fan wrote:
>> > latch = (latch + 1) & 0x7FFFFFFF;  // Mask the sign bit
>> I'm fine with it.
>>
>> BTW, if you like, I may suggest to use a little bit small number for
>> the mask, for example 0x1FFFFFFF, so that the counter variable does
>> not overflow either.  It works if counter overflow, but better not if
>> we want the counter meaningful.
>>
>> Xuelei
>>
>>
>> On 9/22/2016 7:29 AM, Jamil Nimeh wrote:
>>> So here are a couple ideas related to your suggestion.
>>>
>>> We can leave a simple increment on latch and let it overflow, then in
>>> the array access do this:
>>>
>>> v ^= rndTab[(latch & 0x7FFFFFFF) % 255];
>>>
>>> That clears the high order bit and the mod will keep it in the range of
>>> 0-254.  the lvalue for the mod operation will never go negative.  The
>>> downside of that is counter will still get assigned a large negative
>>> value (which as I said earlier could cause another iteration of the main
>>> loop...not the end of the world since it can only happen 6 times max).
>>>
>>> The other approach would be to increment latch and mask off the high
>>> order bit:
>>>
>>> latch = (latch + 1) & 0x7FFFFFFF;  // Mask the sign bit
>>>
>>> Then the v^=[latch % 255] is safe as-is and counter doesn't get some
>>> massively negative value (though it can still overflow across multiple
>>> iterations of the outer loop).
>>>
>>> I like the second approach a little better, personally. Up-front use of
>>> the bitwise-and is a little more clear that we're forcing the value to
>>> be non-negative before we use it as an array index input.  Let me know
>>> what you think and I'll update the webrev accordingly.
>>>
>>> Thanks,
>>> --Jamil
>>>
>>> On 09/21/2016 09:05 AM, Wang Weijun wrote:
>>>> I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a
>>>> little difficult to understand. Does rndTab[latch & 0xff] also work?
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>
>>>>> On Sep 21, 2016, at 11:57 PM, Jamil Nimeh <jamil.j.nimeh at oracle.com>
>>>>> wrote:
>>>>>
>>>>> Hi Max and Xuelei,
>>>>>
>>>>> Yesterday I also reached out to the SQE engineer who submitted the
>>>>> bug, asking if this is an issue he's seen going forward from the
>>>>> original instance in 8u20.  He said that he hasn't seen this issue
>>>>> come up since the original bug submission.  Since the simple overflow
>>>>> condition is easily solved with my fix, and the code has been
>>>>> otherwise stable I'd like to suggest that we keep the fix as-is.  The
>>>>> loop timing as it stands now is not the source of the bug, other than
>>>>> that latch can overflow and that is solved in one line.  If we want
>>>>> to revisit this and improve the overall performance (though I haven't
>>>>> seen evidence that there is a perf issue with this at all) then maybe
>>>>> an RFE is in order.  What do you think?
>>>>>
>>>>> --Jamil
>>>
>

From valerie.peng at oracle.com  Thu Sep 22 21:59:54 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 22 Sep 2016 14:59:54 -0700
Subject: [9]RFR 6946830: javax.crypto.Cipher.doFinal behavior differs
	depending on platform
In-Reply-To: <4ac1ee9c-4851-39e4-1ae5-3b2ba12dd47d@oracle.com>
References: <8bad70f8-8f08-6d51-279f-325e95ddb94f@oracle.com>
	<4ac1ee9c-4851-39e4-1ae5-3b2ba12dd47d@oracle.com>
Message-ID: <d463335f-91ca-46eb-942f-1d0db0d5a5dd@oracle.com>


Ok, I think this should be better:
http://cr.openjdk.java.net/~valeriep/6946830/webrev.01/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Cipher.java.sdiff.html

Made some minor changes for clean up as well.
Thanks,
Valerie



On 9/19/2016 6:20 PM, Xuelei Fan wrote:
> P11Cipher.java
> --------------
> line 775 and 850:
> The code looks special to me.  Is it possible/better to check the 
> range before the call to PKCS11 decryption function?
>
> Xuelei
>
> On 9/20/2016 5:11 AM, Valerie Peng wrote:
>>
>> Anyone has time to review this trivial fix? This is a corner case of
>> decrypting with 0-length data. Some provider throws exception but some
>> just returns (no-op). For less impact, I changed all to match SunJCE
>> provider's behavior which just returns.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6946830
>> Webrev: http://cr.openjdk.java.net/~valeriep/6946830/webrev.00/
>>
>> Thanks,
>> Valerie


From xuelei.fan at oracle.com  Fri Sep 23 00:39:17 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 23 Sep 2016 08:39:17 +0800
Subject: [9]RFR 6946830: javax.crypto.Cipher.doFinal behavior differs
	depending on platform
In-Reply-To: <d463335f-91ca-46eb-942f-1d0db0d5a5dd@oracle.com>
References: <8bad70f8-8f08-6d51-279f-325e95ddb94f@oracle.com>
	<4ac1ee9c-4851-39e4-1ae5-3b2ba12dd47d@oracle.com>
	<d463335f-91ca-46eb-942f-1d0db0d5a5dd@oracle.com>
Message-ID: <cb2ea20e-3e16-5924-e1ab-84c4dbd0abb1@oracle.com>

I like the new update.  Thanks!

Xuelei

On 9/23/2016 5:59 AM, Valerie Peng wrote:
>
> Ok, I think this should be better:
> http://cr.openjdk.java.net/~valeriep/6946830/webrev.01/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Cipher.java.sdiff.html
>
>
> Made some minor changes for clean up as well.
> Thanks,
> Valerie
>
>
>
> On 9/19/2016 6:20 PM, Xuelei Fan wrote:
>> P11Cipher.java
>> --------------
>> line 775 and 850:
>> The code looks special to me.  Is it possible/better to check the
>> range before the call to PKCS11 decryption function?
>>
>> Xuelei
>>
>> On 9/20/2016 5:11 AM, Valerie Peng wrote:
>>>
>>> Anyone has time to review this trivial fix? This is a corner case of
>>> decrypting with 0-length data. Some provider throws exception but some
>>> just returns (no-op). For less impact, I changed all to match SunJCE
>>> provider's behavior which just returns.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6946830
>>> Webrev: http://cr.openjdk.java.net/~valeriep/6946830/webrev.00/
>>>
>>> Thanks,
>>> Valerie
>

From tiantian.du at oracle.com  Tue Sep 27 10:32:35 2016
From: tiantian.du at oracle.com (Tim Du)
Date: Tue, 27 Sep 2016 18:32:35 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall be
	updated to run on ARM platforms
Message-ID: <f57a4feb-0327-5fbe-9c70-8f6977ccc5cd@oracle.com>

Hi All:

Would you help to review the patch for sun/security/pkcs11/PKCS11Test.java?
The test keep pass on not supported platforms, it will make nobody 
notice the test was skipped,which is not our expected. Update case to 
show failure, when platform not supported. And add the support for  
Linux-arm-32 and Linux-arm-64 platforms. Thanks.

JBS: https://bugs.openjdk.java.net/browse/JDK-8164322
Webrev: http://cr.openjdk.java.net/~tidu/8164322/webrev.00/


Regards
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160927/30d72f53/attachment.html>

From xuelei.fan at oracle.com  Tue Sep 27 11:25:19 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 27 Sep 2016 19:25:19 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <f57a4feb-0327-5fbe-9c70-8f6977ccc5cd@oracle.com>
References: <f57a4feb-0327-5fbe-9c70-8f6977ccc5cd@oracle.com>
Message-ID: <b2c72b51-1576-6672-8a1d-41499a72796a@oracle.com>

I think, it is the expected behavior to ignore the test if a platform 
does not support it.  If showing failures, every testing on unsupported 
platform will fail, and additional effort MUST be paid to evaluate the 
root cause of the failure.  We should try to avoid that.

Xuelei

On 9/27/2016 6:32 PM, Tim Du wrote:
> Hi All:
>
> Would you help to review the patch for sun/security/pkcs11/PKCS11Test.java?
> The test keep pass on not supported platforms, it will make nobody
> notice the test was skipped,which is not our expected. Update case to
> show failure, when platform not supported. And add the support for
> Linux-arm-32 and Linux-arm-64 platforms. Thanks.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8164322
> Webrev: http://cr.openjdk.java.net/~tidu/8164322/webrev.00/
>
>
> Regards
> Tim

From sergei.kovalev at oracle.com  Tue Sep 27 12:56:24 2016
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Tue, 27 Sep 2016 15:56:24 +0300
Subject: RFR(s): 8166378: Missing dependencies in several java/security
	tests
In-Reply-To: <99bccefa-b844-f16a-6244-196dcab0852d@oracle.com>
References: <99bccefa-b844-f16a-6244-196dcab0852d@oracle.com>
Message-ID: <da401184-3c9d-8daf-edee-4a641467e0d0@oracle.com>

Hello team,

This is re-request for review.


20.09.16 16:32, Sergei Kovalev wrote:
> Hello team,
>
> Please review very small fix for several regression tests.
>
> BugID: https://bugs.openjdk.java.net/browse/JDK-8166378
> WebReview: http://cr.openjdk.java.net/~skovalev/8166378/webrev.00
>
> Issue: The tests has no declared dependencies on jdk.security modules. 
> This leads the tests to fail in case of usage "--limit-modules" java 
> command line option.
>
> Solution: add missed dependencies if required.
>

-- 
With best regards,
Sergei


From xuelei.fan at oracle.com  Tue Sep 27 13:06:51 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 27 Sep 2016 21:06:51 +0800
Subject: RFR(s): 8166378: Missing dependencies in several java/security
	tests
In-Reply-To: <99bccefa-b844-f16a-6244-196dcab0852d@oracle.com>
References: <99bccefa-b844-f16a-6244-196dcab0852d@oracle.com>
Message-ID: <bf569117-495f-60ee-9717-cad128897d25@oracle.com>

Looks fine to me.

Xuelei

On 9/20/2016 9:32 PM, Sergei Kovalev wrote:
> Hello team,
>
> Please review very small fix for several regression tests.
>
> BugID: https://bugs.openjdk.java.net/browse/JDK-8166378
> WebReview: http://cr.openjdk.java.net/~skovalev/8166378/webrev.00
>
> Issue: The tests has no declared dependencies on jdk.security modules.
> This leads the tests to fail in case of usage "--limit-modules" java
> command line option.
>
> Solution: add missed dependencies if required.
>

From weijun.wang at oracle.com  Tue Sep 27 14:22:45 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 27 Sep 2016 22:22:45 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <b2c72b51-1576-6672-8a1d-41499a72796a@oracle.com>
References: <f57a4feb-0327-5fbe-9c70-8f6977ccc5cd@oracle.com>
	<b2c72b51-1576-6672-8a1d-41499a72796a@oracle.com>
Message-ID: <23AC42BC-3156-4552-A0E0-7EB87CAEFC7E@oracle.com>

Looking at the webrev, it looks we've never tested on "Linux-arm-32" and "Linux-aarch64-64" before and we only realized it now. This is a true problem.

On the other hand, I also agree with Xuelei's concern. If a new platform is added and it does not have NSS libs tests will fail.

How about this? If there is such a new platform called "mhos-arch-32", we can add

   osMap("mhos-arch-32", new String[]{});

and, make nssLibDirs == null a failure, but nssLibDirs.length == 0 can return null.

Is this good?

Thanks
Max


> On Sep 27, 2016, at 7:25 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> I think, it is the expected behavior to ignore the test if a platform does not support it.  If showing failures, every testing on unsupported platform will fail, and additional effort MUST be paid to evaluate the root cause of the failure.  We should try to avoid that.
> 
> Xuelei
> 
> On 9/27/2016 6:32 PM, Tim Du wrote:
>> Hi All:
>> 
>> Would you help to review the patch for sun/security/pkcs11/PKCS11Test.java?
>> The test keep pass on not supported platforms, it will make nobody
>> notice the test was skipped,which is not our expected. Update case to
>> show failure, when platform not supported. And add the support for
>> Linux-arm-32 and Linux-arm-64 platforms. Thanks.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8164322
>> Webrev: http://cr.openjdk.java.net/~tidu/8164322/webrev.00/
>> 
>> 
>> Regards
>> Tim


From artem.smotrakov at oracle.com  Tue Sep 27 18:02:13 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 27 Sep 2016 11:02:13 -0700
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <23AC42BC-3156-4552-A0E0-7EB87CAEFC7E@oracle.com>
References: <f57a4feb-0327-5fbe-9c70-8f6977ccc5cd@oracle.com>
	<b2c72b51-1576-6672-8a1d-41499a72796a@oracle.com>
	<23AC42BC-3156-4552-A0E0-7EB87CAEFC7E@oracle.com>
Message-ID: <fe47510a-ccb8-4ff8-a0d8-aa8bd82c7b1f@oracle.com>

(cc'ing Denis who reported the bug)

I think making PKCS11 tests fail on unexpected platform would be helpful 
for people who port JDK on new platforms and run tests on them. 
Currently the tests silently quit which looks like they pass. This makes 
people think that everything went smoothly, but actually nothing was tested.

I would prefer to update PKCS11Test to report a failure in case of 
unexpected platform.

But before that it would be good to make sure that PKCS11 tests work 
fine on those generic platforms which are listed in "osMap".

Tim,

Did you run PKCS11 tests on those platforms? (it might be good to submit 
multiple runs).

One minor comment, could you please check that indentation is correct in 
lines 625-629?

Artem

On 09/27/2016 07:22 AM, Wang Weijun wrote:
> Looking at the webrev, it looks we've never tested on "Linux-arm-32" and "Linux-aarch64-64" before and we only realized it now. This is a true problem.
>
> On the other hand, I also agree with Xuelei's concern. If a new platform is added and it does not have NSS libs tests will fail.
>
> How about this? If there is such a new platform called "mhos-arch-32", we can add
>
>     osMap("mhos-arch-32", new String[]{});
>
> and, make nssLibDirs == null a failure, but nssLibDirs.length == 0 can return null.
>
> Is this good?
>
> Thanks
> Max
>
>
>> On Sep 27, 2016, at 7:25 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> I think, it is the expected behavior to ignore the test if a platform does not support it.  If showing failures, every testing on unsupported platform will fail, and additional effort MUST be paid to evaluate the root cause of the failure.  We should try to avoid that.
>>
>> Xuelei
>>
>> On 9/27/2016 6:32 PM, Tim Du wrote:
>>> Hi All:
>>>
>>> Would you help to review the patch for sun/security/pkcs11/PKCS11Test.java?
>>> The test keep pass on not supported platforms, it will make nobody
>>> notice the test was skipped,which is not our expected. Update case to
>>> show failure, when platform not supported. And add the support for
>>> Linux-arm-32 and Linux-arm-64 platforms. Thanks.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8164322
>>> Webrev: http://cr.openjdk.java.net/~tidu/8164322/webrev.00/
>>>
>>>
>>> Regards
>>> Tim


From valerie.peng at oracle.com  Tue Sep 27 21:46:53 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 27 Sep 2016 14:46:53 -0700
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <23AC42BC-3156-4552-A0E0-7EB87CAEFC7E@oracle.com>
References: <f57a4feb-0327-5fbe-9c70-8f6977ccc5cd@oracle.com>
	<b2c72b51-1576-6672-8a1d-41499a72796a@oracle.com>
	<23AC42BC-3156-4552-A0E0-7EB87CAEFC7E@oracle.com>
Message-ID: <6c109a02-43a0-7ac7-24cc-8d808388d7bb@oracle.com>

I think it makes sense to error out on unknown platforms.
This doesn't conflict with skipping tests (or silently passing) for 
unsupported platforms.
We just need a way to distinguish them. I'd probably go for the same 
approach that Max suggested, i.e. add the list of (known) unsupported 
platforms to osMap and errors out if the requested platform cannot be 
found in osMap.

Valerie

On 9/27/2016 7:22 AM, Wang Weijun wrote:
> Looking at the webrev, it looks we've never tested on "Linux-arm-32" and "Linux-aarch64-64" before and we only realized it now. This is a true problem.
>
> On the other hand, I also agree with Xuelei's concern. If a new platform is added and it does not have NSS libs tests will fail.
>
> How about this? If there is such a new platform called "mhos-arch-32", we can add
>
>     osMap("mhos-arch-32", new String[]{});
>
> and, make nssLibDirs == null a failure, but nssLibDirs.length == 0 can return null.
>
> Is this good?
>
> Thanks
> Max
>
>
>> On Sep 27, 2016, at 7:25 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> I think, it is the expected behavior to ignore the test if a platform does not support it.  If showing failures, every testing on unsupported platform will fail, and additional effort MUST be paid to evaluate the root cause of the failure.  We should try to avoid that.
>>
>> Xuelei
>>
>> On 9/27/2016 6:32 PM, Tim Du wrote:
>>> Hi All:
>>>
>>> Would you help to review the patch for sun/security/pkcs11/PKCS11Test.java?
>>> The test keep pass on not supported platforms, it will make nobody
>>> notice the test was skipped,which is not our expected. Update case to
>>> show failure, when platform not supported. And add the support for
>>> Linux-arm-32 and Linux-arm-64 platforms. Thanks.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8164322
>>> Webrev: http://cr.openjdk.java.net/~tidu/8164322/webrev.00/
>>>
>>>
>>> Regards
>>> Tim


From xuelei.fan at oracle.com  Tue Sep 27 23:59:36 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 28 Sep 2016 07:59:36 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <fe47510a-ccb8-4ff8-a0d8-aa8bd82c7b1f@oracle.com>
References: <f57a4feb-0327-5fbe-9c70-8f6977ccc5cd@oracle.com>
	<b2c72b51-1576-6672-8a1d-41499a72796a@oracle.com>
	<23AC42BC-3156-4552-A0E0-7EB87CAEFC7E@oracle.com>
	<fe47510a-ccb8-4ff8-a0d8-aa8bd82c7b1f@oracle.com>
Message-ID: <aaf052ad-4d3d-4ad3-0d70-b48a7903a3a9@oracle.com>

On 9/28/2016 2:02 AM, Artem Smotrakov wrote:
> Currently the tests silently quit which looks like they pass. This makes
> people think that everything went smoothly, but actually nothing was
> tested.
>
I did not get the idea.  Looks like, if no NSS installed, the test would 
be ignored; if NSS get installed, the test is actually get run.  If no 
NSS get installed,  the test should quite silently and test nothing 
because nothing should be tested.  That's the expected common behavior 
in order to test specific configuration.

If you don't want the test quit silently, I may prefer to check the 
platform to install NSS libs rather than update this test cases. 
Exposing the testing environment configuration problem is not the job of 
this test.

> I would prefer to update PKCS11Test to report a failure in case of
> unexpected platform.
Then you need to know all expected platform.  The test is not only run 
in a certain known environment (for example the platforms Mach5 or 
JPRT), it can also be run by third party environment (OpenJDK 
contributors).  If not possible, I think it is a hard job to know all 
the expected platform exactly.

Xuelei

From weijun.wang at oracle.com  Wed Sep 28 00:04:42 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 28 Sep 2016 08:04:42 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <aaf052ad-4d3d-4ad3-0d70-b48a7903a3a9@oracle.com>
References: <f57a4feb-0327-5fbe-9c70-8f6977ccc5cd@oracle.com>
	<b2c72b51-1576-6672-8a1d-41499a72796a@oracle.com>
	<23AC42BC-3156-4552-A0E0-7EB87CAEFC7E@oracle.com>
	<fe47510a-ccb8-4ff8-a0d8-aa8bd82c7b1f@oracle.com>
	<aaf052ad-4d3d-4ad3-0d70-b48a7903a3a9@oracle.com>
Message-ID: <E10BE336-729F-4EB6-BFBA-6F9A86F7AA34@oracle.com>


> On Sep 28, 2016, at 7:59 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
>> Currently the tests silently quit which looks like they pass. This makes
>> people think that everything went smoothly, but actually nothing was
>> tested.
>> 
> I did not get the idea.

I think what Artem meant is that without the platform name in osMap, the platform is not tested at all. If the platform has NSS libs, we won't be able to know whether it works.

--Max




From artem.smotrakov at oracle.com  Wed Sep 28 00:22:57 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 27 Sep 2016 17:22:57 -0700
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <E10BE336-729F-4EB6-BFBA-6F9A86F7AA34@oracle.com>
References: <f57a4feb-0327-5fbe-9c70-8f6977ccc5cd@oracle.com>
	<b2c72b51-1576-6672-8a1d-41499a72796a@oracle.com>
	<23AC42BC-3156-4552-A0E0-7EB87CAEFC7E@oracle.com>
	<fe47510a-ccb8-4ff8-a0d8-aa8bd82c7b1f@oracle.com>
	<aaf052ad-4d3d-4ad3-0d70-b48a7903a3a9@oracle.com>
	<E10BE336-729F-4EB6-BFBA-6F9A86F7AA34@oracle.com>
Message-ID: <043704ec-2101-d581-cf7a-1627a7430ebc@oracle.com>

Right, thank you Max.

Currently PKCS11 tests are seen as passed on unsupported (by the tests) 
platforms, but actually nothing was tested. We'd better know about it.

Artem


On 09/27/2016 05:04 PM, Wang Weijun wrote:
>> On Sep 28, 2016, at 7:59 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>>> Currently the tests silently quit which looks like they pass. This makes
>>> people think that everything went smoothly, but actually nothing was
>>> tested.
>>>
>> I did not get the idea.
> I think what Artem meant is that without the platform name in osMap, the platform is not tested at all. If the platform has NSS libs, we won't be able to know whether it works.
>
> --Max
>
>
>


From xuelei.fan at oracle.com  Wed Sep 28 00:42:16 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 28 Sep 2016 08:42:16 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <043704ec-2101-d581-cf7a-1627a7430ebc@oracle.com>
References: <f57a4feb-0327-5fbe-9c70-8f6977ccc5cd@oracle.com>
	<b2c72b51-1576-6672-8a1d-41499a72796a@oracle.com>
	<23AC42BC-3156-4552-A0E0-7EB87CAEFC7E@oracle.com>
	<fe47510a-ccb8-4ff8-a0d8-aa8bd82c7b1f@oracle.com>
	<aaf052ad-4d3d-4ad3-0d70-b48a7903a3a9@oracle.com>
	<E10BE336-729F-4EB6-BFBA-6F9A86F7AA34@oracle.com>
	<043704ec-2101-d581-cf7a-1627a7430ebc@oracle.com>
Message-ID: <d543b5db-c4f2-352c-f880-069b56b540b1@oracle.com>

I agree with the update for that part to add new items.  But please 
don't throw exception if NSS libs was not found (that's another part of 
the fix).

Xuelei

On 9/28/2016 8:22 AM, Artem Smotrakov wrote:
> Right, thank you Max.
>
> Currently PKCS11 tests are seen as passed on unsupported (by the tests)
> platforms, but actually nothing was tested. We'd better know about it.
>
> Artem
>
>
> On 09/27/2016 05:04 PM, Wang Weijun wrote:
>>> On Sep 28, 2016, at 7:59 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>
>>>> Currently the tests silently quit which looks like they pass. This
>>>> makes
>>>> people think that everything went smoothly, but actually nothing was
>>>> tested.
>>>>
>>> I did not get the idea.
>> I think what Artem meant is that without the platform name in osMap,
>> the platform is not tested at all. If the platform has NSS libs, we
>> won't be able to know whether it works.
>>
>> --Max
>>
>>
>>
>

From xuelei.fan at oracle.com  Wed Sep 28 15:00:30 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 28 Sep 2016 23:00:30 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <bcb9192d-6670-46d9-9b41-5165853281ee@default>
References: <bcb9192d-6670-46d9-9b41-5165853281ee@default>
Message-ID: <e035f56e-fc9d-4380-2289-c7d997d7cade@oracle.com>

On 9/28/2016 9:20 PM, Denis Kononenko wrote:
> There're 60+ tests related to PKCS11. Two years they have been "passed" on 3 unsupported platforms on hosts where usually no NSS libraries were installed. How can we rely on these results?
;-) The words of "unsupported platforms" are very confusing in this mail 
thread.

Let's think more about what if a test failed.  What one will do if a 
test failed?
1. Test fail means source code problems for developers.  One cannot 
submit a change-set if a test failed.  He need to pay additional effort 
and analysis the failure.  It take one developer a lot effort to know 
the root cause.  I would never like this unnecessary cost.
2. In order to get the test pass, he need to install the NSS libs 
although NSS has nothing to do with his changeset.  It may be a very 
very hard step or even impossible (for example licenses issues) step for 
him.

TBH, I did not see much benefits to fail on unsupported platforms.  I 
agree that skip for pass is not a good idea, but fail to warn is worse.

I think the root cause if "unsupported platforms" actually are supported 
platforms, but by accident the NSS libraries are not installed or not 
installed properly.

If one is not interested in NSS, the test get ignored (passed).  If one 
is interested in NSS, he should install the NSS libs and the test get 
checked.

What do you think if fix the testing infrastructure with properly 
installed NSS libs?

 > The problem is the tests report they passed but actually they were
 > skipped. I have no objections against skipping tests but it would
 > be better to give a hint somehow how many tests were skipped and why.
Agreed.  Unfortunately, there are only two options, "pass" or "fail", at 
present.  It would be nice if there is a grey area.  Any idea to make 
summary of skipped tests and reasons?

Xuelei

From artem.smotrakov at oracle.com  Wed Sep 28 20:32:26 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 28 Sep 2016 13:32:26 -0700
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <e035f56e-fc9d-4380-2289-c7d997d7cade@oracle.com>
References: <bcb9192d-6670-46d9-9b41-5165853281ee@default>
	<e035f56e-fc9d-4380-2289-c7d997d7cade@oracle.com>
Message-ID: <2b43c59d-f7ab-5477-249f-7ea8d1d24eac@oracle.com>

Hi Xuelei,

I understand your concerns. But I'd prefer to be aware of situations 
when a test reports that it passed when it actually did nothing.

How about using @requires key? We can try to specify all expected 
platforms. If I understand correctly, jtreg won't run tests if specified 
requirements are not met. In this case, you need to look at the report 
to make sure all tests you are interested in were run.

Artem


On 09/28/2016 08:00 AM, Xuelei Fan wrote:
> On 9/28/2016 9:20 PM, Denis Kononenko wrote:
>> There're 60+ tests related to PKCS11. Two years they have been 
>> "passed" on 3 unsupported platforms on hosts where usually no NSS 
>> libraries were installed. How can we rely on these results?
> ;-) The words of "unsupported platforms" are very confusing in this 
> mail thread.
>
> Let's think more about what if a test failed.  What one will do if a 
> test failed?
> 1. Test fail means source code problems for developers.  One cannot 
> submit a change-set if a test failed.  He need to pay additional 
> effort and analysis the failure.  It take one developer a lot effort 
> to know the root cause.  I would never like this unnecessary cost.
> 2. In order to get the test pass, he need to install the NSS libs 
> although NSS has nothing to do with his changeset.  It may be a very 
> very hard step or even impossible (for example licenses issues) step 
> for him.
>
> TBH, I did not see much benefits to fail on unsupported platforms.  I 
> agree that skip for pass is not a good idea, but fail to warn is worse.
>
> I think the root cause if "unsupported platforms" actually are 
> supported platforms, but by accident the NSS libraries are not 
> installed or not installed properly.
>
> If one is not interested in NSS, the test get ignored (passed). If one 
> is interested in NSS, he should install the NSS libs and the test get 
> checked.
>
> What do you think if fix the testing infrastructure with properly 
> installed NSS libs?
>
> > The problem is the tests report they passed but actually they were
> > skipped. I have no objections against skipping tests but it would
> > be better to give a hint somehow how many tests were skipped and why.
> Agreed.  Unfortunately, there are only two options, "pass" or "fail", 
> at present.  It would be nice if there is a grey area. Any idea to 
> make summary of skipped tests and reasons?
>
> Xuelei


From xuelei.fan at oracle.com  Thu Sep 29 00:52:27 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 29 Sep 2016 08:52:27 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <2b43c59d-f7ab-5477-249f-7ea8d1d24eac@oracle.com>
References: <bcb9192d-6670-46d9-9b41-5165853281ee@default>
	<e035f56e-fc9d-4380-2289-c7d997d7cade@oracle.com>
	<2b43c59d-f7ab-5477-249f-7ea8d1d24eac@oracle.com>
Message-ID: <b729c9d9-26c8-7d8f-1012-d3a241a6cd8e@oracle.com>

Hi Artem,

What do you think fix the testing infrastructure (JPRT/Mach5) with 
proper configuration?  I think it is a easier than update a large bunch 
of test codes.

I understand the concerns of yours, but I don't want add additional 
effort for those who need to run the test on their own environment. 
Some people run the test locally before submit JPRT jobs (or no access 
to JPRT systems for external people).

Update the testing infrastructure may solve both of your concerns and my 
concerns.

I'm not sure the @requires tag would work or not.  It would be great if 
you can find a solution with the tag.

Thanks,
Xuelei

On 9/29/2016 4:32 AM, Artem Smotrakov wrote:
> Hi Xuelei,
>
> I understand your concerns. But I'd prefer to be aware of situations
> when a test reports that it passed when it actually did nothing.
>
> How about using @requires key? We can try to specify all expected
> platforms. If I understand correctly, jtreg won't run tests if specified
> requirements are not met. In this case, you need to look at the report
> to make sure all tests you are interested in were run.
>
> Artem
>
>
> On 09/28/2016 08:00 AM, Xuelei Fan wrote:
>> On 9/28/2016 9:20 PM, Denis Kononenko wrote:
>>> There're 60+ tests related to PKCS11. Two years they have been
>>> "passed" on 3 unsupported platforms on hosts where usually no NSS
>>> libraries were installed. How can we rely on these results?
>> ;-) The words of "unsupported platforms" are very confusing in this
>> mail thread.
>>
>> Let's think more about what if a test failed.  What one will do if a
>> test failed?
>> 1. Test fail means source code problems for developers.  One cannot
>> submit a change-set if a test failed.  He need to pay additional
>> effort and analysis the failure.  It take one developer a lot effort
>> to know the root cause.  I would never like this unnecessary cost.
>> 2. In order to get the test pass, he need to install the NSS libs
>> although NSS has nothing to do with his changeset.  It may be a very
>> very hard step or even impossible (for example licenses issues) step
>> for him.
>>
>> TBH, I did not see much benefits to fail on unsupported platforms.  I
>> agree that skip for pass is not a good idea, but fail to warn is worse.
>>
>> I think the root cause if "unsupported platforms" actually are
>> supported platforms, but by accident the NSS libraries are not
>> installed or not installed properly.
>>
>> If one is not interested in NSS, the test get ignored (passed). If one
>> is interested in NSS, he should install the NSS libs and the test get
>> checked.
>>
>> What do you think if fix the testing infrastructure with properly
>> installed NSS libs?
>>
>> > The problem is the tests report they passed but actually they were
>> > skipped. I have no objections against skipping tests but it would
>> > be better to give a hint somehow how many tests were skipped and why.
>> Agreed.  Unfortunately, there are only two options, "pass" or "fail",
>> at present.  It would be nice if there is a grey area. Any idea to
>> make summary of skipped tests and reasons?
>>
>> Xuelei
>

From artem.smotrakov at oracle.com  Thu Sep 29 01:26:40 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 28 Sep 2016 18:26:40 -0700
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <b729c9d9-26c8-7d8f-1012-d3a241a6cd8e@oracle.com>
References: <bcb9192d-6670-46d9-9b41-5165853281ee@default>
	<e035f56e-fc9d-4380-2289-c7d997d7cade@oracle.com>
	<2b43c59d-f7ab-5477-249f-7ea8d1d24eac@oracle.com>
	<b729c9d9-26c8-7d8f-1012-d3a241a6cd8e@oracle.com>
Message-ID: <5768e015-578b-b93b-a3e2-44a988c57f98@oracle.com>

Hi Xuelei,

This is not a problem with machine configuration. The actual test cases 
are not going to be run (even if there are NSS libs on a test machine) 
until "osMap" contains an entry for specific platform.

Artem


On 09/28/2016 05:52 PM, Xuelei Fan wrote:
> Hi Artem,
>
> What do you think fix the testing infrastructure (JPRT/Mach5) with 
> proper configuration?  I think it is a easier than update a large 
> bunch of test codes.
>
> I understand the concerns of yours, but I don't want add additional 
> effort for those who need to run the test on their own environment. 
> Some people run the test locally before submit JPRT jobs (or no access 
> to JPRT systems for external people).
>
> Update the testing infrastructure may solve both of your concerns and 
> my concerns.
>
> I'm not sure the @requires tag would work or not.  It would be great 
> if you can find a solution with the tag.
>
> Thanks,
> Xuelei
>
> On 9/29/2016 4:32 AM, Artem Smotrakov wrote:
>> Hi Xuelei,
>>
>> I understand your concerns. But I'd prefer to be aware of situations
>> when a test reports that it passed when it actually did nothing.
>>
>> How about using @requires key? We can try to specify all expected
>> platforms. If I understand correctly, jtreg won't run tests if specified
>> requirements are not met. In this case, you need to look at the report
>> to make sure all tests you are interested in were run.
>>
>> Artem
>>
>>
>> On 09/28/2016 08:00 AM, Xuelei Fan wrote:
>>> On 9/28/2016 9:20 PM, Denis Kononenko wrote:
>>>> There're 60+ tests related to PKCS11. Two years they have been
>>>> "passed" on 3 unsupported platforms on hosts where usually no NSS
>>>> libraries were installed. How can we rely on these results?
>>> ;-) The words of "unsupported platforms" are very confusing in this
>>> mail thread.
>>>
>>> Let's think more about what if a test failed.  What one will do if a
>>> test failed?
>>> 1. Test fail means source code problems for developers.  One cannot
>>> submit a change-set if a test failed.  He need to pay additional
>>> effort and analysis the failure.  It take one developer a lot effort
>>> to know the root cause.  I would never like this unnecessary cost.
>>> 2. In order to get the test pass, he need to install the NSS libs
>>> although NSS has nothing to do with his changeset.  It may be a very
>>> very hard step or even impossible (for example licenses issues) step
>>> for him.
>>>
>>> TBH, I did not see much benefits to fail on unsupported platforms.  I
>>> agree that skip for pass is not a good idea, but fail to warn is worse.
>>>
>>> I think the root cause if "unsupported platforms" actually are
>>> supported platforms, but by accident the NSS libraries are not
>>> installed or not installed properly.
>>>
>>> If one is not interested in NSS, the test get ignored (passed). If one
>>> is interested in NSS, he should install the NSS libs and the test get
>>> checked.
>>>
>>> What do you think if fix the testing infrastructure with properly
>>> installed NSS libs?
>>>
>>> > The problem is the tests report they passed but actually they were
>>> > skipped. I have no objections against skipping tests but it would
>>> > be better to give a hint somehow how many tests were skipped and why.
>>> Agreed.  Unfortunately, there are only two options, "pass" or "fail",
>>> at present.  It would be nice if there is a grey area. Any idea to
>>> make summary of skipped tests and reasons?
>>>
>>> Xuelei
>>


From xuelei.fan at oracle.com  Thu Sep 29 05:05:17 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 29 Sep 2016 13:05:17 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <5768e015-578b-b93b-a3e2-44a988c57f98@oracle.com>
References: <bcb9192d-6670-46d9-9b41-5165853281ee@default>
	<e035f56e-fc9d-4380-2289-c7d997d7cade@oracle.com>
	<2b43c59d-f7ab-5477-249f-7ea8d1d24eac@oracle.com>
	<b729c9d9-26c8-7d8f-1012-d3a241a6cd8e@oracle.com>
	<5768e015-578b-b93b-a3e2-44a988c57f98@oracle.com>
Message-ID: <ea153031-c8ba-4b0f-598b-10558fb581ad@oracle.com>

On 9/29/2016 9:26 AM, Artem Smotrakov wrote:
> Hi Xuelei,
>
> This is not a problem with machine configuration. The actual test cases
> are not going to be run (even if there are NSS libs on a test machine)
> until "osMap" contains an entry for specific platform.
>
OK.  Please fix for the purpose accordingly.

Tim, the current fix has two parts.  The 1st part, which throw exception 
is a machine configuration problem, is not in the scope of Artem's 
consideration, please remove it.  The 2nd part, which add new items to 
the osMap, is fine to me.  I think we are on the same page now.  Please 
update the webrev accordingly.  I will approve the 2nd part fix.

Thanks,
Xuelei

> Artem
>
>
> On 09/28/2016 05:52 PM, Xuelei Fan wrote:
>> Hi Artem,
>>
>> What do you think fix the testing infrastructure (JPRT/Mach5) with
>> proper configuration?  I think it is a easier than update a large
>> bunch of test codes.
>>
>> I understand the concerns of yours, but I don't want add additional
>> effort for those who need to run the test on their own environment.
>> Some people run the test locally before submit JPRT jobs (or no access
>> to JPRT systems for external people).
>>
>> Update the testing infrastructure may solve both of your concerns and
>> my concerns.
>>
>> I'm not sure the @requires tag would work or not.  It would be great
>> if you can find a solution with the tag.
>>
>> Thanks,
>> Xuelei
>>
>> On 9/29/2016 4:32 AM, Artem Smotrakov wrote:
>>> Hi Xuelei,
>>>
>>> I understand your concerns. But I'd prefer to be aware of situations
>>> when a test reports that it passed when it actually did nothing.
>>>
>>> How about using @requires key? We can try to specify all expected
>>> platforms. If I understand correctly, jtreg won't run tests if specified
>>> requirements are not met. In this case, you need to look at the report
>>> to make sure all tests you are interested in were run.
>>>
>>> Artem
>>>
>>>
>>> On 09/28/2016 08:00 AM, Xuelei Fan wrote:
>>>> On 9/28/2016 9:20 PM, Denis Kononenko wrote:
>>>>> There're 60+ tests related to PKCS11. Two years they have been
>>>>> "passed" on 3 unsupported platforms on hosts where usually no NSS
>>>>> libraries were installed. How can we rely on these results?
>>>> ;-) The words of "unsupported platforms" are very confusing in this
>>>> mail thread.
>>>>
>>>> Let's think more about what if a test failed.  What one will do if a
>>>> test failed?
>>>> 1. Test fail means source code problems for developers.  One cannot
>>>> submit a change-set if a test failed.  He need to pay additional
>>>> effort and analysis the failure.  It take one developer a lot effort
>>>> to know the root cause.  I would never like this unnecessary cost.
>>>> 2. In order to get the test pass, he need to install the NSS libs
>>>> although NSS has nothing to do with his changeset.  It may be a very
>>>> very hard step or even impossible (for example licenses issues) step
>>>> for him.
>>>>
>>>> TBH, I did not see much benefits to fail on unsupported platforms.  I
>>>> agree that skip for pass is not a good idea, but fail to warn is worse.
>>>>
>>>> I think the root cause if "unsupported platforms" actually are
>>>> supported platforms, but by accident the NSS libraries are not
>>>> installed or not installed properly.
>>>>
>>>> If one is not interested in NSS, the test get ignored (passed). If one
>>>> is interested in NSS, he should install the NSS libs and the test get
>>>> checked.
>>>>
>>>> What do you think if fix the testing infrastructure with properly
>>>> installed NSS libs?
>>>>
>>>> > The problem is the tests report they passed but actually they were
>>>> > skipped. I have no objections against skipping tests but it would
>>>> > be better to give a hint somehow how many tests were skipped and why.
>>>> Agreed.  Unfortunately, there are only two options, "pass" or "fail",
>>>> at present.  It would be nice if there is a grey area. Any idea to
>>>> make summary of skipped tests and reasons?
>>>>
>>>> Xuelei
>>>
>

From tiantian.du at oracle.com  Thu Sep 29 09:36:58 2016
From: tiantian.du at oracle.com (Tim Du)
Date: Thu, 29 Sep 2016 17:36:58 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <ea153031-c8ba-4b0f-598b-10558fb581ad@oracle.com>
References: <bcb9192d-6670-46d9-9b41-5165853281ee@default>
	<e035f56e-fc9d-4380-2289-c7d997d7cade@oracle.com>
	<2b43c59d-f7ab-5477-249f-7ea8d1d24eac@oracle.com>
	<b729c9d9-26c8-7d8f-1012-d3a241a6cd8e@oracle.com>
	<5768e015-578b-b93b-a3e2-44a988c57f98@oracle.com>
	<ea153031-c8ba-4b0f-598b-10558fb581ad@oracle.com>
Message-ID: <e4aacb3d-784b-ad34-3c1b-2e3649e2fee2@oracle.com>

Thank you for reviewing the codes.
Remove the codes which throw exception and add codes could show machine 
not installed NSS library information.
The latest code is here: 
http://cr.openjdk.java.net/~tidu/8164322/webrev.01/ ,please help to 
review it.

For whether throw exception caused by OS/machine issue ,I file an 
Enhancement https://bugs.openjdk.java.net/browse/JDK-8166893 , we can 
keep discussing by it ,and then the test 
sun/security/pkcs11/PKCS11Test.java could be supported to run on ARM 
platform firstly. Thanks

Regards
Tim
On 2016/9/29 13:05, Xuelei Fan wrote:
> On 9/29/2016 9:26 AM, Artem Smotrakov wrote:
>> Hi Xuelei,
>>
>> This is not a problem with machine configuration. The actual test cases
>> are not going to be run (even if there are NSS libs on a test machine)
>> until "osMap" contains an entry for specific platform.
>>
> OK.  Please fix for the purpose accordingly.
>
> Tim, the current fix has two parts.  The 1st part, which throw 
> exception is a machine configuration problem, is not in the scope of 
> Artem's consideration, please remove it.  The 2nd part, which add new 
> items to the osMap, is fine to me.  I think we are on the same page 
> now.  Please update the webrev accordingly.  I will approve the 2nd 
> part fix.
>
> Thanks,
> Xuelei
>
>> Artem
>>
>>
>> On 09/28/2016 05:52 PM, Xuelei Fan wrote:
>>> Hi Artem,
>>>
>>> What do you think fix the testing infrastructure (JPRT/Mach5) with
>>> proper configuration?  I think it is a easier than update a large
>>> bunch of test codes.
>>>
>>> I understand the concerns of yours, but I don't want add additional
>>> effort for those who need to run the test on their own environment.
>>> Some people run the test locally before submit JPRT jobs (or no access
>>> to JPRT systems for external people).
>>>
>>> Update the testing infrastructure may solve both of your concerns and
>>> my concerns.
>>>
>>> I'm not sure the @requires tag would work or not.  It would be great
>>> if you can find a solution with the tag.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 9/29/2016 4:32 AM, Artem Smotrakov wrote:
>>>> Hi Xuelei,
>>>>
>>>> I understand your concerns. But I'd prefer to be aware of situations
>>>> when a test reports that it passed when it actually did nothing.
>>>>
>>>> How about using @requires key? We can try to specify all expected
>>>> platforms. If I understand correctly, jtreg won't run tests if 
>>>> specified
>>>> requirements are not met. In this case, you need to look at the report
>>>> to make sure all tests you are interested in were run.
>>>>
>>>> Artem
>>>>
>>>>
>>>> On 09/28/2016 08:00 AM, Xuelei Fan wrote:
>>>>> On 9/28/2016 9:20 PM, Denis Kononenko wrote:
>>>>>> There're 60+ tests related to PKCS11. Two years they have been
>>>>>> "passed" on 3 unsupported platforms on hosts where usually no NSS
>>>>>> libraries were installed. How can we rely on these results?
>>>>> ;-) The words of "unsupported platforms" are very confusing in this
>>>>> mail thread.
>>>>>
>>>>> Let's think more about what if a test failed.  What one will do if a
>>>>> test failed?
>>>>> 1. Test fail means source code problems for developers. One cannot
>>>>> submit a change-set if a test failed.  He need to pay additional
>>>>> effort and analysis the failure.  It take one developer a lot effort
>>>>> to know the root cause.  I would never like this unnecessary cost.
>>>>> 2. In order to get the test pass, he need to install the NSS libs
>>>>> although NSS has nothing to do with his changeset.  It may be a very
>>>>> very hard step or even impossible (for example licenses issues) step
>>>>> for him.
>>>>>
>>>>> TBH, I did not see much benefits to fail on unsupported platforms.  I
>>>>> agree that skip for pass is not a good idea, but fail to warn is 
>>>>> worse.
>>>>>
>>>>> I think the root cause if "unsupported platforms" actually are
>>>>> supported platforms, but by accident the NSS libraries are not
>>>>> installed or not installed properly.
>>>>>
>>>>> If one is not interested in NSS, the test get ignored (passed). If 
>>>>> one
>>>>> is interested in NSS, he should install the NSS libs and the test get
>>>>> checked.
>>>>>
>>>>> What do you think if fix the testing infrastructure with properly
>>>>> installed NSS libs?
>>>>>
>>>>> > The problem is the tests report they passed but actually they were
>>>>> > skipped. I have no objections against skipping tests but it would
>>>>> > be better to give a hint somehow how many tests were skipped and 
>>>>> why.
>>>>> Agreed.  Unfortunately, there are only two options, "pass" or "fail",
>>>>> at present.  It would be nice if there is a grey area. Any idea to
>>>>> make summary of skipped tests and reasons?
>>>>>
>>>>> Xuelei
>>>>
>>


From xuelei.fan at oracle.com  Thu Sep 29 10:16:36 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 29 Sep 2016 18:16:36 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <e4aacb3d-784b-ad34-3c1b-2e3649e2fee2@oracle.com>
References: <bcb9192d-6670-46d9-9b41-5165853281ee@default>
	<e035f56e-fc9d-4380-2289-c7d997d7cade@oracle.com>
	<2b43c59d-f7ab-5477-249f-7ea8d1d24eac@oracle.com>
	<b729c9d9-26c8-7d8f-1012-d3a241a6cd8e@oracle.com>
	<5768e015-578b-b93b-a3e2-44a988c57f98@oracle.com>
	<ea153031-c8ba-4b0f-598b-10558fb581ad@oracle.com>
	<e4aacb3d-784b-ad34-3c1b-2e3649e2fee2@oracle.com>
Message-ID: <556bc547-9b2a-2d12-7298-78389994f9bd@oracle.com>

On 9/29/2016 5:36 PM, Tim Du wrote:
> Thank you for reviewing the codes.
> Remove the codes which throw exception and add codes could show machine
> not installed NSS library information.
> The latest code is here:
> http://cr.openjdk.java.net/~tidu/8164322/webrev.01/ ,please help to
> review it.
>
Looks fine to me.  A very minor comment:
  303   + ",please initialize ...

Please add a white space between ",' and 'please".

Thanks,
Xuelei

> For whether throw exception caused by OS/machine issue ,I file an
> Enhancement https://bugs.openjdk.java.net/browse/JDK-8166893 , we can
> keep discussing by it ,and then the test
> sun/security/pkcs11/PKCS11Test.java could be supported to run on ARM
> platform firstly. Thanks
>
> Regards
> Tim
> On 2016/9/29 13:05, Xuelei Fan wrote:
>> On 9/29/2016 9:26 AM, Artem Smotrakov wrote:
>>> Hi Xuelei,
>>>
>>> This is not a problem with machine configuration. The actual test cases
>>> are not going to be run (even if there are NSS libs on a test machine)
>>> until "osMap" contains an entry for specific platform.
>>>
>> OK.  Please fix for the purpose accordingly.
>>
>> Tim, the current fix has two parts.  The 1st part, which throw
>> exception is a machine configuration problem, is not in the scope of
>> Artem's consideration, please remove it.  The 2nd part, which add new
>> items to the osMap, is fine to me.  I think we are on the same page
>> now.  Please update the webrev accordingly.  I will approve the 2nd
>> part fix.
>>
>> Thanks,
>> Xuelei
>>
>>> Artem
>>>
>>>
>>> On 09/28/2016 05:52 PM, Xuelei Fan wrote:
>>>> Hi Artem,
>>>>
>>>> What do you think fix the testing infrastructure (JPRT/Mach5) with
>>>> proper configuration?  I think it is a easier than update a large
>>>> bunch of test codes.
>>>>
>>>> I understand the concerns of yours, but I don't want add additional
>>>> effort for those who need to run the test on their own environment.
>>>> Some people run the test locally before submit JPRT jobs (or no access
>>>> to JPRT systems for external people).
>>>>
>>>> Update the testing infrastructure may solve both of your concerns and
>>>> my concerns.
>>>>
>>>> I'm not sure the @requires tag would work or not.  It would be great
>>>> if you can find a solution with the tag.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 9/29/2016 4:32 AM, Artem Smotrakov wrote:
>>>>> Hi Xuelei,
>>>>>
>>>>> I understand your concerns. But I'd prefer to be aware of situations
>>>>> when a test reports that it passed when it actually did nothing.
>>>>>
>>>>> How about using @requires key? We can try to specify all expected
>>>>> platforms. If I understand correctly, jtreg won't run tests if
>>>>> specified
>>>>> requirements are not met. In this case, you need to look at the report
>>>>> to make sure all tests you are interested in were run.
>>>>>
>>>>> Artem
>>>>>
>>>>>
>>>>> On 09/28/2016 08:00 AM, Xuelei Fan wrote:
>>>>>> On 9/28/2016 9:20 PM, Denis Kononenko wrote:
>>>>>>> There're 60+ tests related to PKCS11. Two years they have been
>>>>>>> "passed" on 3 unsupported platforms on hosts where usually no NSS
>>>>>>> libraries were installed. How can we rely on these results?
>>>>>> ;-) The words of "unsupported platforms" are very confusing in this
>>>>>> mail thread.
>>>>>>
>>>>>> Let's think more about what if a test failed.  What one will do if a
>>>>>> test failed?
>>>>>> 1. Test fail means source code problems for developers. One cannot
>>>>>> submit a change-set if a test failed.  He need to pay additional
>>>>>> effort and analysis the failure.  It take one developer a lot effort
>>>>>> to know the root cause.  I would never like this unnecessary cost.
>>>>>> 2. In order to get the test pass, he need to install the NSS libs
>>>>>> although NSS has nothing to do with his changeset.  It may be a very
>>>>>> very hard step or even impossible (for example licenses issues) step
>>>>>> for him.
>>>>>>
>>>>>> TBH, I did not see much benefits to fail on unsupported platforms.  I
>>>>>> agree that skip for pass is not a good idea, but fail to warn is
>>>>>> worse.
>>>>>>
>>>>>> I think the root cause if "unsupported platforms" actually are
>>>>>> supported platforms, but by accident the NSS libraries are not
>>>>>> installed or not installed properly.
>>>>>>
>>>>>> If one is not interested in NSS, the test get ignored (passed). If
>>>>>> one
>>>>>> is interested in NSS, he should install the NSS libs and the test get
>>>>>> checked.
>>>>>>
>>>>>> What do you think if fix the testing infrastructure with properly
>>>>>> installed NSS libs?
>>>>>>
>>>>>> > The problem is the tests report they passed but actually they were
>>>>>> > skipped. I have no objections against skipping tests but it would
>>>>>> > be better to give a hint somehow how many tests were skipped and
>>>>>> why.
>>>>>> Agreed.  Unfortunately, there are only two options, "pass" or "fail",
>>>>>> at present.  It would be nice if there is a grey area. Any idea to
>>>>>> make summary of skipped tests and reasons?
>>>>>>
>>>>>> Xuelei
>>>>>
>>>
>

From aph at redhat.com  Thu Sep 29 15:28:49 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 29 Sep 2016 16:28:49 +0100
Subject: [Semi-]off-line encryption
Message-ID: <ad4a1185-8073-46df-ea70-fe60d85bf773@redhat.com>


GCM allows most of the work in an encryption to be done offline (and
ahead of time) by other processors, reducing latency and increasing
throughput.  It'd be lovely if we could do this in Java, but I can't
really see a way to fit this in to the platform security framework.
We don't want to do this eagerly, because we don't know that more data
will be encrypted and we don't want to speculate.

However, if we had a hint that (say) a large stream would need to
encrypt a megabyte of data at some time in the future we could
precompute a megabyte of keystream.  Has anyone considered this?

Andrew.

From mstjohns at comcast.net  Thu Sep 29 16:49:48 2016
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 29 Sep 2016 12:49:48 -0400
Subject: [Semi-]off-line encryption
In-Reply-To: <ad4a1185-8073-46df-ea70-fe60d85bf773@redhat.com>
References: <ad4a1185-8073-46df-ea70-fe60d85bf773@redhat.com>
Message-ID: <b1222dc5-57b2-5a1d-43bf-bf0828e45dba@comcast.net>

On 9/29/2016 11:28 AM, Andrew Haley wrote:
> GCM allows most of the work in an encryption to be done offline (and
> ahead of time) by other processors, reducing latency and increasing
> throughput.  It'd be lovely if we could do this in Java, but I can't
> really see a way to fit this in to the platform security framework.
> We don't want to do this eagerly, because we don't know that more data
> will be encrypted and we don't want to speculate.
>
> However, if we had a hint that (say) a large stream would need to
> encrypt a megabyte of data at some time in the future we could
> precompute a megabyte of keystream.  Has anyone considered this?
>
> Andrew.


Um.  No.   You can make this work with CTR, but you can't with GCM.  
With CTR, you just encrypt a stream of zeroes to get an encryption 
stream and then XOR the encryption stream later with your actual plain 
text.  GCM (and CCM) tend to compute the integrity tag in parallel with 
calculating the encryption stream. You'd have to still process all of 
the plain text (or cipher text) to get the integrity tag.

Mike



From aph at redhat.com  Thu Sep 29 17:25:23 2016
From: aph at redhat.com (Andrew Haley)
Date: Thu, 29 Sep 2016 18:25:23 +0100
Subject: [Semi-]off-line encryption
In-Reply-To: <b1222dc5-57b2-5a1d-43bf-bf0828e45dba@comcast.net>
References: <ad4a1185-8073-46df-ea70-fe60d85bf773@redhat.com>
	<b1222dc5-57b2-5a1d-43bf-bf0828e45dba@comcast.net>
Message-ID: <cc475ddf-84d0-f6be-156a-0eb9294d93e4@redhat.com>

On 29/09/16 17:49, Michael StJohns wrote:
> On 9/29/2016 11:28 AM, Andrew Haley wrote:
>> GCM allows most of the work in an encryption to be done offline (and
>> ahead of time) by other processors, reducing latency and increasing
>> throughput.  It'd be lovely if we could do this in Java, but I can't
>> really see a way to fit this in to the platform security framework.
>> We don't want to do this eagerly, because we don't know that more data
>> will be encrypted and we don't want to speculate.
>>
>> However, if we had a hint that (say) a large stream would need to
>> encrypt a megabyte of data at some time in the future we could
>> precompute a megabyte of keystream.  Has anyone considered this?
> 
> Um.  No.   You can make this work with CTR, but you can't with GCM.  
> With CTR, you just encrypt a stream of zeroes to get an encryption 
> stream and then XOR the encryption stream later with your actual plain 
> text.  GCM (and CCM) tend to compute the integrity tag in parallel with 
> calculating the encryption stream. You'd have to still process all of 
> the plain text (or cipher text) to get the integrity tag.

The keystream doesn't depend on the plaintext or the ciphertext.  Of
course the auth tag can't be calculated before we have the ciphertext
but the keystream can be, and the keystream is the expensive part of
the calculation.  The auth tag doesn't require anything more than a
Galois field multiplication, and that's really fast with current
hardware.  We could arrange it so that there is always some keystream
precalculated, and then the encryption latency would be no more than a
couple of XORs and a GF multiplication.

Maybe there's no point if AES-NI can generate the keystream at 20ish
cycles per block and the GF multiplication can be done in parallel,
but not every target has AES-NI or some equivalent.  And I'm not sure
that every target which does have appropriate instructions can issue
the AES and the GF multiplication instructions at the same time.

Having said all of that, it may be that the overheads of inter-
processor communication would make this inefficient.

Andrew.

From tiantian.du at oracle.com  Fri Sep 30 08:39:08 2016
From: tiantian.du at oracle.com (Tim Du)
Date: Fri, 30 Sep 2016 16:39:08 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <556bc547-9b2a-2d12-7298-78389994f9bd@oracle.com>
References: <bcb9192d-6670-46d9-9b41-5165853281ee@default>
	<e035f56e-fc9d-4380-2289-c7d997d7cade@oracle.com>
	<2b43c59d-f7ab-5477-249f-7ea8d1d24eac@oracle.com>
	<b729c9d9-26c8-7d8f-1012-d3a241a6cd8e@oracle.com>
	<5768e015-578b-b93b-a3e2-44a988c57f98@oracle.com>
	<ea153031-c8ba-4b0f-598b-10558fb581ad@oracle.com>
	<e4aacb3d-784b-ad34-3c1b-2e3649e2fee2@oracle.com>
	<556bc547-9b2a-2d12-7298-78389994f9bd@oracle.com>
Message-ID: <82a5a46b-5d5c-f031-1c49-2f5cdb5cd113@oracle.com>

Thanks Xuelei review it.
Latest webrev available here 
:http://cr.openjdk.java.net/~tidu/8164322/webrev.02/ ,Please help to 
review it. Thanks

Regards
Tim
On 2016/9/29 18:16, Xuelei Fan wrote:
> On 9/29/2016 5:36 PM, Tim Du wrote:
>> Thank you for reviewing the codes.
>> Remove the codes which throw exception and add codes could show machine
>> not installed NSS library information.
>> The latest code is here:
>> http://cr.openjdk.java.net/~tidu/8164322/webrev.01/ ,please help to
>> review it.
>>
> Looks fine to me.  A very minor comment:
>  303   + ",please initialize ...
>
> Please add a white space between ",' and 'please".
>
> Thanks,
> Xuelei
>
>> For whether throw exception caused by OS/machine issue ,I file an
>> Enhancement https://bugs.openjdk.java.net/browse/JDK-8166893 , we can
>> keep discussing by it ,and then the test
>> sun/security/pkcs11/PKCS11Test.java could be supported to run on ARM
>> platform firstly. Thanks
>>
>> Regards
>> Tim
>> On 2016/9/29 13:05, Xuelei Fan wrote:
>>> On 9/29/2016 9:26 AM, Artem Smotrakov wrote:
>>>> Hi Xuelei,
>>>>
>>>> This is not a problem with machine configuration. The actual test 
>>>> cases
>>>> are not going to be run (even if there are NSS libs on a test machine)
>>>> until "osMap" contains an entry for specific platform.
>>>>
>>> OK.  Please fix for the purpose accordingly.
>>>
>>> Tim, the current fix has two parts.  The 1st part, which throw
>>> exception is a machine configuration problem, is not in the scope of
>>> Artem's consideration, please remove it.  The 2nd part, which add new
>>> items to the osMap, is fine to me.  I think we are on the same page
>>> now.  Please update the webrev accordingly.  I will approve the 2nd
>>> part fix.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>> Artem
>>>>
>>>>
>>>> On 09/28/2016 05:52 PM, Xuelei Fan wrote:
>>>>> Hi Artem,
>>>>>
>>>>> What do you think fix the testing infrastructure (JPRT/Mach5) with
>>>>> proper configuration?  I think it is a easier than update a large
>>>>> bunch of test codes.
>>>>>
>>>>> I understand the concerns of yours, but I don't want add additional
>>>>> effort for those who need to run the test on their own environment.
>>>>> Some people run the test locally before submit JPRT jobs (or no 
>>>>> access
>>>>> to JPRT systems for external people).
>>>>>
>>>>> Update the testing infrastructure may solve both of your concerns and
>>>>> my concerns.
>>>>>
>>>>> I'm not sure the @requires tag would work or not.  It would be great
>>>>> if you can find a solution with the tag.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>> On 9/29/2016 4:32 AM, Artem Smotrakov wrote:
>>>>>> Hi Xuelei,
>>>>>>
>>>>>> I understand your concerns. But I'd prefer to be aware of situations
>>>>>> when a test reports that it passed when it actually did nothing.
>>>>>>
>>>>>> How about using @requires key? We can try to specify all expected
>>>>>> platforms. If I understand correctly, jtreg won't run tests if
>>>>>> specified
>>>>>> requirements are not met. In this case, you need to look at the 
>>>>>> report
>>>>>> to make sure all tests you are interested in were run.
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>>
>>>>>> On 09/28/2016 08:00 AM, Xuelei Fan wrote:
>>>>>>> On 9/28/2016 9:20 PM, Denis Kononenko wrote:
>>>>>>>> There're 60+ tests related to PKCS11. Two years they have been
>>>>>>>> "passed" on 3 unsupported platforms on hosts where usually no NSS
>>>>>>>> libraries were installed. How can we rely on these results?
>>>>>>> ;-) The words of "unsupported platforms" are very confusing in this
>>>>>>> mail thread.
>>>>>>>
>>>>>>> Let's think more about what if a test failed.  What one will do 
>>>>>>> if a
>>>>>>> test failed?
>>>>>>> 1. Test fail means source code problems for developers. One cannot
>>>>>>> submit a change-set if a test failed.  He need to pay additional
>>>>>>> effort and analysis the failure.  It take one developer a lot 
>>>>>>> effort
>>>>>>> to know the root cause.  I would never like this unnecessary cost.
>>>>>>> 2. In order to get the test pass, he need to install the NSS libs
>>>>>>> although NSS has nothing to do with his changeset.  It may be a 
>>>>>>> very
>>>>>>> very hard step or even impossible (for example licenses issues) 
>>>>>>> step
>>>>>>> for him.
>>>>>>>
>>>>>>> TBH, I did not see much benefits to fail on unsupported 
>>>>>>> platforms.  I
>>>>>>> agree that skip for pass is not a good idea, but fail to warn is
>>>>>>> worse.
>>>>>>>
>>>>>>> I think the root cause if "unsupported platforms" actually are
>>>>>>> supported platforms, but by accident the NSS libraries are not
>>>>>>> installed or not installed properly.
>>>>>>>
>>>>>>> If one is not interested in NSS, the test get ignored (passed). If
>>>>>>> one
>>>>>>> is interested in NSS, he should install the NSS libs and the 
>>>>>>> test get
>>>>>>> checked.
>>>>>>>
>>>>>>> What do you think if fix the testing infrastructure with properly
>>>>>>> installed NSS libs?
>>>>>>>
>>>>>>> > The problem is the tests report they passed but actually they 
>>>>>>> were
>>>>>>> > skipped. I have no objections against skipping tests but it would
>>>>>>> > be better to give a hint somehow how many tests were skipped and
>>>>>>> why.
>>>>>>> Agreed.  Unfortunately, there are only two options, "pass" or 
>>>>>>> "fail",
>>>>>>> at present.  It would be nice if there is a grey area. Any idea to
>>>>>>> make summary of skipped tests and reasons?
>>>>>>>
>>>>>>> Xuelei
>>>>>>
>>>>
>>


From xuelei.fan at oracle.com  Fri Sep 30 08:47:35 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 30 Sep 2016 16:47:35 +0800
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
In-Reply-To: <82a5a46b-5d5c-f031-1c49-2f5cdb5cd113@oracle.com>
References: <bcb9192d-6670-46d9-9b41-5165853281ee@default>
	<e035f56e-fc9d-4380-2289-c7d997d7cade@oracle.com>
	<2b43c59d-f7ab-5477-249f-7ea8d1d24eac@oracle.com>
	<b729c9d9-26c8-7d8f-1012-d3a241a6cd8e@oracle.com>
	<5768e015-578b-b93b-a3e2-44a988c57f98@oracle.com>
	<ea153031-c8ba-4b0f-598b-10558fb581ad@oracle.com>
	<e4aacb3d-784b-ad34-3c1b-2e3649e2fee2@oracle.com>
	<556bc547-9b2a-2d12-7298-78389994f9bd@oracle.com>
	<82a5a46b-5d5c-f031-1c49-2f5cdb5cd113@oracle.com>
Message-ID: <e0bc16b7-fd3a-4f5c-49ef-3129cc61eb25@oracle.com>

Looks fine to me.

Xuelei

On 9/30/2016 4:39 PM, Tim Du wrote:
> Thanks Xuelei review it.
> Latest webrev available here
> :http://cr.openjdk.java.net/~tidu/8164322/webrev.02/ ,Please help to
> review it. Thanks
>
> Regards
> Tim
> On 2016/9/29 18:16, Xuelei Fan wrote:
>> On 9/29/2016 5:36 PM, Tim Du wrote:
>>> Thank you for reviewing the codes.
>>> Remove the codes which throw exception and add codes could show machine
>>> not installed NSS library information.
>>> The latest code is here:
>>> http://cr.openjdk.java.net/~tidu/8164322/webrev.01/ ,please help to
>>> review it.
>>>
>> Looks fine to me.  A very minor comment:
>>  303   + ",please initialize ...
>>
>> Please add a white space between ",' and 'please".
>>
>> Thanks,
>> Xuelei
>>
>>> For whether throw exception caused by OS/machine issue ,I file an
>>> Enhancement https://bugs.openjdk.java.net/browse/JDK-8166893 , we can
>>> keep discussing by it ,and then the test
>>> sun/security/pkcs11/PKCS11Test.java could be supported to run on ARM
>>> platform firstly. Thanks
>>>
>>> Regards
>>> Tim
>>> On 2016/9/29 13:05, Xuelei Fan wrote:
>>>> On 9/29/2016 9:26 AM, Artem Smotrakov wrote:
>>>>> Hi Xuelei,
>>>>>
>>>>> This is not a problem with machine configuration. The actual test
>>>>> cases
>>>>> are not going to be run (even if there are NSS libs on a test machine)
>>>>> until "osMap" contains an entry for specific platform.
>>>>>
>>>> OK.  Please fix for the purpose accordingly.
>>>>
>>>> Tim, the current fix has two parts.  The 1st part, which throw
>>>> exception is a machine configuration problem, is not in the scope of
>>>> Artem's consideration, please remove it.  The 2nd part, which add new
>>>> items to the osMap, is fine to me.  I think we are on the same page
>>>> now.  Please update the webrev accordingly.  I will approve the 2nd
>>>> part fix.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>>> Artem
>>>>>
>>>>>
>>>>> On 09/28/2016 05:52 PM, Xuelei Fan wrote:
>>>>>> Hi Artem,
>>>>>>
>>>>>> What do you think fix the testing infrastructure (JPRT/Mach5) with
>>>>>> proper configuration?  I think it is a easier than update a large
>>>>>> bunch of test codes.
>>>>>>
>>>>>> I understand the concerns of yours, but I don't want add additional
>>>>>> effort for those who need to run the test on their own environment.
>>>>>> Some people run the test locally before submit JPRT jobs (or no
>>>>>> access
>>>>>> to JPRT systems for external people).
>>>>>>
>>>>>> Update the testing infrastructure may solve both of your concerns and
>>>>>> my concerns.
>>>>>>
>>>>>> I'm not sure the @requires tag would work or not.  It would be great
>>>>>> if you can find a solution with the tag.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>> On 9/29/2016 4:32 AM, Artem Smotrakov wrote:
>>>>>>> Hi Xuelei,
>>>>>>>
>>>>>>> I understand your concerns. But I'd prefer to be aware of situations
>>>>>>> when a test reports that it passed when it actually did nothing.
>>>>>>>
>>>>>>> How about using @requires key? We can try to specify all expected
>>>>>>> platforms. If I understand correctly, jtreg won't run tests if
>>>>>>> specified
>>>>>>> requirements are not met. In this case, you need to look at the
>>>>>>> report
>>>>>>> to make sure all tests you are interested in were run.
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>>
>>>>>>> On 09/28/2016 08:00 AM, Xuelei Fan wrote:
>>>>>>>> On 9/28/2016 9:20 PM, Denis Kononenko wrote:
>>>>>>>>> There're 60+ tests related to PKCS11. Two years they have been
>>>>>>>>> "passed" on 3 unsupported platforms on hosts where usually no NSS
>>>>>>>>> libraries were installed. How can we rely on these results?
>>>>>>>> ;-) The words of "unsupported platforms" are very confusing in this
>>>>>>>> mail thread.
>>>>>>>>
>>>>>>>> Let's think more about what if a test failed.  What one will do
>>>>>>>> if a
>>>>>>>> test failed?
>>>>>>>> 1. Test fail means source code problems for developers. One cannot
>>>>>>>> submit a change-set if a test failed.  He need to pay additional
>>>>>>>> effort and analysis the failure.  It take one developer a lot
>>>>>>>> effort
>>>>>>>> to know the root cause.  I would never like this unnecessary cost.
>>>>>>>> 2. In order to get the test pass, he need to install the NSS libs
>>>>>>>> although NSS has nothing to do with his changeset.  It may be a
>>>>>>>> very
>>>>>>>> very hard step or even impossible (for example licenses issues)
>>>>>>>> step
>>>>>>>> for him.
>>>>>>>>
>>>>>>>> TBH, I did not see much benefits to fail on unsupported
>>>>>>>> platforms.  I
>>>>>>>> agree that skip for pass is not a good idea, but fail to warn is
>>>>>>>> worse.
>>>>>>>>
>>>>>>>> I think the root cause if "unsupported platforms" actually are
>>>>>>>> supported platforms, but by accident the NSS libraries are not
>>>>>>>> installed or not installed properly.
>>>>>>>>
>>>>>>>> If one is not interested in NSS, the test get ignored (passed). If
>>>>>>>> one
>>>>>>>> is interested in NSS, he should install the NSS libs and the
>>>>>>>> test get
>>>>>>>> checked.
>>>>>>>>
>>>>>>>> What do you think if fix the testing infrastructure with properly
>>>>>>>> installed NSS libs?
>>>>>>>>
>>>>>>>> > The problem is the tests report they passed but actually they
>>>>>>>> were
>>>>>>>> > skipped. I have no objections against skipping tests but it would
>>>>>>>> > be better to give a hint somehow how many tests were skipped and
>>>>>>>> why.
>>>>>>>> Agreed.  Unfortunately, there are only two options, "pass" or
>>>>>>>> "fail",
>>>>>>>> at present.  It would be nice if there is a grey area. Any idea to
>>>>>>>> make summary of skipped tests and reasons?
>>>>>>>>
>>>>>>>> Xuelei
>>>>>>>
>>>>>
>>>
>

From martinrb at google.com  Fri Sep 30 17:41:08 2016
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 30 Sep 2016 10:41:08 -0700
Subject: RFR 8166976: TestCipherPBECons has wrong @run line
Message-ID: <CA+kOe0_29wXJqvpeDpox6Y0JGAGQDuWxWjwxQ4Md1Kx7rnZv0w@mail.gmail.com>

https://bugs.openjdk.java.net/browse/JDK-8166976
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TestCipherPBECons/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160930/88cdec5c/attachment.html>

From rasbold at google.com  Fri Sep 30 18:01:11 2016
From: rasbold at google.com (Chuck Rasbold)
Date: Fri, 30 Sep 2016 11:01:11 -0700
Subject: RFR 8166976: TestCipherPBECons has wrong @run line
In-Reply-To: <CA+kOe0_29wXJqvpeDpox6Y0JGAGQDuWxWjwxQ4Md1Kx7rnZv0w@mail.gmail.com>
References: <CA+kOe0_29wXJqvpeDpox6Y0JGAGQDuWxWjwxQ4Md1Kx7rnZv0w@mail.gmail.com>
Message-ID: <CALFb4KsAXDJa6fUV1CYvZTO01MuqWZncfKEuuO4jdR4edrZBNg@mail.gmail.com>

Looks good to me.

On Fri, Sep 30, 2016 at 10:41 AM, Martin Buchholz <martinrb at google.com>
wrote:

> https://bugs.openjdk.java.net/browse/JDK-8166976
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TestCipherPBECons/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160930/28a1a3c8/attachment.html>

From denis.kononenko at oracle.com  Wed Sep 28 13:20:04 2016
From: denis.kononenko at oracle.com (Denis Kononenko)
Date: Wed, 28 Sep 2016 06:20:04 -0700 (PDT)
Subject: [9] RFR: JDK-8164322: sun/security/pkcs11/PKCS11Test.java shall
	be updated to run on ARM platforms
Message-ID: <bcb9192d-6670-46d9-9b41-5165853281ee@default>


Hi All,

> On 9/28/2016 2:02 AM, Artem Smotrakov wrote:
> > Currently the tests silently quit which looks like they pass. This
> makes
> > people think that everything went smoothly, but actually nothing
> was
> > tested.
> >
> I did not get the idea.  Looks like, if no NSS installed, the test
> would 
> be ignored; if NSS get installed, the test is actually get run.  If no
> 
> NSS get installed,  the test should quite silently and test nothing 
> because nothing should be tested.  That's the expected common behavior
> 
> in order to test specific configuration.

The problem is the tests report they passed but actually they were skipped. I have no objections against skipping tests but it would be better to give a hint somehow how many tests were skipped and why. 

> 
> If you don't want the test quit silently, I may prefer to check the 
> platform to install NSS libs rather than update this test cases. 
> Exposing the testing environment configuration problem is not the job
> of 
> this test.

There're 60+ tests related to PKCS11. Two years they have been "passed" on 3 unsupported platforms on hosts where usually no NSS libraries were installed. How can we rely on these results?

> 
> > I would prefer to update PKCS11Test to report a failure in case of
> > unexpected platform.
> Then you need to know all expected platform.  The test is not only run
> 
> in a certain known environment (for example the platforms Mach5 or 
> JPRT), it can also be run by third party environment (OpenJDK 
> contributors).  If not possible, I think it is a hard job to know all
> 
> the expected platform exactly.

>From my experience the most common environment issue is a lack of GUI libraries. Fortunately, in such case tests simply fail due to unsatisfied dependencies. If they would pass due to uncertain environment we could end up having completely untested UI functionality with green status.

> 
> Xuelei

Thank you,
Denis.

From bradford.wetmore at oracle.com  Fri Sep 30 18:14:01 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 30 Sep 2016 11:14:01 -0700
Subject: RFR 8166976: TestCipherPBECons has wrong @run line
In-Reply-To: <CA+kOe0_29wXJqvpeDpox6Y0JGAGQDuWxWjwxQ4Md1Kx7rnZv0w@mail.gmail.com>
References: <CA+kOe0_29wXJqvpeDpox6Y0JGAGQDuWxWjwxQ4Md1Kx7rnZv0w@mail.gmail.com>
Message-ID: <931b9db3-6271-b792-8e08-b51b8d9322f8@oracle.com>

Looks fine.  Looks like a copy/paste error.  Good catch.

If you want to be consistent, you could do the same with the others in 
this directory, or just the one.

PBESealedObject.java: * @run main PBESealedObject
PBKDF2Translate.java: * @run main PBKDF2Translate
PBMacBuffer.java: * @run main PBMacBuffer
PBMacDoFinalVsUpdate.java: * @run main PBMacDoFinalVsUpdate
TestCipherKeyWrapperPBEKey.java: * @run main TestCipherKeyWrapperPBEKey
TestCipherPBECons.java: * @run main TestCipherKeyWrapperPBEKey

Brad



On 9/30/2016 10:41 AM, Martin Buchholz wrote:
> https://bugs.openjdk.java.net/browse/JDK-8166976
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TestCipherPBECons/

From martinrb at google.com  Fri Sep 30 19:14:50 2016
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 30 Sep 2016 12:14:50 -0700
Subject: RFR 8166976: TestCipherPBECons has wrong @run line
In-Reply-To: <931b9db3-6271-b792-8e08-b51b8d9322f8@oracle.com>
References: <CA+kOe0_29wXJqvpeDpox6Y0JGAGQDuWxWjwxQ4Md1Kx7rnZv0w@mail.gmail.com>
	<931b9db3-6271-b792-8e08-b51b8d9322f8@oracle.com>
Message-ID: <CA+kOe096U7-ShnF97qWZeu7+jzbB8mmbA5ac1aSBGHSk-czxeg@mail.gmail.com>

On Fri, Sep 30, 2016 at 11:14 AM, Bradford Wetmore <
bradford.wetmore at oracle.com> wrote:

> Looks fine.  Looks like a copy/paste error.  Good catch.
>
> If you want to be consistent, you could do the same with the others in
> this directory, or just the one.
>

It would be a fine project to delete most of the unnecessary @run main
ThisClass in the jdk,
but I'm not going to take that on now.


> PBESealedObject.java: * @run main PBESealedObject
> PBKDF2Translate.java: * @run main PBKDF2Translate
> PBMacBuffer.java: * @run main PBMacBuffer
> PBMacDoFinalVsUpdate.java: * @run main PBMacDoFinalVsUpdate
> TestCipherKeyWrapperPBEKey.java: * @run main TestCipherKeyWrapperPBEKey
> TestCipherPBECons.java: * @run main TestCipherKeyWrapperPBEKey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20160930/1f07741c/attachment.html>