Integrated: 8272908: Missing coverage for certain classes in com.sun.org.apache.xml.internal.security

2021-10-14 Thread Fernando Guallini
On Tue, 12 Oct 2021 17:04:27 GMT, Fernando Guallini wrote: > This patch improves code coverage on the following classes: > - > com.sun.org.apache.xml.internal.security.algorithms.implementations.IntegrityHmac > - com.sun.org.apache.xml.internal.security.utils.

Re: RFR: 8272908: Missing coverage for certain classes in com.sun.org.apache.xml.internal.security [v2]

2021-10-14 Thread Fernando Guallini
On Wed, 13 Oct 2021 16:17:37 GMT, Rajan Halade wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> throw RuntimeException > > test/jdk/com/sun/org/apache/xml/internal/security/Sig

Re: RFR: 8272908: Missing coverage for certain classes in com.sun.org.apache.xml.internal.security [v2]

2021-10-14 Thread Fernando Guallini
; > The new tests exercise code blocks that are not currently covered by other > tests. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: throw RuntimeException - Changes: - all: https://git.openjdk.java.net/jdk

RFR: 8272908: Missing coverage for certain classes in com.sun.org.apache.xml.internal.security

2021-10-12 Thread Fernando Guallini
This patch improves code coverage on the following classes: - com.sun.org.apache.xml.internal.security.algorithms.implementations.IntegrityHmac - com.sun.org.apache.xml.internal.security.utils.ElementProxy - com.sun.org.apache.xml.internal.security.keys.KeyInfo The new tests exercise code blocks

Integrated: 8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is skipped

2021-09-07 Thread Fernando Guallini
On Thu, 2 Sep 2021 13:33:30 GMT, Fernando Guallini wrote: > This trivial change fixes the case 2 in test > sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec, the method > testKeySpec is expecting a class object of type KeySpec as second argument in > order to be reusable

RFR: 8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is skipped

2021-09-02 Thread Fernando Guallini
This trivial change fixes the case 2 in test sun/security/pkcs11/rsa/TestP11KeyFactoryGetRSAKeySpec, the method testKeySpec is expecting a class object of type KeySpec as second argument in order to be reusable for multiple test scenarios, but then instead of using that argument the

Integrated: 8271560: sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java still fails due to "An established connection was aborted by the software in your host machine"

2021-08-30 Thread Fernando Guallini
On Wed, 4 Aug 2021 13:56:17 GMT, Fernando Guallini wrote: > The following test has been seen to fail intermittently on Windows platform: > sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java > with the exception: > java.net.SocketException: An established connection

Re: RFR: 8271560: sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java still fails due to "An established connection was aborted by the software in your host machine" [v2]

2021-08-19 Thread Fernando Guallini
On Wed, 4 Aug 2021 14:16:55 GMT, Fernando Guallini wrote: >> The following test has been seen to fail intermittently on Windows platform: >> sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java >> with the exception: >> java.net.SocketException: An establishe

Re: RFR: 8271560: sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java still fails due to "An established connection was aborted by the software in your host machine" [v2]

2021-08-04 Thread Fernando Guallini
> The test seems to be suffering from some race condition in occasions that > should be handled to avoid instability Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: avoid other types of SSLExceptions -

RFR: 8271560: sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java still fails due to "An established connection was aborted by the software in your host machine"

2021-08-04 Thread Fernando Guallini
The following test has been seen to fail intermittently on Windows platform: sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java with the exception: java.net.SocketException: An established connection was aborted by the software in your host machine The test seems to be suffering from some

Integrated: 8209776: Refactor jdk/security/JavaDotSecurity/ifdefs.sh to plain java test

2021-07-28 Thread Fernando Guallini
On Thu, 15 Jul 2021 11:05:08 GMT, Fernando Guallini wrote: > This change converts security/JavaDotSecurity/ifdefs.sh to java equivalent This pull request has now been integrated. Changeset: 97110337 Author: Fernando Guallini Committer: Rajan Halade URL: ht

RFR: 8209776: Refactor jdk/security/JavaDotSecurity/ifdefs.sh to plain java test

2021-07-15 Thread Fernando Guallini
This change converts security/JavaDotSecurity/ifdefs.sh to java equivalent - Commit messages: - refactored to java Changes: https://git.openjdk.java.net/jdk/pull/4791/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4791=00 Issue:

