Integrated: 8285493: ECC calculation error

2022-04-27 Thread Weijun Wang
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. This pull request has now been integrated. Changeset: c11

Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2]

2022-04-27 Thread Weijun Wang
On Wed, 27 Apr 2022 22:54:47 GMT, Valerie Peng wrote: >> RSASSA-PSS always requires a user-provided params. >> >> I think one thing we can guarantee is that the default/random values >> generated by the impl will never overwrite the user-provided ones, they will >> only be supplemented. Also,

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v11]

2022-04-27 Thread Weijun Wang
On Wed, 27 Apr 2022 21:24:43 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally

Re: RFR: 8255552: Add DES/3DES/MD5 to jdk.security.legacyAlgorithms

2022-04-27 Thread Weijun Wang
On Wed, 27 Apr 2022 19:35:04 GMT, Sean Mullan wrote: >> Please review these changes to add DES/3DES/MD5 to >> `jdk.security.legacyAlgorithms` security property, and to add the legacy >> algorithm constraint checking to `keytool` commands that are associated with >> secret key entries stored

Re: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider

2022-04-27 Thread Weijun Wang
On Wed, 27 Apr 2022 02:26:48 GMT, Bernd wrote: >> On Windows you can now access the local machine keystores using the strings >> "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the >> application requires admin privileges. >> >> "Windows-MY" and "Windows-ROOT" remain

Re: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider

2022-04-27 Thread Weijun Wang
On Tue, 12 Apr 2022 19:03:40 GMT, Mat Carter wrote: > On Windows you can now access the local machine keystores using the strings > "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the > application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v10]

2022-04-27 Thread Weijun Wang
On Wed, 27 Apr 2022 07:48:44 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally

Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException [v2]

2022-04-27 Thread Weijun Wang
On Wed, 27 Apr 2022 00:35:49 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/Signature.java line 1015: >> >>> 1013: * parameters were not supplied and the underlying signature >>> implementation >>> 1014: * can generate the parameter values, it will be returned.

Re: RFR: 8285493: ECC calculation error

2022-04-27 Thread Weijun Wang
On Wed, 27 Apr 2022 06:28:27 GMT, Xue-Lei Andrew Fan 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. > >

Re: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2]

2022-04-26 Thread Weijun Wang
On Tue, 26 Apr 2022 20:40:50 GMT, Bradford Wetmore wrote: >> Wasn't there another bug to address this? > > Perhaps as part of > [JDK-6725221](https://bugs.openjdk.java.net/browse/JDK-6725221)? No problem. - PR: https://git.openjdk.java.net/jdk/pull/8384

RFR: 8285493: ECC calculation error

2022-04-26 Thread Weijun Wang
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. - Commit messages: - ECC calculation error fix Changes: https://git.openjdk.java.net/jdk/pull/8409/files Webrev:

Integrated: 8285404: RSA signature verification should reject non-DER OCTET STRING

2022-04-26 Thread Weijun Wang
On Fri, 22 Apr 2022 17:10:58 GMT, Weijun Wang wrote: > Compare encoded instead of decoded digest in RSA signature verification. This pull request has now been integrated. Changeset: 14e7d911 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/com

Re: RFR: 8285380: Fix typos in security [v2]

