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

2021-03-23 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 JDK-8254717:
> 
> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
> |--|--|--|
> | RSAPrivateKey | Return RSAPrivateKeySpec  | Throw `InvalidKeySpecException` 
> |
> | RSAPrivateCrtKey | Return RSAPrivateKeySpec | Return RSAPrivateKeyCrtSpec |
> 
> After JDK-8254717 (Green check is what we want to fix, red cross is the 
> regression):
> 
> |  | RSAPrivateKeySpec.class | RSAPrivateCrtKeySpec.class |
> |--|--|--|
> | RSAPrivateKey | Throw `InvalidKeySpecException` ❌  | Throw 
> `InvalidKeySpecException` |
> | RSAPrivateCrtKey | Return RSAPrivateKeyCrtSpec ✅ | Return 
> RSAPrivateKeyCrtSpec |
> 
> This commit fixes the regression.
> 
> 
> ### Tests
> 
> * Jtreg: All tests under `java/security`, `sun/security`, `javax/crypto` 
> passed
> * JCK: All JCK-16 (I do not have jCK-17)tests under `api/java_security` passed

Ziyi Luo has updated the pull request incrementally with two additional commits 
since the last revision:

 - Remove trailing whitespace
 - Refactor P11RSAKeyFactory and improve tests

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2949/files
  - new: https://git.openjdk.java.net/jdk/pull/2949/files/da25a691..2594ef2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=2949=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2949=04-05

  Stats: 152 lines in 4 files changed: 95 ins; 23 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2949.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2949/head:pull/2949

PR: https://git.openjdk.java.net/jdk/pull/2949

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 lines in 1 file changed: 1 ins; 0 del; 4 mod

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

Reviewed-by: valeriep

-

PR: https://git.openjdk.java.net/jdk/pull/3124

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: https://git.openjdk.java.net/jdk/pull/3124/files/6bd8b100..56dff532

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=3124=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3124=01-02

  Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3124.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3124/head:pull/3124

PR: https://git.openjdk.java.net/jdk/pull/3124

Re: RFR: 8248268: Support KWP in addition to KW [v3]

2021-03-23 Thread Michael StJohns 

On 3/22/2021 5:43 PM, Valerie Peng wrote:

This change updates SunJCE provider as below:
- updated existing AESWrap support with AES/KW/NoPadding cipher transformation.
- added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.

Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to 
KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. 
The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes 
which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data 
copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the 
same input buffer which is allocated and managed by KeyWrapCipher class.

Also note that existing AESWrap impl does not take IV. However, the 
corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to 
both KW and KWP.

Thanks,
Valerie



PR: https://git.openjdk.java.net/jdk/pull/2404


KeyWrapCipher.java:


  /**
212  * Sets the padding mechanism of this cipher. Currently, only
213  * "NoPadding" scheme is accepted for this cipher.
214  *
215  * @param padding the padding mechanism
216  *
217  * @exception NoSuchPaddingException if the requested padding mechanism
218  * does not match the supported padding scheme
219  */
220 @Override
221 protected void engineSetPadding(String padding)
222 throws NoSuchPaddingException {
223 if ((this.padding == null && 
!"NoPadding".equalsIgnoreCase(padding)) ||
224 this.padding instanceof PKCS5Padding &&
225 "PKCS5Padding".equalsIgnoreCase(padding)) {
226 throw new NoSuchPaddingException();
227 }
228 }


Shouldn't this be rejecting PKCS5Padding?

Actually, I keep wondering why this isn't  AES/KW/NoPadding, 
AES/KW/KWPPadding and AES/KW/AutoPadding where the latter doesn't take a 
user provided IV, but figures out which of the two default IV values to 
use based on whether the input is a multiple of the blocksize or not?


Decrypting is similar - do the decryption, and check which IV you get to 
figure out padded or not padded.


Mike

Re: RFR: 8248268: Support KWP in addition to KW [v3]

2021-03-23 Thread Michael StJohns 

On 3/23/2021 4:15 PM, Greg Rubin wrote:

177: System.out.println("Testing " + ALGO);
178: c = Cipher.getInstance(ALGO, "SunJCE");
179: for (int i = 0; i < MAX_KWP_PAD_LEN; i++) {

I see that here (and earlier) we do test all padding lengths. I'd still like 
some KATs generated by a known good implementation to ensure that we are not 
just compatible with ourselves.



http://csrc.nist.gov/groups/STM/cavp/documents/mac/kwtestvectors.zip has 
the NIST test vectors.  See 
https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/mac/KWVS.pdf 
for details.


Mike

Re: RFR: 8248268: Support KWP in addition to KW [v3]

2021-03-23 Thread Greg Rubin 
On Mon, 22 Mar 2021 21:43:31 GMT, Valerie Peng  wrote:

>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher 
>> transformation. 
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>> 
>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed 
>> to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil 
>> class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded 
>> classes which extend FeedbackCipher and used in KeyWrapCipher class. To 
>> minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto 
>> operation over the same input buffer which is allocated and managed by 
>> KeyWrapCipher class. 
>> 
>> Also note that existing AESWrap impl does not take IV. However, the 
>> corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to 
>> both KW and KWP.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>   AES/KWP/NoPadding

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 41:

> 39:  * and represents AES cipher in KW mode.
> 40:  */
> 41: class AESKeyWrap extends FeedbackCipher {

I see lots of unsupported operations and `encrypt/decryptFinal` ignores their 
output parameters. Should we be extending `FeedbackCipher` if so much doesn't 
seem to quite fit?

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 155:

> 153: " be at least 16 bytes and multiples of 8");
> 154: }
> 155: // assert ptOfs == 0; ct == pt; ctOfs == 0;

Is this a missing code assertion?

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java line 193:

> 191: if (!Arrays.equals(ivOut, 0, ICV1.length, this.iv, 0, 
> ICV1.length)) {
> 192: throw new IllegalBlockSizeException("Integrity check 
> failed");
> 193: }

It feels like an odd asymmetry that we validate the IV upon decryption in 
`AESKeyWrap` but the IV is prepended in `KeyWrapCipher.writeIvSemiBlock`.  I'm 
worried that by separating this logic like this it is easier for us to get it 
wrong (or break it in the future).

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 
69:

> 67: if (!Arrays.equals(ivAndLen, 0, ICV2.length, icv, 0, 
> ICV2.length)) {
> 68: throw new IllegalBlockSizeException("Integrity check failed");
> 69: }

While I cannot find any public discussion of this, I'm always uncomfortable 
checking the plaintext (prior to authentication) against a known value in 
non-constant time. I'm worried that this (and the equivalent in the unpadded 
version) might be a problem in the future.

src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java line 
246:

> 244: int outLen = validateIV(ivAndLen, this.iv);
> 245: // check padding bytes
> 246: int padLen = ctLen - outLen;

Can we add an explicit check that `0 <= padLen < SEMI_BLKSIZE`?

src/java.base/share/classes/com/sun/crypto/provider/KWUtil.java line 87:

> 85:  */
> 86: static final void W_INV(byte[] in, int inLen, byte[] ivOut,
> 87: SymmetricCipher cipher) {

The asymmetry between `W` not taking an IV but `W_INV` returning an IV also 
bothers me and seems to make this harder to use safely.

src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line 507:

> 505: } else {
> 506: outLen = cipher.encryptFinal(dataBuf, 0, dataIdx, null, 
> -1);
> 507: }

Can we extract this shared logic (among the different versions of 
`engineDoFinal`) into a separate helper method so that the different 
`engineDoFinal` methods just need to handle their specific differences (such as 
returning `Arrays.copyOf(dataBuf, outLen)` or calling 
`System.arraycopy(dataBuf, 0, out, outOfs, outLen); return outLen;`).

src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line 660:

> 658: @Override
> 659: protected byte[] engineWrap(Key key)
> 660: throws IllegalBlockSizeException, InvalidKeyException {

Is it okay that we can call `cipher.init(Cipher.ENCRYPT_MODE, ...)` and then 
use it with `cipher.wrap()`?

Also, can we simply delegate the heavy lifting to `engineDoFinal()` (or the new 
suggested helper method) rather than duplicating this logic here?

test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/NISTWrapKAT.java line 105:

> 103: 
> 104: @DataProvider
> 105: public Object[][] testData() {

Can we please add test cases for `AES/KWP/NoPadding` where the input is an even 
multiple of 8? We've [seen bugs in this case 
before](https://github.com/pyca/cryptography/issues/4156).

test/jdk/com/sun/crypto/provider/Cipher/KeyWrap/TestGeneral.java line 50:

> 48: 
> 49:

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

2021-03-23 Thread Bernd Eckenfels 
Hello,

I agree with the need for such a facility.

Instead, or in addition to a key log a session handshake listener with access 
to the handshake result (and the master key) would also be useful for auditing, 
renegotiation limiting and key logging. It can even be used for things like 
priming introspecting firewalls.

There is not yet a good official platform API with access to that kind of 
information (and proxying client Hello packages to get the offered ciphers is 
really ugly). With the API an Adapter which can write NSS Keylogs can be 
provided by users and you don’t have to worry about having debug logging Code 
expose secrets.

Gruss
Bernd

--
http://bernd.eckenfels.net

Von: security-dev  im Auftrag von 
ra...@web.de 
Gesendet: Tuesday, March 23, 2021 6:36:06 PM
An: security-dev@openjdk.java.net 
Betreff: Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS 
keys

Hi all,

I very much appreciate @SalusaSecondus' idea for providing a key logger.

For, when working with networks, it's quite natural to analyze message flow
with help of wireshark. In TLS 1.3 this isn't possible without a key log
because most parts of the handshake messages are encrypted. So, if both,
client and server, are Java apps, it isn't possible to trace the message flow
with wireshark. That's a great disadvantage.

To give an example: I'm running a https client based on SSLEngine and an
AsynchronousSocketChannel. The entries in the log provided by 
javax.net.debug=ssl
arise from SSLEngine, but the messages itself are sent by the channel. So it is
not possible to check what messages are actually sent over the network
(I could have made a programming error in using the data provided by
the SSLEngine or something could go wrong within the channel).
Therefore, being able to produce a key log on the Java client side and
to observe the messages and their content in wireshark, would be very
helpful.

Concerning the security issue: Of course, holding keys is always a risk.
But if one stores the output of javax.net.debug in a file, then an attacker
who has access to the system could read decrypted messages as well. But, of
course, the implementation of a key logger in Java has to ensure that no
key log is produced by default but only if it is explicitly enabled
(similar to javax.net.debug).

I would be very glad if there would be a chance to implement @SalusaSecondus'
proposal in some way because a key logger would be really helpful for
doing networking with Java.

Regards,

Ralph





Gesendet: Freitag, 19. März 2021 um 13:48 Uhr
Von: "Sean Mullan" 
An: security-dev@openjdk.java.net
Betreff: Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS 
keys
On Thu, 18 Mar 2021 21:26:28 GMT, SalusaSecondus 
 wrote:

>> It is not good practice to leave secret information in debug log. Also, it 
>> may be not a good practice to introduce new logger format, including file 
>> and NSS format, into the SSLLogger. Someone also may want to introduce log 
>> format for MSS or XSS as well. Instead, please consider to make use of the 
>> features of Java Logger if you want to write the log to files, or use any 
>> special format.
>
> @XueleiFan I'd really like to move this forward but I'm uncertain what 
> changes you want me to make. This extra debugging information will be very 
> valuable to those of us debugging Java TLS connections.

I am also not comfortable adding this feature to the JDK, especially since 
every build of the JDK would by default have this feature enabled. Logging 
sensitive information to log files is not good security practice (there are 
many references I could cite). I also think it would be too easy to 
accidentally leave the system property enabled or forget to remove the file.

-

PR: https://git.openjdk.java.net/jdk/pull/2896

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

2021-03-23 Thread raell 
Hi all, 

I very much appreciate @SalusaSecondus' idea for providing a key logger. 

For, when working with networks, it's quite natural to analyze message flow 
with help of wireshark. In TLS 1.3 this isn't possible without a key log 
because most parts of the handshake messages are encrypted. So, if both, 
client and server, are Java apps, it isn't possible to trace the message flow 
with wireshark. That's a great disadvantage. 

To give an example: I'm running a https client based on SSLEngine and an 
AsynchronousSocketChannel. The entries in the log provided by 
javax.net.debug=ssl 
arise from SSLEngine, but the messages itself are sent by the channel. So it is 
not possible to check what messages are actually sent over the network 
(I could have made a programming error in using the data provided by 
the SSLEngine or something could go wrong within the channel). 
Therefore, being able to produce a key log on the Java client side and 
to observe the messages and their content in wireshark, would be very 
helpful.

Concerning the security issue: Of course, holding keys is always a risk. 
But if one stores the output of javax.net.debug in a file, then an attacker 
who has access to the system could read decrypted messages as well. But, of 
course, the implementation of a key logger in Java has to ensure that no 
key log is produced by default but only if it is explicitly enabled 
(similar to javax.net.debug). 

I would be very glad if there would be a chance to implement @SalusaSecondus' 
proposal in some way because a key logger would be really helpful for 
doing networking with Java. 

Regards, 

Ralph 

 
 
 

Gesendet: Freitag, 19. März 2021 um 13:48 Uhr
Von: "Sean Mullan" 
An: security-dev@openjdk.java.net
Betreff: Re: RFR: 8262880: Add support for the NSS Key Log Format for SSL/TLS 
keys
On Thu, 18 Mar 2021 21:26:28 GMT, SalusaSecondus 
 wrote:

>> It is not good practice to leave secret information in debug log. Also, it 
>> may be not a good practice to introduce new logger format, including file 
>> and NSS format, into the SSLLogger. Someone also may want to introduce log 
>> format for MSS or XSS as well. Instead, please consider to make use of the 
>> features of Java Logger if you want to write the log to files, or use any 
>> special format.
>
> @XueleiFan I'd really like to move this forward but I'm uncertain what 
> changes you want me to make. This extra debugging information will be very 
> valuable to those of us debugging Java TLS connections.

I am also not comfortable adding this feature to the JDK, especially since 
every build of the JDK would by default have this feature enabled. Logging 
sensitive information to log files is not good security practice (there are 
many references I could cite). I also think it would be too easy to 
accidentally leave the system property enabled or forget to remove the file.

-

PR: https://git.openjdk.java.net/jdk/pull/2896

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

2021-03-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 that made the ECPrivateKey 
> change in a different place.  The new exception handling is a result of no 
> longer having the native library.  Many of the checks waited until 
> generateSecret() to send the keys to the native library. Now that native is 
> gone, checks can happen when keys are provided to the methods and proper 
> exceptions can be thrown instead of wrapping everything as a ProviderException
> 
> thanks,
> 
> Tony

Anthony Scarpino has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains four commits:

 - update test bug id
 - Simpler fix for ECPrivateKey
 - merge with 8261502
 - initial change

-

Changes: https://git.openjdk.java.net/jdk/pull/2659/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2659=03
  Stats: 203 lines in 2 files changed: 137 ins; 32 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2659.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2659/head:pull/2659

PR: https://git.openjdk.java.net/jdk/pull/2659

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Andrew Haley 
On Tue, 23 Mar 2021 16:20:47 GMT, Ludovic Henry  wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>
>>Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: 
>> https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Marked as reviewed by luhenry (Author).

> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 
> > > > maintainers to accept this (and few other, like jep-388, as we depend 
> > > > on it) contribution.
> > > 
> > > 
> > > To the extent that 11u has fixed policies :) we definitely have a policy 
> > > of accepting patches to keep 11u working on current hardware. So yes.
> > 
> > 
> > @lewurm That sounds like a green flag for you and jep-388 (with its 
> > R18_RESERVED functionality) ;)
> 
> Thanks, @theRealAph, and @VladimirKempik . We are on it!

