Re: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs [v2]

2021-10-25 Thread Weijun Wang
On Fri, 22 Oct 2021 21:53:30 GMT, Bernd wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> renames > > src/java.base/share/classes/javax/security/auth/Subject.java line 475: > >>

Re: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs [v2]

2021-10-25 Thread Weijun Wang
On Fri, 22 Oct 2021 21:45:25 GMT, Bernd wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> renames > > src/java.base/share/classes/javax/security/auth/Subject.java line 325: &g

Re: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

2021-10-25 Thread Weijun Wang
On Mon, 25 Oct 2021 12:53:43 GMT, Sean Mullan wrote: > The JDK implementation (as supplied by the "SUN" provider) of > `X509Certificate::getSubjectAlternativeNames` and > `X509Certificate::getIssuerAlternativeNames` returns `null` instead of > throwing a `CertificateParsingException` when the

Re: RFR: 8158689: java.security.KeyPair should implement Destroyable

2021-10-22 Thread Weijun Wang
On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of this change. It makes KeyPair implement Destroyable and > implements the methods to call the underlying privateKey. It also sets the > public and private key to 'final'. > > The bug includes a CSR and

Re: RFR: 8158689: java.security.KeyPair should implement Destroyable

2021-10-22 Thread Weijun Wang
On Fri, 22 Oct 2021 23:50:38 GMT, Anthony Scarpino wrote: > Hi, > > I need a review of this change. It makes KeyPair implement Destroyable and > implements the methods to call the underlying privateKey. It also sets the > public and private key to 'final'. > > The bug includes a CSR and

Re: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs [v2]

2021-10-22 Thread Weijun Wang
gt; `AccessControlContext` inside the call inherits the subject from the outer > one. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: renames - Changes: - all: https://git.openjdk.java.net/jdk/pull/5024/files

Integrated: 8270380: Change the default value of the java.security.manager system property to disallow

2021-10-21 Thread Weijun Wang
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system > property from "allow" to "disallow". This means unless it's explicitly set to > "allow", any call to `System.s

Re: RFR: 8243585: AlgorithmChecker::check throws confusing exception when it rejects the signer key [v3]

2021-10-21 Thread Weijun Wang
On Thu, 21 Oct 2021 13:43:40 GMT, Sean Mullan wrote: >> OK, but in the ctor `trustedPubKey` is also null. > > True, but that's because none of the fields are set yet, so it feels odd for > the ctor to check if the field is null when it is always true, even if it is > a different method. What

Re: RFR: 8243585: AlgorithmChecker::check throws confusing exception when it rejects the signer key [v3]

2021-10-21 Thread Weijun Wang
On Thu, 21 Oct 2021 12:06:39 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java >> line 363: >> >>> 361: // been specified. >>> 362: if (this.prevPubKey == null) { >>> 363: if (anchor == null) { >> >> This

Re: RFR: 8243585: AlgorithmChecker::check throws confusing exception when it rejects the signer key [v3]

2021-10-20 Thread Weijun Wang
On Wed, 20 Oct 2021 14:47:31 GMT, Sean Mullan wrote: >> This fix improves the exception message to better indicate when the key (and >> not the signature algorithm) is restricted. This change also includes a few >> other improvements: >> >> - The constraints checking in

RFR: 8251134: Unwrapping a key with a Private Key generated by Microsoft CNG fails

2021-10-20 Thread Weijun Wang
Support Cipher operations on CNG keys. - Depends on: https://git.openjdk.java.net/jdk/pull/6047 Commit messages: - 8251134: Unwrapping a key with a Private Key generated by Microsoft CNG fails Changes: https://git.openjdk.java.net/jdk/pull/6049/files Webrev:

RFR: 8185844: MSCAPI doesn't list aliases correctly

2021-10-20 Thread Weijun Wang
If a entry is overwritten by another one using the same alias, make sure the old one is removed. - Commit messages: - 8185844: MSCAPI doesn't list aliases correctly Changes: https://git.openjdk.java.net/jdk/pull/6047/files Webrev:

RFR: 8225181: KeyStore should have a getAttributes method

2021-10-19 Thread Weijun Wang
Add `KeyStore::getAttributes` so that one can get the attributes of an entry without retrieving the entry first. This is especially useful for a private key entry which can only be retrieved with a password. - Commit messages: - 8225181: KeyStore should have a getAttributes method

