Code review request: 8016051: Possible ClassCastException in KdcComm

Hi, please review this fix for 8: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016051 http://1.smotrakov.z8.ru/8016051/webrev.00/ It fixes a possible ClassCastException if an exception thrown from send() method is not IOException or KrbException. The first exception is thrown if all

Re: Code review request: 8016051: Possible ClassCastException in KdcComm

? Thanks Max On 6/25/2013 1:35 PM, Artem Smotrakov wrote: Hi, please review this fix for 8: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016051 http://1.smotrakov.z8.ru/8016051/webrev.00/ It fixes a possible ClassCastException if an exception thrown from send() method is not IOException

Code Review request: 8028431: NullPointerException in DerValue.equals(DerValue)

Hi, please review this fix for 9: https://bugs.openjdk.java.net/browse/JDK-8028431 http://cr.openjdk.java.net/~asmotrak/8028431/webrev.00/ http://cr.openjdk.java.net/%7Easmotrak/8028431/webrev.00/ sun.security.util.DerValue.equals(DerValue) method does not check that null is passed. As a

Re: Code Review request: 8028431: NullPointerException in DerValue.equals(DerValue)

'. Thanks. On 20/12/2013 12:51, Artem Smotrakov wrote: Hi, please review this fix for 9: https://bugs.openjdk.java.net/browse/JDK-8028431 http://cr.openjdk.java.net/~asmotrak/8028431/webrev.00/ http://cr.openjdk.java.net/%7Easmotrak/8028431/webrev.00/ sun.security.util.DerValue.equals(DerValue

Re: Code Review request: 8028431: NullPointerException in DerValue.equals(DerValue)

of DerValue.java. Also I would add the test to the existing test/java/security/cert/X509Certificate/ directory rather than create a new one. Finally, I think the test should run fine without the jtreg tag for 'othervm'. Thanks. On 20/12/2013 12:51, Artem Smotrakov wrote: Hi, please review this fix for 9

Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString()

Please review this fix for 9: https://bugs.openjdk.java.net/browse/JDK-8028591 http://cr.openjdk.java.net/~asmotrak/8028591/webrev.00/ http://cr.openjdk.java.net/%7Easmotrak/8028591/webrev.00/ getLength() method is used to get a length of bit string. The method can return a negative value

Re: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString()

). Then, for the encodings where it is illegal to use the indefinite-length method, change the code to call the method with the flag set to true. --Sean On 01/30/2014 03:47 AM, Artem Smotrakov wrote: Please review this fix for 9: https://bugs.openjdk.java.net/browse/JDK-8028591 http://cr.openjdk.java.net

Re: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString()

of returning -1). Then, for the encodings where it is illegal to use the indefinite-length method, change the code to call the method with the flag set to true. --Sean On 01/30/2014 03:47 AM, Artem Smotrakov wrote: Please review this fix for 9: https://bugs.openjdk.java.net/browse/JDK-8028591 http

Re: Code Review request: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString()

On 03/12/2014 02:14 PM, Wang Weijun wrote: First, let me clarify again that your webrev is fine. All items below are unrelated and we can address it with another bug if necessary. Ok, thank you. On Mar 12, 2014, at 16:55, Artem Smotrakov artem.smotra...@oracle.com wrote: Hi Max, 1

RFR: 8048603: Additional tests for MAC algorithms

Please review a couple of new test cases for MAC algorithms. https://bugs.openjdk.java.net/browse/JDK-8048603 http://cr.openjdk.java.net/~asmotrak/8048603/webrev.00/ Artem

[9] request for review 8059009: LDAPCertStore fails to retrieve CRL after LDAP server closes idle connection

Please review this fix for 9. It corrects the following issues: - InitialLdapContext and LDAPCertStore does not recover connection if it was closed, for example, by server, or due to some network issue - A cache of CertStore instances in LDAPCertStore does not work if LDAPCertStoreParameters

Re: RFR: 8048603: Additional tests for MAC algorithms

a check that CloneNotSupportedException is thrown on Solaris Please take a look. http://cr.openjdk.java.net/~asmotrak/8048603/webrev.01/ Artem On 11/07/2014 01:07 PM, Artem Smotrakov wrote: Please review a couple of new test cases for MAC algorithms. https://bugs.openjdk.java.net/browse/JDK-8048603

Re: [9] request for review: 8049171: Additional tests for jarsigner's warnings

