Re: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4]

2021-04-01 Thread Weijun Wang
On Fri, 2 Apr 2021 01:56:15 GMT, Weijun Wang wrote: >> Only a few minor comments. Approved. > > Maybe we don't need to resolve it in this code change. If we look carefully > at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2 > is using the signer's S

Re: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4]

2021-04-01 Thread Weijun Wang
On Fri, 2 Apr 2021 01:44:03 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update with review comments > > Only a few minor comments. Approved. Maybe we don't n

Re: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v4]

2021-04-01 Thread Weijun Wang
On Thu, 1 Apr 2021 23:36:04 GMT, Hai-May Chao wrote: >> Please review the changes that adds the -signer option to keytool >> -genkeypair command. As key agreement algorithms do not have a signing >> algorithm, the specified signer's private key will be used to sign and >> generate a key

Re: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v3]

2021-04-01 Thread Weijun Wang
On Thu, 1 Apr 2021 20:37:47 GMT, Hai-May Chao wrote: >> Please review the changes that adds the -signer option to keytool >> -genkeypair command. As key agreement algorithms do not have a signing >> algorithm, the specified signer's private key will be used to sign and >> generate a key

Re: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2]

2021-04-01 Thread Weijun Wang
On Thu, 1 Apr 2021 16:34:43 GMT, Hai-May Chao wrote: >> Please review the changes that adds the -signer option to keytool >> -genkeypair command. As key agreement algorithms do not have a signing >> algorithm, the specified signer's private key will be used to sign and >> generate a key

Re: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2]

2021-04-01 Thread Weijun Wang
On Thu, 1 Apr 2021 16:25:49 GMT, Hai-May Chao wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1941: >> >>> 1939: signerFlag = true; >>> 1940: >>> 1941: if (keyStore.containsAlias(signerAlias) == false) { >> >> It's probably more precise

Re: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2]

2021-04-01 Thread Weijun Wang
On Thu, 1 Apr 2021 16:34:43 GMT, Hai-May Chao wrote: >> Please review the changes that adds the -signer option to keytool >> -genkeypair command. As key agreement algorithms do not have a signing >> algorithm, the specified signer's private key will be used to sign and >> generate a key

Re: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2]

2021-04-01 Thread Weijun Wang
On Thu, 1 Apr 2021 16:26:39 GMT, Hai-May Chao wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2013: >> >>> 2011: } >>> 2012: >>> 2013: X509Certificate[] chain = new X509Certificate[1]; >> >> Since the chain might contain one, I'd suggest we just

Re: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair [v2]

