RFR[15] JDK-8242538: java/security/SecureRandom/ThreadSafe.java failed on windows

Hi, This test failed due to the expected concurrency issue didn't raise. This patch may mitigate this test failure. diff -r 7a61a943ce9d test/jdk/java/security/SecureRandom/ThreadSafe.java --- a/test/jdk/java/security/SecureRandom/ThreadSafe.java    Sat Jul 04 01:06:07 2020 -0700 +++ b/test/jdk/

Re: RFR 8245520: Provide a way to add CA certificate to cacerts during test run

Move this patch to sun/security/util/module_patch Webrev: http://cr.openjdk.java.net/~jjiang/8245520/webrev.01/ Best regards, John Jiang On 2020/6/11 15:55, sha.ji...@oracle.com wrote: Hi Max, Thanks for your info! It looks that patch for java.base:sun.security.util.FilePaths.java is used for

Re: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options

Hi Hai-May, On 2020/6/13 06:34, Hai-May Chao wrote: Hi John, Updated Webrev - https://cr.openjdk.java.net/~hchao/8244148/webrev.03/ Thanks for this updated webrev! I have no more comment. Best regards, John Jiang On Jun 11, 2020, at 1:45 AM, sha.ji...@oracle.com

Re: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options

Hi Hai-May, On 2020/6/8 04:01, Hai-May Chao wrote: Updated webrev - https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ -- src/java.base/share/classes/sun/security/util/FilePaths.java Would it be better to use String.join() or even java.nio.file.Path to build the file path? -- src/java.base

Re: RFR 8245520: Provide a way to add CA certificate to cacerts during test run

Hi Max, Thanks for your info! It looks that patch for java.base:sun.security.util.FilePaths.java is used for specifying an alternative cacerts file. But my requirement is updating the existing cacerts with given CAs. Both of the functions are useful. I'll submit a new webrev after the fix for JD

RFR 8245520: Provide a way to add CA certificate to cacerts during test run

Hi, This patch contains a patched version for class sun.security.util.AnchorCertificates. It allows to add CAs to cacerts at runtime for testing purpose. Webrev: http://cr.openjdk.java.net/~jjiang/8245520/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8245520 Best regards, John Jia

RFR[15] JDK-8246709: sun/security/tools/jarsigner/TsacertOptionTest.java compilation failed after JDK-8244683

Hi, This patch takes TsacertOptionTest.java to use TsaServer directly, and removes some unnecessary constructors in TsaServer. Webrev: http://cr.openjdk.java.net/~jjiang/8246709/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8246709 Best regards, John Jiang

Re: RFR[15] JDK-8244683: A TSA server used by tests

Hi Max Please review this webrev: http://cr.openjdk.java.net/~jjiang/8244683/webrev.05/ - TimestampCheck.java The codes in those private methods in Interceptor are merged into getRespParam(). - TsaParam.java Group the fields as signing internals and TSA fields. - TsaSigner.java parseRequestPara

Re: RFR[15] JDK-8244683: A TSA server used by tests

On 2020/6/3 22:57, Weijun Wang wrote: TsaParam.java: - Please group the fields into different area. Looks like some are fields in TSTInfo, and some are server internals. One usage of this class is carrying all parameters delivered by HTTP request. Do you mean they should be grouped in differ

Re: RFR[15] JDK-8244683: A TSA server used by tests

Hi Max, On 2020/6/3 17:17, Weijun Wang wrote: TimeStampCheck.java: - Can you please inline all those private getXyz() calls in Interceptor into getRespParam()? I would like to see all these customizations in one place. Just add a blank line in between and it will be clean enough for me. OK

Re: RFR[15] JDK-8244683: A TSA server used by tests

After discussed with Max, I just updated the patch, http://cr.openjdk.java.net/~jjiang/8244683/webrev.04/ Interface TsaInterceptor is renamed to RespInterceptor. The methods, which affect TSA response fields, are merged into getRespParam(reqParam). Best regards, John Jiang On 2020/5/13 08:18, s

RFR[15] JDK-8245691: Add EdDSA certificstes to SSLSocketTemplate and CertUtils

Hi, This patch just adds some EdDSA, including Ed25519 and Ed448, certificates to javax/net/ssl/SSLSocketTemplate.java and jdk/test/lib/security/CertUtils.java. Please note these new certificates are not used by default. Issue: https://bugs.openjdk.java.net/browse/JDK-8245691 Webrev: http://cr

