[security-dev 00111]: hg: jdk7/jsn/jdk: 6648816: REGRESSION: setting -Djava.security.debug=failure result in NPE in ACC

Changeset: 7dc3b56f220f Author:xuelei Date: 2008-03-15 13:43 -0400 URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/7dc3b56f220f 6648816: REGRESSION: setting -Djava.security.debug=failure result in NPE in ACC Summary: unchecking the null pointer of the debug handle Reviewed-by: mull

[security-dev 00112]: hg: jdk7/jsn/jdk: 6618387: SSL client sessions do not close cleanly. A TCP reset occurs instead of a close_notify alert.

Changeset: d69e411f0711 Author:xuelei Date: 2008-03-16 01:37 -0400 URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/d69e411f0711 6618387: SSL client sessions do not close cleanly. A TCP reset occurs instead of a close_notify alert. Summary: closeIdelConnection() does not query the

[security-dev 00113]: hg: jdk7/jsn/jdk: 6542796: CPU issue with JSSE and tomcat

Changeset: 73f50a1c8634 Author:xuelei Date: 2008-03-16 23:46 -0400 URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/73f50a1c8634 6542796: CPU issue with JSSE and tomcat Summary: record length count error Reviewed-by: weijun ! src/share/classes/sun/security/ssl/InputRecord.java

[security-dev 00114]: hg: jdk7/jsn/jdk: 6447412: Issue with socket.close() for ssl sockets when poweroff on other system

Changeset: 280a7b75cd39 Author:xuelei Date: 2008-03-17 03:11 -0400 URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/280a7b75cd39 6447412: Issue with socket.close() for ssl sockets when poweroff on other system Summary: Support SSL sockets SOLINGER Reviewed-by: chegar ! src/share/cl

[security-dev 00134]: hg: jdk7/jsn/jdk: 6668231: Presence of a critical subjectAltName causes JSSE's SunX509 to fail trusted checks

Changeset: df5d7e6ac15e Author:xuelei Date: 2008-04-02 22:44 -0400 URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/df5d7e6ac15e 6668231: Presence of a critical subjectAltName causes JSSE's SunX509 to fail trusted checks Summary: make the critical extension known to end entity chec

[security-dev 00139]: hg: jdk7/jsn/jdk: 6546639: (spec)javax.net.ssl.SSLContext.getInstance(null) throws undocumented NPE

Changeset: c0eb84957bea Author:xuelei Date: 2008-04-11 03:33 -0400 URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/c0eb84957bea 6546639: (spec)javax.net.ssl.SSLContext.getInstance(null) throws undocumented NPE Summary: add NullPointerException description to those methods. Reviewe

[security-dev 00140]: hg: jdk7/jsn/jdk: 6546671: (spec)javax.net.ssl.TrustManagerFactory.getInstance() throws undocumented NP; ...

Changeset: da9fa1fa9b95 Author:xuelei Date: 2008-04-11 03:43 -0400 URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/da9fa1fa9b95 6546671: (spec)javax.net.ssl.TrustManagerFactory.getInstance() throws undocumented NP 5053895: (spec) Unspecified IllegalStateException in TrustManagerFa

[security-dev 00141]: hg: jdk7/jsn/jdk: 6571950: SSLSocket(raddr, rport, laddr, lport) allows null as laddr that spec doesn't reflect

Changeset: 143e1a9b51a9 Author:xuelei Date: 2008-04-11 03:50 -0400 URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/143e1a9b51a9 6571950: SSLSocket(raddr, rport, laddr, lport) allows null as laddr that spec doesn't reflect Summary: add the description that while the local address p

[security-dev 00189]: hg: jdk7/jsn/jdk: 6690018: RSAClientKeyExchange NullPointerException

Changeset: e8201036fc65 Author:xuelei Date: 2008-06-04 09:56 +0800 URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/e8201036fc65 6690018: RSAClientKeyExchange NullPointerException Summary: checking certificate key length for RSA_EXPORT key exchange Reviewed-by: wetmore, mullan ! sr

[security-dev 00404]: hg: jdk7/tl/jdk: 6728126: Parsing Extensions in Client Hello message is done in a wrong way

Changeset: 16efbe49c725 Author:xuelei Date: 2008-11-13 23:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/16efbe49c725 6728126: Parsing Extensions in Client Hello message is done in a wrong way Summary: the inputStream.read(byte[], int, 0) is not always return zero. Reviewe

[security-dev 00405]: hg: jdk7/tl/jdk: 6745052: SLServerSocket file descriptor leak

Changeset: dcb8d806d731 Author:xuelei Date: 2008-11-13 23:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dcb8d806d731 6745052: SLServerSocket file descriptor leak Summary: SSLServerSocketImpl.checkEnabledSuites() does not release the temporary socket properly Reviewed-by:

[security-dev 00417]: Re: NullPointerException at sun.security.ssl.OutputRecord.writeBuffer

Hi Kanatoko, We have had it fixed at openjdk 7, and will integrate the fix into openjdk 6 shortly. In case of users who use sun JAVA SE 6, the fix will also be integrate into the next  Java SE 6 update sooner. For more detailed, please refer to http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/dcb

[security-dev 00468]: hg: jdk7/tl/jdk: 6750401: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes, with PCKS11 provider

Changeset: 85fe3cd9d6f9 Author:wetmore Date: 2008-12-19 10:35 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/85fe3cd9d6f9 6750401: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes,with PCKS11 provider Summary: This is the JSSE portion of the fi

[security-dev 00471]: Re: hg: jdk7/tl/jdk: 6750401: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes, with PCKS11 provider

Brad Wetmore wrote: One comment tho, this probably should have been grouped together with Valerie's fix. jcheck only allows for one putback per bug id, so we may need to file a separate bug for her part. That's too bad, which make it hard to trace the consistence with jdk 6 updates. Valeri

[security-dev 00501]: Re: SSLContextFactory

Hi Bruno, I have read your jsslutils project times, it is a really good practice to wrap complex logics into a simple one. By my understanding (If I'm wrong or something missed, correct me), the underlying requirements for SSLContextFactory are: 1. multiple SSLContext instances per thread or req

[security-dev 00510]: Re: SSLContextFactory

this. It can be in a separate library indeed. Yes, it is of great help for some certain applications, but just as you said, I really don't think it should be in JRE level. Thanks, Andrew Best wishes, Bruno. Xuelei Fan wrote: Hi Bruno, I have read your jsslutils project times, it i

[security-dev 00548]: hg: jdk7/tl/jdk: 6782783: regtest HttpsURLConnection/B6216082.java throws ClosedByInterruptException

Changeset: a96a1f0edeeb Author:xuelei Date: 2009-02-04 19:10 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a96a1f0edeeb 6782783: regtest HttpsURLConnection/B6216082.java throws ClosedByInterruptException Summary: make the test robust Reviewed-by: weijun ! test/sun/securit

[security-dev 00565]: Re: SNI support in JSSE

No, and there is no plan to support it at jdk7 at present. Xuelei Richard Stupek wrote: Is SNI (Server name indication) slated to be in JDK7?

[security-dev 00566]: Re: SNI support in JSSE

urity/jsse/JSSERefGuide.html [8]: http://www.jiema.org/xref/openjdk/jdk7/jdk/src/share/classes/sun/security/ssl/HandshakeMessage.java <http://www.jiema.org/xref/openjdk/jdk7/jdk/src/share/classes/sun/security/ssl/HandshakeMessage.java#ClientHello> Xuelei Fan wrote: No, and there is no plan to suppo

[security-dev 00574]: Re: Code review request: 6780416: New keytool commands/options: -gencert, -printcertreq, -ext

> If you find the webrev too long, you might only review a part of it. sun/security/x509/SubjectInfoAccessExtension.java: This class looks fine for me except that the SubjectInfoAccessSyntax is introduced from RFC3280, so I think it would be better change line 50 from RFC5280 to RFC3280. Xue

[security-dev 00577]: Re: Code review request: 6780416: New keytool commands/options: -gencert, -printcertreq, -ext

If you find the webrev too long, you might only review a part of it. 1. src/share/classes/sun/security/x509/IssuerAlternativeNameExtension.java Adding a new constructor which allow mark this extension as critical. The spec requires "Where present, conforming CAs SHOULD mark this extension as no

[security-dev 00581]: Re: Code review request: 6780416: New keytool commands/options: -gencert, -printcertreq, -ext

Max (Weijun) Wang wrote: I will look at KeyTool.java tomorrow, others looks fine for me by now. A mini suggestion, would you please also add the "-ext" format into the usage() output? I did not find what the ext should looks like in the help message. Do you have a test case with an empty "S

[security-dev 00583]: Re: Code review request: 6780416: New keytool commands/options: -gencert, -printcertreq, -ext

ected "-ext" updates. BTW, I think there are many lines with more than 80 letters, which make the wide-diff hard to read. Xuelei Fan wrote: Max (Weijun) Wang wrote: I will look at KeyTool.java tomorrow, others looks fine for me by now. A mini suggestion, would you plea

[security-dev 00585]: hg: jdk7/tl/jdk: 4918870: Examine session cache implementation (sun.misc.Cache)

Changeset: a144afafb6fe Author:xuelei Date: 2009-02-20 12:50 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a144afafb6fe 4918870: Examine session cache implementation (sun.misc.Cache) Summary: replace sun.misc.Cache with sun.security.util.Cache Reviewed-by: weijun ! src/shar

[security-dev 00586]: hg: jdk7/tl/jdk: 6697270: Inputstream dosent behave correct

Changeset: 6bdbb2f5c763 Author:xuelei Date: 2009-02-20 13:05 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6bdbb2f5c763 6697270: Inputstream dosent behave correct Summary: do not try to read zero byte from a InputStream, and do always return immediately for zero byte readin

[security-dev 00600]: code review request: 5067458 Loopback SSLSocketImpl createSocket is throwing an exception.

I need to get a code review for: 5067458 Loopback SSLSocketImpl createSocket is throwing an exception. http://cr.openjdk.java.net/~xuelei/5067458/webrev.00/ The bug description: - i'm

[security-dev 00602]: Re: code review request: 5067458 Loopback SSLSocketImpl createSocket is throwing an exception.

ess. [1]: src/share/classes/javax/net/SocketFactory.java Thanks, Andrew Max On Feb 23, 2009, at 1:07 PM, Xuelei Fan wrote: I need to get a code review for: 5067458 Loopback SSLSocketImpl createSocket is throwing an exception. http://cr.openjdk.java.net/~xuelei/5067458/webrev.00/ <htt

[security-dev 00604]: hg: jdk7/tl/jdk: 5067458: Loopback SSLSocketImpl createSocket is throwing an exception

Changeset: 2a7c1a997102 Author:xuelei Date: 2009-02-23 17:32 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2a7c1a997102 5067458: Loopback SSLSocketImpl createSocket is throwing an exception Summary: A null hostname should be regarded as a loopback address. Reviewed-by: weiju

[security-dev 00621]: Re: SNI support in JSSE

o do that, though. What do you think? Yes, need to disable SSLv2Hello. But you can also choose to disable SSLv2Hello when enabling SNI extension in the implementation. Andrew Michael Tandy Xuelei Fan wrote: It is appreciate you'd like to investigate it. If you need more informati

[security-dev 00624]: code review request: 4773451 Support IP address based virtual hosting in default KeyManager implementation

I need to get a code review for: 4773451 Support IP address based virtual hosting in default KeyManager implementation http://cr.openjdk.java.net/~xuelei/4773451/webrev.00/ Thanks, Xuelei The bug description: --

[security-dev 00627]: Re: SNI support in JSSE

ituation is using an HttpsURLConnection. I guess it would be OK to ask users who wanted SNI support to do that, though. What do you think? Yes, need to disable SSLv2Hello. But you can also choose to disable SSLv2Hello when enabling SNI extension in the implementation. Andre

[security-dev 00633]: Re: SNI support in JSSE

Michael Tandy wrote: We can enable it always, I think, just as what the EC extension do now. But we need to consider a very small part of old servers which are not ready to read any extension data field, so we might need a approach to disable all extensions. Maybe adding a new system pr

[security-dev 00635]: Re: help me please

michel wrote: Dear friends, Two days ago, I sent you and email asked some questions about jvm and its source. But nobody answered me. It really does not look like a question about security. ;-) I am at a critical opportunity and I need to know answer to those q