RFR: 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification of protocol and cipher support

2021-07-07 Thread Fernando Guallini
test/jdk/javax/net/ssl/compatibility/JdkInfo is a helper class for the compatibility tests. It is verifying whether a protocol or cipher suite is supported/enabled by setting all the allowed values as a string, and then invoking String contains() to return whether a specific version is

[jdk17] Integrated: 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset"

2021-06-17 Thread Fernando Guallini
On Wed, 16 Jun 2021 14:24:31 GMT, Fernando Guallini wrote: > The following test: javax/net/ssl/SSLSession/TestEnabledProtocols.java, is > failing intermittently because the client side is expecting a SocketException > only if it is wrapped into a SSLException, but it should al

[jdk17] RFR: 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset"

2021-06-16 Thread Fernando Guallini
The following test: javax/net/ssl/SSLSession/TestEnabledProtocols.java, is failing intermittently because the client side is expecting a SocketException only if it is wrapped into a SSLException, but it should also expect a SocketException when there is no exception chaining. -

Integrated: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception"

2021-06-03 Thread Fernando Guallini
On Wed, 2 Jun 2021 14:03:57 GMT, Fernando Guallini wrote: > The test `SSLSocketImplThrowsWrongExceptions` is failing intermittently after > the change: [JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in > SSLSocketImpl](https://bugs.openjdk.java.net/browse/JDK-8259662) &

Re: RFR: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception"

2021-06-02 Thread Fernando Guallini
On Wed, 2 Jun 2021 17:29:51 GMT, Clive Verghese wrote: > Thank you @fguallini for fixing this test. > > Should the SocketException be expected by the client logic as well? >

RFR: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception"

2021-06-02 Thread Fernando Guallini
The test `SSLSocketImplThrowsWrongExceptions` is failing intermittently after the change: [JDK-8259662: Don't wrap SocketExceptions into SSLExceptions in SSLSocketImpl](https://bugs.openjdk.java.net/browse/JDK-8259662) Since SocketExceptions are not wrapped into SSLException, also need to be

Integrated: 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures

2021-06-01 Thread Fernando Guallini
On Tue, 18 May 2021 13:19:53 GMT, Fernando Guallini wrote: > Refactor the following shell tests to Java: > - security/pkcs11/KeyStore/Basic.sh > - security/pkcs11/KeyStore/ClientAuth.sh > - security/pkcs11/KeyStore/SecretKeysBasic.sh > - security/pkcs11/Provider/Config

Re: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures [v2]

2021-06-01 Thread Fernando Guallini
On Fri, 28 May 2021 15:50:23 GMT, Fernando Guallini wrote: >> Refactor the following shell tests to Java: >> - security/pkcs11/KeyStore/Basic.sh >> - security/pkcs11/KeyStore/ClientAuth.sh >> - security/pkcs11/KeyStore/SecretKeysBasic.sh >> - security/pkcs11/

Re: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures [v2]

2021-05-28 Thread Fernando Guallini
one has expired. > > - Basic: Remove redundant X509Certificate casting > > - SecretKeysBasic: it was already in the problem list since it reproduces the > open bug JDK-8209398 and fails. Test is refactored to java and still > reproduces the issue. > > All the mentioned tests

Re: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures

2021-05-27 Thread Fernando Guallini
On Thu, 27 May 2021 09:55:10 GMT, Sibabrata Sahoo wrote: >> Refactor the following shell tests to Java: >> - security/pkcs11/KeyStore/Basic.sh >> - security/pkcs11/KeyStore/ClientAuth.sh >> - security/pkcs11/KeyStore/SecretKeysBasic.sh >> - security/pkcs11/Provider/ConfigQuotedString.sh >> -

Re: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures

2021-05-26 Thread Fernando Guallini
On Tue, 18 May 2021 13:19:53 GMT, Fernando Guallini wrote: > Refactor the following shell tests to Java: > - security/pkcs11/KeyStore/Basic.sh > - security/pkcs11/KeyStore/ClientAuth.sh > - security/pkcs11/KeyStore/SecretKeysBasic.sh > - security/pkcs11/Provider/Config

RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain java tests and fix failures

2021-05-18 Thread Fernando Guallini
Refactor the following shell tests to Java: - security/pkcs11/KeyStore/Basic.sh - security/pkcs11/KeyStore/ClientAuth.sh - security/pkcs11/KeyStore/SecretKeysBasic.sh - security/pkcs11/Provider/ConfigQuotedString.sh - security/pkcs11/Provider/Login.sh - security/pkcs11/Config/ReadConfInUTF16Env.sh

Integrated: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption

2021-05-13 Thread Fernando Guallini
On Tue, 4 May 2021 15:12:39 GMT, Fernando Guallini wrote: > test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior > when a server closes the socket connection during a handshake. The server was > waiting a fixed 100ms before closing it, but there was no

Re: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v2]

2021-05-13 Thread Fernando Guallini
On Mon, 10 May 2021 11:00:34 GMT, Julia Boes wrote: > @fguallini I'm happy to sponsor this change once it's been reviewed by > someone from security. Thank you for sponsoring!. Rajan has reviewed the PR, it should be ready for integration. - PR:

Re: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v3]