It's going to be tricky to do in a really clean way, given some of the 
weirdnesses of the ABI. However, I think there's probably a need for it

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Ludovic Henry 
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
>> windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
>> JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with 
>> necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
>> required on macOS/AArch64 platform. It's implemented with 
>> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
>> thread, so W^X mode change relates to the java thread state change (for java 
>> threads). In most cases, JVM executes in write-only mode, except when 
>> calling a generated stub like SafeFetch, which requires a temporary switch 
>> to execute-only mode. The same execute-only mode is enabled when a java 
>> thread executes in java or native states. This approach of managing W^X mode 
>> turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>
>Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: 
> https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by luhenry (Author).

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Monica Beckwith 
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
>> windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
>> JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with 
>> necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
>> required on macOS/AArch64 platform. It's implemented with 
>> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
>> thread, so W^X mode change relates to the java thread state change (for java 
>> threads). In most cases, JVM executes in write-only mode, except when 
>> calling a generated stub like SafeFetch, which requires a temporary switch 
>> to execute-only mode. The same execute-only mode is enabled when a java 
>> thread executes in java or native states. This approach of managing W^X mode 
>> turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>
>Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: 
> https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by mbeckwit (Author).

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Monica Beckwith 
On Tue, 23 Mar 2021 14:01:12 GMT, Vladimir Kempik  wrote:

> > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 
> > > maintainers to accept this (and few other, like jep-388, as we depend on 
> > > it) contribution.
> > 
> > 
> > To the extent that 11u has fixed policies :) we definitely have a policy of 
> > accepting patches to keep 11u working on current hardware. So yes.
> 
> @lewurm That sounds like a green flag for you and jep-388 (with its 
> R18_RESERVED functionality) ;)

Thanks, @theRealAph, and @VladimirKempik . We are on it!

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Vladimir Kempik 
On Tue, 23 Mar 2021 13:58:03 GMT, Andrew Haley  wrote:

> > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 
> > maintainers to accept this (and few other, like jep-388, as we depend on 
> > it) contribution.
> 
> To the extent that 11u has fixed policies :) we definitely have a policy of 
> accepting patches to keep 11u working on current hardware. So yes.

@lewurm That sounds like a green flag for you and jep-388 (with its 
R18_RESERVED functionality) ;)

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Andrew Haley 
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
>> windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
>> JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with 
>> necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
>> required on macOS/AArch64 platform. It's implemented with 
>> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
>> thread, so W^X mode change relates to the java thread state change (for java 
>> threads). In most cases, JVM executes in write-only mode, except when 
>> calling a generated stub like SafeFetch, which requires a temporary switch 
>> to execute-only mode. The same execute-only mode is enabled when a java 
>> thread executes in java or native states. This approach of managing W^X mode 
>> turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>
>Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: 
> https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by aph (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Andrew Haley 
On Tue, 23 Mar 2021 13:54:24 GMT, Andrew Haley  wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>
>>Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: 
>> https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Marked as reviewed by aph (Reviewer).

> [ Back-porting this patch to JDK 11] depends on the will of openjdk11 
> maintainers to accept this (and few other, like jep-388, as we depend on it) 
> contribution.

To the extent that 11u has fixed policies :)  we definitely have a policy of 
accepting patches to keep 11u working on current hardware. So yes.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Vladimir Kempik 
On Tue, 23 Mar 2021 13:26:19 GMT, Anton Kozlov  wrote:

>> Build changes still look good. Hope you can get this done now! :)
>
>> > No, no, no! I am not suggesting you change anything else, just that
>> > you do not define contentless macros. You might as well define it
>> > to be something, and true is a reasonable default, that's all. It's
>> > not terribly important, it's just good practice.
>> 
>> I'm quite prepared to drop this if it's holding up the port. It's a style 
>> thing, but it's not critical.
> 
> Sorry, I missed your reply.
> 
> R18_RESERVED is also defined in 
> https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96.
>  I think changing the value here and there would be slightly out of the scope 
> of this PR, so I would prefer to avoid the suggested change. 
> 
> The biggest argument from my side is that the current macro value is 
> consistent with the rest of the macros in this file. For example 
> https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
> and 
> https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137
> 
> But 
> https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
> and   
> https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

