On Thu, 3 Aug 2023 20:51:33 GMT, Valerie Peng wrote:
> This change addresses the scenario where a certificate is first stored as
> part of a certificate chain and then stored again as a certificate
> corresponding to a PrivateKey entry. Newer version of NSS errors out with
> CKR_GENERAL_ERROR
On Tue, 22 Aug 2023 17:14:27 GMT, Jamil Nimeh wrote:
> This looks good. Does the bug need a noreg label since this is addressing an
> existing test failure?
There is a test update with this bug id and no need to add noreg label. Rajan
confirmed this as well. :)
-
PR Comment:
On Thu, 3 Aug 2023 20:51:33 GMT, Valerie Peng wrote:
> This change addresses the scenario where a certificate is first stored as
> part of a certificate chain and then stored again as a certificate
> corresponding to a PrivateKey entry. Newer version of NSS errors out with
> CKR_GENERAL_ERROR
This PR updates the various security classes using Cleaner with the try/finally
pattern. Also noticed that SunJCE's PBEKey impl class overrides the destroy()
method but not the isDestroyed() method, fixed this inconsistency as well.
Thanks in advance for the review!
-
Commit
On Thu, 3 Aug 2023 20:51:33 GMT, Valerie Peng wrote:
> This change addresses the scenario where a certificate is first stored as
> part of a certificate chain and then stored again as a certificate
> corresponding to a PrivateKey entry. Newer version of NSS errors out with
> CKR_GENERAL_ERROR
On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma wrote:
> In addition to the issue
> [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing
> the scope from benchmark to thread for below benchmark files having shared
> state, also which fixes few of the benchmarks
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added
On Tue, 27 Jun 2023 18:29:45 GMT, Tim Prinzing wrote:
>> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408:
>>
>>> 406: @Override
>>> 407: public int read(ByteBuffer buf) throws IOException {
>>> 408: if (!SocketReadEvent.enabled()) {
>>
>> The read/write
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added
On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin wrote:
> An exception event will be emitted. The event is disabled by default, but
> there is ongoing work on a throttling mechanism, so it can be always-on.
Good, I think the exception cases are probably the most interesting for this
area when it
On Wed, 2 Aug 2023 20:09:39 GMT, Alan Bateman wrote:
> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling
> https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event
> generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event
> for
12 matches
Mail list logo
