Re: Do your NSS DLLs on Windows have execute permission?

[Wang Weijun]

> On Sep 16, 2016, at 2:30 AM, Bradford Wetmore  
> 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

Re: X.509 Certificate Testing...

[Wang Weijun]

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  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

X.509 Certificate Testing...

[Milton Smith]

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

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

[Artem Smotrakov]

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  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-...@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

Re: Do your NSS DLLs on Windows have execute permission?

[Bradford Wetmore]

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

Intended behavior of the -providerName option of keytool

[Michael Wang]

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

Re: RFR(S): 8165689: Fix module dependencies for sun/security/pkcs11/* tests

[Sergei Kovalev]

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

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

[Daniel Fuchs]

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/

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

[Chris Hegarty]

On 15 Sep 2016, at 02:55, Xuelei Fan  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-...@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
>>> 
>> 
 
>> 

RE: [9] RFR: 8156054: Test Task: Develop new tests for JEP C155: Remove FilePermission Pathname Canonicalization

[Sibabrata Sahoo]

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@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