, Artem Smotrakov artem.smotra...@oracle.com wrote: Hello, Please review a couple of new tests for jarsigner's warnings. Basically tests run jarsigner and check warning/error messages and exit codes according to [1]. https://bugs.openjdk.java.net/browse/JDK-8049171 http://cr.openjdk.java.net

[9] request for review: 8049171: Additional tests for jarsigner's warnings

Hello, Please review a couple of new tests for jarsigner's warnings. Basically tests run jarsigner and check warning/error messages and exit codes according to [1]. https://bugs.openjdk.java.net/browse/JDK-8049171 http://cr.openjdk.java.net/~asmotrak/8049171/webrev.00 [1]

Re: [9] request for review: 8049171: Additional tests for jarsigner's warnings

Hi Max, Here is an updated webrev, please take a look. http://cr.openjdk.java.net/~asmotrak/8049171/webrev.02/ Artem On 01/26/2015 05:03 AM, Weijun Wang wrote: On 1/23/2015 16:12, Artem Smotrakov wrote: If the MANIFEST and the signature files must be at the beginning, should

Re: [9] request for review: 8049171: Additional tests for jarsigner's warnings

Hi Max, Please see inline. On 01/23/2015 05:18 AM, Wang Weijun wrote: I have updated the webrev, updateJar() method does the following: - creates a new jar file (destJarFilename) - puts files which are specified in files parameter to destJarFilename - copies files from srcJarFilename to

[9] request for review: 8048147: Privilege tests with JAAS Subject.doAs

Hello, Please review a couple of new tests for privilege checks on Subject.doAs(). https://bugs.openjdk.java.net/browse/JDK-8048147 http://cr.openjdk.java.net/~asmotrak/8048147/webrev.00/ Artem

Re: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs

them clearer. Please take a look: http://cr.openjdk.java.net/~asmotrak/8048147/webrev.02/ Artem On 03/18/2015 06:08 PM, Wang Weijun wrote: On Mar 18, 2015, at 19:31, Artem Smotrakov artem.smotra...@oracle.com wrote: The tests can be updated to start a new process with ProcessTools, or use

Re: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs

the webrev. Sorry about that and thanks for attention. Please take a look at http://cr.openjdk.java.net/~asmotrak/8048147/webrev.03/ Artem Thanks Max On Mar 19, 2015, at 19:39, Artem Smotrakov artem.smotra...@oracle.com wrote: Hi Max, I agree that sometimes use of a shell script makes a test

Re: [9] request for review: 8048147: Privilege tests with JAAS Subject.doAs

the changeset comment you want to use. Thanks Max On Mar 20, 2015, at 14:49, Artem Smotrakov artem.smotra...@oracle.com wrote: Hi Max, Please see inline. On 03/19/2015 05:33 PM, Wang Weijun wrote: This looks fine. One comment, 156 cmds.add(-Duser.dir= + WORK_DIR); Looks unnecessary

[9] RFR: 8076221: Disable RC4 cipher suites

Hello, RFC 7465 [1] has been published to prohibit RC4. Please review this fix which disables RC4 cipher suites in JDK 9 by adding RC4 to jdk.tls.disabledAlgorithms security property. Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.00/ Bug:

[9] RFR: 8050374: More Signature tests

Hello, Please review a couple of new tests for Signature and SignedObject. The test use different providers, that's why I put them to provider-specific locations. Bug: https://bugs.openjdk.java.net/browse/JDK-8050374 Webrev: http://cr.openjdk.java.net/~asmotrak/8050374/webrev.00/ Artem

[9] RFR: 8048138: Tests for JAAS callbacks

Hello, Please review a couple of new tests for JAAS: - StandardCallbacks.java is for standard JAAS callbacks (except RealmCallback and RealmChoiceCallback since the test is not about Sasl, and actually those two callback extends ChoiceCallback which is used in the test) - SharedState.java

Re: [9] RFR: 8048138: Tests for JAAS callbacks

/javax/security/auth/login/LoginContext.html Please see an updated webrev: http://cr.openjdk.java.net/~asmotrak/8048138/webrev.01/ Artem Thanks Max On 4/21/2015 10:22 PM, Artem Smotrakov wrote: Hello, Please review a couple of new tests for JAAS: - StandardCallbacks.java is for standard JAAS

Re: [9] RFR: 8075007: Additional tests for krb5-related cipher suites with unbound server

requite the policy file. But they still need to be run in othervm mode since they use system properties. I updated these two tests not to use the policy file http://cr.openjdk.java.net/~asmotrak/8075007/webrev.01/ Artem Thanks Max On 4/21/2015 10:41 PM, Artem Smotrakov wrote: Hello, Please