Hello
That depends on the will of openjdk11 maintainers to accept this (and few 
other, like jep-388, as we depend on it) contribution.

> 23 марта 2021 г., в 16:39, drej1 ***@***.***> написал(а):
> 
> 
> So, where are we up to now? Are we done yet?
> 
> Hello
> we would like to get approval for the final version we have now and then 
> integrate this pr as soon as Mark will target it to jdk17
> 
> Hi there, will this be also supported backwards? To support java11 LTS 
> version?
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> .
>

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Anton Kozlov 
On Tue, 23 Mar 2021 12:49:34 GMT, Magnus Ihse Bursie  wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>
>>Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: 
>> https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Build changes still look good. Hope you can get this done now! :)

> > No, no, no! I am not suggesting you change anything else, just that
> > you do not define contentless macros. You might as well define it
> > to be something, and true is a reasonable default, that's all. It's
> > not terribly important, it's just good practice.
> 
> I'm quite prepared to drop this if it's holding up the port. It's a style 
> thing, but it's not critical.

Sorry, I missed your reply.

R18_RESERVED is also defined in 
https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96.
 I think changing the value here and there would be slightly out of the scope 
of this PR, so I would prefer to avoid the suggested change. 

The biggest argument from my side is that the current macro value is consistent 
with the rest of the macros in this file. For example 
https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
and 
https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137

But 
https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
and   
https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Erik Joelsson 
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
>> windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
>> JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with 
>> necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
>> required on macOS/AArch64 platform. It's implemented with 
>> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
>> thread, so W^X mode change relates to the java thread state change (for java 
>> threads). In most cases, JVM executes in write-only mode, except when 
>> calling a generated stub like SafeFetch, which requires a temporary switch 
>> to execute-only mode. The same execute-only mode is enabled when a java 
>> thread executes in java or native states. This approach of managing W^X mode 
>> turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>
>Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: 
> https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Build changes look good.

-

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]

2021-03-23 Thread Magnus Ihse Bursie 
On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov  wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
>> windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
>> JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with 
>> necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
>> required on macOS/AArch64 platform. It's implemented with 
>> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
>> thread, so W^X mode change relates to the java thread state change (for java 
>> threads). In most cases, JVM executes in write-only mode, except when 
>> calling a generated stub like SafeFetch, which requires a temporary switch 
>> to execute-only mode. The same execute-only mode is enabled when a java 
>> thread executes in java or native states. This approach of managing W^X mode 
>> turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>
>Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: 
> https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Build changes still look good. Hope you can get this done now! :)

-

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

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

2021-03-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/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional 
commit since the last revision:

  Removed @since from nextDouble ThreadLocalRandom

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/4562dd13..22ea21d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=1292=34
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1292=33-34

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]

2021-03-23 Thread Vladimir Kempik 
On Tue, 23 Mar 2021 09:54:16 GMT, Andrew Haley  wrote:

> So, where are we up to now? Are we done yet?

Hello
we would like to get approval for the final version we have now and then 
integrate this pr as soon as Mark will target it to jdk17

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]

2021-03-23 Thread Andrew Haley 
On Tue, 23 Mar 2021 09:53:54 GMT, Andrew Haley  wrote:

>>> @theRealAph, could you elaborate on what is need to be done for [#2200 
>>> (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
>> 
>> I think that what you've got now is fine.
>
>> _Mailing list message from [Andrew Haley](mailto:a...@redhat.com) on 
>> [build-dev](mailto:build-...@openjdk.java.net):_
>> 
>> On 3/15/21 6:56 PM, Anton Kozlov wrote:
>> 
>> > On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley  wrote:
>> > > > We always check for `R18_RESERVED` with `#if(n)def`, is there any 
>> > > > reason to define the value for the macro?
>> > > 
>> > > 
>> > > Robustness, clarity, maintainability, convention. Why not?
>> > 
>> > 
>> > I've tried to implement the suggestion, but it pulled more unnecessary 
>> > changes. It makes the intended way to check the condition less clear 
>> > (`#ifdef` and not `#if`).
>> 
>> No, no, no! I am not suggesting you change anything else, just that
>> you do not define contentless macros. You might as well define it
>> to be something, and true is a reasonable default, that's all. It's
>> not terribly important, it's just good practice.
> 
> I'm quite prepared to drop this if it's holding up the port. It's a style 
> thing, but it's not critical.

So, where are we up to now? Are we done yet?

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]

2021-03-23 Thread Andrew Haley 
On Fri, 12 Mar 2021 16:32:10 GMT, Andrew Haley  wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains 105 commits:
>> 
>>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk 
>> into jdk-macos
>>  - workaround JDK-8262895 by disabling subtest
>>  - Fix typo
>>  - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
>>  - JDK-8259937: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Fix after JDK-8259539, partially revert preconditions
>>  - JDK-8260471: bsd_aarch64 part
>>  - JDK-8259539: bsd_aarch64 part
>>  - JDK-8257828: bsd_aarch64 part
>>  - ... and 95 more: 
>> https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834
>
>> @theRealAph, could you elaborate on what is need to be done for [#2200 
>> (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
> 
> I think that what you've got now is fine.

> _Mailing list message from [Andrew Haley](mailto:a...@redhat.com) on 
> [build-dev](mailto:build-...@openjdk.java.net):_
> 
> On 3/15/21 6:56 PM, Anton Kozlov wrote:
> 
> > On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley  wrote:
> > > > We always check for `R18_RESERVED` with `#if(n)def`, is there any 
> > > > reason to define the value for the macro?
> > > 
> > > 
> > > Robustness, clarity, maintainability, convention. Why not?
> > 
> > 
> > I've tried to implement the suggestion, but it pulled more unnecessary 
> > changes. It makes the intended way to check the condition less clear 
> > (`#ifdef` and not `#if`).
> 
> No, no, no! I am not suggesting you change anything else, just that
> you do not define contentless macros. You might as well define it
> to be something, and true is a reasonable default, that's all. It's
> not terribly important, it's just good practice.

I'm quite prepared to drop this if it's holding up the port. It's a style 
thing, but it's not critical.

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Integrated: 8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with Read timed out

2021-03-23 Thread Sibabrata Sahoo 
On Mon, 22 Mar 2021 10:45:34 GMT, Sibabrata Sahoo  wrote:

> The Test getting timeout intermittently because the SO_TIMEOUT of 5 seconds 
> set on sslServerSocket. This time interval could be inadequate when the 
> machine is too busy. Also it looks setting SO_TIMEOUT is unnecessary here. So 
> the statement has been removed.

This pull request has now been integrated.

Changeset: 036ae0ea
Author:Sibabrata Sahoo 
URL:   https://git.openjdk.java.net/jdk/commit/036ae0ea
Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8225438: javax/net/ssl/TLSCommon/TestSessionLocalPrincipal.java failed with 
Read timed out

Reviewed-by: xuelei, rhalade, hchao

-

PR: https://git.openjdk.java.net/jdk/pull/3116

Integrated: 8247895: SHA1PRNGReseed.java is calling setSeed(0)

2021-03-23 Thread Sibabrata Sahoo 
On Mon, 22 Mar 2021 10:30:07 GMT, Sibabrata Sahoo  wrote:

> The Test is updated to use positive integer as seed for SecureRandom.

This pull request has now been integrated.

Changeset: 5a51d709
Author:Sibabrata Sahoo 
URL:   https://git.openjdk.java.net/jdk/commit/5a51d709
Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8247895: SHA1PRNGReseed.java is calling setSeed(0)

Reviewed-by: weijun, rhalade

-

PR: https://git.openjdk.java.net/jdk/pull/3114