2021-05-11 Thread Fernando Guallini
ng that time frame > > With this changeset, the server is checking whether the client thread has > initiated handshake, and retrying if needed after waiting a short time. In > addition, the test is now reusing SSLSocketTemplate to simplify sockets > configuration and client/serve

Re: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v3]

2021-05-11 Thread Fernando Guallini
On Mon, 10 May 2021 15:40:49 GMT, Rajan Halade wrote: >> OK > > Can you please add this as a comment in a test file for clientThread > variable? I am sure we will have (failed) try to convert it to CountDownLatch > in future. @rhalade sure comment included - PR:

Re: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v2]

2021-05-05 Thread Fernando Guallini
On Tue, 4 May 2021 16:07:42 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> var volatile > > test/jdk/sun/security/ssl/SSLSocketImpl/CloseSocket.java l

Re: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v2]

2021-05-05 Thread Fernando Guallini
ng that time frame > > With this changeset, the server is checking whether the client thread has > initiated handshake, and retrying if needed after waiting a short time. In > addition, the test is now reusing SSLSocketTemplate to simplify sockets > configuration and client/serve

RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption

2021-05-04 Thread Fernando Guallini
test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior when a server closes the socket connection during a handshake. The server was waiting a fixed 100ms before closing it, but there was no guarantee that the client started the handshake before or during that time frame

Integrated: 8228442: DHKeyExchange/LegacyDHEKeyExchange.java failed due to "SSLException: An established connection was aborted by the software in your host machine"

2021-04-28 Thread Fernando Guallini
On Thu, 22 Apr 2021 11:41:40 GMT, Fernando Guallini wrote: > Test DHKeyExchange/LegacyDHEKeyExchange.java has been seen to fail > intermittently. There is a thread synchronisation issue that is fixed by: > > - Using SSLSocketTemplate that handles client/server socket c

RFR: 8228442: DHKeyExchange/LegacyDHEKeyExchange.java failed due to "SSLException: An established connection was aborted by the software in your host machine"

2021-04-22 Thread Fernando Guallini
Test DHKeyExchange/LegacyDHEKeyExchange.java has been seen to fail intermittently. There is a thread synchronisation issue that is fixed by: - Using SSLSocketTemplate that handles client/server socket configuration and synchronisation before connection - Making use of a CountDownLatch and

Integrated: 8264152: javax/net/ssl/DTLS/RespondToRetransmit.java timed out

2021-04-16 Thread Fernando Guallini
On Tue, 13 Apr 2021 13:19:17 GMT, Fernando Guallini wrote: > test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java has been seen to fail > intermittently. > The server side is binding to the wildcard/localhost address which has been a > source of instability in many tests. Binding

RFR: 8264152: javax/net/ssl/DTLS/RespondToRetransmit.java timed out

2021-04-13 Thread Fernando Guallini
test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java has been seen to fail intermittently. The server side is binding to the wildcard/localhost address which has been a source of instability in many tests. Binding to loopback address fixes the intermittent failures. In addition, other changes

Integrated: 8264190: Harden TLS interop tests