Re: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases

Hi Valerie, Thanks for your clarification! Could you please review this updated webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.01/ Best regards, John Jiang On 2020/5/22 06:08, Valerie Peng wrote: On 5/20/2020 7:38 PM, sha.ji...@oracle.com wrote: - line 176, maybe it's better to

Re: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases

Hi Valerie, Thanks for your comments! On 2020/5/21 04:21, Valerie Peng wrote: Hi John, - line 125, typo: "aliaes" should be "aliases" Will fix it. - line 132: if aliases is not null, check its length is certStrs.length Will fix it. - line 152, use the specified type instead of DEFAULT_

RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases

Hi, This patch adds some new createTrustStore() and createKeyStore() methods to test lib class jdk.test.lib.security.KeyStoreUtils. These new methods allow to pass trust/key store aliases in. Issue: https://bugs.openjdk.java.net/browse/JDK-8245134 Webrev: http://cr.openjdk.java.net/~jjiang/8245

RFR[15] JDK-8245005: javax/net/ssl/compatibility/BasicConnectTest.java failed with No enum constant

Hi, Possibly run the manual test javax/net/ssl/compatibility/BasicConnectTest.java with JDK builds supporting TLS_KRB5 cipher suites. However these cipher suites are not in test/jdk/javax/net/ssl/TLSCommon/ChpherSuite.java. When convert a TLS_KRB5 cipher suite name to a ChpherSuite enum, Illega

Re: RFR[15] JDK-8244683: A TSA server used by tests

Hi Max, Thanks for your comments! Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8244683/webrev.02/ The codes are refactored significantly. On 2020/5/11 10:51, Weijun Wang wrote: Can you update the existing TimeStampCheck test to use this class? I know that test can simu

RFR[15] JDK-8244683: A TSA server used by tests

Hi, This patch introduces a TSA server, which can work with jarsigner. This server will be used by the following jar signing tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8244683 Webrev: http://cr.openjdk.java.net/~jjiang/8244683/webrev.00/ Best regards, John Jiang

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security)

Hi, Generally, this patch doesn't take care of the solaris/sunos/ucrypto-related words in test summaries, code comments, configs and READMEs. E.g. test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java test/jdk/sun/security/provider/MessageDigest/TestSHAClone.java test/jdk/sun/security/util/Resou

RFR[15] JDK-8243549: sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java failed with Unsupported signature algorithm: DSA

Hi, DHE_DSS cipher suites cannot work with SHA256withDSA (key size 2048) certificates over pre-TLSv1.2 protocols. Please see JDK-8242928 for more details. This fix takes the test to use a SHA1withDSA certificate (key size 1024) for TLSv1 and TLSv1.1. Webrev: http://cr.openjdk.java.net/~jjian

RFR[15] JDK-8243029: Rewrite javax/net/ssl/compatibility/Compatibility.java with a flexible interop test framework

Hi, This patch introduces a flexible test framework for supporting JSSE interop testing. This framework supports the SSL/TLS communication between not only JDK builds, but also possibly other TLS implementations. The original test cases in javax/net/ssl/compatibility/Compatibility.java are di

Re: RFR[15] JDK-8237977: Further update javax/net/ssl/compatibility/Compatibility.java

Hi Rajan, Thanks for your suggestions. Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8237977/webrev.01/ On 2020/3/25 11:08, Rajan Halade wrote: Hi John, Thanks for taking care of this fix. Your changes look good me. I have couple of suggestions: - consider changing he

RFR[15] JDK-8237977: Further update javax/net/ssl/compatibility/Compatibility.java

Hi, This patch updates the manual test javax/net/ssl/compatibility/Compatibility.java on the following points: 1. Covers SSLv3 2. The server side doesn't limit/specify protocols and cipher suites anymore. Only the client side specifies these parameters. 3. Only focus on the testing JDK specifie

Re: RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version

Hi Daniel, Would it be possible to include a comment in Cert.java that contains the command you used to generate the certificates? That will be a great help to future maintainers if the certificates ever needs to be re-generated (e.g. to update the expiry date etc...) I'll do that. Please re

Re: RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version

Hi Daniel, On 2020/2/7 19:29, Daniel Fuchs wrote: Hi John, Looks good to me. Thanks for taking care of this! I'm glad to see the binary files go away :-) Thanks for your review! Would it be possible to include a comment in Cert.java that contains the command you used to generate the certifi

