Changeset: 3fca37c636be
Author:xuelei
Date: 2013-10-01 20:25 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fca37c636be
8025123: SNI support in Kerberos cipher suites
Reviewed-by: weijun, xuelei
Contributed-by: Artem Smotrakov
! src/share/classes/sun/security/ssl/ClientHan
Changeset: 0d5f4f1782e8
Author:xuelei
Date: 2013-10-07 18:46 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d5f4f1782e8
6956398: make ephemeral DH key match the length of the certificate key
Reviewed-by: weijun
! src/share/classes/sun/security/ssl/ServerHandshaker.java
+
t
Changeset: fb202a8e83c9
Author:xuelei
Date: 2013-10-13 21:10 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fb202a8e83c9
8026119: Regression test DHEKeySizing.java failing intermittently
Reviewed-by: weijun
!
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/
Changeset: 1158d504e39e
Author:xuelei
Date: 2013-11-13 01:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1158d504e39e
8023147: Test DisabledShortRSAKeys.java intermittent failed
Reviewed-by: mullan
! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java
Changeset: 40d0ccd00f87
Author:xuelei
Date: 2013-11-14 16:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40d0ccd00f87
8014266: regression test AsyncSSLSocketClose.java time out.
Reviewed-by: xuelei
Contributed-by: Rajan Halade
!
test/sun/security/ssl/com/sun/net/ssl/int
Changeset: 8d35f0985dd7
Author:xuelei
Date: 2013-12-18 16:46 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d35f0985dd7
7093640: Enable client-side TLS 1.2 by default
Reviewed-by: weijun, mullan, wetmore
! src/share/classes/sun/security/ssl/ProtocolVersion.java
! src/share/
What's the platform are you using for the testing? Windows, Linux,
Solaris or Mac OS? GCM are now only implemented in SunJCE provider. I
want to make sure the crypto provider for AES-CBC, which is different
for different platforms by default, is not the major cause of the
performance impact.
Th
Networking experts, any suggestion?
Xuelei
On 3/21/2014 8:28 AM, Matthew Hall wrote:
> On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote:
>> here. Although MTU is not PMTU, but it is normally "correct".
>
> I would state, not "normally correct", but
Hi,
Please review the fix for JDK-8040062:
http://cr.openjdk.java.net/~xuelei/8040062/webrev.00/
In JDK-8036979, there are news methods are added to java.net.Socket.
These methods need to be overridden in SSL socket implementation,
sun/security/ssl/BaseSSLSocketImpl.java.
No new regression
On 4/14/2014 8:59 PM, Sean Mullan wrote:
> Looks fine to me. Can you add a relates to link to JDK-8036979 and an
> appropriate noreg label?
>
Made the update in JBS.
Thanks for the review.
Xuelei
> --Sean
>
> On 04/14/2014 06:04 AM, Xuelei Fan wrote:
>> Hi,
>>
&g
The change looks fine to me.
Xuelei
On 4/26/2014 1:22 AM, Chris Hegarty wrote:
> Hi 8u maintainers,
>
> Stupidly I mixed up testing results, and consequently pushed a new test to
> 8u-dev [1] that has a minor issue, that causes it to fail on all platforms,
> all of the time. Root cause, the ke
> - security
>
http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/
Looks fine to me. Thanks for making this update.
Xuelei
On 5/12/2014 6:03 PM, Paul Sandoz wrote:
> Hi,
>
> This is a request for review of Otavio's patch replacing StringBuffer
> with Stri
I have not read the fix. I was just wondering that this fix save the
wait time, but increase the networking traffics, and increase the
workload of KDC servers. I think the KDC timeout should be corner cases
for TCP, and it is tolerable for UDP connections. I'm not confident
that this is a cost-e
Missed the security-dev list.
On 7/7/2014 10:39 AM, Xuelei Fan wrote:
> I have not read the fix. I was just wondering that this fix save the
> wait time, but increase the networking traffics, and increase the
> workload of KDC servers. I think the KDC timeout should be corner cases
Looks fine to me. Thanks for the update.
Xuelei
On 8/20/2014 9:02 PM, Michael McMahon wrote:
> This is the recently reported fix to HttpsURLConnection.equals
>
> http://cr.openjdk.java.net/~michaelm/8055299/webrev.1/
>
> The fix includes a test. Not shown in the webrev is java key store
> file
Good catch!
Looks fine to me.
Xuelei
On 2/5/2015 7:54 PM, Weijun Wang wrote:
> Hi All
>
> A test helper tries to parse the "test.src.path" system property using
> delimiter ":". This is not correct on Windows.
>
> The fix is simply
>
> diff --git a/test/lib/testlibrary/jdk/testlibrary/SimpleS
On 9/25/2015 7:45 AM, Bradford Wetmore wrote:
>
> On 9/23/2015 2:33 AM, Simone Bordet wrote:
>> Hi,
>>
>> On Wed, Sep 23, 2015 at 7:04 AM, Bradford Wetmore
>> wrote:
>>>
This new proposal still requires that ciphers are sorted in a way that
matches the ApplicationProtocol order.
Wo
On 9/25/2015 4:11 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 3:44 AM, Xuelei Fan wrote:
>> For example, a client wants to negotiate {HTTP2, HTTP1.1} or {HTTP1.1,
>> HTTP2} and {TLS_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_
On 9/25/2015 7:42 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan wrote:
>> Here is the question to answer, which preference should be respected
>> firstly between cipher suite and application protocol? If application
>> protocol are pr
On 9/25/2015 8:48 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 2:26 PM, Xuelei Fan wrote:
>> Maybe, we are not on the same page, I think.
>
> We are.
>
>> I think a general cipher strength comparator is sufficient for HTTP/2
>> preference t
On 9/25/2015 9:14 PM, Simone Bordet wrote:
> On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd
> wrote:
>> > Well, SNI already basically works this way, so it's not so great a stretch.
> I don't follow ?
> SNI has APIs in JDK 8, you don't use SSLExplorer at all.
There are two typical cases for SNI
On 9/25/2015 10:20 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 3:20 PM, Xuelei Fan wrote:
>> For the complication, I posted the comments in previous mail here:
>>
>> -
>>> In case you have [HTTP/2, AP_NEW, HTTP/1.1],
CC security-dev.
On 9/25/2015 9:14 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd
> wrote:
>> Well, SNI already basically works this way, so it's not so great a stretch.
>
> I don't follow ?
> SNI has APIs in JDK 8, you don't use SSLExplorer at all.
>
> Als
On 9/25/2015 10:28 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 4:19 PM, Xuelei Fan wrote:
>> Actually, it was a puzzle to me: whether a concrete server can support
>> both HTTP/2 and HTTP/1.1, or not. If HTTP/2 mode of the server does not
>> work, is it
I would second David's proposal based on the #1/#A ideas.
Here are some background and options.
1. a HTTP2 server should support HTTP2
If a HTTP2 server declare to support HTTP2, it should support HTTP2
protocol. What happens if corner cases happen that the security is not
sufficient (client requ
On 9/26/2015 8:47 AM, Bradford Wetmore wrote:
>> {TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}
>
> BTW, in case anyone was wondering, both of these suites are on the RFC
> 7540 blacklist.
Ooops, I meant to use "TLS_ECDHE_" as HTTP2 non-blacklisted cipher suite.
Xuelei
On 9/26/2015 8:47 AM, Bradford Wetmore wrote:
>> It might be not customers expected behavior to re-order/sort their
>> preference of cipher suites or preference.
>
> Are we are clear that the intention was never for the JDK to internally
> resort the ciphersuites, but rather to provide an external
On 10/2/2015 9:03 AM, Bradford Wetmore wrote:
> Major changes:
>
> 1. ApplicationProtocols is gone. The H2 black list and comparator were
> moved to StandardConstants.
>
> 2. StandardConstants. Strings for "h2" and "http/1.1" are back. And
> now that you are parsing the raw network bytes, I
Thanks!
Xuelei
On 10/3/2015 8:19 AM, Bradford Wetmore wrote:
>
>
> On 10/1/2015 7:35 PM, Xuelei Fan wrote:
>> On 10/2/2015 9:03 AM, Bradford Wetmore wrote:
>>> Major changes:
>>>
>>> 1. ApplicationProtocols is gone. The H2 black list and comp
Looks fine to me. Just a few minor comments.
ServerHandshaker.java
=
There is a typo of the first line.
- /* Copyright (c) 1996, 2015, ...
+ /*
+ * Copyright (c) 1996, 2015 ...
line 538-546
String negotiatedValue = null;
List protocols = clientHelloALPN.g
Looks fine to me. Thanks for the update.
Xuelei
On 12/1/2015 7:08 AM, Vincent Ryan wrote:
> Thanks for your review. Comments in-line.
>
>> On 30 Nov 2015, at 06:30, Xuelei Fan wrote:
>>
>> Looks fine to me. Just a few minor comments.
>
Is it nice to say in the spec that it is not reliable if the timeout is
too small? At least 1000ms timeout by default may be not acceptable in
some circumstances.
Xuelei
On 12/9/2015 12:31 AM, Rob McKenna wrote:
> Testing has shown that when a timeout < 1000ms is specified the
> IcmpSendEcho cal
hability I feel that this small corner case is a worthwhile tradeoff.
>
> -Rob
>
> On 09/12/15 01:31, Xuelei Fan wrote:
>> Is it nice to say in the spec that it is not reliable if the timeout is
>> too small? At least 1000ms timeout by default may be not acceptable in
>
As you were already there, I would suggest to consider the
SSLSocketSample.java template as the comment in JDK-8163924 review thread.
Thanks,
Xuelei
On 9/15/2016 9:13 AM, Artem Smotrakov wrote:
Not urgent, but I would appreciate if someone can get a chance to look
at this.
Artem
On 09/07/20
lient.
Xuelei
I would prefer to have it as a separate enhancement.
Artem
On 09/14/2016 06:19 PM, Xuelei Fan wrote:
As you were already there, I would suggest to consider the
SSLSocketSample.java template as the comment in JDK-8163924 review
thread.
Thanks,
Xuelei
On 9/15/2016 9:13 AM, Artem Smot
the fix. Otherwise, you cannot
avoid the intermittent failure for this test case in the current testing
environment.
Xuelei
I can make this enhancement, but like I said I don't think it's going to
help, so I would like to keep debug output on.
Artem
On 09/14/2016 06:39 PM, Xuelei Fa
Just FYI.
The intermittent failures look like similar to some anti-free-port using
issues. In the current testing environment, for the InheritHandle test
case, this anti-free-port using issue may looks like:
1. InheritHandle creates a server socket on a free port, and gets the
port (PORT-A)
In theory, there are intermittent compatibility problems as this update
may not close the SSL connection over the existing socket layer
gracefully, even for high speed networking environments, while the
underlying socket is alive. The impact could be serious in some
environment.
For safe, I
On 9/13/2017 5:52 AM, Xuelei Fan wrote:
In theory, there are intermittent compatibility problems as this update
may not close the SSL connection over the existing socket layer
gracefully, even for high speed networking environments, while the
underlying socket is alive. The impact could be
ng in mind that we are closing
the underlying socket)
I did not get the point, are we really closing the underlying socket (or
the layered ssl connection?) for the context of you update?
Xuelei
I'll file a CSR as soon as we settle on the direction this fix will
take.
-Rob
On 13/09/1
On 9/13/2017 8:52 AM, Rob McKenna wrote:
W.r.t. a separate timeout, the underlying mechanics of a close already
depend on the readTimeout in this situation.
That's a concerns of mine. In order to work for your countermeasure,
applications have to set receiving timeout, and take care of the clos
nd lower impact.
In my opinion the default behaviour of potentially hanging indefinitely
is worse than the alternative here. (bearing in mind that we are closing
the underlying socket)
I'll file a CSR as soon as we settle on the direction this fix will
take.
-Rob
On 13/09/17 05:52, X
details.
Xuelei
-Rob
On 13/09/17 04:09, Xuelei Fan wrote:
It's a little bit complicated for layered SSL connections. Application can
build a SSL connection on existing socket (we call it layered SSL
connections). The problem scenarios make look like:
1. open a socket for applica
polling.
What you are suggesting would effectively necessitate a reimplementation
of the close mechanics discarding the read timeout completely. (which
would be a significant enough change in terms of compatibility)
-Rob
On 13/09/17 03:56, Xuelei Fan wrote:
On 9/13/2017 8:52 AM, Rob McKenn
On 9/15/2017 7:16 AM, Rob McKenna wrote:
On 13/09/17 03:52, Xuelei Fan wrote:
On 9/13/2017 8:52 AM, Rob McKenna wrote:
Hi Xuelei,
This behaviour is already exposed via the autoclose boolean in:
https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocketFactory.html#createSocket
On 9/15/2017 7:41 AM, Rob McKenna wrote:
On 15/09/17 07:07, Xuelei Fan wrote:
On 9/15/2017 7:00 AM, Rob McKenna wrote:
When we call close() on the SSLSocket that calls close() on the
underlying java Socket which closes the native socket.
Sorry, I did not get the point. Please see the close
point. Applications don't have to set a read timeout.
Xuelei
, my proposal doesn't
alter this fact. (i.e. if the read timeout isn't set applications which
call close could potentially get stuck in readReply indefinitely)
-Rob
On 15/09/17 07:23, Xuelei Fan wrote:
On 9/15/2017
point.
Xuelei
-Rob
On 15/09/17 07:55, Xuelei Fan wrote:
On 9/15/2017 7:41 AM, Rob McKenna wrote:
On 15/09/17 07:07, Xuelei Fan wrote:
On 9/15/2017 7:00 AM, Rob McKenna wrote:
When we call close() on the SSLSocket that calls close() on the
underlying java Socket which closes the native socket.
think it's fine just call
fatal() for the first timeout.
Xuelei
On 9/15/2017 4:32 PM, Xuelei Fan wrote:
On 9/15/2017 8:22 AM, Rob McKenna wrote:
This test calls close directly. (3rd last line in the stack)
I believe this is the only possible stack (with the new parameter) once
autoclose
> On Sep 22, 2017, at 6:06 AM, Rob McKenna wrote:
>
> Thanks Xuelei, webrev below:
>
> http://cr.openjdk.java.net/~robm/8184328/webrev.02/
>
Looks fine to me.
> Presumably this won't require a CSR?
>
Agreed.
Xuelei
> -Rob
>
>> On 15/09/17 04:3
Please let me know your concerns by the end of August 1st, 2018.
Thanks,
Xuelei
On 7/30/2018 9:59 AM, Xuelei Fan wrote:
Hi,
Please review the update for the TLS 1.3 half-close and synchronization
implementation:
http://cr.openjdk.java.net/~xuelei/8207009/webrev.00/
Unlike TLS 1.2 and
1.3 client side.
Thanks,
Xuelei
On 7/30/2018 10:24 AM, Xuelei Fan wrote:
Please let me know your concerns by the end of August 1st, 2018.
Thanks,
Xuelei
On 7/30/2018 9:59 AM, Xuelei Fan wrote:
Hi,
Please review the update for the TLS 1.3 half-close and
synchronization implementation:
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
://mail.openjdk.java.net/pipermail/security-dev/2018-August/017778.html
Please let me know your concerns before this Wednesday.
Thanks,
Xuelei
On 8/3/2018 1:55 PM, Xuelei Fan wrote:
Update: http://cr.openjdk.java.net/~xuelei/8207009/webrev.02/
In webrev.01, the socket close may be blocked by super class close
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need richer
information for the underlying TLS connections, for example the
negotiated TLS protocol version.
Please let me know if you have concerns to add a new meth
On 10/31/2018 8:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need richer
information for the underlying TLS connections, for example the
, at 20:03, Xuelei Fan <mailto:xuelei@oracle.com>> wrote:
...
Yes. I had the same concern about the optional operation. However, I
came to a different conclusion if I'm from viewpoint of these users
that need to use this new operation.
If an application have to use this new
On 11/1/2018 11:24 AM, Sean Mullan wrote:
On 10/31/18 11:52 AM, Chris Hegarty wrote:
Xuelei,
On 30/10/18 20:55, Xuelei Fan wrote:
Hi,
For the current HttpsURLConnection, there is not much security
parameters exposed in the public APIs. An application may need
richer information for the
Thanks for the review and suggestions, Chris and Sean.
I just finalized the CSR.
Thanks,
Xuelei
On 11/2/2018 5:58 AM, Chris Hegarty wrote:
Thanks for the updates Xuelei, some minor comments inline..
On 1 Nov 2018, at 23:42, Xuelei Fan <mailto:xuelei@oracle.com>> wrote:
On 11/
OK with this change.
Thanks,
Xuelei
On 11/2/2018 11:42 AM, Xuelei Fan wrote:
Thanks for the review and suggestions, Chris and Sean.
I just finalized the CSR.
Thanks,
Xuelei
On 11/2/2018 5:58 AM, Chris Hegarty wrote:
Thanks for the updates Xuelei, some minor comments inline..
On 1 Nov 2018, at
On 11/7/2018 1:30 PM, Sean Mullan wrote:
https://bugs.openjdk.java.net/browse/JDK-8213161
http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/
I didn't see a test for SecureCacheResponse - is it possible?
JDK does not have the reference implementation of SecureCacheResponse.
You could
/18 7:22 PM, Xuelei Fan wrote:
On 11/7/2018 1:30 PM, Sean Mullan wrote:
https://bugs.openjdk.java.net/browse/JDK-8213161
http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/
I didn't see a test for SecureCacheResponse - is it possible?
JDK does not have the reference implementati
re is using them (even though they are not supposed to).
The rest of this looks ok, pretty straightforward.
--Sean
On 2/21/19 10:45 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed:
http://cr.openjdk.java.net/~xuelei/8215430/webrev.00/
The internal package com.sun.ne
l valid tests.
They are helper classes and used by ProviderTest, which is used to test
the com.sun.net.ssl wrappers.
Thanks,
Xuelei
Thanks,
Brad
On 2/26/2019 7:33 AM, Chris Hegarty wrote:
On 26 Feb 2019, at 03:53, Xuelei Fan wrote:
It makes sense to me to leave the AbstractDelegateHt
+1.
Xuelei
On 9/12/2019 4:43 AM, Chris Hegarty wrote:
On 11 Sep 2019, at 16:24, Daniel Fuchs wrote:
Hi,
Please find below a patch for:
8230858: Replace wildcard address with loopback or local host in
tests - part 23
https://bugs.openjdk.java.net/browse/JDK-8230858
webrev:
http://
Hi,
Could I get the following update reviewed?
Bug: https://bugs.openjdk.java.net/browse/JDK-8241039
CSR: https://bugs.openjdk.java.net/browse/JDK-8241047
webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/
In a preview review thread,
https://mail.openjdk.java.net/pipermail/security-
, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
Bug: https://bugs.openjdk.java.net/browse/JDK-8241039
CSR: https://bugs.openjdk.java.net/browse/JDK-8241047
webrev: http://cr.openjdk.java.net/~xuelei/8241039/webrev.00/
I see you've created a new issue (and sub-tasks), in whic
t to show an example about how to handle with the method in
third party's source code.
Thanks,
Xuelei
best regards
-- daniel
On 16/03/2020 04:25, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
Bug: https://bugs.openjdk.java.net/browse/JDK-8241039
CSR: https://bu
I updated the CSR and local code.
Thanks,
Xuelei
On 3/16/2020 10:23 AM, Alan Bateman wrote:
On 16/03/2020 16:00, Xuelei Fan wrote:
Hi Alan,
Thanks for the review. All comments look good to me. Here is the
update webrev:
http://cr.openjdk.java.net/~xuelei/8241039/webrev.01
With this update, the logic looks like: if TLSv1.3 is not enabled in the
SSLContext, use TLSv1.2 instead; Otherwise, use TLSv1.3 and TLSv1.2.
There may be a couple of issues:
1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled.
For example:
System.setProperty("jdk.tls.client.protocols
quot;DTLS");
and the protocol values returned by the following invocation on that context
`getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does
it do?
Yes.
Xuelei
-Chris.
On 26 Mar 2020, at 16:58, Xuelei Fan wrote:
With this update, the logic looks l
On 3/27/2020 10:36 AM, Chris Hegarty wrote:
Thank you Xuelei, this very helpful.
Sorry, but I am going to ask just a few more clarifying questions to make sure
that we’re on the same page.
On 27 Mar 2020, at 16:23, Xuelei Fan wrote:
On 3/27/2020 5:52 AM, Chris Hegarty wrote:
Xuelei
Changeset: c0eb84957bea
Author:xuelei
Date: 2008-04-11 03:33 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/c0eb84957bea
6546639: (spec)javax.net.ssl.SSLContext.getInstance(null) throws undocumented
NPE
Summary: add NullPointerException description to those methods.
Reviewe
Changeset: da9fa1fa9b95
Author:xuelei
Date: 2008-04-11 03:43 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/da9fa1fa9b95
6546671: (spec)javax.net.ssl.TrustManagerFactory.getInstance() throws
undocumented NP
5053895: (spec) Unspecified IllegalStateException in TrustManagerFa
Changeset: 143e1a9b51a9
Author:xuelei
Date: 2008-04-11 03:50 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/143e1a9b51a9
6571950: SSLSocket(raddr, rport, laddr, lport) allows null as laddr that spec
doesn't reflect
Summary: add the description that while the local address p
Refer to: http://bugreport.sun.com/bugreport/, at the bottom of the
page, there is a start a new report button, report a bug from here, please.
- xuelei
Ole Ersoy wrote:
Hi,
Could someone please tell the URL for filing an openjdk bug report?
Thanks,
- Ole
Changeset: 16efbe49c725
Author:xuelei
Date: 2008-11-13 23:08 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16efbe49c725
6728126: Parsing Extensions in Client Hello message is done in a wrong way
Summary: the inputStream.read(byte[], int, 0) is not always return zero.
Reviewe
Changeset: dcb8d806d731
Author:xuelei
Date: 2008-11-13 23:25 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dcb8d806d731
6745052: SLServerSocket file descriptor leak
Summary: SSLServerSocketImpl.checkEnabledSuites() does not release the
temporary socket properly
Reviewed-by:
Changeset: 85fe3cd9d6f9
Author:wetmore
Date: 2008-12-19 10:35 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/85fe3cd9d6f9
6750401: SSL stress test with GF leads to 32 bit max process size in less than
5 minutes,with PCKS11 provider
Summary: This is the JSSE portion of the fi
Changeset: a96a1f0edeeb
Author:xuelei
Date: 2009-02-04 19:10 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a96a1f0edeeb
6782783: regtest HttpsURLConnection/B6216082.java throws
ClosedByInterruptException
Summary: make the test robust
Reviewed-by: weijun
!
test/sun/securit
Changeset: a144afafb6fe
Author:xuelei
Date: 2009-02-20 12:50 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a144afafb6fe
4918870: Examine session cache implementation (sun.misc.Cache)
Summary: replace sun.misc.Cache with sun.security.util.Cache
Reviewed-by: weijun
! src/shar
Changeset: 6bdbb2f5c763
Author:xuelei
Date: 2009-02-20 13:05 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6bdbb2f5c763
6697270: Inputstream dosent behave correct
Summary: do not try to read zero byte from a InputStream, and do always return
immediately for zero byte readin
Changeset: 2a7c1a997102
Author:xuelei
Date: 2009-02-23 17:32 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2a7c1a997102
5067458: Loopback SSLSocketImpl createSocket is throwing an exception
Summary: A null hostname should be regarded as a loopback address.
Reviewed-by: weiju
Changeset: b656e842e1be
Author:xuelei
Date: 2009-03-02 23:17 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b656e842e1be
6549506: Specification of Permission.toString() method contradicts with JDK
implementation
Summary: update the spec, and add double quotes around componen
Changeset: f381e737916d
Author:xuelei
Date: 2009-03-13 12:59 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f381e737916d
6798714: OCSPResponse class has to check the validity of signing certificate
for OCSP response
Summary: checking validity and ocsp-nocheck extension.
Revi
Changeset: 181472dbbebb
Author:xuelei
Date: 2009-03-17 11:54 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/181472dbbebb
6383095: CRL revoked certificate failures masked by OCSP failures
Summary: remove the mask if certificate revoked
Reviewed-by: mullan
!
src/share/classes
Changeset: d93b7df1e260
Author:xuelei
Date: 2009-05-26 16:19 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d93b7df1e260
6822460: support self-issued certificate
Summary: checking self-issued certificate during certification path building
Reviewed-by: mullan, weijun
! src/sh
Changeset: c3c5cc0f2a3e
Author:xuelei
Date: 2009-05-26 16:43 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c3c5cc0f2a3e
6720721: CRL check with circular depency support needed
Summary: checking AKID of certificates and CRLs
Reviewed-by: mullan, weijun
! src/share/classes/su
Changeset: 25db260cb810
Author:xuelei
Date: 2009-05-27 17:48 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25db260cb810
6845286: Add regression test for name constraints
Summary: create regression test cases on name constraints
Reviewed-by: weijun
+
test/java/security/cert
Changeset: 045743e0eb2d
Author:xuelei
Date: 2009-06-04 11:28 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/045743e0eb2d
6847459: Allow trust anchor self-issued intermediate version 1 and version 2
certificate
Reviewed-by: weijun
! src/share/classes/sun/security/provider/ce
Changeset: ffbcf1d1103c
Author:xuelei
Date: 2009-06-12 09:00 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ffbcf1d1103c
6570344: Invalid RSA OID in sun.security.x509.AlgorithmId
Summary: change RSA OID to "2.5.8.1.1"
Reviewed-by: mullan
! src/share/classes/sun/security/x509
Changeset: 1299804aa6e7
Author:xuelei
Date: 2009-06-16 20:46 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1299804aa6e7
6850783: InvalidityDateExtension returns reference to internal mutable state
Summary: return cloned instead of referenced object
Reviewed-by: weijun
! src
Changeset: c2baa2f0415e
Author:xuelei
Date: 2009-07-03 11:13 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2baa2f0415e
6853793: OutOfMemoryError in sun.security.provider.certpath.OCSPChecker.check
Summary: allocate memory dynamically, keep reading until EOF.
Reviewed-by: we
Changeset: 6f26e2e5f4f3
Author:xuelei
Date: 2009-07-10 17:27 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6f26e2e5f4f3
6852744: PIT b61: PKI test suite fails because self signed certificates are
beingrejected
Summary: make the builder aware of SKID/AKID, break the internal
Changeset: d0ce095004b2
Author:xuelei
Date: 2009-07-13 23:01 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d0ce095004b2
6453837: PartialCompositeContext.allEmpty is buggy
Reviewed-by: weijun
! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java
Changeset: d78bfd73ee42
Author:xuelei
Date: 2009-07-27 22:04 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d78bfd73ee42
6449574: Invalid ldap filter is accepted and processed
Reviewed-by: vinnie
! src/share/classes/com/sun/jndi/ldap/Filter.java
+ test/com/sun/jndi/ldap/Bala
Changeset: 056c8e724015
Author:xuelei
Date: 2009-07-28 11:15 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/056c8e724015
6865482: test case BalancedParentheses.java is missing GPL header.
Reviewed-by: weijun
! test/com/sun/jndi/ldap/BalancedParentheses.java
Changeset: aface89bfcf6
Author:xuelei
Date: 2009-08-11 18:27 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aface89bfcf6
6585239: Regression: 2 DNS tests fail with JDK 5.0u13 b01 and pass with
5.0u12fcs
Reviewed-by: vinnie
! src/share/classes/com/sun/jndi/dns/DnsContext.jav
Changeset: dca3a251a001
Author:xuelei
Date: 2010-01-20 21:38 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dca3a251a001
6862064: incorrect implementation of PKIXParameters.clone()
Reviewed-by: weijun, mullan
! src/share/classes/java/security/cert/PKIXParameters.java
Changeset: 9929203a8b98
Author:xuelei
Date: 2010-02-25 13:32 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9929203a8b98
6916202: More cases of invalid ldap filters accepted and processed
Reviewed-by: vinnie, weijun
! src/share/classes/com/sun/jndi/ldap/Filter.java
+ test/co
1 - 100 of 237 matches
Mail list logo