2022-04-26 Thread Weijun Wang
On Thu, 21 Apr 2022 17:32:32 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on modules owned by the security team (`java.security.jgss >> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki >> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and

Re: RFR: JDK-8285504 Minor cleanup could be done in javax.net [v2]

2022-04-26 Thread Weijun Wang
On Tue, 26 Apr 2022 00:27:43 GMT, Mark Powers wrote: >> https://bugs.openjdk.java.net/browse/JDK-8285504 >> >> JDK-8273046 is the umbrella bug for this bug. The changes were too large for >> a single code review, so it was decided to split into smaller chunks. This >> is one such chunk: >>

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v8]

2022-04-26 Thread Weijun Wang
On Mon, 25 Apr 2022 06:07:00 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request with a new

Re: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 [v2]

2022-04-26 Thread Weijun Wang
On Tue, 26 Apr 2022 16:02:41 GMT, Weijun Wang wrote: >> Compare encoded instead of decoded digest in RSA signature verification. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > only check digest v

Re: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4 [v2]

2022-04-26 Thread Weijun Wang
> Compare encoded instead of decoded digest in RSA signature verification. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: only check digest value - Changes: - all: https://git.openjdk.java.net/jdk/pull/8365/fi

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v8]

2022-04-26 Thread Weijun Wang
On Tue, 26 Apr 2022 13:38:04 GMT, Xue-Lei Andrew Fan wrote: >> IMO, there's no need to reset it to zero in `dispose()`. As for the usage in >> native implementation, if there is really a case that it gets updated, then >> the cleanable you registered at the beginning will be useless. Isn't

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v8]

2022-04-26 Thread Weijun Wang
On Mon, 25 Apr 2022 06:07:00 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request with a new

Re: RFR: 8253176: Signature.getParameters should specify that it can throw UnsupportedOperationException

2022-04-26 Thread Weijun Wang
On Tue, 26 Apr 2022 02:59:48 GMT, Valerie Peng wrote: > This is to update the method javadoc of > java.security.Signature.getParameters() with the missing `@throws > UnsupportedOperationException`. In addition, the wording on the returned > parameters are updated to match those in Cipher and

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v8]

2022-04-26 Thread Weijun Wang
On Tue, 26 Apr 2022 05:05:30 GMT, Xue-Lei Andrew Fan wrote: >> The same for `GSSName`. Where is a test for `GSSCredential`? > >> Where is a test for `GSSCredential`? > > I did not find a way to create a GSSCredential object successfully, exception > thrown. Is there an example I can refer to?

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v8]

2022-04-26 Thread Weijun Wang
On Tue, 26 Apr 2022 05:02:51 GMT, Xue-Lei Andrew Fan wrote: >> src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java >> line 54: >> >>> 52: private final Cleaner.Cleanable cleanable; >>> 53: >>> 54: long pName = 0; // Pointer to the gss_name_t structure >>

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v8]

2022-04-25 Thread Weijun Wang
On Mon, 25 Apr 2022 06:07:00 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request with a new

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v8]

2022-04-25 Thread Weijun Wang
On Tue, 26 Apr 2022 02:01:10 GMT, Weijun Wang wrote: >> Xue-Lei Andrew Fan has updated the pull request with a new target base due >> to a merge or a rebase. The pull request now contains 10 commits: >> >> - Merge and resovle merge conflict >> - chang

Re: RFR: 8285516: clearPassword should be called in a finally try block

2022-04-25 Thread Weijun Wang
On Sun, 24 Apr 2022 05:13:36 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > Could I have the simple update reviewed? > > In the PKCS12 key store implementation, the PBEKeySpec.clearPassword() should > be called in a finally try block. Otherwise, the password cleanup could be > interrupted by

Re: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4

2022-04-24 Thread Weijun Wang
On Fri, 22 Apr 2022 23:20:43 GMT, Valerie Peng wrote: > Regardless whether we ended up with decode/encode, we should make sure > RSASSA-PSS signature impl is also covered and consistent. RSASSA-PSS is not affected. Neither with the PKCS11 RSA signature. - PR:

Re: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4

2022-04-22 Thread Weijun Wang
On Fri, 22 Apr 2022 18:09:33 GMT, Michael StJohns wrote: > This is a weird one.? AFAICT the way it was being done is valid and > allowed by RFC8017 - I would have closed the bug report as notabug Yes, I saw the "Note". It's definitely OK to decode but one has to make sure the input is DER

RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4

2022-04-22 Thread Weijun Wang
Compare encoded instead of decoded digest in RSA signature verification. - Commit messages: - RFC 8017 8.2.2 Step 4 Changes: https://git.openjdk.java.net/jdk/pull/8365/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8365=00 Issue:

Integrated: 8284291: sun/security/krb5/auto/Renew.java fails intermittently on Windows 11

2022-04-20 Thread Weijun Wang
On Mon, 4 Apr 2022 21:27:51 GMT, Weijun Wang wrote: > `Thread.sleep()` seems not very precise on some systems. Update this test to > check the current time continously. This pull request has now been integrated. Changeset: 05ae7ed1 Author:Weijun Wang URL:

Re: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider

2022-04-12 Thread Weijun Wang
On Tue, 12 Apr 2022 19:03:40 GMT, Mat Carter wrote: > On Windows you can now access the local machine keystores using the strings > "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the > application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v3]

2022-04-09 Thread Weijun Wang
On Sat, 9 Apr 2022 06:22:51 GMT, Xue-Lei Andrew Fan wrote: > Could you have more details? I did not catch the comment about > NativeGSSContext. When `NativeGSSContext(GSSNameElement peer, GSSCredElement myCred, int time, GSSLibStub stub)` is called, `pContext` is 0 and you haven't registered

Re: RFR: 8284105: Update security libraries to use sealed classes [v2]

2022-04-08 Thread Weijun Wang
On Fri, 8 Apr 2022 20:07:32 GMT, Sean Mullan wrote: >> Please review these changes to update the security libraries to use sealed >> classes. See JEP 409 for more details on sealed classes. >> >> No CSR is required as all the changes are to internal classes. A few classes >> that did not have

Re: RFR: 8284105: Update security libraries to use sealed classes

2022-04-08 Thread Weijun Wang
On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote: > Please review these changes to update the security libraries to use sealed > classes. See JEP 409 for more details on sealed classes. > > No CSR is required as all the changes are to internal classes. A few classes > that did not have

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v3]

2022-04-08 Thread Weijun Wang
On Thu, 7 Apr 2022 19:21:31 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v3]

2022-04-07 Thread Weijun Wang
On Thu, 7 Apr 2022 19:21:31 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v3]

2022-04-07 Thread Weijun Wang
On Thu, 7 Apr 2022 19:21:31 GMT, Xue-Lei Andrew Fan wrote: >> Please review the update to remove finalizer method in the >> java.security.jgss module. It is one of the efforts to clean up the use of >> finalizer method in JDK. > > Xue-Lei Andrew Fan has updated the pull request incrementally

Re: RFR: 8284490: Remove finalizer method in java.security.jgss [v3]

2022-04-07 Thread Weijun Wang
On Thu, 7 Apr 2022 17:54:35 GMT, Xue-Lei Andrew Fan wrote: >> Hmm, the earlier JCE change would also needs to be updated as it calls a >> cleanup method on the to-be-cleaned object. > >> Hmm, the earlier JCE change would also needs to be updated as it calls a >> cleanup method on the

Re: RFR: 8284291: sun/security/krb5/auto/Renew.java fails intermittently on Windows 11

2022-04-05 Thread Weijun Wang
On Tue, 5 Apr 2022 08:23:39 GMT, Andrey Turbanov wrote: >> `Thread.sleep()` seems not very precise on some systems. Update this test to >> check the current time continously. > > 50 repeats. No failures. Thank you! @turbanoff Thanks for the code review. At the same time, I'm still curious why

Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5]

2022-03-25 Thread Weijun Wang
On Sat, 26 Mar 2022 00:27:19 GMT, Valerie Peng wrote: >> Almost the whole class spec is copied from PKCS #1 but at the end you have >> "defined in the ASN.1 encoding from the PKCS#1 standard", which might make >> people wonder if it is something else. If you don't want to remove anything, >>

Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5]

2022-03-25 Thread Weijun Wang
On Fri, 25 Mar 2022 21:34:28 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line 78: >> >>> 76: * Please do not rely on {@code PSSParameterSpec.DEFAULT} unless these >>> 77: * values are really what you want to use. >>> 78: * >> >> I just

Integrated: 8283691: Classes in java.security still reference deprecated classes in spec

2022-03-25 Thread Weijun Wang
On Fri, 25 Mar 2022 15:34:23 GMT, Weijun Wang wrote: > Some spec cleanup. This pull request has now been integrated. Changeset: e97cf157 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/e97cf157cf20aeaef4a8c16fed6f3bb2bc933819 Stats: 6 lines in 3 files changed

RFR: 8283691: Classes in java.security still reference deprecated classes in spec

2022-03-25 Thread Weijun Wang
Some spec cleanup. - Commit messages: - 8283691: Classes in java.security still reference deprecated classes in spec Changes: https://git.openjdk.java.net/jdk/pull/7961/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7961=00 Issue:

Re: RFR: 8283665: Two Jarsigner tests needs to be updated with JDK-8267319

2022-03-25 Thread Weijun Wang
On Fri, 25 Mar 2022 05:11:18 GMT, Valerie Peng wrote: > Max, can you please help review this fix? It updates the two jarsigner tests > which are added to the main trunk during the code review of JDK-8267319. > > Mach5 run succeeds. > Thanks, > Valerie Marked as reviewed by weijun (Reviewer).

Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v5]

2022-03-24 Thread Weijun Wang
On Thu, 24 Mar 2022 23:34:30 GMT, Valerie Peng wrote: >> Can someone help review this update to the PSSParameterSpec class regarding >> the constructor with int argument and the DEFAULT static field? Just added >> @Deprecate javadoc tag and caution about their usage as suggested in the bug >>

Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v2]

2022-03-24 Thread Weijun Wang
On Thu, 24 Mar 2022 18:58:28 GMT, Valerie Peng wrote: >> Can someone help review this update to the PSSParameterSpec class regarding >> the constructor with int argument and the DEFAULT static field? Just added >> @Deprecate javadoc tag and caution about their usage as suggested in the bug >>

Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor [v2]

2022-03-24 Thread Weijun Wang
On Thu, 24 Mar 2022 18:58:28 GMT, Valerie Peng wrote: >> Can someone help review this update to the PSSParameterSpec class regarding >> the constructor with int argument and the DEFAULT static field? Just added >> @Deprecate javadoc tag and caution about their usage as suggested in the bug >>

Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor

2022-03-23 Thread Weijun Wang
On Thu, 24 Mar 2022 00:52:28 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/spec/PSSParameterSpec.java line >> 114: >> >>> 112: * recommended to explicitly specify all desired parameter >>> 113: * values with >>> 114: * {@link

Re: RFR: 8254935: Deprecate the PSSParameterSpec(int) constructor

2022-03-22 Thread Weijun Wang
On Wed, 23 Mar 2022 00:29:16 GMT, Valerie Peng wrote: > Can someone help review this update to the PSSParameterSpec class regarding > the constructor with int argument and the DEFAULT static field? Just added > @Deprecate javadoc tag and caution about their usage as suggested in the bug >

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]

2022-03-22 Thread Weijun Wang
On Tue, 22 Mar 2022 21:25:28 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384

Re: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive [v3]

2022-03-22 Thread Weijun Wang
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

Re: RFR: 8257733: Move module-specific data from make to respective module [v9]

2022-03-16 Thread Weijun Wang
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]

2022-03-15 Thread Weijun Wang
On Tue, 15 Mar 2022 20:44:20 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java >> line 122: >> >>> 120: default -> { >>> 121: throw new ProviderException >>> 122: ("Unrecognized

Re: RFR: 8282293: Domain value for system property jdk.https.negotiate.cbt should be case-insensitive [v2]

2022-03-15 Thread Weijun Wang
On Thu, 10 Mar 2022 05:59:14 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

Re: RFR: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled [v2]

2022-03-15 Thread Weijun Wang
On Tue, 15 Mar 2022 15:37:25 GMT, Hai-May Chao wrote: >> When a named curve is disabled in `jdk.disabled.namedCurves` property which >> is included in `jdk.jar.disabledAlgorithms` and >> `jdk.certpath.disabledAlgorithms`, `jarsigner` should display the disabled >> named curve as a result of

Re: RFR: 8282633: jarsigner output does not explain why an EC key is disabled if its curve has been disabled

2022-03-14 Thread Weijun Wang
On Mon, 14 Mar 2022 17:41:28 GMT, Hai-May Chao wrote: > When a named curve is disabled in `jdk.disabled.namedCurves` property which > is included in `jdk.jar.disabledAlgorithms` and > `jdk.certpath.disabledAlgorithms`, `jarsigner` should display the disabled > named curve as a result of its

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]

2022-03-14 Thread Weijun Wang
On Mon, 14 Mar 2022 20:08:31 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]

2022-03-11 Thread Weijun Wang
On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > moved CurrencyNames changes to jdk.localedata The security related changes look

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3]

2022-03-09 Thread Weijun Wang
On Wed, 9 Mar 2022 19:15:36 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384

Integrated: 8282884: Provide OID aliases for MD2, MD5, and OAEP

2022-03-09 Thread Weijun Wang
On Wed, 9 Mar 2022 16:04:02 GMT, Weijun Wang wrote: > Add missing OID aliases for several algorithms. This pull request has now been integrated. Changeset: 70318e1d Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/70318e1d17072198be5674ebe7118fb5f9373144 Stats:

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2]

2022-03-09 Thread Weijun Wang
On Wed, 9 Mar 2022 02:02:51 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384

RFR: 8282884: Provide OID aliases for MD2, MD5, and OAEP

2022-03-09 Thread Weijun Wang
Add missing OID aliases for several algorithms. - Commit messages: - 8282884: Provide OID aliases for MD2, MD5, and OAEP Changes: https://git.openjdk.java.net/jdk/pull/7761/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7761=00 Issue:

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v6]

2022-03-03 Thread Weijun Wang
On Thu, 3 Mar 2022 22:18:53 GMT, Hai-May Chao wrote: >> This fixes jarsigner to enforce checking against algorithm constraint >> properties so when the signature algorithms parameters use disabled or >> legacy algorithms, it will emit warnings accordingly. If the algorithm used >> in

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v4]

2022-03-03 Thread Weijun Wang
On Thu, 3 Mar 2022 07:24:49 GMT, Hai-May Chao wrote: >> This fixes jarsigner to enforce checking against algorithm constraint >> properties so when the signature algorithms parameters use disabled or >> legacy algorithms, it will emit warnings accordingly. If the algorithm used >> in

Integrated: 8281628: KeyAgreement : generateSecret intermittently not resetting

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 19:35:50 GMT, Weijun Wang wrote: > The comment said "pad it w/ leading 0s". So let's pad it. This pull request has now been integrated. Changeset: 1485883c Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/1485883c9e6e24315bb21f20604

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v3]

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 22:48:36 GMT, Weijun Wang wrote: >> With a bigger buffer, i.e. say 80-byte long, instead of 64-byte, I'd expect >> a difference and higher reproducibility... > > After `n = generateSecret(secret, offset)` is called, only `n` bytes from > `offs

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v3]

