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

2021-02-23 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: 8248862: Implement Enhanced Pseudo-Random Number Generators [v24]

2021-02-23 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: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25]

2021-02-23 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: 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, t

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

2021-02-23 Thread Fernando Guallini
On Tue, 23 Feb 2021 18:13:24 GMT, Weijun Wang wrote: >> Fernando Guallini has updated the pull request incrementally with one >> additional commit since the last revision: >> >> remove native lib test with MD5 > > test/jdk/sun/security/krb5/auto/ReplayCacheTestProcWithMD5.java line 40: > >>

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

2021-02-23 Thread Fernando Guallini
> Kerberos new replay cache format released in 1.18 (installed in OL8.3) is > causing the tests failures: > `https://web.mit.edu/kerberos/www/krb5-latest/doc/formats/rcache_file_format.html` > > New and old format are not compatible, that means they cannot share a rcache > file. Since there is n

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

2021-02-23 Thread Anthony Scarpino
> 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 exception > handling the underlying code changed significantly th

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

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

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: https://git.openjdk.java.n

Re: RFR: 8254717: isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards

2021-02-23 Thread Jamil Nimeh
On Tue, 23 Feb 2021 01:47:48 GMT, Ziyi Luo wrote: > All of the "isAssignableFrom" checks in "engineGetKeySpec" appear to be > backwards in Java's KeyFactorySpi.engineGetKeySpec implementations. In most > cases, the requested KeySpec is equal to the concrete implementation so the > inversion do