2021-04-12 Thread Fernando Guallini
On Fri, 26 Mar 2021 15:31:43 GMT, Fernando Guallini wrote: > Occasional interop tests failures may occur when making use of the > test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no > assurance the selected available port it is still free at the time a server

Re: RFR: 8264190: Harden TLS interop tests [v3]

2021-03-31 Thread Fernando Guallini
On Mon, 29 Mar 2021 18:45:47 GMT, Rajan Halade wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Improve JdkServer::close and Utilities::waitFor methods > > test/jdk/j

Re: RFR: 8264190: Harden TLS interop tests [v4]

2021-03-31 Thread Fernando Guallini
d second session creation time to validate session > resumption Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: add max_retries count, move shell methods to ProcUtils and add win methods - Changes: - all: https://g

Re: RFR: 8264190: Harden TLS interop tests [v3]

2021-03-29 Thread Fernando Guallini
On Mon, 29 Mar 2021 17:31:59 GMT, Fernando Guallini wrote: >> Occasional interop tests failures may occur when making use of the >> test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no >> assurance the selected available port it is still free at the time

Re: RFR: 8264190: Harden TLS interop tests [v3]

2021-03-29 Thread Fernando Guallini
d second session creation time to validate session > resumption Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: Improve JdkServer::close and Utilities::waitFor methods - Changes: - all: https://git.openjdk.jav

Re: RFR: 8264190: Harden TLS interop tests [v2]

2021-03-26 Thread Fernando Guallini
d second session creation time to validate session > resumption Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: no need to check if alive while iterating during accept - Changes: - all: https://git.openjdk.jav

RFR: 8264190: Harden TLS interop tests

2021-03-26 Thread Fernando Guallini
Occasional interop tests failures may occur when making use of the test/jdk/javax/net/ssl/TLSCommon/interop framework since there is no assurance the selected available port it is still free at the time a server using the framework starts up, for instance, by command line. To mitigate

Integrated: 8262862: Harden tests sun/security/x509/URICertStore/ExtensionsWithLDAP.java and krb5/canonicalize/Test.java

2021-03-05 Thread Fernando Guallini
On Wed, 3 Mar 2021 12:23:00 GMT, Fernando Guallini wrote: > Certain JVM tools may access and initialise InetAddress class and its static > fields during start up resulting in a NameService implementation being > already set to the default **PlatformNameService**, causing int

Re: RFR: 8262862: Harden tests sun/security/x509/URICertStore/ExtensionsWithLDAP.java and krb5/canonicalize/Test.java [v2]

2021-03-04 Thread Fernando Guallini
at a > [NameService](https://github.com/openjdk/jdk/blob/382e38dd246596ec94a1f1ce0e0f9e87f53366c7/src/java.base/share/classes/java/net/InetAddress.java#L1155) > is created Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8262862: Harden tests sun/security/x509/URICertStore/ExtensionsWithLDAP.java and krb5/canonicalize/Test.java [v2]

2021-03-04 Thread Fernando Guallini
On Thu, 4 Mar 2021 13:42:57 GMT, Aleksei Efimov wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> move set env properties to header > > test/jdk/sun/security/krb5/canonicali

Integrated: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3

2021-02-24 Thread Fernando Guallini
On Mon, 22 Feb 2021 16:39:56 GMT, Fernando Guallini wrote: > Kerberos new replay cache format released in 1.18 (installed in OL8.3) is > causing the tests failures: > `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html` > > New and old format are

Re: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v2]

2021-02-24 Thread Fernando Guallini
On Tue, 23 Feb 2021 22:43:09 GMT, Rajan Halade wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> remove native lib test with MD5 > > test/jdk/sun/security/krb5/auto/ReplayCacheTes

Re: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v3]

2021-02-24 Thread Fernando Guallini
a own > implementation API only. > > If there is a decision to support the new format in the future, tests will be > revisited accordingly. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: add comment when scen

Re: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v2]

2021-02-23 Thread Fernando Guallini
a own > implementation API only. > > If there is a decision to support the new format in the future, tests will be > revisited accordingly. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: remove native lib test wi

Re: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v2]

2021-02-23 Thread Fernando Guallini
On Tue, 23 Feb 2021 18:13:24 GMT, Weijun Wang wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> remove native lib test with MD5 > > test/jdk/sun/security/krb5/auto/ReplayCac

RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3