2022-03-02 Thread Weijun Wang
> The comment said "pad it w/ leading 0s". So let's pad it. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: check length as well - Changes: - all: https://git.openjdk.java.net/jdk/pull/7665/files

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v2]

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 22:31:02 GMT, Valerie Peng wrote: >> Maybe not. When the generated secret is shorter, the padded bytes are always >> at the beginning. > > With a bigger buffer, i.e. say 80-byte long, instead of 64-byte, I'd expect a > difference and higher reproducibility... After `n =

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting [v2]

2022-03-02 Thread Weijun Wang
> The comment said "pad it w/ leading 0s". So let's pad it. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: wrap and comment - Changes: - all: https://git.openjdk.java.net/jdk/pull/7665/files

Re: RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 21:47:06 GMT, Valerie Peng wrote: >> The comment said "pad it w/ leading 0s". So let's pad it. > > src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java line > 347: > >> 345: // Array too short, pad it w/ leading 0s >> 346: if

RFR: 8281628: KeyAgreement : generateSecret intermittently not resetting

2022-03-02 Thread Weijun Wang
The comment said "pad it w/ leading 0s". So let's pad it. - Commit messages: - remove x bits - 8281628: KeyAgreement : generateSecret intermittently not resetting Changes: https://git.openjdk.java.net/jdk/pull/7665/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7665=00

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2]

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 18:01:04 GMT, Weijun Wang wrote: >> I add "RA-PSS using “ to the `-verbose` output as suggested, and keep >> the remaining output as the parameters for the RSASSA-PSS contain >> hashAlgorithm and maskGenAlgorithm that could be disabled or wea

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled [v2]