Re: [9] RFR: 8075007: Additional tests for krb5-related cipher suites with unbound server

of the startServer() method? I believe all the current tests can actually benefit from this. --Max On 4/23/2015 2:30 PM, Artem Smotrakov wrote: Hi Max, On 04/22/2015 05:51 PM, Weijun Wang wrote: Hi Artem These are splendid tests. So do they just all pass? :-) Yes, fortunately they do

[9] RFR: 8076486: javax/security/auth/Subject/doAs/NestedActions.java fails if extra VM options are given

Hello, Please review this fix for javax/security/auth/Subject/doAs/NestedActions.java test. The test runs java in a separate process. It fails if multiple java options are passed because ProcessBuilder expects each parameter to be put in to a separate array element, but the test didn't do

Re: [9] RFR: 8076486: javax/security/auth/Subject/doAs/NestedActions.java fails if extra VM options are given

. And it seems Collections.addAll() can add an array to a list. Of course, you are free to exercise any fancy jdk8 features. :-) Thanks Max On 4/29/2015 3:23 PM, Artem Smotrakov wrote: Hello, Please review this fix for javax/security/auth/Subject/doAs/NestedActions.java test. The test runs java

[9] RFR: 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads system properties

Hello, Please review this fix for 9. If security manager is enabled, but org.jcp.xml.dsig.secureValidation property is off, IgnoreAllErrorHandler tries to read two system properties. If appropriate permissions are not granted, it fails with ExceptionInInitializerError. Changes: - updated

[9] RFR: 8079138: Additional negative tests for XML signature processing

Hello, Please review a couple of negative tests which check that invalid XML digital signatures are rejected. Bug: https://bugs.openjdk.java.net/browse/JDK-8079138 Webrev: http://cr.openjdk.java.net/~asmotrak/8079138/webrev.01/ Artem

Re: [9] RFR: 8079140: IgnoreAllErrorHandler should use doPrivileged when it reads system properties

50-52) because ideally this code needs to stay in sync with the Apache Santuario implementation which still supports JDK 1.6 and up. Thanks, Sean On 05/15/2015 02:23 PM, Artem Smotrakov wrote: Hello, Please review this fix for 9. If security manager is enabled

Re: [9] RFR: 8050374: More Signature tests

Hello, I added 'randomness' key, and updated Offsets.java to use jdk.testlibrary.RandomFactory. Please take a look: http://cr.openjdk.java.net/~asmotrak/8050374/webrev.01/ Artem On 04/21/2015 08:25 AM, Artem Smotrakov wrote: Hello, Please review a couple of new tests for Signature

[9] RFR: 8074784: Additional tests for XML DSig API

Hello, Please review a new test for generating and validation of detached XML digital signatures. Bug: https://bugs.openjdk.java.net/browse/JDK-8074784 Webrev: http://cr.openjdk.java.net/~asmotrak/8074784/webrev.00/ Artem

[8u] RFR: 8076221: Disable RC4 cipher suites

Hello, RFC 7465 [1] has been published to prohibit RC4. Please review this fix which disables RC4 cipher suites in JDK 8u by adding RC4 to jdk.tls.disabledAlgorithms security property. Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.8u.00/ Bug:

Re: [9] RFR: 8074784: Additional tests for XML DSig API

and ValidationTests in the test/javax/xml/crypto/dsig directory, so you could reuse common code. Thanks, Sean On 05/12/2015 11:32 AM, Artem Smotrakov wrote: Hello, Please review a new test for generating and validation of detached XML digital signatures. Bug: https://bugs.openjdk.java.net/browse

Re: [9] RFR: 8129575: Equal DelegationPermission instances may return different hash codes

Sure, http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.02/ Artem On 06/25/2015 02:14 PM, Sean Mullan wrote: Looks good. There is an incorrect period at the end of line 152, can you also remove that? Thanks, Sean On 06/25/2015 06:56 AM, Artem Smotrakov wrote: Hello, Please

[9] RFR: 8129575: Equal DelegationPermission instances may return different hash codes

Hello, Please review this fix for 9. A string which contains a number of principals can be passed to constructor of DelegationPermission. The class parses this string, and extracts principals. But hashCode() method in DelegationPermission uses Permission.getName() to calculate a hash.

Re: [9] RFR: 8074784: Additional tests for XML DSig API