2021-02-22 Thread Fernando Guallini
Kerberos new replay cache format released in 1.18 (installed in OL8.3) is causing the tests failures: `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html` New and old format are not compatible, that means they cannot share a rcache file. Since there is no

Integrated: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset

2021-02-16 Thread Fernando Guallini
On Thu, 4 Feb 2021 13:00:47 GMT, Fernando Guallini wrote: > The server side is binding to the wildcard address which has been a source of > instability in many networking tests due to javax.net.ssl.SSLException: > Connection reset. Changing the following tests to bind to loopbac

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v4]

2021-02-11 Thread Fernando Guallini
On Thu, 11 Feb 2021 12:17:41 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> check exception type > > test/jdk/javax/net/ssl/SSLSession/TestEnabledProt

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v5]

2021-02-11 Thread Fernando Guallini
fore the client > is done during handshake. That race condition cannot be completely removed in > this test, thus is now handled and logged. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: refactor isConnectionReset method

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v3]

2021-02-11 Thread Fernando Guallini
On Wed, 10 Feb 2021 12:24:15 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> narrow down connection reset handling > > test/jdk/javax/net/ssl/SSLSession/Test

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v4]

2021-02-11 Thread Fernando Guallini
fore the client > is done during handshake. That race condition cannot be completely removed in > this test, thus is now handled and logged. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: check exception type

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v3]

2021-02-05 Thread Fernando Guallini
On Fri, 5 Feb 2021 17:45:45 GMT, Rajan Halade wrote: >> test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 145: >> >>> 143: // The server side may have closed the socket. >>> 144: System.out.println("Client SSLException:"); >>> 145:

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v3]

2021-02-05 Thread Fernando Guallini
fore the client > is done during handshake. That race condition cannot be completely removed in > this test, thus is now handled and logged. Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: narrow down connection reset ha

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v2]

2021-02-05 Thread Fernando Guallini
On Thu, 4 Feb 2021 15:11:39 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Merge branch '8241372' of github.com:fguallini/jdk into 8241372 >> - remove not

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v2]

2021-02-05 Thread Fernando Guallini
fore the client > is done during handshake. That race condition cannot be completely removed in > this test, thus is now handled and logged. Fernando Guallini has updated the pull request incrementally with two additional commits since the last revision: - Merge branch '8241372' of github.c

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v2]

2021-02-05 Thread Fernando Guallini
On Thu, 4 Feb 2021 14:50:24 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Merge branch '8241372' of github.com:fguallini/jdk into 8241372 >> - remove not

Integrated: 8163498: Many long-running security libs tests

2021-02-04 Thread Fernando Guallini
On Wed, 3 Feb 2021 13:29:54 GMT, Fernando Guallini wrote: > The following tests have been split based on lower/higher key sizes in order > to reduce individual execution time and run in parallel with jtreg > sun/security/provider/DSA/SupportedDSAParamGen.java > sun/security/provid

Re: RFR: 8163498: Many long-running security libs tests [v4]

2021-02-04 Thread Fernando Guallini
xponent. > That redundancy is removed. This speeds up the execution from ~54s to ~25s on > average Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: add short description regarding test split. - Changes: - all: http

Re: RFR: 8163498: Many long-running security libs tests [v3]

2021-02-04 Thread Fernando Guallini
On Wed, 3 Feb 2021 22:30:02 GMT, Weijun Wang wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> add key itself to signature verification > > test/jdk/s

RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset

2021-02-04 Thread Fernando Guallini
The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures:

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset

2021-02-04 Thread Fernando Guallini
On Thu, 4 Feb 2021 13:00:47 GMT, Fernando Guallini wrote: > The server side is binding to the wildcard address which has been a source of > instability in many networking tests due to javax.net.ssl.SSLException: > Connection reset. Changing the following tests to bind to loopbac

Re: RFR: 8163498: Many long-running security libs tests [v3]

2021-02-03 Thread Fernando Guallini
xponent. > That redundancy is removed. This speeds up the execution from ~54s to ~25s on > average Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: add key itself to signature verification - Changes: - all: http

Re: RFR: 8163498: Many long-running security libs tests [v2]