[security-dev 00638]: Re: SNI support in JSSE

Michael Tandy wrote: Good point. But for FIPS-140 compliant. TLS1.0 should be used, SSL v2 Hello will not be used in a FIPS validated environment. On the subject of FIPS, perhaps you can answer a question: I gather we have FIPS support [3], but from the documentation [4] I've got no idea o

[security-dev 00639]: hg: jdk7/tl/jdk: 6549506: Specification of Permission.toString() method contradicts with JDK implementation

Changeset: b656e842e1be Author:xuelei Date: 2009-03-02 23:17 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b656e842e1be 6549506: Specification of Permission.toString() method contradicts with JDK implementation Summary: update the spec, and add double quotes around componen

[security-dev 00640]: code review request:

I need to get a code review for:   6798714 OCSPResponse class has to check the validity of signing certificate for OCSP response webrev: http://cr.openjdk.java.net/~xuelei/6798714/webrev.00/ bug detail:  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6798714 updates: check the validity

[security-dev 00643]: Re: Please review:

Max, I'm not satisfied with the fix, it try to read the *first* 1024 files in the "java.io.tmpdir", I don't know the order of the iterator of java.nio.file.Path.newDirectoryStream(), but if the order sounds like by name, by creation time, etc. I don't think the randomness is strong enough. W

[security-dev 00644]: Re: RFC for jarsigner: more warning, more concise output

Max (Weijun) Wang wrote: Hi All Looking at this bug now: jarsigner needs enhanced cert validation(options) http://bugs.sun.com/view_bug.do?bug_id=6802846 I've exchanged some emails with the bug reporter (BCC'ed :) ). Basically we found these problems with the current jarsigner: 1. Does

[security-dev 00646]: Re: Please review:

Sounds fine to me. Xuelei Weijun Wang wrote: Xuelei Fan wrote: Max, I'm not satisfied with the fix, it try to read the *first* 1024 files in the "java.io.tmpdir", I don't know the order of the iterator of java.nio.file.Path.newDirectoryStream(), but if the order sou

[security-dev 00650]: Re: code review request: 4773451 Support IP address based virtual hosting in default KeyManager implementation

hinking of using your fix for this bug as an example of how we might implement SNI in the future. BTW, could I cc to security-dev@openjdk.java.net? Done. Michael 2009/3/3 Xuelei Fan : Michael Tandy wrote: I was wondering - I see

[security-dev 00665]: Re: Review request: Infinite loop if SPNEGO specified as sun.security.jgss.mechanism

"sun.security.jgss.mechanism", it is a undocumented property, right? I think it is hard to explain why SPNEGO is request, but KRB5 given, it is not the expected behavior. Why not thrown a GSSException? Andrew Weijun Wang wrote: Hi Andrew or Valerie Please take a review at this bug fix: h

[security-dev 00683]: Re: keytool: -import reply different when length is different

Weijun Wang wrote: Hi In keytool's installReply(), there is: if (replyCerts.length == 1) { // single-cert reply newChain = establishCertChain(userCert, replyCerts[0]); } else { // cert-chain reply (e.g., PKCS#7) newChain = validate

[security-dev 00686]: hg: jdk7/tl/jdk: 6798714: OCSPResponse class has to check the validity of signing certificate for OCSP response

Changeset: f381e737916d Author:xuelei Date: 2009-03-13 12:59 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f381e737916d 6798714: OCSPResponse class has to check the validity of signing certificate for OCSP response Summary: checking validity and ocsp-nocheck extension. Revi

[security-dev 00694]: hg: jdk7/tl/jdk: 6383095: CRL revoked certificate failures masked by OCSP failures

Changeset: 181472dbbebb Author:xuelei Date: 2009-03-17 11:54 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/181472dbbebb 6383095: CRL revoked certificate failures masked by OCSP failures Summary: remove the mask if certificate revoked Reviewed-by: mullan ! src/share/classes

[security-dev 00733]: Re: Possible minor mistake in the JSSE documentation

Bruno Harbulot wrote: Hello, In the Java 6 JSSE reference guide section on customization , the default truststore type entry says "Note that the value NONE may be specified. This setting is appro

[security-dev 00778]: CRL Distribution Points and Issuing DistributionPoint Extension

Hi, In the DistributionPointFetcher.verifyCRL() [1], if CRL issuer in a certificate CRLDP is set, the CRL must set IssuingDistributionPoint extension, otherwise, the verification will failed. The codes: 300 boolean verifyCRL(X509CertImpl certImpl, DistributionPoint point, 301

[security-dev 00784]: Re: CRL Distribution Points and Issuing DistributionPoint Extension

Sean Mullan wrote: Xuelei Fan wrote: In line 318, if "idpExt == null" is true, "false" will return. I don't find any spec support such logic, it might be a bug here. I think the codes should looks like: 318 if (idpExt != null && 319

[security-dev 00845]: hg pull failed: patch cannot be decoded

$ hg pull pulling from http://hg.openjdk.java.net/jdk7/tl/jdk searching for changes adding changesets adding manifests transaction abort! rollback completed ** unknown exception encountered, details follow ** report bug details to http://www.selenic.com/mercurial/bts ** or mercur...@selenic.com *

[security-dev 00847]: Re: Code review request: 6813340: X509Factory should not depend on is.available()==0

1. 116 byte[] buffer = new byte[length]; I would like to use a fixed length, such as 1024, for memory saving for large data. Just a very very personal preference. 2. 562 ~ 567 You assume that the end character of a line is the same for all lines. That's OK, I just worry about the situ

[security-dev 00849]: Re: Code review request: 6813340: X509Factory should not depend on is.available()==0

Max (Weijun) Wang wrote: On May 25, 2009, at 6:47 PM, Xuelei Fan wrote: 1. 116 byte[] buffer = new byte[length]; I would like to use a fixed length, such as 1024, for memory saving for large data. Just a very very personal preference. I see what you mean. My attempt was read it

[security-dev 00851]: Re: Code review request: 6813340: X509Factory should not depend on is.available()==0

Max (Weijun) Wang wrote: 3. 584 ~ EOF You assume that the tag occupy only one byte, that's incorrect, the tag would occupy more than one byte when it is bigger than 30. The assume would make the following length parser code incorrect. You assume that the end of indefinite length is only one

[security-dev 00852]: Re: Code review request: 6813340: X509Factory should not depend on is.available()==0

Xuelei Fan wrote: t to support indefinite-length, I think you can simply keep reading until get two zero bytes. As I understand, "0x80 0x06 0x07 0x01 0x00 0x00" is not an indef-len BER. You're right, it is not a valid indef-len BER. I will look twice of readBERInte

[security-dev 00856]: Re: hg pull failed: patch cannot be decoded

Brad Wetmore wrote: There was a problem where the tl and tl-gate got out of sync and was fixed around 12:35 this afternoon. I don't know if it's the cause of your problem. The "hg pull" still did not work for me. but the "hg clone" works now. Thanks, Andrew b

[security-dev 00859]: Re: Code review request: 6813340: X509Factory should not depend on is.available()==0

throw new IOException("Invalid BER/DER data (too huge?)"); } I didn't support 0x84 because strictly that would mean int32 is not enough and I need to use long and another readFully()... seems not worthy. Or I can check to make sure the first length byte is &