RFR[15] 8238677: java/net/httpclient/ssltest/CertificateTest.java should not specify TLS version

Hi, java/net/httpclient/ssltest/CertificateTest.java shouldn't use a specific TLS version. And it would be better not to use binary key store files. Since DSA is not supported by TLSv1.3, this fix also updates the certificates to use RSA. Webrev: http://cr.openjdk.java.net/~jjiang/8238677/web

RFR[14] JDK-8234727: sun/security/ssl/X509TrustManagerImpl tests support TLSv1.3

Hi, Because the below tests use MD5withRSA certificates, so TLSv1.3 cannot be used. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java test/jdk/sun/security/ssl/X509TrustManagerImpl/SelfIssuedCert.java This fix just re-generates the certificates to use SHA256withRSA. Issue: h

Re: RFR[14] JDK-8235813: System property fullCipherSuites is not used by javax/net/ssl/compatibility/Compatibility.java

Hi Xuelei, On 2019/12/16 11:22, Xuelei Fan wrote: I think the property is for test code only, is it? Yes. It is only used by this test. The update looks fine to me. Thanks! Best regards, John Jiang Xuelei On Dec 15, 2019, at 6:09 PM, sha.ji...@oracle.com wrote: Hi, javax/net/ssl/compa

RFR[14] JDK-8235813: System property fullCipherSuites is not used by javax/net/ssl/compatibility/Compatibility.java

Hi, javax/net/ssl/compatibility/Compatibility.java should use property fullCipherSuites to indicate if testing all of specific cipher suites. In addition, the cases on TLS_ECDH_RSA cipher suites fail due to a RSA-signed EC key certificate has something wrong. Issue: https://bugs.openjdk.java.n

RFR[14] JDK-8231810: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "java.lang.Exception: Unexpected EOF"

Hi, When the server socket in this test tries to receive close_notify, possibly the client socket is (being) closed. Without this patch, this failure was easily reproduced by running the test in a loop. With this patch, I didn't reproduce it in the same way. Issue: https://bugs.openjdk.java.

RFR[14] JDK-8235255: ProblemList javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java

Hi, It needs to put javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java into ProblemList due to JDK-8231810. diff -r aa12d1f0bc66 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt    Tue Dec 03 14:10:53 2019 + +++ b/test/jdk/ProblemList.txt    Tue Dec 03 22:31:15 2019 +0800 @@ -68

RFR[14] JDK-8234724: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java supports TLSv1.3

Hi, This simple patch just takes test javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java to cover TLSv1.3. diff -r 88502b1cf76f test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java --- a/test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java Mon Sep 09 11:43:16 2019

Re: RFR: 8231351: Add notes for PKCS11 tests in the test doc

Hi Jie, IIRC, this test passed on your Ubuntu 18.04 with a new built NSS 3.35 libs. So, I suspected your Linux or the system built-in NSS libs had something wrong. Now that this test passed with NSS 3.35 on others' Linux, including mine, it may not make sense that this test is skipped for NSS 3.

Re: RFR: 8231351: Add notes for PKCS11 tests in the test doc

Hi Jia, I think this isn't a general testing problem. It may not worthy of highlighting this point in the JDK testing doc. In fact, PKCS11 tests have their own doc at: test/jdk/sun/security/pkcs11/README Best regards, John Jiang On 2019/9/23 18:04, Jia Huang wrote: Hi all, JBS:    https://bu

RFR[14] JDK-8180837: SunPKCS11-NSS tests failing with CKR_ATTRIBUTE_READ_ONLY and CKR_MECHANISM_PARAM_INVALID

Hi, Tests sun/security/pkcs11/Secmod/AddTrustedCert.java and sun/security/pkcs11/tls/TestKeyMaterial.java failed due to some changes in NSS. This fix just workarounds this problem. For more details, please see the comments in this JBS issue. And it also provides a pre-built NSS libs for linux-x

Re: FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests

Ping... In the future, we would use these utilities to refactor some existing tests, which depend on binary trust/key stores. I just run all tests in java/security, javax/security, javax/net/ssl and sun/security with this patch. The results are fine. Best regards, John Jiang On 2019/8/19 1

RFR[14] JDK-8226221: Update PKCS11 tests to use NSS 3.46 libs