2021-02-03 Thread Fernando Guallini
On Wed, 3 Feb 2021 19:50:02 GMT, Weijun Wang wrote: >> That is right, PSSKeyCompatibility already explicitly proves they both are >> equal and there are other tests that generates both manually and using >> KeyFactory. In addition, this test focuses on signature verification rather >> than

Re: RFR: 8163498: Many long-running security libs tests [v2]

2021-02-03 Thread Fernando Guallini
xponent. > That redundancy is removed. This speeds up the execution from ~54s to ~25s on > average Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: prove factory key spec and manual instantiated key spec are equal -

Re: RFR: 8163498: Many long-running security libs tests

2021-02-03 Thread Fernando Guallini
On Wed, 3 Feb 2021 15:06:37 GMT, Weijun Wang wrote: >> The following tests have been split based on lower/higher key sizes in order >> to reduce individual execution time and run in parallel with jtreg >> sun/security/provider/DSA/SupportedDSAParamGen.java >>

RFR: 8163498: Many long-running security libs tests

2021-02-03 Thread Fernando Guallini
The following tests have been split based on lower/higher key sizes in order to reduce individual execution time and run in parallel with jtreg sun/security/provider/DSA/SupportedDSAParamGen.java sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java

Integrated: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails

2021-01-26 Thread Fernando Guallini
On Mon, 25 Jan 2021 17:08:45 GMT, Fernando Guallini wrote: > Fixing manual Test > "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java". > It was not handling "weak algorithm" warning during jarsigner output > verification This pull

Re: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails [v2]

2021-01-26 Thread Fernando Guallini
On Mon, 25 Jan 2021 22:57:04 GMT, Hai-May Chao wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> add bugid and missing space > > Change copyright year to 2021 Thanks for the re

Re: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails [v2]

2021-01-26 Thread Fernando Guallini
> Fixing manual Test > "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java". > It was not handling "weak algorithm" warning during jarsigner output > verification Fernando Guallini has updated the pull request incrementally with one

RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails

2021-01-25 Thread Fernando Guallini
Fixing manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java". It was not handling "weak algorithm" warning during jarsigner output verification - Commit messages: - rename method - handle warning for SHA-1 weak algorithm Changes:

Withdrawn: 8244411: javax/net/ssl/TLSCommon/CipherSuite.java should cover DTLS protocols

2021-01-21 Thread Fernando Guallini
On Thu, 21 Jan 2021 11:15:20 GMT, Fernando Guallini wrote: > test/jdk/javax/net/ssl/TLSCommon/CipherSuite.java only indicates which TLS > protocols support a cipher suite. > It should also indicate which DTLS protocols support a cipher suite. This pull request has been closed with

RFR: 8244411: javax/net/ssl/TLSCommon/CipherSuite.java should cover DTLS protocols

2021-01-21 Thread Fernando Guallini
test/jdk/javax/net/ssl/TLSCommon/CipherSuite.java only indicates which TLS protocols support a cipher suite. It should also indicate which DTLS protocols support a cipher suite. - Commit messages: - remove not used protocols - rename vars - Merge branch 'master' into 8244411 -

Integrated: 8255546: Missing coverage for javax.smartcardio.CardPermission and ResponseAPDU

2020-11-12 Thread Fernando Guallini
On Fri, 6 Nov 2020 12:04:20 GMT, Fernando Guallini wrote: > This patch is to add code coverage to the following methods > - javax.smartcardio.CardPermission::**implies** (1) > - javax.smartcardio.ResponseAPDU::**toString** (2) > > Tests are added following the expected imple

Re: RFR: 8255546: Missing coverage for javax.smartcardio.CardPermission and ResponseAPDU

2020-11-09 Thread Fernando Guallini
On Fri, 6 Nov 2020 12:04:20 GMT, Fernando Guallini wrote: > This patch is to add code coverage to the following methods > - javax.smartcardio.CardPermission::**implies** (1) > - javax.smartcardio.ResponseAPDU::**toString** (2) > > Tests are added following the expected imple

RFR: 8255546: Missing coverage for javax.smartcardio.CardPermission and ResponseAPDU

2020-11-06 Thread Fernando Guallini
This patch is to add code coverage to the following methods - javax.smartcardio.CardPermission::**implies** (1) - javax.smartcardio.ResponseAPDU::**toString** (2) Tests are added following the expected implementation given in the methods specifications (1)