[security-dev 00860]: hg: jdk7/tl/jdk: 6822460: support self-issued certificate

Changeset: d93b7df1e260 Author:xuelei Date: 2009-05-26 16:19 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d93b7df1e260 6822460: support self-issued certificate Summary: checking self-issued certificate during certification path building Reviewed-by: mullan, weijun ! src/sh

[security-dev 00861]: hg: jdk7/tl/jdk: 6720721: CRL check with circular depency support needed

Changeset: c3c5cc0f2a3e Author:xuelei Date: 2009-05-26 16:43 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c3c5cc0f2a3e 6720721: CRL check with circular depency support needed Summary: checking AKID of certificates and CRLs Reviewed-by: mullan, weijun ! src/share/classes/su

[security-dev 00863]: hg: jdk7/tl/jdk: 6845286: Add regression test for name constraints

Changeset: 25db260cb810 Author:xuelei Date: 2009-05-27 17:48 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25db260cb810 6845286: Add regression test for name constraints Summary: create regression test cases on name constraints Reviewed-by: weijun + test/java/security/cert

[security-dev 00873]: Re: CR 6847459 Created, P3 java/classes_secu Allow trust anchor self-issued intermediate version 1 and version 2 certificate

Hi Max, Would you please review the updates? I think JavaOne would occupy most of the time of others. Webrev: http://cr.openjdk.java.net/~xuelei/6847459/webrev.00/ No new test case, the closed/sun/security/validator/BasicTests.java covered the case. Thanks, Andrew xuelei@sun.com wrot

[security-dev 00875]: Re: CR 6847459 Created, P3 java/classes_secu Allow trust anchor self-issued intermediate version 1 and version 2 certificate

throw new CertPathValidatorException(ce); +} +} +} else { +pathLenConstraint = currCert.getBasicConstraints(); + } Xuelei Fan wrote: Hi Max, Would you please review the updates? I think JavaOne would occupy most of the time of others.

[security-dev 00877]: Re: CR 6847459 Created, P3 java/classes_secu Allow trust anchor self-issued intermediate version 1 and version 2 certificate

Weijun Wang wrote: Xuelei Fan wrote: Weijun Wang wrote: +// We choose to reject all version 1 and version 2 intermediate +// certificates except that it is self issued by the trust +// anchor in order to support key rollover or changes in +// certificate policies

[security-dev 00879]: Re: CR 6847459 Created, P3 java/classes_secu Allow trust anchor self-issued intermediate version 1 and version 2 certificate

trust anchor's certificate, it is a little bit complex. Trust anchor is not in the certification path, cert[0] is the cert directly issued by the trust anchor. So, maybe, it is reasonable, I don't think it worthy of too many changes. Thanks, Andrew Max Xuelei Fan wrote: Weijun

[security-dev 00882]: Re: CR 6847459 Created, P3 java/classes_secu Allow trust anchor self-issued intermediate version 1 and version 2 certificate

Florian Weimer wrote: What does self-issued mean? Is it the same as self-signed? Wouldn't it break the chain in that case? Self-issued certificates are those certificates in which the subject and issuer are the same entity. Self-signed certificate is a sub type of self-issued certificate

[security-dev 00883]: hg: jdk7/tl/jdk: 6847459: Allow trust anchor self-issued intermediate version 1 and version 2 certificate

Changeset: 045743e0eb2d Author:xuelei Date: 2009-06-04 11:28 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/045743e0eb2d 6847459: Allow trust anchor self-issued intermediate version 1 and version 2 certificate Reviewed-by: weijun ! src/share/classes/sun/security/provider/ce

[security-dev 00886]: Re: CR 6847459 Created, P3 java/classes_secu Allow trust anchor self-issued intermediate version 1 and version 2 certificate

Sean Mullan wrote: Xuelei Fan wrote: Many, many Verisign root certs are V1, and the intermediate cert are V3. I believe that is because many Verisign roots were issued in the late 1990's and perhaps v3 (published in 1996) had not gained enough support in the market yet. I am wond

[security-dev 00888]: code review request 6570344 Invalid RSA OID in sun.security.x509.AlgorithmId

