Please review the webrev for JDK-6996377 when you get a chance.
http://cr.openjdk.java.net/~ascarpino/6996377/webrev.01/
Thank you,
--Jamil
.
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.
http://cr.openjdk.java.net
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, Jamil
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
, Objects.requireNonNull(o, msg) can be used in those if (o == null)
cases.
Thanks
Max
On Jun 10, 2014, at 23:32, Sean Mullan sean.mul...@oracle.com wrote:
Looks good to me.
--Sean
On 06/06/2014 06:16 PM, Jamil Nimeh wrote:
One more version of this webrev with minor comment changes:
http
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:
http
, at 17:26, Jamil Nimeh jamil.j.ni...@oracle.com wrote:
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
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).
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
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 has the following test changes
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
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:
http
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
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
, Jamil Nimeh jamil.j.ni...@oracle.com 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
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/6562449
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.
features could be controlled dynamically.
Greetings
Bernd
Am Tue, 02 Sep 2014 14:15:45 -0700 schrieb Jamil Nimeh
jamil.j.ni...@oracle.com:
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
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
, I can think of
renaming it to readOneBlock(firstByte, is) so inside your fix you can call
readOneBlock(perkByte, is) and in other cases call readOneBlock(is.read(), is).
This might look a little strange but hopefully you can find a more concise one.
Thanks
Max
On Sep 30, 2014, at 5:11, Jamil
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
://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 comments and some
to be invalid. This would help maintainers
understand where it comes from.
Thanks
Max
On Oct 15, 2014, at 1:42, Jamil Nimeh jamil.j.ni...@oracle.com 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 addition
/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.java
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
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:
, 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: http
/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 SSLProtocolException
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
class summary
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 RC5ParameterSpec
javadoc.
Bug: https
@oracle.com
Date: 01/07/2015 5:27 PM (GMT-08:00)
To: Michael StJohns mstjo...@comcast.net, Weijun Wang
weijun.w...@oracle.com, Jamil Nimeh jamil.j.ni...@oracle.com
Cc: security-dev@openjdk.java.net
Subject: Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error)
to http
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 have
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
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,
This bug moves
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 test
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:
,
--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 getRevocationReason
/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 02:18
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 put out another webrev
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 more
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 Fanxuelei@oracle.com:
Caches, for example session/trust manager/key manager, are used a
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:
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
) 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 stapling webrev posted for your review:
JEP: https
. 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/browse/JDK-8046321
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8046321/webrev.0/
A couple items
AIO schemes. 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
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 review:
JEP
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
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
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 stop here for the first round code review. Looking forward for
the next round webrev.
Thanks,
Xuelei
On 6/27/2015 11:06 PM, Jamil Nimeh wrote:
Hello all, I've posted
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
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/2015 11:06 PM, Jamil Nimeh wrote:
Hello all, I've posted an updated
.
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:06 PM, Jamil Nimeh wrote:
Hello all, I've posted an updated webrev
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 and tests.
webrev: http
. 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, Xuelei Fan wrote:
On 7/1/2015
) ? 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.openjdk.java.net/~jnimeh
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
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
/~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 is immutable
now
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 unneed
Hi Usha, you might try setting the System property
com.sun.security.ocsp.clockSkew. It takes an integer value for the
clock skew in seconds. Give that a try and let me know how that works out.
--Jamil
On 09/29/2015 06:49 AM, Seshadri, Usha wrote:
Hi,
The following bug reports seems to
Hello all,
While looking at CertStatusReqItemV2, I came across a left-over from
early prototyping. The class currently implements StatusRequest, but it
really shouldn't. It never caused a problem because StatusRequest
requires the implementation of length and send methods, and that class
,
--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 isn't
Hi folks, can I please get a quick review for a very simple javadoc fix
in X509KeyManager?
Bug: https://bugs.openjdk.java.net/browse/JDK-8157925
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8157925/webrev.01
Thanks!
--Jamil
d
I may use a lazy loading mode, and statusResponseManager would not be
initialized until it get used.
Thanks,
Xuelei
On 2/22/2016 4:37 AM, Jamil Nimeh wrote:
Hello all,
This fix makes a change to SSLContextImpl so it only creates a
StatusResponseManager if OCSP stapling has been enabled on the s
a HTTPS
URL:
URL url = "https://www.example.com;;
url.openConnect();// statusResponseManager may be generated
I may use a lazy loading mode, and statusResponseManager would not be
initialized until it get used.
Thanks,
Xuelei
On 2/22/2016 4:37 AM, Jamil Nimeh wrote:
Hello all,
Thi
e.com;;
url.openConnect();// statusResponseManager may be generated
I may use a lazy loading mode, and statusResponseManager would not be
initialized until it get used.
Thanks,
Xuelei
On 2/22/2016 4:37 AM, Jamil Nimeh wrote:
Hello all,
This fix makes a change to SSLContextImpl so it only cr
Hello all,
This fix makes a change to SSLContextImpl so it only creates a
StatusResponseManager if OCSP stapling has been enabled on the server
side. This fix also takes care of a deviation from the design in terms
of how SSLSockets/Engines determine if stapling has been enabled. The
new
get ignore before your update.
I may miss something. Can you have more details about this point.
On 3/3/2016 12:48 AM, Jamil Nimeh wrote:
Hello all, this fixes a minor issue with OCSP stapling, where we now do
the argument checking up-front before attempting to instantiate the
Certifi
Hello all, this fixes a minor issue with OCSP stapling, where we now do
the argument checking up-front before attempting to instantiate the
CertificateStatus handshake message object. Also I've pulled out the
OCSP stapling processing from within the clientHello method since it
already was
On 5/12/2016 10:38 AM, Anthony Scarpino wrote:
On 05/04/2016 07:08 PM, Valerie Peng wrote:
Hi,
Can someone help reviewing the changes for SHA-3?
The result has been validated against the NIST test vectors (for
BYTE-ONLY impls, i.g. input which are multiples of bytes).
The feature complete
Hello all,
We are looking to add HKDF support as a KeyGenerator into OpenJDK 9.
This will be available for general-purpose use. I've documented the
proposed API below.
RFE: https://bugs.openjdk.java.net/browse/JDK-8145255
Proof-of-concept implementation:
d
on the key spec's you provide.
This generalizes well to other KDFs including SP800-108.
I'll have to spend a little time digesting what you put down here.
Interesting stuff.
--Jamil
Mike
On 4/15/2016 2:06 PM, Jamil Nimeh wrote:
Hello all,
We are looking to add HKDF suppo
On 04/15/2016 05:02 PM, Michael StJohns wrote:
On 4/15/2016 5:33 PM, Jamil Nimeh wrote:
Hi Mike, thanks for your comments and suggestions, I need to digest
some of this but I have some follow-up questions to start:
On 04/15/2016 12:54 PM, Michael StJohns wrote:
Hi Jamil -
I need to look
.
Thanks,
Xuelei
On 8/11/2016 3:51 PM, Jamil Nimeh wrote:
Hello all,
This javadoc-only change adds references to the JSSE cipher suite list
in the Standard Names documentation for those methods which return or
can set lists of cipher suites by their String names.
JBS: https://bugs.openjdk.java.net
Hi Bernd,
For the status_request_v2 extension, both ocsp and ocsp_multi forms are
supported, with preference on the latter type. The only feature we currently
don't support right now is Responder ID selection, and that will hopefully
come in a 9 update.
--Jamil
Original message
Hi Chris, I am not an official reviewer, but this looks pretty
straightforward to me.
--Jamil
On 08/10/2016 08:42 AM, Chris Hegarty wrote:
The SunPKCS11 poller thread has no need of any user defined class loader,
so should set its context class loader to null before starting, so as to not
Hi Artem, more comments in-line
On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
Hi Jamil,
Thank you for review. Please see inline.
On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
Hi Artem,
I'm not an official reviewer but the solution for making the servers
reject connections rather than stop
Hello all,
This javadoc-only change adds references to the JSSE cipher suite list
in the Standard Names documentation for those methods which return or
can set lists of cipher suites by their String names.
JBS: https://bugs.openjdk.java.net/browse/JDK-8162808
Webrev:
if you think it's better.
Artem
On 08/12/2016 09:13 AM, Jamil Nimeh wrote:
Hi Artem, more comments in-line
On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
Hi Jamil,
Thank you for review. Please see inline.
On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
Hi Artem,
I'm not an official reviewer
Thank you Artem. The fix looks good. You just need a +1 from an official
reviewer.
--Jamil
Original message From: Artem Smotrakov
<artem.smotra...@oracle.com> Date: 8/12/16 1:07 PM (GMT-08:00) To: Jamil
Nimeh <jamil.j.ni...@oracle.com>, Security Dev OpenJDK
&
Hi Artem,
I'm not an official reviewer but the solution for making the servers
reject connections rather than stop and start looks pretty fair to me
and seems like a nice way to simulate a downed OCSP responder instead of
having to bounce it. A couple comments/questions:
I'm a bit
Hi all,
This fixes a couple problems. The first is a file descriptor leak in
the SSLSocketWithStapling test. The second is a thread exhaustion issue
that can happen when many many (> 1000) SSLContext objects are created
with StatusResponseManagers. I think this is a pretty far flung edge
Hello all,
This is a quick webrev to clarify the behavior in the javadoc for a null
URL input in the CodeSource constructors. There are a few other minor
javadoc nit fixes too.
Bug: https://bugs.openjdk.java.net/browse/JDK-8129972
Webrev:
condition was added.
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132943/webrev.02
Thanks,
--Jamil
On 08/05/2016 09:56 PM, Jamil Nimeh wrote:
Hello all,
This fixes an issue with OCSPStatusRequest selection by the server
when doing OCSP stapling. Since we currently do not support responder
Hello all,
This fixes an issue with OCSPStatusRequest selection by the server when
doing OCSP stapling. Since we currently do not support responder ID
filtering, the server should not select an OCSPStatusRequest with
responder IDs in it, else it could potentially return OCSP responses
that
Hello all,
This fixes a few typos in the Javadoc for Cipher.java.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8030132
https://bugs.openjdk.java.net/browse/JDK-8160222
Webrev:
http://cr.openjdk.java.net/~jnimeh/reviews/8030132/webrev.01/
--Jamil
Hi Max, just one nit for JDK-8044085:
The release note is one sentence, but it is a bit of a run-on. It might
be worth breaking it up into two sentences, the first for the
description and the second containing the example.
Aside from that they look good to me.
--Jamil
On 1/18/2017 6:40
Hello all,
Please review this one release note that documents a change in behavior
for the Subject class and it's underlying SecureSet collections:
Original bug: https://bugs.openjdk.java.net/browse/JDK-8015081
Release note: https://bugs.openjdk.java.net/browse/JDK-8173069
Text of the
the overall performance (though I haven't seen evidence that
there is a perf issue with this at all) then maybe an RFE is in order.
What do you think?
--Jamil
On 09/20/2016 10:32 PM, Jamil Nimeh wrote:
Hi Max and Xuelei, thanks for the feedback.
On 09/20/2016 07:52 PM, Wang Weijun wrote
AM, Wang Weijun wrote:
I am OK with your fix, but I found "(latch + 1) % Integer.MAX_VALUE" a little
difficult to understand. Does rndTab[latch & 0xff] also work?
Thanks
Max
On Sep 21, 2016, at 11:57 PM, Jamil Nimeh <jamil.j.ni...@oracle.com> wrote:
Hi Max and Xuelei,
if you like, I may suggest to use a little bit small number for
the mask, for example 0x1FFF, so that the counter variable does
not overflow either. It works if counter overflow, but better not if
we want the counter meaningful.
Xuelei
On 9/22/2016 7:29 AM, Jamil Nimeh wrote:
Hello all,
This fixes a bug found in stress testing where on faster CPUs the latch
can overflow resulting in a negative array index. The fix avoids the
overflow by resetting the latch to 0 when it reaches Integer.MAX_VALUE -
1 and will continue increasing from there.
Bug:
it just means another
spin around the outer loop and another byte dropped in the pool. And
that loop can only iterate 6 times at the most so it's not like things
can run away.
--Max
Xuelei
On 9/21/2016 8:57 AM, Jamil Nimeh wrote:
Hello all,
This fixes a bug found in stress testing where o
AM, Vincent Ryan wrote:
Looks fine to me.
Thanks.
On 22 Nov 2016, at 18:45, Jamil Nimeh <jamil.j.ni...@oracle.com> wrote:
Hello all,
This is a short webrev that adds extra debug output that will show
users which ciphers are not in the enabled list due to being
disabled by thing
Hello all,
This is a short webrev that adds extra debug output that will show users
which ciphers are not in the enabled list due to being disabled by
things like jdk.tls.disabledAlgorithms, etc.
Bug: https://bugs.openjdk.java.net/browse/JDK-8170035
Webrev:
Hello all,
This fixes an issue in ProtectionDomain, where Permission classes that
take a loose interpretation of the getActions() method and return null
cause an NPE to be thrown when a ProtectionDomain's toString method is
called (during debugging for instance).
Bug:
1 - 100 of 452 matches
Mail list logo