Integrated: 8275252: Migrate cacerts from JKS to password-less PKCS12

2021-10-19 Thread Weijun Wang
On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code > that uses a JKS KeyStore object can continuously load it using a null > password (in fact, any password) and see all certificates inside. This pull re

Re: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 [v2]

2021-10-19 Thread Weijun Wang
> The cacerts file is now a password-less PKCS12 file. This make sure old code > that uses a JKS KeyStore object can continuously load it using a null > password (in fact, any password) and see all certificates inside. Weijun Wang has updated the pull request incrementally with one a

Re: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 [v2]

2021-10-19 Thread Weijun Wang
On Tue, 19 Oct 2021 18:49:11 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> use a standard name > > make/jdk/src/classes/build/tools/generatecacerts/Generate

Re: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs

2021-10-19 Thread Weijun Wang
On Thu, 5 Aug 2021 20:10:44 GMT, Weijun Wang wrote: > New `Subject` APIs `current()` and `callAs()` are created to be replacements > of `getSubject()` and `doAs()` since the latter two methods are now > deprecated for removal. > > In this implementation, by default, `cur

Re: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs

2021-10-19 Thread Weijun Wang
On Wed, 18 Aug 2021 15:01:12 GMT, Sean Mullan wrote: >> New `Subject` APIs `current()` and `callAs()` are created to be replacements >> of `getSubject()` and `doAs()` since the latter two methods are now >> deprecated for removal. >> >> In this implementation, by default, `current()` returns

RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs

2021-10-19 Thread Weijun Wang
New `Subject` APIs `current()` and `callAs()` are created to be replacements of `getSubject()` and `doAs()` since the latter two methods are now deprecated for removal. In this implementation, by default, `current()` returns the same value as `getSubject(AccessController.getCurrent())` and

Re: RFR: 8243585: AlgorithmChecker::check throws confusing exception when it rejects the signer key

2021-10-19 Thread Weijun Wang
On Tue, 19 Oct 2021 15:26:52 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java line >> 48: >> >>> 46:"SHA-384", "SHA384", "SHA-512", "SHA512", "SHA-512/224", >>> 47:"SHA512/224", "SHA-512/256", "SHA512/256"); >>>

Re: RFR: 8243585: AlgorithmChecker::check throws confusing exception when it rejects the signer key

2021-10-19 Thread Weijun Wang
On Wed, 13 Oct 2021 13:42:25 GMT, Sean Mullan wrote: > This fix improves the exception message to better indicate when the key (and > not the signature algorithm) is restricted. This change also includes a few > other improvements: > > - The constraints checking in `AlgorithmChecker.check()`

Re: RFR: 8272163: Add -version option to keytool and jarsigner [v4]

2021-10-19 Thread Weijun Wang
On Tue, 19 Oct 2021 06:26:17 GMT, Hai-May Chao wrote: >> It'd be useful to have a -version option for keytool and jarsigner. Many >> other JDK tools already have a -version option. This is to add -version >> option to keytool and jarsigner like jar command does. >> >> CSR review: >>

Re: RFR: 8272163: Add -version option to keytool and jarsigner [v4]

2021-10-19 Thread Weijun Wang
On Tue, 19 Oct 2021 06:26:17 GMT, Hai-May Chao wrote: >> It'd be useful to have a -version option for keytool and jarsigner. Many >> other JDK tools already have a -version option. This is to add -version >> option to keytool and jarsigner like jar command does. >> >> CSR review: >>

Re: RFR: 8272163: Add -version option to keytool and jarsigner [v2]

2021-10-18 Thread Weijun Wang
On Tue, 19 Oct 2021 01:09:26 GMT, Hai-May Chao wrote: >> It'd be useful to have a -version option for keytool and jarsigner. Many >> other JDK tools already have a -version option. This is to add -version >> option to keytool and jarsigner like jar command does. >> >> CSR review: >>

Integrated: 8274721: UnixSystem fails to provide uid, gid or groups if no username is available

2021-10-18 Thread Weijun Wang
On Mon, 4 Oct 2021 17:40:22 GMT, Weijun Wang wrote: > Two changes: > > 1. Calculation of groups is put in a separate block. > 2. Add fallback for uid and gid > > No regression test. Hard to reproduce bud reporter's environment in jtreg. This pull request has now been inte

Re: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12

2021-10-15 Thread Weijun Wang
On Fri, 15 Oct 2021 14:12:55 GMT, Magnus Ihse Bursie wrote: >> make/jdk/src/classes/build/tools/generatecacerts/GenerateCacerts.java line >> 74: >> >>> 72: cert = (X509Certificate) cf.generateCertificate(fis); >>> 73: } >>> 74:

Integrated: 8049520: FileCredentialsCache loads cache once and is never refreshed

2021-10-15 Thread Weijun Wang
On Thu, 14 Oct 2021 22:53:42 GMT, Weijun Wang wrote: > Just re-load the CredentialsCache like we did on non-Windows non-macOS > systems. This pull request has now been integrated. Changeset: 8e020642 Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/

Re: RFR: 8272163: Add -version option to keytool and jarsigner

2021-10-15 Thread Weijun Wang
On Thu, 14 Oct 2021 16:04:08 GMT, Hai-May Chao wrote: > It'd be useful to have a -version option for keytool and jarsigner. Many > other JDK tools already have a -version option. This is to add -version > option to keytool and jarsigner like jar command does. > > CSR review: >

Re: RFR: 8049520: FileCredentialsCache loads cache once and is never refreshed [v2]

2021-10-15 Thread Weijun Wang
> Just re-load the CredentialsCache like we did on non-Windows non-macOS > systems. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: test info - Changes: - all: https://git.openjdk.java.net/jdk/pull/5960/files

Re: RFR: 8049520: FileCredentialsCache loads cache once and is never refreshed [v2]

2021-10-15 Thread Weijun Wang
On Fri, 15 Oct 2021 12:54:37 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> test info > > test/jdk/sun/security/krb5/ccache/Refresh.java line 26: > >>

RFR: 8049520: FileCredentialsCache loads cache once and is never refreshed

2021-10-14 Thread Weijun Wang
Just re-load the CredentialsCache like we did on non-Windows non-macOS systems. - Commit messages: - 8049520: FileCredentialsCache loads cache once and is never refreshed Changes: https://git.openjdk.java.net/jdk/pull/5960/files Webrev:

Re: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12

2021-10-14 Thread Weijun Wang
On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code > that uses a JKS KeyStore object can continuously load it using a null > password (in fact, any password) and see all certificates inside. For pass

Re: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12

2021-10-14 Thread Weijun Wang
On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code > that uses a JKS KeyStore object can continuously load it using a null > password (in fact, any password) and see all certificates inside. No

Re: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12

2021-10-14 Thread Weijun Wang
On Thu, 14 Oct 2021 19:07:55 GMT, Michael Osipov wrote: > Generating this trust store with Java code like I do? What do you mean "like you do"? If you accept the proposed format in this PR, then just follow what `GenerateCACerts.java` is doing and how it's called. If you are thinking about

Re: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12

2021-10-14 Thread Weijun Wang
On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code > that uses a JKS KeyStore object can continuously load it using a null > password (in fact, any password) and see all certificates inside. If

RFR: 8231107: Allow store password to be null when saving a PKCS12 KeyStore

2021-10-14 Thread Weijun Wang
You can create a password-less PKCS12 KeyStore file now by calling `ks.store(outStream, null)` no matter what the default cert protection algorithm and Mac algorithm are defined in `java.security`. - Commit messages: - 8231107: Storing PKCS12 keystore without integrity protection

RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12

2021-10-14 Thread Weijun Wang
The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. - Commit messages: - 8275252: Migrate cacerts from JKS to

Re: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with "RuntimeException: Unexpected log output:" [v2]

2021-10-14 Thread Weijun Wang
On Thu, 14 Oct 2021 03:32:19 GMT, Jaikiran Pai wrote: > So from what I understand, this `LogParameters` testcase is just there to Absolutely correct. - PR: https://git.openjdk.java.net/jdk/pull/5927

Re: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with "RuntimeException: Unexpected log output:" [v2]

2021-10-13 Thread Weijun Wang
On Wed, 13 Oct 2021 14:22:16 GMT, Jaikiran Pai wrote: >> The commit here tries to address an intermittent failure reported in >> https://bugs.openjdk.java.net/browse/JDK-8254267. >> >> The `LogParameters` test case sets the log level to `ALL` for the >> `java.lang.String.class` and then

Re: RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with "RuntimeException: Unexpected log output:"

2021-10-13 Thread Weijun Wang
On Wed, 13 Oct 2021 10:49:57 GMT, Jaikiran Pai wrote: > The commit here tries to address an intermittent failure reported in > https://bugs.openjdk.java.net/browse/JDK-8254267. > > The `LogParameters` test case sets the log level to `ALL` for the > `java.lang.String.class` and then attaches a

Re: RFR: 8275079: Remove unnecessary conversion to String in java.net.http

2021-10-11 Thread Weijun Wang
On Sat, 2 Oct 2021 20:05:37 GMT, Andrey Turbanov wrote: > Cleanup unnecessary String.valueOf calls (and similar) when conversion will > happen implicitly anyway Some small comments. src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java line 738: > 736: if

Re: RFR: 8274949: Use String.contains() instead of String.indexOf() in java.base

2021-10-08 Thread Weijun Wang
On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov wrote: > String.contains was introduced in Java 5. > Some code in java.base still uses old approach with `String.indexOf` to check > if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to

Re: RFR: 8273826: Correct Manifest file name and NPE checks [v2]

2021-10-07 Thread Weijun Wang
On Thu, 7 Oct 2021 15:12:33 GMT, Sean Mullan wrote: >> Looks like it's required if there's a @build directive > > Ok. It might be necessary because there is already a `@build` there. - PR: https://git.openjdk.java.net/jdk/pull/5841

Re: RFR: 8273826: Correct Manifest file name and NPE checks [v2]

2021-10-07 Thread Weijun Wang
On Thu, 7 Oct 2021 14:21:27 GMT, Sean Coffey wrote: >> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java >> line 66: >> >>> 64: >>> 65: private String name = null; >>> 66: private String manifestFileName; >> >> Make this final and add a comment that it will

Re: RFR: 8273826: Correct Manifest file name and NPE checks

2021-10-06 Thread Weijun Wang
On Wed, 6 Oct 2021 16:58:51 GMT, Sean Coffey wrote: > Use correct manifest file name in the Manifest verifier checks. > Also - extra null check > > The test doesn't reproduce the exact issue reported but should prevent future > regressions in this area. Marked as reviewed by weijun

Integrated: 8274656: Remove default_checksum and safe_checksum_type from krb5.conf

2021-10-05 Thread Weijun Wang
On Fri, 1 Oct 2021 17:36:13 GMT, Weijun Wang wrote: > Remove support for the 2 settings. Remove classes around the KRB_PRIV and > KRB_SAFE message types that were never used in Java. This pull request has now been integrated. Changeset: 1e752033 Author:Weijun Wang URL:

Re: RFR: 8274656: Remove default_checksum and safe_checksum_type from krb5.conf [v3]

2021-10-05 Thread Weijun Wang
> Remove support for the 2 settings. Remove classes around the KRB_PRIV and > KRB_SAFE message types that were never used in Java. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: clean up comment - Changes:

Integrated: 8273670: Remove weak etypes from default krb5 etype list

2021-10-05 Thread Weijun Wang
On Thu, 23 Sep 2021 14:32:01 GMT, Weijun Wang wrote: > This code change removes weak etypes from the default list so it's safer to > enable one of them. See the corresponding CSR at > https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, > please review the

Re: RFR: 8273026: Slow LoginContext.login() on multi threading application

2021-10-04 Thread Weijun Wang
On Mon, 4 Oct 2021 13:59:43 GMT, Weijun Wang wrote: >> This fix adds a cache of service provider classes to LoginContext (in >> particular, it's a cache of LoginModules classes). The approach helps to >> increase the performance of the LoginContext.login() method significant

Re: RFR: 8274656: Remove default_checksum and safe_checksum_type from krb5.conf

2021-10-04 Thread Weijun Wang
On Mon, 4 Oct 2021 19:29:27 GMT, Valerie Peng wrote: > Do we still need all the constants defined in > sun/security/krb5/internal/cryptoKeyUsage.java now that the corresponding > classes are removed? I haven't touched this file, and I also haven't cleaned up constants in

Re: RFR: 8274656: Remove default_checksum and safe_checksum_type from krb5.conf [v2]

2021-10-04 Thread Weijun Wang
On Mon, 4 Oct 2021 19:26:04 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update copyright years > > src/java.security.jgss/share/classes/sun/security/krb5/KrbTgsR

Re: RFR: 8274656: Remove default_checksum and safe_checksum_type from krb5.conf [v2]

2021-10-04 Thread Weijun Wang
> Remove support for the 2 settings. Remove classes around the KRB_PRIV and > KRB_SAFE message types that were never used in Java. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: update copyright years - C

Re: RFR: 8274656: Remove default_checksum and safe_checksum_type from krb5.conf

2021-10-04 Thread Weijun Wang
On Mon, 4 Oct 2021 19:18:18 GMT, Valerie Peng wrote: >> Remove support for the 2 settings. Remove classes around the KRB_PRIV and >> KRB_SAFE message types that were never used in Java. > > src/java.security.jgss/share/classes/sun/security/krb5/Checksum.java line 75: > >> 73: //

RFR: 8274721: UnixSystem fails to provide uid, gid or groups if no username is available

2021-10-04 Thread Weijun Wang
Two changes: 1. Calculation of groups is put in a separate block. 2. Add fallback for uid and gid No regression test. Hard to reproduce bud reporter's environment in jtreg. - Commit messages: - 8274721: UnixSystem fails to provide uid, gid or groups if no username is available

Integrated: 8274471: Verification of OCSP Response signed with RSASSA-PSS fails

2021-10-04 Thread Weijun Wang
On Thu, 30 Sep 2021 15:44:32 GMT, Weijun Wang wrote: > Extra parameters need to be set for RSASSA-PSS signatures. We already have a > helper method for that. > > Some other cleanups: > 1. When using GET for OCSP, make sure no double slash. > 2. Several throws clauses

Re: RFR: 8274333: Redundant null comparison after Pattern.split

2021-10-04 Thread Weijun Wang
On Sun, 26 Sep 2021 15:10:52 GMT, Andrey Turbanov wrote: > In couple of classes, result part of arrays of Pattern.split is compared with > `null`. Pattern.split (and hence String.split) never returns `null` in array > elements. Such comparisons are redundant. Marked as reviewed by weijun

Re: RFR: 8273026: Slow LoginContext.login() on multi threading application

2021-10-04 Thread Weijun Wang
On Wed, 29 Sep 2021 10:45:41 GMT, Larry-N wrote: > This fix adds a cache of service provider classes to LoginContext (in > particular, it's a cache of LoginModules classes). The approach helps to > increase the performance of the LoginContext.login() method significantly, > especially in a

Re: RFR: 8273026: Slow LoginContext.login() on multi threading application

2021-10-04 Thread Weijun Wang
On Wed, 29 Sep 2021 10:45:41 GMT, Larry-N wrote: > This fix adds a cache of service provider classes to LoginContext (in > particular, it's a cache of LoginModules classes). The approach helps to > increase the performance of the LoginContext.login() method significantly, > especially in a

Re: RFR: 8274679: Remove unnecessary conversion to String in security code in java.base

2021-10-04 Thread Weijun Wang
On Sun, 3 Oct 2021 16:24:33 GMT, Andrey Turbanov wrote: > Cleanup unnecessary String.valueOf calls (and similar) when conversion will > happen implicitly anyway. Change looks fine. Thanks for taking of this. - Marked as reviewed by weijun (Reviewer). PR:

RFR: 8274656: Remove default_checksum and safe_checksum_type from krb5.conf

2021-10-01 Thread Weijun Wang
Remove support for the 2 settings. Remove classes around the KRB_PRIV and KRB_SAFE message types that were never used in Java. - Commit messages: - 8274656: Remove default_checksum and safe_checksum_type from krb5.conf Changes: https://git.openjdk.java.net/jdk/pull/5788/files

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list [v4]

2021-10-01 Thread Weijun Wang
On Tue, 28 Sep 2021 14:24:01 GMT, Weijun Wang wrote: >> This code change removes weak etypes from the default list so it's safer to >> enable one of them. See the corresponding CSR at >> https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, >&g

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list [v5]

2021-10-01 Thread Weijun Wang
> This code change removes weak etypes from the default list so it's safer to > enable one of them. See the corresponding CSR at > https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, > please review the CSR as well. Weijun Wang has updated the pull request i

Re: RFR: 8274471: Verification of OCSP Response signed with RSASSA-PSS fails [v2]

2021-10-01 Thread Weijun Wang
On Fri, 1 Oct 2021 03:32:11 GMT, Weijun Wang wrote: >> Extra parameters need to be set for RSASSA-PSS signatures. We already have a >> helper method for that. >> >> Some other cleanups: >> 1. When using GET for OCSP, make sure no double slash. >> 2. Seve

Re: RFR: 8274471: Verification of OCSP Response signed with RSASSA-PSS fails [v3]

2021-10-01 Thread Weijun Wang
ds to access an external server. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: verifier should not use automatically derived parameters fails - Changes: - all: https://git.openjdk.java.net/jdk/pull/5778/files - new: http

Re: RFR: 8274471: Verification of OCSP Response signed with RSASSA-PSS fails [v2]

2021-09-30 Thread Weijun Wang
ds to access an external server. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: a test - Changes: - all: https://git.openjdk.java.net/jdk/pull/5778/files - new: https://git.openjdk.java.net/jdk/pull/5778/files/12e8f249..ae

Re: RFR: 8274471: Verification of OCSP Response signed with RSASSA-PSS fails

2021-09-30 Thread Weijun Wang
On Thu, 30 Sep 2021 23:15:33 GMT, Hai-May Chao wrote: > As throwing ProviderException is removed from initVerifyWithParam(), could we > remove the ProviderException in the try-catch block from the callers of > initVerifyWithParam()? For example, one of the callers at: >

Re: RFR: 8274393: Suppress more warnings on non-serializable non-transient instance fields in security libs [v2]

2021-09-30 Thread Weijun Wang
On Wed, 29 Sep 2021 18:13:14 GMT, Joe Darcy wrote: >> Follow-up change to JDK-8231262, augmentations to javac's Xlint:serial >> checking are out for review (#5709) and various security libraries would >> need some changes to pass under the expanded checks. >> >> The changes are to suppress

RFR: 8274471: Verification of OCSP Response signed with RSASSA-PSS fails

2021-09-30 Thread Weijun Wang
Extra parameters need to be set for RSASSA-PSS signatures. We already have a helper method for that. Some other cleanups: 1. When using GET for OCSP, make sure no double slash. 2. Several throws clauses are not necessary. No regression test. OCSP needs to access an external server.

Integrated: 8274330: Incorrect encoding of the DistributionPointName object in IssuingDistributionPointExtension

2021-09-29 Thread Weijun Wang
On Sun, 26 Sep 2021 13:27:47 GMT, Weijun Wang wrote: > `DistributionPointName` in `IssuingDistributionPointExtension` is a CHOICE > and should not be encoded as IMPLICIT. > > Please note that the parsing side (at > https://github.com/openjdk/jdk/blob/a9db70418f7bc6b2f95afdd36

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-09-28 Thread Weijun Wang
On Tue, 31 Aug 2021 02:05:06 GMT, Weijun Wang wrote: >> This change modifies the default value of the `java.security.manager` system >> property from "allow" to "disallow". This means unless it's explicitly set >> to "allow", any call to

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list [v4]

2021-09-28 Thread Weijun Wang
> This code change removes weak etypes from the default list so it's safer to > enable one of them. See the corresponding CSR at > https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, > please review the CSR as well. Weijun Wang has updated the pull request i

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list [v3]

2021-09-28 Thread Weijun Wang
On Tue, 28 Sep 2021 14:08:44 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> disable weak checksums as well > > src/java.security.jgss/share/classes/sun/security/k

RFR: 8274330: Incorrect encoding of the DistributionPointName object in IssuingDistributionPointExtension

2021-09-27 Thread Weijun Wang
`DistributionPointName` in `IssuingDistributionPointExtension` is a CHOICE and should not be encoded as IMPLICIT. Please note that the parsing side (at

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list [v3]

2021-09-26 Thread Weijun Wang
> This code change removes weak etypes from the default list so it's safer to > enable one of them. See the corresponding CSR at > https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, > please review the CSR as well. Weijun Wang has updated the pull request i

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list [v2]

2021-09-24 Thread Weijun Wang
> This code change removes weak etypes from the default list so it's safer to > enable one of them. See the corresponding CSR at > https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, > please review the CSR as well. Weijun Wang has updated the pull request i

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list

2021-09-24 Thread Weijun Wang
On Fri, 24 Sep 2021 22:06:27 GMT, Valerie Peng wrote: >> This is because MIT krb5 treats DES as weak and RC4 as deprecated. In Java, >> we treat both as weak after JDK-8139348 (the title is "Deprecate 3DES and >> RC4 in Kerberos" but this "deprecate" is not the same as the one in MIT >>

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list

2021-09-24 Thread Weijun Wang
On Fri, 24 Sep 2021 22:01:26 GMT, Valerie Peng wrote: >> This code change removes weak etypes from the default list so it's safer to >> enable one of them. See the corresponding CSR at >> https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, >> please review the CSR as

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list

2021-09-24 Thread Weijun Wang
On Fri, 24 Sep 2021 21:59:04 GMT, Valerie Peng wrote: >> This code change removes weak etypes from the default list so it's safer to >> enable one of them. See the corresponding CSR at >> https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, >> please review the CSR as

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list

2021-09-24 Thread Weijun Wang
On Fri, 24 Sep 2021 21:55:44 GMT, Valerie Peng wrote: >> This code change removes weak etypes from the default list so it's safer to >> enable one of them. See the corresponding CSR at >> https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, >> please review the CSR as

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list

2021-09-24 Thread Weijun Wang
On Fri, 24 Sep 2021 19:33:12 GMT, Sean Mullan wrote: >> This code change removes weak etypes from the default list so it's safer to >> enable one of them. See the corresponding CSR at >> https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, >> please review the CSR as

Re: RFR: 8273670: Remove weak etypes from default krb5 etype list

2021-09-24 Thread Weijun Wang
On Fri, 24 Sep 2021 19:49:14 GMT, Sean Mullan wrote: >> This code change removes weak etypes from the default list so it's safer to >> enable one of them. See the corresponding CSR at >> https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, >> please review the CSR as

Re: RFR: 8273299: Unnecessary Vector usage in java.security.jgss [v2]

2021-09-24 Thread Weijun Wang
On Thu, 23 Sep 2021 20:31:16 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection Vector is unnecessary. It's recommended to >> use ArrayList if a thread-safe implementation is not needed. > > Andrey Turbanov has updated the pull request incrementally with one > additional commit

Re: RFR: 8273299: Unnecessary Vector usage in java.security.jgss [v2]

2021-09-24 Thread Weijun Wang
On Thu, 23 Sep 2021 20:31:16 GMT, Andrey Turbanov wrote: >> Usage of thread-safe collection Vector is unnecessary. It's recommended to >> use ArrayList if a thread-safe implementation is not needed. > > Andrey Turbanov has updated the pull request incrementally with one > additional commit

Re: RFR: 8274237: Replace 'for' cycles with iterator with enhanced-for in java.base

2021-09-24 Thread Weijun Wang
On Thu, 23 Sep 2021 20:42:48 GMT, Andrey Turbanov wrote: > There are few places in code where manual `for` loop is used with Iterator to > iterate over Collection. > Instead of manual `for` cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read

Re: RFR: 8274143 Disable "invalid entry for security.provider.X" error message in log file when security.provider.X is empty

2021-09-24 Thread Weijun Wang
On Fri, 24 Sep 2021 08:01:07 GMT, Daniel JeliƄski wrote: > The default list of providers defined in java.security file can be overridden > with a custom file, declared with > `-Djava.security.properties=/path/to/custom.security` command line parameter. > If the new list of providers is

Re: RFR: 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC [v2]

2021-09-24 Thread Weijun Wang
On Fri, 24 Sep 2021 05:33:46 GMT, Alexey Bakhtin wrote: >> The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received >> from KDC and resends the initial request to the next KDC in the list. It >> aligns error code handling with the MIT Kerberos implementation. >>

Re: RFR: 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC

2021-09-23 Thread Weijun Wang
On Thu, 23 Sep 2021 16:52:07 GMT, Alexey Bakhtin wrote: > The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from > KDC and resends the initial request to the next KDC in the list. It aligns > error code handling with the MIT Kerberos implementation. > sun/security/krb5

Re: RFR: 8274205: Handle KDC_ERR_SVC_UNAVAILABLE error code from KDC

2021-09-23 Thread Weijun Wang
On Thu, 23 Sep 2021 16:52:07 GMT, Alexey Bakhtin wrote: > The code change handles KDC_ERR_SVC_UNAVAILABLE error code (29) received from > KDC and resends the initial request to the next KDC in the list. It aligns > error code handling with the MIT Kerberos implementation. > sun/security/krb5

RFR: 8273670: Remove weak etypes from default krb5 etype list

2021-09-23 Thread Weijun Wang
This code change removes weak etypes from the default list so it's safer to enable one of them. See the corresponding CSR at https://bugs.openjdk.java.net/browse/JDK-8274207 for more explanation. BTW, please review the CSR as well. - Commit messages: - 8273670: Remove weak etypes

Re: RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module

2021-09-21 Thread Weijun Wang
On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov wrote: > Pass "cause" exception as constructor parameter is shorter and easier to read. Looks fine. Thanks. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5551

Re: RFR: 8269039: Disable SHA-1 Signed JARs [v2]

2021-09-20 Thread Weijun Wang
On Mon, 20 Sep 2021 17:27:42 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/provider/certpath/PKIX.java line >> 228: >> >>> 226: } >>> 227: return timestampDate; >>> 228: } >> >> Can we also add some words to the `date()` method? Something

Re: RFR: 8269039: Disable SHA-1 Signed JARs [v2]

2021-09-20 Thread Weijun Wang
On Fri, 17 Sep 2021 14:29:34 GMT, Sean Mullan wrote: >> This change will disable JARs signed with algorithms using SHA-1 by default, >> and treat them as unsigned. This applies to the algorithms used to digest, >> sign, and optionally timestamp the JAR. It also applies to the signature and >>

Re: RFR: 8273646: Add openssl from path variable also in to Default System Openssl Path in OpensslArtifactFetcher

2021-09-20 Thread Weijun Wang
On Wed, 15 Sep 2021 08:01:30 GMT, Thejasvi Voniadka wrote: > The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs > interoperability checks between JDK and openssl with respect to certain > keystore operations. The test requires a suitable version of openssl to be >

Re: RFR: 8273646: Add openssl from path variable also in to Default System Openssl Path in OpensslArtifactFetcher

2021-09-15 Thread Weijun Wang
On Wed, 15 Sep 2021 08:01:30 GMT, Thejasvi Voniadka wrote: > The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs > interoperability checks between JDK and openssl with respect to certain > keystore operations. The test requires a suitable version of openssl to be >

Integrated: 8246797: A convenient method to read OPTIONAL element

2021-09-13 Thread Weijun Wang
On Mon, 23 Aug 2021 14:52:46 GMT, Weijun Wang wrote: > This code change adds new methods to `DerInputStream` to easily and safely > read optional fields in a ASN.1 DER-encoded value. It also adds several > wrapping methods to `DerValue` to avoid unnecessary memory copying when

Re: RFR: 8272385: Enforce ECPrivateKey d value to be in the range [1, n-1] for SunEC provider

2021-09-01 Thread Weijun Wang
On Wed, 1 Sep 2021 04:17:23 GMT, Jamil Nimeh wrote: > This fix adds an EC private key range check for the scalar value to be within > the range [1, n-1] (n being the order of the generator) for the SunEC ECDSA > Signature algorithms and ECDH KeyAgreement algorithms. While the SunEC >

Re: RFR: 8272385: Enforce ECPrivateKey d value to be in the range [1, n-1] for SunEC provider

2021-09-01 Thread Weijun Wang
On Wed, 1 Sep 2021 04:17:23 GMT, Jamil Nimeh wrote: > This fix adds an EC private key range check for the scalar value to be within > the range [1, n-1] (n being the order of the generator) for the SunEC ECDSA > Signature algorithms and ECDH KeyAgreement algorithms. While the SunEC >

Integrated: 8262186: Call X509KeyManager.chooseClientAlias once for all key types

2021-08-31 Thread Weijun Wang
On Wed, 25 Aug 2021 19:00:06 GMT, Weijun Wang wrote: > This code change collects all key types and runs `chooseClientAlias` only > once. This pull request has now been integrated. Changeset: 3d657eb0 Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow [v2]

2021-08-30 Thread Weijun Wang
urityManager` at runtime. > > Please note that this code change requires jtreg to be upgraded to 6.1, where > a security manager [will not be > set](https://bugs.openjdk.java.net/browse/CODETOOLS-7902990). Weijun Wang has updated the pull request incrementally with one additional co

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

2021-08-30 Thread Weijun Wang
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system > property from "allow" to "disallow". This means unless it's explicitly set to > "allow", any call to `System.s

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