2022-03-02 Thread Weijun Wang
On Wed, 2 Mar 2022 17:46:26 GMT, Hai-May Chao wrote: >> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java line >> 1414: >> >>> 1412: } catch (CertPathValidatorException e) { >>> 1413: disabledAlgFound = true; >>> 1414: return

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled

2022-03-02 Thread Weijun Wang
On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled

2022-03-02 Thread Weijun Wang
On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters

Re: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled

2022-03-02 Thread Weijun Wang
On Tue, 22 Feb 2022 22:00:05 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint > properties so when the signature algorithms parameters use disabled or legacy > algorithms, it will emit warnings accordingly. If the algorithm used in > parameters

Integrated: 8281234: The -protected option is not always checked in keytool and jarsigner

2022-03-02 Thread Weijun Wang
On Thu, 3 Feb 2022 18:23:55 GMT, Weijun Wang wrote: > The option means there is no need to provide a password when loading a > keystore. In some places in jarsigner and keytool, even with the option > specified, password is still prompted for or warnings are still shown. This pull re

Re: RFR: 8282320: Remove case conversion for debugging log in SSLCipher

2022-03-01 Thread Weijun Wang
On Wed, 23 Feb 2022 22:08:03 GMT, Xue-Lei Andrew Fan wrote: > String.toUpperCase() is used in SSLCipher.java for debugging logging, which > is not necessary. See also comment in [this > PR](https://github.com/openjdk/jdk/pull/7583). Marked as reviewed by weijun (Reviewer). - PR:

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v9]

2022-02-28 Thread Weijun Wang
On Fri, 18 Feb 2022 20:05:46 GMT, Weijun Wang wrote: >> The enhancement adds two extra items in the `getSubjectAlternativeNames()` >> output for an OtherName. >> >> It also fix several errors: >> 1. In `OtherName.java`, `nameValue` should be the value inside `CO

Integrated: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName

2022-02-28 Thread Weijun Wang
On Thu, 20 Jan 2022 19:42:22 GMT, Weijun Wang wrote: > The enhancement adds two extra items in the `getSubjectAlternativeNames()` > output for an OtherName. > > It also fix several errors: > 1. In `OtherName.java`, `nameValue` should be the value inside `CONTEXT [0]` &g

Re: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2]

2022-02-24 Thread Weijun Wang
On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeliński wrote: >> Please review this PR that enables >> [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) >> compiler flag, which makes assigning a string

Re: RFR: 8282316: Operation before String case conversion [v2]

2022-02-23 Thread Weijun Wang
On Wed, 23 Feb 2022 23:41:36 GMT, Xue-Lei Andrew Fan wrote: >> In the SignatureUtil implementation, the checkName() requires >> case-insensitive input for "OID". However, the method is called before the >> case conversion, for example: >> >> sigName =

Re: RFR: 8282279: Interpret case-insensitive string locale independently

2022-02-23 Thread Weijun Wang
On Wed, 23 Feb 2022 00:05:58 GMT, Xue-Lei Andrew Fan wrote: > The String.toUpperCase() or String.toLowerCase() method is locale sensitive, > and may produce unexpected results if used for strings that are intended to > be interpreted locale independently. The use of the two methods had been

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v9]

2022-02-18 Thread Weijun Wang
On Fri, 18 Feb 2022 20:05:46 GMT, Weijun Wang wrote: >> The enhancement adds two extra items in the `getSubjectAlternativeNames()` >> output for an OtherName. >> >> It also fix several errors: >> 1. In `OtherName.java`, `nameValue` should be the value inside `CO

Re: RFR: 8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022

2022-02-18 Thread Weijun Wang
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. Looks fine to me. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7537

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v9]

