RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java fails

A recently added test case lacks sufficient permissions to read a conf file when running with security manager. bug report : https://bugs.openjdk.java.net/browse/JDK-8162916 proposed patch : diff --git a/test/sun/security/krb5/auto/unbound.ssl.policy

Re: [jdk9] RFR: 8163896: Finalizing one key of a KeyPair invalidates the other key

Not sure how you end up finding such issues Ivan! The fix looks good. One suggestion on the testcase. Could you make it more generic ? i.e. don't just test the MSCAPI provider. Let's cycle through all providers available for KeyPairGenerator and ensure no other provider suffers (or

Re: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509 certificates

Looks good. Thanks. Regards, Sean. On 10/08/16 17:39, Vincent Ryan wrote: I’ve updated the webrev to include your suggestion: http://cr.openjdk.java.net/~vinnie/8163503/webrev.01/ Thanks. On 10 Aug 2016, at 10:59, Seán Coffey <sean.cof...@oracle.com> wrote: It would be good if

RFR : 8147772, 8163104

Looking to backport the following two bug fixes to jdk8u-dev : JDK-8147772 Update KerberosTicket to describe behavior if it has been destroyed and fix NullPointerExceptions JDK-8163104 Unexpected NPE still possible on some Kerberos ticket calls The changes are similar to JDK 9 expect that the

Re: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509 certificates

It would be good if we can print the cert class type in the new exception if the instanceof check fails. Regards, Sean. On 09/08/16 19:14, Vincent Ryan wrote: Please review this fix to improve the error handling for attempts to store a Certificate object in PKCS12 keystore. The PKCS12

Re: JDK-8152524

Hi Sheon, only see your mail now. The issue turned out to be a McAfee issue. They issued a new patch. You'll have to contact them. Regards, Sean. On 13/07/2016 23:57, sheon banks wrote: Hi All, This message is actually for Sean Coffey in relation to the JDK-8152524. I saw the incident on

Re: Code Review Request JDK-8162362, Cannot enable previously default enabled cipher suites

looks good. Regards, Sean. On 03/08/16 10:23, Xuelei Fan wrote: New webrev: http://cr.openjdk.java.net/~xuelei/8162362/webrev.01/ On 8/3/2016 4:13 PM, Seán Coffey wrote: Hi Xuelei, Thanks for taking this one on. I think the approach looks good. Some minor comments .. Can we update bug

Re: Code Review Request JDK-8162362, Cannot enable previously default enabled cipher suites

Hi Xuelei, Thanks for taking this one on. I think the approach looks good. Some minor comments .. Can we update bug description to something like "Introduce system property to control enabled ciphersuites" SSLContextImpl.java : typo : getCustomizedCipehrSuites --> getCustomizedCipherSuites

Re: RFR: 8153948: sun/security/mscapi/ShortRSAKey1024.sh fails with "Field length overflow"

Looks like a good test fix to me Ivan. Regards, Sean. On 29/06/2016 16:20, Ivan Gerasimov wrote: Hello! The mentioned test was seen failing on a machine, where the keystore contains a lot of certificates because they overflowed the maximum allowed list of authorities in the

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

! thanks, Sean. Thanks Max On Jun 30, 2016, at 6:59 PM, Seán Coffey <sean.cof...@oracle.com> wrote: minor comment from me Max. src/java.base/share/classes/sun/security/tools/KeyStoreUtil.java 293 throw new IllegalArgumentException("No provider found"); Can you print t

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

minor comment from me Max. src/java.base/share/classes/sun/security/tools/KeyStoreUtil.java 293 throw new IllegalArgumentException("No provider found"); Can you print the provider name that was being searched for in your exception ? Regards, Sean. On 30/06/2016 04:18, Wang Weijun

Re: [8u-dev] Request for Review + Request for Approval for 8147969: Print size of DH keysize when errors are encountered

at). Thank you, Svetlana On 24.06.2016 9:59, Seán Coffey wrote: src/share/classes/sun/security/ssl/ServerHandshaker.java : ! "Unsupported customized DH key size: " + ! customizedDHKeySize + ". " + !

Re: JDK-8144566