Hi, The below simple patch just take PKCS11 tests to use the latest NSS, exactly version 3.46, libs. diff -r bf3fb5465543 test/jdk/sun/security/pkcs11/PKCS11Test.java --- a/test/jdk/sun/security/pkcs11/PKCS11Test.java    Tue Sep 03 17:45:02 2019 +0300 +++ b/test/jdk/sun/security/pkcs11/PKCS11T

Re: FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests

Could this patch be reviewed? Best regards, John On 2019/8/4 07:32, sha.ji...@oracle.com wrote: Hi Sean, I moved test/jdk/java/security/testlibrary/CertUtils.java  to test/lib/jdk/test/lib/security/CertUtils.java, and added the new methods to this class. The affected existing tests are also

Re: FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests

Hi Sean, I moved test/jdk/java/security/testlibrary/CertUtils.java  to test/lib/jdk/test/lib/security/CertUtils.java, and added the new methods to this class. The affected existing tests are also modified. http://cr.openjdk.java.net/~jjiang/8228967/webrev.01/ Best regards, John Jiang On 2019

FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests

Hi, This enhancement provides a set of utilities for creating certificate, trust/key store and SSL context. It provides the default trust and key stores with RSA, ECDSA, RSASSA-PSS and DSA certificates, and also the default TLS and DTLS contexts with the default trust and key stores. Three tes

RFR[13] JDK-8228403: SignTwice.java failed with java.io.FileNotFoundException: File name too long

Hi, The Java runtime version of JDK builds may be long, then the path to the generated jars, which use this version as part of file name, would be too long. This fix takes the jar names to use Java version, which should be much shorter. Now, the report table displays the Java versions and the

Re: RFR[13]: 8227551 Session Resumption without Server-Side State off by default

Hi Tony, Just a minor comment.  242 if (st.compareToIgnoreCase("true") == 0) {  243 statelessSession = true;  244 } Could it simply use the below statement? statelessSession = st.equalsIgnoreCase("true"); Best regards, John Jiang On 2019/7/17 11:12, Antho

Re: RFR 8217375: jarsigner breaks old signature with long lines in manifest

Hi, Sorry for this late reply! I only focus on the changes on the tests in sun/security/tools/jarsigner/compatibility. Compatibility.java has been modified significantly, I just had a quick look at it. sun/security/tools/jarsigner/compatibility/SignTwice.java With my test

Re: [13]RFR:8224650:Add tests to support X25519 and X448 in TLS

Hi, Because Siba has to be offline for some days, now I take over this task. Please review this updated webrev: http://cr.openjdk.java.net/~jjiang/8224650/webrev.01/ It covers more cipher suites, and changes SSLSocketTemplate.java on creating SSL context. Now, SSLSocketTemplate.java contains ne

Re: [13]RFR:8224650:Add tests to support X25519 and X448 in TLS