2022-02-18 Thread Weijun Wang
gument in constructor `extClass.getConstructor(Object.class)` is > suspicious. Maybe it meant `byte[]`. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: make exception message clearer - Changes: - all: https://git.openjdk.java

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v8]

2022-02-18 Thread Weijun Wang
On Thu, 17 Feb 2022 16:00:46 GMT, Weijun Wang wrote: >> The enhancement adds two extra items in the `getSubjectAlternativeNames()` >> output for an OtherName. >> >> It also fix several errors: >> 1. In `OtherName.java`, `nameValue` should be the value inside `CO

Integrated: 8255266: Update Public Suffix List to 3c213aa

2022-02-18 Thread Weijun Wang
On Thu, 17 Feb 2022 23:28:35 GMT, Weijun Wang wrote: > Updating to a recent release of PSL. This pull request has now been integrated. Changeset: 7ce75afb Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/7ce75afbbcca7635356c7377be7ddff15335e563 Stats: 1254 li

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]

2022-02-18 Thread Weijun Wang
On Fri, 18 Feb 2022 15:17:30 GMT, Michael Osipov wrote: >> I want to minimize behavior change and I'm leaving them to notice there's no >> string there and fail. > > While I understand that, `new DerValue(byte[])` will be ignored and this will > be also inconsistent with the remaining general

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]

2022-02-18 Thread Weijun Wang
On Fri, 18 Feb 2022 06:56:04 GMT, Michael Osipov wrote: >> Yes. I don't want to let the method fail. Since `instanceof String` should >> be called anyway the caller can decide how to fail. > > So you leave it to the user to read the ASN.1 value and fail if the encoding > is incorrect instead

RFR: 8255266: 2021-11-27 public suffix list update v 3c213aa

2022-02-17 Thread Weijun Wang
Updating to a recent release of PSL. - Commit messages: - 8255266: 2021-11-27 public suffix list update v 3c213aa Changes: https://git.openjdk.java.net/jdk/pull/7526/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7526=00 Issue:

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]

2022-02-17 Thread Weijun Wang
On Thu, 17 Feb 2022 19:42:30 GMT, Michael Osipov wrote: >> But in this case, we still have a place to provide the raw bytes. Maybe >> that's better? Or you'd rather be guaranteed that one particular otherName >> should always have a string there and there's no need to do an `instanceof` >>

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v6]

2022-02-17 Thread Weijun Wang
On Thu, 17 Feb 2022 15:36:23 GMT, Sean Mullan wrote: >> I thought about "the", but it does not show the belong to relation. > > What you can do is reword the sentence by including `otherName` in it, ex: "A > third entry may also be present in the list containing the {@code type-id} of > the

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v8]

2022-02-17 Thread Weijun Wang
gument in constructor `extClass.getConstructor(Object.class)` is > suspicious. Maybe it meant `byte[]`. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: s/can/may/ - Changes: - all: https://git.openjdk.java.net/jdk/pull/7

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v7]

2022-02-17 Thread Weijun Wang
gument in constructor `extClass.getConstructor(Object.class)` is > suspicious. Maybe it meant `byte[]`. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: hopefully the final wording - Changes: - all: https://git.openjdk.java

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v6]

2022-02-16 Thread Weijun Wang
On Thu, 17 Feb 2022 03:07:12 GMT, Weijun Wang wrote: >> src/java.base/share/classes/java/security/cert/X509Certificate.java line 595: >> >>> 593: * returned as byte arrays containing the ASN.1 DER encoded form >>> of the >>> 594: * name.

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v6]

2022-02-16 Thread Weijun Wang
On Wed, 16 Feb 2022 21:56:36 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> retell the formats > > src/java.base/share/classes/java/security/cert/X509Certif

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v6]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 20:09:27 GMT, Michael Osipov wrote: > > New commit pushed. For the openssl style suggestion, I think its major > > benefit is to provide a string format of the type (like `"othername: > > UPN:"`). In the `default` block, it still extracts either the IA5String or > > the

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v6]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 19:51:57 GMT, Weijun Wang wrote: >> The enhancement adds two extra items in the `getSubjectAlternativeNames()` >> output for an OtherName. >> >> It also fix several errors: >> 1. In `OtherName.java`, `nameValue` should be the value inside `CO

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v6]

2022-02-15 Thread Weijun Wang
gument in constructor `extClass.getConstructor(Object.class)` is > suspicious. Maybe it meant `byte[]`. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: retell the formats - Changes: - all: https://git.openjdk.java.net/jdk/pull/7

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v4]

2022-02-15 Thread Weijun Wang
On Tue, 15 Feb 2022 17:15:13 GMT, Michael Osipov wrote: > Oh, can you reference? Sorry, memory is incorrect, those are date time types (in https://www.oss.com/asn1/resources/reference/ASN.1-Reference-Card-format-USA.pdf). But here they do promote a VisibleString that we don't support.

<    1   2   3   4   5   6   7   8   9   10   >