My test case is using all higher level classes that wrap SSLEngine. But on
Monday I should be able to convert it to a test that uses just the SSLEngine.
- Tim
> On Aug 3, 2018, at 6:47 PM, Xuelei Fan wrote:
>
> Hi Tim,
>
> Your concerns make sense to me. Did you have a test case that I can u
Hi Tim,
Your concerns make sense to me. Did you have a test case that I can use
to reproduce the issues?
Thanks,
Xuelei
On 8/3/2018 5:04 PM, Tim Brooks wrote:
Hi Xuelei
I pulled the JDK 11 source today and applied your patch. And then I built the
jdk to run some tests. I hope that is the
I can file a follow-on issue. However, I want to clarify what we want to
do before filing it.
Based on current exchanges: We want to update
Cipher.getParameters()/CipherSpi.engineGetParameters() with similar
format/wording as Signature.getParameters(), e.g. expanding the meaning
when null
Hi Xuelei
I pulled the JDK 11 source today and applied your patch. And then I built the
jdk to run some tests. I hope that is the correct approach.
It appears that this change resolved some of my prior issues. But I notice some
other issues. This is tested with TLS 1.2. I have not really setup
Yes I should be able to take a look this week.
> On Jul 30, 2018, at 12:13 PM, Xuelei Fan wrote:
>
> Hi Tim,
>
> Would you mind look at the code I posted in the following thread:
> http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017708.html
>
> In the update, we are trying make t
Hi Valerie,
* http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10/
* http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10.zip
New in webrev 10:
* Bug fix when private DSA/EC keys are sensitive
* I found this bug removing "attributes = compatibility" entry in
Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/
In webrev.01, the socket close may be blocked by super class close
synchronization. Updated the SSLSocketImpl.java to use handshake only
lock in the startHandshake() implementation.
Thanks,
Xuelei
On 8/1/2018 7:27 PM, Xuelei Fan
It looks fine to me, then.
Thanks,
Xuelei
On 8/3/2018 10:50 AM, Sibabrata Sahoo wrote:
serverSocket.close() and serverSocket.accept() are not declared synchronized in
java/net/ServerSocket.java.
Thanks,
Siba
-Original Message-
From: Xuelei Fan
Sent: Friday, August 03, 2018 10:38 PM
T
serverSocket.close() and serverSocket.accept() are not declared synchronized in
java/net/ServerSocket.java.
Thanks,
Siba
-Original Message-
From: Xuelei Fan
Sent: Friday, August 03, 2018 10:38 PM
To: Sibabrata Sahoo ; John Jiang
Cc: [email protected]
Subject: Re: [11] RFR:
Hi Siba,
The use of SO_TIMEOUT may cause intermittent failure in JDK test
environment. I'm not very sure if serverSocket.close() and
serverSocket.accept() are synchronized or not. If they did, there may
be a dead waiting condition.
Xuelei
On 8/3/2018 2:32 AM, Sibabrata Sahoo wrote:
Hi Xu
Thanks.
Regards,
Sean.
On 03/08/18 14:02, Weijun Wang wrote:
You don't need to modify PBEKeyFactory.java anymore. Everything else is fine.
--Max
On Aug 3, 2018, at 8:49 PM, Seán Coffey wrote:
Whoops! Patching too fast. Yes- that field is redundant for jdk8u.
I've removed its use. Webrev u
You don't need to modify PBEKeyFactory.java anymore. Everything else is fine.
--Max
> On Aug 3, 2018, at 8:49 PM, Seán Coffey wrote:
>
> Whoops! Patching too fast. Yes- that field is redundant for jdk8u.
>
> I've removed its use. Webrev updated in place.
>
> Regards,
> Sean.
>
> On 03/08/18
Whoops! Patching too fast. Yes- that field is redundant for jdk8u.
I've removed its use. Webrev updated in place.
Regards,
Sean.
On 03/08/18 12:14, Weijun Wang wrote:
Why does PBEKey::new still have a useClear parameter then?
On Aug 3, 2018, at 6:49 PM, Seán Coffey wrote:
Max,
I've applie
Why does PBEKey::new still have a useClear parameter then?
> On Aug 3, 2018, at 6:49 PM, Seán Coffey wrote:
>
> Max,
>
> I've applied the same patch to jdk8u-dev. It's pretty much a straightforward
> port. Some small parts didn't apply cleanly since jdk8u doesn't involve use
> of Finalizer/Cl
Max,
I've applied the same patch to jdk8u-dev. It's pretty much a
straightforward port. Some small parts didn't apply cleanly since jdk8u
doesn't involve use of Finalizer/Cleaner in some areas.
i.e.
around line 80 : src/share/classes/com/sun/crypto/provider/PBEKey.java
and in constructor of
Thanks for your review Weijun. I'll update with your comments [1] and
push shortly.
regards,
Sean.
[1]
com/sun/crypto/provider/KeyProtector.java:
(reverted to as was)
187: KeyFactory kFac = KeyFactory.getInstance(oidName);
return kFac.generatePrivate(new
PKC
Hi Xuelei/John,
I did a minor change to handle graceful shutdown of server thread along with
handling timeout for long waiting accept().
Webrev: http://cr.openjdk.java.net/~ssahoo/8208496/webrev.01/
Thanks,
Siba
From: John Jiang
Sent: Friday, August 03, 2018 7:21 AM
To: Sibabrata
com/sun/crypto/provider/KeyProtector.java:
187 Key k = kFac.generatePrivate(new PKCS8EncodedKeySpec(plain));
188 return k;
No need to create a local variable "k" anymore.
JavaKeyStore.java:
128 byte[] passwordBytes = null;
No need to define so early and a
Thanks for the review Tony. Yes - no problems with tests. Copyright
updated and changeset pushed.
regards,
Sean.
On 03/08/2018 05:23, Anthony Scarpino wrote:
Looks good. Only comment is update the copyright year. No need to regenerate a
webrev. Assuming it passes all the tests I say it’s rea
19 matches
Mail list logo