Hi, The RSA OID from sun.security.x509.AlgorithmId is 1.2.5.8.1.1. However no such OID seems to exist. The correct one should be 2.5.8.1.1. ITU-T X.509 defined RSA encryption algorithm as: id-ea-rsa = {joint-iso-itu-t(2) ds(5) algorithm(8) encryptionAlgorithm(1) rsa(1)} rsa ALGORITHM ::= {

[security-dev 00891]: Re: code review request 6570344 Invalid RSA OID in sun.security.x509.AlgorithmId

e. --Sean Xuelei Fan wrote: Hi, The RSA OID from sun.security.x509.AlgorithmId is 1.2.5.8.1.1. However no such OID seems to exist. The correct one should be 2.5.8.1.1. ITU-T X.509 defined RSA encryption algorithm as: id-ea-rsa = {joint-iso-itu-t(2) ds(5) algorithm(8) encryptionAlgorithm(1) rs

[security-dev 00892]: hg: jdk7/tl/jdk: 6570344: Invalid RSA OID in sun.security.x509.AlgorithmId

Changeset: ffbcf1d1103c Author:xuelei Date: 2009-06-12 09:00 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ffbcf1d1103c 6570344: Invalid RSA OID in sun.security.x509.AlgorithmId Summary: change RSA OID to "2.5.8.1.1" Reviewed-by: mullan ! src/share/classes/sun/security/x509

[security-dev 00902]: hg: jdk7/tl/jdk: 6850783: InvalidityDateExtension returns reference to internal mutable state

Changeset: 1299804aa6e7 Author:xuelei Date: 2009-06-16 20:46 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1299804aa6e7 6850783: InvalidityDateExtension returns reference to internal mutable state Summary: return cloned instead of referenced object Reviewed-by: weijun ! src

[security-dev 00945]: code review request 6852744: PIT b61: PKI test suite fails because self signed certificates are being rejected

Hi, bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6852744 webrev: http://cr.openjdk.java.net/~xuelei/6852744/webrev/ Evaluation of the bug: 1. There is a loop of forward builder for self-issused intermediate certificates. The ForwardBuilder looks for the next certificate

[security-dev 00946]: code review request 6853793: OutOfMemoryError in sun.security.provider.certpath.OCSPChecker.check

Hi, bug desc: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853793 webrv: http://cr.openjdk.java.net/~xuelei/6853793/webrev/ no new regression test, trivial changes, hard to write a new test. Thanks, Xuelei

[security-dev 00950]: Re: code review request 6853793: OutOfMemoryError in sun.security.provider.certpath.OCSPChecker.check

resp = Arrays.copyOf(resp, resp.len*2); } } Also, I guess the response should be truncated back to total after the reading is complete. response = Arrays.copyOf(response, total); Thanks Max Xuelei Fan wrote: Hi, bug desc: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=68

[security-dev 00952]: Re: code review request 6853793: OutOfMemoryError in sun.security.provider.certpath.OCSPChecker.check

alid ocsp/timestamping response for we does not have similar APIs, it does not worthy new APIs. As I know, there are OCSP tests, I just wrote one weeks ago, which connects to alive OCSP server. Thanks for the review. Xuelei Thanks Max On Jul 2, 2009, at 6:39 PM, Xuelei Fan wrote: Much b

[security-dev 00953]: hg: jdk7/tl/jdk: 6853793: OutOfMemoryError in sun.security.provider.certpath.OCSPChecker.check

Changeset: c2baa2f0415e Author:xuelei Date: 2009-07-03 11:13 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2baa2f0415e 6853793: OutOfMemoryError in sun.security.provider.certpath.OCSPChecker.check Summary: allocate memory dynamically, keep reading until EOF. Reviewed-by: we

[security-dev 00954]: Re: code review request 6852744: PIT b61: PKI test suite fails because self signed certificates are being rejected

