Please review the webrev for JDK-6996377 when you get a chance.
http://cr.openjdk.java.net/~ascarpino/6996377/webrev.01/
Thank you,
--Jamil
ke
that change.
I'll make the change on line 130 as well and look for any other
instances where I'm doing that.
Thanks!
--Jamil
On 05/08/2014 06:50 AM, Sean Mullan wrote:
On 05/07/2014 03:12 PM, Jamil Nimeh wrote:
Please review the webrev for JDK-6996377 when you get a chance.
h
Hello all,
Updated webrev to account for Sean and Xuelei's comments is here:
http://cr.openjdk.java.net/~ascarpino/6996377/webrev.02/
<http://cr.openjdk.java.net/%7Eascarpino/6996377/webrev.02/>
Thank you,
--Jamil
On 05/07/2014 12:12 PM, Jamil Nimeh wrote:
Please review the web
Hello all,
This bug was originally to resolve issues where Subject principal and
credential Set fields containing null elements could cause
NullPointerException to be thrown. It was decided to make the Subject
throw NullPointerException when attempts to construct or modify Subjects
will null
Hello all,
This is an update to the webrev for JDK-8015081 that takes into account
review changes and adds a few more tests.
http://cr.openjdk.java.net/~ascarpino/8015081/webrev.03
<http://cr.openjdk.java.net/%7Eascarpino/8015081/webrev.03>
Thanks!
--Jamil
On 05/27/2014 05:53 PM,
One more version of this webrev with minor comment changes:
http://cr.openjdk.java.net/~ascarpino/8015081/webrev.04
Thanks,
--Jamil
On 06/04/2014 04:29 PM, Jamil Nimeh wrote:
Hello all,
This is an update to the webrev for JDK-8015081 that takes into
account review changes and adds a few
Hello all,
These are some minor clean-up changes in SeedGenerator.java that were
found while fixing a different issue.
http://cr.openjdk.java.net/~xuelei/7176176/webrev.01
Thank you,
--Jamil
let the method throw the NPE?
Also, Objects.requireNonNull(o, msg) can be used in those "if (o == null)"
cases.
Thanks
Max
On Jun 10, 2014, at 23:32, Sean Mullan wrote:
Looks good to me.
--Sean
On 06/06/2014 06:16 PM, Jamil Nimeh wrote:
One more version of this webrev with minor
Next round: This one incorporates Weijun's comments and cleans up a
couple warnings in the test code.
http://cr.openjdk.java.net/~weijun/8015081/webrev.05/
--Jamil
On 06/06/2014 06:16 PM, Jamil Nimeh wrote:
One more version of this webrev with minor comment changes:
(this, PRINCIPAL_SET, inputPrincs));
} catch (NullPointerException npe) {
// Sometimes people deserialize the principals set only.
It looks you accept principals being null in serialized form. (Of course, the
new object contains a non-null one).
Hello all,
This is an update to the fix 8015081:
* Incorporate Max's comments from the previous revision
* Remove binary file test input and bring test data into
SubjectNullTests.java as byte arrays (with descriptions on how they were
made).
http://cr.openjdk.java.net/~ascarpino/8015081/webre
Hello all,
This revision for the fix for 8015081 has the following test changes:
Removal of the static byte buffers for serialized data in lieu of a more
dynamic approach. A stripped down version of Subject in its own package
is now being compiled alongside SubjectNullTests.java. This version
false;
->
1368 if (!(o instanceof SecureSet))
1369 return false;
Or I think you can re-use the spec of AbstractSet.equals() if SecureSet
extends AbstractSet.
Otherwise, looks fine to me.
Xuelei
On 6/20/2014 9:11 AM, Jamil Nimeh wrote:
Hello all,
This revision for the fix for 8015081
Hello all,
This follow-on webrev addresses the following issues:
* Adds braces to if/else constructs
* Fixes imports in Serial.java and Generic.java tests to explicitly
import javax.security.auth.Subject rather than
javax.security.auth.*. The overridden Subject.java solution in the
t
Hello all,
This is just a quick broken-link fix for SecureRandom's javadoc.
http://cr.openjdk.java.net/~ascarpino/8054366/webrev.01
Thanks,
--Jamil
On 08/08/2014 01:58 AM, Florian Weimer wrote:
On 08/07/2014 11:03 PM, Jamil Nimeh wrote:
Hello all,
This is just a quick broken-link fix for SecureRandom's javadoc.
http://cr.openjdk.java.net/~ascarpino/8054366/webrev.01
You could link to the HTML version of the RFC instead:
Hello all,
This webrev covers a fix to LoginContext so it no longer selects the
wrong method when a LoginModule method (login, logout, commit, etc.) has
been overloaded.
Bug: https://bugs.openjdk.java.net/browse/JDK-6562449
Webrev: http://cr.openjdk.java.net/~ascarpino/6562449/webrev.01
Than
Ping! Any takers out there?
Many thanks,
--Jamil
On 08/11/2014 02:56 PM, Jamil Nimeh wrote:
Hello all,
This webrev covers a fix to LoginContext so it no longer selects the
wrong method when a LoginModule method (login, logout, commit, etc.)
has been overloaded.
Bug: https
Hello everyone,
This is an updated review that addresses comments from the original webrev.
http://cr.openjdk.java.net/~ascarpino/6562449/webrev.02
Thank you,
--Jamil
On 08/11/2014 02:56 PM, Jamil Nimeh wrote:
Hello all,
This webrev covers a fix to LoginContext so it no longer selects the
21, 2014, at 5:38, Jamil Nimeh wrote:
Hello everyone,
This is an updated review that addresses comments from the original webrev.
http://cr.openjdk.java.net/~ascarpino/6562449/webrev.02
Thank you,
--Jamil
On 08/11/2014 02:56 PM, Jamil Nimeh wrote:
Hello all,
This webrev covers a fix to Log
One more update, with Max's nits addressed:
http://cr.openjdk.java.net/~weijun/6562449/webrev.03
--Jamil
On 08/20/2014 02:38 PM, Jamil Nimeh wrote:
Hello everyone,
This is an updated review that addresses comments from the original
webrev.
http://cr.openjdk.java.net/~ascarpino/65
Hello all,
The draft JEP "OCSP Stapling for TLS" has been opened up for community
review. This is an update to the original call for comments back in
mid-March this year[*]. Like some of the other early JEPs this year,
this has been brought under the JEP 2.0 process.
https://bugs.openjdk.j
f SNI I could
work around by constructing the client socket with no hostname, but I
really wish both features could be controlled dynamically.
Greetings
Bernd
Am Tue, 02 Sep 2014 14:15:45 -0700 schrieb Jamil Nimeh
:
Hello all,
The draft JEP "OCSP Stapling for TLS" has been opened up fo
Hello all,
This review fixes a small regression in the generateCertificates() and
generateCRLs() methods for the CertificateFactory class. At some point,
input consisting entirely of non-certificate data ceased to throw
CertificateException or CRLException and instead returned an empty
colle
se one.
Thanks
Max
On Sep 30, 2014, at 5:11, Jamil Nimeh wrote:
Hello all,
This review fixes a small regression in the generateCertificates() and
generateCRLs() methods for the CertificateFactory class. At some point, input
consisting entirely of non-certificate data ceased to throw
Cer
Hello all, this is an update to address review comments and some cleanup
of a couple warnings given by NetBeans.
http://cr.openjdk.java.net/~ascarpino/8032573/webrev.02/
Thank you,
--Jamil
On 09/29/2014 02:11 PM, Jamil Nimeh wrote:
Hello all,
This review fixes a small regression in the
brev: http://cr.openjdk.java.net/~ascarpino/8032573/webrev.02/
JDK 8 webrev: http://cr.openjdk.java.net/~ascarpino/8057141/webrev.01/
JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8032573
Thanks,
--Jamil
On 10/09/2014 10:09 AM, Jamil Nimeh wrote:
Hello all, this is an update to address review comment
odified to "X" to be invalid. This would help maintainers
understand where it comes from.
Thanks
Max
On Oct 15, 2014, at 1:42, Jamil Nimeh wrote:
Hello all, this is another update to JDK-8032573. This link adds the JDK 8
backport. It's pretty much the same fix, with the ad
/webrev.03
Thanks,
--Jamil
On 10/14/2014 08:24 PM, Jamil Nimeh wrote:
Thank you for the reviews and I will go make the comment changes as
you suggest.
--Jamil
On 10/14/2014 7:11 PM, Wang Weijun wrote:
Jamil
Both code changes look fine.
One suggestion: you might want to mention that the first
Hi Max, I only have very nit-picky comments/questions, actually the same
question across 4 files.
* KerberosKey.java
o 298 and 305: Should the "KerberosKey" words be inside @code braces?
* KerberosPrincipal.java
o 195: Same @code question as above with "Principal"
* KerberosTicket.j
Hi Mala, the backport looks good to me. Only one nit: I think the
comment "no crls provided" in X509Factory.java:461 should be removed
since you have the corrected comment in there.
For what it's worth I'm not an approved reviewer on the census yet so
you might need someone else to give the o
Hello all,
This is a quick fix to deal with a broken link for the RC5ParameterSpec
javadoc.
Bug: https://bugs.openjdk.java.net/browse/JDK-8058912
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8058912/webrev.01/
Thanks!
--Jamil
ry
Looks fine to me.
Just curious, why update the link of
"http://www.ietf.org/rfc/rfc2040.txt";? The link works.
Thanks,
Xuelei
On 1/7/2015 10:59 AM, Jamil Nimeh wrote:
> Hello all,
>
> This is a quick fix to deal with a broken link for the RC5ParameterSp
: 01/07/2015 5:27 PM (GMT-08:00)
To: Michael StJohns , Weijun Wang
, Jamil Nimeh
Cc: [email protected]
Subject: Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error)
to http://www.rsasecurity.com in RC5ParameterSpec class summary
Good point! Thanks for looking
Hi all,
This review is to provide length checks on the session ID for SSL/TLS
connections. It appears to be the only vector/array that needs
additional length-checks to make sure it's not exceeding 32 bytes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8044860
Webrev: http://cr.openjdk.java
ld be verified
for allowed sizes
I may use SSLProtocolException if the size of session ID is bigger than
32. Otherwise, looks fine to me.
Xuelei
On 1/23/2015 2:35 AM, Jamil Nimeh wrote:
> Hi all,
>
> This review is to provide length checks on the session ID for SSL/TLS
> connect
, Jamil Nimeh wrote:
Hi all,
This review is to provide length checks on the session ID for SSL/TLS
connections. It appears to be the only vector/array that needs
additional length-checks to make sure it's not exceeding 32 bytes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8044860
Webrev:
1/22/2015 6:27 PM, Xuelei Fan wrote:
Looks fine to me. Thanks!
Xuelei
On 1/23/2015 10:24 AM, Jamil Nimeh wrote:
Hi Xuelei, et al.:
Updated webrev:
http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.02
Thanks,
--Jamil
On 01/22/2015 04:26 PM, Xuelei Fan wrote:
I may use SSLProtocolExcepti
Hello all, this review fixes an issue in OCSPResponse where it does not
parse singleExtensions in the SingleResponse structure. I also fixed
two minor deviations from the OCSP.RevocationStatus interface when
getRevocationTime and getRevocationReason are called on good responses.
Bug: https://
mples.
Thanks,
--Jamil
On 03/02/2015 04:05 PM, Jamil Nimeh wrote:
Hello all, this review fixes an issue in OCSPResponse where it does
not parse singleExtensions in the SingleResponse structure. I also
fixed two minor deviations from the OCSP.RevocationStatus interface
when getRevocationTime and getR
Okay, I've got an updated webrev for this issue:
http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.02/index.html
Thanks,
--Jamil
On 03/03/2015 02:18 PM, Jamil Nimeh wrote:
Hello all, I've come across a couple edge cases that this fix doesn't
cover properly. I'll pu
/reviews/8074064/webrev.03/index.html
Thanks, Vinnie for the feedback and suggestions!
--Jamil
On 03/03/2015 04:10 PM, Jamil Nimeh wrote:
Okay, I've got an updated webrev for this issue:
http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.02/index.html
Thanks,
--Jamil
On 03/03/2015
r order. Regardless, I'll take a whack at it and see what happens.
Thanks for the comments!
--Jamil
--Sean
On 03/04/2015 05:50 PM, Jamil Nimeh wrote:
One more round of updates. Only the test code and the test inputs have
changed. Test input is now Base64 format, with comment headers tha
} else {
derVal == null;
}
then what is now line 794 becomes:
if (derVal != null && derVal.isContextSpecific((byte)1)) {
--Sean
On 03/04/2015 05:50 PM, Jamil Nimeh wrote:
One more round of updates. Only the test code and the test inputs have
changed. Test input is now Base64
Hello all,
This bug moves the internal MacAlg concrete class to an enum, and alters
the CipherSuite constructor to no longer use String parsing on the
cipher suite name to determine the MacAlg. Instead, the constructor now
requires the caller to pass in a MacAlg, similar to how it already tak
On 03/13/2015 08:43 AM, Sean Mullan wrote:
On 03/11/2015 06:10 PM, Jamil Nimeh wrote:
Okay, an updated webrev has been posted that addresses Sean's comments
(thanks, BTW).
http://cr.openjdk.java.net/~jnimeh/reviews/8074064/webrev.04/
Code changes look good, but I had not reviewed the
Ping?
On 03/11/2015 04:55 PM, Jamil Nimeh wrote:
Hello all,
This bug moves the internal MacAlg concrete class to an enum, and
alters the CipherSuite constructor to no longer use String parsing on
the cipher suite name to determine the MacAlg. Instead, the
constructor now requires the
ing now to
see if anything happens there. Let me know what you think.
--Jamil
On 03/14/2015 01:08 AM, Xuelei Fan wrote:
Looks fine to me.
Do you want to consider a similar conversion on BulkCipher? Maybe in a
new bug.
Thanks,
Xuelei
On 3/12/2015 7:55 AM, Jamil Nimeh wrote:
Hello all,
Thi
Hi Xuelei, this looks good to me.
--Jamil
On 3/9/2015 10:52 PM, Xuelei Fan wrote:
On 3/10/2015 12:27 PM, Jamil Nimeh wrote:
Hi Xuelei, I can't be an official reviewer, but I did look over the code
and it looks pretty good to me.
I think it is OK to push if you reviewed the code.
I did
Hi Thomas, thanks for your interest in this JEP.
As it turns out, I'm working on JDK-8046321 which is the OCSP stapling
JEP. I'm targeting mid-to-late May for the completion of client and
server-side support. I would love to have your input during the code
review process, especially since it
Hello all,
I have a first cut at the OCSP stapling webrev posted for your review:
JEP: https://bugs.openjdk.java.net/browse/JDK-8046321
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/
A couple items to note:
* I'm in the process of updating the JEP with some more details.
0) for
+ * server certificate(s) authentication. The returned
+ * list may be empty if no OCSP response was presented
+ * during handshaking.
Just for your consideration.
Xuelei
On 6/19/2015 8:27 AM, Jamil Nimeh wrote:
Hello all,
I have a first cut at the OCSP stap
Hi Thomas, thanks for the comments. I have some follow-ups below
On 06/21/2015 06:46 AM, Thomas Lußnig wrote:
Hi,
here are some comments about what i was thinking:
http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java.pat
Just one follow up from a previous set of comments:
On 06/21/2015 12:12 PM, Thomas Lußnig wrote:
On 21.06.2015 17:56, Jamil Nimeh wrote:
The X509TrustManager, if configured to do revocation checking at all,
should handle the checks so the client doesn't have to. Can you tell
me a little
ith a fatal
unexpected_message if the extension is not requested.
Yes, I think you're right. I'll fix this up too.
Xuelei
On 6/19/2015 8:27 AM, Jamil Nimeh wrote:
Hello all,
I have a first cut at the OCSP stapling webrev posted for your review:
JEP: https://bugs.openjdk.java.net/b
On 06/23/2015 01:17 AM, Bernd Eckenfels wrote:
Hello,
this is a general comment, not necesarily applicable for the OCSP
stapling options directly:
Am Tue, 23 Jun 2015 15:39:30 +0800
schrieb Xuelei Fan:
Caches, for example session/trust manager/key manager, are used a lot
in SSL/TLS handsh
I'll get this coded up
and issue a new webrev with all the comments up to now.
Xuelei
On 6/19/2015 8:27 AM, Jamil Nimeh wrote:
Hello all,
I have a first cut at the OCSP stapling webrev posted for your review:
JEP: https://bugs.openjdk.java.net/browse/JDK-8046321
Webrev: http://cr.openjd
Hello all, I've posted an updated webrev based on comments I've received
so far:
http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.1
Thanks,
--Jamil
On 06/18/2015 05:27 PM, Jamil Nimeh wrote:
Hello all,
I have a first cut at the OCSP stapling webrev posted for your re
HandshakeOutStream.putBytes24() accepts null parameter.
Yeah, that is a better way to do it and not have the unnecessary object
creation.
-
line 827/828, unlikely to happen. I would suggest you add a comment or
remove the lines.
I'll comment it.
Xuelei
On 6/27/2015 11:0
207 public final String getType() {
Looks like this method does not get used. Is it redundant?
It's gone now. I was using it when I did the ThreadLocal solution and
forgot to rip it out when we moved the logic into PKIXValidator.
Xuelei
On 6/27/
On 06/30/2015 06:04 PM, Xuelei Fan wrote:
On 7/1/2015 6:39 AM, Jamil Nimeh wrote:
src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java
==
line 713/714, 730/731 throws SSLHandshakeException for extension
constructor
On 06/30/2015 06:53 PM, Xuelei Fan wrote:
On 7/1/2015 7:38 AM, Jamil Nimeh wrote:
src/java.base/share/classes/sun/security/validator/PKIXValidator.java
=
minor comment:
Is it more instinctive if changing the parameter name
tated above, we don't create new threads for each connection.
Threads are reused when they are idle/available.
You are correct, non-empty OCSPStatusRequests are rare. I've never seen
a client do one. I've only looked at browsers, but none of them
populate the request.
I will s
On 7/2/2015 9:43 AM, Xuelei Fan wrote:
On 7/2/2015 10:26 PM, Jamil Nimeh wrote:
On 07/02/2015 05:05 AM, Xuelei Fan wrote:
sun/security/ssl/ServerHandshaker.java
==
OCSP stapling only used for certificate-based server authentication at
present. I was
Hello all,
I have an updated webrev for OCSP stapling which incorporates comments
thus far and a few bug fixes and tests.
webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.2
JEP: https://bugs.openjdk.java.net/browse/JDK-8046321
Thanks,
--Jamil
ero-length byte arrays in the returned list.
http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.2
Thanks,
--Jamil
On 07/11/2015 02:16 PM, Jamil Nimeh wrote:
Hello all,
I have an updated webrev for OCSP stapling which incorporates comments
thus far and a few bug fixes
ge. If it is a
quick change I'll get it out before the weekend is over, otherwise I'll
file the bug as you mentioned.
You can file a new bug and make the update later.
Xuelei
On 7/1/2015 10:42 AM, Xuelei Fan wrote:
On 7/1/2015 10:02 AM, Jamil Nimeh wrote:
On 06/30/2015 06:04 PM, Xuele
Hi all,
This is a quick fix to the OCSPNonceExtension class to add a couple
defensive copies to public get/set methods.
JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.00
Thanks,
--Jamil
return (nonceData != null) ? nonceData.clone() : null;
Xuelei
On 8/25/2015 12:55 PM, Jamil Nimeh wrote:
Hi all,
This is a quick fix to the OCSPNonceExtension class to add a couple
defensive copies to public get/set methods.
JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364
Webrev: http://cr
hanks,
--Jamil
On 08/25/2015 08:11 AM, Jamil Nimeh wrote:
Hi Sean,
Yes, I was just following Extension convention in terms of
implementing CertAttrSet. Within sun.security.x509, X509CertInfo uses
the set methods from other objects implementing CertAttrSet. But
OCSPNonceExtension really is
class being in a "sun" package. Thanks also for the link
[1]...interesting reading.
--Jamil
On 09/01/2015 11:29 AM, Sean Mullan wrote:
On 08/28/2015 09:25 PM, Jamil Nimeh wrote:
Hello all,
I've removed the CertAttrSet interface from OCSPNonceExtension and
trimmed away a few unn
k.java.net/~jnimeh/reviews/8134364/webrev.02/
Thanks,
--Jamil
On 09/01/2015 11:29 AM, Sean Mullan wrote:
On 08/28/2015 09:25 PM, Jamil Nimeh wrote:
Hello all,
I've removed the CertAttrSet interface from OCSPNonceExtension and
trimmed away a few unneeded methods. As a result the class i
Hello all,
This fix handles an issue in TLS client certificate authentication where
our client was failing to send a certificate after consuming the
CertificateRequest message. Thanks to Norman Maurer for bringing this
to our attention.
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/821
I will add my test information to the bug. Thanks for reviewing it.
--Jamil
Original message From: Bradford Wetmore
Date: 9/19/18 3:13 PM (GMT-08:00) To: Norman
Maurer , Jamil Nimeh
Cc: OpenJDK Dev list Subject: Re: RFR:
JDK-8210846, TLSv.1.3 interop problems with
Great news! Thanks for running the tests on your end, Norman.
--Jamil
Original message
From: Norman Maurer
Date: 9/19/18 4:32 PM (GMT-08:00)
To: Bradford Wetmore
Cc: Jamil Nimeh , OpenJDK Dev list
Subject: Re: RFR: JDK-8210846, TLSv.1.3 interop problems with
Looks good.
On 9/20/2018 1:02 PM, Xuelei Fan wrote:
Hi,
Please review this simple fix for SunJSSE debug log:
http://cr.openjdk.java.net/~xuelei/8210974/webrev.00/
The debug log for ClientHello message does not appear in JDK 12.
Trivial update, no new regression test.
Thanks,
Xuelei
Hello all,
This review is for a backport of 3 TLS interoperability issues that have
come up over the past week or so. These are already in jdk/jdk. They
cover the following issues:
* An NPE thrown during processing of the supported groups extension
with curves not enabled by default
*
Yep, code review coming in a few minutes.
--Jamil
On 9/21/2018 2:22 PM, Bradford Wetmore wrote:
Looks fine.
Where are your new regression tests for 916/334? Will that be under a
separate bug?
Thanks.
Brad
On 9/20/2018 11:51 PM, Jamil Nimeh wrote:
Hello all,
This review is for a
Hello all,
This adds a test that lets us send different kinds of client hellos to a
JSSE server. It can be extended to handle different kinds of corner
cases for client hello extension sets as well as fuzzing test cases in
the future. It also provides some extra test coverage for JDK-8210334
r one
case per test? Or break immediately if a test case failed, instead of
waiting for all to complete?
Thanks,
Xuelei
On 9/21/2018 2:35 PM, Jamil Nimeh wrote:
Hello all,
This adds a test that lets us send different kinds of client hellos
to a JSSE server. It can be extended to handle diff
uggest void.
OK, I can do that.
Hope this helps.
Brad
On 9/21/2018 2:35 PM, Jamil Nimeh wrote:
Hello all,
This adds a test that lets us send different kinds of client hellos
to a JSSE server. It can be extended to handle different kinds of
corner cases for client hello extension sets as w
, Jamil Nimeh wrote:
Are you suggesting having multiple run lines or something like that?
I think we could do that.
I would prefer to to the run lines.
I would like to have it run all cases rather than short-circuit on
the first failure, as each case doesn't depend on the others.
It should be
have to
isolate specific tests that are the ones that fail. Maybe we should
revisit those test cases in the future and see if we can do something
better.
--Jamil
On 09/21/2018 05:18 PM, Xuelei Fan wrote:
On Sep 21, 2018, at 4:45 PM, Jamil Nimeh wrote:
Hi Xuelei,
I started getting into
Hi Brad, Xuelei, et al.,
Thanks for all your comments. I've udpated the test with Brad's
findings and made it use separate @run lines for each test as Xuelei
requested.
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210918/webrev.02
--Jamil
On 09/21/2018 02:35 PM, Jamil N
Hello all, this fixes an issue where for TLSv1.2 connections
specifically, clients will not authenticate using PSS certs even when
PSS signature algorithms are asserted in the CertificateRequest
message. This brings in a method for client certificate selection
similar to how we do it for TLS 1
Hello all,
This fixes an issue with the TLS 1.3 CertificateRequest message. In
cases where the server side can initially support multiple protocol
versions by the time it issues a CertificateRequest message it collects
the list of supported signature schemes for the signature_algorithms and
s
Hello all,
This addresses an issue where the client hello in a resumed TLS 1.3
session lacks the server_name client hello extension. This can cause
servers who use this extension field to direct traffic to websites to
present other certificate chains for other websites than the one the
clien
tes? (e.g. return certs based on
their server_name?)
Otherwise, I'd to do a quick double check of a couple things in the
code, but initially it looks ok.
Brad
On 10/12/2018 9:39 PM, Jamil Nimeh wrote:
Hello all,
This addresses an issue where the client hello in a resumed TLS 1.3
se
x27;t use
the CertificateRequest.certificate_types any more. Maybe, some words
like, "Note that the certificate_types field is not used here. The
supported_signature_algorithms field has provide sufficient information".
Thanks,
Xuelei
On 10/7/2018 9:33 AM, Jamil Nimeh wrote:
Hello
int vectorLen = SignatureScheme.sizeInRecord() *
sigAlgs.size();
Thanks,
Xuelei
On 10/11/2018 10:11 AM, Jamil Nimeh wrote:
Hello all,
This fixes an issue with the TLS 1.3 CertificateRequest message. In
cases where the server side can initially support multiple protocol
ver
Hello everyone,
I've added a test to go along with the bugfix. No changes to the actual
fix itself.
Updated webrev:
http://cr.openjdk.java.net/~jnimeh/reviews/8211806/webrev.02/
Thanks,
--Jamil
On 10/12/18 9:39 PM, Jamil Nimeh wrote:
Hello all,
This addresses an issue where the c
Looks good to me.
--Jamil
On 10/23/18 12:38 PM, Sean Mullan wrote:
Please review this change to add the TLS anonymous and NULL cipher
suites to the "jdk.tls.disabledAlgorithms" security property.
These suites are used rarely and have security weaknesses. Anonymous
suites are vulnerable to ma
Hello Oleg,
Thanks for bringing this to our attention. I've filed JDK-8212885 to
track this issue. I haven't played around with my test code to look for
alternative ways to get at the peer cert chain, but I can try a few
things. I have one idea but it is completely a shot from the hip since
Hi Daniel thanks for bringing this up, this sounds like
https://bugs.openjdk.java.net/browse/JDK-8212885. I'm very close to a
fix on this one, just working out a few issues in testing.
--Jamil
On 10/8/2018 2:34 PM, Daniel Christensen wrote:
I have a custom HostnameVerifier that attempts to ex
Hello all,
This fixes an issue where TLS 1.3 resumed sessions were not carrying
forward many of the parameters from the parent session, namely the peer
certificates, but also the local certificates and a few other
SSLSessionImpl fields. This also moves the fix from an earlier, related
issue
va, I may suggest moving it to
pre_shared_key extension class. It may be a little bit safer if the
extension can be loaded in other places.
Thanks,
Xuelei
On 11/5/2018 11:51 PM, Jamil Nimeh wrote:
Hello all,
This fixes an issue where TLS 1.3 resumed sessions were not carrying
forward many o
Hi Xuelei, updated review here:
http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.02
I followed your suggestions and also cleaned up some remnant comments
and removed a double-semicolon...just cosmetic stuff.
--Jamil
On 11/6/18 10:11 AM, Jamil Nimeh wrote:
Okay, I can move this into
g.toString());;
+ MessageDigest md = MessageDigest.getInstance(hashAlg.name);
Thanks,
Xuelei
On 11/6/2018 11:05 AM, Jamil Nimeh wrote:
Hi Xuelei, updated review here:
http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.02
I followed your suggestions and also cleaned up some remnant com
Looks fine to me.
On 11/9/2018 8:43 AM, Xuelei Fan wrote:
Hi,
Could I get the following small change reviewed please?
http://cr.openjdk.java.net/~xuelei/8213694/webrev.00/
The test SSLSessionContextImpl/Timeout.java is running in the default
mode. As the test initializes the SSLContext wit
Hi Xuelei,
Content looks good. I'd remove specific references to Amazon from the
CSR (it's fine to leave it in the source bug though). Where'd you get
the 20480 session cache limit from? I saw a similar limit using the
builtin SSL session cache from NGINX, is that where that number comes
f
1 - 100 of 477 matches
Mail list logo
