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

2021-03-18 Thread SalusaSecondus
On Thu, 18 Mar 2021 23:17:51 GMT, Valerie Peng wrote: >> Ziyi Luo has updated the pull request with a new target base due to a merge >> or a rebase. The pull request now contains four commits: >> >> - Fix P11RSAKeyFactory and add one more jtreg test >> - Add one test case for the regression f

Integrated: 8260274: Cipher.init(int, key) does not use highest priority provider for random bytes

2021-03-18 Thread Valerie Peng
On Mon, 15 Mar 2021 20:39:13 GMT, Valerie Peng wrote: > Can someone help review this somewhat trivial change? > > Updated JCAUtil class to return the cached SecureRandom object only when the > provider configuration has not changed. > Added a regression test to check the affected classes, i.e.

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

2021-03-18 Thread Valerie Peng
On Thu, 18 Mar 2021 17:30:55 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-

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 additional >> commits sin

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v32]

2021-03-18 Thread Joe Darcy
On Thu, 18 Mar 2021 15:08:56 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be

Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS keys

2021-03-18 Thread SalusaSecondus
On Thu, 11 Mar 2021 16:33:10 GMT, Xue-Lei Andrew Fan wrote: >> This is my implementation for >> [JDK-8262880](https://bugs.openjdk.java.net/browse/JDK-8262880) and enables >> creating of an SSL/TLS key log in the standardized [NSS Key Log >> Format](https://developer.mozilla.org/en-US/docs/Moz

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

2021-03-18 Thread Ziyi Luo
On Thu, 18 Mar 2021 18:57:57 GMT, SalusaSecondus wrote: >> Ziyi Luo has updated the pull request with a new target base due to a merge >> or a rebase. The pull request now contains four commits: >> >> - Fix P11RSAKeyFactory and add one more jtreg test >> - Add one test case for the regressio

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

2021-03-18 Thread Sean Mullan
On Thu, 11 Mar 2021 00:06:50 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 (Ex: encrypt

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

2021-03-18 Thread SalusaSecondus
On Thu, 18 Mar 2021 17:30:55 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-

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

2021-03-18 Thread Claes Redestad
On Thu, 18 Mar 2021 17:02:57 GMT, Alex Blewitt wrote: >> Sonar displays a warning message that modifiers should be declared in the >> order listed in the JLS; specifically, that isntead of using `final static` >> the `static final` should be preferred. >> >> This fixes the issues in the `java

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

2021-03-18 Thread Ziyi Luo
> 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: type of `keySpec` > Y-axis: type of `key` > > Before

Re: RFR: 8263825: Remove unused and commented out member from NTLMException

2021-03-18 Thread Claes Redestad
On Thu, 18 Mar 2021 16:58:31 GMT, Alex Blewitt wrote: >> Removed commented out value from `NTLMException` > > See commentary on #2993 Filed [JDK-8263825](https://bugs.openjdk.java.net/browse/JDK-8263825) for this. - PR: https://git.openjdk.java.net/jdk/pull/3076

Re: RFR: 8263825: Remove unused and commented out member from NTLMException

2021-03-18 Thread Alex Blewitt
On Thu, 18 Mar 2021 16:57:59 GMT, Alex Blewitt wrote: > Removed commented out value from `NTLMException` See commentary on #2993 - PR: https://git.openjdk.java.net/jdk/pull/3076

RFR: 8263825: Remove unused and commented out member from NTLMException

2021-03-18 Thread Alex Blewitt
Removed commented out value from `NTLMException` - Commit messages: - 8263825: Remove unused and commented out member from NTLMException Changes: https://git.openjdk.java.net/jdk/pull/3076/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3076&range=00 Issue: https://bu

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

2021-03-18 Thread Claes Redestad
On Thu, 18 Mar 2021 17:06:04 GMT, Alex Blewitt wrote: >>> If I have other fixes for different modules, should I file PRs with the >>> same bug number e.g. "8263658: Use the blessed modifier order in >>> java.logging/java.desktop" or should we have separate bug numbers for them? >> >> Separate

Re: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling [v2]

2021-03-18 Thread Jamil Nimeh
On Tue, 23 Feb 2021 20:40:05 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this change to ECDH. It is a combination of fixing >> the implementation to not only accept ECPrivateKeyImpl along with a fix to >> the exception handling. They started as two fixes, but with the

Re: RFR: 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling [v2]

2021-03-18 Thread Jamil Nimeh
On Tue, 23 Feb 2021 20:40:05 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this change to ECDH. It is a combination of fixing >> the implementation to not only accept ECPrivateKeyImpl along with a fix to >> the exception handling. They started as two fixes, but with the

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

2021-03-18 Thread Alex Blewitt
On Thu, 18 Mar 2021 17:03:28 GMT, Claes Redestad wrote: >> If I have other fixes for different modules, should I file PRs with the same >> bug number e.g. "8263658: Use the blessed modifier order in >> java.logging/java.desktop" or should we have separate bug numbers for them? > >> If I have ot

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

2021-03-18 Thread Claes Redestad
On Thu, 18 Mar 2021 16:51:35 GMT, Alex Blewitt wrote: > If I have other fixes for different modules, should I file PRs with the same > bug number e.g. "8263658: Use the blessed modifier order in > java.logging/java.desktop" or should we have separate bug numbers for them? Separate bug numbers

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

2021-03-18 Thread Alex Blewitt
On Thu, 18 Mar 2021 16:50:39 GMT, Claes Redestad wrote: >> Is that there to indicate a placeholder value that was once used and is kept >> for documentation purposes? Should the corresponding JavaDoc be removed as >> well? Should I do this in the same commit/PR as this one, or submit a new >>

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

2021-03-18 Thread Alex Blewitt
> Sonar displays a warning message that modifiers should be declared in the > order listed in the JLS; specifically, that isntead of using `final static` > the `static final` should be preferred. > > This fixes the issues in the `java.base` package for ease of reviewing. > > https://sonarcloud.

Re: RFR: 8263658: Use the blessed modifier order in java.base

2021-03-18 Thread Claes Redestad
On Thu, 18 Mar 2021 16:42:39 GMT, Alex Blewitt wrote: >> Yeah, I agree. > > Is that there to indicate a placeholder value that was once used and is kept > for documentation purposes? Should the corresponding JavaDoc be removed as > well? Should I do this in the same commit/PR as this one, or s

Re: RFR: 8263658: Use the blessed modifier order in java.base

2021-03-18 Thread Alex Blewitt
On Thu, 18 Mar 2021 14:50:43 GMT, Claes Redestad wrote: >> Sonar displays a warning message that modifiers should be declared in the >> order listed in the JLS; specifically, that isntead of using `final static` >> the `static final` should be preferred. >> >> This fixes the issues in the `jav

Re: RFR: 8263658: Use the blessed modifier order in java.base

2021-03-18 Thread Alex Blewitt
On Thu, 18 Mar 2021 15:08:09 GMT, Aleksey Shipilev wrote: >> src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52: >> >>> 50: * from server. >>> 51: */ >>> 52: //public static final int DOMAIN_UNMATCH = 3; >> >> Maybe this one ought to be removed instead? >

Re: RFR: 8263658: Use the blessed modifier order in java.base

2021-03-18 Thread Aleksey Shipilev
On Wed, 17 Mar 2021 12:31:22 GMT, Claes Redestad wrote: >> Sonar displays a warning message that modifiers should be declared in the >> order listed in the JLS; specifically, that isntead of using `final static` >> the `static final` should be preferred. >> >> This fixes the issues in the `jav

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v32]

2021-03-18 Thread Jim Laskey
> This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at > http://cr.openjdk.java.net/~jlaskey/prng/doc/a

Re: RFR: 8263658: Use the blessed modifier order in java.base

2021-03-18 Thread Claes Redestad
On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt wrote: > Sonar displays a warning message that modifiers should be declared in the > order listed in the JLS; specifically, that isntead of using `final static` > the `static final` should be preferred. > > This fixes the issues in the `java.base

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

2021-03-18 Thread Jim Laskey
On Tue, 16 Mar 2021 20:37:57 GMT, Tommy Ettinger wrote: >> This is now looking very nicely structured. >> >> The only thing i am unsure are the details around `RandomGenerator` being a >> service provider interface. The documentation mentions this at various >> points (mostly as implementatio

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31]

2021-03-18 Thread Jim Laskey
On Mon, 15 Mar 2021 23:02:33 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Missing @since > > src/java.base/share/classes/java/util/Random.java line 135: > >> 133: * number generator which is m

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31]

2021-03-18 Thread Jim Laskey
On Mon, 15 Mar 2021 23:07:53 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Missing @since > > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line > 62: > >> 60: @Retent

RFR: 8258753: StartTlsResponse.close() hangs due to synchronization issues

2021-03-18 Thread Prajwal Kumaraswamy
**Scenario:** 1. Issue occurs in a muti-threaded environment where SSL socket read() and close() are invoked in parallel. 2. SSL socket read is already called. 2. close() calls waitForCloseNotify() -> decode() ->-> socketRead0() to read the close_notify acknowledgment. 3. Since there is no sy