Looks like a good candidate for backporting to jdk8u-dev. A backport record has been opened. Regards, Sean. On 15/06/16 09:50, Jaroslav Kameník wrote: Hi, could you please backport fix for this bug into JDK8? We run into it recently, our use case works well with JDK9, but it is long time to

Re: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ?

2 PM, Seán Coffey <sean.cof...@oracle.com <mailto:sean.cof...@oracle.com>> wrote: On 01/06/2016 03:42, Jim Manico wrote: I think this is the right answer. From https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support The SSL/TLS implementatio

Re: Query - Does JSSE library implement the Ciphers or Algorithms of a SSL protocol ?

On 01/06/2016 03:42, Jim Manico wrote: I think this is the right answer. From https://stackoverflow.com/questions/27323858/java-6-ecdhe-cipher-suite-support The SSL/TLS implementation "JSSE" in Java 1.6 and later supports ECDHE suites*IF there is an available (JCE) provider*for needed ECC

Re: [jdk9] RFR: 8080273: JCA Signature provider service loading bottlenecks

Ivan, apologies for late review. I like the approach taken. It should help minimize contention. I'd have to highlight though that most contention seen in this area will be probably down to lack of raw CPU power. As RSA key lengths continue to grow, more CPU calculations will become

Re: RFR: 8158111: Make handling of 3rd party providers more stable