Hi Sean, I added new test cases to GenerationTests, please take a look: http://cr.openjdk.java.net/~asmotrak/8074784/webrev.01/ Artem On 06/16/2015 07:23 PM, Sean Mullan wrote: On 05/20/2015 04:16 PM, Artem Smotrakov wrote: Hi Sean, Yes, at first, I thought about updating the existing

[9] RFR: 8078823: javax/net/ssl/ciphersuites/DisabledAlgorithms.java fails intermittently

Hello, Please review this fix for javax/net/ssl/ciphersuites/DisabledAlgorithms.java test. It fails very rarely with SocketException. The test runs clients in main thread, but a server runs in a separate thread. In checkFailure() method, clients expect a SSLHandshakeException, and when it

[9] RFR: 8048622: Enhance tests for PKCS11 keystores with NSS

Hello, Please review a couple of changes for PKCS11 tests: - Added a new test which checks that a keystore can't be loaded with incorrect password, found https://bugs.openjdk.java.net/browse/JDK-8134232 - Added a check that a trusted entry can be removedfrom keystore - Updated existing tests

Re: [9] RFR: 8075299: Additional tests for 6857795

a look at updated webrev http://cr.openjdk.java.net/~asmotrak/8075299/webrev.01/ Artem Thanks Max On 08/05/2015 07:01 PM, Artem Smotrakov wrote: Hello, Please review a couple of new tests which checks if krb5 settings are read correctly from conf file and system properties. Bug: https

Re: [9] RFR: 8048596: Tests for AEAD ciphers

the same input for various test scenarios in the same test class. As far as I am concerned, the benefit of get data in one line doesn't quite justify the extra dependency. The updated webrev looks fine. Valerie On 7/20/2015 11:33 PM, Artem Smotrakov wrote: Hi Valerie, The tests can easily get

Re: [9] RFR: 8049814: Additional SASL client-server tests

not move lines 88-93 to the beginning? 92: s/authQopConf/authConfQop/; Thanks Max On 07/10/2015 01:16 AM, Artem Smotrakov wrote: Removed one duplicate test case at line 100 in webrev.00, please see updated webrev: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.01/ Artem On 07/08/2015 05

Re: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056

the review process longer so you can push it yourself. :-) It looks like my account has been updated, so probably I can push it by myself now :-) http://openjdk.java.net/census#asmotrak Artem Thanks Max On 07/17/2015 05:05 AM, Artem Smotrakov wrote: Hi Max, Good point, please see an updated webrev

Re: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056

Hi Max, Please see an updated webrev: http://cr.openjdk.java.net/~asmotrak/8075297/webrev.03/ Artem On 07/16/2015 11:31 PM, Wang Weijun wrote: I think it it enough to add a max_retries = 1 to [libdefaults] of krb5.conf, and left default timeout value for the test. Please take a look at

Re: [9] RFR: 8075297: Tests for RFEs 4515853 and 4745056

On 07/18/2015 01:51 AM, Artem Smotrakov wrote: Hi Max, Please see an updated webrev: http://cr.openjdk.java.net/~asmotrak/8075297/webrev.03/ Artem On 07/16/2015 11:31 PM, Wang Weijun wrote: I think it it enough to add a max_retries = 1 to [libdefaults] of krb5.conf, and left default timeout

Re: [9] RFR: 8048596: Tests for AEAD ciphers

: getInstance with SunJCE? SameBuffer.java - line 110: this check can be done earlier, e.g. on line 108. Thanks, Valerie On 7/10/2015 1:02 PM, Artem Smotrakov wrote: Hello, Please review a couple of new tests for AEAD ciphers. Webrev: http://cr.openjdk.java.net/~asmotrak/8048596/webrev.01/ Bug: https

Re: [9] RFR: 8049814: Additional SASL client-server tests

Thanks Max! Yes, I still can't commit the changes, please push them http://cr.openjdk.java.net/~asmotrak/8049814/webrev.03/ Artem On 07/15/2015 05:11 AM, Weijun Wang wrote: On 07/15/2015 10:29 AM, Artem Smotrakov wrote: Hi Max, Status is currently used to indicate an error on server side

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

Hi Mark, I am not a reviewer, just have a couple of comments about InetAddress.java 1. It may be better to create an instance of Scanner in try-with-resource block to be sure that Scanner.close() method is called. 2. Lines 909-923: There are two similar "if" blocks in the loop. Looks like

Re: [9] RFR: 8049814: Additional SASL client-server tests

