It's a nice find of the port reuse issues.
This update will turn into expected connection failure into
reading/writing interruption as the server simulate the failure by
closing the incoming connections. It's fine for this test, I think.
For lines like:
288 intOcsp.rejectConnections();
Hello!
It was noticed, that SunMSCAPI implementation of a KeyPair has a
problem: The public and the private keys share the same native handles.
As the result, when one of the keys is finalized, and its resources are
freed, the second key becomes invalid.
Would you please help review the fix
Thank you for review Jamil.
Xuelei,
Could you please take a look?
Artem
On 08/12/2016 02:38 PM, Jamil Nimeh wrote:
Thank you Artem. The fix looks good. You just need a +1 from an
official reviewer.
--Jamil
Original message
From: Artem Smotrakov
Date: 8/12/16 1:07 PM
Thank you Artem. The fix looks good. You just need a +1 from an official
reviewer.
--Jamil
Original message From: Artem Smotrakov
Date: 8/12/16 1:07 PM (GMT-08:00) To: Jamil
Nimeh , Security Dev OpenJDK
Subject: Re: [9] RFR: 8162484:
javax/net/ssl/Stapling/SSLSocketWit
No problem.
http://cr.openjdk.java.net/~asmotrak/8162484/webrev.02/
Artem
On 08/12/2016 12:02 PM, Jamil Nimeh wrote:
For the tests as we use them today we don't intend the server to
restart. The intent of SimpleOCSPServer was to be of use for a
variety of testing purposes. I don't know tha
I’ve made that change at l.970 and updated webrev.02 in-place.
Thanks.
> On 12 Aug 2016, at 19:53, Sean Mullan wrote:
>
> Looks fine, although I would probably avoid calling checkX509Certs on line
> 970 and just checking the cert right there to avoid creating the array which
> is not needed.
>
For the tests as we use them today we don't intend the server to
restart. The intent of SimpleOCSPServer was to be of use for a variety
of testing purposes. I don't know that we can say for all intended uses
that we'll *never* need to restart it. That's why I'd like to keep the
unbound socke
Looks fine, although I would probably avoid calling checkX509Certs on
line 970 and just checking the cert right there to avoid creating the
array which is not needed.
--Sean
On 08/12/2016 11:07 AM, Vincent Ryan wrote:
I’ve moved the X.509 check to earlier in the code and reverted the changes
Hi Jamil,
There was no any specific reason to remove ServerSocket.bind() call.
ServerSocket(0) constructor creates a server socket, automatically bound
to a random free port. If I am not missing something, it doesn't look
necessary to set the SO_REUSEADDR socket options if the server is not
g
Hi Artem, more comments in-line
On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
Hi Jamil,
Thank you for review. Please see inline.
On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
Hi Artem,
I'm not an official reviewer but the solution for making the servers
reject connections rather than stop an
I’ve moved the X.509 check to earlier in the code and reverted the changes to
the validateChain method.
Updated webrev is at:
http://cr.openjdk.java.net/~vinnie/8163503/webrev.02/
> On 10 Aug 2016, at 21:15, Sean Mullan wrote:
>
> On 08/10/2016 12:39 PM, Vincent Ryan wrote:
>> Yes they cou
11 matches
Mail list logo
