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
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
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
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
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
, 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
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-
+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://
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
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
/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
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
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
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/
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
, 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 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
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
://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
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
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:
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
> 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
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
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.
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
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
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
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
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
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
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
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 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
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
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)
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
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
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
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
>
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
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.
>
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
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
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
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 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
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/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
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: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],
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 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 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 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: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
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
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
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
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
> - 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
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
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
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
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
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
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/
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: 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: 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: 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: 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: c9083205e6eb
Author:xuelei
Date: 2013-09-10 21:31 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9083205e6eb
8024501: sun.security.mscapi.Key has no definition of serialVersionUID
Reviewed-by: weijun
! src/windows/classes/sun/security/mscapi/Key.java
Changeset: f80b8af9c218
Author:xuelei
Date: 2013-09-09 19:07 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f80b8af9c218
802: Change to use othervm mode of tests in SSLEngineImpl
Reviewed-by: mullan
!
test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/Clos
Changeset: 0f47f9f622d9
Author:xuelei
Date: 2013-09-07 17:05 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f47f9f622d9
7188657: There should be a way to reorder the JSSE ciphers
Reviewed-by: weijun, wetmore
! src/share/classes/javax/net/ssl/SSLParameters.java
! src/share/c
Changeset: ead6babac5a9
Author:xuelei
Date: 2013-09-01 20:00 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ead6babac5a9
8024068: sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java fails
Reviewed-by: weijun
! test/sun/security/ssl/javax/net/ssl/ServerName/IllegalS
Changeset: cdf68747b0fb
Author:xuelei
Date: 2013-08-29 18:58 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdf68747b0fb
8023881: IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in
IDN.toASCII
Reviewed-by: michaelm
! src/share/classes/java/net/IDN.java
+ test/j
he comment. Thanks for the quick code review.
Xuelei
> That explains what exactly was fixed here.
>
> Michael
>
> On 29/08/13 13:46, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the fix of JDK-8023881.
>>
>> webrev: http://cr.openjdk.java.net/~xuelei/802
Hi,
Please review the fix of JDK-8023881.
webrev: http://cr.openjdk.java.net/~xuelei/8023881/webrev.00/
This bug has not been ported to bugs.sun.com. The following is the
descirption of the issue.
IDN.toASCII("示例.com", IDN.USE_STD3_ASCII
On 8/22/2013 11:37 AM, Laxmi Narayan NIT DGP wrote:
> is there are any chances of contribution for outsider of oracle and even
> student developers ??
>
Sure. Please see the following page about how to contribute:
http://openjdk.java.net/contribute/
And The OpenJDK Developers' Guide:
htt
Changeset: ec827a62070a
Author:xuelei
Date: 2013-08-21 19:44 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec827a62070a
808: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs
Reviewed-by: weijun
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCac
Changeset: 21a25911f7f7
Author:xuelei
Date: 2013-08-19 18:49 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21a25911f7f7
8023230: The impl of KerberosClientKeyExchange maybe not exist
Reviewed-by: weijun
! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java
Changeset: 096e7c665857
Author:xuelei
Date: 2013-08-19 17:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/096e7c665857
8020842: IDN do not throw IAE when hostname ends with a trailing dot
Reviewed-by: weijun, michaelm
! src/share/classes/java/net/IDN.java
+ test/java/net/I
If no objections, I will push the change by COB Monday.
Thanks,
Xuelei
On 8/13/2013 4:29 PM, Xuelei Fan wrote:
> Can I get an additional code review from networking team?
>
> Thanks,
> Xuelei
>
> On 8/12/2013 2:07 PM, Weijun Wang wrote:
>> new webrev: http://cr.openjdk.
ct with other parts of the IDN specification?
>
> Mike
>
> On Aug 13 2013, at 01:29 , Xuelei Fan wrote:
>
>> Can I get an additional code review from networking team?
>>
>> Thanks,
>> Xuelei
>>
>> On 8/12/2013 2:07 PM, Weijun Wang wrote:
>>> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/
>
Can I get an additional code review from networking team?
Thanks,
Xuelei
On 8/12/2013 2:07 PM, Weijun Wang wrote:
> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/
dequate and necessary.
>
> One problem: lines 367-373 adds a new IAE to ToUnicode but the method
> should not fail forever.
>
> And some small comments on styles etc.
>
> On 8/12/13 9:09 AM, Xuelei Fan wrote:
>> new webrev: http://cr.openjdk.java.net/~xuelei/8020
Changeset: ea4f4164422e
Author:xuelei
Date: 2013-08-11 18:21 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea4f4164422e
8022487: DEREncodedKeyValue.supportedKeyTypes should be private
Reviewed-by: mullan
!
src/share/classes/com/sun/org/apache/xml/internal/security/keys/con
new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/
Added a new test to test illegal hostname in SNIHostName.
Xuelei
On 8/10/2013 10:49 AM, Xuelei Fan wrote:
> Hi Michael,
>
> It is pretty hard to get the issue solved in SNIHostName in a good
> sharp. Here is my try
http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
Thanks,
Xuelei
On 8/10/2013 9:13 AM, Xuelei Fan wrote:
> Hi Michael,
>
> I plan to address this issue in SNIHostName. I have filled another two
> the potential bugs in IDN.
>
> Thank you, and other people, for the feedb
Hi Michael,
I plan to address this issue in SNIHostName. I have filled another two
the potential bugs in IDN.
Thank you, and other people, for the feedback.
Thanks,
Xuelei
On 8/9/2013 11:25 PM, Xuelei Fan wrote:
> On 8/9/2013 7:31 PM, Michael McMahon wrote:
>> I don't see how
bout this point.
Xuelei
> I'd prefer to check first where that requirement is coming from, if it is
> actually necessary, and if not consider removing it from SNIHostName.
> If it is necessary, then the check should be implemented in SNIHostName.
>
> Michael
>
> On 09/0
On Aug 9, 2013, at 14:08, Dmitry Samersoff wrote:
> Xuelei,
>
> 119 p = q + 1;
> 120 if (p < input.length() || q == (input.length() - 1)) {
>
> Could be simplified to:
>
> q <= input.length()-1
>
It's cool!
Xuelei
> -Dmitry
&
Thanks for your feedback and suggestions.
Here is the new webrev:
http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/
"." is regarded as valid IDN in this update.
Thanks,
Xuelei
On 8/9/2013 10:50 AM, Xuelei Fan wrote:
> On 8/9/2013 10:14 AM, Weijun Wang wrote:
>>
>
On 8/9/2013 11:24 AM, Matthew Hall wrote:
> But, DNS considers "." as the valid root zone...
>
Good! Looks like that IDN.toASCII(".") should returns ".", so that a
general domain name can always use IDN.toASCII() conversion instead of
throwing runtime exception.
Xuelei
On 8/9/2013 10:14 AM, Weijun Wang wrote:
>
>
> On 8/9/13 9:37 AM, Xuelei Fan wrote:
>> On 8/9/2013 9:22 AM, Weijun Wang wrote:
>>> I tried nslookup. Those with ".." inside are illegal,
>>>
>>> $ nslookup com..
>>> nslookup: 'com..
sider it in another bug.
Can I push the changeset?
Thanks,
Xuelei
> Thanks
> Max
>
> On 8/9/13 8:41 AM, Xuelei Fan wrote:
>> Ping.
>>
>> Thanks,
>> Xuelei
>>
>> On 8/7/2013 11:17 PM, Xuelei Fan wrote:
>>> Please review the new update:
>
Ping.
Thanks,
Xuelei
On 8/7/2013 11:17 PM, Xuelei Fan wrote:
> Please review the new update:
>
> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/
>
> With this update, "com." is valid (return "com."); "." and
> "example..com&
chael McMahon wrote:
> On 07/08/13 15:13, Xuelei Fan wrote:
>> On 8/7/2013 10:05 PM, Michael McMahon wrote:
>>> Resolvers seem to accept queries using trailing dots.
>>>
>>> eg nslookup www.oracle.com.
>>>
>>> or InetAddress.getByName("www.
or IDN.toASCII("www.oracle.com."),
"www.oracle.com." or "www.oracle.com"? The current returned value is
"www.oracle.com". I would like to reserve the behavior in this update.
I think we are on same page soon.
Thanks,
Xuelei
> Michael
>
> On 07/08/1
1 - 100 of 237 matches
Mail list logo