Removed one duplicate test case at line 100 in webrev.00, please see updated webrev: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.01/ Artem On 07/08/2015 05:30 PM, Artem Smotrakov wrote: Hello, Please review a client/server test for SASL which uses different mechanisms and QOPs

[9] RFR: 8130041: TsacertOptionTest.java intermittently fails on Mac

Hello, Please review this fix for TsacertOptionTest.java test. The test fails intermittently on some Macs. It starts a local TSA service which is actually an HTTP server. Then, it runs jarsigner which uses this local TSA service. The failure happens on some Macs due to system network

[9] RFR: 8049814: Additional SASL client-server tests

Hello, Please review a client/server test for SASL which uses different mechanisms and QOPs. Bug: https://bugs.openjdk.java.net/browse/JDK-8049814 Webrev: http://cr.openjdk.java.net/~asmotrak/8049814/webrev.00/ Artem

[9] RFR: 8048596: Tests for AEAD ciphers

Hello, Please review a couple of new tests for AEAD ciphers. Webrev: http://cr.openjdk.java.net/~asmotrak/8048596/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8048596 Artem

[9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources

Hello, Please review this fix for 9. Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources. This happens because LDAPCertStore accepts only instances of LDAPCertStoreParameters and URICertStoreParameters classes, but

Re: [9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources

URIs are supported for LDAP Certore"); Let's print the scheme received! } else if (!(selector instanceof X509CertSelector)) { throw new CertStoreException("need X509CertSelector to find certs"); this code occurs twice. Let's print the selector class received.

Re: [9] RFR: 8075299: Additional tests for 6857795

://cr.openjdk.java.net/~asmotrak/8075299/webrev.02/ [1] http://docs.oracle.com/javase/8/docs/technotes/tools/windows/kinit.html Artem On 09/10/2015 11:48 AM, Wang Weijun wrote: Everything is fine. Some answers inline: On Aug 6, 2015, at 9:42 PM, Artem Smotrakov <artem.smotra...@oracle.com> wrote: By t

Re: [9] RFR: 8075299: Additional tests for 6857795

Sorry, I forgot to remove "-f" and "-p" options for kinit http://cr.openjdk.java.net/~asmotrak/8075299/webrev.03/ Artem On 09/10/2015 03:18 PM, Artem Smotrakov wrote: Hi Max, It seems that kinit doesn't print any info about ticket flags [1] (I am not sure that it is

Re: [9] RFR: 8048622: Enhance tests for PKCS11 keystores with NSS

Hello, I just sent out a suggested fix for 8048622. I'll update ProblemList.txt here if 8048622 is integrated. Please take a look. Artem On 08/21/2015 11:34 PM, Artem Smotrakov wrote: Hello, Please review a couple of changes for PKCS11 tests: - Added a new test which checks that a keystore

[9] RFR: 8134232: KeyStore.load() throws an IOException with a wrong cause in case of wrong password

Hello, Please review this for 9. According to [1], KeyStore.load(InputStream, char[]) method should throw an IOException, and the cause of the IOException should be an UnrecoverableKeyException: ... Throws: IOException - if there is an I/O or format problem with the keystore data, if a

[9] RFR 8136600: sun/security/krb5/auto/tools/KinitConfPlusProps.java test intermittently fails because PortUnreachableException is missing

Hello, Please review this small test fix for https://bugs.openjdk.java.net/browse/JDK-8136600 The test runs kinit, and expects PortUnreachableException because of wrong KDC port number specified. It seems that other exceptions may be thrown as well. That may depend on platform where the

Re: [9] RFR 8136600: sun/security/krb5/auto/tools/KinitConfPlusProps.java test intermittently fails because PortUnreachableException is missing

Hi Max, I observed SocketTimeoutException on Windows only, but I suppose it can happen on other platforms. Artem On 09/29/2015 05:49 PM, Wang Weijun wrote: Looks fine. Is it Mac or Windows? Is it a SocketTimeoutException? Thanks Max On 2015年9月29日, at 下午10:01, Artem Smotrakov

[9] RFR: 8140470: javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java failed with java.security.AccessControlException

Hello, Please review this small fix which updates XMLDSigWithSecMgr.java test to extend the default security policy instead of override. Please see details here:

Re: [9] RFR: 8140470: javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java failed with java.security.AccessControlException

I sent a wrong version of webrev, please use the following one http://cr.openjdk.java.net/~asmotrak/8140470/webrev.01/ Artem On 12/03/2015 05:10 PM, Artem Smotrakov wrote: Hello, Please review this small fix which updates XMLDSigWithSecMgr.java test to extend the default security policy

[9] RFR: 8144539: Update PKCS11 tests to run with security manager

Hello, Please review this enhancement for PKCS11 tests which updates them to run with both enabled and disable security manager. Tests enable a security manager before running actual test cases for each particular security provider, and disable it when the test cases finish. This helps to

Re: [9] RFR: 8152745: javax/net/ssl/TLS/TestJSSE.java fails intermittently: Unsupported or unrecognized SSL message

dex-v6.html It has a recommendation about line lengths, but it allows lines more than 80 characters if it makes it more readable. Anyway, I avoided lines more than 80 characters (mostly I renamed variables). Please take a look at updated webrev: http://cr.openjdk.java.net/~asmotrak/8152745/w

[9] RFR: 8152745: javax/net/ssl/TLS/TestJSSE.java fails intermittently: Unsupported or unrecognized SSL message

Hello, Please review the patch below for javax/net/ssl/TLS/TestJSSE.java test. The test has been observed to fail intermittently with "Unsupported or unrecognized SSL" error. But I couldn't reproduce it manually while running the test in a loop for a couple of days on Linux x64. For now

Re: [9] RFR: 8074580: sun/security/pkcs11/rsa/TestKeyPairGenerator.java fails due to PKCS11Exception: CKR_FUNCTION_FAILED

I forgot to include PKCS11.java to webrev, here is an updated webrev http://cr.openjdk.java.net/~asmotrak/8074580/webrev.01/ Artem On 06/20/2016 11:12 AM, Artem Smotrakov wrote: Hello, Please review the following patch below for 9. TestKeyPairGenerator.java test intermittently fails

[9] RFR: 8074580: sun/security/pkcs11/rsa/TestKeyPairGenerator.java fails due to PKCS11Exception: CKR_FUNCTION_FAILED

Hello, Please review the following patch below for 9. TestKeyPairGenerator.java test intermittently fails with CKR_FUNCTION_FAILED error when NSS crypto libs is used via SunPKCS11 provider. Looks like the root cause is a bug 1012786 in NSS

[9] RFR: 8049314: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "Unexpected EOF" message

Hello, Please review this patch for SSLSocketSSLEngineTemplate.java test. The test fails intermittently with "Unexpected EOF" error. Please see Brad's comment which explains the issue

[9] RFR: 8159501: ShortRSAKey512.java intermittently times out

Hello, Please review the patch below for javax/net/ssl/TLSv12/ShortRSAKey512.java test. The test has been seen to fail intermittently with a time out. I was not able to reproduce this failure. The test fails with "Client died ..." message which occurs in case of exception on client side.

[9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout

Hello, Please review this patch for javax/net/ssl/DTLS tests. A couple of DTLS tests fail intermittently on Mac with timeout or "Too many handshake loops ..." error. The tests use UDP to transfer DTLS records. It happens sometimes that server cannot receive UDP packets with

[9] RFR: 8151734: Mark Unreachable.java and MaxRetries.java as intermittently failing

Hello, The following krb5 tests have been observed to intermittently fail: sun/security/krb5/auto/Unreachable.java sun/security/krb5/auto/MaxRetries.java Please see the following bugs for details: https://bugs.openjdk.java.net/browse/JDK-8087144

Re: RFR 8153545: sun/security/pkcs11/Provider/Login.sh fails on Linux

Hi Max, The policy files already have SecurityPermission "putProviderProperty.*", PKCS11Test class is quite complex. PKCS11Test needs to be run without specifying -Djava.secutity.manager. In PKCS11Test.main(), if args[0] is "sm", then the class enables a security manager right before actual

[9] RFR: 8152798: Mark WeakCipherSuite.java as intermittently failing

Hello, The following DTLS test has been observed to intermittently fail: javax/net/ssl/DTLS/WeakCipherSuite.java Please see https://bugs.openjdk.java.net/browse/JDK-8138877 for details. Until this bug is fixed, the test should be marked accordingly. Please review the patch below which does

[9] RFR: 8157344: Multiple test timeouts after push for JDK-8141039

Hello, Please review this patch for SecureRandom tests which may fail with timeout because SeedGenerator. generateSeed() may block on /dev/random. The tests now use /dev/urandom instead. They also run in othervm mode since "java.security.egd" system property seems to be read once while

Re: [9] RFR: 8129389: javax/net/ssl/DTLS tests fail intermittently

I added more output for debugging intermittent failures in https://bugs.openjdk.java.net/browse/JDK-8132320 I also updated produceHandshakePackets() to handle NEED_UNWRAP_AGAIN. http://cr.openjdk.java.net/~asmotrak/8129389/webrev.01/ Artem On 05/18/2016 08:28 PM, Artem Smotrakov wrote

[9] RFR: 8129389: javax/net/ssl/DTLS tests fail intermittently

Hello, Please review the following patch for DTLS tests. A couple of DTLS tests which are based on DTLSOverDatagram.java fail intermittently. I was not able to reproduce these failures. I am proposing to update the tests to print more information to logs, so that more information will be

Re: Code Review Request JDK-8161106 Improve SSLSocket test template

Hi Xuelei, The webrev looks good to me. Please see inline. On 07/12/2016 10:36 PM, Xuelei Fan wrote: Thanks for the feedback, Artem. Here is the updated webrev per your suggestions: http://cr.openjdk.java.net/~xuelei/8161106/webrev.02/ On 7/13/2016 1:03 AM, Artem Smotrakov wrote: Hi

Re: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method

Hi Svetlana, I'll leave the main review to an official reviewer, but I have a couple of comments. There are a couple of other places in Extension.java where NPE may occur: - line 255: I see that "extensionId" is checked for null in other methods, but not in getId() - line 200: I see that

Re: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout

conditions. Could you please take a look at updated webrev? http://cr.openjdk.java.net/~asmotrak/8159416/webrev.02/ Artem On 06/27/2016 06:25 PM, Xuelei Fan wrote: On 6/28/2016 9:12 AM, Artem Smotrakov wrote: Hello, Please review this patch for javax/net/ssl/DTLS tests. A couple of DTLS

Re: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout

problematic test. Or alternatively, we can ask the JTREG to consider the behavior more about the debug length restrictions. Thanks, Xuelei On 8/2/2016 9:25 AM, Artem Smotrakov wrote: Here is an updated webrev which includes a fix for 8161086 (thanks Xuelei for help): - No updates to the problem l

Re: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout

Please see an updated webrev http://cr.openjdk.java.net/~asmotrak/8159416/webrev.04/ Artem On 08/02/2016 02:42 PM, Artem Smotrakov wrote: Hi Xuelei, Thank you for review. Please see inline. I'll send an updated webrev soon. On 08/01/2016 09:35 PM, Xuelei Fan wrote: DTLSOutputRecord

Re: [9] RFR: 8162484: javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails intermittently with "Address already in use" error

k.java.net/~asmotrak/8162484/webrev.01/ Artem --Jamil On 08/10/2016 03:44 PM, Artem Smotrakov wrote: Hello, Please review this update for OCSP stapling tests. The tests use test/java/security/testlibrary/SimpleOCSPServer.java which try to re-use a server port if the server restarted.

Re: RFR 8163489: Avoid using Utils.getFreePort() in TsacertOptionTest.java test

+1 Minor: no need a semicolon in "try" block, I originally added it by mistake. You also may want to update a copyright year. Artem On 08/09/2016 08:46 AM, Chris Hegarty wrote: On 9 Aug 2016, at 16:37, Weijun Wang wrote:

Re: RFR 8133910: Some sun/security/tools tests failed.

Hi Max, The update looks good to me. Artem On 08/09/2016 08:39 AM, Weijun Wang wrote: I was wrong. The test were written by Artem. --Max On 8/9/2016 15:37, Wang Weijun wrote: Please review the fix at http://cr.openjdk.java.net/~weijun/8133910/webrev.00/ Basically,

Re: [9] RFR: 8162484: javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails intermittently with "Address already in use" error

Thank you for review Jamil. Xuelei, Could you please take a look? Artem On 08/12/2016 02:38 PM, Jamil Nimeh wrote: Thank you Artem. The fix looks good. You just need a +1 from an official reviewer. --Jamil Original message From: Artem Smotrakov <artem.smo

Re: [9] RFR: 8162484: javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails intermittently with "Address already in use" error

, Artem Smotrakov wrote: Hi Jamil, Thank you for review. Please see inline. On 08/10/2016 04:16 PM, Jamil Nimeh wrote: Hi Artem, I'm not an official reviewer but the solution for making the servers reject connections rather than stop and start looks pretty fair to me and seems like a nice way

Re: [9] RFR: 8162484: javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails intermittently with "Address already in use" error

that we can say for all intended uses that we'll *never* need to restart it. That's why I'd like to keep the unbound socket/set sockopt/bind/listen behavior. I don't think ServerSocket(0) achieves that. --Jamil On 8/12/2016 11:30 AM, Artem Smotrakov wrote: Hi Jamil, There was no any specific

[9] RFR: 8162484: javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails intermittently with "Address already in use" error

Hello, Please review this update for OCSP stapling tests. The tests use test/java/security/testlibrary/SimpleOCSPServer.java which try to re-use a server port if the server restarted. Looks like sometimes it may cause "Address already in use" error. The patch updates OCSP stapling tests

Re: RFR 8054536: sun.security.x509.Extension object may throw NPE for hashCode and equals method

licate code. As for unnecessary try-catch in test I'd prefer to have it to emphasis that we are checking for NPE. Okay. I'm not sure about "iff" but let it be, it seems like a right place to use it. Sure. Artem Thank you, Svetlana On 14.07.2016 19:35, Artem Smotrakov wrote: Hi

Re: Code Review Request JDK-8161106 Improve SSLSocket test template

Hi Xuelei, I am not an official reviewer, but I have a couple of comments. 1. line 149: would it be better to check this condition in a loop? 2. Using try-with-resources blocks might simplify doServerSide() a little bit (no need to call close() on sockets, and a couple of "try" blocks might

Re: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout

UDP sockets. If we want to test real connections, then it should be different tests which take into account #1 and #2 above. Artem On 06/27/2016 06:25 PM, Xuelei Fan wrote: On 6/28/2016 9:12 AM, Artem Smotrakov wrote: Hello, Please review this patch for javax/net/ssl/DTLS tests. A couple

Re: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout

is specified - Updated InvalidRecords.java tests not to drop packets by default because handshaking unexpectedly succeeds if an invalid packet was dropped http://cr.openjdk.java.net/~asmotrak/8159416/webrev.03/ Please take a look. Artem On 07/28/2016 04:36 PM, Artem Smotrakov wrote: Hi Xuelei, I

Re: [9] RFR: 8162484: javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails intermittently with "Address already in use" error

to bootup again, is the delay still needed? Otherwise, looks fine to me. Thanks, Xuelei On 8/13/2016 6:25 AM, Artem Smotrakov wrote: Thank you for review Jamil. Xuelei, Could you please take a look? Artem On 08/12/2016 02:38 PM, Jamil Nimeh wrote: Thank you Artem. The fix looks good. You

Re: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java fails

jdk8u-dev. The bug is marked 9-na. The provider loading changes made in this area for 9 mean that it's not affected. Regards, Sean. On 17/08/16 18:10, Artem Smotrakov wrote: Hi Sean, If I remember correctly, there is no ext directory in JDK 9 any more. I don't see in jtr file that &quo

Re: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java fails

Hi Sean, If I remember correctly, there is no ext directory in JDK 9 any more. I don't see in jtr file that "java.ext.dirs" system property is passed to the test. If I understand correctly, "file:${{java.ext.dirs}}/*" becomes "file:/*" which seems to grand all permissions to all the code. It

[9] RFR: 8164100: com/sun/crypto/provider/KeyFactory/TestProviderLeak.java fails with java.util.concurrent.TimeoutException

Hello, Please review the following patch for com/sun/crypto/provider/KeyFactory/TestProviderLeak.java test. This is a request to make the test take into account a test timeout factor. Timeout factor can be specified with "-timeout" jtreg's command line option. This option is used in some

Re: RFR 8172975: SecurityTools.keytool() needs to accept user input

It's up to you. You can change it now if you have time, or we can do it once we need to update jarsigner tests. Artem On 01/20/2017 12:23 PM, Weijun Wang wrote: Also, I am feeling that the jarsigner-related calls are quite complicated. I suggest we use the same method for signing and

Re: RFR 8172975: SecurityTools.keytool() needs to accept user input

Hi Max, In general, looks okay. Would it be better if it called redirectInput() only if the response file exists? keytool() method might also delete the response file after reading it. These two measures may prevent situations when the response file is unnecessary used. What do you think?

Re: RFR 8172975: SecurityTools.keytool() needs to accept user input

Wang wrote: Updated http://cr.openjdk.java.net/~weijun/8172975/root/webrev.01/ http://cr.openjdk.java.net/~weijun/8172975/webrev.01/ I'll need this in my other work. Thanks Max On 01/20/2017 07:23 PM, Artem Smotrakov wrote: It's up to you. You can change it now if you have time, or we can do

  1   2   >