Hi Siba, I have some minor comments. Now that JDK-8225766 has been fixed, I suppose this test can cover some ECDHE_ECDSA cipher suites.   48 private static volatile int index;   ...   56 for (String c : getCiphers(protocols[index], args[0])) {   ...   66 String[] ps = n

RFR JDK-8225390: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8161536

Hi, Test sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java should be in ProblemList until JDK-8161536 is resolved. diff -r 184b05daf50f test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt    Wed Jun 05 21:50:29 2019 -0400 +++ b/test/jdk/ProblemList.txt    Thu Jun 06 09:58:13 2019 +0800 @

Re: RFR 8211018: Session Resumption without Server-Side State

Hi Tony, On 2019/6/5 00:46, Anthony Scarpino wrote: 125 if (secondSession.getCreationTime() > secondStartTime && 126 !clientCache && !serverServerless) { 127 throw new RuntimeException("Session was not reused"); 128 } If the session

Re: RFR 8211018: Session Resumption without Server-Side State

ResumeChecksServer.java 57 static boolean clientCache = false, serverServerless = false; Should "serverServerless" be "serverStateless"? 86 if (st.compareToIgnoreCase("stateless") == 0) { 87 serverServerless = true; 88 } 89 st = Syste

Re: RFR 8211018: Session Resumption without Server-Side State

Hi Tony, I have some minor comments on the test. ResumeChecksServer.java 57 static boolean clientCache = false, serverServerless = false; Should "serverServerless" be "serverStateless"? 86 if (st.compareToIgnoreCase("stateless") == 0) { 87 serverServe

Re: RFR 8211018: Session Resumption without Server-Side State

Hi Tony, The new introduced properties in the source and CSR are jdk.tls.client.sessionTicketExtension and jdk.tls.server.sessionCacheState, but the new tests ResumeChecksClientStateless.java and ResumeChecksServerStateless.java use javax.net.ssl.sessionTicketExtension and javax.net.ssl.session

Re: RFR[13] JDK-8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed

Hi Valeria, On 2019/5/1 04:25, Valerie Peng wrote: Looks fine to me. Thanks for your review! With further testing, sun/security/tools/keytool/NssTest.java may fail due to some dependencies are not found. But this failure should not be related to this NSS libs upgrade, because it could also r

RFR[13] JDK-8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed

Hi, NSS 3.41 has been approved, so just build this version for windows (with VS2017) and macosx. Webrev: http://cr.openjdk.java.net/~jjiang/8204203/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8204203 Best regards, John Jiang

RFR[13] JDK-8222391: javax/net/ssl/compatibility/Compatibility.java should be more flexible

Hi, This fix just makes some improvements for the manual test javax/net/ssl/compatibility/Compatibility.java in the following points: 1. The test cases could be customized. 2. The current testing JDK (namely, the test.jdk) always be covered. 3. It allows to exclude the test cases if the JSSE ser

Re: RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output

Hi Max, On 2019/3/18 22:04, Weijun Wang wrote: Hi John, The new webrev looks mostly fine, except that I don't like the new lambda in Test.java. But I'll leave it to you to decide if that style is good. Have you been able to reproduce the original test failure and make sure your updated test

Re: RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output

Hi Max, If using "-J-Duser.timezone=null", it looks jarsigner always uses timezone GMT-8/PST, but not the local timezone. Currently, the testing machines should use GMT-7/PDT. If no user.timezone is specified, jarsigner just uses local timezone. Please review the updated webrev: http://cr.open

Re: RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output

On 2019/3/13 16:58, sha.ji...@oracle.com wrote: Hi, This fix just makes sure that specified timezone is not null, and the jar verifying and date formatting use the same different timezone. ... use the same (not different) timezone. John Webrev: http://cr.openjdk.java.net/~jjiang/8220410/we

RFR[13] JDK-8220410: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with missing expected output

Hi, This fix just makes sure that specified timezone is not null, and the jar verifying and date formatting use the same different timezone. Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8220410 Best regards, John Jiang

Re: RFR[13] JDK-8219723: javax/net/ssl/compatibility/Compatibility.java failed on some SNI cases

Hi Jamil, Thanks for your suggestion. Best regards, John Jiang On 2019/3/1 01:54, Jamil Nimeh wrote: This comment doesn't directly apply to this fix, but tests that depend on the certs from Cert.java and have configurable PKIXParameters might also just set setDate to something in the middle of

RFR[13] JDK-8219723: javax/net/ssl/compatibility/Compatibility.java failed on some SNI cases

Hi, Test javax/net/ssl/compatibility/Compatibility.java failed due to the associated certificates are expired. This fix just re-generates the certificates and set much longer validity period. Issue: https://bugs.openjdk.java.net/browse/JDK-8219723 Webrev: http://cr.openjdk.java.net/~jjiang/821

RFR[13] JDK-8215524: Finished message validation failure should be decrypt_error alert

Hi, When Finished message is validated failed, illegal_parameter is raised currently. But per RFC 8446 section 6.2, this error should alert decrypt_error. And according to the same section, if the length of verify_data in Finished is incorrect, it should alert decode_error rather than illegal_

RFR[13] JDK-8146392: sun/security/tools/keytool/selfissued.sh failed with ar_SA locale

Hi, This fix just makes sure that the keytool in test sun/security/tools/keytool/selfissued.sh uses en_US locale, or the test fails with ar_SA. diff -r bc20d0376402 test/jdk/sun/security/tools/keytool/selfissued.sh --- a/test/jdk/sun/security/tools/keytool/selfissued.sh    Mon Jan 28 23:00:31

Re: RFR[12] JDK-8203687: javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3

Hi Xuelei, On 2019/1/18 02:00, Xuelei Fan wrote: Hi John, Looks fine to me except a minor format comment. Would you mind check the line length and limit to 80 characters each line? For example, using "\"  join multiple lines together.     // openssl req -x509 -new -key key.pem \     //

RFR[12] JDK-8203687: javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3

Hi, The patch adds TLS 1.3 cases for test javax/net/ssl/compatibility/Compatibility.java. Beside this enhancement, it also changes the test on the following points: 1. Re-generate all certificates to use key size 2048 and SHA256 rather than 1024 and SHA1. And new RSA signed EC key certificates

RFR[12] JDK-8214937: sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed due to unexpected expiration date

Hi, This test should determine the cert expiration date from the cert itself, but not try to calculate that date. Issue: https://bugs.openjdk.java.net/browse/JDK-8214937 Webrev: http://cr.openjdk.java.net/~jjiang/8214937/webrev.00/ Best regards, John Jiang

RFR[12] JDK-8214520: [TEST_BUG] sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java failed with incorrect jtreg tags order

Hi, When run this test on Windows, jtreg complains that '@library' must appear before first action tag. So, just adjust the tag positions. Issue: https://bugs.openjdk.java.net/browse/JDK-8214520 diff -r a6182c464b31 test/jdk/sun/security/mscapi/nonUniqueAliases/NonUniqueAliases.java --- a/te

Re: RFR[12] JDK-8214459: NSS source should be removed

Hi Valerie, Do you have more concern about this issue? I re-generate this patch with hg diff option -g. The new patch should delete all the files, including the directory. diff --git a/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz b/test/jdk/sun/security/pkcs11/nss/sr

Re: RFR[12] JDK-8214459: NSS source should be removed

Hi Valerie, On 2018/11/30 10:28, Valerie Peng wrote: I assume not just the two files, their containing src directory will be removed, right? Yes. This directory also will be removed. Best regards, John Jiang Valerie On 11/28/2018 10:35 PM, sha.ji...@oracle.com wrote: Hi, The NSS 3.16 sou

RFR[12] JDK-8214459: NSS source should be removed

Hi, The NSS 3.16 source in test/jdk/sun/security/pkcs11/nss/src is not needed anymore, so just remove it. diff -r 1d520c376105 test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz Binary file test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz has changed d

RFR[12] JDK-8212562: To remove lib/security from test/jdk/TEST.groups

Hi, test/jdk/lib/security doesn't exist, so this directory could be removed from jdk_security3 diff -r f54dcfc5a5f8 test/jdk/TEST.groups --- a/test/jdk/TEST.groups    Fri Oct 05 15:12:37 2018 -0700 +++ b/test/jdk/TEST.groups    Wed Oct 17 15:01:36 2018 +0800 @@ -218,8 +218,7 @@ -sun/securi

Re: RFR[12] JDK-8210632: Add key exchange algorithm to javax/net/ssl/TLSCommon/CipherSuite.java

Ping... On 2018/10/10 11:25, sha.ji...@oracle.com wrote: Hi, It would be better that javax/net/ssl/TLSCommon/CipherSuite.java has an attribute on key exchange algorithm. This attribute could be used on selecting appropriate certificates by some tests. Issue: https://bugs.openjdk.java.net/bro

RFR JDK-8211971: Move security/cacerts/VerifyCACerts.java and security/CheckBlacklistedCerts.java

Hi, This fix moves tests VerifyCACerts.java and CheckBlacklistedCerts.java in lib/security to sun/security/lib. Issue: https://bugs.openjdk.java.net/browse/JDK-8211971 Webrev: http://cr.openjdk.java.net/~jjiang/8211971/webrev.00/ Best regards, John JIang

Re: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary

Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8211978/webrev.01/ AbstractSSLTubeTest.java and FlowTest.java now use the same internal.net.http.SimpleSSLContext.java In addition, it looks the original jdk/testlibrary/SimpleSSLContext.java could accept an alternative keyst

Re: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary

At least, the inner SimpleSSLContext classes in AbstractSSLTubeTest.java and FlowTest.java could be combined. I'm doing it. Best regards, John Jiang On 2018/10/15 17:21, Daniel Fuchs wrote: Hi Max, These tests are whitebox tests - the tests classes are patched into the java.net.http module, a

RFR[12] JDK-8210632: Add key exchange algorithm to javax/net/ssl/TLSCommon/CipherSuite.java

Hi, It would be better that javax/net/ssl/TLSCommon/CipherSuite.java has an attribute on key exchange algorithm. This attribute could be used on selecting appropriate certificates by some tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8210632 Webrev: http://cr.openjdk.java.net/~jjiang/

Re: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

On 2018/9/27 21:20, Weijun Wang wrote: Change looks fine. On PKCS11Test.java:453, you can use Files::newInputStream. Just addressed it, please take a look at this updated webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.03/ It also renames the test in ProblemList.txt accordingly. Best

Re: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

Hi Max, Please review this new webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.02/ You previous points, except #1, are addressed. Best regards, John Jiang On 2018/9/27 11:18, sha.ji...@oracle.com wrote: On 2018/9/27 10:34, Weijun Wang wrote: Hi John 1. Please add @bug to all tests

Re: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

On 2018/9/27 11:20, Weijun Wang wrote: On Sep 27, 2018, at 11:18 AM, sha.ji...@oracle.com wrote: On 2018/9/27 10:34, Weijun Wang wrote: Hi John 1. Please add @bug to all tests. Which issue should be linked? JDK-8209546? I suppose @bug should indicate a product issue here. At least, JDK-820954

Re: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

On 2018/9/27 10:34, Weijun Wang wrote: Hi John 1. Please add @bug to all tests. Which issue should be linked? JDK-8209546? I suppose @bug should indicate a product issue here. At least, JDK-8209546 looks have no much association with this test. 2. Are getLibPath() and findLib() in AutoTest.j

Re: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

Hi Max, Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.01/ All your comments are addressed, though this test is moved to problem list for windows due to JDK-8204203. Best regards, John Jiang On 2018/9/25 22:30, Weijun Wang wrote: Some questions: 1. Do we

Re: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

2. Is launching a separate process necessary? Can we just call KeyToolTest::main after setting system properties and copying the files. I did think about this point. It looks this test could be run by manual if someone want to set those system properties. I supposed that's why KeyToolTest.

Re: RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

Hi Max, On 2018/9/25 22:30, Weijun Wang wrote: Some questions: 1. Do we still need the OS check on lines 47-49? As long as getLibPath() can return something, does it mean the test should just run? Especially, does the test run on Windows? The original test ignores Windows, and says "This test

RFR[12] JDK-8209546: Make sun/security/tools/keytool/autotest.sh to support macosx

Hi, JDK-8164639 removed NSS libs from repo, so sun/security/tools/keytool/autotest.sh has to download NSS libs from artifactory on macosx. This patch also refactors this shell test to a Java test. Webrev: http://cr.openjdk.java.net/~jjiang/8209546/webrev.00/ Issue: https://bugs.openjdk.java.ne

Re: RFR[12] JDK-8209362: sun/security/ssl/SSLSocketImpl/ReuseAddr.java failed due to "BindException: Address already in use (Bind failed)"

On 2018/8/31 09:22, Xuelei Fan wrote: On 8/30/2018 6:16 PM, sha.ji...@oracle.com wrote: Hi Xuelei, It still be possible that two test runs fail. Yes.  I was wondering the possibility of the failure may go down. I searched this test in JBS, and didn't find many failures on this test. So, it ma

Re: RFR[12] JDK-8209362: sun/security/ssl/SSLSocketImpl/ReuseAddr.java failed due to "BindException: Address already in use (Bind failed)"

Hi Xuelei, It still be possible that two test runs fail. Best regards, John Jiang On 2018/8/30 22:02, Xuelei Fan wrote: Maybe, run the test twice and pass if one passed? Xuelei On 8/29/2018 7:34 PM, sha.ji...@oracle.com wrote: Hi, In test sun/security/ssl/SSLSocketImpl/ReuseAddr.java, the se

RFR[12] JDK-8209362: sun/security/ssl/SSLSocketImpl/ReuseAddr.java failed due to "BindException: Address already in use (Bind failed)"

Hi, In test sun/security/ssl/SSLSocketImpl/ReuseAddr.java, the second server tries to reuse the first server's port after it stops. But the port may already be occupied by another test before this rebinding. Although I'm not sure a way to resolve this problem thoroughly, it's a chance to refactor

RFR[11] JDK-8209537: Two security tests failed after JDK-8164639 due to dependency was missed

Hi, JDK-8164639 removed NSS libs from repo and added @Artifact in /test/lib to PKCS11Test.java as dependency. Some tests outside of sun/security/pkcs11 are also affected. So they have to be modified accordingly. Webrev: http://cr.openjdk.java.net/~jjiang/8209537/webrev.00/ Issue: https://bugs.

Re: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries

On 2018/8/15 15:14, Weijun Wang wrote: I see. One more question: Since the osMap content is not changed, is there a special reason you move the code from a static block into a static method? If preferable NSS lib paths have been provided, it looks no need to create that map. Best regards, Jo

Re: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries

On 2018/8/15 14:54, Weijun Wang wrote: I notice one behavior change in PKCS11Test.java. 693 private static String[] getNssLibPaths(String osId) { 694 String[] preferablePaths = getPreferableNssLibPaths(osId); 695 if (preferablePaths.length != 0) { 696 retu

Re: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries

Hi Max, Thanks for your comments very much! Please review this version: http://cr.openjdk.java.net/~jjiang/8164639/werbrev.03/ All of your comments are addressed. Assume external developers have no JIB jar, the artifact resolving fails quickly. The tests will be skipped for this case. Best

Re: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries

Thanks for the comments! Please take a look the updated webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.02/ Only README was adjusted. Best regards, John Jiang On 2018/8/14 23:48, Rajan Halade wrote: Few minor comments on README: - Please leave an empty line after each numbered sect

Re: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries

Hi Max, Please review the new webrev: http://cr.openjdk.java.net/~jjiang/8164639/webrev.01/ The new system property has been renamed to test.nss.lib.paths, and it supports multiple paths. Currently, it cannot download the artifacts outside Oracle network. This affects the test executions on W

Re: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries

Hi Max, On 2018/8/13 13:58, Weijun Wang wrote: On Aug 13, 2018, at 1:46 PM, sha.ji...@oracle.com wrote: On 2018/8/13 11:25, Weijun Wang wrote: Can test.nss.lib.path contain multiple paths? For example, some systems might have libsoftkn3.so and libnss3.so in different directories [1] and dep

Re: RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries

On 2018/8/13 11:25, Weijun Wang wrote: Can test.nss.lib.path contain multiple paths? For example, some systems might have libsoftkn3.so and libnss3.so in different directories [1] and depending on whether secmod is used the test might load one or the other. I assume the custom libs are in a si

RFR JDK-8164639: Configure PKCS11 tests to use user-supplied NSS libraries

Hi, This patch provides a system property, exactly test.nss.lib.path, for specifying the absolute path to the custom NSS lib. And it also removes the NSS 3.16 binary libs on windows and macosx from repo. On these two platforms, PKCS11 tests will download new built NSS 3.35 libs from Artifactory

Re: [11] RFR: 8208496: New Test to verify concurrent behavior for TLS.

Hi Siba, Would it be better to check how many connections the server accepts? In your case, the server must accept 50 (no more no less) connections; otherwise, some problem may raise. And I suppose, when the server thread is interrupted, the server socket may not be closed. The server should e

Re: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found

Hi Valerie, Thanks for your review! Please take a look at this new webrev: http://cr.openjdk.java.net/~jjiang/8206258/webrev.02 On 2018/7/24 06:18, Valerie Peng wrote: Hi John, Changes look fine. I just have one nit, perhaps add more information reporting when skipping tests, e.g. PKCS11T

Re: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found

Ping... John On 2018/7/13 09:15, sha.ji...@oracle.com wrote: Could the new patch be reviewed? http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/ Thanks! John On 2018/7/9 15:38, sha.ji...@oracle.com wrote: Hi Thomas, Thanks for your testing. I'm not sure that's a reasonable case. From my

RFR[12] JDK-8206443: Update security libs manual test to cope with removal of javac -source/-target 6

Hi, JDK-8028563 has removed javac support for 6/1.6 source and target, so the following tests has to be updated accordingly. javax/net/ssl/compatibility/Compatibility.java sun/security/tools/jarsigner/compatibility/Compatibility.java In addition, this fix also makes javax/net/ssl/compatibility

Re: RFR[11] JDK-8206258: [Test Error] sun/security/pkcs11 tests fail if NSS libs not found

Could the new patch be reviewed? http://cr.openjdk.java.net/~jjiang/8206258/webrev.01/ Thanks! John On 2018/7/9 15:38, sha.ji...@oracle.com wrote: Hi Thomas, Thanks for your testing. I'm not sure that's a reasonable case. From my view, PKCS11Test.java simply checks if the NSS library director

Re: RFR[11] JDK-8199645: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with Connection reset

Hi Xuelei, Thanks for your review! The fix just was pushed. I adjusted the following longer lines:  129 System.out.println("Client got UNEXPECTED SSLHandshakeException:");  134 System.out.println("Client got expected SSLHandshakeException:"); In addition, the p

  1   2   >