2021-04-01 Thread Weijun Wang
On Thu, 1 Apr 2021 16:25:13 GMT, Hai-May Chao wrote: >> src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java >> line 114: >> >>> 112: } >>> 113: >>> 114: /** >> >> The original constructor can be modified to call >> `this(keyType,sigAlg,providerName,null,null)`.

Re: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v3]

2021-04-01 Thread Weijun Wang
tands extra fields in `PSSParameterSpec` and is aware of the > defaults in both directions. > 3. Update `DOMSignedInfo` so that secure validation can restrict > `DigestMethod` used inside `RSAPSSParameterSpec` > 4. Tests Weijun Wang has updated the pull request incrementally with one additional

Re: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2]

2021-04-01 Thread Weijun Wang
On Tue, 30 Mar 2021 20:24:49 GMT, Weijun Wang wrote: >> I wonder if the @implSpec is clear enough that this will be returned. I >> might suggest adding a similar @implSpec in this method that basically >> states what you said above. > > I'm not sure if it's appropriat

Re: RFR: 8260693: Provide the support for specifying a signer in keytool -genkeypair

2021-03-31 Thread Weijun Wang
On Wed, 31 Mar 2021 06:30:01 GMT, Hai-May Chao wrote: > Please review the changes that adds the -signer option to keytool -genkeypair > command. As key agreement algorithms do not have a signing algorithm, the > specified signer's private key will be used to sign and generate a key >

Re: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2]

2021-03-30 Thread Weijun Wang
On Tue, 30 Mar 2021 18:41:45 GMT, Sean Mullan wrote: >> There are other fields in `RSASSAParams`, so if there is no DigestMethod, it >> will be SHA-256 but the other fields (like SaltLength or TrailerField) will >> still be read if they exist. >> >> If there is no `RSASSAParams` at all or if

Re: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2]

2021-03-30 Thread Weijun Wang
On Tue, 30 Mar 2021 15:34:16 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update XMLUtils (not used by tests here) > > src/java.xml.crypto/share/clas

Re: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2]

2021-03-30 Thread Weijun Wang
On Tue, 30 Mar 2021 15:31:22 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update XMLUtils (not used by tests here) > > src/java.xml.crypto/share/clas

Re: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2]

2021-03-30 Thread Weijun Wang
On Tue, 30 Mar 2021 15:04:29 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update XMLUtils (not used by tests here) > > src/java.xml.crypto/share/clas

RFR: 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission

2021-03-30 Thread Weijun Wang
These permissions are needed so that the URIDereferencer is able to read data from a file system or a network. As the test shows, you still have to grant the same type of permission to your application. - Depends on: https://git.openjdk.java.net/jdk/pull/3181 Commit messages: -

Re: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params [v2]

2021-03-29 Thread Weijun Wang
tands extra fields in `PSSParameterSpec` and is aware of the > defaults in both directions. > 3. Update `DOMSignedInfo` so that secure validation can restrict > `DigestMethod` used inside `RSAPSSParameterSpec` > 4. Tests Weijun Wang has updated the pull request incrementally with one additional

Re: RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params

2021-03-24 Thread Weijun Wang
On Wed, 24 Mar 2021 21:36:21 GMT, Weijun Wang wrote: > This enhancement contains the following code changes: > > 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` > and remove the internal one. > 2. Update marshaling and unmarshal

RFR: 8241306: Add SignatureMethodParameterSpec subclass for RSASSA-PSS params

2021-03-24 Thread Weijun Wang
This enhancement contains the following code changes: 1. Create a new public API `javax/xml/crypto/dsig/spec/RSAPSSParameterSpec` and remove the internal one. 2. Update marshaling and unmarshaling code inside `DOMRSAPSSSignatureMethod` so it understands extra fields in `PSSParameterSpec` and is

Integrated: 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed

2021-03-23 Thread Weijun Wang
On Mon, 22 Mar 2021 15:49:55 GMT, Weijun Wang wrote: > We don't use `digest` anymore but still need to ignore the 0 argument. This pull request has now been integrated. Changeset: 0b2aa1b6 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/0b2aa1b6 Stats: 5 li

Re: RFR: 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed [v3]

2021-03-23 Thread Weijun Wang
> We don't use `digest` anymore but still need to ignore the 0 argument. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: simplify - Changes: - all: https://git.openjdk.java.net/jdk/pull/3124/files - new: ht

Re: RFR: 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed [v2]

2021-03-22 Thread Weijun Wang
On Mon, 22 Mar 2021 18:40:37 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> typo > > src/java.base/share/classes/java/security/SecureRandom.java line 739: > >

Re: RFR: 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed [v2]

2021-03-22 Thread Weijun Wang
> We don't use `digest` anymore but still need to ignore the 0 argument. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: typo - Changes: - all: https://git.openjdk.java.net/jdk/pull/3124/files - new: ht

RFR: 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed

2021-03-22 Thread Weijun Wang
We don't use `digest` anymore but still need to ignore the 0 argument. - Commit messages: - 8263978: Clarify why 0 argument is ignored in SecureRandom::setSeed Changes: https://git.openjdk.java.net/jdk/pull/3124/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3124=00

Re: RFR: 8247895: SHA1PRNGReseed.java is calling setSeed(0)

2021-03-22 Thread Weijun Wang
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 weijun (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3114

Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v9]

2021-03-19 Thread Weijun Wang
names are renamed to be internal. There are also some > bulk changes on company name, comment style, and white spaces. > > Next steps are patches applied by JDK. Some are old patches before the last > import. Some are new. > > Several tests need to be updated because of internal method

Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v8]

2021-03-18 Thread Weijun Wang
On Thu, 18 Mar 2021 20:10:20 GMT, Sean Mullan wrote: >> Weijun Wang 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 15 addi

Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v8]

2021-03-13 Thread Weijun Wang
On Fri, 12 Mar 2021 16:29:34 GMT, Sean Mullan wrote: >> Weijun Wang 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 15 addi

Re: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec

2021-03-12 Thread Weijun Wang
On Fri, 12 Mar 2021 22:04:35 GMT, Ziyi Luo wrote: >> My understanding is that the problem here is the 2 `isAssignableFrom` checks >> are in wrong order. The parent class RSA_PRIV_KEYSPEC_CLS should be checked >> first. >> >> BTW, please add a regression test to the fix. Thanks. > > Hi

Re: RFR: 8263497: Clean up sun.security.krb5.PrincipalName::toByteArray

2021-03-12 Thread Weijun Wang
On Fri, 12 Mar 2021 09:22:40 GMT, Aleksey Shipilev wrote: > SonarCloud actually found this: > Verify this is the index that was intended; it was already set before. > > > public byte[][] toByteArray() { > byte[][] result = new byte[nameStrings.length][]; > for (int i =

Re: RFR: 8263404: RsaPrivateKeySpec is always recognized as RSAPrivateCrtKeySpec in RSAKeyFactory.engineGetKeySpec

2021-03-12 Thread Weijun Wang
On Thu, 11 Mar 2021 19:51:19 GMT, Ziyi Luo wrote: > This is a P2 regression introduced by JDK-8254717. > > In `RSAKeyFactory.engineGetKeySpec`, when the key is a RSA key and the > KeySpec is RSAPrivateKeySpec or RSAPrivateCrtKeySpec. The method behavior is > described as follow: > > X-axis:

Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v8]

2021-03-10 Thread Weijun Wang
names are renamed to be internal. There are also some > bulk changes on company name, comment style, and white spaces. > > Next steps are patches applied by JDK. Some are old patches before the last > import. Some are new. > > Several tests need to be updated because of internal method

Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v7]

2021-03-06 Thread Weijun Wang
On Sun, 10 Jan 2021 05:17:23 GMT, Xue-Lei Andrew Fan wrote: >> Weijun Wang has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental views will show differences >> compared to the previous content of the PR. > > Mark

Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.1 [v7]

2021-03-06 Thread Weijun Wang
names are renamed to be internal. There are also some > bulk changes on company name, comment style, and white spaces. > > Next steps are patches applied by JDK. Some are old patches before the last > import. Some are new. > > Several tests need to be updated because of internal method

Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v6]

2021-03-06 Thread Weijun Wang
names are renamed to be internal. There are also some > bulk changes on company name, comment style, and white spaces. > > Next steps are patches applied by JDK. Some are old patches before the last > import. Some are new. > > Several tests need to be updated because of internal method

Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v5]

2021-03-06 Thread Weijun Wang
names are renamed to be internal. There are also some > bulk changes on company name, comment style, and white spaces. > > Next steps are patches applied by JDK. Some are old patches before the last > import. Some are new. > > Several tests need to be updated because of internal method

Integrated: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0

2021-03-06 Thread Weijun Wang
On Fri, 13 Nov 2020 17:22:10 GMT, Weijun Wang wrote: > This is a multi-commits PR that upgrades xmldsig to be equivalent to > Santuario 2.2.0. > > The first step is an auto-import. The JDK implementation is removed first and > Santuario code are imported. Some unrelated files

Integrated: 8259535: ECDSA SignatureValue do not always have the specified length

2021-02-26 Thread Weijun Wang
On Fri, 12 Feb 2021 15:24:07 GMT, Weijun Wang wrote: > The code change fixes the ECDSA XML signature length issue. It should only > happen when there is no P1363 ECDSA support, which is not true when SunEC is > used. > > If a PrivateKey is not of ECPrivateKey type then the bug

Re: RFR: 8259535: ECDSA SignatureValue do not always have the specified length

2021-02-26 Thread Weijun Wang
On Thu, 25 Feb 2021 21:23:51 GMT, Sean Mullan wrote: >> The code change fixes the ECDSA XML signature length issue. It should only >> happen when there is no P1363 ECDSA support, which is not true when SunEC is >> used. >> >> If a PrivateKey is not of ECPrivateKey type then the bug will still

RFR: 8262389: Use permitted_enctypes if default_tkt_enctypes or default_tgs_enctypes is not present

2021-02-25 Thread Weijun Wang
When default_tkt_enctypes or default_tgs_enctypes, use the value of permitted_enctypes if it exists. Please also review the CSR at https://bugs.openjdk.java.net/browse/JDK-8262391 and release note at https://bugs.openjdk.java.net/browse/JDK-8262401. - Commit messages: - 8262389:

Integrated: 8139348: Deprecate 3DES and RC4 in Kerberos

2021-02-25 Thread Weijun Wang
On Wed, 24 Feb 2021 01:38:07 GMT, Weijun Wang wrote: > Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add > "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based > etypes deprecated long ago). This pull request has now been int

Re: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos [v3]

2021-02-25 Thread Weijun Wang
> Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add > "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based > etypes deprecated long ago). Weijun Wang has updated the pull request incrementally with one additional commit sinc

Re: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos [v2]

2021-02-25 Thread Weijun Wang
On Thu, 25 Feb 2021 13:40:59 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> test updates > > test/jdk/sun/security/krb5/auto/W83.java line 26: > >> 24: /*

Re: RFR: 8259709: Disable SHA-1 XML Signatures

2021-02-24 Thread Weijun Wang
On Wed, 24 Feb 2021 22:02:45 GMT, Sean Mullan wrote: > > All test changes are about re-enabling disabled algorithms. Do we have a > > test on ensuring disabled algorithms are indeed disabled? How about we set > > "org.jcp.xml.dsig.secureValidation" to false everywhere in the existing > >

Re: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos [v2]

2021-02-24 Thread Weijun Wang
> Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add > "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based > etypes deprecated long ago). Weijun Wang has updated the pull request incrementally with one additional commit sinc

Re: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos

2021-02-24 Thread Weijun Wang
On Wed, 24 Feb 2021 21:43:52 GMT, Weijun Wang wrote: >> Is there a test that checks that the weak algorithms are actually disabled? >> I wasn't sure if I saw anything or maybe that is another test that you >> didn't have to modify? > >> Is there a test that chec

Re: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos

2021-02-24 Thread Weijun Wang
On Wed, 24 Feb 2021 21:33:33 GMT, Sean Mullan wrote: > Is there a test that checks that the weak algorithms are actually disabled? I > wasn't sure if I saw anything or maybe that is another test that you didn't > have to modify? Actually there's no. I can add all weak etypes into

Re: RFR: 8139348: Deprecate 3DES and RC4 in Kerberos

2021-02-24 Thread Weijun Wang
On Wed, 24 Feb 2021 21:28:41 GMT, Sean Mullan wrote: >> Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add >> "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the >> DES-based etypes deprecated long ago). > > test/jdk/sun/security/krb5/auto/NewSalt.java

RFR: 8139348: Deprecate 3DES and RC4 in Kerberos

2021-02-23 Thread Weijun Wang
Deprecate des3-hmac-sha1 (etype 16) and rc4-hmac (etype 23). User can add "allow_weak_crypto = true" in krb5.conf to re-enable them (plus the DES-based etypes deprecated long ago). - Commit messages: - 8139348: Deprecate 3DES and RC4 in Kerberos Changes:

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

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

Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v4]

2021-02-22 Thread Weijun Wang
On Mon, 11 Jan 2021 17:58:03 GMT, Weijun Wang wrote: >> I've force pushed a new series of commits from scratch. The difference: >> >> 1. The `s/Portions copyright/Copyright/` change is inside auto import. >> 2. Some `s/Sun Microsystems/Oracle/` change in auto import

Re: RFR: 8255255: Update Apache Santuario (XML Signature) to version 2.2.0 [v4]

2021-02-22 Thread Weijun Wang
of internal method signature changes. > > The "Support RSA-PSS with parameters" commit introduces a new public API and > would need a CSR. > > The last patch is one we just fixed several days ago. Weijun Wang has refreshed the contents of this pull request, and previous commits h

Integrated: 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel.

2021-02-22 Thread Weijun Wang
On Fri, 19 Feb 2021 21:44:15 GMT, Weijun Wang wrote: > `InetAddress` is loading native library `net` and at the same time > `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside > `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and

Re: RFR: 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel. [v2]

2021-02-22 Thread Weijun Wang
dress` in `SunNativeProvider.` before loading > the jgss library. i.e. use `Class.forName` to ensure `InetAddress` is > initialized. Thanks to @dholmes-ora for providing this workaround. > > No new regression test, hard to reproduce. Weijun Wang has updated the pull request increme

Re: RFR: 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel.

2021-02-22 Thread Weijun Wang
On Mon, 22 Feb 2021 18:33:17 GMT, Xue-Lei Andrew Fan wrote: >> `InetAddress` is loading native library `net` and at the same time >> `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside >> `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a >>

Re: RFR: 8258915: Temporary buffer cleanup [v9]

2021-02-22 Thread Weijun Wang
On Mon, 22 Feb 2021 07:12:57 GMT, Valerie Peng wrote: > Changes look good. Thanks~ Thanks a lot for your patience and precious feedback. - PR: https://git.openjdk.java.net/jdk/pull/2070

Re: RFR: 8259709: Disable SHA-1 XML Signatures

2021-02-21 Thread Weijun Wang
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

Re: RFR: 8259709: Disable SHA-1 XML Signatures

2021-02-19 Thread Weijun Wang
On Tue, 9 Feb 2021 21:04:00 GMT, Weijun Wang 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 o

Re: RFR: 8258915: Temporary buffer cleanup [v8]

2021-02-19 Thread Weijun Wang
On Thu, 18 Feb 2021 11:09:17 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> materials > > Other files look fine. Thanks~ Add one more clean.

Re: RFR: 8258915: Temporary buffer cleanup [v9]

2021-02-19 Thread Weijun Wang
> Clean up temporary byte array, char array, and keyspec around keys and > passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: simpler spec creation, and one more clean --

RFR: 8210373: Deadlock in libj2gss.so when loading "j2gss" and "net" libraries in parallel.

2021-02-19 Thread Weijun Wang
`InetAddress` is loading native library `net` and at the same time `SunNativeProvider` is loading `j2gss`, and in the `OnLoad` function inside `j2gss` it is calling `FindClass(env, "java/net/InetAddress")` and thus a deadlock. We can access `InetAddress` in `SunNativeProvider.` before loading

Re: RFR: 8258915: Temporary buffer cleanup [v8]

2021-02-18 Thread Weijun Wang
On Thu, 18 Feb 2021 11:08:06 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> materials > > src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerat

Re: RFR: 8258915: Temporary buffer cleanup [v8]

2021-02-18 Thread Weijun Wang
On Thu, 18 Feb 2021 05:03:58 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> materials > > src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGener

Re: RFR: 8257497: Key identifier compliance issue [v5]

2021-02-12 Thread Weijun Wang
On Fri, 12 Feb 2021 20:42:03 GMT, Hai-May Chao wrote: >> This change is made for compliance with RFC 5280 section 4.2.1.1 for >> Authority Key Identifier extension. > > Hai-May Chao has updated the pull request incrementally with one additional > commit since the last revision: > > Reduced

RFR: 8259535: ECDSA SignatureValue do not always have the specified length

2021-02-12 Thread Weijun Wang
The code change fixes the ECDSA XML signature length issue. It should only happened when there is no P1363 ECDSA support, which is not true when SunEC is used. Technically, if a PrivateKey is not of ECPrivateKey the bug will still show up, and in this case we can actually look into the

Integrated: 8261481: Cannot read Kerberos settings in dynamic store on macOS Big Sur

2021-02-12 Thread Weijun Wang
On Wed, 10 Feb 2021 01:23:29 GMT, Weijun Wang wrote: > Accept macOS 11.x as well. > > No new regression test. This can be approved by running the existing test > test/sun/security/krb5/config/native/TestDynamicStore.java on Big Sur. This pull request has now been integrated

Re: RFR: 8257497: Key identifier compliance issue [v3]

2021-02-12 Thread Weijun Wang
On Thu, 11 Feb 2021 22:10:55 GMT, Hai-May Chao wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1482: >> >>> 1480: byte[] signerSubjectKeyIdExt = >>> ((X509Certificate)signerCert).getExtensionValue( >>> 1481:

Re: RFR: 8257497: Key identifier compliance issue [v3]

2021-02-11 Thread Weijun Wang
On Thu, 11 Feb 2021 01:01:56 GMT, Hai-May Chao wrote: >> This change is made for compliance with RFC 5280 section 4.2.1.1 for >> Authority Key Identifier extension. > > Hai-May Chao has updated the pull request incrementally with one additional > commit since the last revision: > > API used

Re: RFR: 8257497: Key identifier compliance issue [v2]

2021-02-10 Thread Weijun Wang
On Wed, 10 Feb 2021 23:07:51 GMT, Hai-May Chao wrote: >> test/jdk/sun/security/tools/keytool/CheckCertAKID.java line 69: >> >>> 67: .shouldContain(": 00 01 02 03 04 05 06 07 08 09 >>> 10 11 12 13 14 15") >>> 68: .shouldContain("0010: 16 17 18 19") >>> 69:

Re: RFR: 8257497: Key identifier compliance issue [v2]

2021-02-10 Thread Weijun Wang
On Wed, 10 Feb 2021 21:52:01 GMT, Hai-May Chao wrote: >> This change is made for compliance with RFC 5280 section 4.2.1.1 for >> Authority Key Identifier extension. > > Hai-May Chao has updated the pull request incrementally with one additional > commit since the last revision: > > Test

Re: RFR: 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint

2021-02-10 Thread Weijun Wang
On Wed, 10 Feb 2021 01:52:21 GMT, Jamil Nimeh wrote: >> Print out "no limit" instead. This is the words RFC 5280 uses: "Where >> pathLenConstraint does not appear, no limit is imposed". >> >> No regression test. Trivial. > > Looks fine to me. > Sorry - not quite right, it's not quite that

Integrated: 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint

2021-02-09 Thread Weijun Wang
On Wed, 10 Feb 2021 01:39:15 GMT, Weijun Wang wrote: > Print out "no limit" instead. This is the words RFC 5280 uses: "Where > pathLenConstraint does not appear, no limit is imposed". > > No regression test. Trivial. This pull request has now been integra

RFR: 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no pathLenConstraint

2021-02-09 Thread Weijun Wang
Print out "no limit" instead. This is the words RFC 5280 uses: "Where pathLenConstraint does not appear, no limit is imposed". No regression test. Trivial. - Commit messages: - 8261472: BasicConstraintsExtension::toString shows "PathLen:2147483647" if there is no

RFR: 8261481: Cannot read Kerberos settings in dynamic store on macOS Big Sur

2021-02-09 Thread Weijun Wang
Accept macOS 11.x as well. No new regression test. This can be approved by running the existing test test/sun/security/krb5/config/native/TestDynamicStore.java on Big Sur. - Commit messages: - 8261481: Cannot read Kerberos settings in dynamic store on macOS Big Sur Changes:

Re: RFR: 8259709: Disable SHA-1 XML Signatures

2021-02-09 Thread Weijun Wang
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

Re: RFR: 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo [v8]

2021-02-08 Thread Weijun Wang
On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov wrote: >> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8080272: Refactor I/O stream

Re: RFR: 8258915: Temporary buffer cleanup [v6]

2021-02-06 Thread Weijun Wang
On Fri, 5 Feb 2021 16:34:29 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> drbg >> >> only in patch2: >> unchanged: > > src/java.base/share

Re: RFR: 8258915: Temporary buffer cleanup [v8]

2021-02-06 Thread Weijun Wang
> Clean up temporary byte array, char array, and keyspec around keys and > passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: materials - Changes:

Re: RFR: 8258915: Temporary buffer cleanup [v7]

2021-02-06 Thread Weijun Wang
> Clean up temporary byte array, char array, and keyspec around keys and > passwords. > > No new regression test. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: TLS key generators - Changes:

Re: RFR: 8257497: Key identifier compliance issue

2021-02-05 Thread Weijun Wang
On Fri, 5 Feb 2021 21:54:19 GMT, Sean Mullan wrote: > I think it would be useful to add a test that checks that `keytool` now > creates the AKID from the issuing CA's SKID. `keytool -ext` should be able to > create a certificate with your own AKID, but you need to specify the OID and > a

Re: RFR: 8258915: Temporary buffer cleanup [v5]

2021-02-04 Thread Weijun Wang
On Thu, 4 Feb 2021 15:20:02 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> cleanups for key generations > > src/java.base/share/classes/com/sun/crypto/provider/AES

Re: RFR: 8258915: Temporary buffer cleanup

2021-02-04 Thread Weijun Wang
On Thu, 4 Feb 2021 16:13:11 GMT, Valerie Peng wrote: > > New commit for key generations. > > How about the Tls*Generator classes in SunJCE provider? Looks like they need > to be handled as well. I'll take a look. I thought the secrets going in and out of them are ephemeral. -

Re: RFR: 8258915: Temporary buffer cleanup [v5]

2021-02-04 Thread Weijun Wang
On Thu, 4 Feb 2021 15:25:14 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> cleanups for key generations > > src/java.base/share/classes/com/sun/crypto/provider/DES

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

2021-02-04 Thread Weijun Wang
On Thu, 4 Feb 2021 16:08:09 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 >>

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

2021-02-03 Thread Weijun Wang
On Wed, 3 Feb 2021 22:24:03 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 >>

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

2021-02-03 Thread Weijun Wang
On Wed, 3 Feb 2021 18:24:05 GMT, Fernando Guallini wrote: >> test/jdk/sun/security/rsa/SignatureTest.java line 137: >> >>> 135: return new Key[]{ >>> 136: kf.generatePublic(kf.getKeySpec(key, >>> RSAPublicKeySpec.class)), >>> 137:

Integrated: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m

2021-02-03 Thread Weijun Wang
On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang wrote: > This fix covers both > > - [[macOS]: Remove JNF dependency from > libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from > libosxkrb5/SCDynamicSt

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

2021-02-03 Thread Weijun Wang
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 >

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v8]

2021-02-03 Thread Weijun Wang
> This fix covers both > > - [[macOS]: Remove JNF dependency from > libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from > libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v7]

2021-02-03 Thread Weijun Wang
On Wed, 3 Feb 2021 11:27:49 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - file attr error >> - objc use .m > > src/java.security.jgss/share/classes/sun/sec

Re: RFR: 8260864: ProblemList two security/krb5 tests on Linux

2021-02-01 Thread Weijun Wang
On Mon, 1 Feb 2021 22:51:06 GMT, Daniel D. Daugherty wrote: > @wangweij - just a heads up that I'm ProblemListing the two tests you said to > "ignore". No problem! Good idea!! Well done!!! - PR: https://git.openjdk.java.net/jdk/pull/2342

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v7]

2021-02-01 Thread Weijun Wang
> This fix covers both > > - [[macOS]: Remove JNF dependency from > libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from > libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v6]

2021-02-01 Thread Weijun Wang
On Mon, 1 Feb 2021 11:41:02 GMT, Magnus Ihse Bursie wrote: >> Weijun Wang 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 cont

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v6]

2021-01-31 Thread Weijun Wang
> This fix covers both > > - [[macOS]: Remove JNF dependency from > libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from > libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v3]

2021-01-30 Thread Weijun Wang
On Sat, 30 Jan 2021 00:06:51 GMT, Phil Race wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> phil comment > > Marked as reviewed by prr (Reviewer). Added a test. Unfortunately it has t

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v5]

2021-01-30 Thread Weijun Wang
> This fix covers both > > - [[macOS]: Remove JNF dependency from > libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from > libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v4]

2021-01-30 Thread Weijun Wang
> This fix covers both > > - [[macOS]: Remove JNF dependency from > libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from > libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v3]

2021-01-29 Thread Weijun Wang
> This fix covers both > > - [[macOS]: Remove JNF dependency from > libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858) > - [[macOS]: Remove JNF dependency from > libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860

Re: RFR: 8257858: [macOS]: Remove JNF dependency from libosxsecurity/KeystoreImpl.m [v2]

2021-01-29 Thread Weijun Wang
On Fri, 29 Jan 2021 22:05:21 GMT, Phil Race wrote: >> So I should remember how env was retrieved and only detach when it's from >> `AttachCurrentThreadAsDaemon`? In fact, in my test the plain `GetEnv` has >> never succeeded and it was always attached. > > Yes that is the idea. BTW which thread

<    3   4   5   6   7   8   9   10   11   12   >