Hi all,
The JDK Enhancement Proposal, TLS Certificate Compression, has been opened
for community review. Detailed, please refer to the draft:
https://bugs.openjdk.java.net/browse/JDK-8281710
Feel free to make comments and send your feedback to the alias. I may
submit this JEP in the
On Nov 16, 2021, at 7:28 PM, Michael StJohns
mailto:mstjo...@comcast.net>> wrote:
id-kp-timeStampingOBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation
Hm, we
I would suggest to fix in a separate bug.
Thanks,
Xuelei
> On Nov 3, 2021, at 2:27 PM, Daniel Jeliński wrote:
>
> On Wed, 3 Nov 2021 09:12:29 GMT, Daniel Jeliński
> wrote:
>
>>> src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java
>>> line 436:
>>>
434:
435:
Hi Daniel,
Thank you for the nice catch! I filed a JBS bug:
https://bugs.openjdk.java.net/browse/JDK-8275811
It would be nice if you could also update similar issues in (DTLS)OutRecord
files.
Thanks,
Xuelei
On Oct 22, 2021, at 8:14 AM, Daniel Jeliński
mailto:djelins...@gmail.com>>
It looks like an unintended behavior change to me. It looks reasonable to
change the behavior back.
Xuelei
> On Aug 25, 2021, at 2:59 AM, Volker Simonis wrote:
>
> Hi,
>
> I'd like to resurrect this old discussion which seems to have got lost.
>
> David has analyzed and described the
/op
> [Current version using CipherSuite.values]
> CipherSuiteBench.initiateHandshake avgt 25 4.366 ? 0.037 ms/op
> [Proposed change Static Array]
>
> I will proceed to create the JBS issue and work on getting additional
> benchmarks and numbers.
>
> Regards,
> Clive
BTW, it may worthy to track the development of the Frozen Arrays JEP:
https://openjdk.java.net/jeps/8261007
Xuelei
On Jul 9, 2021, at 11:21 AM, Xuelei Fan
mailto:xuelei@oracle.com>> wrote:
Hi Clive,
It’s a good point to me! Did you have the numbers about the performance
Hi Clive,
It’s a good point to me! Did you have the numbers about the performance impact?
Considering the size of CipherSuites, I think it is good to make an
improvement. As we are already here, may be we could consider if we could make
further performance improvement for searching as well.
Hi Peter,
For further understanding, may I know more details about the test code?
Thanks,
Xuelei
> On May 11, 2021, at 10:31 PM, Peter Firmstone
> wrote:
>
> Just ran some performance stress tests to compare performance between Java 8
> and Java 14 with SecurityManager enabled and using
ystem. Here is the PDF
>> version. BTW, I also made an update on the use of AEAD algorithm with
>> additional data.
>>
>> Thanks,
>> Xuelei
>>
>>
>>> On Oct 23, 2020, at 8:58 AM, Xuelei Fan wrote:
>>>
>>> Hi,
>>>
>>
, October 31, 2020.
BTW, I will post a new thread about the algorithm used for the session
ticket protection and synchronization in the cluster.
Thanks,
Xuelei
On 9/29/2020 9:25 PM, Xuelei Fan wrote:
Hi,
I was wondering to improve the scalability of the TLS implementation in
JDK. TLS
On 10/21/2020 1:01 PM, Jamil Nimeh wrote:
I'm not very sure why EdDSA cannot apply to ServerKeyExchange and
CertificateVerify in TLS 1.0 and 1.1. ServerKeyExchange and
CertificateVerify is used to authenticate the server or the client's
possession of the private key of the cert. So if EdDSA
Hi Jamil,
Sorry for delay. It took a few days before I was able to read the CSR.
Just a few comments for your consideration.
In the specification section, you mentioned how to disable the
algorithms. It might not be necessary. It is just something we need to
implement so that it does not
Hi,
I was wondering to improve the scalability of the TLS implementation in
JDK. TLS session resumption is much faster than full handshaking. It
may be a good to support efficiently distributing and resuming TLS
sessions across clusters of computers, by using stateless TLS session
tickets.
is likely good enough, otherwise I can
put together proposals for per-SSLSocket and per-HandshakeCompletionListner
executor configuration if that's helpful.
Thanks,
Carter Kozak
On Thu, Sep 17, 2020, at 15:08, Xuelei Fan wrote:
I thought more about the problem. I could see the performance
subsequent proposals, but unfortunately
this was something we inherited long ago. That's one of the reasons I
didn't include it in SSLEngine, but rather made a FINISHED
HandshakeStatus Event Type.
Thanks,
Brad
On 9/16/2020 12:21 PM, Xuelei Fan wrote:
Good catch!
Alternatively, I was
Good catch!
Alternatively, I was wondering if it is possible to delegate the job to
listeners, without modify the APIs, for example by implementing a
Runnable interface (not a proposal, just a guess for now). I don't like
the creation of threads in the JSSE provider, as application could
Looks good to me.
Thanks,
Xuelei
On 8/29/2020 10:56 AM, Rajan Halade wrote:
Please review this change to update test artifacts used for GlobalSign
R6 Root CA.
Webrev: http://cr.openjdk.java.net/~rhalade/8249176/webrev.00/
Thanks,
Rajan
It's good. Thanks!
Xuelei
On 8/26/2020 10:13 AM, Rajan Halade wrote:
Please review this update to remove key intermittent from AmazonCA test.
This test no longer fails intermittently.
@@ -24,7 +24,6 @@
/*
* @test
* @bug 8233223
*- * @key intermittent*
* @summary Interoperability
Looks good to me.
Thanks,
Xuelei
On 8/20/2020 8:14 AM, Roger Riggs wrote:
Please review using the java.util.Hex api in security related classes.
(The review of the API is being done on the
core-libs-...@openjdk.java.net).
Within the JDK and JDK tests there are multiple implementations to
Looks fine to me.
Just a trivial format comment. Some use link for "RFC 2253", some do
not. It's OK. And it's good as well if you want to use a uniform style.
Xuelei
On 8/21/2020 9:24 AM, Sean Mullan wrote:
Ping ...
On 8/7/20 10:01 AM, Sean Mullan wrote:
Please review this change to
ts in line.
On 8/18/2020 10:13 PM, Xuelei Fan wrote:
On 8/18/2020 2:43 PM, Valerie Peng wrote:
Using a shared instance is surely faster. However, the API specified
that the most preferred SecureRandom impl will be used. To ensure
this for all scenarios, creating default SecureRandom obj will
provi
ce, it may be
fine if we want to avoid the performance impact if the impact exists.
Just for your consideration.
Xuelei
Valerie
On 8/18/2020 2:10 PM, Xuelei Fan wrote:
Is there any performance impact?
Xuelei
On 8/18/2020 12:51 PM, Valerie Peng wrote:
Anyone has cycles to review this somewh
Is there any performance impact?
Xuelei
On 8/18/2020 12:51 PM, Valerie Peng wrote:
Anyone has cycles to review this somewhat trivial changes? JceSecurity
has this shared SecureRandom instance which may lead to NPE when certain
3rd party JCE provider is set as most preferred. Removing this
Looks fine to me.
Thanks,
Xuelei
On 8/17/2020 5:11 PM, Rajan Halade wrote:
Please review this patch to perform backdated certpath check as test
certificate has expired.
/diff -r cb8450f00ee9
test/jdk/sun/security/validator/PKIXValAndRevCheckTests.java/
/---
All good catches! I will update accordingly.
Thanks,
Xuelei
On 8/13/2020 11:13 AM, Anthony Scarpino wrote:
On 8/11/20 9:44 AM, Xuelei Fan wrote:
ping ...
On 7/30/2020 11:26 AM, Xuelei Fan wrote:
Hi,
May I get the following test code update reviewed?
http://cr.openjdk.java.net/~xuelei
ping ...
On 7/30/2020 11:26 AM, Xuelei Fan wrote:
Hi,
May I get the following test code update reviewed?
http://cr.openjdk.java.net/~xuelei/8250839/webrev.00/
SSLEngineTemplate is a template used for SSLEngine testing, which
depends on binary key store files, and not easy to extend
Hm, it's an interesting bug. I filed the issue on the Java Bug System.
https://bugs.openjdk.java.net/browse/JDK-8251304
Thanks,
Xuelei
On 8/7/2020 5:00 AM, Norman Maurer wrote:
Hi there,
In netty we support using BlockHound[1] to detect if people do blocking
operations within the
Hi,
May I get the following test code update reviewed?
http://cr.openjdk.java.net/~xuelei/8250839/webrev.00/
SSLEngineTemplate is a template used for SSLEngine testing, which
depends on binary key store files, and not easy to extend. This update
makes it easier to extend, by removing the
Looks good to me.
Thanks,
Xuelei
On 7/28/2020 10:28 AM, Rahul Yadav wrote:
Hello,
Request to have my fix reviewed for issue:
JDK-8250602 : Update
sun/security/ssl/SSLLogger/LoggerDateFormatterTest.java to handle
TimeZones.
This fix updates the test LoggerDateFormatterTest.java to be
Looks good to me. Thanks!
Xuelei
On 7/27/2020 4:03 PM, Jamil Nimeh wrote:
All taken care of.
https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.03/
--Jamil
On 7/27/20 1:58 PM, Xuelei Fan wrote:
Hi Jamil,
Thanks for taking the comment. The webrev looks good to me. Just a
few
.
Thank you very much for your consideration.
Scott
On Jul 27, 2020, at 11:44 AM, Xuelei Fan wrote:
Hi Scott,
Thanks for the feedback. May I have more information if there is a real
project/requirement for the use_srtp extension? As would help me plan for the
priority for the support.
I'm
ongest in terms of time. I'll restructure this and
issue a new webrev.
--Jamil
On 7/27/2020 8:21 AM, Xuelei Fan wrote:
I was just wondering, could we just simplify the implementation by
using two named groups for the top two-preferred categories, without
limited to XDH and ECDHE? For example, if F
Hi Scott,
Thanks for the feedback. May I have more information if there is a real
project/requirement for the use_srtp extension? As would help me plan
for the priority for the support.
I'm thinking about to support more flexible extension customization, but
for now it is not easy to add
I was just wondering, could we just simplify the implementation by using
two named groups for the top two-preferred categories, without limited
to XDH and ECDHE? For example, if FFDHE is on the top 2, FFDHE will be
used as well. Normally, XDH and ECDHE will be used, but the simplifying
is a
Looks good to me.
Xuelei
On 6/20/2020 7:47 AM, Weijun Wang wrote:
The 3 newly added log0() methods
in com/sun/org/slf4j/internal/Logger.java are declared public. This is a
stupid typo. In fact, in the comment at the beginning of that class [1]
I specifically pointed out they are private.
I added myself as reviewer of the CSR.
Xuelei
On 6/15/2020 5:42 PM, Anthony Scarpino wrote:
The specifications for TLS 1.3 (RFC 8446) and Stateless Resumption for
TLS 1.2 (RFC 5077) does not define session invalidation. Additionally,
RFC 5077 provides research that it is unnecessary. This
Hi,
May I have the following typo correction reviewed in test file?
$ hg diff test/jdk/javax/net/ssl/SSLEngine/IllegalHandshakeMessage.java
@@ -70,7 +70,7 @@
cliToSrv.put(7, (byte)0x80);// use illegal message length
} else {
// unlikely
-throw
On 6/11/2020 1:50 AM, Prasadrao Koppula wrote:
http://cr.openjdk.java.net/~pkoppula/8246031/webrev.01/
I may have 8 more white spaces indent at line 449, and have 446 and 447
in one line.
Otherwise, looks good to me. Need no more review from me.
Thanks,
Xuelei
Thank you for taking care of the issue. The update looks good to me. I
added myself as the reviewer in the CSR.
Xuelei
On 6/10/2020 4:12 PM, Joe Darcy wrote:
Hello,
Please review the addition of several explicit constructors to abstract
classes in javax.net.ssl to remove the use of
It may be not needed to update the handleException() method.
- 440handleException(iioe);
+ 440if (resumable) {
+throw iioe;
+} else {
+handleException(iioe);
+}
Otherwise, looks good to me.
Xuelei
A simple fix like this looks good to me. I may check this first, before
the EC available and signature checking.
Xuelei
On 6/9/2020 3:12 PM, Anthony Scarpino wrote:
Hi,
I need a code review of this very simple change for a situation that I'm
not sure is a problem in the real world.
The
About the prefix, it may follow RFC 5056 (See page 7, section 2.1).
o Specifications of channel bindings for any secure channels MUST
provide for a single, canonical octet string encoding of the
channel bindings. Under this framework, channel bindings MUST
start with the
articular scenario.
The chance of 3rd non-PKCS11 party provider whose
MessageDigest/MessageDigestSpi impl implements Cloneable but throws
CNSE when clone() is called should be very low? So, I think it should
be sufficient to use "md instanceof Cloneable && md is not from PKCS11"?
Vale
As the the Delegate class takes care of the Cloneable SPI
implementation, it should be sufficient to use "md instanceof Cloneable"
only. It is not a expected behavior that a provider implements
Cloneable but does not really support it.
Xuelei
On 6/5/2020 10:54 PM, Weijun Wang wrote:
Is it
Looks good to me.
Xuelei
On 6/4/2020 8:18 PM, Weijun Wang wrote:
Please review the patch below. The tag name should be camelCased.
*diff --git
a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java
On 6/3/2020 8:15 AM, Weijun Wang wrote:
On Jun 3, 2020, at 10:10 PM, Xuelei Fan wrote:
It looks good to me.
Thanks.
BTW, I may declare KnownOIDs.oid as final and use it directly, rather than use
the value() method.
I'll keep it flexible at the moment. I dreamed of a day where an OID
It looks good to me.
BTW, I may declare KnownOIDs.oid as final and use it directly, rather
than use the value() method.
Xuelei
On 6/2/2020 11:27 PM, Weijun Wang wrote:
Please review the code change at
http://cr.openjdk.java.net/~weijun/8246397/webrev.00/
The following KnownOIDs lines
Good catch, Simone. It is not expected to parser the alias in application
code. Would you like file a bug?
Thanks,
Xuelei
> On Jun 1, 2020, at 2:13 AM, Simone Bordet wrote:
>
> Hi,
>
> when using "PKIX" as KeyManagerFactoryAlgorithm, the alias is
> manipulated from what's in the keystore
Looks good to me. You may also want to update the copyright date in
KDC.java.
Xuelei
On 5/30/2020 4:54 AM, Weijun Wang wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8246193/webrev.00/
While searching for ENC-PA-REP in the PA-DATA list of AS-REQ, it's possible
there
if Certificate + CertificateVerify +
Finished hanshake messages wrapped in one record. The block in
SSLEngineImpl.writeRecord() 167-172 is used to handle this case.
Thanks,
Xuelei
thanks
Tony
On 5/27/20 8:44 PM, Xuelei Fan wrote:
Tony and I had a private chat, and I understand his concerns better
is the new webrev:
http://cr.openjdk.java.net/~xuelei/8240871/webrev.01/
Thanks,
Xuelei
On 5/26/2020 2:40 PM, Xuelei Fan wrote:
On 5/26/2020 1:26 PM, Anthony Scarpino wrote:
On 5/13/20 1:44 PM, Xuelei Fan wrote:
On 5/13/2020 9:41 AM, Anthony Scarpino wrote:
On 4/30/20 10:19 AM, Xuelei Fan
Hi Ben,
The tutorial is impressive to me.
Thanks for the reporting, I filed a RFE for the tracking:
https://bugs.openjdk.java.net/browse/JDK-8245983
Xuelei
On 5/27/2020 7:23 AM, Ben Smyth wrote:
I have written a TLS 1.3 tutorial
(https://bensmyth.com/publications/2019-TLS-tutorial/) which
On 5/26/2020 1:26 PM, Anthony Scarpino wrote:
On 5/13/20 1:44 PM, Xuelei Fan wrote:
On 5/13/2020 9:41 AM, Anthony Scarpino wrote:
On 4/30/20 10:19 AM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed:
http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/
For TLS 1.3 full
Ping ...
On 5/13/2020 1:44 PM, Xuelei Fan wrote:
On 5/13/2020 9:41 AM, Anthony Scarpino wrote:
On 4/30/20 10:19 AM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed:
http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/
For TLS 1.3 full handshake, if the last handshake
Looks good to me. Thank you for adding the cert for EdDSA.
Xuelei
On 5/24/2020 6:53 PM, sha.ji...@oracle.com wrote:
Hi,
This patch just adds some EdDSA, including Ed25519 and Ed448, certificates
to javax/net/ssl/SSLSocketTemplate.java and
jdk/test/lib/security/CertUtils.java.
Please note
On 5/22/2020 11:17 AM, Sean Mullan wrote:
On 5/22/20 1:55 PM, Xuelei Fan wrote:
* test/jdk/sun/security/ssl/X509TrustManagerImpl/TooMuchCAs.java
Will this test FAIL if we ever exceed the maximum number of CAs? I
think it is important that it does FAIL, as the extension is
effectively
All good comments. I updated the code and CSR accordingly.
http://cr.openjdk.java.net/~xuelei/8206925/webrev.05/
On 5/22/2020 8:41 AM, Sean Mullan wrote:
On 5/15/20 6:11 PM, Xuelei Fan wrote:
New webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.04/
*
src/java.base/share/classes
On 5/19/2020 6:58 AM, Weijun Wang wrote:
One more thing: do you think we should allow "-siglag Ed25519" and "-sigalg
Ed448"?
I would like to have the two options.
It looks like we should support it because we can call Signature.getInstance() on it, but even if
so, the block extension name
New webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.04/
On 5/15/2020 5:27 AM, Sean Mullan wrote:
On 5/15/20 1:22 AM, Xuelei Fan wrote:
Alexey has some good point about the size limit of the extension. I
added more comments about the compatibility impact and interop impact
when
Looks good to me.
Xuelei
On 5/15/2020 5:38 AM, sha.ji...@oracle.com wrote:
Hi,
Possibly run the manual test
javax/net/ssl/compatibility/BasicConnectTest.java
with JDK builds supporting TLS_KRB5 cipher suites. However these cipher
suites
are not in
. I will review the updated webrev later.
Please file and add a link to a docs issue to document the new system
property.
--Sean
On 5/13/20 5:20 PM, Xuelei Fan wrote:
On 5/13/2020 2:11 PM, Sean Mullan wrote:
It is not expected to use this extension regularly.
Please let me know if you
Hi Alexey,
Thanks for the reproducer. Would you mind add it to JDK-8206925 for
further testing?
I think more about if a control number could be helpful. If the
certificate authorities can not be fully listed, it cannot be used to
indicate the peer certificate selection accuracy. For
On 5/13/2020 2:11 PM, Sean Mullan wrote:
It is not expected to use this extension regularly.
Please let me know if you still prefer to use "enableCAExtension".
Also, it is a bit unfortunate that we have to have a system
property to enable it. Can we not enable it based on whether the
On 5/13/2020 9:41 AM, Anthony Scarpino wrote:
On 4/30/20 10:19 AM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed:
http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/
For TLS 1.3 full handshake, if the last handshake flight wraps the
Finished together with other
/CertificateAuthorityExtension.java
[2] - https://tools.ietf.org/html/rfc8446#page-45
Thank you
Alexey
On 13 May 2020, at 00:43, Xuelei Fan wrote:
Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.01/
On 5/12/2020 12:40 PM, Sean Mullan wrote:
On 5/5/20 2:29 PM, Xuelei Fan wrote:
Hi,
Could I get
Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.02/
The CSR and release note were updated accordingly, to use the new system
property.
On 5/13/2020 6:38 AM, Sean Mullan wrote:
On 5/12/20 5:43 PM, Xuelei Fan wrote:
Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925
Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.01/
On 5/12/2020 12:40 PM, Sean Mullan wrote:
On 5/5/20 2:29 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
RFE: https://bugs.openjdk.java.net/browse/JDK-8206925
CSR: https://bugs.openjdk.java.net/browse
Looks fine to me.
Xuelei
On 5/8/2020 1:14 PM, Valerie Peng wrote:
Anyone can help with this trivial two-line change? Just updating the
version to 1.8.26 from 1.8.24, no change to the headers' content besides
the version change/update.
RFE: https://bugs.openjdk.java.net/browse/JDK-8244151
Looks fine to me.
Xuelei
On 5/7/2020 1:31 PM, Sean Mullan wrote:
The LuxTrust CA has resolved the issue on their side, so the fix is
simply to remove the test from the ProblemList:
diff -r 868fe697bad4 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt Thu May 07 19:18:22 2020 +0100
Hi,
Could I get the following update reviewed?
RFE: https://bugs.openjdk.java.net/browse/JDK-8206925
CSR: https://bugs.openjdk.java.net/browse/JDK-821
Release-note: https://bugs.openjdk.java.net/browse/JDK-8244460
webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.00/
The
Looks good to me.
Thanks,
Xuelei
On 5/2/2020 7:30 AM, Alan Bateman wrote:
I need a reviewer for a small update to
test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java. The
test accesses a private field in com.sun.crypto.provider from a VM
launched by the test. The launched VM
Hi,
Could I get the following update reviewed:
http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/
For TLS 1.3 full handshake, if the last handshake flight wraps the
Finished together with other handshake message, for example client
certificate, the flight could be wrapped and encrypted
Hi Tony,
Thanks for the review. I will update the typo before commit.
Xuelei
On 4/24/2020 10:08 AM, Anthony Scarpino wrote:
On 4/23/20 1:14 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8236464/webrev.00/
In the current
Looks fine to me.
Thanks,
Xuelei
On 4/24/2020 8:42 AM, sha.ji...@oracle.com wrote:
Hi,
DHE_DSS cipher suites cannot work with SHA256withDSA (key size 2048)
certificates over pre-TLSv1.2 protocols.
Please see JDK-8242928 for more details.
This fix takes the test to use a SHA1withDSA
Looks good to me.
Thanks,
Xuelei
On 4/19/2020 6:33 PM, sha.ji...@oracle.com wrote:
Hi,
This patch introduces a flexible test framework for supporting JSSE
interop testing.
This framework supports the SSL/TLS communication between not only JDK
builds,
but also possibly other TLS
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8236464/webrev.00/
In the current implementation, the sending of close_notify may not
respect the SO_LINGER setting in some circumstances. With this update,
the delivering of close_notify alert will
It looks fine to me. Thank you!
Xuelei
On 4/23/2020 12:43 AM, sibabrata.sa...@oracle.com wrote:
Hi Xuelei,
Please review the patch for,
JBS: https://bugs.openjdk.java.net/browse/JDK-8242929
Webrev: http://cr.openjdk.java.net/~ssahoo/8242929/webrev.00/
This is a small fix to make named
notes in the CSR.
Also, what is the
behavior if there are syntax errors (ex: not using a comma) in the format?
It was stated that "Unrecognized or unsupported signature scheme names
specified in the property are ignored".
Thanks,
Xuelei
--Sean
On 4/14/20 11:42 PM, Xuelei Fan wr
be changed to reflect
that your forcing a single signature scheme.
--Jamil
On 4/14/2020 8:42 PM, Xuelei Fan wrote:
ping ...
On 4/3/2020 4:13 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
Bug: https
It looks good to me.
Nice to see a a new template!
Thanks,
Xuelei
On 4/8/2020 1:18 PM, Anthony Scarpino wrote:
Hi,
I'd like a review of the following change. There wre inconsistencies
with SSLSession and session caching that needed to be fixed. They are:
- With stateless resumption,
ping ...
On 4/3/2020 4:13 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
Release-note: https
I added my name to the CSR.
> On Apr 7, 2020, at 6:41 PM, Weijun Wang wrote:
>
> Can you please add your name as a CSR reviewer?
>
> Thanks,
> Max
>
>> On Apr 8, 2020, at 9:25 AM, Xuelei Fan wrote:
>>
>> +1.
>>
>> Xuelei
>>
+1.
Xuelei
On 4/7/2020 6:18 PM, Hai-May Chao wrote:
Hi Max,
Changes look good to me.
Is there a man page bug being filed for this?
Thanks,
Hai-May
On Apr 7, 2020, at 1:04 AM, Weijun Wang wrote:
I am thinking about removing the `jarsigner -altsigner -altsignerpath` options
and
+1.
Xuelei
On 4/7/2020 5:46 PM, Hai-May Chao wrote:
Hi Max,
Changes look good to me.
Hai-May
On Apr 6, 2020, at 8:11 PM, Weijun Wang wrote:
Please review the fix at
http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
The major change is inside X509CRLImpl.java to allow params
The conContext.isBroken condition in line 1124 is duplicated, and could
be safely removed, I think. Otherwise, looks good to me. I don't think
there's need for another round of RFR.
Thanks,
Xuelei
On 4/7/2020 12:53 PM, Jamil Nimeh wrote:
Hello all,
This is a fix that brings the JSSE
On 4/5/2020 1:41 PM, Anthony Scarpino wrote:
On 4/4/20 6:11 PM, Xuelei Fan wrote:
Hi,
Could I have the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8215711/webrev.00/
In the current TLS implementation, if one of "supported_groups"
extension and "key_s
Hi,
Could I have the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8215711/webrev.00/
In the current TLS implementation, if one of "supported_groups"
extension and "key_share" extension is not present in the ClientHello
handshake message, the internal_error alter will be
Hi,
Could I get the following update reviewed?
Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
Release-note: https://bugs.openjdk.java.net/browse/JDK-8242147
A third
Please update copyright year to 2020.
SSLEngine.java
--
@@ -1109,10 +1115,14 @@
+ * @implNote
+ * The JDK SunJSSE provider implementation returns false unless
{@link setUseClientMode}
+ * is used to change the mode to true.
For the link, I may add parameter,
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
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 like:
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:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8215712/webrev.00/
While parsing the extensions, the alter used in the implementation may
no comply to the specification. With this fix, an improvement is made
by passing the HandshakeContext to the
Updated in my local workspace. I would not update the webrev and CSR
unless you want a check.
Thanks,
Xuelei
On 3/16/2020 12:19 PM, Sean Mullan wrote:
On 3/16/20 12:49 PM, Xuelei Fan wrote:
Good catch! Updated in the webrev:
http://cr.openjdk.java.net/~xuelei/8241039/webrev.01/
While you
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
on(
"This method is deprecated and marked for removal. Use the
" +
"getPeerCertificates() method instead.");
--Sean
On 3/16/20 12:25 AM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
Bug: https://bugs.openjdk.java.net/browse/JDK-824
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://bugs.openjdk.java.net/brows
, 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 which JDK
, and then come back for
the removal in a few years.
For more details, please refer to the new code review request:
https://mail.openjdk.java.net/pipermail/security-dev/2020-March/021421.html
Thanks & Regards,
Xuelei
On 3/12/2020 10:34 AM, Xuelei Fan wrote:
And the release note task:
h
1 - 100 of 1967 matches
Mail list logo
