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

> 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

Re: X.509 Certificate Testing...

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

X.509 Certificate Testing...

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

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

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

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

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

Intended behavior of the -providerName option of keytool

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

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

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

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

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

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

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

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

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;