If I remember correct, there was a serious performance impact when
trying to check every crypto operations before using them (suspend for
seconds or minutes, I cannot remember numbers). That's the underlying
reason why most of the checking got removed in latest JDK releases.
The best approach
Hi Xuelei,
Thanks for having a look.
I'll work on a benchmark to see the impact of this proposal.
I have a couple of ideas but wish we could discuss them before moving to
their implementation.
#1
...
Under the assumption that security providers do not change in run
Hi Martin,
Would you mind evaluate the performance impact of the fix and improve it
accordingly?
Thanks,
Xuelei
On 5/7/2019 12:45 PM, Martin Balao wrote:
Hi,
I'd like to propose a fix for "8223482: Unsupported ciphersuites may be
offered by a TLS client" [1]:
* http://cr.openjdk.java.net
Hi,
I'd like to propose a fix for "8223482: Unsupported ciphersuites may be
offered by a TLS client" [1]:
* http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.webrev.00/
Testing:
* FipsModeTLS12 (after Webrev.00 modifications) reproduces this bug and
works as a regression test
* No
On Thu, Mar 21, 2019 at 11:01:32AM +0800, Weijun Wang wrote:
> All of them at
>
>https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams
>
> You might want to add more descriptions.
Below is the commentary I've collated from GitHub, along with my
responses.
-
src/java.securit
On 5/7/2019 9:16 AM, Sean Mullan wrote:
On 5/7/19 11:28 AM, Xuelei Fan wrote:
What do you think if com.sun.security.crl.readtimeout is not set,
CRL_READ_TIMEOUT is set as the same value as CRL_CONNECT_TIMEOUT?
There may be good reasons you would want different values for these two
properti
On 5/7/19 11:28 AM, Xuelei Fan wrote:
What do you think if com.sun.security.crl.readtimeout is not set,
CRL_READ_TIMEOUT is set as the same value as CRL_CONNECT_TIMEOUT?
There may be good reasons you would want different values for these two
properties, so if com.sun.security.crl.readtimeout i
Updated webrev at
http://cr.openjdk.java.net/~weijun/8200400/webrev.02/
The CSR at https://bugs.openjdk.java.net/browse/JDK-821433 is also updated.
I reuse the Logger name "javax.security.sasl" used by our SASL providers. The
name looks high-level enough to be used here.
Thanks,
Max
> On
What do you think if com.sun.security.crl.readtimeout is not set,
CRL_READ_TIMEOUT is set as the same value as CRL_CONNECT_TIMEOUT?
Otherwise, looks fine to me.
Xuelei
On 5/7/2019 7:28 AM, Sean Mullan wrote:
Please review this change to add a system property for configuring the
read timeout w
Please review this change to add a system property for configuring the
read timeout when downloading CRLs with a default value of 15 seconds.
Currently there is no timeout so downloads of large CRLs can block for a
long time or indefinitely. Current workaround is to use the
sun.net.client.defau
Ping: can I please have a review for this?
From: Langer, Christoph
Sent: Donnerstag, 2. Mai 2019 14:55
To: 'jdk8u-...@openjdk.java.net' ; security-dev
Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates
(Integration for JEP 319: Root Certificates)
Hi,
as was already discu
Hi Xuelei,
looks good to me as well.
best regards,
-- daniel
On 05/05/2019 16:18, Xuelei Fan wrote:
All good catches!
I made the update accordingly. Here is the new webrev:
http://cr.openjdk.java.net/~xuelei/8219991/webrev.03/
Thanks,
Xuelei
On 5/3/2019 11:27 PM, Alan Bateman wrote:
O
12 matches
Mail list logo