Looks good Ivan. Given that we know that the cipher transformation is RSA/ECB/PKCS1Padding, maybe you can consider printing that in the exception. As a result, maybe something like : + System.out.println("Retrieval of RSA/ECB/PKCS1Padding cipher transformation" + +

Re: RFR JDK-8000415: Add support for SHA-3

Valerie, some comments on supportability of the new code. Some handling could be improved to contain context perhaps : sun/security/provider/SHA3.java +if (numOfPadding < 1) { +throw new ProviderException("Incorrect pad size"); Can we print the numOfPadding value ? +

Re: Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread

Logged https://bugs.openjdk.java.net/browse/JDK-8156841 Regards, Sean. On 10/05/2016 14:51, Mark Thomas wrote: Hi, While working my way through Tomcat's memory leak protection / detection / fixing code, I have found an issue that remains unresolved in the latest JDK 9 source. The poller

Re: [8u-dev] Request for Review and Approval to backport: 8133070: Hot lock on BulkCipher.isAvailable

Approved for jdk8u-dev. Regards, Sean. On 27/04/16 16:09, Xuelei Fan wrote: The update looks to to me. Thanks, Xuelei On 4/27/2016 1:03 AM, Ivan Gerasimov wrote: Thank you Jianhao Mo for contributing the patch for the backport! I see Alibaba Group Holding Limited on the OCA Signatories

Re: [jdk9] RFR: 8154947: Send empty list of authorities in CertificateRequest, if server has too many of them

Looks like a fair approach to solving this issue Ivan. A few comments from me : typo : authoririesOverflow --> authoritiesOverflow typo : handleAuthoritesOverflow --> handleAuthoritiesOverflow typo : jdk.tls.handleCertReqAuthoritesOverflow --> jdk.tls.handleCertReqAuthoritiesOverflow +

Re: Code Review Request 8072452 Support DHE sizes up to 8192-bits

Looks good! Thanks, Sean. On 15/04/2016 02:41, Xuelei Fan wrote: Good points! I made the update accordingly. http://cr.openjdk.java.net/~xuelei/8072452/webrev.04/ Thanks, Xuelei On 4/15/2016 1:33 AM, Seán Coffey wrote: without sounding like a broken record(!), can I ask that new

Re: Code Review Request 8072452 Support DHE sizes up to 8192-bits

without sounding like a broken record(!), can I ask that new exceptions provide better information (where possible) ? com/sun/crypto/provider/DHKeyPairGenerator.java +throw new InvalidParameterException( +"Keysize must be multiple of 64, and can only range " +

Re: [8u-dev] Request for Review + Request for Approval for Backport : 8048147: Privilege tests with JAAS Subject.doAs + 8076486 (test's fix)

Approved for jdk8u-dev. Regards, Sean. On 07/04/2016 15:00, Wang Weijun wrote: The jdk8 changeset looks fine. Thanks, Max On Apr 5, 2016, at 9:58 PM, Svetlana Nikandrova wrote: Hello, please review and approve the backport of tests enhancement: Original

Re: RFR : 8153531: Improve exception messaging for RSAClientKeyExchange

Thanks. Line width adjustments made and changes pushed : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0b18ad7184bc Regards, Sean. On 06/04/2016 00:21, Xuelei Fan wrote: Looks fine to me. Please keep each line bellow 80 characters. Thanks, Xuelei On 4/6/2016 2:23 AM, Seán Coffey wrote

RFR : 8153531: Improve exception messaging for RSAClientKeyExchange

Some trivial updates to exception messages that should ease debugging for future issues: https://bugs.openjdk.java.net/browse/JDK-8153531 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8153531/webrev/ one edit I thought I'd highlight: I've converted this exception into an SSLException to

Re: RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

A few comments from supportability side of the table. = sun/security/provider/AbstractDrbg.java +if (dp.getStrength() > strength) { +throw new IllegalArgumentException("strength too high"); +} +if (result.length > maxNbLength) { +

Re: Code Review Request 8149017 Delayed provider selection broken inRSA client key exchange

Looks ok to me Xuelei - tricky one to test, we should ensure some 3rd party interoperability testing is run. Would it make sense to append to the exception message to the debug message on line 135 ? i.e. 132 if (debug != null && Debug.isOn("handshake")) { 133 System.out.println("The Cipher

Re: RFR 8138653: Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations should be upgraded

I think you might have forgotten the PKCS11 implementation Sean. e.g. src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java On a side note, I notice a discrepancy in the KeyPairGenerator javadoc. It's more of an implNote issue : If the algorithm is

Re: Code Review Request 8149417 Use final restricted flag

On 18/02/2016 02:09, Wang Weijun wrote: IMO a noreg-trivial is enough. Why ? Yes -- the fix may be trivial but a testcase helps ensure that no engineer even reverts this field in the future without seeing this issue. Code goes through churning and people forget edits made in the past -

Re: RFR : 8038837:Add support to jarsigner for specifying timestamp hash algorithm

did you remove the JarSignerParameters class definition inside jarsigner/Main.java? Was it duplicated somewhere else? Thanks Max On Jan 27, 2016, at 11:09 PM, Seán Coffey <sean.cof...@oracle.com> wrote: Hi, I'd like to backport this enhancement to JDK 8u. It's been approved via CCC p

RFR : 8038837:Add support to jarsigner for specifying timestamp hash algorithm

Hi, I'd like to backport this enhancement to JDK 8u. It's been approved via CCC process already. The fix differs to that in JDK 9 in that I've chosen not to update the JDK 9 deprecated ContentSignerParameters interface. That was a request from Dev engineer. For jdk8u, the tSAPolicyID

Re: RFR: 8147931 - Incorrect edits for JDK-8064330

Looks good. Regards, Sean. On 21/01/2016 10:26, Rob McKenna wrote: Apologies folks, managed to overwrite a changeset when pushing 8064330 a few minutes ago. Looking to rectify asap: http://cr.openjdk.java.net/~robm/8147931/webrev.01/ -Rob

Re: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension

Hey Vinnie, question on SSLParameters.setApplicationProtocols(String[] protocols) method What happens if you pass an empty array into this method. Shouldn't it throw an IllegalArgumentException ? In ALPNExtension.java : +if (listLength < 2 || listLength + 2 != len) { +

Re: Fwd: Need permission for viewing JDK-8067664

There isn't much information available in 8067664. The workaround appears to be as per the short comment - use buffered I/O. /@ DataOutputStream out = new DataOutputStream(new/ /@ BufferedOutputStream(socket.getOutputStream()));/ Seems like a strange bug for sure. Would be good to get some

Re: RFR : 8133535: Better exception messaging in Ucrypto code

On 08/09/2015 10:42, Ivan Gerasimov wrote: Thanks, Seán! On 08.09.2015 11:00, Seán Coffey wrote: With recent changes from (JDK-8132082) affecting the same ucrypto code, I've re-based my patch. Here's the new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9.v2/webrev

Re: RFR : 8133535: Better exception messaging in Ucrypto code

With recent changes from (JDK-8132082) affecting the same ucrypto code, I've re-based my patch. Here's the new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9.v2/webrev/ Regards, Sean. On 24/08/2015 13:54, Seán Coffey wrote: Hoping to improve some of the exception messaging

Re: [9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources

- removed unused field - removed unused imports Artem On 09/02/2015 01:23 PM, Seán Coffey wrote: Hi Artem, I'll let the main review to other reviewers but while we're here, can you consider improving the original exception message that was seen in this issue ? In LDAPCertStore constructor

Re: RFR 8132082: Let OracleUcrypto accept RSAPrivateKey

Looks good to me Ivan. Thanks for handling. Some new exception messages need padding out as per efforts in 8133535 but I'll re-sync/rework my patch once your changes hit the repo. Regards, Sean. On 03/09/2015 16:53, Ivan Gerasimov wrote: Hello! Would you please help review this fix, which

Re: [9] RFR: 8134708: Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources

Hi Artem, I'll let the main review to other reviewers but while we're here, can you consider improving the original exception message that was seen in this issue ? In LDAPCertStore constructor : } else { throw new InvalidAlgorithmParameterException(

RFR : 8133535: Better exception messaging in Ucrypto code

Hoping to improve some of the exception messaging that is thrown from Ucrypto code. I'm hoping to tackle other components in the security libraries on a case by case basis. Aim is to improve exception messages and capture detail for end user where possible. bug report :

RFR: (XS) : 8131665: Bad exception message in HandshakeHash.getFinishedHash

Bug report : https://bugs.openjdk.java.net/browse/JDK-8131665 Simple fix to improve the Error message for this scenario. diff --git a/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java b/src/java.base/share/classes/sun/security/ssl/HandshakeHash.java ---

Re: RFR 8130022: Use Java-style array declarations consistently

Looks good to me.. and is much easier to read now! Regards, Sean. On 08/07/2015 16:35, Ivan Gerasimov wrote: Hello! We've got a request to fix javadoc for SecureRandom, so that the example code will read byte[] bytes = new byte[20]; instead of byte bytes[] = new byte[20]; I took

Re: RFR 8130022: Use Java-style array declarations consistently

On 08/07/2015 18:14, Ivan Gerasimov wrote: On 08.07.2015 18:57, Seán Coffey wrote: Looks good to me.. and is much easier to read now! Thanks Seán for review! I've missed some portion of update int the previous webrev. Now, sending the whole changeset: http://cr.openjdk.java.net/~igerasim

Re: RFR : 8080102: Java 8 cannot load its cacerts in FIPS. no such provider: SunEC

/2015 3:21 AM, Seán Coffey wrote: Looking to resolve a recently reported issue where the P11ECKeyFactory class has too much dependence on the SunEC provider. With some reshuffling and creation of a new P11ECUtil class, I was able to remove the call for lookup of SunEC Provider. The test picks up

RFR: 8077418: StackOverflowError during PolicyFile lookup

A regression has been discovered after JDK-8058547 was fixed in 8u60. For now, I'm proposing we back the fix out from the jdk8u-dev forest and plan a new fix. This is a straight-forward anti delta of 8058547 JDK 9 is not impacted since JDK-8055753 already removed this code. bug :

RFR : 8080102: Java 8 cannot load its cacerts in FIPS. no such provider: SunEC

Looking to resolve a recently reported issue where the P11ECKeyFactory class has too much dependence on the SunEC provider. With some reshuffling and creation of a new P11ECUtil class, I was able to remove the call for lookup of SunEC Provider. The test picks up the regression when running

Fwd: 8078439: 8048194: possible bug in commit for these two fixes

FYI, concerns from Darwin on the 8078439: 8048194 fixes. regards, Sean. Forwarded Message Subject:8078439: 8048194: possible bug in commit for these two fixes Date: Wed, 20 May 2015 16:28:29 -0700 From: Darwin Felix darwinfe...@yahoo.com To:

Re: [8u-dev] Request for review AND approval to backport: 8077102:

Approved. Regards, Sean. On 21/05/2015 07:46, Weijun Wang wrote: Code change is fine. Thanks Max On 5/21/2015 12:58 AM, Ivan Gerasimov wrote: Hi! The backport required some manual editing, thus I'm asking for a review too. Would you please review and approve backporting this fix? BUGURL:

Re: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath (8055207)

http://cr.openjdk.java.net/~juh/8054037/02/ Looks good. regards, Sean. On 03/03/2015 18:25, Jason Uh wrote: Thanks for catching that. Here it is with the HandshakeMessage.java changes. I'll push with both bug IDs. On 03/03/2015 01:25 AM, Seán Coffey wrote: Jason, I think you're missing

Re: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath (8055207)

, Seán Coffey wrote: Jason, thanks for taking this on. Your changes look fine to be and should help the debugging experience. Some extra comments from me. Here's some standard output that one sees (early in connection) from a standard TLS connection attempt with verbose certpath logging

Re: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath

Jason, thanks for taking this on. Your changes look fine to be and should help the debugging experience. Some extra comments from me. Here's some standard output that one sees (early in connection) from a standard TLS connection attempt with verbose certpath logging : certpath:

Re: [9] RFR: 8054037: Improve tracing for java.security.debug=certpath

Hi Jason, I just spotted this thread now. Thanks for taking this on. I'd like to do some testing with your new patch and get back to you tomorrow. Will update then! regards, Sean. On 13/02/2015 00:05, Jason Uh wrote: Please review this change, which augments some of the debug statements

RFR: 8065994: HTTP Tunnel connection to NTLM proxy reauthenticates instead of using keep-alive

Looking for a review around this issue that came in as a reported performance regression in NTLM proxy authentication. It turned out that HttpsClients were being discarded after Proxy SocketAddress equality tests failed. Lack of caching is expensive in terms for performance for TLS and

Re: DSA with keylength 1024 no longer accepted (jdk7u-dev Digest, Vol 43, Issue 8)

Peter, the issue you reference isn't a problem in jdk7u. - for the Oracle JDK at least. The code snippet your refer to is from jdk8 source code. The key length restriction was initially introduced as a side effect of this fix in JDK 8 https://bugs.openjdk.java.net/browse/JDK-7044060 That

Re: DSA with keylength 1024 no longer accepted

Hi Peter, security-dev is best mailing list to discuss this issue, I'm cc'ing that list and bcc'ing off jdk7u-dev. Are you hitting this issue with JDK 8 and later ? (I'll assume so) - You've hit https://bugs.openjdk.java.net/browse/JDK-8039921 To aid compatibility, it's been decided to relax

Re: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224

there are settings on the Apache webserver that allow it to still accept DH keys of less than 2048 bits. Is that the case ? regards, Sean. On 08/01/15 19:08, Seán Coffey wrote: Thanks for the code reviews Valerie. Andrew - looks like you need to submit new review with 7169496. Note that you still

Re: request for review : 8052406: SSLv2Hello protocol may be filtered out unexpectedly

Ping. regards, Sean. On 02/10/2014 10:19, Seán Coffey wrote: I should have prefixed my comments with point that this is a request for review given the changes. Subject updated. regards, Sean. On 01/10/2014 17:23, Seán Coffey wrote: Turned out that I do need to make a change to this backport

Re: RFR: 8004488 wrong permissions checked in krb5

Ping. regards, Sean. On 02/10/2014 17:34, Seán Coffey wrote: I'm looking to backport this fix to JDK 7u code line. The fix applies pretty much as is with the JDK 8 fix with the exception of not having to deal with a ServiceCreds tgt variable (Krb5Util.java) which was only introduced in JDK 8

Re: Issue JDK-8048194 backport in jdk9 ?

in the coming 1-2 weeks. regards, Sean. On 07/10/2014 11:40, Koen Serry wrote: Hi, sorry to be a bit of a nuisance, just for my info, were you able to apply the patch in JDK8u ? Thanks, Koen On 01/10/14 11:41, Seán Coffey wrote: On 01/10/14 01:38, Wang Weijun wrote: On Oct 1, 2014, at 0:05

request for review : 8052406: SSLv2Hello protocol may be filtered out unexpectedly

I should have prefixed my comments with point that this is a request for review given the changes. Subject updated. regards, Sean. On 01/10/2014 17:23, Seán Coffey wrote: Turned out that I do need to make a change to this backport. The testcase hadn't run initially on JPRT due to a new path

RFR (XS) : 8031191 Warning exception when XMLSignature logging is enabled

Simple fix to the issue reported in the bug report. I've moved the logging calls past the 'sa.initVerify(pk); call. bug : https://bugs.openjdk.java.net/browse/JDK-8031191 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8031191/webrev/ regards, Sean.

RFR: 8004488 wrong permissions checked in krb5

I'm looking to backport this fix to JDK 7u code line. The fix applies pretty much as is with the JDK 8 fix with the exception of not having to deal with a ServiceCreds tgt variable (Krb5Util.java) which was only introduced in JDK 8 for : 6355584: Introduce constrained Kerberos delegation bug

Re: Issue JDK-8048194 backport in jdk9 ?

On 01/10/14 01:38, Wang Weijun wrote: On Oct 1, 2014, at 0:05, Seán Coffey sean.cof...@oracle.com wrote: Iris is correct. This fix is in JDK 9 only. I'm not sure why you think it's fixed in jdk8u. Max - are you willing to pull this fix into the JDK 8u code line or shall I ? Public holiday

Re: Fwd: Issue JDK-8048194 backport in jdk9 ?

Iris is correct. This fix is in JDK 9 only. I'm not sure why you think it's fixed in jdk8u. Max - are you willing to pull this fix into the JDK 8u code line or shall I ? regards, Sean. On 30/09/2014 07:56, Koen Serry wrote: Hi, could anyone merge the code of jdk9 into jdk8 as supposedly

RFR: 8057813: Alterations to jdk_security3 test target

Continuation of the security test target clean up for jdk7u. 7u doesn't have the test groups concept so I had to break down some test targets to explicit directory names. Also found that the javax/xml/crypto was missing for 7u testing.

Re: [9] RFR 8056026 Debug security logging should print Provider used for each crypto operation

Thanks for tackling this one Vinnie. It'll certainly help better debug environments where several providers are available to perform similar crypto operations. One minor suggestion might be to use a simple boolean to control whether the engine provider info gets printed. i.e. change private

Re: RFR(XXS) : 8057813: Alterations to jdk_security3 test target

there: test/sun/security/krb5 \ test/sun/security/jgss \ test/com/sun/security/jgss \ test/javax/security/auth/kerberos \ Is that OK? Thanks Max On 9/10/2014 1:10, Seán Coffey wrote: On some recent JPRT test jobs, I've noticed that the jdk_security3 test target

RFR : 8052406: SSLv2Hello protocol may be filter out unexpectedly and 8057813: Alterations to jdk_security3 test target

looking to push two fixes to jdk8u : 8052406: SSLv2Hello protocol may be filter out unexpectedly This is a straight forward backport of the JDK 9. The testcase did require one minor config adjustment : pathToStores value updated to : ../../../../sun/security/ssl/etc; 8057813: Alterations to

RFR(XXS) : 8057813: Alterations to jdk_security3 test target

On some recent JPRT test jobs, I've noticed that the jdk_security3 test target is taking 40+ mins on some systems. Looking closer at test times, I see that sun/security/krb5 tests alone can take ~15-16 mins to run. I'd like to separate those tests out into their own test target (jdk_security4)

RFR : 8054019 Keytool Error publicKey's is not X.509, but X509

I'd like to bring this change into 7u only. The 7u40 7109096 fix introduced tighter conditions around Key.getFormat(). Some interoperability issues have been seen for key generators that mightn't strictly honour the ASN.1 data format of X509 keys. As a result, I don't think the restriction was

Re: RFR : 8054019 Keytool Error publicKey's is not X.509, but X509

that in JDK 9. Thanks, Sean On 09/02/2014 11:52 AM, Seán Coffey wrote: I'd like to bring this change into 7u only. The 7u40 7109096 fix introduced tighter conditions around Key.getFormat(). Some interoperability issues have been seen for key generators that mightn't strictly honour the ASN.1 data

RFR (XS) : 8057076 : Correct exception message in CertAndKeyGen.java

https://bugs.openjdk.java.net/browse/JDK-8057076 As per earlier discussion today, a simple update to the exception message used in JDK 9. diff --git a/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java

Re: [9] request for review: 8055207: keystore and truststore debug output could be much better

Looks good Vinnie. Thanks for handling this. One more comment from me.. I recently worked with a group who were reading the verbose security messages when trying to debug an SSL connection issue. They weren't sure if two-way SSL authentication was set up between the server and client. Could

Re: [8u40] Request for approval: 8046343: (smartcardio) CardTerminal.connect('direct') does not work on MacOSX

Ivan, No need to convert the JDK 9 patch here. Lambda in JDK 8u! I'm approving the jdk9 changeset for import into jdk8u-dev on condition that it applies cleanly. If it doesn't get a peer code review. regards, Sean. On 07/08/2014 13:21, Ivan Gerasimov wrote: Hello! May I ask for the

Re: RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission

. However, I am a little concerned that the security check isn't being performed in the old buggy impl. Is there any customer running into this, e.g. rely on the old behavior with security manager enabled? Valerie On 7/22/2014 2:45 PM, Seán Coffey wrote: A recent fix was introduced to preserve

RFR : 8051614 : smartcardio TCK tests fail due to lack of 'reset' permission

A recent fix was introduced to preserve the behaviour of an old buggy implementation of smartcardio Card.disconnect : https://bugs.openjdk.java.net/browse/JDK-8049250 The old behaviour is not fully restored with this flag if a security manager lacking sufficient permissions is present. This

8043200,8050158 :RC4 preference re-ordering.

Looking to backport this change to jdk7u-dev. Best security practice would be to lower the preference ordering of RC4 ciphersuites. This is work that's already in progress for JDK 8u and JDK 9. For JDK 7u, I'd also like to introduce a compatibility flag which will reverse this change in case

RFR: 8021804: Certpath validation fails if validity period of root cert does not include validity period of intermediate cert

Looking to backport this fix to the JDK 7u code line. The code was refactored in JDK 8 but the change is still easily applied. No issues with JPRT test run. bug ID: https://bugs.openjdk.java.net/browse/JDK-8021804 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8021804.7u/webrev/ JDK 8

Re: RFR [7195480]: javax.smartcardio does not detect cards on Mac OS X

Hopefully a member of the security team can help review this Ivan. It looks good to me. I'm not sure if QA run any smart card tests on mac - doesn't look like it! It could be worth following up with them to ensure they add this to their test configurations. One note on the 'noreg-existing'

RFR: 8028192 : Use of PKCS11-NSS provider in FIPS mode broken

This is more or less a backport of the 8u20 code to the 7u-dev codebase. This update fixes the SunJSSE problem that in FIPS mode, SunJSSE does not work because keys cannot be extracted from crypto device. Builds and tests are good.

RFR : 8019979 : Replace CheckPackageAccess test with better one from closed repo

I'd like to move this testcase from our internal test repo and replace the current test/java/lang/SecurityManager/CheckPackageAccess.java testcase . It's a straightforward test to ensure that the package restrictions enforced via the java.security file are those expected. The testcase should

Re: Status of old sun tracker issues?

A JIRA system is now the system of record for OpenJDK issues.[1] Work on getting that system open to external audience is ongoing. In the meantime you can reference the bug via bugs.sun.com : http://bugs.sun.com/view_bug.do?bug_id=7007966 regards, Sean. [1]

Re: [7u40] Resolve ambiguity in OCSPChecker CrlRevocationChecker

On 23/05/2013 10:45, Andrew Hughes wrote: Original Message - Andrew, Bug report just created : JDK-8015275 : Resolve ambiguity in OCSPChecker CrlRevocationChecker Looks like both classes being modified for jdk8 don't exist any longer. Ah, even better. Seems they were removed in:

Re: Code review request: 8010531: Add BadKdc* tests to problem list for solaris-sparcv9

I was wondering the same. Is this sparc only or is solaris x86 impacted also ? regards, Sean. On 22/03/2013 10:00, Alan Bateman wrote: On 22/03/2013 09:49, Weijun Wang wrote: Please take a look at http://cr.openjdk.java.net/~weijun/8010531/webrev.00/ The tests have been failed a lot

RFR for CR 7179879 : SSLSocket connect times out instead of throwing socket closed exception

Requesting a review for the following issue : http://bugs.sun.com/view_bug.do?bug_id=7179879 The SSLSocketImpl doesn't appear to handle the case where a connect operation is cancelled before an SSL session has begun (we simple ignore such a case) Fix would be to honour the close call which

Re: RFR: 7169257: Fix for 6424631 only partially ported to JDK 7 JDK 8

/2012 17:04, Seán Coffey wrote: Thanks Sean, Further testing has thrown up a testcase failure. (recursion in Policy setup) - This one skipped by me prior to logging RFR. Let me look into it and get back with an updated webrev. Regards, Sean. On 21/05/12 13:37, Sean Mullan wrote: The changes

RFR: 7169257: Fix for 6424631 only partially ported to JDK 7 JDK 8

Recently noticed that the 6424631 fix was not fully ported to the JDK 7 workspace. Porting the changes (to 8 7) so that no regression is seen for users migrating to latest JDK families. bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169257 webrev :

Re: RFR: 7169257: Fix for 6424631 only partially ported to JDK 7 JDK 8

/12 6:25 AM, Seán Coffey wrote: Recently noticed that the 6424631 fix was not fully ported to the JDK 7 workspace. Porting the changes (to 8 7) so that no regression is seen for users migrating to latest JDK families. bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169257 webrev

RFR : 7163470 : Build fails if javax.crypto src files not present.

The JDK has historically allowed builds without the javax.crypto package src. Bug fix 7058133 altered the bootclasspath for security library builds. This fix simply allows the builds to continue if javax.crypto package is not present. In such cases we append the jce.jar to bootclasspath.

RFR: 7152564: Improve CodeSource.matchLocation(CodeSource) performance

This is a backport from jdk8 (minus the javadoc changes) to jdk7u The same fix has also gone into a jdk6 update. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152564 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7152564.7u/ Regards, Sean

Re: JDK 8 Code Review Request for 7152564 and 7155693

Looks good Sean. Thanks for taking care of jdk 8 changes. Hopefully someone else can also review since I'm not an official jdk 8 reviewer. regards, Sean. On 06/04/12 14:40, Sean Mullan wrote: Hi Sean, Can you please review the code changes for the following bugs: 7152564: Improve

Re: Changeset 5052 a589a8dbde79 question

thanks for raising this point Chris. we certainly don't want any windows for such an attack. I'll revisit this. regards, Sean. On 24/02/12 13:31, Christopher Meyer wrote: Hi, please correct me if I'm wrong, but the Changeset 5052 in ZoneInfoFile could maybe draw an unexpected SideChannel at

Re: Changeset 5052 a589a8dbde79 question

hold on, the indexOf test will match with those ASCII format chars. i.e /.\56/.\56/.\56/etc/passwd.indexOf(..) returns 1. Is the fix still ok then ?christopher.me...@rub.de regards, Sean On 24/02/12 14:09, Seán Coffey wrote: thanks for raising this point Chris. we certainly don't want any

Re: updated code review request: 7099399: cannot deal with CRL file larger than 16MB

Should this test be set to run manually ? 5 mins is far too long for a jtreg unit test IMO. regards, Sean. On 13/10/2011 02:52, Xuelei Fan wrote: Looks fine to me. Xuelei On 10/13/2011 3:12 AM, Weijun Wang wrote: Sorry, a new updated webrev

Code review request for 7049079: NTSYSTEM CLASS IS LEAKING 3 WINDOWS TOKENS

This is a forward port to JDK 8 of a fix gone into jdk 5 and jdk6 releases. It'll be ported to 7u shortly after jdk8. Bug id is not public. NTSystem() obtains a native Token instance for each constructor call. This is unnecessary and Token instances should only be requested when called for,

Code review request for 7024697

This is a forward port of http://bugs.sun.com/view_bug.do?bug_id=7024697 to jdk 7 8 releases. Code change is identical to that made in jdk6. http://cr.openjdk.java.net/~coffeys/webrev.7024697/ regards, Sean.

codereview request for 7025227 6932403

Andrew, this is a code review request for the recent SSLSocketImpl issues that we've been working on. 7025227 SSLSocketImpl does not close the TCP layer socket if a close notify cannot be sent to the peer 6932403 SSLSocketImpl state issue

<    1   2   3