evKey = certImpl.getPublicKey(); + } else { indirectCRL = true; + } } else if (crlIssuer.equals(certIssuer) == false) { -- Thanks, Xuelei Xuelei Fan wrote: Hi, bug description: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6852744 webrev:

[security-dev 00967]: Re: code review request 6852744: PIT b61: PKI test suite fails because self signed certificates are being rejected

, I think most of the practical certificate only has one form. But as a identification process, I think it would be better to be strict and check both if present, otherwise, it will be easy to get criticized that we don't check the other one. Thanks, Andrew I'm still looking over

[security-dev 00971]: Re: code review request 6852744: PIT b61: PKI test suite fails because self signed certificates are being rejected

Sean Mullan wrote: Some additional comments in the new tests describing what path building scenarios are being tested would be very useful. OK, I will add some comments on the certification path structure. A few comments below. Everything else looks good. Xuelei Fan wrote: new webrev: http

[security-dev 00973]: Re: code review request 6852744: PIT b61: PKI test suite fails because self signed certificates are being rejected

webrev updated, adding comments to tests: http://cr.openjdk.java.net/~xuelei/6852744/webrev.02/ Sean Mullan wrote: Xuelei Fan wrote: In this block of code: 858 if (principal != null && publicKey != null && 859

[security-dev 00976]: Re: code review request 6852744: PIT b61: PKI test suite fails because self signed certificates are being rejected

Sean Mullan wrote: Xuelei Fan wrote: webrev updated, adding comments to tests: http://cr.openjdk.java.net/~xuelei/6852744/webrev.02/ In DisableRevocation.java, why do you add CRLs to the CertStore if revocation is disabled? The CRLs are useless, I will remove those lines. Thanks, Xuelei

[security-dev 00977]: hg: jdk7/tl/jdk: 6852744: PIT b61: PKI test suite fails because self signed certificates are beingrejected

Changeset: 6f26e2e5f4f3 Author:xuelei Date: 2009-07-10 17:27 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6f26e2e5f4f3 6852744: PIT b61: PKI test suite fails because self signed certificates are beingrejected Summary: make the builder aware of SKID/AKID, break the internal

[security-dev 00980]: code review request

Hi Max, Would you please review a simple bug fix of JNDI when you available? webrev: http://cr.openjdk.java.net/~xuelei/6453837/webrev.00/ simple fix, noreg-trivial Thanks, Andrew

[security-dev 00982]: hg: jdk7/tl/jdk: 6453837: PartialCompositeContext.allEmpty is buggy

Changeset: d0ce095004b2 Author:xuelei Date: 2009-07-13 23:01 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d0ce095004b2 6453837: PartialCompositeContext.allEmpty is buggy Reviewed-by: weijun ! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java

[security-dev 01009]: hg: jdk7/tl/jdk: 6449574: Invalid ldap filter is accepted and processed

Changeset: d78bfd73ee42 Author:xuelei Date: 2009-07-27 22:04 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d78bfd73ee42 6449574: Invalid ldap filter is accepted and processed Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/Filter.java + test/com/sun/jndi/ldap/Bala

[security-dev 01018]: hg: jdk7/tl/jdk: 6865482: test case BalancedParentheses.java is missing GPL header.

Changeset: 056c8e724015 Author:xuelei Date: 2009-07-28 11:15 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/056c8e724015 6865482: test case BalancedParentheses.java is missing GPL header. Reviewed-by: weijun ! test/com/sun/jndi/ldap/BalancedParentheses.java

[security-dev 01066]: hg: jdk7/tl/jdk: 6585239: Regression: 2 DNS tests fail with JDK 5.0u13 b01 and pass with 5.0u12fcs

Changeset: aface89bfcf6 Author:xuelei Date: 2009-08-11 18:27 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aface89bfcf6 6585239: Regression: 2 DNS tests fail with JDK 5.0u13 b01 and pass with 5.0u12fcs Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/dns/DnsContext.jav

[security-dev 01243]: Re: Code review request: 6880321 sun.security.provider.JavaKeyStore abuse of OOM Exception handling

Max (Weijun) Wang wrote: On Sep 22, 2009, at 4:09 PM, Florian Weimer wrote: * Max Wang: Please take a review on this code change: http://cr.openjdk.java.net/~weijun/6880321/webrev.00/ This code is still unreliable. You cannot hide OutOfMemoryError this way. The error could even be th

[security-dev 01362]: Re: 6894643: Separate out dependency on Kerberos

Looks fine to me. Xuelei Vincent Ryan wrote: > There's an updated webrev at: > > http://cr.openjdk.java.net/~vinnie/6894643/webrev.01/ > > The reflection code in KerberosClientKeyExchange has been reworked to avoid > an object initializer problem. > > > Vincent Ryan wrote: >> Hello all, >

[security-dev 01449]: Re: Code review request: 6908628: ObjectIdentifier s11n test fails

Looks fine to me. BTW, I guess listing the bug IDs in one line is the common way. Xuelei Max (Weijun) Wang wrote: > Hi Xuelei > > Please take a review at -- > >http://cr.openjdk.java.net/~weijun/6908628/webrev.00 > > Thanks > Max > > Begin forwarded message: > >> From: weijun.w...@sun.co

[security-dev 01528]: Re: Please review changes in regression test test/java/security/Provider/Turkish.java

Alan Bateman wrote: Pavel Tisnovsky wrote: Hi, please review changes in regression test jtest/java/security/Provider/Turkish.java. Webrev is available at http://cr.openjdk.java.net/~ptisnovs/Turkish/ We already discussed similar issue on jdk6-dev mailing list, concretely in this thread: h

[security-dev 01540]: hg: jdk7/tl/jdk: 6862064: incorrect implementation of PKIXParameters.clone()

Changeset: dca3a251a001 Author:xuelei Date: 2010-01-20 21:38 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dca3a251a001 6862064: incorrect implementation of PKIXParameters.clone() Reviewed-by: weijun, mullan ! src/share/classes/java/security/cert/PKIXParameters.java

[security-dev 01564]: Re: Code review request: 6919610 KeyTabInputStream uses static field for per-instance value

Looks fine to me. Xuelei On 1/25/2010 1:07 PM, Max (Weijun) Wang wrote: Hi All Please take a review at -- http://cr.openjdk.java.net/~weijun/6919610/webrev.00 Bug description follows. Thanks Max *Change Request ID*: 6919610 *Synopsis*: KeyTabInputStream uses static field for per-ins

[security-dev 01638]: hg: jdk7/tl/jdk: 6916202: More cases of invalid ldap filters accepted and processed

Changeset: 9929203a8b98 Author:xuelei Date: 2010-02-25 13:32 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9929203a8b98 6916202: More cases of invalid ldap filters accepted and processed Reviewed-by: vinnie, weijun ! src/share/classes/com/sun/jndi/ldap/Filter.java + test/co

[security-dev 01651]: Re: Code review request: 6880321 sun.security.provider.JavaKeyStore abuse of OOM Exception handling

% compatibility is a must here, I can consider it. Thanks Max On Feb 27, 2010, at 9:26 AM, Xuelei Fan wrote: Max, I think you still need to catch OOME exception in case of the resource exhaustation. OOME is unchecked exception, it should be converted to IOE as the old logic. Andrew On

[security-dev 01730]: Re: Code Review: 6614957, 6771432, 6766775

Christopher Hegarty - Sun Microsystems Ireland wrote: Hi Andrew, Michael, This review is to forward port the following three bugs from 6uXX to JDK7: 6614957: HttpsURLConnection not using the set SSLSocketFactory for creating all its Sockets 6771432: createSocket() - smpatch fail

[security-dev 01731]: Re: Code Review: 6614957, 6771432, 6766775

Christopher Hegarty - Sun Microsystems Ireland wrote: Dooh! Webrev: http://cr.openjdk.java.net/~chegar/6614957/webrev.00/webrev/ Looks fine to me. Andrew -Chris. On 22/03/2010 16:01, Christopher Hegarty - Sun Microsystems Ireland wrote: Hi Andrew, Michael, This review is to forward por

[security-dev 01743]: hg: jdk7/tl/jdk: 6693917: regression tests need to update for supporting ECC on solaris 11

Changeset: 31517a0345d1 Author:xuelei Date: 2010-03-29 13:27 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31517a0345d1 6693917: regression tests need to update for supporting ECC on solaris 11 Reviewed-by: weijun ! test/sun/security/ssl/etc/keystore ! test/sun/security/ssl

hg: jdk7/tl/jdk: 6941936: Broken pipe error of test case DNSIdentities.java

Changeset: 89f4ec9e4b33 Author:xuelei Date: 2010-04-10 09:13 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/89f4ec9e4b33 6941936: Broken pipe error of test case DNSIdentities.java Reviewed-by: chegar ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSI

Re: CR 6939248/7 Created, P4 java/classes_secu Jarsigner can't extract Extended Key Usage from Timestamp Reply currectly

Looks fine to me. Xuelei On 4/13/2010 10:47 AM, Weijun Wang wrote: > Hi Xuelei and Sean > > Please take a review on the fix for OpenJDK: > >http://cr.openjdk.java.net/~weijun/6939248/webrev.00 > > Note that I've added some check: > > 1. response cert null check > 2. extension isCritical c

Re: Code Review 6943219: test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java fail in linux

Looks fine to me. Thanks, Andrew On 4/15/2010 5:05 PM, Chris Hegarty wrote: > Hi Andrew, > > These tests have canned certs with 'localhost' as a subject alternative > name in the client certificate. This fails client authentication on the > accepted server socket if the platform returns anything

Re: code review request: 6948803/7: CertPath validation regression caused by SHA1 replacement root and MD2 disable feature

Looks fine to me. Andrew On 5/21/2010 5:34 PM, Weijun Wang wrote: > Hi Sean and Andrew > > This webrev is 6948803 for opejdk-7. Please review it: > >http://cr.openjdk.java.net/~weijun/6948803/webrev.00/ > > The src/ changes are identical to the 6u21 one. Test is enhanced, > certificates a

Re: code review request: 6948287 KDC test strange kvno

Looks fine to me. Xuelei On 4/29/2010 12:40 PM, Weijun Wang wrote: > Hi > > Please take a review at this test bug: > >http://cr.openjdk.java.net/~weijun/6948287/webrev.00 > > Thanks > Max > >> *Change Request ID*: 6948287 >> >> *Synopsis*: KDC test strange kvno >> >> Keywords: noreg-self

  1   2   3   4   5   6   7   8   9   10   >