Re: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always returns 'true' [v4]
On Fri, 10 Jun 2022 21:41:50 GMT, Hai-May Chao wrote: >> Please review a small fix in CryptoPolicyParser class that it should not >> pass “processedPermissions” parameter by value. >> Ran MACH5 tier1 and tier2 without failures. > > Hai-May Chao has updated the pull request incrementally with one additional > commit since the last revision: > > Manual test instr using System.out Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.org/jdk/pull/8985
Re: RFR: 8286779: javax.crypto.CryptoPolicyParser#isConsistent always returns 'true' [v3]
On Fri, 10 Jun 2022 16:19:05 GMT, Hai-May Chao wrote: >> Please review a small fix in CryptoPolicyParser class that it should not >> pass “processedPermissions” parameter by value. >> Ran MACH5 tier1 and tier2 without failures. > > Hai-May Chao has updated the pull request incrementally with one additional > commit since the last revision: > > Fixed copyright test/jdk/javax/crypto/CryptoPermissions/InconsistentEntries.java line 38: > 36: import java.security.Security; > 37: > 38: // This is a manual test to test a custom “default_local.policy" > containing inconsistent entries Thanks for the instructions. For manual test, I would rather have these as a System.out on test start than a comment here. This helps engineers who look at jtr file for failure analysis as they generally won't refer test source code to understand missing steps. - PR: https://git.openjdk.org/jdk/pull/8985
Integrated: 8224768: Test ActalisCA.java fails
On Thu, 9 Jun 2022 00:33:27 GMT, Rajan Halade wrote: > Updated with new test artifacts from CA. This pull request has now been integrated. Changeset: c6dd2ab9 Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/c6dd2ab9d72298b1e25ee811b1e200f6a0fdc933 Stats: 198 lines in 2 files changed: 8 ins; 38 del; 152 mod 8224768: Test ActalisCA.java fails Reviewed-by: mullan - PR: https://git.openjdk.org/jdk/pull/9097
Re: RFR: 8224768: Test ActalisCA.java fails [v2]
> Updated with new test artifacts from CA. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: Adjust hard wrap to 90 chars - Changes: - all: https://git.openjdk.org/jdk/pull/9097/files - new: https://git.openjdk.org/jdk/pull/9097/files/d800a30d..5bb68432 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=9097=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9097=00-01 Stats: 18 lines in 1 file changed: 0 ins; 3 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/9097.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9097/head:pull/9097 PR: https://git.openjdk.org/jdk/pull/9097
Integrated: 8288132: Update test artifacts in QuoVadis CA interop tests
On Thu, 9 Jun 2022 17:31:29 GMT, Rajan Halade wrote: > Updated test artifacts. Test will continue to fail intermittently with what > appears to be issue in CA infra. JDK-8277855 will track it. This pull request has now been integrated. Changeset: 3ee1e605 Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/3ee1e60595171be0dd8bda47d96e0a1268cdc461 Stats: 191 lines in 1 file changed: 21 ins; 0 del; 170 mod 8288132: Update test artifacts in QuoVadis CA interop tests Reviewed-by: mullan - PR: https://git.openjdk.org/jdk/pull/9110
Re: RFR: 8288132: Update test artifacts in QuoVadis CA interop tests [v2]
> Updated test artifacts. Test will continue to fail intermittently with what > appears to be issue in CA infra. JDK-8277855 will track it. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: Adjust hard wrap to 90 chars - Changes: - all: https://git.openjdk.org/jdk/pull/9110/files - new: https://git.openjdk.org/jdk/pull/9110/files/c21d7fb2..74159299 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=9110=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9110=00-01 Stats: 42 lines in 1 file changed: 0 ins; 15 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/9110.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9110/head:pull/9110 PR: https://git.openjdk.org/jdk/pull/9110
Integrated: 8271838: AmazonCA.java interop test fails
On Thu, 9 Jun 2022 18:59:36 GMT, Rajan Halade wrote: > Updated test certificates to new from CA. I did a loop run of this test and > don't see the intermittent failure anymore. This pull request has now been integrated. Changeset: 512db0ff Author: Rajan Halade URL: https://git.openjdk.org/jdk/commit/512db0ff31a0a1a2bd8805964ba3d06e2cbfb9e9 Stats: 245 lines in 1 file changed: 0 ins; 51 del; 194 mod 8271838: AmazonCA.java interop test fails Reviewed-by: mullan - PR: https://git.openjdk.org/jdk/pull/9111
Re: RFR: 8271838: AmazonCA.java interop test fails [v2]
> Updated test certificates to new from CA. I did a loop run of this test and > don't see the intermittent failure anymore. Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: adjust hard wrap to 90 chars - Changes: - all: https://git.openjdk.org/jdk/pull/9111/files - new: https://git.openjdk.org/jdk/pull/9111/files/4a248529..592679bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=9111=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9111=00-01 Stats: 16 lines in 1 file changed: 0 ins; 8 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9111.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9111/head:pull/9111 PR: https://git.openjdk.org/jdk/pull/9111
RFR: 8271838: AmazonCA.java interop test fails
Updated test certificates to new from CA. I did a loop run of this test and don't see the intermittent failure anymore. - Commit messages: - 8271838: AmazonCA.java interop test fails Changes: https://git.openjdk.org/jdk/pull/9111/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9111=00 Issue: https://bugs.openjdk.org/browse/JDK-8271838 Stats: 252 lines in 1 file changed: 7 ins; 50 del; 195 mod Patch: https://git.openjdk.org/jdk/pull/9111.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9111/head:pull/9111 PR: https://git.openjdk.org/jdk/pull/9111
RFR: 8288132: Update test artifacts in QuoVadis CA interop tests
Updated test artifacts. Test will continue to fail intermittently with what appears to be issue in CA infra. JDK-8277855 will track it. - Commit messages: - 8288132: Update test artifacts in QuoVadis CA interop tests Changes: https://git.openjdk.org/jdk/pull/9110/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9110=00 Issue: https://bugs.openjdk.org/browse/JDK-8288132 Stats: 215 lines in 1 file changed: 36 ins; 0 del; 179 mod Patch: https://git.openjdk.org/jdk/pull/9110.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9110/head:pull/9110 PR: https://git.openjdk.org/jdk/pull/9110
RFR: 8224768: Test ActalisCA.java fails
Updated with new test artifacts from CA. - Commit messages: - 8224768: Test ActalisCA.java fails Changes: https://git.openjdk.java.net/jdk/pull/9097/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9097=00 Issue: https://bugs.openjdk.org/browse/JDK-8224768 Stats: 199 lines in 2 files changed: 9 ins; 36 del; 154 mod Patch: https://git.openjdk.java.net/jdk/pull/9097.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9097/head:pull/9097 PR: https://git.openjdk.java.net/jdk/pull/9097
Integrated: 8287109: Distrust.java failed with CertificateExpiredException
On Mon, 23 May 2022 20:14:37 GMT, Rajan Halade wrote: > Incorporated patch from my @seanjmullan and removed expired root chains. This pull request has now been integrated. Changeset: 5b7d066c Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/5b7d066ca5cb68e07a704d3ce13283761c1cf3ad Stats: 173 lines in 4 files changed: 21 ins; 149 del; 3 mod 8287109: Distrust.java failed with CertificateExpiredException Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/8856
RFR: 8287109: Distrust.java failed with CertificateExpiredException
Incorporated patch from my @seanjmullan and removed expired root chains. - Commit messages: - Reformat code - Update ProblemList - 8287109: Distrust.java failed with CertificateExpiredException Changes: https://git.openjdk.java.net/jdk/pull/8856/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8856=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287109 Stats: 173 lines in 4 files changed: 21 ins; 149 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8856/head:pull/8856 PR: https://git.openjdk.java.net/jdk/pull/8856
Integrated: 8287119: Add Distrust.java to ProblemList
On Sat, 21 May 2022 00:26:10 GMT, Rajan Halade wrote: > It will take me some time to figure out what to do with expired certificates. > We can either remove those test scenarios, perform backdated validation or > allow those expired scenarios to be treated as pass. This pull request has now been integrated. Changeset: da8fd454 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/da8fd4547f27cea8d940df5c99dd99503617bf4e Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8287119: Add Distrust.java to ProblemList Reviewed-by: wetmore - PR: https://git.openjdk.java.net/jdk/pull/8823
RFR: 8287119: Add Distrust.java to ProblemList
It will take me some time to figure out what to do with expired certificates. We can either remove those test scenarios, perform backdated validation or allow those expired scenarios to be treated as pass. - Commit messages: - 8287119: Add Distrust.java to ProblemList Changes: https://git.openjdk.java.net/jdk/pull/8823/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8823=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287119 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8823.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8823/head:pull/8823 PR: https://git.openjdk.java.net/jdk/pull/8823
Re: RFR: 8286969: Add a new test library API to execute kinit in SecurityTools.java
On Wed, 18 May 2022 16:19:40 GMT, Sibabrata Sahoo wrote: > A new API to execute kinit. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8775
Re: RFR: 8285493: ECC calculation error
On Tue, 26 Apr 2022 21:02:49 GMT, Weijun Wang wrote: > Only numbers from the same modular fields can be involved in arithmetic > calculations. Add `assert` to guarantee this. > > Also, found one broken case and rewrote it. Please update bug with applicable noreg label. - PR: https://git.openjdk.java.net/jdk/pull/8409
Re: RFR: 8281717: Cover logout method for several LoginModule [v3]
On Tue, 29 Mar 2022 06:24:16 GMT, Sibabrata Sahoo wrote: >> Added coverage to logout method. > > Sibabrata Sahoo has updated the pull request incrementally with one > additional commit since the last revision: > > Update AllPlatforms.java > > Updated exception handling to ignore the case where the running platform > doesn't match the test case. In that case required native library loading > will fail. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7940
Re: RFR: 8281717: Cover logout method for several LoginModule [v3]
On Mon, 28 Mar 2022 06:58:29 GMT, Sibabrata Sahoo wrote:
>> test/jdk/com/sun/security/auth/module/AllPlatforms.java line 45:
>>
>>> 43: UNIX_MODULE, "optional",
>>> 44: NT_MODULE, "optional");
>>> 45: login(OS.replaceAll("[^a-zA-Z0-9]", ""),
>>> getPlatformLoginModule(), "required");
>>
>> I think test should still be run on all platforms even though login would
>> fail. On other platforms than the test being run on, test shouldn't fail
>> with "UnsatisfiedLinkError" as per JDK-8039951.
>
> Now it will run in all platform other than the running one and the expected
> failure is LoginException. So any other types of Exception will be treated as
> failure including UnsatisfiedLinkError.
thanks for addressing it!
-
PR: https://git.openjdk.java.net/jdk/pull/7940
Re: RFR: 8281717: Cover logout method for several LoginModule
On Thu, 24 Mar 2022 10:41:18 GMT, Sibabrata Sahoo wrote:
> Added coverage to logout method.
test/jdk/com/sun/security/auth/module/AllPlatforms.java line 26:
> 24: /*
> 25: * @test
> 26: * @bug 8039951 8281717
No need to add bug id here as this is not a product change.
test/jdk/com/sun/security/auth/module/AllPlatforms.java line 44:
> 42: try {
> 43: login("windows", "NTLoginModule", "required");
> 44: login("unix", "UnixLoginModule", "required");
thanks for fixing this code. Test earlier skipped UnixLoginModule early on
"nix" platform as windows login would fail.
test/jdk/com/sun/security/auth/module/AllPlatforms.java line 45:
> 43: UNIX_MODULE, "optional",
> 44: NT_MODULE, "optional");
> 45: login(OS.replaceAll("[^a-zA-Z0-9]", ""),
> getPlatformLoginModule(), "required");
I think test should still be run on all platforms even though login would fail.
On other platforms than the test being run on, test shouldn't fail with
"UnsatisfiedLinkError" as per JDK-8039951.
-
PR: https://git.openjdk.java.net/jdk/pull/7940
Re: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368
On Tue, 22 Mar 2022 00:26:01 GMT, Bradford Wetmore wrote: >> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java >> line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights >>> reserved. >> >> should this be updated to only list 2022? > > In previous days, we used to include the dates from the templates, which this > test was derived from. I could go either way. I am not knowledgable one in this area and thought was merely a typo. Fine either way. - PR: https://git.openjdk.java.net/jdk/pull/7796
Re: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368
On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote: > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal > internal_error (80) and invalidate existing sessions (either completed or > under construction) as described in (RFC 4346/TLSv1.1+) if a connection was > closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the > SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their > respective sessions. > > Tier1/2 mach5 tests have been successfully run. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7796
Re: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive [v3]
On Tue, 22 Mar 2022 07:51:18 GMT, Sibabrata Sahoo wrote: >> Domain value for system property jdk.https.negotiate.cbt is >> case-insensitive now. Included Test has been updated to address the change. > > Sibabrata Sahoo has updated the pull request incrementally with one > additional commit since the last revision: > > Update AbstractDelegateHttpsURLConnection.java Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7759
Re: RFR: 8273553: sun.security.ssl.SSLEngineImpl.closeInbound also has similar error of JDK-8253368
On Sat, 12 Mar 2022 00:55:07 GMT, Bradford Wetmore wrote: > JDK-8253368 changed the behavior of SSLSocket to no longer throw a fatal > internal_error (80) and invalidate existing sessions (either completed or > under construction) as described in (RFC 4346/TLSv1.1+) if a connection was > closed without receiving a close_notify alert from the peer. > > This change introduces similar behavior to SSLEngine. > > The unit test checks that closing the read(input) sides of the > SSLSocket/SSLEngine throws an SSLException, but doesn't invalidate their > respective sessions. > > Tier1/2 mach5 tests have been successfully run. test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketSSLEngineCloseInbound.java line 2: > 1: /* > 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights > reserved. should this be updated to only list 2022? - PR: https://git.openjdk.java.net/jdk/pull/7796
Integrated: 8282832: Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh
On Tue, 8 Mar 2022 20:25:12 GMT, Rajan Halade wrote: > …ecurity/util/Pem/encoding.sh This pull request has now been integrated. Changeset: ea19114e Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/ea19114e66326e4be7b4b9995888ad2ead3d37dc Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8282832: Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/7749
Integrated: 8282832: Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh
…ecurity/util/Pem/encoding.sh - Commit messages: - Update copyright year - 8282832: Update file path for HostnameMatcher/cert5.crt in test sun/security/util/Pem/encoding.sh Changes: https://git.openjdk.java.net/jdk/pull/7749/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7749=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282832 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7749.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7749/head:pull/7749 PR: https://git.openjdk.java.net/jdk/pull/7749
Re: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 [v2]
On Tue, 8 Mar 2022 12:56:50 GMT, Sean Mullan wrote:
>> test/jdk/sun/security/util/HostnameChecker/Wildcard.java line 72:
>>
>>> 70: } catch (Exception e) {
>>> 71: if (expected) {
>>> 72: throw new Exception("unexpectedly failed match", e);
>>
>> consider to update these to RuntimeException
>
> What are the benefits of throwing `RuntimeException` instead of `Exception`?
> In the latest commit, I have merged the `Wildcard.java` test into
> `TestHostnameChecker.java` test which already throws `Exception` on failures.
It's not essential. RuntimeException is a convenient choice since it's
unchecked, so you don't have to sprinkle your code with throws clauses.
https://openjdk.java.net/jtreg/faq.html#if-a-test-fails-do-i-have-to-throw-my-own-exception
-
PR: https://git.openjdk.java.net/jdk/pull/7697
Re: RFR: 7192189: Support endpoint identification algorithm in RFC 6125 [v2]
On Tue, 8 Mar 2022 13:00:50 GMT, Sean Mullan wrote: >> Please review this change to fully support RFC 6125 in the TLS >> implementation. This change forbids wildcard domains in TLS certificates >> unless the wildcard is in the left-most component. Certificates of this >> nature should be rare and are not allowed per the CABForum baseline >> requirements. However there may be a small compatibility risk associated >> with this change, so a CSR has also been filed. > > Sean Mullan has updated the pull request incrementally with one additional > commit since the last revision: > > Merge Wildcard test into TestHostnameCheck. > Rename HostnameMatcher dir to HostnameChecker. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7697
Re: RFR: 8282632: Cleanup unnecessary calls to Throwable.initCause() in java.security.jgss [v2]
On Sat, 5 Mar 2022 06:49:43 GMT, Andrey Turbanov wrote: >> Pass cause exception as constructor parameter is shorter and easier to read. > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8282632: Cleanup unnecessary calls to Throwable.initCause() in > java.security.jgss > typo Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7682
Re: RFR: 7192189: Support endpoint identification algorithm in RFC 6125
On Fri, 4 Mar 2022 14:59:54 GMT, Sean Mullan wrote:
> Please review this change to fully support RFC 6125 in the TLS
> implementation. This change forbids wildcard domains in TLS certificates
> unless the wildcard is in the left-most component. Certificates of this
> nature should be rare and are not allowed per the CABForum baseline
> requirements. However there may be a small compatibility risk associated with
> this change, so a CSR has also been filed.
test/jdk/sun/security/util/HostnameChecker/Wildcard.java line 72:
> 70: } catch (Exception e) {
> 71: if (expected) {
> 72: throw new Exception("unexpectedly failed match", e);
consider to update these to RuntimeException
test/jdk/sun/security/util/HostnameMatcher/TestHostnameChecker.java line 196:
> 194: check(checker, "5.6.7.8", cert3, true);
> 195: check(checker, "foo.bar.com", cert4, true);
> 196: check(checker, "altfoo.bar.com", cert4, true);
Can expected result be updated to false instead of removing this case?
-
PR: https://git.openjdk.java.net/jdk/pull/7697
Re: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2]
On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors >> taking a cause to javax.net.ssl exceptions. The use of initCause in the >> JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one > additional commit since the last revision: > > typo correction Please consider adding simple tests to cover new APIs, similar to https://github.com/openjdk/jdk/pull/7705/files#diff-28e1041be519b6266b3b92aea29c5d8917c279880da7e5e9823a518196e96ea5 - PR: https://git.openjdk.java.net/jdk/pull/7722
Re: RFR: 8282723: Add constructors taking a cause to JSSE exceptions [v2]
On Mon, 7 Mar 2022 19:42:47 GMT, Xue-Lei Andrew Fan wrote: >> Please review this small API enhancement to add the usual constructors >> taking a cause to javax.net.ssl exceptions. The use of initCause in the >> JSSE implementation code is updated to use the new constructors accordingly. >> >> Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282724 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one > additional commit since the last revision: > > typo correction Update following for SSLPeerUnverifiedException - https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java#L439 - PR: https://git.openjdk.java.net/jdk/pull/7722
Re: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template [v3]
On Thu, 3 Mar 2022 16:31:41 GMT, Xue-Lei Andrew Fan wrote: >> May I have this test update reviewed? >> >> The certificates used in SSL testing template SSLExampleCert could expired >> in the future (for example >> [JDK-8282398](https://bugs.openjdk.java.net/browse/JDK-8282398)). It is not >> always easy to replace the certificates if the template has been used a lot. >> >> This update is trying to use a fixed validation date, so that even the >> certificates are expired the test will continue to work with no surprises. >> >> I also did a few code clean up in this patch. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one > additional commit since the last revision: > > typo introduced in bug ID Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7651
Re: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template [v2]
On Tue, 1 Mar 2022 23:23:53 GMT, Xue-Lei Andrew Fan wrote: >> May I have this test update reviewed? >> >> The certificates used in SSL testing template SSLExampleCert could expired >> in the future (for example >> [JDK-8282398](https://bugs.openjdk.java.net/browse/JDK-8282398)). It is not >> always easy to replace the certificates if the template has been used a lot. >> >> This update is trying to use a fixed validation date, so that even the >> certificates are expired the test will continue to work with no surprises. >> >> I also did a few code clean up in this patch. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one > additional commit since the last revision: > > Chaneg to use DateFormat test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java line 26: > 24: /** > 25: * @test > 26: * @bug 8806542 Missed to note earlier. 8806542 is not a valid bug number. It was updated to 8065422 so this change is not needed. - PR: https://git.openjdk.java.net/jdk/pull/7651
Re: RFR: 8282511: Use fixed certificate validation date in SSLExampleCert template
On Tue, 1 Mar 2022 22:38:30 GMT, Xue-Lei Andrew Fan wrote:
> May I have this test update reviewed?
>
> The certificates used in SSL testing template SSLExampleCert could expired in
> the future (for example
> [JDK-8282398](https://bugs.openjdk.java.net/browse/JDK-8282398). It is not
> always easy to replace the certificates if the template has been used a lot.
>
> This update is trying to use a fixed validation date, so that even the
> certificates are expired the test will continue to work with no surprises.
>
> I also did a few code clean up in this patch.
test/jdk/javax/net/ssl/ServerName/EndingDotHostname.java line 26:
> 24: /**
> 25: * @test
> 26: * @bug 8806542 8282511
No need to add a bug id here as this is test only change
test/jdk/javax/net/ssl/templates/SSLExampleCert.java line 373:
> 371: // Set the date for the verifying of certificates.
> 372: @SuppressWarnings("deprecation")
> 373: Date verifyingDate = new Date(123, 3, 3);
can DateFormat be used instead to parse Date from a readable string
representation?
-
PR: https://git.openjdk.java.net/jdk/pull/7651
Integrated: 8282398: EndingDotHostname.java test fails because SSL cert expired
On Fri, 25 Feb 2022 21:41:52 GMT, Rajan Halade wrote: > Updated test certificates with 20 years of validity This pull request has now been integrated. Changeset: afd4bcbc Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/afd4bcbc1d1b2a8a1c29005878c8e06c662a1f6e Stats: 202 lines in 2 files changed: 30 ins; 2 del; 170 mod 8282398: EndingDotHostname.java test fails because SSL cert expired Reviewed-by: xuelei - PR: https://git.openjdk.java.net/jdk/pull/7626
Re: RFR: 8282398: EndingDotHostname.java test fails because SSL cert expired [v2]
> Updated test certificates with 20 years of validity Rajan Halade has updated the pull request incrementally with one additional commit since the last revision: 8065422: update formatting - Changes: - all: https://git.openjdk.java.net/jdk/pull/7626/files - new: https://git.openjdk.java.net/jdk/pull/7626/files/669e3524..e2529520 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7626=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7626=00-01 Stats: 31 lines in 2 files changed: 0 ins; 1 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/7626.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7626/head:pull/7626 PR: https://git.openjdk.java.net/jdk/pull/7626
RFR: 8282398: EndingDotHostname.java test fails because SSL cert expired
Updated test certificates with 20 years of validity - Commit messages: - 8065422: remove unwanted change - 8282398: EndingDotHostname.java test fails because SSL cert expired Changes: https://git.openjdk.java.net/jdk/pull/7626/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7626=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282398 Stats: 205 lines in 2 files changed: 30 ins; 1 del; 174 mod Patch: https://git.openjdk.java.net/jdk/pull/7626.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7626/head:pull/7626 PR: https://git.openjdk.java.net/jdk/pull/7626
Integrated: 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022
On Fri, 18 Feb 2022 18:24:46 GMT, Rajan Halade wrote: > We are checking with CA if root cert can be removed. Meanwhile, updated test > to add expiry exception. This pull request has now been integrated. Changeset: d3749de4 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/d3749de47832c6de4bcee9cf64a0b698e796b2f2 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022 Reviewed-by: weijun - PR: https://git.openjdk.java.net/jdk/pull/7537
RFR: 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022
We are checking with CA if root cert can be removed. Meanwhile, updated test to add expiry exception. - Commit messages: - 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022 Changes: https://git.openjdk.java.net/jdk/pull/7537/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7537=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277488 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7537.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7537/head:pull/7537 PR: https://git.openjdk.java.net/jdk/pull/7537
Re: RFR: 8278080: Add --with-cacerts-src='user cacerts folder' to enable deterministic cacerts generation [v2]
On Thu, 2 Dec 2021 12:13:03 GMT, Andrew Leonard wrote: >> Addition of a configure option --with-cacerts-src='user cacerts folder' to >> allow developers to specify their own cacerts PEM folder for generation of >> the cacerts store using the deterministic openjdk GenerateCacerts tool. >> >> Signed-off-by: Andrew Leonard > > Andrew Leonard has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > - 8278080: Add --with-cacerts-src='user cacerts folder' to enable > deterministic cacerts generation > >Signed-off-by: Andrew Leonard > - Merge branch 'master' of https://github.com/openjdk/jdk into cacertssrc > - 8278080: Add --with-cacerts-src='user cacerts folder' to enable > determinsitic cacerts generation > >Signed-off-by: Andrew Leonard > - 8278080: Add --with-cacerts-src='user cacerts folder' to enable > determinsitic cacerts generation > >Signed-off-by: Andrew Leonard The purpose of this test is to ensure integrity of the cacerts file along with basic validation of included roots. Having a config file with this information sounds like a good idea for now to be able to handle multiple files. - PR: https://git.openjdk.java.net/jdk/pull/6647
Re: RFR: 8272908: Missing coverage for certain classes in com.sun.org.apache.xml.internal.security
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.ElementProxy > - com.sun.org.apache.xml.internal.security.keys.KeyInfo > > The new tests exercise code blocks that are not currently covered by other > tests. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5913
Re: RFR: 8272908: Missing coverage for certain classes in com.sun.org.apache.xml.internal.security
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.ElementProxy
> - com.sun.org.apache.xml.internal.security.keys.KeyInfo
>
> The new tests exercise code blocks that are not currently covered by other
> tests.
test/jdk/com/sun/org/apache/xml/internal/security/SignatureKeyInfo.java line
117:
> 115: doc.getElementsByTagNameNS(NS, "Signature");
> 116: if (nl.getLength() == 0) {
> 117: throw new Exception("Could not find signature Element");
update this to RuntimeException
-
PR: https://git.openjdk.java.net/jdk/pull/5913
Re: RFR: 8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is skipped
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 for multiple test scenarios, but then instead of using
> that argument the RSAPrivateKeySpec.class is hardcoded:
>
>
> private static void testKeySpec(KeyFactory factory, PrivateKey key, Class extends KeySpec> specClass) throws Exception {
> try {
> KeySpec spec = factory.getKeySpec(key, RSAPrivateKeySpec.class);
>
>
> it should be:
>
> `KeySpec spec = factory.getKeySpec(key, specClass);
> `
Marked as reviewed by rhalade (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5351
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]
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 established connection was aborted by the >> software in your host machine >> >> 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 Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4993
Re: RFR: 8272708: [Test]: Cleanup: test/jdk/security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java no longer needs ocspEnabled
On Thu, 19 Aug 2021 12:11:21 GMT, Thejasvi Voniadka wrote: > Hi, > > Please review this simple clean-up fix to remove an unused variable. The test > passed on all platforms after this clean-up. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5182
Integrated: 8225083: Remove Google certificate that is expiring in December 2021
On Tue, 17 Aug 2021 03:59:15 GMT, Rajan Halade wrote: > Removed the expiring root certificate. This pull request has now been integrated. Changeset: 1cbf41a8 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/1cbf41a87b153c010c51fdbae832e00314422193 Stats: 34 lines in 2 files changed: 0 ins; 31 del; 3 mod 8225083: Remove Google certificate that is expiring in December 2021 Reviewed-by: xuelei, mullan - PR: https://git.openjdk.java.net/jdk/pull/5137
RFR: 8225083: Remove Google certificate that is expiring in December 2021
Removed the expiring root certificate. - Commit messages: - 8225083: Remove Google certificate that is expiring in December 2021 Changes: https://git.openjdk.java.net/jdk/pull/5137/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5137=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225083 Stats: 34 lines in 2 files changed: 0 ins; 31 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5137.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5137/head:pull/5137 PR: https://git.openjdk.java.net/jdk/pull/5137
Integrated: 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert
On Tue, 20 Jul 2021 23:10:33 GMT, Rajan Halade wrote: > Update the test certificates. This pull request has now been integrated. Changeset: 4bc9b049 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/4bc9b049846bd59f5c41bd62a59b567b52c9efc5 Stats: 440 lines in 2 files changed: 141 ins; 233 del; 66 mod 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/4847
Re: RFR: 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert [v2]
> Update the test certificates. Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8263059 - 8263059: update ProblemList.txt - 8263059: security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java fails due to revoked cert - Changes: https://git.openjdk.java.net/jdk/pull/4847/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4847=01 Stats: 440 lines in 2 files changed: 141 ins; 233 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/4847.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4847/head:pull/4847 PR: https://git.openjdk.java.net/jdk/pull/4847
Integrated: 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked
On Tue, 20 Jul 2021 23:50:44 GMT, Rajan Halade wrote: > Test certificates are updated. This pull request has now been integrated. Changeset: d6bb8461 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/d6bb846159be7e46fba0c3ca2915617f945e0b42 Stats: 380 lines in 2 files changed: 34 ins; 32 del; 314 mod 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/4849
Re: RFR: 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked [v2]
> Test certificates are updated. Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8248899 - 8248899: update ProblemList.txt - 8248899: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails, Certificate has been revoked - Changes: https://git.openjdk.java.net/jdk/pull/4849/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4849=01 Stats: 380 lines in 2 files changed: 34 ins; 32 del; 314 mod Patch: https://git.openjdk.java.net/jdk/pull/4849.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4849/head:pull/4849 PR: https://git.openjdk.java.net/jdk/pull/4849
Integrated: 8225082: Remove IdenTrust certificate that is expiring in September 2021
On Wed, 21 Jul 2021 02:02:06 GMT, Rajan Halade wrote: > This CA had no code signing certificates issued so it is safe to remove it > from cacerts truststore. This pull request has now been integrated. Changeset: 2ec45dc2 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/2ec45dc2dd3a6bcb4f68ee7cde5858d63614305a Stats: 34 lines in 2 files changed: 0 ins; 31 del; 3 mod 8225082: Remove IdenTrust certificate that is expiring in September 2021 Reviewed-by: shade, mullan - PR: https://git.openjdk.java.net/jdk/pull/4851
Integrated: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error
On Thu, 22 Jul 2021 17:29:32 GMT, Rajan Halade wrote: > I have updated revoked test certificate but this test may again fail in Sept > as test certificate expire leading to OCSP error. > > CA is not willing to issue test certificates with more than 90 day validity > so this test will fail every quarter. I am re-thinking the CA certification > testing approach to may be try a TLS connection with test websites. This will > ensure that test will pass as long as CA keeps test website updated. This pull request has now been integrated. Changeset: f4b3ee5d Author:Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/f4b3ee5dca8cfdc2fbb8ee64a1e8cdb8894b0061 Stats: 29 lines in 2 files changed: 0 ins; 4 del; 25 mod 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/4877
Re: RFR: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error
On Fri, 23 Jul 2021 15:00:44 GMT, Sean Mullan wrote: > But you could cache the OCSPResponse now while the certificate is not > expired, and use that in the test by calling > `PKIXRevocationChecker.setOcspResponses()`. For CRLs, you could also do > something similar by caching the CRL and storing it in `CollectionCertStore` > and adding that to `PKIXParameters`. Just some ideas to avoid having to > continuously update the test certificates every 3 months. > > I can approve this now, but can you file a follow-on issue to look into this > some more? Sure. I will investigate this along with idea of using TLS connection to test websites. Thanks! - PR: https://git.openjdk.java.net/jdk/pull/4877
Re: RFR: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error
On Fri, 23 Jul 2021 13:18:16 GMT, Sean Mullan wrote: > Have you thought about using a cached OCSPResponse to avoid the expiration > issues? You would not be testing a live OCSP network request/response, but it > might be an acceptable workaround for cases like this. For OCSP, it is possible to do backdated query and we do this when needed. The problem is some OCSP servers return UNAUTHORIZED error code after certificate expiry. We also need to update these certificates after expiry for CRL check. - PR: https://git.openjdk.java.net/jdk/pull/4877
Integrated: 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails
On Thu, 22 Jul 2021 18:07:42 GMT, Rajan Halade wrote: > Test certificates are updated for now. I am re-thinking the CA certification > testing approach to may be try a TLS connection with test websites. This will > ensure that test will pass as long as CA keeps test website updated. This pull request has now been integrated. Changeset: 45abbeed Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/45abbeed2f4f2899a3c1595b0cd8e573990a16fa Stats: 246 lines in 2 files changed: 49 ins; 7 del; 190 mod 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/4878
RFR: 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails
Test certificates are updated for now. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. - Commit messages: - 8243543: jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails Changes: https://git.openjdk.java.net/jdk/pull/4878/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4878=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243543 Stats: 246 lines in 2 files changed: 49 ins; 7 del; 190 mod Patch: https://git.openjdk.java.net/jdk/pull/4878.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4878/head:pull/4878 PR: https://git.openjdk.java.net/jdk/pull/4878
RFR: 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error
I have updated revoked test certificate but this test may again fail in Sept as test certificate expire leading to OCSP error. CA is not willing to issue test certificates with more than 90 day validity so this test will fail every quarter. I am re-thinking the CA certification testing approach to may be try a TLS connection with test websites. This will ensure that test will pass as long as CA keeps test website updated. - Commit messages: - 8270280: security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java OCSP response error Changes: https://git.openjdk.java.net/jdk/pull/4877/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4877=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270280 Stats: 29 lines in 2 files changed: 0 ins; 4 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/4877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4877/head:pull/4877 PR: https://git.openjdk.java.net/jdk/pull/4877
Re: RFR: 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification of protocol and cipher support
On Wed, 7 Jul 2021 15:23:09 GMT, Fernando Guallini
wrote:
> 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 supported.
> This approach is problematic when, for instance, supportedProtocols is equal
> to 'TLSv1.3,TLSv1.2', then supportedProtocols.contains("TLSv1") will return
> true, given that 'TLSv1' is effectively a substring of 'TLSv1.3'.
>
> Proposed fix: Set the supported/enabled protocols and ciphers as elements in
> lists, and use List contains() to find matches
Marked as reviewed by rhalade (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/4710
[jdk17] Integrated: 8268678: LetsEncryptCA.java test fails as Let’s Encrypt Authority X3 is retired
On Fri, 18 Jun 2021 00:54:43 GMT, Rajan Halade wrote: > clean backport to JDK 17 > > Reviewed-by: xuelei This pull request has now been integrated. Changeset: 483f1ee2 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk17/commit/483f1ee211bc0e37b486eb9d38d283ff02f0bdcc Stats: 125 lines in 1 file changed: 11 ins; 9 del; 105 mod 8268678: LetsEncryptCA.java test fails as Let’s Encrypt Authority X3 is retired Backport-of: 58e6e6d919cb15559a61a67805da263be3c9d693 - PR: https://git.openjdk.java.net/jdk17/pull/94
[jdk17] Integrated: 8268678: LetsEncryptCA.java test fails as Let’s Encrypt Authority X3 is retired
clean backport to JDK 17 Reviewed-by: xuelei - Commit messages: - 8268678: LetsEncryptCA.java test fails as Let’s Encrypt Authority X3 is retired Changes: https://git.openjdk.java.net/jdk17/pull/94/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=94=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268678 Stats: 125 lines in 1 file changed: 11 ins; 9 del; 105 mod Patch: https://git.openjdk.java.net/jdk17/pull/94.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/94/head:pull/94 PR: https://git.openjdk.java.net/jdk17/pull/94
Integrated: 8268678: LetsEncryptCA.java test fails as Let’s Encrypt Authority X3 is retired
On Thu, 17 Jun 2021 23:10:58 GMT, Rajan Halade wrote: > See the bug for more details. > > - Intermediate root cert R3 doesn't specify OCSP responder and end entity > test certificates doesn't specify CRLs > - New test artifacts are available but revoked expires on July 7th, 2021 and > valid on August 31st, 2021. so backdated validity check is performed for OCSP. > > If this fix is not acceptable for now then we can wait till CA updates test > sites. This pull request has now been integrated. Changeset: 58e6e6d9 Author:Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/58e6e6d919cb15559a61a67805da263be3c9d693 Stats: 125 lines in 1 file changed: 11 ins; 9 del; 105 mod 8268678: LetsEncryptCA.java test fails as Let’s Encrypt Authority X3 is retired Reviewed-by: xuelei - PR: https://git.openjdk.java.net/jdk/pull/4524
RFR: 8268678: LetsEncryptCA.java test fails as Let’s Encrypt Authority X3 is retired
See the bug for more details. - Intermediate root cert R3 doesn't specify OCSP responder and end entity test certificates doesn't specify CRLs - New test artifacts are available but revoked expires on July 7th, 2021 and valid on August 31st, 2021. so backdated validity check is performed for OCSP. If this fix is not acceptable for now then we can wait till CA updates test sites. - Commit messages: - 8268678: LetsEncryptCA.java test fails as Let’s Encrypt Authority X3 is retired Changes: https://git.openjdk.java.net/jdk/pull/4524/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4524=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268678 Stats: 125 lines in 1 file changed: 11 ins; 9 del; 105 mod Patch: https://git.openjdk.java.net/jdk/pull/4524.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4524/head:pull/4524 PR: https://git.openjdk.java.net/jdk/pull/4524
[jdk17] Integrated: 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test
On Wed, 16 Jun 2021 18:44:30 GMT, Rajan Halade wrote: > clean backport to JDK 17. > > Reviewed-by: xuelei This pull request has now been integrated. Changeset: 54f5ffea Author: Rajan Halade URL: https://git.openjdk.java.net/jdk17/commit/54f5ffeaad9da7cc77d9b6c0339758340c42ea2e Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Backport-of: b836b83b2aefbc87b0cf26990ddbab4479c42b71 - PR: https://git.openjdk.java.net/jdk17/pull/83
[jdk17] Integrated: 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test
clean backport to JDK 17. Reviewed-by: xuelei - Commit messages: - 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Changes: https://git.openjdk.java.net/jdk17/pull/83/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=83=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259338 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/83.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/83/head:pull/83 PR: https://git.openjdk.java.net/jdk17/pull/83
Re: [jdk17] RFR: 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset"
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 also expect a > SocketException when there is no exception chaining. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/80
Integrated: 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test
On Tue, 15 Jun 2021 22:20:23 GMT, Rajan Halade wrote: > Test is updated to add expiry exception for "identrustdstx3 [jdk]" alias. This pull request has now been integrated. Changeset: b836b83b Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/b836b83b2aefbc87b0cf26990ddbab4479c42b71 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Reviewed-by: xuelei - PR: https://git.openjdk.java.net/jdk/pull/4500
RFR: 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test
Test is updated to add expiry exception for "identrustdstx3 [jdk]" alias. - Commit messages: - 8259338: Add expiry exception for identrustdstx3 alias to VerifyCACerts.java test Changes: https://git.openjdk.java.net/jdk/pull/4500/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4500=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259338 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4500/head:pull/4500 PR: https://git.openjdk.java.net/jdk/pull/4500
Re: RFR: 8262409: sun/security/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions. SSL test failures caused by java failed with "Server reported the wrong exception"
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) > > Since SocketExceptions are not wrapped into SSLException, also need to be > caught. Other tests that were expecting a SSLException to be thrown under > certain condition were updated with a similar fix in the change previously > mentioned. > > In addition, thread.sleep was replaced with a CountDownLatch for > client/server synchronization Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4308
Re: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v3]
On Tue, 11 May 2021 13:58:28 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 guarantee that >> the client started the handshake before or during 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/server synchronization > > Fernando Guallini has updated the pull request incrementally with one > additional commit since the last revision: > > added thread stack comment in test Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3856
Re: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v2]
On Wed, 5 May 2021 11:13:13 GMT, Daniel Fuchs wrote: >> Thanks, updated to be volatile. >> >> SSLSocket::startHandshake internally first checks that the socket is not >> closed or broken and still connected, so it needs the server to close the >> socket after those verifications are performed to reproduce the test >> scenario, thus a CountDownLatch in the test before calling startHandshake >> would not guarantee that its internal operations are run before the server, >> already unblocked at that time, closes the socket >> >> A CountDownLatch after startHandshake does not work either since the client >> keeps waiting for a server response, which is blocked waiting for the latch. >> That is why I think that looking at the thread stack is the best way to >> guarantee the scenario is properly verified > > 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. - PR: https://git.openjdk.java.net/jdk/pull/3856
Re: RFR: 8265227: Move Proc.java from security/testlibrary to test/lib [v3]
On Wed, 14 Apr 2021 22:57:55 GMT, Weijun Wang wrote: >> I'd like to move this tool to test/lib inside a proper named package. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > do not call internal method Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3496
Re: RFR: 8264190: Harden TLS interop tests [v4]
On Wed, 31 Mar 2021 10:53:34 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 >> using the framework starts up, for instance, by command line. To mitigate >> intermittent failures, this patch updates interop/BaseInteropTest.java in >> order to validate the server is alive and if not, retry to create a valid >> server. >> >> In addition, Utilities::isSessionResumed implementation is now comparing >> equality of first and 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 Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3218
Re: RFR: 8264190: Harden TLS interop tests [v3]
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 a server >> using the framework starts up, for instance, by command line. To mitigate >> intermittent failures, this patch updates interop/BaseInteropTest.java in >> order to validate the server is alive and if not, retry to create a valid >> server. >> >> In addition, Utilities::isSessionResumed implementation is now comparing >> equality of first and 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 test/jdk/javax/net/ssl/TLSCommon/interop/BaseInteropTest.java line 236: > 234: // Retry operation, server might have failed to bind a port > 235: server.signalStop(); > 236: server = createServer(useCase, executor); Can you please define MAX_RETRIES and use loop to retry? This will make it flexible for us to update retries if needed and avoid duplicate code. - PR: https://git.openjdk.java.net/jdk/pull/3218
Re: RFR: 8247895: SHA1PRNGReseed.java is calling setSeed(0)
On Mon, 22 Mar 2021 10:30:07 GMT, Sibabrata Sahoo wrote: > The Test is updated to use positive integer as seed for SecureRandom. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3114
Re: RFR: 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out
On Mon, 22 Mar 2021 10:45:34 GMT, Sibabrata Sahoo wrote: > The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds > set on sslServerSocket. This time interval could be inadequate when the > machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So > the statement has been removed. Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3116
Re: RFR: 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" [v3]
On Thu, 4 Mar 2021 09:47:03 GMT, Evan Whelan wrote: >> Hi all, >> >> Please review my test fix relating to JDK-8262438 >> >> This patch introduces as Thread.sleep at the start of each iteration which >> creates a new test jvm. >> This allows the server socket sufficient time to release the previous >> connection and allows the port to be used again. >> >> I also refactored the behaviour for when the exitCode is not 0, allowing for >> an easier to read output. >> An incorrect HttpsUrlConnection.disconnect() was also removed. >> >> The test was ran 100 times on all platforms and no failures were seen. >> >> Thanks, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional > commit since the last revision: > > 8262438: Removed custom socket handling logic Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2749
Re: RFR: 8262438: sun/security/ssl/SSLLogger/LoggingFormatConsistency.java failed with "SocketException: Socket is closed" [v3]
On Fri, 5 Mar 2021 16:15:42 GMT, Rob McKenna wrote:
>> I don't see any specific issue with what you are proposing from a networking
>> perspective, but you will need someone from security-libs to review the
>> proposed changes and acknowledge that the test is still testing what it
>> intends to test.
>
> The changes here don't affect the original fix given that the default impl of
> the client & server work for the purposes of the test.
Can you please confirm that you saw all protocols ("TLSv1", "TLSv1.1",
"TLSv1.2", "TLSv1.3") negotiated with updated test run?
-
PR: https://git.openjdk.java.net/jdk/pull/2749
Re: RFR: JDK-8261969: SNIHostName should check if the encoded hostname conform to RFC 3490 [v3]
On Tue, 23 Feb 2021 02:10:58 GMT, John Jiang wrote: >> Similar to the constructor SNIHostName(String hostname), the constructor >> SNIHostName(byte[] encoded) also needs to check if the encoded hostname >> conform to RFC 3490. > > John Jiang has updated the pull request incrementally with one additional > commit since the last revision: > > Throw RuntimeException instead of Exception Thanks for updating the test. - Marked as reviewed by rhalade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2639
Re: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v3]
On Wed, 24 Feb 2021 12:34:16 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 not compatible, that means they cannot share a rcache >> file. Since there is no interoperability between java GSS-API and native >> GSS-API new rcache format at the moment, this patch only enables the test >> scenarios that mimic AP-REQ replays with multiple processes using native >> GSS-API only (when available) and multiple processes using Java 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 scenario is skipped Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2676
Re: RFR: 8258855: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and ReplayCacheTestProcWithMD5.java failed on OL8.3 [v2]
On Tue, 23 Feb 2021 18:56:03 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 not compatible, that means they cannot share a rcache
>> file. Since there is no interoperability between java GSS-API and native
>> GSS-API new rcache format at the moment, this patch only enables the test
>> scenarios that mimic AP-REQ replays with multiple processes using native
>> GSS-API only (when available) and multiple processes using Java 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 with MD5
test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java line 127:
> 125: libs = userLibs.split(",");
> 126: if (Arrays.asList(libs).contains("N") &&
> !isNativeLibAvailable()) {
> 127: System.out.println("Native mode not available -
> skipped");
Can you please add a comment here with which scenarios are skipped?
-
PR: https://git.openjdk.java.net/jdk/pull/2676
Re: RFR: 8211227: Inconsistent TLS protocol version in debug output [v3]
On Mon, 22 Feb 2021 09:47:16 GMT, Evan Whelan wrote: >> Hi everyone, >> >> Please review my fix for JDK-8211227 >> >> This supportability fix will result in a more consistent debug format when >> reading and writing TLS protocol versions. >> >> Thanks, >> Evan > > Evan Whelan has updated the pull request incrementally with one additional > commit since the last revision: > > 8211227: Re-wrote LoggingFormatConsistency to leverage SSLSocketTemplate Thanks for developing test for this change and updating it to use template. - Marked as reviewed by rhalade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2331
Re: RFR: JDK-8261969: SNIHostName would check if the encoded hostname conform to RFC 3490
On Fri, 19 Feb 2021 08:39:23 GMT, John Jiang wrote:
> Similar to the constructor SNIHostName(String hostname), the constructor
> SNIHostName(byte[] encoded) also needs to check if the encoded hostname
> conform to RFC 3490.
Changes requested by rhalade (Reviewer).
test/jdk/javax/net/ssl/ServerName/IllegalSNIName.java line 40:
> 38: try {
> 39: new SNIHostName(hostname);
> 40: throw new Exception("Expected to get IllegalArgumentException
> for "
Suggestion:
throw new RuntimeException("Expected to get
IllegalArgumentException for "
test/jdk/javax/net/ssl/ServerName/IllegalSNIName.java line 50:
> 48: try {
> 49: new SNIHostName(encodedHostname);
> 50: throw new Exception("Expected to get IllegalArgumentException
> for "
Suggestion:
throw new RuntimeException("Expected to get
IllegalArgumentException for "
-
PR: https://git.openjdk.java.net/jdk/pull/2639
Re: RFR: 8211227: Inconsistent TLS protocol version in debug output [v2]
On Thu, 18 Feb 2021 20:37:58 GMT, Evan Whelan wrote:
>> Hi everyone,
>>
>> Please review my fix for JDK-8211227
>>
>> This supportability fix will result in a more consistent debug format when
>> reading and writing TLS protocol versions.
>>
>> Thanks,
>> Evan
>
> Evan Whelan has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8211227: Re-wrote LoggingFormatConsistency to use local SSL server rather
> than an existing URL
Changes requested by rhalade (Reviewer).
test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 145:
> 143: * Fork off the other side, then do your work.
> 144: */
> 145: LoggingFormatConsistency() throws Exception {
Have you looked at the templates available at test/jdk/javax/net/ssl/templates?
Check SSLSocketTemplate.java which is using CountDownLatch.
-
PR: https://git.openjdk.java.net/jdk/pull/2331
Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v5]
On Thu, 11 Feb 2021 12:39:54 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 loopback address >> fixes intermittent failures: >> sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java >> javax/net/ssl/TLSCommon/TLSTest.java >> sun/security/ssl/CipherSuite/SupportedGroups.java >> >> >> javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection >> reset occasionally because the server closes the connection before 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 Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2405
Integrated: 8225081: Remove Telia Company CA certificate expiring in April 2021
On Mon, 8 Feb 2021 21:26:21 GMT, Rajan Halade wrote: > Removed "Sonera Class2 CA" CA certificate from Telia Company that will expire > in April 2021. > > Release Note: https://bugs.openjdk.java.net/browse/JDK-8261361 This pull request has now been integrated. Changeset: ef7ee3f4 Author:Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/ef7ee3f4 Stats: 33 lines in 2 files changed: 0 ins; 30 del; 3 mod 8225081: Remove Telia Company CA certificate expiring in April 2021 Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/2464
Re: RFR: 8259709: Disable SHA-1 XML Signatures
On Mon, 8 Feb 2021 20:46:41 GMT, Sean Mullan wrote: > Please review this change to disable XML signatures that use SHA-1 based > digest or signature algorithms. SHA-1 is weak and is not a recommended > algorithm for digital signatures. This will improve out of the box security > by restricting XML signatures that use SHA-1 algorithms. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8261246 > Release Note: https://bugs.openjdk.java.net/browse/JDK-8261364 Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2463
RFR: 8225081: Remove Telia Company CA certificate expiring in April 2021
Removed "Sonera Class2 CA" CA certificate from Telia Company that will expire in April 2021. Release Note: https://bugs.openjdk.java.net/browse/JDK-8261361 - Commit messages: - 8225081: Remove Telia Company CA certificate expiring in April 2021 Changes: https://git.openjdk.java.net/jdk/pull/2464/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2464=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225081 Stats: 33 lines in 2 files changed: 0 ins; 30 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2464.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2464/head:pull/2464 PR: https://git.openjdk.java.net/jdk/pull/2464
Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v2]
On Thu, 4 Feb 2021 14:55: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 needed bug id from tests, run with preferIPv4Stack
>
> 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: ssle.printStackTrace(System.out);
>
> If security / TLS experts agree that this is OK, then it is OK for me. Not
> being an expert, I'd be concerned that catching plain SSLException might be
> too wide and that this might hide errors. In that case, and if the error is
> intermittent, one possibility could be to respin the test in case of
> SSLException (do client side and server side again) and fail if the second
> attempts fails too.
You can use getCause() to examine reason for SSLException.
-
PR: https://git.openjdk.java.net/jdk/pull/2405
Re: RFR: 8163498: Many long-running security libs tests
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/provider/NSASuiteB/TestDSAGenParameterSpec.java > com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java > > sun/security/rsa/SignatureTest.java is now using a fake generator since its > objective is to test signature not key generation itself. In addition, it was > generating and verifying the same key twice, with same modulus and exponent. > That redundancy is removed. This speeds up the execution from ~54s to ~25s on > average Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2381
Integrated: 8256421: Add 2 HARICA roots to cacerts truststore
On Thu, 28 Jan 2021 01:22:52 GMT, Rajan Halade wrote: > Following two roots are added to cacerts store - > > CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic > Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic > Academic and Research Institutions Cert. Authority, L=Athens, C=GR > > Release Note is at - https://bugs.openjdk.java.net/browse/JDK-8260597 This pull request has now been integrated. Changeset: 69189f88 Author:Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/69189f88 Stats: 393 lines in 4 files changed: 390 ins; 0 del; 3 mod 8256421: Add 2 HARICA roots to cacerts truststore Reviewed-by: hchao, mullan - PR: https://git.openjdk.java.net/jdk/pull/2272
Re: RFR: 8211227: Inconsistent TLS protocol version in debug output
On Mon, 1 Feb 2021 10:37:35 GMT, Evan Whelan wrote:
> Hi everyone,
>
> Please review my fix for JDK-8211227
>
> This supportability fix will result in a more consistent debug format when
> reading and writing TLS protocol versions.
>
> Thanks,
> Evan
Changes requested by rhalade (Reviewer).
test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 36:
> 34: /*
> 35: * This test runs in another process so we can monitor the debug
> 36: * results. The OutputAnalyzer must see correct debug output to return a
Suggestion:
* results. The OutputAnalyzer must see correct debug output to return a
test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 83:
> 81: // Re-enabling as test depends on these algorithms
> 82: SecurityUtils.removeFromDisabledTlsAlgs("TLSv1", "TLSv1.1");
> 83: var url = new URL("https://jpg-data.us.oracle.com/;);
This URL is not accessible outside.
test/jdk/sun/security/ssl/SSLLogger/LoggingFormatConsistency.java line 50:
> 48: public class LoggingFormatConsistency {
> 49: public static void main(String[] args) throws Exception {
> 50: if (args.length == 0){
Please add a comment to explain when the test should be run with parameter.
-
PR: https://git.openjdk.java.net/jdk/pull/2331
Re: RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program
On Thu, 28 Jan 2021 18:13:39 GMT, Hai-May Chao wrote: > Looks good. Thanks!! Can you please approve review with approval on changeset? With that, your OpenJDK id will be added as reviewer to the fix. - PR: https://git.openjdk.java.net/jdk/pull/2272
RFR: 8256421: Add 2 HARICA roots to Oracle Root CA Program
Following two roots are added to cacerts store - CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR - Commit messages: - 8256421: Add 2 HARICA roots to Oracle Root CA Program Changes: https://git.openjdk.java.net/jdk/pull/2272/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2272=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256421 Stats: 393 lines in 4 files changed: 390 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2272/head:pull/2272 PR: https://git.openjdk.java.net/jdk/pull/2272
Re: RFR: 8259801: Enable XML Signature secure validation mode by default
On Fri, 22 Jan 2021 17:23:12 GMT, Sean Mullan wrote: > This change enables the XML Signature secure validation mode by default. This > will improve out of the box security by restricting signatures that contain > potentially unsafe content by default. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8260154 Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2197
Re: RFR: 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails [v2]
On Tue, 26 Jan 2021 09:06:57 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 > > Fernando Guallini has updated the pull request incrementally with one > additional commit since the last revision: > > add bugid and missing space Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2224
Re: RFR: 8217633: Configurable extensions with system properties [v2]
On Mon, 25 Jan 2021 22:17:56 GMT, Xue-Lei Andrew Fan wrote: >> The TLS protocols are designed to tolerant unknown TLS extensions. However, >> although it is not common, there are a few TLS implementations that cannot >> handle unknown extensions properly. As results in unexpected >> interoperability issue when new extensions are introduced in JDK. The >> interoperability impact could be mitigated If applications can customize the >> extensions if needed. >> >> With this update, two system properties are added to configure the default >> extensions in either client or server side of TLS connections. Please note >> that the impact of blocking TLS extensions is complicated. For example, a >> TLS connection may not be able to established if a mandatory extension is >> blocked. Please don't use this feature unless you clearly understand the >> impact. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217633 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8217993 > > Xue-Lei Andrew Fan has updated the pull request incrementally with one > additional commit since the last revision: > > Update copyright years to 2021 Marked as reviewed by rhalade (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1752
Re: RFR: 8258915: Temporary buffer cleanup
On Wed, 13 Jan 2021 21:32:07 GMT, Weijun Wang wrote: > Clean up temporary byte array, char array, and keyspec around keys and > passwords. > > No new regression test. please add noreg label to the JBS bug. - PR: https://git.openjdk.java.net/jdk/pull/2070
Re: RFR: 8259662: SocketException should be passed through
On Wed, 13 Jan 2021 06:19:18 GMT, Clive Verghese wrote: > Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears > to not be fully fixed > > This also fixes JDK-8259516: Alerts sent by peer may not be received > correctly during TLS handshake Changes requested by rhalade (Reviewer). test/jdk/sun/security/ssl/SSLContextImpl/ShouldThrowSSLExceptionWhenPeerClosesSocket.java line 32: > 30: > 31: /* > 32: * @test Suggestion: * @test * @bug 8259662 8259516 - PR: https://git.openjdk.java.net/jdk/pull/2057
