The test sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java caused sporadic
noise because sometimes it opens more file handles than expected. It was moved
to a manual test to quiesce this
([JDK-8257670](https://bugs.openjdk.java.net/browse/JDK-8257670))
It would be good, however, to have this te
On Sat, 5 Dec 2020 23:23:47 GMT, Jamil Nimeh wrote:
> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
> throw NPE when getParameters() is called. It will now generate parameters
> containing a random nonce on each pre-init call to getParameters().
> Post-initializati
> Hi, Please review
> Windows mapping for file into memory could not happen to reserved memory.
> In mapping CDS archive we first reserve enough memory then before mapping,
> release them. For cds archive and using class space, need split the whole
> space into two, that is, release the whole
> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
> throw NPE when getParameters() is called. It will now generate parameters
> containing a random nonce on each pre-init call to getParameters().
> Post-initialization calls to the getParameters() method will always ret
On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move to share/data, and move jdwp.spec to java.se
>
> I have reviewed all lines in the patch file with or near
Oh, one other thing in case you weren't talking about this in the
context of Cipher and instead were talking about the AlgorithmParameters
object itself. If that's all you've got in scope one approach is to
call getParameterSpec(IvParameterSpec.class).getIV(); That will give
you the byte arra
Hi Bernd, it's not a stupid question at all. I think what you might be
looking for is Cipher.getIV()? In the case of ChaCha20-Poly1305, that
method returns the nonce as a byte array where getParameters() returns
an AlgorithmParameters object where the encoding is consistent with RFC
8103.
B
BTW stupid - somewhat related - question, why does the nonce to be parsed out
of a DER blob, shouldn’t there be an getter on the Parameter Spec object? Many
protocols would need the raw array, is there a matching spec - or should we add
one?
Gruss
Bernd
--
http://bernd.eckenfels.net
___
> This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not
> reliable if there are some other test cases or applications running at the
> same time. It's a good manual test, but might be not suitable for OpenJDK
> automation regression test if it could be impacted. Move it
On Mon, 7 Dec 2020 23:35:49 GMT, Xue-Lei Andrew Fan wrote:
> This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not
> reliable if there are some other test cases or applications running at the
> same time. It's a good manual test, but might be not suitable for OpenJDK
>
On Mon, 7 Dec 2020 23:44:41 GMT, Jamil Nimeh wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> typo correction
>
> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java line 39:
>
>> 37: * @run main/manu
On Mon, 7 Dec 2020 23:35:49 GMT, Xue-Lei Andrew Fan wrote:
> This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not
> reliable if there are some other test cases or applications running at the
> same time. It's a good manual test, but might be not suitable for OpenJDK
>
On Mon, 7 Dec 2020 23:35:49 GMT, Xue-Lei Andrew Fan wrote:
> This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not
> reliable if there are some other test cases or applications running at the
> same time. It's a good manual test, but might be not suitable for OpenJDK
>
This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not
reliable if there are some other test cases or applications running at the same
time. It's a good manual test, but might be not suitable for OpenJDK
automation regression test if it could be impacted. Move it to manu
On Mon, 7 Dec 2020 22:32:23 GMT, Jamil Nimeh wrote:
>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
>> throw NPE when getParameters() is called. It will now generate parameters
>> containing a random nonce on each pre-init call to getParameters().
>> Post-initiali
> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
> throw NPE when getParameters() is called. It will now generate parameters
> containing a random nonce on each pre-init call to getParameters().
> Post-initialization calls to the getParameters() method will always ret
On Mon, 7 Dec 2020 19:53:27 GMT, Valerie Peng wrote:
>> Jamil Nimeh has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> pre-init getParameters nonce data is now a local variable
>
> src/java.base/share/classes/com/sun/crypto/provider/ChaCha2
On Mon, 7 Dec 2020 19:35:27 GMT, Sean Mullan wrote:
>> Jamil Nimeh has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> pre-init getParameters nonce data is now a local variable
>
> src/java.base/share/classes/com/sun/crypto/provider/ChaCha20
On Mon, 7 Dec 2020 17:50:25 GMT, Jamil Nimeh wrote:
>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
>> throw NPE when getParameters() is called. It will now generate parameters
>> containing a random nonce on each pre-init call to getParameters().
>> Post-initiali
On Mon, 7 Dec 2020 17:50:25 GMT, Jamil Nimeh wrote:
>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
>> throw NPE when getParameters() is called. It will now generate parameters
>> containing a random nonce on each pre-init call to getParameters().
>> Post-initiali
On Mon, 7 Dec 2020 19:35:33 GMT, Sean Mullan wrote:
>> Jamil Nimeh has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> pre-init getParameters nonce data is now a local variable
>
> Marked as reviewed by mullan (Reviewer).
The test should pr
On Mon, 7 Dec 2020 17:50:25 GMT, Jamil Nimeh wrote:
>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
>> throw NPE when getParameters() is called. It will now generate parameters
>> containing a random nonce on each pre-init call to getParameters().
>> Post-initiali
On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
>
> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
> throw NPE when getParameters() is called. It will now generate parameters
> containing a random nonce on each pre-init call to getParameters().
> Post-initialization calls to the getParameters() method will always ret
On Mon, 7 Dec 2020 15:42:19 GMT, Sean Mullan wrote:
>> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
>> throw NPE when getParameters() is called. It will now generate parameters
>> containing a random nonce on each pre-init call to getParameters().
>> Post-initiali
On Fri, 4 Dec 2020 22:58:07 GMT, Xue-Lei Andrew Fan wrote:
> In the SunJSSE provider implementation, there are a few class fields are not
> used other than the constructors. Those fields could be removed and replaced
> with local variables.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-825
On Sat, 5 Dec 2020 23:23:47 GMT, Jamil Nimeh wrote:
> This fix corrects a problem where ChaCha20-Poly1305 objects prior to init
> throw NPE when getParameters() is called. It will now generate parameters
> containing a random nonce on each pre-init call to getParameters().
> Post-initializati
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actually* used by
> make for the whole build.)
>
> These data files should move t
On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie wrote:
>> @erikj79 Good point, that makes much more sense.
>
> I'm not sure about the formal process for suggesting changes to a delivered
> JEP, but this is the text I suggest should replace the current definition of
> the new scheme:
>
>
On Fri, 4 Dec 2020 15:17:06 GMT, Magnus Ihse Bursie wrote:
>> Regarding the chosen layout. Did you consider following the existing pattern
>> of src//{share,}/data?
>
> @erikj79 Good point, that makes much more sense.
I'm not sure about the formal process for suggesting changes to a delivered
On Mon, 7 Dec 2020 11:08:37 GMT, Conor Cleary wrote:
>> test/jdk/sun/net/www/http/KeepAliveStreamCleaner/KeepAliveStreamCleanerTestDriver.java
>> line 26:
>>
>>> 24: /*
>>> 25: * @test
>>> 26: * @modules java.base/sun.net.www.http
>>
>> Hi Conor,
>>
>> Can you add:
>>
>> @bug 8255124
>>
>
On Mon, 7 Dec 2020 10:55:06 GMT, Daniel Fuchs wrote:
>> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously
>> seen to fail with an IllegalMonitorStateException. This failure was caused
>> by the use of `wait()` in a non synchronized block. This failure was
>> mitigated t
On Mon, 7 Dec 2020 09:52:47 GMT, Conor Cleary wrote:
> The KeepAliveStreamCleaner in sun.net.ww.http package had been previously
> seen to fail with an IllegalMonitorStateException. This failure was caused by
> the use of `wait()` in a non synchronized block. This failure was mitigated
> throu
The KeepAliveStreamCleaner in sun.net.ww.http package had been previously seen
to fail with an IllegalMonitorStateException. This failure was caused by the
use of `wait()` in a non synchronized block. This failure was mitigated through
use of `await()` instead as is shown below (code can be view
34 matches
Mail list logo
