From weijun.wang at oracle.com Wed Apr 1 02:48:19 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 1 Apr 2015 10:48:19 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <55143318.8050407@oracle.com> References: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> <55143318.8050407@oracle.com> Message-ID: > On Mar 27, 2015, at 00:26, Mandy Chung wrote: > >> The root repo also needs a little change: >> >> diff --git a/common/bin/unshuffle_list.txt b/common/bin/unshuffle_list.txt > > This is a new package that you don't need to include in the > unshuffle_list.txt (that's mainly for backporting use). JoeD has mentioned that this can be backported to jdk8u to ease transition to the new API. --Max From xuelei.fan at oracle.com Wed Apr 1 05:53:39 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 01 Apr 2015 13:53:39 +0800 Subject: custom critical X509v3 extensions In-Reply-To: References: Message-ID: <551B87E3.70005@oracle.com> What's the requirements for the customization? If required, alternatively, developer can customize the trust manager instead. Xuelei On 3/24/2015 8:53 PM, Jan Willem Janssen wrote: > Hi, > > When a X509TrustManager validates an endpoint certificate containing a > critical custom extension the sun.security.validator.EndEntityChecker > will always fail. While this is correct behaviour, and according to > the spec, there appears no way of adding support for custom critical > extensions on endpoint certificates?! > > -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > My world is revolving around INAETICS and Amdatu > > Luminis Technologies B.V. > Churchillplein 1 > 7314 BZ Apeldoorn > +31 88 586 46 00 > > http://www.luminis-technologies.com > http://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8169.78.566.B.01 > From weijun.wang at oracle.com Thu Apr 2 09:52:28 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 02 Apr 2015 17:52:28 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> References: <6747D17B-1BBF-48E6-9283-A07DCE6347C1@oracle.com> Message-ID: <551D115C.1010409@oracle.com> Hi All Webrev updated at http://cr.openjdk.java.net/~weijun/8056174/webrev.01/. Major changes: 1. JarSignerException is now a RuntimeException, no more ErrorCode 2. Action.java and Builder.java moved into sun.security.tools.jarsigner. Hopefully the jarsigner tool can use them. The code changes in the root repo remain unchanged. The unshuffle_list.txt also remains. We are considering backporting the enhancement to jdk8u to ease the transition from calling internal jarsigner class to this new API. Thanks to Mandy and Sean for the code review. --Max On 3/24/2015 5:47 PM, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8056174/webrev.00/ > > It provides a new jdk.Exported API JarSigner to perform jar signing. The class contains popular functions of the jarsigner tool. The jarsigner tool is unchanged and currently independent of the new class. > > The root repo also needs a little change: > > diff --git a/common/bin/unshuffle_list.txt b/common/bin/unshuffle_list.txt > --- a/common/bin/unshuffle_list.txt > +++ b/common/bin/unshuffle_list.txt > @@ -1305,6 +1304,7 @@ > jdk/src/jdk.httpserver/share/classes/com/sun/net/httpserver : jdk/src/share/classes/com/sun/net/httpserver > jdk/src/jdk.httpserver/share/classes/sun/net/httpserver : jdk/src/share/classes/sun/net/httpserver > jdk/src/jdk.jartool/share/classes/com/sun/jarsigner : jdk/src/share/classes/com/sun/jarsigner > +jdk/src/jdk.jartool/share/classes/jdk/security/jarsigner : jdk/src/share/classes/jdk/security/jarsigner > jdk/src/jdk.jartool/share/classes/sun/security/tools/jarsigner : jdk/src/share/classes/sun/security/tools/jarsigner > jdk/src/jdk.jartool/share/classes/sun/tools/jar : jdk/src/share/classes/sun/tools/jar > jdk/src/jdk.jcmd/share/classes/sun/tools/jcmd : jdk/src/share/classes/sun/tools/jcmd > diff --git a/modules.xml b/modules.xml > --- a/modules.xml > +++ b/modules.xml > @@ -1634,6 +1645,9 @@ > > com.sun.jarsigner > > + > + jdk.security.jarsigner > + > > > jdk.javadoc > > Thanks > Max > From vladimir.x.ivanov at oracle.com Thu Apr 2 20:05:52 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 02 Apr 2015 23:05:52 +0300 Subject: Lambda in security manager initialization fail In-Reply-To: <5519ABA6.2030409@gmail.com> References: <9AC801D9-750C-4168-B1A6-76C16886E3A1@oracle.com> <5519ABA6.2030409@gmail.com> Message-ID: <551DA120.30901@oracle.com> Peter, Thanks for the exhaustive analysis. Filed JDK-8076596 [1] Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8076596 On 3/30/15 11:01 PM, Peter Levart wrote: > Hi Max, > > On 03/30/2015 05:24 PM, Wang Weijun wrote: >> I have a customized security manager: >> >> import java.security.AccessController; >> import java.security.PrivilegedAction; >> >> public class A3 extends SecurityManager { >> public A3() { >> // 1. Using lambda >> AccessController.doPrivileged((PrivilegedAction) >> () -> null); >> // 2. Using inner class >> AccessController.doPrivileged(new PrivilegedAction() { >> @Override >> public Void run() { >> return null; >> } >> }); >> } >> } >> >> If I use the inner class, everything is OK. If the lambda, I see this error: >> >> $ java -Djava.security.manager=A3 >> Error occurred during initialization of VM >> java.lang.ExceptionInInitializerError >> at java.lang.invoke.BoundMethodHandle.(BoundMethodHandle.java:829) >> at java.lang.invoke.LambdaForm.createIdentityForms(LambdaForm.java:1753) >> at java.lang.invoke.LambdaForm.(LambdaForm.java:1808) >> at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:223) >> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) >> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) >> at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1612) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1797) >> at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1746) >> at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:477) >> at A3.(A3.java:6) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> at java.lang.Class.newInstance(Class.java:444) >> at sun.misc.Launcher.(Launcher.java:96) >> at sun.misc.Launcher.(Launcher.java:57) >> at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1440) >> at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1425) >> Caused by: java.lang.NullPointerException >> at sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) >> at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54) >> at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) >> at java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:1065) >> at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) >> at java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.initForBootstrap(BoundMethodHandle.java:358) >> at java.lang.invoke.BoundMethodHandle$SpeciesData.(BoundMethodHandle.java:447) >> at java.lang.invoke.BoundMethodHandle.(BoundMethodHandle.java:829) >> at java.lang.invoke.LambdaForm.createIdentityForms(LambdaForm.java:1753) >> at java.lang.invoke.LambdaForm.(LambdaForm.java:1808) >> at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:223) >> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) >> at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) >> at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:1612) >> at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:1797) >> at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1746) >> at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:477) >> at A3.(A3.java:6) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> at java.lang.Class.newInstance(Class.java:444) >> >> Any reason why? >> >> Thanks >> Max >> >> > > I'm including mlvm-dev list because I think this is caused by unusual > initialization sequence triggered by initialization of java.lang.invoke > infrastructure because lambdas use invokedynamic and method handles. The > part of stack trace that is interesting is this: > > Caused by: java.lang.NullPointerException > at sun.invoke.util.BytecodeDescriptor.parseSig(BytecodeDescriptor.java:83) > at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:54) > at sun.invoke.util.BytecodeDescriptor.parseMethod(BytecodeDescriptor.java:41) > at java.lang.invoke.MethodType.fromMethodDescriptorString(MethodType.java:1065) > at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) > > makeCbmhCtor calls MethodType.fromMethodDescriptorString(..., null) with > null ClassLoader, which propagates to the following > BytecodeDescriptor.parseMethod method: > > > static List> parseMethod(String bytecodeSignature, > int start, int end, ClassLoader loader) { > if (loader == null) > loader = ClassLoader.getSystemClassLoader(); > String str = bytecodeSignature; > int[] i = {start}; > ArrayList> ptypes = new ArrayList>(); > if (i[0] < end && str.charAt(i[0]) == '(') { > ++i[0]; // skip '(' > while (i[0] < end && str.charAt(i[0]) != ')') { > Class pt = parseSig(str, i, end, loader); > if (pt == null || pt == void.class) > parseError(str, "bad argument type"); > ptypes.add(pt); > } > ++i[0]; // skip ')' > } else { > parseError(str, "not a method type"); > } > Class rtype = parseSig(str, i, end, loader); > if (rtype == null || i[0] != end) > parseError(str, "bad return type"); > ptypes.add(rtype); > return ptypes; > } > > > this method checks for null 'loader' and replaces it with the result of > ClassLoader.getSystemClassLoader(). But invoking this method is actually > re-entering it, as this whole stack trace is started from within the > call to that method: > > .... > > .... > > at sun.misc.Launcher.(Launcher.java:96) > at sun.misc.Launcher.(Launcher.java:57) > at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1440) > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1425) > > > ...this re-entering of ClassLoader.getSystemClassLoader() also re-enters > Launcher.getLauncher(): > > > private static synchronized void initSystemClassLoader() { > if (!sclSet) { > if (scl != null) > throw new IllegalStateException("recursive invocation"); > sun.misc.Launcher l = sun.misc.Launcher.getLauncher(); > if (l != null) { > Throwable oops = null; > scl = l.getClassLoader(); > try { > scl = AccessController.doPrivileged( > new SystemClassLoaderAction(scl)); > } catch (PrivilegedActionException pae) { > oops = pae.getCause(); > if (oops instanceof InvocationTargetException) { > oops = oops.getCause(); > } > } > if (oops != null) { > if (oops instanceof Error) { > throw (Error) oops; > } else { > // wrap the exception > throw new Error(oops); > } > } > } > sclSet = true; > } > } > > > ...which returns null and the whole initialization of 'scl' is skipped, > therefore ClassLoader.getSystemClassLoader() returns null, which is > later passed to BytecodeDescriptor.parseSig(...., null) which throws NPE > when dereferencing it. > > > This re-entering of ClassLoader.getSystemClassLoader() is caused by > Launcher which instantiates a custom SecurityManager, which uses lambdas > which triggers java.lang.invoke infrastructure initialization which uses > ClassLoader.getSystemClassLoader(). > > I think that java.lang.invoke infrastructure initialization should not > need to have access to system class loader. All types it deals with are > loadable by bootstrap class loader. I too have already encountered a > problem because of that and my suggestion was to create an internal > method similar to MethodType.fromMethodDescriptorString() that would > treat null ClassLoader as bootstrap class loader and use this method for > internal initialization instead of the public one: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/MethodType.fromDescriptor/webrev.01/ > > With this patch, your A3 security manager using lambdas works normally. > > > Regards, Peter > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From xuelei.fan at oracle.com Sun Apr 5 01:29:49 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 05 Apr 2015 09:29:49 +0800 Subject: Code Review Request: 8064546 CipherInputStream throws BadPaddingException if stream is not fully read In-Reply-To: <55144612.4090308@oracle.com> References: <55144612.4090308@oracle.com> Message-ID: <5520900D.6020807@oracle.com> Looks fine to me. Xuelei On 3/27/2015 1:46 AM, Anthony Scarpino wrote: > Hi, > > I'd like a review of the below webrev: > http://cr.openjdk.java.net/~ascarpino/8064546/webrev/ > > The code change is very simple, where close() should not throw > exceptions. Most of the code change is comments that are just > informational > > The attached test goes through all the scenarios making sure AEAD and > non-AEAD ciphers operate as expected. > > thanks > > Tony From fweimer at redhat.com Mon Apr 6 20:18:48 2015 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 06 Apr 2015 22:18:48 +0200 Subject: RFR 8072394: java.security.cert.PolicyQualifierInfo needs value-based equality In-Reply-To: <54F7454D.4050906@oracle.com> References: <54D0A628.3080404@redhat.com> <54DE53E9.7010200@oracle.com> <54DE5B96.9000704@redhat.com> <54E26B6C.3040202@oracle.com> <54E35086.7090408@redhat.com> <54E7B3D1.4070402@oracle.com> <54F4728E.7070405@redhat.com> <54F7454D.4050906@oracle.com> Message-ID: <5522EA28.5070609@redhat.com> On 03/04/2015 06:47 PM, Sean Mullan wrote: > I can take care of filing an internal CCC and will let you know when > that is approved or if there are any questions. This new webrev incorporates feedback from the CCC: This needs additional tests, but I want to check first if the direction is okay. The PolicyQualifierInfoSet class is needed because there is no existing LinkedTreeSet class. I do not want to continue to use LinkedHashSet because of the denial of service risk from hash collisions (this was not a problem before because the hash was identity-based), and the cost of computing hash codes even for single-element sets. -- Florian Weimer / Red Hat Product Security From lussnig at smcc.net Mon Apr 6 20:27:27 2015 From: lussnig at smcc.net (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Mon, 6 Apr 2015 22:27:27 +0200 Subject: Jjeps 8046321 Message-ID: <5522EC2F.8030900@smcc.net> Hi, is there anyone working on OCSP-Stapling ? I patched my java version to get it running for server side. Maybe i can help with some parts of the implementation. Gru? Thomas From alexander.v.stepanov at oracle.com Wed Apr 8 11:37:55 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Wed, 08 Apr 2015 14:37:55 +0300 Subject: [9] Review Request: 8076223 Rest of tidy warning in javax.security / java.security Message-ID: <55251313.30003@oracle.com> Hello, could you please review the following fix http://cr.openjdk.java.net/~avstepan/8076223/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8076223 Just some minor HTML markup fixes for documentation. Thanks, Alexander From vincent.x.ryan at oracle.com Wed Apr 8 17:12:04 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 8 Apr 2015 18:12:04 +0100 Subject: [9] RFR 8077273: Disable the PKCS11 NSS tests on Windows Message-ID: <7C6F7B16-D192-4AB3-B78B-E89DD43489C8@oracle.com> The recent upgrade to using Visual Studio 2013 compiler and runtime has caused a problem for the NSS DLLs which are pre-built using VS2010. This change temporarily excludes the failing tests from the PKCS11 NSS test runs on Windows. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8077273 Webrev: http://cr.openjdk.java.net/~vinnie/8077273/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Apr 8 17:55:40 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 08 Apr 2015 13:55:40 -0400 Subject: [9] RFR 8077273: Disable the PKCS11 NSS tests on Windows In-Reply-To: <7C6F7B16-D192-4AB3-B78B-E89DD43489C8@oracle.com> References: <7C6F7B16-D192-4AB3-B78B-E89DD43489C8@oracle.com> Message-ID: <55256B9C.70507@oracle.com> Looks good to me, just add a noreg label to the bug. --Sean On 04/08/2015 01:12 PM, Vincent Ryan wrote: > The recent upgrade to using Visual Studio 2013 compiler and runtime has > caused a problem > for the NSS DLLs which are pre-built using VS2010. This change > temporarily excludes the failing tests > from the PKCS11 NSS test runs on Windows. > > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8077273 > Webrev: http://cr.openjdk.java.net/~vinnie/8077273/webrev.00/ > > > > From vincent.x.ryan at oracle.com Wed Apr 8 17:56:13 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 8 Apr 2015 18:56:13 +0100 Subject: [9] RFR 8077273: Disable the PKCS11 NSS tests on Windows In-Reply-To: <55256B9C.70507@oracle.com> References: <7C6F7B16-D192-4AB3-B78B-E89DD43489C8@oracle.com> <55256B9C.70507@oracle.com> Message-ID: <4378C08C-4CD6-4BC1-A119-781ECEC5B65D@oracle.com> Label added. Thanks. > On 8 Apr 2015, at 18:55, Sean Mullan wrote: > > Looks good to me, just add a noreg label to the bug. > > --Sean > > On 04/08/2015 01:12 PM, Vincent Ryan wrote: >> The recent upgrade to using Visual Studio 2013 compiler and runtime has >> caused a problem >> for the NSS DLLs which are pre-built using VS2010. This change >> temporarily excludes the failing tests >> from the PKCS11 NSS test runs on Windows. >> >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8077273 >> Webrev: http://cr.openjdk.java.net/~vinnie/8077273/webrev.00/ >> >> >> >> From jason.uh at oracle.com Wed Apr 8 19:20:22 2015 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 08 Apr 2015 12:20:22 -0700 Subject: [9] Review Request: 8076223 Rest of tidy warning in javax.security / java.security In-Reply-To: <55251313.30003@oracle.com> References: <55251313.30003@oracle.com> Message-ID: <55257F76.2010804@oracle.com> Hi Alexander, I'm not an official Reviewer, but this change looks good to me. Thanks, Jason On 4/8/15 4:37 AM, alexander stepanov wrote: > Hello, > > could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8076223/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8076223 > > Just some minor HTML markup fixes for documentation. > > Thanks, > Alexander From xuelei.fan at oracle.com Wed Apr 8 22:50:34 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 09 Apr 2015 06:50:34 +0800 Subject: [9] Review Request: 8076223 Rest of tidy warning in javax.security / java.security In-Reply-To: <55257F76.2010804@oracle.com> References: <55251313.30003@oracle.com> <55257F76.2010804@oracle.com> Message-ID: <5525B0BA.3040109@oracle.com> Looks fine to me, too. Thanks, Xuelei On 4/9/2015 3:20 AM, Jason Uh wrote: > Hi Alexander, > > I'm not an official Reviewer, but this change looks good to me. > > Thanks, > Jason > > On 4/8/15 4:37 AM, alexander stepanov wrote: >> Hello, >> >> could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8076223/webrev.00/ >> for >> https://bugs.openjdk.java.net/browse/JDK-8076223 >> >> Just some minor HTML markup fixes for documentation. >> >> Thanks, >> Alexander > From jamil.j.nimeh at oracle.com Thu Apr 9 05:20:20 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 08 Apr 2015 22:20:20 -0700 Subject: Jjeps 8046321 In-Reply-To: <5522EC2F.8030900@smcc.net> References: <5522EC2F.8030900@smcc.net> Message-ID: <55260C14.3070905@oracle.com> Hi Thomas, thanks for your interest in this JEP. As it turns out, I'm working on JDK-8046321 which is the OCSP stapling JEP. I'm targeting mid-to-late May for the completion of client and server-side support. I would love to have your input during the code review process, especially since it sounds like you have done some work in this area and are familiar with the challenges associated with supporting these extension(s). I cannot discuss any details of your implementation down at the code level, but I'm curious - did you implement the status_request extension from RFC 6066 only, or did you also do the status_request_v2 extension in RFC 6961? Sincerely, --Jamil On 04/06/2015 01:27 PM, Thomas Lu?nig wrote: > Hi, > > is there anyone working on OCSP-Stapling ? > I patched my java version to get it running for server side. > Maybe i can help with some parts of the implementation. > > Gru? Thomas From zaiyao.liu at oracle.com Thu Apr 9 06:14:55 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Thu, 09 Apr 2015 14:14:55 +0800 Subject: RFR 8048820: Implement tests for SecretKeyFactory Message-ID: <552618DF.7040502@oracle.com> Hi All, Please review a couple of new tests for SecretKeyFactory.translateKey(). https://bugs.openjdk.java.net/browse/JDK-8048820 http://cr.openjdk.java.net/~zailiu/8048820/webrev.00/ Thanks Kevin From mark.reinhold at oracle.com Thu Apr 9 22:36:35 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 9 Apr 2015 15:36:35 -0700 (PDT) Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension Message-ID: <20150409223635.74AFC555B2@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/244 - Mark From zaiyao.liu at oracle.com Fri Apr 10 01:41:17 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Fri, 10 Apr 2015 09:41:17 +0800 Subject: RFR 8048599: Tests for key wrap and unwrap operations Message-ID: <55272A3D.4060308@oracle.com> Hi All, Please help to review the new test for wrap and unwrap operations with crypto keys. Webrev : http://cr.openjdk.java.net/~zailiu/8048599/webrev.00/ JDK bug: https://bugs.openjdk.java.net/browse/JDK-8048599 Thanks Kevin From Alan.Bateman at oracle.com Fri Apr 10 16:01:25 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Apr 2015 17:01:25 +0100 Subject: RFR [9] 8077332: tidy warnings from javax/xml In-Reply-To: <5527F132.80408@oracle.com> References: <5527F132.80408@oracle.com> Message-ID: <5527F3D5.7070309@oracle.com> On 10/04/2015 16:50, alexander stepanov wrote: > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8077332/ > > for > https://bugs.openjdk.java.net/browse/JDK-8077332 > > Some HTML cleanup for docs. cc'ing security-dev as that is where the XML-DSIG code is maintained. I've also cc'ed Miroslav Kos as I think you'll need to work with him to get the JAX-WS and JAXB updated in the upstream repos. This is mostly just about ensuring that the changes in the jaxws repo don't get overridden at the next JAX-WS sync up. -Alan From sean.mullan at oracle.com Fri Apr 10 17:07:47 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 10 Apr 2015 13:07:47 -0400 Subject: RFR [9] 8077332: tidy warnings from javax/xml In-Reply-To: <5527F3D5.7070309@oracle.com> References: <5527F132.80408@oracle.com> <5527F3D5.7070309@oracle.com> Message-ID: <55280363.1070101@oracle.com> On 04/10/2015 12:01 PM, Alan Bateman wrote: > On 10/04/2015 16:50, alexander stepanov wrote: >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8077332/ >> >> for >> https://bugs.openjdk.java.net/browse/JDK-8077332 >> >> Some HTML cleanup for docs. > cc'ing security-dev as that is where the XML-DSIG code is maintained. The DSig changes look fine. --Sean From jason.uh at oracle.com Fri Apr 10 19:39:37 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 10 Apr 2015 12:39:37 -0700 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation Message-ID: <552826F9.7000402@oracle.com> Please review this fix, which prevents redundant extension checking in EndEntityChecker. When checking extensions in an end entity certificate, if sun.security.validator.EndEntityChecker comes across any extensions that are critical and unknown, it throws an exception, even if those extensions had already been checked by custom PKIXCertPathCheckers (specified in the PKIXParameters) earlier in the validation by PKIXValidator. This checking is not necessary when path validation is performed by a PKIXValidator. However, if the validation is performed by a SimpleValidator, EndEntityChecker should continue to check extensions. webrev: http://cr.openjdk.java.net/~juh/8076117/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8076117 Thanks, Jason From xuelei.fan at oracle.com Fri Apr 10 22:41:54 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 11 Apr 2015 06:41:54 +0800 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation In-Reply-To: <552826F9.7000402@oracle.com> References: <552826F9.7000402@oracle.com> Message-ID: <552851B2.1040102@oracle.com> Looks fine to me except a few minor comments. Validator.java -------------- Would you mind add a comment about why only check extension for TYPE_SIMPLE? EndEntityExtensionCheck.java ---------------------------- line 26-28: We normally use bug tag before other tags. line 52-55, and similar places: Normally, a "*" character is expected for each comment line. As is easier to read. eeextensioncheck.jks -------------------- Binary file is not preferred in Mercurial. Would you mind use string key store as what you did for CA and EE certs in EndEntityExtensionCheck.java? Xuelei On 4/11/2015 3:39 AM, Jason Uh wrote: > Please review this fix, which prevents redundant extension checking in > EndEntityChecker. > > When checking extensions in an end entity certificate, if > sun.security.validator.EndEntityChecker comes across any extensions that > are critical and unknown, it throws an exception, even if those > extensions had already been checked by custom PKIXCertPathCheckers > (specified in the PKIXParameters) earlier in the validation by > PKIXValidator. This checking is not necessary when path validation is > performed by a PKIXValidator. > > However, if the validation is performed by a SimpleValidator, > EndEntityChecker should continue to check extensions. > > webrev: http://cr.openjdk.java.net/~juh/8076117/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8076117 > > Thanks, > Jason From jason.uh at oracle.com Fri Apr 10 23:18:48 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 10 Apr 2015 16:18:48 -0700 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation In-Reply-To: <552851B2.1040102@oracle.com> References: <552826F9.7000402@oracle.com> <552851B2.1040102@oracle.com> Message-ID: <55285A58.9090601@oracle.com> Thanks, Xuelei. On 04/10/2015 03:41 PM, Xuelei Fan wrote: > Looks fine to me except a few minor comments. > > Validator.java > -------------- > Would you mind add a comment about why only check extension for TYPE_SIMPLE? Added. > EndEntityExtensionCheck.java > ---------------------------- > line 26-28: > We normally use bug tag before other tags. Moved @bug before @summary. @test still needs to be first for jtreg. > line 52-55, and similar places: > Normally, a "*" character is expected for each comment line. As is > easier to read. > > eeextensioncheck.jks > -------------------- > Binary file is not preferred in Mercurial. Would you mind use string > key store as what you did for CA and EE certs in > EndEntityExtensionCheck.java? Just changed it to setCertificateEntry from the already constructed CA cert, which is definitely better than using the binary. I'm not aware of a way to export an entire keystore as an encoded string. (Is there a way?) Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/ Thanks, Jason > Xuelei > > On 4/11/2015 3:39 AM, Jason Uh wrote: >> Please review this fix, which prevents redundant extension checking in >> EndEntityChecker. >> >> When checking extensions in an end entity certificate, if >> sun.security.validator.EndEntityChecker comes across any extensions that >> are critical and unknown, it throws an exception, even if those >> extensions had already been checked by custom PKIXCertPathCheckers >> (specified in the PKIXParameters) earlier in the validation by >> PKIXValidator. This checking is not necessary when path validation is >> performed by a PKIXValidator. >> >> However, if the validation is performed by a SimpleValidator, >> EndEntityChecker should continue to check extensions. >> >> webrev: http://cr.openjdk.java.net/~juh/8076117/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8076117 >> >> Thanks, >> Jason > From xuelei.fan at oracle.com Fri Apr 10 23:34:24 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 11 Apr 2015 07:34:24 +0800 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation In-Reply-To: <55285A58.9090601@oracle.com> References: <552826F9.7000402@oracle.com> <552851B2.1040102@oracle.com> <55285A58.9090601@oracle.com> Message-ID: <55285E00.80102@oracle.com> Looks fine to me. > I'm not aware of a way to export an entire keystore as an > encoded string. (Is there a way?) > A keystore can be defined as BASE64 code string, and then load keystore from a stream. More generally, declare the private key and cert string, and then add them to a KeyStore instance. Xuelei On 4/11/2015 7:18 AM, Jason Uh wrote: > Thanks, Xuelei. > > On 04/10/2015 03:41 PM, Xuelei Fan wrote: >> Looks fine to me except a few minor comments. >> >> Validator.java >> -------------- >> Would you mind add a comment about why only check extension for >> TYPE_SIMPLE? > > Added. > >> EndEntityExtensionCheck.java >> ---------------------------- >> line 26-28: >> We normally use bug tag before other tags. > > Moved @bug before @summary. @test still needs to be first for jtreg. > >> line 52-55, and similar places: >> Normally, a "*" character is expected for each comment line. As is >> easier to read. >> >> eeextensioncheck.jks >> -------------------- >> Binary file is not preferred in Mercurial. Would you mind use string >> key store as what you did for CA and EE certs in >> EndEntityExtensionCheck.java? > > Just changed it to setCertificateEntry from the already constructed CA > cert, which is definitely better than using the binary. I'm not aware of > a way to export an entire keystore as an encoded string. (Is there a way?) > > Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/ > > Thanks, > Jason > >> Xuelei >> >> On 4/11/2015 3:39 AM, Jason Uh wrote: >>> Please review this fix, which prevents redundant extension checking in >>> EndEntityChecker. >>> >>> When checking extensions in an end entity certificate, if >>> sun.security.validator.EndEntityChecker comes across any extensions that >>> are critical and unknown, it throws an exception, even if those >>> extensions had already been checked by custom PKIXCertPathCheckers >>> (specified in the PKIXParameters) earlier in the validation by >>> PKIXValidator. This checking is not necessary when path validation is >>> performed by a PKIXValidator. >>> >>> However, if the validation is performed by a SimpleValidator, >>> EndEntityChecker should continue to check extensions. >>> >>> webrev: http://cr.openjdk.java.net/~juh/8076117/00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8076117 >>> >>> Thanks, >>> Jason >> From alexander.v.stepanov at oracle.com Mon Apr 13 10:40:18 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Mon, 13 Apr 2015 13:40:18 +0300 Subject: RFR [9] 8077332: tidy warnings from javax/xml In-Reply-To: <5527F3D5.7070309@oracle.com> References: <5527F132.80408@oracle.com> <5527F3D5.7070309@oracle.com> Message-ID: <552B9D12.6090508@oracle.com> Hello Alan, Thank you. Regards, Alexander On 10.04.2015 19:01, Alan Bateman wrote: > On 10/04/2015 16:50, alexander stepanov wrote: >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8077332/ >> >> for >> https://bugs.openjdk.java.net/browse/JDK-8077332 >> >> Some HTML cleanup for docs. > cc'ing security-dev as that is where the XML-DSIG code is maintained. > > I've also cc'ed Miroslav Kos as I think you'll need to work with him > to get the JAX-WS and JAXB updated in the upstream repos. This is > mostly just about ensuring that the changes in the jaxws repo don't > get overridden at the next JAX-WS sync up. > > -Alan From alexander.v.stepanov at oracle.com Mon Apr 13 10:44:58 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Mon, 13 Apr 2015 13:44:58 +0300 Subject: RFR [9] 8077332: tidy warnings from javax/xml In-Reply-To: <55280363.1070101@oracle.com> References: <5527F132.80408@oracle.com> <5527F3D5.7070309@oracle.com> <55280363.1070101@oracle.com> Message-ID: <552B9E2A.6010100@oracle.com> Thanks! On 10.04.2015 20:07, Sean Mullan wrote: > On 04/10/2015 12:01 PM, Alan Bateman wrote: >> On 10/04/2015 16:50, alexander stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8077332/ >>> >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8077332 >>> >>> Some HTML cleanup for docs. >> cc'ing security-dev as that is where the XML-DSIG code is maintained. > > The DSig changes look fine. > > --Sean From openjdk at suche.org Mon Apr 13 14:57:52 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Mon, 13 Apr 2015 16:57:52 +0200 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation In-Reply-To: <552826F9.7000402@oracle.com> References: <552826F9.7000402@oracle.com> Message-ID: <552BD970.9080002@suche.org> Hi, even if i am new in this list i looked at the solution and have an question. Why there is an switch to turn off check for unknown critical extensions ? >From my point of view as an developer i would say an more secure solution would be instead of an boolean switch, make an Set checkedOids as new parameter, so it is possible to tell what is already been checked. That mean if the "non SimpleValidator" checks only part of the critical extensions the EndEntityChecker would still throw an Exception. Gru? Thomas On 10.04.2015 21:39, Jason Uh wrote: > Please review this fix, which prevents redundant extension checking in > EndEntityChecker. > > When checking extensions in an end entity certificate, if > sun.security.validator.EndEntityChecker comes across any extensions > that are critical and unknown, it throws an exception, even if those > extensions had already been checked by custom PKIXCertPathCheckers > (specified in the PKIXParameters) earlier in the validation by > PKIXValidator. This checking is not necessary when path validation is > performed by a PKIXValidator. > > However, if the validation is performed by a SimpleValidator, > EndEntityChecker should continue to check extensions. > > webrev: http://cr.openjdk.java.net/~juh/8076117/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8076117 > > Thanks, > Jason From openjdk at suche.org Mon Apr 13 14:58:53 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Mon, 13 Apr 2015 16:58:53 +0200 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <20150409223635.74AFC555B2@eggemoggin.niobe.net> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> Message-ID: <552BD9AD.7070000@suche.org> On 10.04.2015 00:36, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/244 > > - Mark Hi, would it not be an great idea to combine all these new extensions to an generic way how to handle the SSL Protocol Handshake ? JEPS-244 ALPN http://openjdk.java.net/jeps/8046321 := OCSP-Stapling http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 public interface HelloHandler { /** Allow to add extesions to Server/Client Hello based on the Client/Server hello */ public void handleHelloMessage(ClientHello clientHello, ServerHello serverHello); /** Allow to add new Handshake Messages based on the Client/Server Hello */ public void sendHandshakeMessage(HandshakeOutStream handshakeOutStream, ClientHello clientHello, ServerHello serverHello); /** define an order of the extensions */ Class runBefore(); Class runAfter(); } With such an extension options it would be much more simple do implement new Extensions. Gru? Thomas Lu?nig From david.lloyd at redhat.com Mon Apr 13 16:22:02 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Apr 2015 11:22:02 -0500 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <552BD9AD.7070000@suche.org> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> Message-ID: <552BED2A.70903@redhat.com> On 04/13/2015 09:58 AM, Thomas Lu?nig wrote: > On 10.04.2015 00:36, mark.reinhold at oracle.com wrote: >> New JEP Candidate: http://openjdk.java.net/jeps/244 >> >> - Mark > > Hi, > > would it not be an great idea to combine all these new extensions to an > generic way how to handle the SSL Protocol Handshake ? Do you know of a Java TLS implementation that has APIs like this already? I am also interested in this for the ability to implement authentication mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like to see such an API materialize as well. -- - DML From simone.bordet at gmail.com Mon Apr 13 16:44:12 2015 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 13 Apr 2015 18:44:12 +0200 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <552BED2A.70903@redhat.com> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> Message-ID: Hi, On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd wrote: > Do you know of a Java TLS implementation that has APIs like this already? I > am also interested in this for the ability to implement authentication > mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like > to see such an API materialize as well. I posted a while back such APIs from 3rd party JSSE implementations: http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html (at the end). The problem that has been raised is that if you offer a generic TLS extensions API, then the extension may have a semantic that it's not implemented. Imagine this TLS extensions API already existed, to add extensions to SSLEngine. Now, ALPN comes along as a new TLS extension. An application could create their own ALPNExtension subclass (extending a standard one provided by the TLS extensions API), and add it to the ClientHello. But there is no code in the JDK that calls the application, asking (on the server) to select one of the protocols, for then send back the chosen protocol to the client. This could be solved by a callback API at the moment the ClientHello is received by the server (and the ServerHello by the client), so the application can examine the ALPN protocols. The NPN extension was doing something even more complicated, creating an additional TLS message that needed to be sent at the right time. It may be that a TLS extensions API (to add/remove/query TLS extensions) *and* a callback API to analyze "hello" messages when they are received is enough to cover a lot of cases, perhaps even all currently existing ones. I asked for feedback some time ago about the status of the ALPN implementation; would be great if the security team could update the current status. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From openjdk at suche.org Mon Apr 13 17:14:06 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Mon, 13 Apr 2015 19:14:06 +0200 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> Message-ID: <552BF95E.6090604@suche.org> Hi, this could be an interface for such an Callback. It allow hello extensions as well as handshake extensions. If it would be really clean we would have an handler for: - NPN - ALPN - Channel ID - ZertificateSignature - OCSP-Stapling - ServerName - Session Ticket The handler could be also used for handling: - TLS_FALLBACK_SCSV The current way is that all these extensions are in the sun Private package space and to make it even worse each extension is written in another way. Also i am missing an API defined way to extend the list in sun.security.ssl.CipherSuite. Gru? Thomas public interface HelloHandler { /** * Allow to add extesions to Server/Client Hello * based on the Client/Server hello */ public void handleHelloMessage(ClientHello clientHello, ServerHello serverHello); /** Allow to add new Handshake Messages based on * the Client/Server Hello */ public void sendHandshakeMessage(HandshakeOutStream handshakeOutStream, ClientHello clientHello, ServerHello serverHello); /** * define an order of the extensions */ Class runBefore(); /** * define an order of the extensions */ Class runAfter(); } > Hi, > > On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd wrote: >> Do you know of a Java TLS implementation that has APIs like this already? I >> am also interested in this for the ability to implement authentication >> mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like >> to see such an API materialize as well. > I posted a while back such APIs from 3rd party JSSE implementations: > http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html > (at the end). > > The problem that has been raised is that if you offer a generic TLS > extensions API, then the extension may have a semantic that it's not > implemented. > > Imagine this TLS extensions API already existed, to add extensions to SSLEngine. > Now, ALPN comes along as a new TLS extension. An application could > create their own ALPNExtension subclass (extending a standard one > provided by the TLS extensions API), and add it to the ClientHello. > But there is no code in the JDK that calls the application, asking (on > the server) to select one of the protocols, for then send back the > chosen protocol to the client. > This could be solved by a callback API at the moment the ClientHello > is received by the server (and the ServerHello by the client), so the > application can examine the ALPN protocols. > > The NPN extension was doing something even more complicated, creating > an additional TLS message that needed to be sent at the right time. > > It may be that a TLS extensions API (to add/remove/query TLS > extensions) *and* a callback API to analyze "hello" messages when they > are received is enough to cover a lot of cases, perhaps even all > currently existing ones. > > I asked for feedback some time ago about the status of the ALPN > implementation; would be great if the security team could update the > current status. > From openjdk at suche.org Mon Apr 13 18:25:40 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Mon, 13 Apr 2015 20:25:40 +0200 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <552BED2A.70903@redhat.com> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> Message-ID: <552C0A24.6000408@suche.org> Hi, i checked the CipherSuites in JDK and found that in the JDK there is and mistake i think. In CipherSuite the method add set the PRF to NONE only if obsoleted less than TLSv1.2. But if the suite is forbidden / obsoleted in TLSv1.2 the check must be <= (less or equal) if i am correct. http://grepcode.com/file_/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/ssl/CipherSuite.java/?v=source /* * Use this method when there is no lower protocol limit where this * suite can be used, and the PRF is P_SHA256. That is, the * existing ciphersuites. From RFC 5246: * * All cipher suites in this document use P_SHA256. */ private static void add(String name, int id, int priority, KeyExchange keyExchange, BulkCipher cipher, boolean allowed, int obsoleted) { // If this is an obsoleted suite, then don't let the TLS 1.2 // protocol have a valid PRF value. PRF prf = P_SHA256; if (obsoleted < ProtocolVersion.TLS12.v) { prf = P_NONE; } add(name, id, priority, keyExchange, cipher, allowed, obsoleted, ProtocolVersion.LIMIT_MIN_VALUE, prf); } Gru? Thomas From john.r.rose at oracle.com Mon Apr 13 19:50:33 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 13 Apr 2015 12:50:33 -0700 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <552BADCF.80109@oracle.com> References: <552BADCF.80109@oracle.com> Message-ID: <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> On Apr 13, 2015, at 4:51 AM, Zolt?n Maj? wrote: > > please review the following patch. Good. This line has a typo ("encrypBlock" = gang member induction party foul?): + * AESCrypt.encrypBlock method can be intrinsified on the HotSpot VM ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Apr 13 19:59:18 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Apr 2015 15:59:18 -0400 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation In-Reply-To: <55285A58.9090601@oracle.com> References: <552826F9.7000402@oracle.com> <552851B2.1040102@oracle.com> <55285A58.9090601@oracle.com> Message-ID: <552C2016.6050201@oracle.com> On 04/10/2015 07:18 PM, Jason Uh wrote: > Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/ Hi Jason, Just a few comments: * Validator 272: I would name this flag checkUnresolvedCritExts, since we only care about them if they are critical and unresolved. 273: You should only ignore the extensions if the type is PKIX, so line 273 should be "(type == TYPE_PKIX) ? false : true;" This way if we ever add another type in the JDK implementation, we won't accidentally ignore extensions when we shouldn't have. * EndEntityChecker 127: don't make this a field of the class, as this can cause concurrency issues if EndEntityChecker is shared by threads and used with different certificates. Just create and pass in the extensions, ex line 163: checkRemainingExtensions(getCriticalExtensions(cert)); and change the other check methods to have a 2nd parameter for the extensions, ex: checkTLSClient(X509Certificate cert, Set exts) * EndEntityExtensionCheck Set the validity date using PKIXParameters.setDate to a time within the certificate's validity so the test won't start failing when the certificates expire. See other chain validation tests for examples. --Sean From anthony.scarpino at oracle.com Mon Apr 13 20:09:10 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 13 Apr 2015 13:09:10 -0700 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> Message-ID: Hi, Could you forward the whole message, with the patch, to the security list. I have only received John's response, but not the webrev. Thanks Tony > On Apr 13, 2015, at 12:50 PM, John Rose wrote: > >> On Apr 13, 2015, at 4:51 AM, Zolt?n Maj? wrote: >> >> please review the following patch. > > Good. This line has a typo ("encrypBlock" = gang member induction party foul?): > + * AESCrypt.encrypBlock method can be intrinsified on the HotSpot VM > > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Mon Apr 13 20:55:06 2015 From: zoltan.majo at oracle.com (=?utf-8?Q?Zolt=C3=A1n_Maj=C3=B3?=) Date: Mon, 13 Apr 2015 22:55:06 +0200 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> Message-ID: <28A5E5B5-4B00-45B8-96D9-1D28B0522319@oracle.com> Hi Tony, > On 13 Apr 2015, at 22:09, Anthony Scarpino wrote: > > Hi, > > Could you forward the whole message, with the patch, to the security list. I have only received John's response, but not the webrev. please find the original RFR below. I?ve sent it to security-dev at openjdk.java.net at the same time as I did send it to hotspot-compiler-dev at openjdk.java.net. But as security-dev seems to be moderated for non-members, the original message is most likely awaiting moderator approval. Thank you and best regards, Zoltan ================ Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8067648 Problem: On architectures with hardware support for AES operations, the Java version (the version in the JDK sources) of the com.sun.crypto.provides.AESCrypt::encryptBlock(byte[], int, byte[], int) method is replaced with an intrinsic that uses the CPU's AES instructions. The Java version of encryptBlock operates on arrays of size AES_BLOCK_SIZE=16 and it consequently performs a number of "implicit" checks (e.g., null checks and range checks) as required by the Java VM specification. The intrinsified version of encryptBlock, however, does not perform any of these checks. Omitting checks results in a VM crash if invalid parameters (e.g., a null pointer, as reported in the current case) are passed to the method. Solution: The failure reported in the current issue appears in the com.sun.crypto.provider.GCTR class that calls the intrinsified version of encryptBlock. None of the methods of the class are accessible from packages other than com.sun.crypto.provider. So, after private a discussion with John Rose, Vladimir Kozlov, and Roland Westrelin, I propose to solve this problem on the Java-level. The GCTR::counter field is supposed to be initialized with an array of size AES_BLOCK_SIZE so that it is safe to call encryptBlock. The 'counter' field is never supposed to become NULL during the lifetime of a GCTR object (so that encryptBlock can be always called safely). The GCTR class supports saving and restoring the value of the 'counter' field (via the save() and restore() methods). For saving/restoring, the class uses the 'counterSave' field as temporary storage. It is also possible to reset the a GCTR object to its initial state by calling reset(). Reset sets both the 'counter' and 'counterSave' fields to their initial values. If a call to the method reset() is followed by a call to restore(), the field 'counter' is not restored to its original value, but it becomes NULL. This is an invalid state, because a GCTR object should always contain a valid 'counter' array. This problem has been also described (in part) by Chris Ellis. https://intrbiz.com/post/blog/development/java_8_aes_gcm_nullpointerexception This patch proposes to restore the contents of 'counter' from 'counterSave' only if some data has been saved into 'counterSave' before (i.e., counterSave is not NULL). The patch also adds a check to the constructor of GCTR to verify if the length of 'counter' is AES_BLOCK_SIZE. (I checked and JDK code uses this class only with arrays of size AES_BLOCK_SIZE, but it is good if the required size is documented and enforced by GCTR.) The array to store the output of the encryptBlock method (the third parameter) should be also of length AES_BLOCK_SIZE. That is ensured by the GCTR class (both in the doFinal and update methods). The input and output offsets (the second and fourth parameters) are 0, as required by encryptBlock. Webrev: http://cr.openjdk.java.net/~zmajo/8067648/webrev.00/ Testing: - JPRT (both with 9 and 8u), all tests in the testsets hotspot pass; - JTREG tests in jdk_security[1-4] executed locally with the sources built with --enable-openjdk-only; all tests that pass without the patch pass with the patch as well; - failure reported in 8067648 can be reproduced with 8u, failure is not triggered with patch applied. Thank you and best regards, Zoltan > Thanks > > Tony > > > > On Apr 13, 2015, at 12:50 PM, John Rose wrote: > >> On Apr 13, 2015, at 4:51 AM, Zolt?n Maj? wrote: >>> >>> please review the following patch. >> >> Good. This line has a typo ("encrypBlock" = gang member induction party foul?): >> + * AESCrypt.encrypBlock method can be intrinsified on the HotSpot VM >> >> ? John From lussnig at suche.org Sat Apr 11 20:43:36 2015 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Sat, 11 Apr 2015 22:43:36 +0200 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation In-Reply-To: <552826F9.7000402@oracle.com> References: <552826F9.7000402@oracle.com> Message-ID: <55298778.90001@suche.org> Hi, even if i am new in this list i looked at the solution and have an question. Why there is an switch to turn off check for unknown critical extensions ? >From my point of view as an developer i would say an more secure solution would be instead of an boolean switch, make an Set checkedOids as new parameter, so it is possible to tell what is already been checked. That mean if the "non SimpleValidator" checks only part of the critical extensions the EndEntityChecker would still throw an Exception. Gru? Thomas On 10.04.2015 21:39, Jason Uh wrote: > Please review this fix, which prevents redundant extension checking in > EndEntityChecker. > > When checking extensions in an end entity certificate, if > sun.security.validator.EndEntityChecker comes across any extensions > that are critical and unknown, it throws an exception, even if those > extensions had already been checked by custom PKIXCertPathCheckers > (specified in the PKIXParameters) earlier in the validation by > PKIXValidator. This checking is not necessary when path validation is > performed by a PKIXValidator. > > However, if the validation is performed by a SimpleValidator, > EndEntityChecker should continue to check extensions. > > webrev: http://cr.openjdk.java.net/~juh/8076117/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8076117 > > Thanks, > Jason From lussnig at suche.org Sun Apr 12 14:50:44 2015 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Sun, 12 Apr 2015 16:50:44 +0200 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <20150409223635.74AFC555B2@eggemoggin.niobe.net> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> Message-ID: <552A8644.8000609@suche.org> On 10.04.2015 00:36, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/244 > > - Mark Hi, would it not be an great idea to combine all these new extensions to an generic way how to handle the SSL Protocol Handshake ? JEPS-244 ALPN http://openjdk.java.net/jeps/8046321 := OCSP-Stapling http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 public interface HelloHandler { /** Allow to add extesions to Server/Client Hello based on the Client/Server hello */ public void handleHelloMessage(ClientHello clientHello, ServerHello serverHello); /** Allow to add new Handshake Messages based on the Client/Server Hello */ public void sendHandshakeMessage(HandshakeOutStream handshakeOutStream, ClientHello clientHello, ServerHello serverHello); /** define an order of the extensions */ Class runBefore(); Class runAfter(); } With such an extension options it would be much more simple do implement new Extensions. Gru? Thomas Lu?nig From zoltan.majo at oracle.com Mon Apr 13 11:51:43 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 13 Apr 2015 13:51:43 +0200 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal Message-ID: <552BADCF.80109@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8067648 Problem: On architectures with hardware support for AES operations, the Java version (the version in the JDK sources) of the com.sun.crypto.provides.AESCrypt::encryptBlock(byte[], int, byte[], int) method is replaced with an intrinsic that uses the CPU's AES instructions. The Java version of encryptBlock operates on arrays of size AES_BLOCK_SIZE=16 and it consequently performs a number of "implicit" checks (e.g., null checks and range checks) as required by the Java VM specification. The intrinsified version of encryptBlock, however, does not perform any of these checks. Omitting checks results in a VM crash if invalid parameters (e.g., a null pointer, as reported in the current case) are passed to the method. Solution: The failure reported in the current issue appears in the com.sun.crypto.provider.GCTR class that calls the intrinsified version of encryptBlock. None of the methods of the class are accessible from packages other than com.sun.crypto.provider. So, after private a discussion with John Rose, Vladimir Kozlov, and Roland Westrelin, I propose to solve this problem on the Java-level. The GCTR::counter field is supposed to be initialized with an array of size AES_BLOCK_SIZE so that it is safe to call encryptBlock. The 'counter' field is never supposed to become NULL during the lifetime of a GCTR object (so that encryptBlock can be always called safely). The GCTR class supports saving and restoring the value of the 'counter' field (via the save() and restore() methods). For saving/restoring, the class uses the 'counterSave' field as temporary storage. It is also possible to reset the a GCTR object to its initial state by calling reset(). Reset sets both the 'counter' and 'counterSave' fields to their initial values. If a call to the method reset() is followed by a call to restore(), the field 'counter' is not restored to its original value, but it becomes NULL. This is an invalid state, because a GCTR object should always contain a valid 'counter' array. This problem has been also described (in part) by Chris Ellis. https://intrbiz.com/post/blog/development/java_8_aes_gcm_nullpointerexception This patch proposes to restore the contents of 'counter' from 'counterSave' only if some data has been saved into 'counterSave' before (i.e., counterSave is not NULL). The patch also adds a check to the constructor of GCTR to verify if the length of 'counter' is AES_BLOCK_SIZE. (I checked and JDK code uses this class only with arrays of size AES_BLOCK_SIZE, but it is good if the required size is documented and enforced by GCTR.) The array to store the output of the encryptBlock method (the third parameter) should be also of length AES_BLOCK_SIZE. That is ensured by the GCTR class (both in the doFinal and update methods). The input and output offsets (the second and fourth parameters) are 0, as required by encryptBlock. Webrev: http://cr.openjdk.java.net/~zmajo/8067648/webrev.00/ Testing: - JPRT (both with 9 and 8u), all tests in the testsets hotspot pass; - JTREG tests in jdk_security[1-4] executed locally with the sources built with --enable-openjdk-only; all tests that pass without the patch pass with the patch as well; - failure reported in 8067648 can be reproduced with 8u, failure is not triggered with patch applied. Thank you and best regards, Zoltan From jason.uh at oracle.com Mon Apr 13 23:40:40 2015 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 13 Apr 2015 16:40:40 -0700 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation In-Reply-To: <552C2016.6050201@oracle.com> References: <552826F9.7000402@oracle.com> <552851B2.1040102@oracle.com> <55285A58.9090601@oracle.com> <552C2016.6050201@oracle.com> Message-ID: <552C53F8.5050502@oracle.com> Thanks, Sean. Here is a revision: http://cr.openjdk.java.net/~juh/8076117/02/ On 04/13/2015 12:59 PM, Sean Mullan wrote: > On 04/10/2015 07:18 PM, Jason Uh wrote: >> Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/ > > Hi Jason, > > Just a few comments: > > * Validator > > 272: I would name this flag checkUnresolvedCritExts, since we only care > about them if they are critical and unresolved. > > 273: You should only ignore the extensions if the type is PKIX, so line > 273 should be "(type == TYPE_PKIX) ? false : true;" This way if we ever > add another type in the JDK implementation, we won't accidentally ignore > extensions when we shouldn't have. > > * EndEntityChecker > > 127: don't make this a field of the class, as this can cause concurrency > issues if EndEntityChecker is shared by threads and used with different > certificates. Just create and pass in the extensions, ex line 163: > > checkRemainingExtensions(getCriticalExtensions(cert)); > > and change the other check methods to have a 2nd parameter for the > extensions, ex: > > checkTLSClient(X509Certificate cert, Set exts) > > * EndEntityExtensionCheck > > Set the validity date using PKIXParameters.setDate to a time within the > certificate's validity so the test won't start failing when the > certificates expire. See other chain validation tests for examples. > > --Sean > > From xuelei.fan at oracle.com Mon Apr 13 23:51:38 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 14 Apr 2015 07:51:38 +0800 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <552C0A24.6000408@suche.org> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> <552C0A24.6000408@suche.org> Message-ID: <552C568A.1030405@oracle.com> On 4/14/2015 2:25 AM, Thomas Lu?nig wrote: > Hi, > > i checked the CipherSuites in JDK and found that in the JDK there is and > mistake i think. > In CipherSuite the method add set the PRF to NONE only if obsoleted less > than TLSv1.2. > But if the suite is forbidden / obsoleted in TLSv1.2 the check must be > <= (less or equal) Can you explain more about this point? Xuelei > if i am correct. > > http://grepcode.com/file_/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/ssl/CipherSuite.java/?v=source > > /* > * Use this method when there is no lower protocol limit where this > * suite can be used, and the PRF is P_SHA256. That is, the > * existing ciphersuites. From RFC 5246: > * > * All cipher suites in this document use P_SHA256. > */ > private static void add(String name, int id, int priority, > KeyExchange keyExchange, BulkCipher cipher, > boolean allowed, int obsoleted) { > // If this is an obsoleted suite, then don't let the TLS 1.2 > // protocol have a valid PRF value. > PRF prf = P_SHA256; > if (obsoleted < ProtocolVersion.TLS12.v) { > prf = P_NONE; > } > > add(name, id, priority, keyExchange, cipher, allowed, obsoleted, > ProtocolVersion.LIMIT_MIN_VALUE, prf); > } > > Gru? Thomas > From jason.uh at oracle.com Mon Apr 13 23:52:46 2015 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 13 Apr 2015 16:52:46 -0700 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation In-Reply-To: <55298778.90001@suche.org> References: <552826F9.7000402@oracle.com> <55298778.90001@suche.org> Message-ID: <552C56CE.80200@oracle.com> Hi Thomas, I am not actually turning off the check for unknown critical extensions. When validating with TYPE_PKIX, CertPathValidator will already have verified all extensions (and an exception would already have been thrown for any violations). This fix is merely to take out what would be a redundant check in EndEntityChecker that would result in wrong behavior. With that said, as Sean pointed out in his review, it would make more sense to disable the checks when validating with a TYPE_PKIX validator rather than enabling for TYPE_SIMPLE, so I've made that change in my latest revision. I've sent that out in a separate email. Also, all of the APIs I've touched in this fix are internal APIs and are not to be used externally, so there is not a security concern in the way you've suggested. Thanks, and I appreciate the feedback. Jason On 04/11/2015 01:43 PM, Thomas Lu?nig wrote: > Hi, > > even if i am new in this list i looked at the solution and have an question. > Why there is an switch to turn off check for unknown critical extensions ? > From my point of view as an developer i would say an more secure solution > would be instead of an boolean switch, make an Set checkedOids as > new parameter, so it is possible to tell what is already been checked. > That mean if the "non SimpleValidator" checks only part of the critical > extensions > the EndEntityChecker would still throw an Exception. > > Gru? Thomas > > On 10.04.2015 21:39, Jason Uh wrote: >> Please review this fix, which prevents redundant extension checking in >> EndEntityChecker. >> >> When checking extensions in an end entity certificate, if >> sun.security.validator.EndEntityChecker comes across any extensions >> that are critical and unknown, it throws an exception, even if those >> extensions had already been checked by custom PKIXCertPathCheckers >> (specified in the PKIXParameters) earlier in the validation by >> PKIXValidator. This checking is not necessary when path validation is >> performed by a PKIXValidator. >> >> However, if the validation is performed by a SimpleValidator, >> EndEntityChecker should continue to check extensions. >> >> webrev: http://cr.openjdk.java.net/~juh/8076117/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8076117 >> >> Thanks, >> Jason > From xuelei.fan at oracle.com Tue Apr 14 03:02:46 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 14 Apr 2015 11:02:46 +0800 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <552BF95E.6090604@suche.org> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> <552BF95E.6090604@suche.org> Message-ID: <552C8356.2020804@oracle.com> Thanks for the proposal. A general TLS/DTLS extension API and pluginable extension implementation is a good idea. But as there is no rules about how an extension may impact the handshake flow, it is not easy to define a general APIs for all existing known or unknown extensions and future extensions. For example, an extension may impact the cipher suite selection, may need to define new handshake messages, may need new algorithm implementation, may impact the algorithm used to sign handshake messages, may impact the algorithm used to protected application data, etc. An extension may impact every details of handshaking, not only the client hello and server hello messages. It would be great if there are general APIs that are simple and cover the possible impact in every details of handshaking. I'm open for more advices. Maybe we can have APIs to define the extension parameters, rather than the handshake implementation. But as we already have SSLParameters, I don't think we need extra APIs for extension parameters any more. JSSE is open source and an provider based framework. Alternatively, we'd like to accept extension implementation contributions, or developer can define their own private provider if necessary. Regards, Xuelei On 4/14/2015 1:14 AM, Thomas Lu?nig wrote: > Hi, > > this could be an interface for such an Callback. > It allow hello extensions as well as handshake extensions. > If it would be really clean we would have an handler for: > - NPN > - ALPN > - Channel ID > - ZertificateSignature > - OCSP-Stapling > - ServerName > - Session Ticket > > The handler could be also used for handling: > - TLS_FALLBACK_SCSV > > The current way is that all these extensions are in the sun Private > package space > and to make it even worse each extension is written in another way. > Also i am missing an API defined way to extend the list in > sun.security.ssl.CipherSuite. > > Gru? Thomas > > public interface HelloHandler { > /** > * Allow to add extesions to Server/Client Hello > * based on the Client/Server hello */ > public void handleHelloMessage(ClientHello clientHello, ServerHello serverHello); > /** Allow to add new Handshake Messages based on > * the Client/Server Hello > */ > public void sendHandshakeMessage(HandshakeOutStream handshakeOutStream, ClientHello clientHello, ServerHello serverHello); > /** > * define an order of the extensions > */ > Class runBefore(); > /** > * define an order of the extensions > */ > Class runAfter(); > } > > > >> Hi, >> >> On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd wrote: >>> Do you know of a Java TLS implementation that has APIs like this already? I >>> am also interested in this for the ability to implement authentication >>> mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like >>> to see such an API materialize as well. >> I posted a while back such APIs from 3rd party JSSE implementations: >> http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html >> (at the end). >> >> The problem that has been raised is that if you offer a generic TLS >> extensions API, then the extension may have a semantic that it's not >> implemented. >> >> Imagine this TLS extensions API already existed, to add extensions to SSLEngine. >> Now, ALPN comes along as a new TLS extension. An application could >> create their own ALPNExtension subclass (extending a standard one >> provided by the TLS extensions API), and add it to the ClientHello. >> But there is no code in the JDK that calls the application, asking (on >> the server) to select one of the protocols, for then send back the >> chosen protocol to the client. >> This could be solved by a callback API at the moment the ClientHello >> is received by the server (and the ServerHello by the client), so the >> application can examine the ALPN protocols. >> >> The NPN extension was doing something even more complicated, creating >> an additional TLS message that needed to be sent at the right time. >> >> It may be that a TLS extensions API (to add/remove/query TLS >> extensions) *and* a callback API to analyze "hello" messages when they >> are received is enough to cover a lot of cases, perhaps even all >> currently existing ones. >> >> I asked for feedback some time ago about the status of the ALPN >> implementation; would be great if the security team could update the >> current status. >> > From artem.smotrakov at oracle.com Tue Apr 14 05:54:50 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 14 Apr 2015 08:54:50 +0300 Subject: [9] RFR: 8076221: Disable RC4 cipher suites Message-ID: <552CABAA.5010402@oracle.com> Hello, RFC 7465 [1] has been published to prohibit RC4. Please review this fix which disables RC4 cipher suites in JDK 9 by adding "RC4" to "jdk.tls.disabledAlgorithms" security property. Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076221 [1] https://tools.ietf.org/html/rfc7465 Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Tue Apr 14 07:44:30 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 14 Apr 2015 09:44:30 +0200 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> Message-ID: <552CC55E.4010702@oracle.com> Hi Johh, thank you for the review! On 04/13/2015 09:50 PM, John Rose wrote: > On Apr 13, 2015, at 4:51 AM, Zolt?n Maj? > wrote: >> >> please review the following patch. > > Good. This line has a typo ("encrypBlock" = gang member induction > party foul?): > + * AESCrypt.encrypBlock method can be intrinsified on the HotSpot VM Thanks for catching that. Here is the new webrev: http://cr.openjdk.java.net/~zmajo/8067648/webrev.01/ Best regards, Zoltan > > ? John From xuelei.fan at oracle.com Tue Apr 14 07:54:57 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 14 Apr 2015 15:54:57 +0800 Subject: [9] RFR: 8076221: Disable RC4 cipher suites In-Reply-To: <552CABAA.5010402@oracle.com> References: <552CABAA.5010402@oracle.com> Message-ID: <552CC7D1.3030408@oracle.com> Looks fine to me. Thanks, Xuelei On 4/14/2015 1:54 PM, Artem Smotrakov wrote: > Hello, > > RFC 7465 [1] has been published to prohibit RC4. > > Please review this fix which disables RC4 cipher suites in JDK 9 by > adding "RC4" to "jdk.tls.disabledAlgorithms" security property. > > Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076221 > > [1] https://tools.ietf.org/html/rfc7465 > > Artem From vladimir.kozlov at oracle.com Tue Apr 14 15:59:06 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Apr 2015 08:59:06 -0700 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <552CC55E.4010702@oracle.com> References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> <552CC55E.4010702@oracle.com> Message-ID: <552D394A.10309@oracle.com> Sorry for later notice. Can you also list initialCounterBlk.length value in exception message? Thanks, Vladimir On 4/14/15 12:44 AM, Zolt?n Maj? wrote: > Hi Johh, > > > thank you for the review! > > On 04/13/2015 09:50 PM, John Rose wrote: >> On Apr 13, 2015, at 4:51 AM, Zolt?n Maj? > wrote: >>> >>> please review the following patch. >> >> Good. This line has a typo ("encrypBlock" = gang member induction party foul?): >> + * AESCrypt.encrypBlock method can be intrinsified on the HotSpot VM > > Thanks for catching that. Here is the new webrev: > > http://cr.openjdk.java.net/~zmajo/8067648/webrev.01/ > > Best regards, > > > Zoltan > >> >> ? John > From openjdk at suche.org Tue Apr 14 16:27:23 2015 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 14 Apr 2015 18:27:23 +0200 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <552C8356.2020804@oracle.com> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> <552BF95E.6090604@suche.org> <552C8356.2020804@oracle.com> Message-ID: <552D3FEB.8080309@suche.org> Hi, the point is simple. The description for the code say that TLSv1.2 should not have an valid PRF. But for example SSL_DH_anon_WITH_DES_CBC_SHA which is obsoleted in TLSv1.2. But since obsoleted is set to TLSv1.2 the code part: if (obsoleted < ProtocolVersion.TLS12.v) { prf = P_NONE; } Does not set the PRF to the invalid NONE as i would expected with the description. Gru? Thomas > Thanks for the proposal. > > A general TLS/DTLS extension API and pluginable extension implementation > is a good idea. But as there is no rules about how an extension may > impact the handshake flow, it is not easy to define a general APIs for > all existing known or unknown extensions and future extensions. For > example, an extension may impact the cipher suite selection, may need to > define new handshake messages, may need new algorithm implementation, > may impact the algorithm used to sign handshake messages, may impact the > algorithm used to protected application data, etc. An extension may > impact every details of handshaking, not only the client hello and > server hello messages. It would be great if there are general APIs that > are simple and cover the possible impact in every details of > handshaking. I'm open for more advices. > > Maybe we can have APIs to define the extension parameters, rather than > the handshake implementation. But as we already have SSLParameters, I > don't think we need extra APIs for extension parameters any more. > > JSSE is open source and an provider based framework. Alternatively, > we'd like to accept extension implementation contributions, or developer > can define their own private provider if necessary. > > Regards, > Xuelei > > On 4/14/2015 1:14 AM, Thomas Lu?nig wrote: >> Hi, >> >> this could be an interface for such an Callback. >> It allow hello extensions as well as handshake extensions. >> If it would be really clean we would have an handler for: >> - NPN >> - ALPN >> - Channel ID >> - ZertificateSignature >> - OCSP-Stapling >> - ServerName >> - Session Ticket >> >> The handler could be also used for handling: >> - TLS_FALLBACK_SCSV >> >> The current way is that all these extensions are in the sun Private >> package space >> and to make it even worse each extension is written in another way. >> Also i am missing an API defined way to extend the list in >> sun.security.ssl.CipherSuite. >> >> Gru? Thomas >> >> public interface HelloHandler { >> /** >> * Allow to add extesions to Server/Client Hello >> * based on the Client/Server hello */ >> public void handleHelloMessage(ClientHello clientHello, ServerHello serverHello); >> /** Allow to add new Handshake Messages based on >> * the Client/Server Hello >> */ >> public void sendHandshakeMessage(HandshakeOutStream handshakeOutStream, ClientHello clientHello, ServerHello serverHello); >> /** >> * define an order of the extensions >> */ >> Class runBefore(); >> /** >> * define an order of the extensions >> */ >> Class runAfter(); >> } >> >> >> >>> Hi, >>> >>> On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd wrote: >>>> Do you know of a Java TLS implementation that has APIs like this already? I >>>> am also interested in this for the ability to implement authentication >>>> mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like >>>> to see such an API materialize as well. >>> I posted a while back such APIs from 3rd party JSSE implementations: >>> http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html >>> (at the end). >>> >>> The problem that has been raised is that if you offer a generic TLS >>> extensions API, then the extension may have a semantic that it's not >>> implemented. >>> >>> Imagine this TLS extensions API already existed, to add extensions to SSLEngine. >>> Now, ALPN comes along as a new TLS extension. An application could >>> create their own ALPNExtension subclass (extending a standard one >>> provided by the TLS extensions API), and add it to the ClientHello. >>> But there is no code in the JDK that calls the application, asking (on >>> the server) to select one of the protocols, for then send back the >>> chosen protocol to the client. >>> This could be solved by a callback API at the moment the ClientHello >>> is received by the server (and the ServerHello by the client), so the >>> application can examine the ALPN protocols. >>> >>> The NPN extension was doing something even more complicated, creating >>> an additional TLS message that needed to be sent at the right time. >>> >>> It may be that a TLS extensions API (to add/remove/query TLS >>> extensions) *and* a callback API to analyze "hello" messages when they >>> are received is enough to cover a lot of cases, perhaps even all >>> currently existing ones. >>> >>> I asked for feedback some time ago about the status of the ALPN >>> implementation; would be great if the security team could update the >>> current status. >>> From zoltan.majo at oracle.com Tue Apr 14 17:54:08 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 14 Apr 2015 19:54:08 +0200 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <552D394A.10309@oracle.com> References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> <552CC55E.4010702@oracle.com> <552D394A.10309@oracle.com> Message-ID: <552D5440.4090005@oracle.com> Hi Vladimir, On 04/14/2015 05:59 PM, Vladimir Kozlov wrote: > Sorry for later notice. Can you also list initialCounterBlk.length > value in exception message? thank you for the feedback! I extended the error message in the exception, here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8067648/webrev.02/ Best regards, Zoltan > > Thanks, > Vladimir > > On 4/14/15 12:44 AM, Zolt?n Maj? wrote: >> Hi Johh, >> >> >> thank you for the review! >> >> On 04/13/2015 09:50 PM, John Rose wrote: >>> On Apr 13, 2015, at 4:51 AM, Zolt?n Maj? >> > wrote: >>>> >>>> please review the following patch. >>> >>> Good. This line has a typo ("encrypBlock" = gang member induction >>> party foul?): >>> + * AESCrypt.encrypBlock method can be intrinsified on the HotSpot VM >> >> Thanks for catching that. Here is the new webrev: >> >> http://cr.openjdk.java.net/~zmajo/8067648/webrev.01/ >> >> Best regards, >> >> >> Zoltan >> >>> >>> ? John >> From vladimir.kozlov at oracle.com Tue Apr 14 17:59:03 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Apr 2015 10:59:03 -0700 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <552D5440.4090005@oracle.com> References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> <552CC55E.4010702@oracle.com> <552D394A.10309@oracle.com> <552D5440.4090005@oracle.com> Message-ID: <552D5567.0@oracle.com> Good. Thanks, Vladimir On 4/14/15 10:54 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > > On 04/14/2015 05:59 PM, Vladimir Kozlov wrote: >> Sorry for later notice. Can you also list initialCounterBlk.length value in exception message? > > thank you for the feedback! > > I extended the error message in the exception, here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8067648/webrev.02/ > > Best regards, > > > Zoltan > >> >> Thanks, >> Vladimir >> >> On 4/14/15 12:44 AM, Zolt?n Maj? wrote: >>> Hi Johh, >>> >>> >>> thank you for the review! >>> >>> On 04/13/2015 09:50 PM, John Rose wrote: >>>> On Apr 13, 2015, at 4:51 AM, Zolt?n Maj? > wrote: >>>>> >>>>> please review the following patch. >>>> >>>> Good. This line has a typo ("encrypBlock" = gang member induction party foul?): >>>> + * AESCrypt.encrypBlock method can be intrinsified on the HotSpot VM >>> >>> Thanks for catching that. Here is the new webrev: >>> >>> http://cr.openjdk.java.net/~zmajo/8067648/webrev.01/ >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>>> >>>> ? John >>> > From zoltan.majo at oracle.com Tue Apr 14 19:09:19 2015 From: zoltan.majo at oracle.com (Zoltan Majo) Date: Tue, 14 Apr 2015 20:09:19 +0100 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <552D5567.0@oracle.com> References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> <552CC55E.4010702@oracle.com> <552D394A.10309@oracle.com> <552D5440.4090005@oracle.com> <552D5567.0@oracle.com> Message-ID: <552D65DF.4020306@oracle.com> Thank you, John and Vladimir, for the review! Best regards, Zoltan On 14.04.2015 18:59, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 4/14/15 10:54 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> >> On 04/14/2015 05:59 PM, Vladimir Kozlov wrote: >>> Sorry for later notice. Can you also list initialCounterBlk.length >>> value in exception message? >> >> thank you for the feedback! >> >> I extended the error message in the exception, here is the updated >> webrev: >> >> http://cr.openjdk.java.net/~zmajo/8067648/webrev.02/ >> >> Best regards, >> >> >> Zoltan >> >>> >>> Thanks, >>> Vladimir >>> >>> On 4/14/15 12:44 AM, Zolt?n Maj? wrote: >>>> Hi Johh, >>>> >>>> >>>> thank you for the review! >>>> >>>> On 04/13/2015 09:50 PM, John Rose wrote: >>>>> On Apr 13, 2015, at 4:51 AM, Zolt?n Maj? >>>> > wrote: >>>>>> >>>>>> please review the following patch. >>>>> >>>>> Good. This line has a typo ("encrypBlock" = gang member induction >>>>> party foul?): >>>>> + * AESCrypt.encrypBlock method can be intrinsified on the >>>>> HotSpot VM >>>> >>>> Thanks for catching that. Here is the new webrev: >>>> >>>> http://cr.openjdk.java.net/~zmajo/8067648/webrev.01/ >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> >>>>> ? John >>>> >> From anthony.scarpino at oracle.com Tue Apr 14 18:11:26 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 14 Apr 2015 11:11:26 -0700 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <552CC55E.4010702@oracle.com> References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> <552CC55E.4010702@oracle.com> Message-ID: <552D584E.50201@oracle.com> The updated changes look good to me.. Tony On 04/14/2015 12:44 AM, Zolt?n Maj? wrote: > Hi Johh, > > > thank you for the review! > > On 04/13/2015 09:50 PM, John Rose wrote: >> On Apr 13, 2015, at 4:51 AM, Zolt?n Maj? > > wrote: >>> >>> please review the following patch. >> >> Good. This line has a typo ("encrypBlock" = gang member induction >> party foul?): >> + * AESCrypt.encrypBlock method can be intrinsified on the HotSpot VM > > Thanks for catching that. Here is the new webrev: > > http://cr.openjdk.java.net/~zmajo/8067648/webrev.01/ > > Best regards, > > > Zoltan > >> >> ? John > From zoltan.majo at oracle.com Tue Apr 14 19:13:22 2015 From: zoltan.majo at oracle.com (Zoltan Majo) Date: Tue, 14 Apr 2015 20:13:22 +0100 Subject: [9] RFR(S): 8067648: JVM crashes reproducable with GCM cipher suites in GCTR doFinal In-Reply-To: <552D584E.50201@oracle.com> References: <552BADCF.80109@oracle.com> <4E2B097B-D807-428A-B7FB-DFC63F1A7B63@oracle.com> <552CC55E.4010702@oracle.com> <552D584E.50201@oracle.com> Message-ID: <552D66D2.2040805@oracle.com> Thank you, Tony, for the review! Best regards, Zoltan On 14.04.2015 19:11, Anthony Scarpino wrote: > The updated changes look good to me.. > > Tony > > On 04/14/2015 12:44 AM, Zolt?n Maj? wrote: >> Hi Johh, >> >> >> thank you for the review! >> >> On 04/13/2015 09:50 PM, John Rose wrote: >>> On Apr 13, 2015, at 4:51 AM, Zolt?n Maj? >> > wrote: >>>> >>>> please review the following patch. >>> >>> Good. This line has a typo ("encrypBlock" = gang member induction >>> party foul?): >>> + * AESCrypt.encrypBlock method can be intrinsified on the HotSpot VM >> >> Thanks for catching that. Here is the new webrev: >> >> http://cr.openjdk.java.net/~zmajo/8067648/webrev.01/ >> >> Best regards, >> >> >> Zoltan >> >>> >>> ? John >> > From sean.mullan at oracle.com Tue Apr 14 18:58:22 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Apr 2015 14:58:22 -0400 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation In-Reply-To: <552C53F8.5050502@oracle.com> References: <552826F9.7000402@oracle.com> <552851B2.1040102@oracle.com> <55285A58.9090601@oracle.com> <552C2016.6050201@oracle.com> <552C53F8.5050502@oracle.com> Message-ID: <552D634E.6000308@oracle.com> On 04/13/2015 07:40 PM, Jason Uh wrote: > Thanks, Sean. > > Here is a revision: > http://cr.openjdk.java.net/~juh/8076117/02/ Looks good. Just one other comment: the type field in Validator should be private since it isn't referenced by any other code in that package. No need to post an updated webrev just for this. --Sean > > On 04/13/2015 12:59 PM, Sean Mullan wrote: >> On 04/10/2015 07:18 PM, Jason Uh wrote: >>> Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/ >> >> Hi Jason, >> >> Just a few comments: >> >> * Validator >> >> 272: I would name this flag checkUnresolvedCritExts, since we only care >> about them if they are critical and unresolved. >> >> 273: You should only ignore the extensions if the type is PKIX, so line >> 273 should be "(type == TYPE_PKIX) ? false : true;" This way if we ever >> add another type in the JDK implementation, we won't accidentally ignore >> extensions when we shouldn't have. >> >> * EndEntityChecker >> >> 127: don't make this a field of the class, as this can cause concurrency >> issues if EndEntityChecker is shared by threads and used with different >> certificates. Just create and pass in the extensions, ex line 163: >> >> checkRemainingExtensions(getCriticalExtensions(cert)); >> >> and change the other check methods to have a 2nd parameter for the >> extensions, ex: >> >> checkTLSClient(X509Certificate cert, Set exts) >> >> * EndEntityExtensionCheck >> >> Set the validity date using PKIXParameters.setDate to a time within the >> certificate's validity so the test won't start failing when the >> certificates expire. See other chain validation tests for examples. >> >> --Sean >> >> From jason.uh at oracle.com Tue Apr 14 19:46:58 2015 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 14 Apr 2015 12:46:58 -0700 Subject: [9] RFR: 8076117: EndEntityChecker should not process custom extensions after PKIX validation In-Reply-To: <552D634E.6000308@oracle.com> References: <552826F9.7000402@oracle.com> <552851B2.1040102@oracle.com> <55285A58.9090601@oracle.com> <552C2016.6050201@oracle.com> <552C53F8.5050502@oracle.com> <552D634E.6000308@oracle.com> Message-ID: <552D6EB2.8080209@oracle.com> On 4/14/15 11:58 AM, Sean Mullan wrote: > On 04/13/2015 07:40 PM, Jason Uh wrote: >> Thanks, Sean. >> >> Here is a revision: >> http://cr.openjdk.java.net/~juh/8076117/02/ > > Looks good. Just one other comment: the type field in Validator should > be private since it isn't referenced by any other code in that package. > > No need to post an updated webrev just for this. Thanks, Sean. I'll push with that change. > --Sean > >> >> On 04/13/2015 12:59 PM, Sean Mullan wrote: >>> On 04/10/2015 07:18 PM, Jason Uh wrote: >>>> Revised webrev: http://cr.openjdk.java.net/~juh/8076117/01/ >>> >>> Hi Jason, >>> >>> Just a few comments: >>> >>> * Validator >>> >>> 272: I would name this flag checkUnresolvedCritExts, since we only care >>> about them if they are critical and unresolved. >>> >>> 273: You should only ignore the extensions if the type is PKIX, so line >>> 273 should be "(type == TYPE_PKIX) ? false : true;" This way if we ever >>> add another type in the JDK implementation, we won't accidentally ignore >>> extensions when we shouldn't have. >>> >>> * EndEntityChecker >>> >>> 127: don't make this a field of the class, as this can cause concurrency >>> issues if EndEntityChecker is shared by threads and used with different >>> certificates. Just create and pass in the extensions, ex line 163: >>> >>> checkRemainingExtensions(getCriticalExtensions(cert)); >>> >>> and change the other check methods to have a 2nd parameter for the >>> extensions, ex: >>> >>> checkTLSClient(X509Certificate cert, Set exts) >>> >>> * EndEntityExtensionCheck >>> >>> Set the validity date using PKIXParameters.setDate to a time within the >>> certificate's validity so the test won't start failing when the >>> certificates expire. See other chain validation tests for examples. >>> >>> --Sean >>> >>> From lussnig at suche.org Tue Apr 14 16:25:08 2015 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 14 Apr 2015 18:25:08 +0200 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <552C568A.1030405@oracle.com> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> <552C0A24.6000408@suche.org> <552C568A.1030405@oracle.com> Message-ID: <552D3F64.4000009@suche.org> Hi, the point is simple. The description for the code say that TLSv1.2 should not have an valid PRF. But for example SSL_DH_anon_WITH_DES_CBC_SHA which is obsoleted in TLSv1.2. But since obsoleted is set to TLSv1.2 the code part: if (obsoleted < ProtocolVersion.TLS12.v) { prf = P_NONE; } Does not set the PRF to the invalid NONE as i would expected with the description. Gru? Thomas > On 4/14/2015 2:25 AM, Thomas Lu?nig wrote: >> Hi, >> >> i checked the CipherSuites in JDK and found that in the JDK there is and >> mistake i think. >> In CipherSuite the method add set the PRF to NONE only if obsoleted less >> than TLSv1.2. >> But if the suite is forbidden / obsoleted in TLSv1.2 the check must be >> <= (less or equal) > Can you explain more about this point? > > Xuelei > >> if i am correct. >> >> http://grepcode.com/file_/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/ssl/CipherSuite.java/?v=source >> >> /* >> * Use this method when there is no lower protocol limit where this >> * suite can be used, and the PRF is P_SHA256. That is, the >> * existing ciphersuites. From RFC 5246: >> * >> * All cipher suites in this document use P_SHA256. >> */ >> private static void add(String name, int id, int priority, >> KeyExchange keyExchange, BulkCipher cipher, >> boolean allowed, int obsoleted) { >> // If this is an obsoleted suite, then don't let the TLS 1.2 >> // protocol have a valid PRF value. >> PRF prf = P_SHA256; >> if (obsoleted < ProtocolVersion.TLS12.v) { >> prf = P_NONE; >> } >> >> add(name, id, priority, keyExchange, cipher, allowed, obsoleted, >> ProtocolVersion.LIMIT_MIN_VALUE, prf); >> } >> >> Gru? Thomas >> From xuelei.fan at oracle.com Wed Apr 15 00:05:44 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Apr 2015 08:05:44 +0800 Subject: JEP 244: TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <552D3F64.4000009@suche.org> References: <20150409223635.74AFC555B2@eggemoggin.niobe.net> <552BD9AD.7070000@suche.org> <552BED2A.70903@redhat.com> <552C0A24.6000408@suche.org> <552C568A.1030405@oracle.com> <552D3F64.4000009@suche.org> Message-ID: <552DAB58.7040001@oracle.com> I see. I filed a new bug: https://bugs.openjdk.java.net/browse/JDK-8077806 Thanks for looking into this issue. Xuelei On 4/15/2015 12:25 AM, Thomas Lu?nig wrote: > Hi, > > the point is simple. The description for the code say that TLSv1.2 > should not have an valid PRF. > But for example SSL_DH_anon_WITH_DES_CBC_SHA which is obsoleted in TLSv1.2. > But since obsoleted is set to TLSv1.2 the code part: > > if (obsoleted < ProtocolVersion.TLS12.v) { prf = P_NONE; } > > Does not set the PRF to the invalid NONE as i would expected with the > description. > > Gru? Thomas >> On 4/14/2015 2:25 AM, Thomas Lu?nig wrote: >>> Hi, >>> >>> i checked the CipherSuites in JDK and found that in the JDK there is and >>> mistake i think. >>> In CipherSuite the method add set the PRF to NONE only if obsoleted less >>> than TLSv1.2. >>> But if the suite is forbidden / obsoleted in TLSv1.2 the check must be >>> <= (less or equal) >> Can you explain more about this point? >> >> Xuelei >> >>> if i am correct. >>> >>> http://grepcode.com/file_/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/security/ssl/CipherSuite.java/?v=source >>> >>> /* >>> * Use this method when there is no lower protocol limit where this >>> * suite can be used, and the PRF is P_SHA256. That is, the >>> * existing ciphersuites. From RFC 5246: >>> * >>> * All cipher suites in this document use P_SHA256. >>> */ >>> private static void add(String name, int id, int priority, >>> KeyExchange keyExchange, BulkCipher cipher, >>> boolean allowed, int obsoleted) { >>> // If this is an obsoleted suite, then don't let the TLS 1.2 >>> // protocol have a valid PRF value. >>> PRF prf = P_SHA256; >>> if (obsoleted < ProtocolVersion.TLS12.v) { >>> prf = P_NONE; >>> } >>> >>> add(name, id, priority, keyExchange, cipher, allowed, obsoleted, >>> ProtocolVersion.LIMIT_MIN_VALUE, prf); >>> } >>> >>> Gru? Thomas >>> > From artem.smotrakov at oracle.com Wed Apr 15 07:06:58 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 15 Apr 2015 10:06:58 +0300 Subject: [8u] RFR: 8076221: Disable RC4 cipher suites Message-ID: <552E0E12.3020202@oracle.com> Hello, RFC 7465 [1] has been published to prohibit RC4. Please review this fix which disables RC4 cipher suites in JDK 8u by adding "RC4" to "jdk.tls.disabledAlgorithms" security property. Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.8u.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076221 [1] https://tools.ietf.org/html/rfc7465 Artem From xuelei.fan at oracle.com Wed Apr 15 07:42:06 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 15 Apr 2015 15:42:06 +0800 Subject: [8u] RFR: 8076221: Disable RC4 cipher suites In-Reply-To: <552E0E12.3020202@oracle.com> References: <552E0E12.3020202@oracle.com> Message-ID: <552E164E.5010601@oracle.com> Looks fine to me. Xuelei On 4/15/2015 3:06 PM, Artem Smotrakov wrote: > Hello, > > RFC 7465 [1] has been published to prohibit RC4. > > Please review this fix which disables RC4 cipher suites in JDK 8u by > adding "RC4" to "jdk.tls.disabledAlgorithms" security property. > > Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.8u.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076221 > > [1] https://tools.ietf.org/html/rfc7465 > > Artem > From artem.smotrakov at oracle.com Wed Apr 15 08:17:54 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 15 Apr 2015 11:17:54 +0300 Subject: [8u] RFR: 8076221: Disable RC4 cipher suites In-Reply-To: <552E164E.5010601@oracle.com> References: <552E0E12.3020202@oracle.com> <552E164E.5010601@oracle.com> Message-ID: <552E1EB2.2050704@oracle.com> cc'ing jdk8u-dev at openjdk.java.net Would you please approve this backport to 8u-dev? The difference is: - JDK 9 has a single java.security file, but JDK 8u has java.security file for each generic platform, so each file needs to be updated. - Test names are different, but the changes are the same (reset 'jdk.tls.disabledAlgorithms' security property) Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.8u.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076221 Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 Artem On 04/15/2015 10:42 AM, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 4/15/2015 3:06 PM, Artem Smotrakov wrote: >> Hello, >> >> RFC 7465 [1] has been published to prohibit RC4. >> >> Please review this fix which disables RC4 cipher suites in JDK 8u by >> adding "RC4" to "jdk.tls.disabledAlgorithms" security property. >> >> Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.8u.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076221 >> >> [1] https://tools.ietf.org/html/rfc7465 >> >> Artem >> From sean.coffey at oracle.com Wed Apr 15 09:54:28 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 15 Apr 2015 10:54:28 +0100 Subject: [8u] RFR: 8076221: Disable RC4 cipher suites In-Reply-To: <552E1EB2.2050704@oracle.com> References: <552E0E12.3020202@oracle.com> <552E164E.5010601@oracle.com> <552E1EB2.2050704@oracle.com> Message-ID: <552E3554.6080507@oracle.com> Looks good. Approved. Regards, Sean. On 15/04/15 09:17, Artem Smotrakov wrote: > cc'ing jdk8u-dev at openjdk.java.net > > Would you please approve this backport to 8u-dev? > > The difference is: > - JDK 9 has a single java.security file, but JDK 8u has java.security > file for each generic platform, so each file needs to be updated. > - Test names are different, but the changes are the same (reset > 'jdk.tls.disabledAlgorithms' security property) > > Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.8u.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076221 > Changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/23cde932f139 > > Artem > > On 04/15/2015 10:42 AM, Xuelei Fan wrote: >> Looks fine to me. >> >> Xuelei >> >> On 4/15/2015 3:06 PM, Artem Smotrakov wrote: >>> Hello, >>> >>> RFC 7465 [1] has been published to prohibit RC4. >>> >>> Please review this fix which disables RC4 cipher suites in JDK 8u by >>> adding "RC4" to "jdk.tls.disabledAlgorithms" security property. >>> >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8076221/webrev.8u.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076221 >>> >>> [1] https://tools.ietf.org/html/rfc7465 >>> >>> Artem >>> > From joe.darcy at oracle.com Thu Apr 16 00:36:32 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 15 Apr 2015 17:36:32 -0700 Subject: JDK 9 RFR of JDK-8077915: Fix doclint issues in javax.smartcardio Message-ID: <552F0410.6010504@oracle.com> Hello, The javax.smartcardio subcomponet in JBS is under the security-libs component so I suppose this is the best place to send a code review request. In any case, some missing doclint in javax.smartcardio is preventing doclint checking for that package being enabled in the build; please review the addition of the missing javadoc: JDK-8077915: Fix doclint issues in javax.smartcardio http://cr.openjdk.java.net/~darcy/8077915.0/ Patch below. Thanks, -Joe --- old/src/java.smartcardio/share/classes/javax/smartcardio/Card.java 2015-04-15 17:33:02.248101501 -0700 +++ new/src/java.smartcardio/share/classes/javax/smartcardio/Card.java 2015-04-15 17:33:02.072101497 -0700 @@ -69,6 +69,7 @@ * Returns the CardChannel for the basic logical channel. The basic * logical channel has a channel number of 0. * + * @return the CardChannel for the basic logical channel * @throws SecurityException if a SecurityManager exists and the * caller does not have the required * {@linkplain CardPermission permission} @@ -82,6 +83,7 @@ * opened by issuing a MANAGE CHANNEL command that should use * the format [00 70 00 00 01]. * + * @return the card to which a logical channel has been opened * @throws SecurityException if a SecurityManager exists and the * caller does not have the required * {@linkplain CardPermission permission} @@ -137,6 +139,7 @@ * * @param controlCode the control code of the command * @param command the command data + * @return the response from the terminal device * * @throws SecurityException if a SecurityManager exists and the * caller does not have the required --- old/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminal.java 2015-04-15 17:33:02.684101511 -0700 +++ new/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminal.java 2015-04-15 17:33:02.508101507 -0700 @@ -83,6 +83,7 @@ * @throws SecurityException if a SecurityManager exists and the * caller does not have the required * {@linkplain CardPermission permission} + * @return the card the connection has been established with */ public abstract Card connect(String protocol) throws CardException; --- old/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminals.java 2015-04-15 17:33:03.124101521 -0700 +++ new/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminals.java 2015-04-15 17:33:02.956101517 -0700 @@ -105,6 +105,7 @@ * Returns the terminal with the specified name or null if no such * terminal exists. * + * @param name the terminal name * @return the terminal with the specified name or null if no such * terminal exists. * From yonathan at gmail.com Thu Apr 16 01:16:40 2015 From: yonathan at gmail.com (Yonathan) Date: Wed, 15 Apr 2015 18:16:40 -0700 Subject: JDK 9 RFR of JDK-8077915: Fix doclint issues in javax.smartcardio In-Reply-To: <552F0410.6010504@oracle.com> References: <552F0410.6010504@oracle.com> Message-ID: --- old/src/java.smartcardio/share/classes/javax/smartcardio/Card.java 2015-04-15 17:33:02.248101501 -0700 +++ new/src/java.smartcardio/share/classes/javax/smartcardio/Card.java 2015-04-15 17:33:02.072101497 -0700 @@ -82,6 +83,7 @@ * opened by issuing a MANAGE CHANNEL command that should use * the format [00 70 00 00 01]. * + * @return the card to which a logical channel has been opened * @throws SecurityException if a SecurityManager exists and the * caller does not have the required * {@linkplain CardPermission permission} The documentation for openLogicalChannel() should be @return the logical channel that was opened From sean.mullan at oracle.com Thu Apr 16 10:46:03 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 16 Apr 2015 06:46:03 -0400 Subject: JDK 9 RFR of JDK-8077915: Fix doclint issues in javax.smartcardio In-Reply-To: <552F0410.6010504@oracle.com> References: <552F0410.6010504@oracle.com> Message-ID: <552F92EB.1080400@oracle.com> Looks fine to me. --Sean On 04/15/2015 08:36 PM, joe darcy wrote: > Hello, > > The javax.smartcardio subcomponet in JBS is under the security-libs > component so I suppose this is the best place to send a code review > request. > > In any case, some missing doclint in javax.smartcardio is preventing > doclint checking for that package being enabled in the build; please > review the addition of the missing javadoc: > > JDK-8077915: Fix doclint issues in javax.smartcardio > http://cr.openjdk.java.net/~darcy/8077915.0/ > > Patch below. > > Thanks, > > -Joe > > --- old/src/java.smartcardio/share/classes/javax/smartcardio/Card.java > 2015-04-15 17:33:02.248101501 -0700 > +++ new/src/java.smartcardio/share/classes/javax/smartcardio/Card.java > 2015-04-15 17:33:02.072101497 -0700 > @@ -69,6 +69,7 @@ > * Returns the CardChannel for the basic logical channel. The basic > * logical channel has a channel number of 0. > * > + * @return the CardChannel for the basic logical channel > * @throws SecurityException if a SecurityManager exists and the > * caller does not have the required > * {@linkplain CardPermission permission} > @@ -82,6 +83,7 @@ > * opened by issuing a MANAGE CHANNEL command that > should use > * the format [00 70 00 00 01]. > * > + * @return the card to which a logical channel has been opened > * @throws SecurityException if a SecurityManager exists and the > * caller does not have the required > * {@linkplain CardPermission permission} > @@ -137,6 +139,7 @@ > * > * @param controlCode the control code of the command > * @param command the command data > + * @return the response from the terminal device > * > * @throws SecurityException if a SecurityManager exists and the > * caller does not have the required > --- > old/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminal.java > 2015-04-15 17:33:02.684101511 -0700 > +++ > new/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminal.java > 2015-04-15 17:33:02.508101507 -0700 > @@ -83,6 +83,7 @@ > * @throws SecurityException if a SecurityManager exists and the > * caller does not have the required > * {@linkplain CardPermission permission} > + * @return the card the connection has been established with > */ > public abstract Card connect(String protocol) throws CardException; > > --- > old/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminals.java > 2015-04-15 17:33:03.124101521 -0700 > +++ > new/src/java.smartcardio/share/classes/javax/smartcardio/CardTerminals.java > 2015-04-15 17:33:02.956101517 -0700 > @@ -105,6 +105,7 @@ > * Returns the terminal with the specified name or null if no such > * terminal exists. > * > + * @param name the terminal name > * @return the terminal with the specified name or null if no such > * terminal exists. > * > From sean.mullan at oracle.com Fri Apr 17 12:47:17 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Apr 2015 08:47:17 -0400 Subject: [9] RFR: 7194452: Remove "Reverse" PKIX CertPathBuilder implementation In-Reply-To: <550CA8F3.2070007@oracle.com> References: <550CA8F3.2070007@oracle.com> Message-ID: <553100D5.7070201@oracle.com> Looks good. --Sean On 03/20/2015 07:10 PM, Jason Uh wrote: > Please review this change to remove the "Reverse" CertPathBuilder mode, > which has never been supported and is undocumented. > > webrev: http://cr.openjdk.java.net/~juh/7194452/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-7194452 > > Thanks, > Jason From magnus.ihse.bursie at oracle.com Fri Apr 17 12:52:23 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 17 Apr 2015 14:52:23 +0200 Subject: RFR: JDK-8074859 Turn on warnings as error Message-ID: <55310207.9050207@oracle.com> With JDK-8074096, the number of warnings in the product was reduced to a minimum. This enables the next step, which is turning on the respective compiler flags that turns warnings into errors. In the long run, this is the only way to keep the warnings from creeping back. Even with JDK-8074096, the product does not build 100% warning free. This is due to some warnings that cannot be disabled, or (in one case) where C and C++ code is mixed, and warnings for both languages cannot be used. A system similar to the one introduced in JDK-8074096 is therefore needed, in which individual libraries can be exempted from this flag, until such warnings are fixed. A library can thus disable warnings as errors with WARNINGS_AS_ERRORS := false, or (better) use a toolchain-specific version, e.g WARNINGS_AS_ERRORS_gcc := false. This is intended as a temporary measure, though. The long-term solution is reasonably to fix the warnings and remove that argument. Also, different versions of compilers can generate a different set of warnings. It is therefore necessary to be able to turn off this globally. Therefor a new flag for configure is introduced: --disable-warnings-as-errors. While the code compiles without errors on the build systems used internally at Oracle, this might not be the case on other combinations of operating system versions and toolchain versions. To facilitate for unexpecting developers, a help message is added if the build fails, that suggests using --disable-warnings-as-errors. This solution was chosen as a compromise between the "hard core" solution of turning on warnings as errors by default for anyone, and the cowar... erm, conservative solution of checking if the compiler versions exactly match what's used inside Oracle (and therefore regularly tested), and only turn it on in that case. Similarly to JDK-8074096, I intend to file follow-up bugs for each individual library that got a WARNINGS_AS_ERRORS_* := false. Bug: https://bugs.openjdk.java.net/browse/JDK-8074859 WebRev for top: http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01 WebRev for jdk: http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01 Some comments: * I needed to add a few more DISABLED_WARNINGS. For windows, this is most likely due to the recent compiler change. For other libraries, I'm not sure, but it might well be the result of recent changes that has introduced new warnings. If so, it highlights the need of this patch to keep the build warning free. * For a few libraries and toolchains, there is *both* WARNINGS_AS_ERRORS := false and a DISABLED_WARNINGS list. This is the case if not all warnings are possible to disable. * I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This is included in our JDK LDFLAGS, so it should not be set separately, and definitely not as CFLAGS. (This caused compiler warnings, which now turned into errors.) However, a more suitable long-term solution is probably to move the knowledge of how to create shared libraries more specifically into SetupNativeCompilation, and not set it as part of the JDK flags. /Magnus From jason.uh at oracle.com Fri Apr 17 19:03:16 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 17 Apr 2015 12:03:16 -0700 Subject: [9] RFR 8076535: Deprecate the com.sun.jarsigner package Message-ID: <553158F4.40205@oracle.com> Please review this change to deprecate the com.sun.jarsigner package. webrev: http://cr.openjdk.java.net/~juh/8076535/00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8076535 Thanks, Jason From mark.reinhold at oracle.com Fri Apr 17 21:05:40 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 17 Apr 2015 14:05:40 -0700 (PDT) Subject: JEP 246: Leverage CPU Instructions for GHASH and RSA Message-ID: <20150417210540.87667569D9@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/246 - Mark From weijun.wang at oracle.com Mon Apr 20 01:46:57 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 20 Apr 2015 09:46:57 +0800 Subject: RFR 8075575/8075576: 2 com/sun/security/auth tests failed in certain env In-Reply-To: <5513990A.5080207@oracle.com> References: <5513990A.5080207@oracle.com> Message-ID: <55345A91.7060802@oracle.com> Ping again. On 3/26/2015 1:28 PM, Weijun Wang wrote: > Please review the change at > > http://cr.openjdk.java.net/~weijun/8075575/webrev.00 > > The test checks for certain English text in the output, and cannot find > if running in another locale. Tests now forced running in English. > > I've tried modifying the tests to check for localized texts returning > from ResourceBundle.getgetBundle().getString(). The test is not easy to > read and in one test MessageFormat.format() needs to be called. I > abandon this attempt and choose the current fix. > > Thanks > Max From xuelei.fan at oracle.com Mon Apr 20 03:50:46 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 20 Apr 2015 11:50:46 +0800 Subject: RFR 8075575/8075576: 2 com/sun/security/auth tests failed in certain env In-Reply-To: <55345A91.7060802@oracle.com> References: <5513990A.5080207@oracle.com> <55345A91.7060802@oracle.com> Message-ID: <55347796.6050100@oracle.com> Looks fine to me. Xuelei On 4/20/2015 9:46 AM, Weijun Wang wrote: > Ping again. > > On 3/26/2015 1:28 PM, Weijun Wang wrote: >> Please review the change at >> >> http://cr.openjdk.java.net/~weijun/8075575/webrev.00 >> >> The test checks for certain English text in the output, and cannot find >> if running in another locale. Tests now forced running in English. >> >> I've tried modifying the tests to check for localized texts returning >> from ResourceBundle.getgetBundle().getString(). The test is not easy to >> read and in one test MessageFormat.format() needs to be called. I >> abandon this attempt and choose the current fix. >> >> Thanks >> Max From erik.joelsson at oracle.com Mon Apr 20 07:02:13 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 20 Apr 2015 09:02:13 +0200 Subject: RFR: JDK-8074859 Turn on warnings as error In-Reply-To: <55310207.9050207@oracle.com> References: <55310207.9050207@oracle.com> Message-ID: <5534A475.2090909@oracle.com> Looks good to me. /Erik On 2015-04-17 14:52, Magnus Ihse Bursie wrote: > With JDK-8074096, the number of warnings in the product was reduced to > a minimum. This enables the next step, which is turning on the > respective compiler flags that turns warnings into errors. In the long > run, this is the only way to keep the warnings from creeping back. > > Even with JDK-8074096, the product does not build 100% warning free. > This is due to some warnings that cannot be disabled, or (in one case) > where C and C++ code is mixed, and warnings for both languages cannot > be used. A system similar to the one introduced in JDK-8074096 is > therefore needed, in which individual libraries can be exempted from > this flag, until such warnings are fixed. A library can thus disable > warnings as errors with WARNINGS_AS_ERRORS := false, or (better) use a > toolchain-specific version, e.g WARNINGS_AS_ERRORS_gcc := false. This > is intended as a temporary measure, though. The long-term solution is > reasonably to fix the warnings and remove that argument. > > Also, different versions of compilers can generate a different set of > warnings. It is therefore necessary to be able to turn off this > globally. Therefor a new flag for configure is introduced: > --disable-warnings-as-errors. > > While the code compiles without errors on the build systems used > internally at Oracle, this might not be the case on other combinations > of operating system versions and toolchain versions. To facilitate for > unexpecting developers, a help message is added if the build fails, > that suggests using --disable-warnings-as-errors. This solution was > chosen as a compromise between the "hard core" solution of turning on > warnings as errors by default for anyone, and the cowar... erm, > conservative solution of checking if the compiler versions exactly > match what's used inside Oracle (and therefore regularly tested), and > only turn it on in that case. > > Similarly to JDK-8074096, I intend to file follow-up bugs for each > individual library that got a WARNINGS_AS_ERRORS_* := false. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074859 > WebRev for top: > http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01 > WebRev for jdk: > http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01 > > Some comments: > > * I needed to add a few more DISABLED_WARNINGS. For windows, this is > most likely due to the recent compiler change. For other libraries, > I'm not sure, but it might well be the result of recent changes that > has introduced new warnings. If so, it highlights the need of this > patch to keep the build warning free. > > * For a few libraries and toolchains, there is *both* > WARNINGS_AS_ERRORS := false and a DISABLED_WARNINGS list. This is the > case if not all warnings are possible to disable. > > * I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This is > included in our JDK LDFLAGS, so it should not be set separately, and > definitely not as CFLAGS. (This caused compiler warnings, which now > turned into errors.) However, a more suitable long-term solution is > probably to move the knowledge of how to create shared libraries more > specifically into SetupNativeCompilation, and not set it as part of > the JDK flags. > > /Magnus From artem.smotrakov at oracle.com Tue Apr 21 05:25:45 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 21 Apr 2015 08:25:45 +0300 Subject: [9] RFR: 8050374: More Signature tests Message-ID: <5535DF59.1070203@oracle.com> Hello, Please review a couple of new tests for Signature and SignedObject. The test use different providers, that's why I put them to provider-specific locations. Bug: https://bugs.openjdk.java.net/browse/JDK-8050374 Webrev: http://cr.openjdk.java.net/~asmotrak/8050374/webrev.00/ Artem From artem.smotrakov at oracle.com Tue Apr 21 14:22:06 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 21 Apr 2015 17:22:06 +0300 Subject: [9] RFR: 8048138: Tests for JAAS callbacks Message-ID: <55365D0E.2050808@oracle.com> Hello, Please review a couple of new tests for JAAS: - StandardCallbacks.java is for standard JAAS callbacks (except RealmCallback and RealmChoiceCallback since the test is not about Sasl, and actually those two callback extends ChoiceCallback which is used in the test) - SharedState.java checks if a shared state is passed to login modules Bug: https://bugs.openjdk.java.net/browse/JDK-8048138 Webrev: http://cr.openjdk.java.net/~asmotrak/8048138/webrev.00/ Artem From artem.smotrakov at oracle.com Tue Apr 21 14:41:52 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 21 Apr 2015 17:41:52 +0300 Subject: [9] RFR: 8075007: Additional tests for krb5-related cipher suites with unbound server Message-ID: <553661B0.7050508@oracle.com> Hello, Please review a couple of new tests for krb5 cipher suites with unbound server: - tests check if an unbound server can handle connections only for allowed service principals - tests check if an unbound server picks up a correct key from keytab - tests check if an unbound server uses a service principal from "sun.security.krb5.principal" system property if specified I also added a helper method to KDC.java to check that a KDC instance is up. Bug: https://bugs.openjdk.java.net/browse/JDK-8075007 Webrev: http://cr.openjdk.java.net/~asmotrak/8075007/webrev.00/ Artem From sean.mullan at oracle.com Tue Apr 21 19:43:03 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 21 Apr 2015 15:43:03 -0400 Subject: CertificateExtensions In-Reply-To: <8592CB88-7F28-48BF-AC5B-E0C0C573E955@oracle.com> References: <8592CB88-7F28-48BF-AC5B-E0C0C573E955@oracle.com> Message-ID: <5536A847.4000305@oracle.com> On 03/30/2015 11:57 PM, Wang Weijun wrote: > Hi Sean > > Are you OK with this? > >> CertificateExtensions.java >> ========================== >> >> Since we don't use names as keys, CertificateExtensions is not a typical CertAttrSet now. Remove the implements clause. > > Almost every class in the x509 package is built around the CertAttrSet and they together weave an elegant net. It will be nice if CertificateExtensions can only use the hierarchical names as keys, but unfortunately, it has to use OID sometimes. > > My suggestion above breaks it from the CertAttrSet net. I won't dare to do this before jdk9 because people outside might use these classes, but now it's probably safe to do so. Well, they may still be able to use them in JDK 9 if they go through some extra hoops. I think that we should proceed with care, and avoid making too many changes to these internal APIs if we can. Although we don't want anyone using these classes, sun.security.x509 is one of the older internal packages, so there is somewhat of a higher risk we will break existing code. That said, it shouldn't be a rule, since there were never any guarantees to begin with. So I would be slightly in favor of leaving it as is for now as long as it isn't causing any other issues. In JDK 10, we can be more aggressive about adapting these internal APIs as we see fit. --Sean > > Said that, CertificateExtensions is now an alien. Although its sibling CRLExtensions has always been one. > > Thanks > Max > From joe.darcy at oracle.com Wed Apr 22 02:13:16 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 21 Apr 2015 19:13:16 -0700 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness Message-ID: <553703BC.1070504@oracle.com> Hello, As the next step of implementing "Proposed new policies for JDK 9 regression tests: tiered testing, intermittent failures, and randomness" [1], please review this changeset which adds a "randomness" jtreg keyword and tags 240 regression tests in the jdk repository with the keyword: JDK-8078334: Mark regression tests using randomness http://cr.openjdk.java.net/~darcy/8078334.0/ The update to test/TEST.ROOT is -# The list of keywords supported in the entire test suite -keys=2d dnd i18n intermittent +# The list of keywords supported in the entire test suite. The +# "intermittent" keyword marks tests known to fail intermittently. +# The "randomness" keyword marks tests using randomness with test +# cases differing from run to run. (A test using a fixed random seed +# would not count as "randomness" by this definition.) Extra care +# should be taken to handle test failures of intermittent or +# randomness tests. + +keys=2d dnd i18n intermittent randomness To find the affected files for this fix, I grepped over the regression tests looking for "random" and verified if a random number generated was used in a way where its values would differ from run to run. In particular, as noted above, a java.util.Random random number generator with a fixed seed did *not* qualify a test for the "randomness" keyword. The usual update to the files in this changeset is just + * @key randomness The updated tests are mostly in the core libs and security libs areas with a few serviceability tests too. The list in this bug is not quite exhaustive; I did not include rmi tests or client libraries tests. I verified that running jtreg ... -l -k:randomness . returns the expected number of tests and that the tests continue to pass (or be ignored) when run. One goal of marking the tests using randomness is to help root out some remaining intermittent test failures. If one of the randomness tests is observed to fail intermittently, if it has not already been updated to print out the random seed and be able to accept a particular seed when run, the test should be so modified so that future failures can log the seed value in hopes of reproducing the failure. Brian Burkhalter has proactively made these sorts of changes to the java.math tests earlier in JDK 9. [2] Since most of the randomness tests don't have a history of instability (and due to the unexpected large number of them!), I don't think it is necessary to proactively update all the other tests without evidence of a history of failure. However, when an otherwise unexplained failure is seen, I recommend applying the sort of updates Brian has done in java.math to the failing test(s). Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html [2] JDK-8074460, Always print seeds used in [Splittable]Random instances in java.math tests, https://bugs.openjdk.java.net/browse/JDK-8074460 From daniel.fuchs at oracle.com Wed Apr 22 08:31:47 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 Apr 2015 10:31:47 +0200 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <553703BC.1070504@oracle.com> References: <553703BC.1070504@oracle.com> Message-ID: <55375C73.7060001@oracle.com> On 22/04/15 04:13, Joseph D. Darcy wrote: > One goal of marking the tests using randomness is to help root out some > remaining intermittent test failures. If one of the randomness tests is > observed to fail intermittently, if it has not already been updated to > print out the random seed and be able to accept a particular seed when > run, the test should be so modified so that future failures can log the > seed value in hopes of reproducing the failure. Hi Joe, The following logging tests use UUID.randomUUID() to generate a 'unique' file name in order to avoid possible collision if these tests are run concurrently or if some files have been left over from a previous run (some of these use %t - the temporary directory - which has been known to cause intermittent failure in those cases). So I believe that removing randomness, or attempting to make it predictable, would in those specific cases make those tests more prone to intermittent failures. In this light - should these tests still be tagged with the @randomness keyword? test/java/util/logging/CheckZombieLockTest.java test/java/util/logging/FileHandlerLongLimit.java test/java/util/logging/FileHandlerPath.java test/java/util/logging/FileHandlerPatternExceptions.java test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java best regards, -- daniel From amy.lu at oracle.com Wed Apr 22 11:19:39 2015 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 22 Apr 2015 19:19:39 +0800 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <55375C73.7060001@oracle.com> References: <553703BC.1070504@oracle.com> <55375C73.7060001@oracle.com> Message-ID: <553783CB.7050902@oracle.com> On 4/22/15 4:31 PM, Daniel Fuchs wrote: > On 22/04/15 04:13, Joseph D. Darcy wrote: >> One goal of marking the tests using randomness is to help root out some >> remaining intermittent test failures. If one of the randomness tests is >> observed to fail intermittently, if it has not already been updated to >> print out the random seed and be able to accept a particular seed when >> run, the test should be so modified so that future failures can log the >> seed value in hopes of reproducing the failure. > > Hi Joe, > > The following logging tests use UUID.randomUUID() to generate > a 'unique' file name in order to avoid possible collision if > these tests are run concurrently or if some files have been > left over from a previous run (some of these use %t - the temporary > directory - which has been known to cause intermittent > failure in those cases). > > So I believe that removing randomness, or attempting to > make it predictable, would in those specific cases make > those tests more prone to intermittent failures. > > In this light - should these tests still be tagged with > the @randomness keyword? > > test/java/util/logging/CheckZombieLockTest.java > test/java/util/logging/FileHandlerLongLimit.java > test/java/util/logging/FileHandlerPath.java > test/java/util/logging/FileHandlerPatternExceptions.java > test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java > > > > best regards, > > -- daniel I notice similar case in below tests: test/java/util/zip/ZipFile/FinalizeZipFile.java Test need some zip file to test on. Random is used to generate the zip file name. test/java/util/zip/ZipFile/ReadZip.java Random is used to generate a non-existing file name for negative test @randomness might not needed for following tests where test need a zip file to test on, and Random is used to fill some content to the file in createZipFile(). test/java/util/zip/ZipFile/MultiThreadedReadTest.java test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Thanks, Amy From vincent.x.ryan at oracle.com Wed Apr 22 12:22:47 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 22 Apr 2015 13:22:47 +0100 Subject: [9] code review request 8078348: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with BindException Message-ID: <31AADC23-15A1-4D9B-B0A3-0DD1AAEA34B5@oracle.com> Please review this fix for an intermittently failing security test. It?s an ?Address already in use? issue corrected by the usual fix. BTW there are 3 less complex versions of this test which have not reported any intermittent failures. I can modify them too in a follow-up fix, if necessary. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8078348 Webrev: http://cr.openjdk.java.net/~vinnie/8078348/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Apr 22 12:34:42 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 22 Apr 2015 20:34:42 +0800 Subject: [9] code review request 8078348: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with BindException In-Reply-To: <31AADC23-15A1-4D9B-B0A3-0DD1AAEA34B5@oracle.com> References: <31AADC23-15A1-4D9B-B0A3-0DD1AAEA34B5@oracle.com> Message-ID: <55379562.6070200@oracle.com> Nice fix! Looks fine to me. On 4/22/2015 8:22 PM, Vincent Ryan wrote: > Please review this fix for an intermittently failing security test. > It?s an ?Address already in use? issue corrected by the usual fix. > > BTW there are 3 less complex versions of this test which have not > reported any intermittent failures. > I can modify them too in a follow-up fix, if necessary. > It is nice to get them fixed too, I think. Thanks, Xuelei > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8078348 > Webrev: http://cr.openjdk.java.net/~vinnie/8078348/webrev.00/ From vincent.x.ryan at oracle.com Wed Apr 22 12:40:49 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 22 Apr 2015 13:40:49 +0100 Subject: [9] code review request 8078348: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with BindException In-Reply-To: <55379562.6070200@oracle.com> References: <31AADC23-15A1-4D9B-B0A3-0DD1AAEA34B5@oracle.com> <55379562.6070200@oracle.com> Message-ID: <0D2DF526-D4B2-494E-9C2C-7DAF4CDE72B1@oracle.com> > On 22 Apr 2015, at 13:34, Xuelei Fan wrote: > > Nice fix! Looks fine to me. > > On 4/22/2015 8:22 PM, Vincent Ryan wrote: >> Please review this fix for an intermittently failing security test. >> It?s an ?Address already in use? issue corrected by the usual fix. >> >> BTW there are 3 less complex versions of this test which have not >> reported any intermittent failures. >> I can modify them too in a follow-up fix, if necessary. >> > It is nice to get them fixed too, I think. The other versions of this test are simpler and do not cycle through all the available JCE providers so they are not exposed to this timing issue where the port is quickly re-requested before it is ready for use. > > Thanks, > Xuelei > >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8078348 >> Webrev: http://cr.openjdk.java.net/~vinnie/8078348/webrev.00/ > From xuelei.fan at oracle.com Wed Apr 22 13:03:23 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 22 Apr 2015 21:03:23 +0800 Subject: [9] code review request 8078348: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails with BindException In-Reply-To: <0D2DF526-D4B2-494E-9C2C-7DAF4CDE72B1@oracle.com> References: <31AADC23-15A1-4D9B-B0A3-0DD1AAEA34B5@oracle.com> <55379562.6070200@oracle.com> <0D2DF526-D4B2-494E-9C2C-7DAF4CDE72B1@oracle.com> Message-ID: <55379C1B.1090104@oracle.com> On 4/22/2015 8:40 PM, Vincent Ryan wrote: >>> >> BTW there are 3 less complex versions of this test which have not >>> >> reported any intermittent failures. >>> >> I can modify them too in a follow-up fix, if necessary. >>> >> >> > It is nice to get them fixed too, I think. > The other versions of this test are simpler and do not cycle through all the available JCE providers so > they are not exposed to this timing issue where the port is quickly re-requested before it is ready for use. > > OK. Xuelei From weijun.wang at oracle.com Wed Apr 22 14:51:44 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Apr 2015 22:51:44 +0800 Subject: [9] RFR: 8075007: Additional tests for krb5-related cipher suites with unbound server In-Reply-To: <553661B0.7050508@oracle.com> References: <553661B0.7050508@oracle.com> Message-ID: <5537B580.10209@oracle.com> Hi Artem These are splendid tests. So do they just all pass? :-) One question, does the policy file make any difference in UnboundSSLMultipleKeys.java and UnboundSSLPrincipalProperty.java? Thanks Max On 4/21/2015 10:41 PM, Artem Smotrakov wrote: > Hello, > > Please review a couple of new tests for krb5 cipher suites with unbound > server: > - tests check if an unbound server can handle connections only for > allowed service principals > - tests check if an unbound server picks up a correct key from keytab > - tests check if an unbound server uses a service principal from > "sun.security.krb5.principal" system property if specified > > I also added a helper method to KDC.java to check that a KDC instance is > up. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075007 > Webrev: http://cr.openjdk.java.net/~asmotrak/8075007/webrev.00/ > > Artem From weijun.wang at oracle.com Wed Apr 22 15:24:07 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Apr 2015 23:24:07 +0800 Subject: [9] RFR: 8048138: Tests for JAAS callbacks In-Reply-To: <55365D0E.2050808@oracle.com> References: <55365D0E.2050808@oracle.com> Message-ID: <5537BD17.6020302@oracle.com> Hi Artem In StandardCallbacks.java, you provide an array of callbacks with an unsupported one at the end, hoping all supported ones are processed before the last one fails. It is very natural for a LoginModule implementation to process them one by one in their original order (like what CustomLoginModule does) but I am not sure if this is a strict requirement. For example, what if it tries the last one first and in this case fails before trying all the others? Can you find any specification on it? Or maybe in a technote article? Another one: - SharedState: If the callback handler is not used, does the constructor without the argument work? Thanks Max On 4/21/2015 10:22 PM, Artem Smotrakov wrote: > Hello, > > Please review a couple of new tests for JAAS: > - StandardCallbacks.java is for standard JAAS callbacks (except > RealmCallback and RealmChoiceCallback since the test is not about Sasl, > and actually those two callback extends ChoiceCallback which is used in > the test) > - SharedState.java checks if a shared state is passed to login modules > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048138 > Webrev: http://cr.openjdk.java.net/~asmotrak/8048138/webrev.00/ > > Artem From rob.mckenna at oracle.com Wed Apr 22 16:21:22 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 22 Apr 2015 17:21:22 +0100 Subject: Kerberos Bug Introduced in d777e2918a77? In-Reply-To: References: Message-ID: <5537CA82.1060107@oracle.com> Hi Daniel, Thanks for the report, I'm cc'ing the security-dev alias. -Rob On 22/04/15 13:10, Daniel Jones wrote: > Hi all, > > Apologies if this is the wrong mailing list - please direct me to the > correct one if so. > > I believe I've found a bug in OpenJDK 1.8.0_40, introduced in commit > d777e2918a77: > http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java > > The change introduced on line 548 means that an authentication mechanism is > only accepted if the OID of the mechanism desired is the *first* in the > list of mechanisms specified as acceptable in the incoming ticket. > > In the case of my current client their service tickets are specifying 4 > acceptable mechanism OIDs, but the only available mechanism's OID appears > second on that list. So whilst the server *can *satisfy the ticket, the > code change on line 548 prevents this from happening. > > Using the same server code, the same Kerberos KDC, and OpenJDK 1.8.0_31, > everything works. Changing only the JDK results in the mechContext not > being properly populated, which in turn causes a NullPointerException from > some Spring Security Kerberos code. > > Has anyone else experienced this? > > From joe.darcy at oracle.com Wed Apr 22 17:02:57 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 22 Apr 2015 10:02:57 -0700 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <55375C73.7060001@oracle.com> References: <553703BC.1070504@oracle.com> <55375C73.7060001@oracle.com> Message-ID: <5537D441.1070204@oracle.com> Hi Daniel, On 4/22/2015 1:31 AM, Daniel Fuchs wrote: > On 22/04/15 04:13, Joseph D. Darcy wrote: >> One goal of marking the tests using randomness is to help root out some >> remaining intermittent test failures. If one of the randomness tests is >> observed to fail intermittently, if it has not already been updated to >> print out the random seed and be able to accept a particular seed when >> run, the test should be so modified so that future failures can log the >> seed value in hopes of reproducing the failure. > > Hi Joe, > > The following logging tests use UUID.randomUUID() to generate > a 'unique' file name in order to avoid possible collision if > these tests are run concurrently or if some files have been > left over from a previous run (some of these use %t - the temporary > directory - which has been known to cause intermittent > failure in those cases). > > So I believe that removing randomness, or attempting to > make it predictable, would in those specific cases make > those tests more prone to intermittent failures. > > In this light - should these tests still be tagged with > the @randomness keyword? > > test/java/util/logging/CheckZombieLockTest.java > test/java/util/logging/FileHandlerLongLimit.java > test/java/util/logging/FileHandlerPath.java > test/java/util/logging/FileHandlerPatternExceptions.java > test/java/util/logging/LogManager/Configuration/ParentLoggerWithHandlerGC.java > > The randomness label is just meant to be documentation and not pejorative. Its uses in the tests you identify it is more likely to increase rather than decrease stability. However, I still think it is appropriate to mark these tests for their behavior. Thanks, -Joe From weijun.wang at oracle.com Wed Apr 22 23:22:02 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 23 Apr 2015 07:22:02 +0800 Subject: Kerberos Bug Introduced in d777e2918a77? In-Reply-To: <5537CA82.1060107@oracle.com> References: <5537CA82.1060107@oracle.com> Message-ID: <55382D1A.8070702@oracle.com> Hi Daniel Thanks for the report. In fact, the bug behind the changeset you mentioned -- 8048194 -- was just meant to make your case work. Before that, the server blindly accepts the mechToken and process it no matter if the OID is supported. Now it first looks at the OID and accept the token if it supports the OID; otherwise, only the negotiated result (its supported OID) is sent back, and waits for the client sending the correct mechToken in the next round. It seems the logic above is not implemented correctly, can you show me the full stack of your NullPointerException? If it includes any sensitive info you can write me privately. Thanks Max On 4/23/2015 12:21 AM, Rob McKenna wrote: > Hi Daniel, > > Thanks for the report, I'm cc'ing the security-dev alias. > > -Rob > > On 22/04/15 13:10, Daniel Jones wrote: >> Hi all, >> >> Apologies if this is the wrong mailing list - please direct me to the >> correct one if so. >> >> I believe I've found a bug in OpenJDK 1.8.0_40, introduced in commit >> d777e2918a77: >> http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java >> >> >> The change introduced on line 548 means that an authentication >> mechanism is >> only accepted if the OID of the mechanism desired is the *first* in the >> list of mechanisms specified as acceptable in the incoming ticket. >> >> In the case of my current client their service tickets are specifying 4 >> acceptable mechanism OIDs, but the only available mechanism's OID appears >> second on that list. So whilst the server *can *satisfy the ticket, the >> code change on line 548 prevents this from happening. >> >> Using the same server code, the same Kerberos KDC, and OpenJDK 1.8.0_31, >> everything works. Changing only the JDK results in the mechContext not >> being properly populated, which in turn causes a NullPointerException >> from >> some Spring Security Kerberos code. >> >> Has anyone else experienced this? >> >> > From weijun.wang at oracle.com Thu Apr 23 00:58:21 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 23 Apr 2015 08:58:21 +0800 Subject: Kerberos Bug Introduced in d777e2918a77? In-Reply-To: <55382D1A.8070702@oracle.com> References: <5537CA82.1060107@oracle.com> <55382D1A.8070702@oracle.com> Message-ID: <553843AD.8050406@oracle.com> Hi Daniel I've read more about your bug report and know what's happening. You are proposing 2 OIDs, [1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2], 1st one being Microsoft's own krb5 OID and 2nd the standard one. Java only understands the 2nd one but before that changeset it blindly accepts the mechToken without looking at the OID. Since it's also krb5, the mechToken is processed correctly and everything goes on. After the changeset, it does not recognize the OID anymore and asks the client to send another mechToken with 1.2.840.113554.1.2.2. I believe a lot of people is using the Microsoft OID. I will see if it's possible to recognize both OIDs. On the other hand, your program has context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length); String user = context.getSrcName().toString(); which is not standard. The acceptSecContext call should be in a loop until a context is established, and then you can call getSrcName(). Can you try that? Hopefully after the client sees the server request for a 1.2.840.113554.1.2.2 mechToken it can send one and the server can go on. Thanks Max On 4/23/2015 7:22 AM, Weijun Wang wrote: > Hi Daniel > > Thanks for the report. > > In fact, the bug behind the changeset you mentioned -- 8048194 -- was > just meant to make your case work. Before that, the server blindly > accepts the mechToken and process it no matter if the OID is supported. > Now it first looks at the OID and accept the token if it supports the > OID; otherwise, only the negotiated result (its supported OID) is sent > back, and waits for the client sending the correct mechToken in the next > round. > > It seems the logic above is not implemented correctly, can you show me > the full stack of your NullPointerException? If it includes any > sensitive info you can write me privately. > > Thanks > Max > > On 4/23/2015 12:21 AM, Rob McKenna wrote: >> Hi Daniel, >> >> Thanks for the report, I'm cc'ing the security-dev alias. >> >> -Rob >> >> On 22/04/15 13:10, Daniel Jones wrote: >>> Hi all, >>> >>> Apologies if this is the wrong mailing list - please direct me to the >>> correct one if so. >>> >>> I believe I've found a bug in OpenJDK 1.8.0_40, introduced in commit >>> d777e2918a77: >>> http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java >>> >>> >>> >>> The change introduced on line 548 means that an authentication >>> mechanism is >>> only accepted if the OID of the mechanism desired is the *first* in the >>> list of mechanisms specified as acceptable in the incoming ticket. >>> >>> In the case of my current client their service tickets are specifying 4 >>> acceptable mechanism OIDs, but the only available mechanism's OID >>> appears >>> second on that list. So whilst the server *can *satisfy the ticket, the >>> code change on line 548 prevents this from happening. >>> >>> Using the same server code, the same Kerberos KDC, and OpenJDK 1.8.0_31, >>> everything works. Changing only the JDK results in the mechContext not >>> being properly populated, which in turn causes a NullPointerException >>> from >>> some Spring Security Kerberos code. >>> >>> Has anyone else experienced this? >>> >>> >> From xuelei.fan at oracle.com Thu Apr 23 01:30:14 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 23 Apr 2015 09:30:14 +0800 Subject: [JEP-219/JDK-8043758] Specification review request: Datagram Transport Layer Security (DTLS) Message-ID: <55384B26.7000804@oracle.com> Hi, I'm proposing the DTLS specification for JEP-219/JDK-8043758. Please review the specification update. Here is the description of the spec update: http://cr.openjdk.java.net/~xuelei/8043758.spec/spec.txt Here is the webrev of the API update: http://cr.openjdk.java.net/~xuelei/8043758.spec/webrev.latest/ I would greatly appreciate it if you could send me feedback on or before May 8, 2015. Thanks & Regards, Xuelei Fan From artem.smotrakov at oracle.com Thu Apr 23 06:18:14 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 23 Apr 2015 09:18:14 +0300 Subject: [9] RFR: 8048138: Tests for JAAS callbacks In-Reply-To: <5537BD17.6020302@oracle.com> References: <55365D0E.2050808@oracle.com> <5537BD17.6020302@oracle.com> Message-ID: <55388EA6.6030208@oracle.com> Hi Max, Please see inline. On 04/22/2015 06:24 PM, Weijun Wang wrote: > Hi Artem > > In StandardCallbacks.java, you provide an array of callbacks with an > unsupported one at the end, hoping all supported ones are processed > before the last one fails. It is very natural for a LoginModule > implementation to process them one by one in their original order > (like what CustomLoginModule does) but I am not sure if this is a > strict requirement. For example, what if it tries the last one first > and in this case fails before trying all the others? > > Can you find any specification on it? Or maybe in a technote article? Yes, the test relies on original order of callbacks. But CustomLoginModule calls a callback handler directly, and it doesn't seem that JAAS framework may affect the order. That's why I make the test rely on original order of callbacks. I think it is okay for test since we control both login module and callback handler. In real applications, a login module and handler may be provided by independent parties, and they should not rely on order of callback. > > Another one: > > - SharedState: If the callback handler is not used, does the > constructor without the argument work? The test uses DummyCallbackHandler that actually does nothing, but actually I forgot to call a callback handler in the login modules. I think it may be better it the test doesn't use a callback handler at all. According to the spec, it should work fine http://docs.oracle.com/javase/8/docs/api/javax/security/auth/login/LoginContext.html Please see an updated webrev: http://cr.openjdk.java.net/~asmotrak/8048138/webrev.01/ Artem > > Thanks > Max > > On 4/21/2015 10:22 PM, Artem Smotrakov wrote: >> Hello, >> >> Please review a couple of new tests for JAAS: >> - StandardCallbacks.java is for standard JAAS callbacks (except >> RealmCallback and RealmChoiceCallback since the test is not about Sasl, >> and actually those two callback extends ChoiceCallback which is used in >> the test) >> - SharedState.java checks if a shared state is passed to login modules >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048138 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8048138/webrev.00/ >> >> Artem From artem.smotrakov at oracle.com Thu Apr 23 06:30:08 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 23 Apr 2015 09:30:08 +0300 Subject: [9] RFR: 8075007: Additional tests for krb5-related cipher suites with unbound server In-Reply-To: <5537B580.10209@oracle.com> References: <553661B0.7050508@oracle.com> <5537B580.10209@oracle.com> Message-ID: <55389170.9080808@oracle.com> Hi Max, On 04/22/2015 05:51 PM, Weijun Wang wrote: > Hi Artem > > These are splendid tests. So do they just all pass? :-) Yes, fortunately they do :) > > One question, does the policy file make any difference in > UnboundSSLMultipleKeys.java and UnboundSSLPrincipalProperty.java? No, these two don't requite the policy file. But they still need to be run in othervm mode since they use system properties. I updated these two tests not to use the policy file http://cr.openjdk.java.net/~asmotrak/8075007/webrev.01/ Artem > > Thanks > Max > > On 4/21/2015 10:41 PM, Artem Smotrakov wrote: >> Hello, >> >> Please review a couple of new tests for krb5 cipher suites with unbound >> server: >> - tests check if an unbound server can handle connections only for >> allowed service principals >> - tests check if an unbound server picks up a correct key from keytab >> - tests check if an unbound server uses a service principal from >> "sun.security.krb5.principal" system property if specified >> >> I also added a helper method to KDC.java to check that a KDC instance is >> up. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075007 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8075007/webrev.00/ >> >> Artem From weijun.wang at oracle.com Thu Apr 23 08:18:45 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 23 Apr 2015 16:18:45 +0800 Subject: [9] RFR: 8075007: Additional tests for krb5-related cipher suites with unbound server In-Reply-To: <55389170.9080808@oracle.com> References: <553661B0.7050508@oracle.com> <5537B580.10209@oracle.com> <55389170.9080808@oracle.com> Message-ID: <5538AAE5.7010701@oracle.com> One question: As for the 3 boolean flags you added to KDC.java (BTW, maybe "consumer"?), is it possible to wait for them to be true right at the end of the startServer() method? I believe all the current tests can actually benefit from this. --Max On 4/23/2015 2:30 PM, Artem Smotrakov wrote: > Hi Max, > > On 04/22/2015 05:51 PM, Weijun Wang wrote: >> Hi Artem >> >> These are splendid tests. So do they just all pass? :-) > Yes, fortunately they do :) >> >> One question, does the policy file make any difference in >> UnboundSSLMultipleKeys.java and UnboundSSLPrincipalProperty.java? > No, these two don't requite the policy file. But they still need to be > run in othervm mode since they use system properties. I updated these > two tests not to use the policy file > > http://cr.openjdk.java.net/~asmotrak/8075007/webrev.01/ > > Artem >> >> Thanks >> Max >> >> On 4/21/2015 10:41 PM, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review a couple of new tests for krb5 cipher suites with unbound >>> server: >>> - tests check if an unbound server can handle connections only for >>> allowed service principals >>> - tests check if an unbound server picks up a correct key from keytab >>> - tests check if an unbound server uses a service principal from >>> "sun.security.krb5.principal" system property if specified >>> >>> I also added a helper method to KDC.java to check that a KDC instance is >>> up. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075007 >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8075007/webrev.00/ >>> >>> Artem > From weijun.wang at oracle.com Thu Apr 23 08:21:40 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 23 Apr 2015 16:21:40 +0800 Subject: [9] RFR: 8048138: Tests for JAAS callbacks In-Reply-To: <55388EA6.6030208@oracle.com> References: <55365D0E.2050808@oracle.com> <5537BD17.6020302@oracle.com> <55388EA6.6030208@oracle.com> Message-ID: <5538AB94.1060206@oracle.com> All codes fine. Thanks Max On 4/23/2015 2:18 PM, Artem Smotrakov wrote: > Hi Max, > > Please see inline. > > On 04/22/2015 06:24 PM, Weijun Wang wrote: >> Hi Artem >> >> In StandardCallbacks.java, you provide an array of callbacks with an >> unsupported one at the end, hoping all supported ones are processed >> before the last one fails. It is very natural for a LoginModule >> implementation to process them one by one in their original order >> (like what CustomLoginModule does) but I am not sure if this is a >> strict requirement. For example, what if it tries the last one first >> and in this case fails before trying all the others? >> >> Can you find any specification on it? Or maybe in a technote article? > Yes, the test relies on original order of callbacks. But > CustomLoginModule calls a callback handler directly, and it doesn't seem > that JAAS framework may affect the order. That's why I make the test > rely on original order of callbacks. I think it is okay for test since > we control both login module and callback handler. In real applications, > a login module and handler may be provided by independent parties, and > they should not rely on order of callback. >> >> Another one: >> >> - SharedState: If the callback handler is not used, does the >> constructor without the argument work? > The test uses DummyCallbackHandler that actually does nothing, but > actually I forgot to call a callback handler in the login modules. I > think it may be better it the test doesn't use a callback handler at > all. According to the spec, it should work fine > > http://docs.oracle.com/javase/8/docs/api/javax/security/auth/login/LoginContext.html > > > Please see an updated webrev: > > http://cr.openjdk.java.net/~asmotrak/8048138/webrev.01/ > > Artem >> >> Thanks >> Max >> >> On 4/21/2015 10:22 PM, Artem Smotrakov wrote: >>> Hello, >>> >>> Please review a couple of new tests for JAAS: >>> - StandardCallbacks.java is for standard JAAS callbacks (except >>> RealmCallback and RealmChoiceCallback since the test is not about Sasl, >>> and actually those two callback extends ChoiceCallback which is used in >>> the test) >>> - SharedState.java checks if a shared state is passed to login modules >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048138 >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8048138/webrev.00/ >>> >>> Artem > From artem.smotrakov at oracle.com Thu Apr 23 10:31:33 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 23 Apr 2015 13:31:33 +0300 Subject: [9] RFR: 8075007: Additional tests for krb5-related cipher suites with unbound server In-Reply-To: <5538AAE5.7010701@oracle.com> References: <553661B0.7050508@oracle.com> <5537B580.10209@oracle.com> <55389170.9080808@oracle.com> <5538AAE5.7010701@oracle.com> Message-ID: <5538CA05.5070309@oracle.com> Agree. Please see an updated webrev: http://cr.openjdk.java.net/~asmotrak/8075007/webrev.02/ Artem On 04/23/2015 11:18 AM, Weijun Wang wrote: > One question: > > As for the 3 boolean flags you added to KDC.java (BTW, maybe > "consumer"?), is it possible to wait for them to be true right at the > end of the startServer() method? I believe all the current tests can > actually benefit from this. > > --Max > > On 4/23/2015 2:30 PM, Artem Smotrakov wrote: >> Hi Max, >> >> On 04/22/2015 05:51 PM, Weijun Wang wrote: >>> Hi Artem >>> >>> These are splendid tests. So do they just all pass? :-) >> Yes, fortunately they do :) >>> >>> One question, does the policy file make any difference in >>> UnboundSSLMultipleKeys.java and UnboundSSLPrincipalProperty.java? >> No, these two don't requite the policy file. But they still need to be >> run in othervm mode since they use system properties. I updated these >> two tests not to use the policy file >> >> http://cr.openjdk.java.net/~asmotrak/8075007/webrev.01/ >> >> Artem >>> >>> Thanks >>> Max >>> >>> On 4/21/2015 10:41 PM, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> Please review a couple of new tests for krb5 cipher suites with >>>> unbound >>>> server: >>>> - tests check if an unbound server can handle connections only for >>>> allowed service principals >>>> - tests check if an unbound server picks up a correct key from keytab >>>> - tests check if an unbound server uses a service principal from >>>> "sun.security.krb5.principal" system property if specified >>>> >>>> I also added a helper method to KDC.java to check that a KDC >>>> instance is >>>> up. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075007 >>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8075007/webrev.00/ >>>> >>>> Artem >> From sean.mullan at oracle.com Thu Apr 23 12:19:33 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 23 Apr 2015 08:19:33 -0400 Subject: RFR 8072394: java.security.cert.PolicyQualifierInfo needs value-based equality In-Reply-To: <5522EA28.5070609@redhat.com> References: <54D0A628.3080404@redhat.com> <54DE53E9.7010200@oracle.com> <54DE5B96.9000704@redhat.com> <54E26B6C.3040202@oracle.com> <54E35086.7090408@redhat.com> <54E7B3D1.4070402@oracle.com> <54F4728E.7070405@redhat.com> <54F7454D.4050906@oracle.com> <5522EA28.5070609@redhat.com> Message-ID: <5538E355.6020101@oracle.com> On 04/06/2015 04:18 PM, Florian Weimer wrote: > On 03/04/2015 06:47 PM, Sean Mullan wrote: > >> I can take care of filing an internal CCC and will let you know when >> that is approved or if there are any questions. > > This new webrev incorporates feedback from the CCC: > > > > This needs additional tests, but I want to check first if the direction > is okay. This looks ok to me. Can you give the test a more descriptive name w/o the bugid in the name? --Sean > > The PolicyQualifierInfoSet class is needed because there is no existing > LinkedTreeSet class. I do not want to continue to use LinkedHashSet > because of the denial of service risk from hash collisions (this was not > a problem before because the hash was identity-based), and the cost of > computing hash codes even for single-element sets. > From weijun.wang at oracle.com Thu Apr 23 14:14:39 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 23 Apr 2015 22:14:39 +0800 Subject: Kerberos Bug Introduced in d777e2918a77? In-Reply-To: References: <5537CA82.1060107@oracle.com> <55382D1A.8070702@oracle.com> <553843AD.8050406@oracle.com> Message-ID: <5538FE4F.5030503@oracle.com> Hi Daniel Sorry for the trouble. On 4/23/2015 7:25 PM, Daniel Jones wrote: > Hi all, > > Thanks to everyone taking the time to look into this. > > Before I get into the detail of the technical issue, can anyone > postulate as to *how quickly fixes tend to make it into releases of > OpenJDK*? Are we talking days, weeks, or months? I'm just trying to > advise my client on the best mitigation strategy until the issue is > resolved. Oracle does not releases binaries for OpenJDK, you only get the source codes on http://hg.openjdk.java.net. Once we made a fix, the changeset will be there. So if you build your own JDK, that's quite fast. If you use Oracle JDK, it has a release schedule at https://www.java.com/en/download/faq/release_dates.xml So it's months. > > The Spring code in question actually changed this morning to throw a > more useful error: > https://github.com/spring-projects/spring-security-kerberos/commit/f046bd7c69d6dad74eb06a7651cd68060b31ff6f > > On the other hand, your program has > context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length); > String user = context.getSrcName().toString(); > which is not standard. The acceptSecContext call should be in a loop > until a context is established, and then you can call getSrcName(). If you look at the class spec in http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/debb4ce14251/src/share/classes/org/ietf/jgss/GSSContext.java the formal context establishment should be like * while (!context.isEstablished()) { * inToken = readToken(); * outToken = context.acceptSecContext(inToken, 0, * inToken.length); * // send output token if generated * if (outToken != null) * sendToken(outToken); * } In your case, before 8048194, it just happens that the while loop only runs once. What is the client here? A browser? On the other hand, I am looking at your code and see if there is a workaround. Can you capture some packets and send to me? Especially I'd like the content of "kerberosTicket" in byte[] responseToken = context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length); In my experiment, the first 48 bytes look like this: 0000: 60 82 02 2D 06 06 2B 06 01 05 05 02 A0 82 02 21 0010: 30 82 02 1D A0 18 30 16 06 09 2A 86 48 82 F7 12 0020: 01 02 02 06 09 2A 86 48 86 F7 12 01 02 02 A1 04 Here, the OIDs are the 11 bytes from 0x18 and 0x23 starting with 06 09. You can see the only difference between the 2 OIDs are 82 (at 0x1D) and 86 (at 0x28). If you swap them, Java will happily accept it. Please note this is only a workaround and the real fix should be inside JDK. If your packet is bigger the 2nd byte might be 83 and you need to look a bit further for the OIDs (still starting with 06 09). Thanks Max > > > I'm not sure that this would work. I'm not at all familiar with what is > best practice in handling Kerberos tickets, but let me explain what > happens at present in u40: > > 1. Spring's SunJaasKerberosTicketValidator gets a GSSContextImpl, and > calls acceptSecContext on it. > 2. The GSSContextImpl calls an overloaded accetSecContext method, which > successfully creates a SpNegoContext and assigns it as the mechCtxt > member. > 3. GSSContextImpl#acceptSecContext then calls > SpNegoContext#acceptSecContext > 4. In SpNegoContext#acceptSecContext we have the new functionality that > only looks at the top item of the list of OIDs from the service ticket. > 5. The inner mechContext of the SpNegoContext is not set. > 6. We return back to the Spring code, with a GSSContextImpl wrapping a > SpNegoContext > 7. Spring calls GSSContextImpl#getSrcName(), which delegates to > SpNegoContext#getSrcName(), which returns null as its mechContext > member is null. Yes. > > > Spring passes the whole ticket into GSSContextImpl, and doesn't know > about OIDs and the list of acceptable mechanisms. It seems like it's a > responsibility of either SpNegoContext or GSSContextImpl to know about > this list and iterate over it. Yes. Unfortunately Java does not understand that 1st OID now. > > If the Spring code were to attempt a repeat, how should it know that the > inner context was not set? What action should it perform next? It's > passed in the ticket it knows about, and got back a populated byte[], > without any exceptions. What would it use to determine that one of the > side affects of GSSContextImpl#acceptSecContext hasn't succeeded? Like what I quoted above, loop until context.isEstablished() is true. Of course, this means the client side must also coded formally to loop on its side. I don't know what the client is and not sure if its application protocol has this loop defined. > > Does the above make sense? Please do get in touch if I an provide any > other assistance in helping with the issue, and thanks again to everyone > looking into it. Thanks. > > > > On Thu, Apr 23, 2015 at 1:58 AM, Weijun Wang > wrote: > > Hi Daniel > > I've read more about your bug report and know what's happening. > > You are proposing 2 OIDs, [1.2.840.48018.1.2.2, > 1.2.840.113554.1.2.2], 1st one being Microsoft's own krb5 OID and > 2nd the standard one. Java only understands the 2nd one but before > that changeset it blindly accepts the mechToken without looking at > the OID. Since it's also krb5, the mechToken is processed correctly > and everything goes on. After the changeset, it does not recognize > the OID anymore and asks the client to send another mechToken with > 1.2.840.113554.1.2.2. > > I believe a lot of people is using the Microsoft OID. I will see if > it's possible to recognize both OIDs. > > On the other hand, your program has > > context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length); > String user = context.getSrcName().toString(); > > which is not standard. The acceptSecContext call should be in a loop > until a context is established, and then you can call getSrcName(). > Can you try that? Hopefully after the client sees the server request > for a 1.2.840.113554.1.2.2 mechToken it can send one and the server > can go on. > > Thanks > Max > > > On 4/23/2015 7:22 AM, Weijun Wang wrote: > > Hi Daniel > > Thanks for the report. > > In fact, the bug behind the changeset you mentioned -- 8048194 > -- was > just meant to make your case work. Before that, the server blindly > accepts the mechToken and process it no matter if the OID is > supported. > Now it first looks at the OID and accept the token if it > supports the > OID; otherwise, only the negotiated result (its supported OID) > is sent > back, and waits for the client sending the correct mechToken in > the next > round. > > It seems the logic above is not implemented correctly, can you > show me > the full stack of your NullPointerException? If it includes any > sensitive info you can write me privately. > > Thanks > Max > > On 4/23/2015 12:21 AM, Rob McKenna wrote: > > Hi Daniel, > > Thanks for the report, I'm cc'ing the security-dev alias. > > -Rob > > On 22/04/15 13:10, Daniel Jones wrote: > > Hi all, > > Apologies if this is the wrong mailing list - please > direct me to the > correct one if so. > > I believe I've found a bug in OpenJDK 1.8.0_40, > introduced in commit > d777e2918a77: > http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java > > > > The change introduced on line 548 means that an > authentication > mechanism is > only accepted if the OID of the mechanism desired is the > *first* in the > list of mechanisms specified as acceptable in the > incoming ticket. > > In the case of my current client their service tickets > are specifying 4 > acceptable mechanism OIDs, but the only available > mechanism's OID > appears > second on that list. So whilst the server *can *satisfy > the ticket, the > code change on line 548 prevents this from happening. > > Using the same server code, the same Kerberos KDC, and > OpenJDK 1.8.0_31, > everything works. Changing only the JDK results in the > mechContext not > being properly populated, which in turn causes a > NullPointerException > from > some Spring Security Kerberos code. > > Has anyone else experienced this? > > > > > > > -- > Regards, > > Daniel Jones > EngineerBetter.com From alexander.v.stepanov at oracle.com Thu Apr 23 16:22:30 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Thu, 23 Apr 2015 19:22:30 +0300 Subject: RFR [9] 8078528: clean out tidy warnings from security.auth Message-ID: <55391C46.6080301@oracle.com> Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8078528/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8078528 Just some HTML markup cleanup for docs. Thanks, Alexander From daniel.jones at engineerbetter.com Thu Apr 23 11:25:32 2015 From: daniel.jones at engineerbetter.com (Daniel Jones) Date: Thu, 23 Apr 2015 12:25:32 +0100 Subject: Kerberos Bug Introduced in d777e2918a77? In-Reply-To: <553843AD.8050406@oracle.com> References: <5537CA82.1060107@oracle.com> <55382D1A.8070702@oracle.com> <553843AD.8050406@oracle.com> Message-ID: Hi all, Thanks to everyone taking the time to look into this. Before I get into the detail of the technical issue, can anyone postulate as to *how quickly fixes tend to make it into releases of OpenJDK*? Are we talking days, weeks, or months? I'm just trying to advise my client on the best mitigation strategy until the issue is resolved. The Spring code in question actually changed this morning to throw a more useful error: https://github.com/spring-projects/spring-security-kerberos/commit/f046bd7c69d6dad74eb06a7651cd68060b31ff6f On the other hand, your program has > context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length); > String user = context.getSrcName().toString(); > which is not standard. The acceptSecContext call should be in a loop until > a context is established, and then you can call getSrcName(). I'm not sure that this would work. I'm not at all familiar with what is best practice in handling Kerberos tickets, but let me explain what happens at present in u40: 1. Spring's SunJaasKerberosTicketValidator gets a GSSContextImpl, and calls acceptSecContext on it. 2. The GSSContextImpl calls an overloaded accetSecContext method, which successfully creates a SpNegoContext and assigns it as the mechCtxt member. 3. GSSContextImpl#acceptSecContext then calls SpNegoContext#acceptSecContext 4. In SpNegoContext#acceptSecContext we have the new functionality that only looks at the top item of the list of OIDs from the service ticket. 5. The inner mechContext of the SpNegoContext is not set. 6. We return back to the Spring code, with a GSSContextImpl wrapping a SpNegoContext 7. Spring calls GSSContextImpl#getSrcName(), which delegates to SpNegoContext#getSrcName(), which returns null as its mechContext member is null. Spring passes the whole ticket into GSSContextImpl, and doesn't know about OIDs and the list of acceptable mechanisms. It seems like it's a responsibility of either SpNegoContext or GSSContextImpl to know about this list and iterate over it. If the Spring code were to attempt a repeat, how should it know that the inner context was not set? What action should it perform next? It's passed in the ticket it knows about, and got back a populated byte[], without any exceptions. What would it use to determine that one of the side affects of GSSContextImpl#acceptSecContext hasn't succeeded? Does the above make sense? Please do get in touch if I an provide any other assistance in helping with the issue, and thanks again to everyone looking into it. On Thu, Apr 23, 2015 at 1:58 AM, Weijun Wang wrote: > Hi Daniel > > I've read more about your bug report and know what's happening. > > You are proposing 2 OIDs, [1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2], 1st > one being Microsoft's own krb5 OID and 2nd the standard one. Java only > understands the 2nd one but before that changeset it blindly accepts the > mechToken without looking at the OID. Since it's also krb5, the mechToken > is processed correctly and everything goes on. After the changeset, it does > not recognize the OID anymore and asks the client to send another mechToken > with 1.2.840.113554.1.2.2. > > I believe a lot of people is using the Microsoft OID. I will see if it's > possible to recognize both OIDs. > > On the other hand, your program has > > context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length); > String user = context.getSrcName().toString(); > > which is not standard. The acceptSecContext call should be in a loop until > a context is established, and then you can call getSrcName(). Can you try > that? Hopefully after the client sees the server request for a > 1.2.840.113554.1.2.2 mechToken it can send one and the server can go on. > > Thanks > Max > > > On 4/23/2015 7:22 AM, Weijun Wang wrote: > >> Hi Daniel >> >> Thanks for the report. >> >> In fact, the bug behind the changeset you mentioned -- 8048194 -- was >> just meant to make your case work. Before that, the server blindly >> accepts the mechToken and process it no matter if the OID is supported. >> Now it first looks at the OID and accept the token if it supports the >> OID; otherwise, only the negotiated result (its supported OID) is sent >> back, and waits for the client sending the correct mechToken in the next >> round. >> >> It seems the logic above is not implemented correctly, can you show me >> the full stack of your NullPointerException? If it includes any >> sensitive info you can write me privately. >> >> Thanks >> Max >> >> On 4/23/2015 12:21 AM, Rob McKenna wrote: >> >>> Hi Daniel, >>> >>> Thanks for the report, I'm cc'ing the security-dev alias. >>> >>> -Rob >>> >>> On 22/04/15 13:10, Daniel Jones wrote: >>> >>>> Hi all, >>>> >>>> Apologies if this is the wrong mailing list - please direct me to the >>>> correct one if so. >>>> >>>> I believe I've found a bug in OpenJDK 1.8.0_40, introduced in commit >>>> d777e2918a77: >>>> >>>> http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java >>>> >>>> >>>> >>>> The change introduced on line 548 means that an authentication >>>> mechanism is >>>> only accepted if the OID of the mechanism desired is the *first* in the >>>> list of mechanisms specified as acceptable in the incoming ticket. >>>> >>>> In the case of my current client their service tickets are specifying 4 >>>> acceptable mechanism OIDs, but the only available mechanism's OID >>>> appears >>>> second on that list. So whilst the server *can *satisfy the ticket, the >>>> code change on line 548 prevents this from happening. >>>> >>>> Using the same server code, the same Kerberos KDC, and OpenJDK 1.8.0_31, >>>> everything works. Changing only the JDK results in the mechContext not >>>> being properly populated, which in turn causes a NullPointerException >>>> from >>>> some Spring Security Kerberos code. >>>> >>>> Has anyone else experienced this? >>>> >>>> >>>> >>> -- Regards, Daniel Jones EngineerBetter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.jones at engineerbetter.com Thu Apr 23 13:51:47 2015 From: daniel.jones at engineerbetter.com (Daniel Jones) Date: Thu, 23 Apr 2015 14:51:47 +0100 Subject: Kerberos Bug Introduced in d777e2918a77? In-Reply-To: References: <5537CA82.1060107@oracle.com> <55382D1A.8070702@oracle.com> <553843AD.8050406@oracle.com> Message-ID: Hi all, FYI We just tried switching to Oracle JRE u45, and the same behaviour is exhibited there. This is a bit of a problem for my client, as they can't use Java and Kerberos whilst still being able to satisfy their security department's policy regarding zero-day bugs. If a new patch gets released for a security issue, we won't be able to adopt it. On Thu, Apr 23, 2015 at 12:25 PM, Daniel Jones < daniel.jones at engineerbetter.com> wrote: > Hi all, > > Thanks to everyone taking the time to look into this. > > Before I get into the detail of the technical issue, can anyone postulate > as to *how quickly fixes tend to make it into releases of OpenJDK*? Are > we talking days, weeks, or months? I'm just trying to advise my client on > the best mitigation strategy until the issue is resolved. > > The Spring code in question actually changed this morning to throw a more > useful error: > https://github.com/spring-projects/spring-security-kerberos/commit/f046bd7c69d6dad74eb06a7651cd68060b31ff6f > > On the other hand, your program has >> context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length); >> String user = context.getSrcName().toString(); >> which is not standard. The acceptSecContext call should be in a loop >> until a context is established, and then you can call getSrcName(). > > > I'm not sure that this would work. I'm not at all familiar with what is > best practice in handling Kerberos tickets, but let me explain what happens > at present in u40: > > > 1. Spring's SunJaasKerberosTicketValidator gets a GSSContextImpl, and > calls acceptSecContext on it. > 2. The GSSContextImpl calls an overloaded accetSecContext method, > which successfully creates a SpNegoContext and assigns it as the mechCtxt > member. > 3. GSSContextImpl#acceptSecContext then calls > SpNegoContext#acceptSecContext > 4. In SpNegoContext#acceptSecContext we have the new functionality > that only looks at the top item of the list of OIDs from the service > ticket. > 5. The inner mechContext of the SpNegoContext is not set. > 6. We return back to the Spring code, with a GSSContextImpl wrapping a > SpNegoContext > 7. Spring calls GSSContextImpl#getSrcName(), which delegates to > SpNegoContext#getSrcName(), which returns null as its mechContext member is > null. > > > Spring passes the whole ticket into GSSContextImpl, and doesn't know about > OIDs and the list of acceptable mechanisms. It seems like it's a > responsibility of either SpNegoContext or GSSContextImpl to know about this > list and iterate over it. > > If the Spring code were to attempt a repeat, how should it know that the > inner context was not set? What action should it perform next? It's passed > in the ticket it knows about, and got back a populated byte[], without any > exceptions. What would it use to determine that one of the side affects of > GSSContextImpl#acceptSecContext hasn't succeeded? > > Does the above make sense? Please do get in touch if I an provide any > other assistance in helping with the issue, and thanks again to everyone > looking into it. > > > > On Thu, Apr 23, 2015 at 1:58 AM, Weijun Wang > wrote: > >> Hi Daniel >> >> I've read more about your bug report and know what's happening. >> >> You are proposing 2 OIDs, [1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2], >> 1st one being Microsoft's own krb5 OID and 2nd the standard one. Java only >> understands the 2nd one but before that changeset it blindly accepts the >> mechToken without looking at the OID. Since it's also krb5, the mechToken >> is processed correctly and everything goes on. After the changeset, it does >> not recognize the OID anymore and asks the client to send another mechToken >> with 1.2.840.113554.1.2.2. >> >> I believe a lot of people is using the Microsoft OID. I will see if it's >> possible to recognize both OIDs. >> >> On the other hand, your program has >> >> context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length); >> String user = context.getSrcName().toString(); >> >> which is not standard. The acceptSecContext call should be in a loop >> until a context is established, and then you can call getSrcName(). Can you >> try that? Hopefully after the client sees the server request for a >> 1.2.840.113554.1.2.2 mechToken it can send one and the server can go on. >> >> Thanks >> Max >> >> >> On 4/23/2015 7:22 AM, Weijun Wang wrote: >> >>> Hi Daniel >>> >>> Thanks for the report. >>> >>> In fact, the bug behind the changeset you mentioned -- 8048194 -- was >>> just meant to make your case work. Before that, the server blindly >>> accepts the mechToken and process it no matter if the OID is supported. >>> Now it first looks at the OID and accept the token if it supports the >>> OID; otherwise, only the negotiated result (its supported OID) is sent >>> back, and waits for the client sending the correct mechToken in the next >>> round. >>> >>> It seems the logic above is not implemented correctly, can you show me >>> the full stack of your NullPointerException? If it includes any >>> sensitive info you can write me privately. >>> >>> Thanks >>> Max >>> >>> On 4/23/2015 12:21 AM, Rob McKenna wrote: >>> >>>> Hi Daniel, >>>> >>>> Thanks for the report, I'm cc'ing the security-dev alias. >>>> >>>> -Rob >>>> >>>> On 22/04/15 13:10, Daniel Jones wrote: >>>> >>>>> Hi all, >>>>> >>>>> Apologies if this is the wrong mailing list - please direct me to the >>>>> correct one if so. >>>>> >>>>> I believe I've found a bug in OpenJDK 1.8.0_40, introduced in commit >>>>> d777e2918a77: >>>>> >>>>> http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java >>>>> >>>>> >>>>> >>>>> The change introduced on line 548 means that an authentication >>>>> mechanism is >>>>> only accepted if the OID of the mechanism desired is the *first* in the >>>>> list of mechanisms specified as acceptable in the incoming ticket. >>>>> >>>>> In the case of my current client their service tickets are specifying 4 >>>>> acceptable mechanism OIDs, but the only available mechanism's OID >>>>> appears >>>>> second on that list. So whilst the server *can *satisfy the ticket, the >>>>> code change on line 548 prevents this from happening. >>>>> >>>>> Using the same server code, the same Kerberos KDC, and OpenJDK >>>>> 1.8.0_31, >>>>> everything works. Changing only the JDK results in the mechContext not >>>>> being properly populated, which in turn causes a NullPointerException >>>>> from >>>>> some Spring Security Kerberos code. >>>>> >>>>> Has anyone else experienced this? >>>>> >>>>> >>>>> >>>> > > > -- > Regards, > > Daniel Jones > EngineerBetter.com > -- Regards, Daniel Jones EngineerBetter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Apr 23 20:11:11 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 23 Apr 2015 16:11:11 -0400 Subject: [9] RFR 8076535: Deprecate the com.sun.jarsigner package In-Reply-To: <553158F4.40205@oracle.com> References: <553158F4.40205@oracle.com> Message-ID: <553951DF.3090002@oracle.com> This looks fine but you should wait until JDK-8078318 (Public API for jarsigner) is resolved, and then change the places where it says "{@code JarSigner}" to an "{@link JarSigner}" (using the correct package name/syntax). Add an "is blocked by" link. Also a few other comments: 1. Add a noreg label to the bug 2. File a separate docs bug and target it to 9 to update the jarsigner man page to document that the options are deprecated. Also add a "securitydocs" label to that bug. 3. Add a "release-notes=yes" label with a few sentences describing what has been deprecated for the release notes. --Sean On 04/17/2015 03:03 PM, Jason Uh wrote: > Please review this change to deprecate the com.sun.jarsigner package. > > webrev: http://cr.openjdk.java.net/~juh/8076535/00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8076535 > > Thanks, > Jason From joe.darcy at oracle.com Thu Apr 23 22:34:03 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 23 Apr 2015 15:34:03 -0700 Subject: JDK 9 RFR of JDK-8078468: Update security libraries to use diamond with anonymous classes Message-ID: <5539735B.2060209@oracle.com> Hello, Please review the straightforward changes to address JDK-8078468: Update security libraries to use diamond with anonymous classes http://cr.openjdk.java.net/~darcy/8078468.0/ This patch combines two kinds of updates; the first to use traditional diamond available since JDK 7 and the second to use diamond with anonymous classes, a feature now available in JDK 9. As with core libraries (JDK-8078467), many of the uses of the new feature are locations where "new PrivilegedAction" is used. The diamond location candidates were found using a finder built into javac. Thanks, -Joe From valerie.peng at oracle.com Thu Apr 23 22:40:00 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 23 Apr 2015 15:40:00 -0700 Subject: [9] RFR 8038084: CertStore needs a way to add new CertStore types Message-ID: <553974C0.6080004@oracle.com> Hi Sean, Can you please review the following fix? Besides the new API and provider, I have also updated LDAPCertStoreParameters to mention the new URICertStoreParameters class per your suggestions. 8038084: CertStore needs a way to add new CertStore types Webrev: http://cr.openjdk.java.net/~valeriep/8038084/webrev.00/ CCC: http://ccc.us.oracle.com/8038084 Thanks, Valerie From weijun.wang at oracle.com Fri Apr 24 00:33:13 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 24 Apr 2015 08:33:13 +0800 Subject: JDK 9 RFR of JDK-8078468: Update security libraries to use diamond with anonymous classes In-Reply-To: <5539735B.2060209@oracle.com> References: <5539735B.2060209@oracle.com> Message-ID: <55398F49.7080901@oracle.com> Hi Joe The changes look good. I remember last time when Stuart updated JDK to use diamond there was a rule that if the assignment of a variable is a little far from its definition, then we don't use diamond. It seems we are not obeying it anymore? Thanks Max On 4/24/2015 6:34 AM, Joseph D. Darcy wrote: > Hello, > > Please review the straightforward changes to address > > JDK-8078468: Update security libraries to use diamond with > anonymous classes > http://cr.openjdk.java.net/~darcy/8078468.0/ > > This patch combines two kinds of updates; the first to use traditional > diamond available since JDK 7 and the second to use diamond with > anonymous classes, a feature now available in JDK 9. As with core > libraries (JDK-8078467), many of the uses of the new feature are > locations where "new PrivilegedAction" is used. > > The diamond location candidates were found using a finder built into javac. > > Thanks, > > -Joe From joe.darcy at oracle.com Fri Apr 24 01:45:29 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 23 Apr 2015 18:45:29 -0700 Subject: JDK 9 RFR of JDK-8078468: Update security libraries to use diamond with anonymous classes In-Reply-To: <55398F49.7080901@oracle.com> References: <5539735B.2060209@oracle.com> <55398F49.7080901@oracle.com> Message-ID: <5539A039.6080307@oracle.com> Hi Max, On 4/23/2015 5:33 PM, Weijun Wang wrote: > Hi Joe > > The changes look good. > > I remember last time when Stuart updated JDK to use diamond there was > a rule that if the assignment of a variable is a little far from its > definition, then we don't use diamond. It seems we are not obeying it > anymore? A few of the changes in the patch were of the form List foos = new ArrayList(); => List foos = new ArrayList<>(); but in most cases a type hint wasn't on the same line. When diamond was first introduced in JDK 7 circa 2010 - 2011, I think developers were less certain of when to use the feature. After a few years to get familiar with it, I think more aggressive diamond use is fine, especially since tooling support should already be in place to view the inferred type bounds if interested (I know NetBeans has long had such a feature). Thanks for the review. -Joe > > Thanks > Max > > On 4/24/2015 6:34 AM, Joseph D. Darcy wrote: >> Hello, >> >> Please review the straightforward changes to address >> >> JDK-8078468: Update security libraries to use diamond with >> anonymous classes >> http://cr.openjdk.java.net/~darcy/8078468.0/ >> >> This patch combines two kinds of updates; the first to use traditional >> diamond available since JDK 7 and the second to use diamond with >> anonymous classes, a feature now available in JDK 9. As with core >> libraries (JDK-8078467), many of the uses of the new feature are >> locations where "new PrivilegedAction" is used. >> >> The diamond location candidates were found using a finder built into >> javac. >> >> Thanks, >> >> -Joe From joe.darcy at oracle.com Fri Apr 24 01:54:17 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 23 Apr 2015 18:54:17 -0700 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <553703BC.1070504@oracle.com> References: <553703BC.1070504@oracle.com> Message-ID: <5539A249.7050105@oracle.com> Hello, Any additional comments on marking with tests in question with a "randomness" keyword? Thanks, -Joe On 4/21/2015 7:13 PM, Joseph D. Darcy wrote: > Hello, > > As the next step of implementing "Proposed new policies for JDK 9 > regression tests: tiered testing, intermittent failures, and > randomness" [1], please review this changeset which adds a > "randomness" jtreg keyword and tags 240 regression tests in the jdk > repository with the keyword: > > JDK-8078334: Mark regression tests using randomness > http://cr.openjdk.java.net/~darcy/8078334.0/ > > The update to test/TEST.ROOT is > > -# The list of keywords supported in the entire test suite > -keys=2d dnd i18n intermittent > +# The list of keywords supported in the entire test suite. The > +# "intermittent" keyword marks tests known to fail intermittently. > +# The "randomness" keyword marks tests using randomness with test > +# cases differing from run to run. (A test using a fixed random seed > +# would not count as "randomness" by this definition.) Extra care > +# should be taken to handle test failures of intermittent or > +# randomness tests. > + > +keys=2d dnd i18n intermittent randomness > > To find the affected files for this fix, I grepped over the regression > tests looking for "random" and verified if a random number generated > was used in a way where its values would differ from run to run. In > particular, as noted above, a java.util.Random random number generator > with a fixed seed did *not* qualify a test for the "randomness" keyword. > > The usual update to the files in this changeset is just > > + * @key randomness > > The updated tests are mostly in the core libs and security libs areas > with a few serviceability tests too. The list in this bug is not quite > exhaustive; I did not include rmi tests or client libraries tests. > > I verified that running > > jtreg ... -l -k:randomness . > > returns the expected number of tests and that the tests continue to > pass (or be ignored) when run. > > One goal of marking the tests using randomness is to help root out > some remaining intermittent test failures. If one of the randomness > tests is observed to fail intermittently, if it has not already been > updated to print out the random seed and be able to accept a > particular seed when run, the test should be so modified so that > future failures can log the seed value in hopes of reproducing the > failure. > > Brian Burkhalter has proactively made these sorts of changes to the > java.math tests earlier in JDK 9. [2] Since most of the randomness > tests don't have a history of instability (and due to the unexpected > large number of them!), I don't think it is necessary to proactively > update all the other tests without evidence of a history of failure. > However, when an otherwise unexplained failure is seen, I recommend > applying the sort of updates Brian has done in java.math to the > failing test(s). > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html > > [2] JDK-8074460, Always print seeds used in [Splittable]Random > instances in java.math tests, > https://bugs.openjdk.java.net/browse/JDK-8074460 From weijun.wang at oracle.com Fri Apr 24 03:29:26 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 24 Apr 2015 11:29:26 +0800 Subject: RFR 8078495: End time checking for native TGT is wrong Message-ID: <5539B896.6090006@oracle.com> Hi All Please review a fix at http://cr.openjdk.java.net/~weijun/8078495/webrev.00 which is essentially GetSystemTimeAsFileTime(&Now); EndTime.dwLowDateTime = msticket->EndTime.LowPart; EndTime.dwHighDateTime = msticket->EndTime.HighPart; - FileTimeToLocalFileTime(&EndTime, &LocalEndTime); - if (CompareFileTime(&Now, &LocalEndTime) < 0) { + if (CompareFileTime(&Now, &EndTime) < 0) { MSDN explicitly specifies that GetSystemTimeAsFileTime() [1] returns a UTC time. It is not very clear about KERB_EXTERNAL_TICKET [2], but according to my observation and the fact that it is directly converted to a KerberosTime string in the BuildKerberosTime() function, I believe it's also UTC. Anyway, the FILETIME structure is a little confusing, its spec [3] says it's an elapsed time from an MS epoch, so it should be timezone independent. But then there is FileTimeToLocalFileTime function which means it can be dependent. I believe the bug was not spotted earlier because when Java sees an expired ticket, it always tries to reacquire one, and returns a valid ticket anyway. (Fortunately it has not tried to validate the new ticket again). Thanks Max [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724397%28v=vs.85%29.aspx [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa378073%28v=vs.85%29.aspx [3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284%28v=vs.85%29.aspx From Alan.Bateman at oracle.com Fri Apr 24 05:58:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Apr 2015 06:58:09 +0100 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <5539A249.7050105@oracle.com> References: <553703BC.1070504@oracle.com> <5539A249.7050105@oracle.com> Message-ID: <5539DB71.2070605@oracle.com> On 24/04/2015 02:54, Joseph D. Darcy wrote: > Hello, > > Any additional comments on marking with tests in question with a > "randomness" keyword? > > Thanks, > > -Joe > I don't object to this keyword although I should say that most of the (apparent) randomness that I've seen hasn't been because of tests using Random but rather because of non-deterministic sequence of tests running in the same VM. The switch from othervm to agentvm a few years ago took a long time to weed out issues, same thing (even more) with -concurrency. Another source of apparent randomness is just having a large pool of machines and where machines are randomly selected to execute the tests. I agree with your comments that tests using Random should have report the seed and a have a way to re-run with the same value. It could help with some cases. One thing that isn't clear to me is how this keyword will be maintained. If I modify a test and replace the use of Random then I guess I need to remember to also remove this label. When I add a test that uses Random ... Just wondering if there is a tool to do the tests analysis, identify the use of specific APIs ,and help identify where the keyword might be missing or not needed. -Alan. From joe.darcy at oracle.com Fri Apr 24 18:04:24 2015 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 24 Apr 2015 11:04:24 -0700 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <5539DB71.2070605@oracle.com> References: <553703BC.1070504@oracle.com> <5539A249.7050105@oracle.com> <5539DB71.2070605@oracle.com> Message-ID: <553A85A8.7080207@oracle.com> On 4/23/2015 10:58 PM, Alan Bateman wrote: > On 24/04/2015 02:54, Joseph D. Darcy wrote: >> Hello, >> >> Any additional comments on marking with tests in question with a >> "randomness" keyword? >> >> Thanks, >> >> -Joe >> > I don't object to this keyword although I should say that most of the > (apparent) randomness that I've seen hasn't been because of tests > using Random but rather because of non-deterministic sequence of tests > running in the same VM. The switch from othervm to agentvm a few years > ago took a long time to weed out issues, same thing (even more) with > -concurrency. Another source of apparent randomness is just having a > large pool of machines and where machines are randomly selected to > execute the tests. > > I agree with your comments that tests using Random should have report > the seed and a have a way to re-run with the same value. It could help > with some cases. > > One thing that isn't clear to me is how this keyword will be > maintained. If I modify a test and replace the use of Random then I > guess I need to remember to also remove this label. When I add a test > that uses Random ... Just wondering if there is a tool to do the > tests analysis, identify the use of specific APIs ,and help identify > where the keyword might be missing or not needed. > The goal of the keyword is to enable better analysis of bug failures. We (still) have some intermittent test failures in the platform, some probably remaining from -concurrency issues and some due to inconsistent machine config issues on the test farms. However, there is reason to believe some of the tests also fail because of the use of randomness in the generation of test cases. For example, the test java/lang/invoke/MethodHandles/CatchExceptionTest.java fails about once every three hundred runs when the random cases it generates trigger an error condition. Setting the seed to known-bad value causes the test to fail consistently (JDK-8055269). I have suspicions some of our other intermittently failing tests are in a similar but undiagnosed situation. If a test uses randomness, I think the default assumed cause for a test failure should switch from environmental causes (bad machine config, etc.) to the random behavior. Therefore, when a random-using test fails, I think the failure analysis needs to include recording of the bad seed to see if the failure is reproducible / deterministic with a fixed seed value. I was very surprised by the large number of random-using tests in the JDK regression tests. Nearly all of these have been stably passing for many years. After the one-time cost of this large update to add the keywords, there would be a small amount of incremental test maintenance as new random-using tests were added or the randomness value of a test changed. However, I would expect whether or not a test used randomness to be a property of a test that very rarely changed. Thanks, -Joe From weijun.wang at oracle.com Sat Apr 25 04:19:37 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 25 Apr 2015 12:19:37 +0800 Subject: RFR 8078439: Kerberos auth fails if client proposes MS krb5 OID Message-ID: <553B15D9.2020609@oracle.com> Hi All Please review a fix at http://cr.openjdk.java.net/~weijun/8078439 This is a regression triggered by JDK-8048194. In SPNEGO, a client might send NegTokenInit with OIDs being {MS_KRB5_OID, KRB5_OID} along with a krb5 AP-REQ as mechToken. Java did not understand MS_KRB5_OID but before JDK-8048194 it blindly accepted the mechToken and everything just went on fine. After JDK-8048194, it rejects the unknown OID and cannot establish a security context. The fix adds a tweak to recognize the MS_KRB5_OID. *Ivan*: Can you try out the patch on jdk8u? Thanks Max From weijun.wang at oracle.com Sun Apr 26 02:21:01 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 26 Apr 2015 10:21:01 +0800 Subject: RFR 8078439: Kerberos auth fails if client proposes MS krb5 OID In-Reply-To: <553B15D9.2020609@oracle.com> References: <553B15D9.2020609@oracle.com> Message-ID: <553C4B8D.1010003@oracle.com> Hi All I've updated the webrev at http://cr.openjdk.java.net/~weijun/8078439/webrev.01/ The only change is @@ -548,6 +548,7 @@ "mechToken is missing"); } accept_token = GSS_acceptSecContext(mechToken); + mech_wanted = mechList[0]; } else { accept_token = null; } This means the supportedMech in response will be MS_KRB5_OID if it was the preferred mech in the request. In my webrev.00, I insisted using the "correct" OID because that was the way before JDK-8048194 and no one complained about it. Therefore I think the client side is able to find out that it's also a flavor of Kerberos 5 and has accepted it happily. So why fix it if it's not broken? However, after writing a SSPI client myself, I find out that it does not accept the "correct" ID and fail. Why didn't people notice that? My understanding is that until now a client that sends those OIDs has always been a browser, and this browser simply ignores the response if it already sees a "200 OK" HTTP status. Thanks Max On 4/25/2015 12:19 PM, Weijun Wang wrote: > Hi All > > Please review a fix at > > http://cr.openjdk.java.net/~weijun/8078439 > > This is a regression triggered by JDK-8048194. In SPNEGO, a client might > send NegTokenInit with OIDs being {MS_KRB5_OID, KRB5_OID} along with a > krb5 AP-REQ as mechToken. Java did not understand MS_KRB5_OID but before > JDK-8048194 it blindly accepted the mechToken and everything just went > on fine. After JDK-8048194, it rejects the unknown OID and cannot > establish a security context. > > The fix adds a tweak to recognize the MS_KRB5_OID. > > *Ivan*: > > Can you try out the patch on jdk8u? > > Thanks > Max From weijun.wang at oracle.com Mon Apr 27 12:51:24 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 27 Apr 2015 20:51:24 +0800 Subject: [9] RFR: 8075007: Additional tests for krb5-related cipher suites with unbound server In-Reply-To: <5538CA05.5070309@oracle.com> References: <553661B0.7050508@oracle.com> <5537B580.10209@oracle.com> <55389170.9080808@oracle.com> <5538AAE5.7010701@oracle.com> <5538CA05.5070309@oracle.com> Message-ID: <553E30CC.4050404@oracle.com> Looks fine. Thanks Max On 4/23/2015 6:31 PM, Artem Smotrakov wrote: > Agree. > > Please see an updated webrev: > > http://cr.openjdk.java.net/~asmotrak/8075007/webrev.02/ > > Artem > > On 04/23/2015 11:18 AM, Weijun Wang wrote: >> One question: >> >> As for the 3 boolean flags you added to KDC.java (BTW, maybe >> "consumer"?), is it possible to wait for them to be true right at the >> end of the startServer() method? I believe all the current tests can >> actually benefit from this. >> >> --Max >> >> On 4/23/2015 2:30 PM, Artem Smotrakov wrote: >>> Hi Max, >>> >>> On 04/22/2015 05:51 PM, Weijun Wang wrote: >>>> Hi Artem >>>> >>>> These are splendid tests. So do they just all pass? :-) >>> Yes, fortunately they do :) >>>> >>>> One question, does the policy file make any difference in >>>> UnboundSSLMultipleKeys.java and UnboundSSLPrincipalProperty.java? >>> No, these two don't requite the policy file. But they still need to be >>> run in othervm mode since they use system properties. I updated these >>> two tests not to use the policy file >>> >>> http://cr.openjdk.java.net/~asmotrak/8075007/webrev.01/ >>> >>> Artem >>>> >>>> Thanks >>>> Max >>>> >>>> On 4/21/2015 10:41 PM, Artem Smotrakov wrote: >>>>> Hello, >>>>> >>>>> Please review a couple of new tests for krb5 cipher suites with >>>>> unbound >>>>> server: >>>>> - tests check if an unbound server can handle connections only for >>>>> allowed service principals >>>>> - tests check if an unbound server picks up a correct key from keytab >>>>> - tests check if an unbound server uses a service principal from >>>>> "sun.security.krb5.principal" system property if specified >>>>> >>>>> I also added a helper method to KDC.java to check that a KDC >>>>> instance is >>>>> up. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075007 >>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8075007/webrev.00/ >>>>> >>>>> Artem >>> > From sean.mullan at oracle.com Mon Apr 27 14:11:33 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 27 Apr 2015 10:11:33 -0400 Subject: [9] RFR 8038084: CertStore needs a way to add new CertStore types In-Reply-To: <553974C0.6080004@oracle.com> References: <553974C0.6080004@oracle.com> Message-ID: <553E4395.2020807@oracle.com> Hi Valerie, Looks good, just a couple of comments: - URICertStoreParameters and JdkLdap.java: please remove the @author tags, this tag is generally discouraged as the information can be obtained from the source code history. * URICertStoreParameters Couple of re-wording suggestions: First sentence: "Parameters used as input for {@code CertStore} algorithms which use information contained in a URI to retrieve certificates and CRLs." Second sentence: s/an URI/a URI/ - add @Override tags to the toString and clone methods --Sean On 04/23/2015 06:40 PM, Valerie Peng wrote: > Hi Sean, > > Can you please review the following fix? > Besides the new API and provider, I have also updated > LDAPCertStoreParameters to mention the new URICertStoreParameters class > per your suggestions. > > 8038084: CertStore needs a way to add new CertStore types > Webrev: http://cr.openjdk.java.net/~valeriep/8038084/webrev.00/ > CCC: http://ccc.us.oracle.com/8038084 > > Thanks, > Valerie From alexander.v.stepanov at oracle.com Mon Apr 27 15:48:30 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Mon, 27 Apr 2015 18:48:30 +0300 Subject: RFR [9] 8078528: clean out tidy warnings from security.auth In-Reply-To: <55391C46.6080301@oracle.com> References: <55391C46.6080301@oracle.com> Message-ID: <553E5A4E.4000500@oracle.com> Sorry, just a reminder... Regards, Alexander On 23.04.2015 19:22, alexander stepanov wrote: > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8078528/webrev.00/ > > for > https://bugs.openjdk.java.net/browse/JDK-8078528 > > Just some HTML markup cleanup for docs. > > Thanks, > Alexander From weijun.wang at oracle.com Tue Apr 28 11:43:35 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 28 Apr 2015 19:43:35 +0800 Subject: Kerberos Bug Introduced in d777e2918a77? In-Reply-To: References: <5537CA82.1060107@oracle.com> <55382D1A.8070702@oracle.com> <553843AD.8050406@oracle.com> <5538FE4F.5030503@oracle.com> Message-ID: <553F7267.1060706@oracle.com> On 4/28/2015 6:14 PM, Daniel Jones wrote: > I noticed in the bug report Internet Explorer is mentioned. We see the > same behaviour with IE, Firefox and Chrome. Thanks. I've mentioned that in the comment. BTW, are you able to build jdk yourself? If so, can you try out the fix? http://cr.openjdk.java.net/~weijun/8078439/webrev.01/ It applies to both both jdk8u (without the module name in src path) and jdk9. I've done some local tests but it would be more confident if it works for your environment. Thanks Max From daniel.jones at engineerbetter.com Tue Apr 28 10:14:15 2015 From: daniel.jones at engineerbetter.com (Daniel Jones) Date: Tue, 28 Apr 2015 11:14:15 +0100 Subject: Kerberos Bug Introduced in d777e2918a77? In-Reply-To: <5538FE4F.5030503@oracle.com> References: <5537CA82.1060107@oracle.com> <55382D1A.8070702@oracle.com> <553843AD.8050406@oracle.com> <5538FE4F.5030503@oracle.com> Message-ID: Hi Weijun, Thanks for your help. Sorry it's taken me a while to reply, I was give other priorities over looking into this issue. Your suggested workaround does indeed work. I've switched elements of the byte array around with a debugger connected to the app, and that solves the problem. Thankfully the position of the elements in the ticket seems to be predictable. It's a brittle and low-level fix, but at least it works, so thanks! I noticed in the bug report Internet Explorer is mentioned. We see the same behaviour with IE, Firefox and Chrome. On Thu, Apr 23, 2015 at 3:14 PM, Weijun Wang wrote: > Hi Daniel > > Sorry for the trouble. > > On 4/23/2015 7:25 PM, Daniel Jones wrote: > >> Hi all, >> >> Thanks to everyone taking the time to look into this. >> >> Before I get into the detail of the technical issue, can anyone >> postulate as to *how quickly fixes tend to make it into releases of >> OpenJDK*? Are we talking days, weeks, or months? I'm just trying to >> advise my client on the best mitigation strategy until the issue is >> resolved. >> > > Oracle does not releases binaries for OpenJDK, you only get the source > codes on http://hg.openjdk.java.net. Once we made a fix, the changeset > will be there. So if you build your own JDK, that's quite fast. > > If you use Oracle JDK, it has a release schedule at > > https://www.java.com/en/download/faq/release_dates.xml > > So it's months. > > >> The Spring code in question actually changed this morning to throw a >> more useful error: >> >> https://github.com/spring-projects/spring-security-kerberos/commit/f046bd7c69d6dad74eb06a7651cd68060b31ff6f >> >> On the other hand, your program has >> context.acceptSecContext(kerberosTicket, 0, >> kerberosTicket.length); >> String user = context.getSrcName().toString(); >> which is not standard. The acceptSecContext call should be in a loop >> until a context is established, and then you can call getSrcName(). >> > > If you look at the class spec in > > > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/debb4ce14251/src/share/classes/org/ietf/jgss/GSSContext.java > > the formal context establishment should be like > > * while (!context.isEstablished()) { > * inToken = readToken(); > * outToken = context.acceptSecContext(inToken, 0, > * inToken.length); > * // send output token if generated > * if (outToken != null) > * sendToken(outToken); > * } > > In your case, before 8048194, it just happens that the while loop only > runs once. > > What is the client here? A browser? > > On the other hand, I am looking at your code and see if there is a > workaround. Can you capture some packets and send to me? Especially I'd > like the content of "kerberosTicket" in > > byte[] responseToken = context.acceptSecContext(kerberosTicket, 0, > kerberosTicket.length); > > In my experiment, the first 48 bytes look like this: > > 0000: 60 82 02 2D 06 06 2B 06 01 05 05 02 A0 82 02 21 > 0010: 30 82 02 1D A0 18 30 16 06 09 2A 86 48 82 F7 12 > 0020: 01 02 02 06 09 2A 86 48 86 F7 12 01 02 02 A1 04 > > Here, the OIDs are the 11 bytes from 0x18 and 0x23 starting with 06 09. > You can see the only difference between the 2 OIDs are 82 (at 0x1D) and 86 > (at 0x28). If you swap them, Java will happily accept it. > > Please note this is only a workaround and the real fix should be inside > JDK. If your packet is bigger the 2nd byte might be 83 and you need to look > a bit further for the OIDs (still starting with 06 09). > > Thanks > Max > > >> >> I'm not sure that this would work. I'm not at all familiar with what is >> best practice in handling Kerberos tickets, but let me explain what >> happens at present in u40: >> >> 1. Spring's SunJaasKerberosTicketValidator gets a GSSContextImpl, and >> calls acceptSecContext on it. >> 2. The GSSContextImpl calls an overloaded accetSecContext method, which >> successfully creates a SpNegoContext and assigns it as the mechCtxt >> member. >> 3. GSSContextImpl#acceptSecContext then calls >> SpNegoContext#acceptSecContext >> 4. In SpNegoContext#acceptSecContext we have the new functionality that >> only looks at the top item of the list of OIDs from the service >> ticket. >> 5. The inner mechContext of the SpNegoContext is not set. >> 6. We return back to the Spring code, with a GSSContextImpl wrapping a >> SpNegoContext >> 7. Spring calls GSSContextImpl#getSrcName(), which delegates to >> SpNegoContext#getSrcName(), which returns null as its mechContext >> member is null. >> > > Yes. > > >> >> Spring passes the whole ticket into GSSContextImpl, and doesn't know >> about OIDs and the list of acceptable mechanisms. It seems like it's a >> responsibility of either SpNegoContext or GSSContextImpl to know about >> this list and iterate over it. >> > > Yes. Unfortunately Java does not understand that 1st OID now. > > >> If the Spring code were to attempt a repeat, how should it know that the >> inner context was not set? What action should it perform next? It's >> passed in the ticket it knows about, and got back a populated byte[], >> without any exceptions. What would it use to determine that one of the >> side affects of GSSContextImpl#acceptSecContext hasn't succeeded? >> > > Like what I quoted above, loop until context.isEstablished() is true. Of > course, this means the client side must also coded formally to loop on its > side. I don't know what the client is and not sure if its application > protocol has this loop defined. > > >> Does the above make sense? Please do get in touch if I an provide any >> other assistance in helping with the issue, and thanks again to everyone >> looking into it. >> > > Thanks. > > >> >> >> On Thu, Apr 23, 2015 at 1:58 AM, Weijun Wang > > wrote: >> >> Hi Daniel >> >> I've read more about your bug report and know what's happening. >> >> You are proposing 2 OIDs, [1.2.840.48018.1.2.2, >> 1.2.840.113554.1.2.2], 1st one being Microsoft's own krb5 OID and >> 2nd the standard one. Java only understands the 2nd one but before >> that changeset it blindly accepts the mechToken without looking at >> the OID. Since it's also krb5, the mechToken is processed correctly >> and everything goes on. After the changeset, it does not recognize >> the OID anymore and asks the client to send another mechToken with >> 1.2.840.113554.1.2.2. >> >> I believe a lot of people is using the Microsoft OID. I will see if >> it's possible to recognize both OIDs. >> >> On the other hand, your program has >> >> context.acceptSecContext(kerberosTicket, 0, >> kerberosTicket.length); >> String user = context.getSrcName().toString(); >> >> which is not standard. The acceptSecContext call should be in a loop >> until a context is established, and then you can call getSrcName(). >> Can you try that? Hopefully after the client sees the server request >> for a 1.2.840.113554.1.2.2 mechToken it can send one and the server >> can go on. >> >> Thanks >> Max >> >> >> On 4/23/2015 7:22 AM, Weijun Wang wrote: >> >> Hi Daniel >> >> Thanks for the report. >> >> In fact, the bug behind the changeset you mentioned -- 8048194 >> -- was >> just meant to make your case work. Before that, the server blindly >> accepts the mechToken and process it no matter if the OID is >> supported. >> Now it first looks at the OID and accept the token if it >> supports the >> OID; otherwise, only the negotiated result (its supported OID) >> is sent >> back, and waits for the client sending the correct mechToken in >> the next >> round. >> >> It seems the logic above is not implemented correctly, can you >> show me >> the full stack of your NullPointerException? If it includes any >> sensitive info you can write me privately. >> >> Thanks >> Max >> >> On 4/23/2015 12:21 AM, Rob McKenna wrote: >> >> Hi Daniel, >> >> Thanks for the report, I'm cc'ing the security-dev alias. >> >> -Rob >> >> On 22/04/15 13:10, Daniel Jones wrote: >> >> Hi all, >> >> Apologies if this is the wrong mailing list - please >> direct me to the >> correct one if so. >> >> I believe I've found a bug in OpenJDK 1.8.0_40, >> introduced in commit >> d777e2918a77: >> >> http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java >> >> >> >> The change introduced on line 548 means that an >> authentication >> mechanism is >> only accepted if the OID of the mechanism desired is the >> *first* in the >> list of mechanisms specified as acceptable in the >> incoming ticket. >> >> In the case of my current client their service tickets >> are specifying 4 >> acceptable mechanism OIDs, but the only available >> mechanism's OID >> appears >> second on that list. So whilst the server *can *satisfy >> the ticket, the >> code change on line 548 prevents this from happening. >> >> Using the same server code, the same Kerberos KDC, and >> OpenJDK 1.8.0_31, >> everything works. Changing only the JDK results in the >> mechContext not >> being properly populated, which in turn causes a >> NullPointerException >> from >> some Spring Security Kerberos code. >> >> Has anyone else experienced this? >> >> >> >> >> >> >> -- >> Regards, >> >> Daniel Jones >> EngineerBetter.com >> > -- Regards, Daniel Jones EngineerBetter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.jones at engineerbetter.com Tue Apr 28 14:57:49 2015 From: daniel.jones at engineerbetter.com (Daniel Jones) Date: Tue, 28 Apr 2015 15:57:49 +0100 Subject: Kerberos Bug Introduced in d777e2918a77? In-Reply-To: <553F7267.1060706@oracle.com> References: <5537CA82.1060107@oracle.com> <55382D1A.8070702@oracle.com> <553843AD.8050406@oracle.com> <5538FE4F.5030503@oracle.com> <553F7267.1060706@oracle.com> Message-ID: Hi (is it Max or Weijun? I don't want to be rude!) I've read through the code changes and static analysis with my eyes suggests the change looks good. The client is not in the habit of building OpenJDK regularly, but there's no reason we can't give it a go. I had a look on http://hg.openjdk.java.net/jdk8u/ and I can't see the changeset anywhere. Is there a specific revision I should be looking for? I'm more familiar with Git than Mercurial, so may be missing something obvious. Cheers! On Tue, Apr 28, 2015 at 12:43 PM, Weijun Wang wrote: > > On 4/28/2015 6:14 PM, Daniel Jones wrote: > >> I noticed in the bug report Internet Explorer is mentioned. We see the >> same behaviour with IE, Firefox and Chrome. >> > > Thanks. I've mentioned that in the comment. > > BTW, are you able to build jdk yourself? If so, can you try out the fix? > > http://cr.openjdk.java.net/~weijun/8078439/webrev.01/ > > It applies to both both jdk8u (without the module name in src path) and > jdk9. > > I've done some local tests but it would be more confident if it works for > your environment. > > Thanks > Max > -- Regards, Daniel Jones EngineerBetter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Apr 28 22:55:37 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 28 Apr 2015 15:55:37 -0700 Subject: [9] RFR 8038084: CertStore needs a way to add new CertStore types In-Reply-To: <553E4395.2020807@oracle.com> References: <553974C0.6080004@oracle.com> <553E4395.2020807@oracle.com> Message-ID: <55400FE9.4000200@oracle.com> Sean, Thanks for the review! Webrev has been updated at: http://cr.openjdk.java.net/~valeriep/8038084/webrev.01/ Can you please review the CCC as well? It's http://ccc.us.oracle.com/8038084 Thanks again, Valerie On 4/27/2015 7:11 AM, Sean Mullan wrote: > Hi Valerie, > > Looks good, just a couple of comments: > > - URICertStoreParameters and JdkLdap.java: please remove the @author > tags, this tag is generally discouraged as the information can be > obtained from the source code history. > > * URICertStoreParameters > > Couple of re-wording suggestions: > > First sentence: > > "Parameters used as input for {@code CertStore} algorithms which use > information contained in a URI to retrieve certificates and CRLs." > > Second sentence: s/an URI/a URI/ > > - add @Override tags to the toString and clone methods > > --Sean > > On 04/23/2015 06:40 PM, Valerie Peng wrote: >> Hi Sean, >> >> Can you please review the following fix? >> Besides the new API and provider, I have also updated >> LDAPCertStoreParameters to mention the new URICertStoreParameters class >> per your suggestions. >> >> 8038084: CertStore needs a way to add new CertStore types >> Webrev: http://cr.openjdk.java.net/~valeriep/8038084/webrev.00/ >> CCC: http://ccc.us.oracle.com/8038084 >> >> Thanks, >> Valerie From joe.darcy at oracle.com Tue Apr 28 23:53:41 2015 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 28 Apr 2015 16:53:41 -0700 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <553A85A8.7080207@oracle.com> References: <553703BC.1070504@oracle.com> <5539A249.7050105@oracle.com> <5539DB71.2070605@oracle.com> <553A85A8.7080207@oracle.com> Message-ID: <55401D85.1090306@oracle.com> Hello, I'd like to get this changeset, or something close to it, pushed soon so we can start taking advantage of better failure triaging. Any further concerns? Thanks, -Joe On 4/24/2015 11:04 AM, joe darcy wrote: > On 4/23/2015 10:58 PM, Alan Bateman wrote: >> On 24/04/2015 02:54, Joseph D. Darcy wrote: >>> Hello, >>> >>> Any additional comments on marking with tests in question with a >>> "randomness" keyword? >>> >>> Thanks, >>> >>> -Joe >>> >> I don't object to this keyword although I should say that most of the >> (apparent) randomness that I've seen hasn't been because of tests >> using Random but rather because of non-deterministic sequence of >> tests running in the same VM. The switch from othervm to agentvm a >> few years ago took a long time to weed out issues, same thing (even >> more) with -concurrency. Another source of apparent randomness is >> just having a large pool of machines and where machines are randomly >> selected to execute the tests. >> >> I agree with your comments that tests using Random should have report >> the seed and a have a way to re-run with the same value. It could >> help with some cases. >> >> One thing that isn't clear to me is how this keyword will be >> maintained. If I modify a test and replace the use of Random then I >> guess I need to remember to also remove this label. When I add a test >> that uses Random ... Just wondering if there is a tool to do the >> tests analysis, identify the use of specific APIs ,and help identify >> where the keyword might be missing or not needed. >> > > The goal of the keyword is to enable better analysis of bug failures. > We (still) have some intermittent test failures in the platform, some > probably remaining from -concurrency issues and some due to > inconsistent machine config issues on the test farms. However, there > is reason to believe some of the tests also fail because of the use of > randomness in the generation of test cases. For example, the test > > java/lang/invoke/MethodHandles/CatchExceptionTest.java > > fails about once every three hundred runs when the random cases it > generates trigger an error condition. Setting the seed to known-bad > value causes the test to fail consistently (JDK-8055269). I have > suspicions some of our other intermittently failing tests are in a > similar but undiagnosed situation. > > If a test uses randomness, I think the default assumed cause for a > test failure should switch from environmental causes (bad machine > config, etc.) to the random behavior. Therefore, when a random-using > test fails, I think the failure analysis needs to include recording of > the bad seed to see if the failure is reproducible / deterministic > with a fixed seed value. > > I was very surprised by the large number of random-using tests in the > JDK regression tests. Nearly all of these have been stably passing for > many years. After the one-time cost of this large update to add the > keywords, there would be a small amount of incremental test > maintenance as new random-using tests were added or the randomness > value of a test changed. However, I would expect whether or not a test > used randomness to be a property of a test that very rarely changed. > > Thanks, > > -Joe From joe.darcy at oracle.com Wed Apr 29 00:44:14 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 28 Apr 2015 17:44:14 -0700 Subject: JDK 9 RFR of JDK-8078880: Mark a few more intermittently failing security-libs tests Message-ID: <5540295E.9080407@oracle.com> Hello, After additional testing, a few more security libs test have been observed to intermittently fail. Please review the patch below to address JDK-8078880: Mark a few more intermittently failuring security-libs tests Thanks, -Joe diff -r b9f8eb8938f4 test/sun/security/mscapi/SignUsingSHA2withRSA.sh --- a/test/sun/security/mscapi/SignUsingSHA2withRSA.sh Tue Apr 28 11:10:45 2015 -0700 +++ b/test/sun/security/mscapi/SignUsingSHA2withRSA.sh Tue Apr 28 17:41:16 2015 -0700 @@ -28,6 +28,7 @@ # @bug 6753664 # @run shell SignUsingSHA2withRSA.sh # @summary Support SHA256 (and higher) in SunMSCAPI +# @key intermittent # set a few environment variables so that the shell-script can run stand-alone # in the source directory diff -r b9f8eb8938f4 test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java --- a/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java Tue Apr 28 11:10:45 2015 -0700 +++ b/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java Tue Apr 28 17:41:16 2015 -0700 @@ -28,6 +28,7 @@ * @author Andreas Sterbenz * @library .. * @run main/othervm TestKeyPairGenerator + * @key intermittent */ import java.io.*; From xuelei.fan at oracle.com Wed Apr 29 01:06:56 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 Apr 2015 09:06:56 +0800 Subject: JDK 9 RFR of JDK-8078880: Mark a few more intermittently failing security-libs tests In-Reply-To: <5540295E.9080407@oracle.com> References: <5540295E.9080407@oracle.com> Message-ID: <55402EB0.5090206@oracle.com> Looks fine to me. Thanks, Xuelei On 4/29/2015 8:44 AM, joe darcy wrote: > Hello, > > After additional testing, a few more security libs test have been > observed to intermittently fail. Please review the patch below to address > > JDK-8078880: Mark a few more intermittently failuring security-libs > tests > > Thanks, > > -Joe > > diff -r b9f8eb8938f4 test/sun/security/mscapi/SignUsingSHA2withRSA.sh > --- a/test/sun/security/mscapi/SignUsingSHA2withRSA.sh Tue Apr 28 > 11:10:45 2015 -0700 > +++ b/test/sun/security/mscapi/SignUsingSHA2withRSA.sh Tue Apr 28 > 17:41:16 2015 -0700 > @@ -28,6 +28,7 @@ > # @bug 6753664 > # @run shell SignUsingSHA2withRSA.sh > # @summary Support SHA256 (and higher) in SunMSCAPI > +# @key intermittent > > # set a few environment variables so that the shell-script can run > stand-alone > # in the source directory > diff -r b9f8eb8938f4 test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java > --- a/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java Tue Apr > 28 11:10:45 2015 -0700 > +++ b/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java Tue Apr > 28 17:41:16 2015 -0700 > @@ -28,6 +28,7 @@ > * @author Andreas Sterbenz > * @library .. > * @run main/othervm TestKeyPairGenerator > + * @key intermittent > */ > > import java.io.*; > From weijun.wang at oracle.com Wed Apr 29 01:10:11 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 29 Apr 2015 09:10:11 +0800 Subject: Kerberos Bug Introduced in d777e2918a77? In-Reply-To: References: <5537CA82.1060107@oracle.com> <55382D1A.8070702@oracle.com> <553843AD.8050406@oracle.com> <5538FE4F.5030503@oracle.com> <553F7267.1060706@oracle.com> Message-ID: <55402F73.4060208@oracle.com> On 4/28/2015 10:57 PM, Daniel Jones wrote: > Hi (is it Max or Weijun? I don't want to be rude!) Either is OK. > > I've read through the code changes and static analysis with my eyes > suggests the change looks good. The client is not in the habit of > building OpenJDK regularly, but there's no reason we can't give it a go. > > I had a look on http://hg.openjdk.java.net/jdk8u/ and I can't see the > changeset anywhere. Is there a specific revision I should be looking > for? I'm more familiar with Git than Mercurial, so may be missing > something obvious. It's still in code review and not in dev repo yet. --Max > > Cheers! > > On Tue, Apr 28, 2015 at 12:43 PM, Weijun Wang > wrote: > > > On 4/28/2015 6:14 PM, Daniel Jones wrote: > > I noticed in the bug report Internet Explorer is mentioned. We > see the > same behaviour with IE, Firefox and Chrome. > > > Thanks. I've mentioned that in the comment. > > BTW, are you able to build jdk yourself? If so, can you try out the fix? > > http://cr.openjdk.java.net/~weijun/8078439/webrev.01/ > > It applies to both both jdk8u (without the module name in src path) > and jdk9. > > I've done some local tests but it would be more confident if it > works for your environment. > > Thanks > Max > > > > > -- > Regards, > > Daniel Jones > EngineerBetter.com From xuelei.fan at oracle.com Wed Apr 29 03:09:58 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 Apr 2015 11:09:58 +0800 Subject: RFR [9] 8078528: clean out tidy warnings from security.auth In-Reply-To: <55391C46.6080301@oracle.com> References: <55391C46.6080301@oracle.com> Message-ID: <55404B86.7050806@oracle.com> I had a quick read of the changes. All about doc cleanup, no behavior changes. I did not check every line of the update. It's OK to me if the update can pass a javadoc check. Thanks, Xuelei On 4/24/2015 12:22 AM, alexander stepanov wrote: > Hello, > > Could you please review the following fix > http://cr.openjdk.java.net/~avstepan/8078528/webrev.00/ > > for > https://bugs.openjdk.java.net/browse/JDK-8078528 > > Just some HTML markup cleanup for docs. > > Thanks, > Alexander From Alan.Bateman at oracle.com Wed Apr 29 06:51:18 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Apr 2015 07:51:18 +0100 Subject: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness In-Reply-To: <55401D85.1090306@oracle.com> References: <553703BC.1070504@oracle.com> <5539A249.7050105@oracle.com> <5539DB71.2070605@oracle.com> <553A85A8.7080207@oracle.com> <55401D85.1090306@oracle.com> Message-ID: <55407F66.1030905@oracle.com> On 29/04/2015 00:53, Joseph D. Darcy wrote: > Hello, > > I'd like to get this changeset, or something close to it, pushed soon > so we can start taking advantage of better failure triaging. > > Any further concerns? I should have been clearer, I don't have any issues with the proposed patch. I was mostly probing to see how the keyword would be used as it looks to be more for triage rather than test selection. -Alan From artem.smotrakov at oracle.com Wed Apr 29 07:23:12 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 29 Apr 2015 10:23:12 +0300 Subject: [9] RFR: 8076486: javax/security/auth/Subject/doAs/NestedActions.java fails if extra VM options are given Message-ID: <554086E0.9080007@oracle.com> Hello, Please review this fix for javax/security/auth/Subject/doAs/NestedActions.java test. The test runs java in a separate process. It fails if multiple java options are passed because ProcessBuilder expects each parameter to be put in to a separate array element, but the test didn't do that. I updated the test to split java option string, and put each option in a separate array element. Bug: https://bugs.openjdk.java.net/browse/JDK-8076486 Webrev: http://cr.openjdk.java.net/~asmotrak/8076486/webrev.00/ Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.v.stepanov at oracle.com Wed Apr 29 10:46:40 2015 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Wed, 29 Apr 2015 13:46:40 +0300 Subject: RFR [9] 8078528: clean out tidy warnings from security.auth In-Reply-To: <55404B86.7050806@oracle.com> References: <55391C46.6080301@oracle.com> <55404B86.7050806@oracle.com> Message-ID: <5540B690.7020201@oracle.com> Hello Xuelei, Thanks. > It's OK to me if the update can pass a javadoc check. Yes, I don't see new javadoc warnings caused by the fix. Regards, Alexander On 29.04.2015 6:09, Xuelei Fan wrote: > I had a quick read of the changes. All about doc cleanup, no behavior > changes. I did not check every line of the update. It's OK to me if > the update can pass a javadoc check. > > Thanks, > Xuelei > > On 4/24/2015 12:22 AM, alexander stepanov wrote: >> Hello, >> >> Could you please review the following fix >> http://cr.openjdk.java.net/~avstepan/8078528/webrev.00/ >> >> for >> https://bugs.openjdk.java.net/browse/JDK-8078528 >> >> Just some HTML markup cleanup for docs. >> >> Thanks, >> Alexander From xuelei.fan at oracle.com Wed Apr 29 11:15:12 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 Apr 2015 19:15:12 +0800 Subject: RFR [9] 8078528: clean out tidy warnings from security.auth In-Reply-To: <5540B690.7020201@oracle.com> References: <55391C46.6080301@oracle.com> <55404B86.7050806@oracle.com> <5540B690.7020201@oracle.com> Message-ID: <5540BD40.1090507@oracle.com> On 4/29/2015 6:46 PM, alexander stepanov wrote: > Hello Xuelei, > > Thanks. >> It's OK to me if the update can pass a javadoc check. > > Yes, I don't see new javadoc warnings caused by the fix. > Good! Thanks, Xuelei > Regards, > Alexander > > > On 29.04.2015 6:09, Xuelei Fan wrote: >> I had a quick read of the changes. All about doc cleanup, no behavior >> changes. I did not check every line of the update. It's OK to me if >> the update can pass a javadoc check. >> >> Thanks, >> Xuelei >> >> On 4/24/2015 12:22 AM, alexander stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix >>> http://cr.openjdk.java.net/~avstepan/8078528/webrev.00/ >>> >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8078528 >>> >>> Just some HTML markup cleanup for docs. >>> >>> Thanks, >>> Alexander > From weijun.wang at oracle.com Wed Apr 29 14:04:12 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 29 Apr 2015 22:04:12 +0800 Subject: [9] RFR: 8076486: javax/security/auth/Subject/doAs/NestedActions.java fails if extra VM options are given In-Reply-To: <554086E0.9080007@oracle.com> References: <554086E0.9080007@oracle.com> Message-ID: <5540E4DC.3080802@oracle.com> Maybe you can call JAVA_OPTS.trim().split("\\s+") to avoid the filtering. And it seems Collections.addAll() can add an array to a list. Of course, you are free to exercise any fancy jdk8 features. :-) Thanks Max On 4/29/2015 3:23 PM, Artem Smotrakov wrote: > Hello, > > Please review this fix for > javax/security/auth/Subject/doAs/NestedActions.java test. > > The test runs java in a separate process. It fails if multiple java > options are passed because ProcessBuilder expects each parameter to be > put in to a separate array element, but the test didn't do that. I > updated the test to split java option string, and put each option in a > separate array element. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076486 > Webrev: http://cr.openjdk.java.net/~asmotrak/8076486/webrev.00/ > > Artem From artem.smotrakov at oracle.com Wed Apr 29 15:44:18 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 29 Apr 2015 18:44:18 +0300 Subject: [9] RFR: 8076486: javax/security/auth/Subject/doAs/NestedActions.java fails if extra VM options are given In-Reply-To: <5540E4DC.3080802@oracle.com> References: <554086E0.9080007@oracle.com> <5540E4DC.3080802@oracle.com> Message-ID: <5540FC52.6030802@oracle.com> Hi Max, These fancy things sometimes make me forget about simpler ways :-) Please take a look http://cr.openjdk.java.net/~asmotrak/8076486/webrev.01/ Thanks! Artem On 04/29/2015 05:04 PM, Weijun Wang wrote: > Maybe you can call JAVA_OPTS.trim().split("\\s+") to avoid the filtering. > > And it seems Collections.addAll() can add an array to a list. > > Of course, you are free to exercise any fancy jdk8 features. :-) > > Thanks > Max > > On 4/29/2015 3:23 PM, Artem Smotrakov wrote: >> Hello, >> >> Please review this fix for >> javax/security/auth/Subject/doAs/NestedActions.java test. >> >> The test runs java in a separate process. It fails if multiple java >> options are passed because ProcessBuilder expects each parameter to be >> put in to a separate array element, but the test didn't do that. I >> updated the test to split java option string, and put each option in a >> separate array element. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076486 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8076486/webrev.00/ >> >> Artem From valerie.peng at oracle.com Wed Apr 29 21:08:58 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 29 Apr 2015 14:08:58 -0700 Subject: [9] RFR 8038084: CertStore needs a way to add new CertStore types In-Reply-To: <55400FE9.4000200@oracle.com> References: <553974C0.6080004@oracle.com> <553E4395.2020807@oracle.com> <55400FE9.4000200@oracle.com> Message-ID: <5541486A.4030806@oracle.com> Updated the webrev in-place with comments from Joe Darcy as well... Valerie On 4/28/2015 3:55 PM, Valerie Peng wrote: > Sean, > > Thanks for the review! > Webrev has been updated at: > http://cr.openjdk.java.net/~valeriep/8038084/webrev.01/ > > Can you please review the CCC as well? It's > http://ccc.us.oracle.com/8038084 > > Thanks again, > Valerie > > On 4/27/2015 7:11 AM, Sean Mullan wrote: >> Hi Valerie, >> >> Looks good, just a couple of comments: >> >> - URICertStoreParameters and JdkLdap.java: please remove the @author >> tags, this tag is generally discouraged as the information can be >> obtained from the source code history. >> >> * URICertStoreParameters >> >> Couple of re-wording suggestions: >> >> First sentence: >> >> "Parameters used as input for {@code CertStore} algorithms which use >> information contained in a URI to retrieve certificates and CRLs." >> >> Second sentence: s/an URI/a URI/ >> >> - add @Override tags to the toString and clone methods >> >> --Sean >> >> On 04/23/2015 06:40 PM, Valerie Peng wrote: >>> Hi Sean, >>> >>> Can you please review the following fix? >>> Besides the new API and provider, I have also updated >>> LDAPCertStoreParameters to mention the new URICertStoreParameters class >>> per your suggestions. >>> >>> 8038084: CertStore needs a way to add new CertStore types >>> Webrev: http://cr.openjdk.java.net/~valeriep/8038084/webrev.00/ >>> CCC: http://ccc.us.oracle.com/8038084 >>> >>> Thanks, >>> Valerie From mark.reinhold at oracle.com Wed Apr 29 23:35:15 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 29 Apr 2015 16:35:15 -0700 (PDT) Subject: JEP 249: OCSP Stapling for TLS Message-ID: <20150429233515.2D2A660BAB@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/249 - Mark From joe.darcy at oracle.com Thu Apr 30 00:24:28 2015 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 29 Apr 2015 17:24:28 -0700 Subject: JDK 9 RFR of JDK-8079107: Update TestKeyPairGenerator.java to use random number generator library Message-ID: <5541763C.9030003@oracle.com> Hello, Please review the patch below to address JDK-8079107: Update TestKeyPairGenerator.java to use random number generator library The patch implements the recommendations recently sent to jdk9-dev: http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002164.html Thanks, -Joe diff -r 409888e3ba56 test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java --- a/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java Wed Apr 29 16:34:49 2015 -0700 +++ b/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java Wed Apr 29 17:22:35 2015 -0700 @@ -24,9 +24,11 @@ /** * @test * @bug 4856966 - * @summary Verify that the RSA KeyPairGenerator works + * @summary Verify that the RSA KeyPairGenerator works (use -Dseed=X to set PRNG seed) * @author Andreas Sterbenz * @library .. + * @library /lib/testlibrary + * @build jdk.testlibrary.* * @run main/othervm TestKeyPairGenerator * @key intermittent randomness */ @@ -106,7 +108,7 @@ int[] keyLengths = {512, 512, 1024}; BigInteger[] pubExps = {null, BigInteger.valueOf(3), null}; KeyPair[] keyPairs = new KeyPair[3]; - new Random().nextBytes(data); + RandomFactory.getRandom().nextBytes(data); KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA", provider); for (int i = 0; i < keyLengths.length; i++) { int len = keyLengths[i]; From valerie.peng at oracle.com Thu Apr 30 01:37:21 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 29 Apr 2015 18:37:21 -0700 Subject: RFR 8078439: Kerberos auth fails if client proposes MS krb5 OID In-Reply-To: <553C4B8D.1010003@oracle.com> References: <553B15D9.2020609@oracle.com> <553C4B8D.1010003@oracle.com> Message-ID: <55418751.3030001@oracle.com> I think your current approach of using the mechList[0] makes sense. As long as the rest of our code will recognize this MS krb5 OID, it will be fine. The source changes look fine to me. Just some nits on the regression test "MSOID.java": 1) line 57 has a typo, aceptor -> acceptor 2) line 59, currently, this test will accept all GSSException as the expected exception which may be a little bit too liberal. Any chance that we can narrow it down to a certain error status code? Just so we don't accidentally allow the wrong exceptions. Thanks, Valerie On 4/25/2015 7:21 PM, Weijun Wang wrote: > Hi All > > I've updated the webrev at > > http://cr.openjdk.java.net/~weijun/8078439/webrev.01/ > > The only change is > > @@ -548,6 +548,7 @@ > "mechToken is missing"); > } > accept_token = GSS_acceptSecContext(mechToken); > + mech_wanted = mechList[0]; > } else { > accept_token = null; > } > > This means the supportedMech in response will be MS_KRB5_OID if it was > the preferred mech in the request. > > In my webrev.00, I insisted using the "correct" OID because that was > the way before JDK-8048194 and no one complained about it. Therefore I > think the client side is able to find out that it's also a flavor of > Kerberos 5 and has accepted it happily. So why fix it if it's not broken? > > However, after writing a SSPI client myself, I find out that it does > not accept the "correct" ID and fail. Why didn't people notice that? > My understanding is that until now a client that sends those OIDs has > always been a browser, and this browser simply ignores the response if > it already sees a "200 OK" HTTP status. > > Thanks > Max > > On 4/25/2015 12:19 PM, Weijun Wang wrote: >> Hi All >> >> Please review a fix at >> >> http://cr.openjdk.java.net/~weijun/8078439 >> >> This is a regression triggered by JDK-8048194. In SPNEGO, a client might >> send NegTokenInit with OIDs being {MS_KRB5_OID, KRB5_OID} along with a >> krb5 AP-REQ as mechToken. Java did not understand MS_KRB5_OID but before >> JDK-8048194 it blindly accepted the mechToken and everything just went >> on fine. After JDK-8048194, it rejects the unknown OID and cannot >> establish a security context. >> >> The fix adds a tweak to recognize the MS_KRB5_OID. >> >> *Ivan*: >> >> Can you try out the patch on jdk8u? >> >> Thanks >> Max From fengzm at sg.ibm.com Thu Apr 30 02:06:32 2015 From: fengzm at sg.ibm.com (Zhemin Feng) Date: Thu, 30 Apr 2015 10:06:32 +0800 Subject: AUTO: Zhemin Feng is out of the office (returning 05/05/2015) Message-ID: I am out of the office until 05/05/2015. I will take leave from 30th April, and will be back on 5th May. Please contact Ke Pi/Singapore/IBM and Tianyu Tang/Singapore/IBM for Java Security L3 work. Best regards, Feng Zhemin Note: This is an automated response to your message "security-dev Digest, Vol 94, Issue 18" sent on 04/30/2015 8:24:34. This is the only notification you will receive while this person is away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Apr 30 09:06:48 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 30 Apr 2015 17:06:48 +0800 Subject: RFR 8078439: Kerberos auth fails if client proposes MS krb5 OID In-Reply-To: <55418751.3030001@oracle.com> References: <553B15D9.2020609@oracle.com> <553C4B8D.1010003@oracle.com> <55418751.3030001@oracle.com> Message-ID: <5541F0A8.9050307@oracle.com> Hi Valerie I've updated the test a little to make sure the exception is NO_CRED and it's sent from the krb5 mech. It passed on my own machine and I'm running a JPRT job now. The webrev is at http://cr.openjdk.java.net/~weijun/8078439/webrev.02/ Thanks Max On 4/30/2015 9:37 AM, Valerie Peng wrote: > I think your current approach of using the mechList[0] makes sense. As > long as the rest of our code will recognize this MS krb5 OID, it will be > fine. > > The source changes look fine to me. > Just some nits on the regression test "MSOID.java": > 1) line 57 has a typo, aceptor -> acceptor > 2) line 59, currently, this test will accept all GSSException as the > expected exception which may be a little bit too liberal. Any chance > that we can narrow it down to a certain error status code? Just so we > don't accidentally allow the wrong exceptions. > > Thanks, > Valerie > > On 4/25/2015 7:21 PM, Weijun Wang wrote: >> Hi All >> >> I've updated the webrev at >> >> http://cr.openjdk.java.net/~weijun/8078439/webrev.01/ >> >> The only change is >> >> @@ -548,6 +548,7 @@ >> "mechToken is missing"); >> } >> accept_token = GSS_acceptSecContext(mechToken); >> + mech_wanted = mechList[0]; >> } else { >> accept_token = null; >> } >> >> This means the supportedMech in response will be MS_KRB5_OID if it was >> the preferred mech in the request. >> >> In my webrev.00, I insisted using the "correct" OID because that was >> the way before JDK-8048194 and no one complained about it. Therefore I >> think the client side is able to find out that it's also a flavor of >> Kerberos 5 and has accepted it happily. So why fix it if it's not broken? >> >> However, after writing a SSPI client myself, I find out that it does >> not accept the "correct" ID and fail. Why didn't people notice that? >> My understanding is that until now a client that sends those OIDs has >> always been a browser, and this browser simply ignores the response if >> it already sees a "200 OK" HTTP status. >> >> Thanks >> Max >> >> On 4/25/2015 12:19 PM, Weijun Wang wrote: >>> Hi All >>> >>> Please review a fix at >>> >>> http://cr.openjdk.java.net/~weijun/8078439 >>> >>> This is a regression triggered by JDK-8048194. In SPNEGO, a client might >>> send NegTokenInit with OIDs being {MS_KRB5_OID, KRB5_OID} along with a >>> krb5 AP-REQ as mechToken. Java did not understand MS_KRB5_OID but before >>> JDK-8048194 it blindly accepted the mechToken and everything just went >>> on fine. After JDK-8048194, it rejects the unknown OID and cannot >>> establish a security context. >>> >>> The fix adds a tweak to recognize the MS_KRB5_OID. >>> >>> *Ivan*: >>> >>> Can you try out the patch on jdk8u? >>> >>> Thanks >>> Max From sean.mullan at oracle.com Thu Apr 30 19:25:29 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 30 Apr 2015 15:25:29 -0400 Subject: JDK 9 RFR of JDK-8079107: Update TestKeyPairGenerator.java to use random number generator library In-Reply-To: <5541763C.9030003@oracle.com> References: <5541763C.9030003@oracle.com> Message-ID: <554281A9.7030208@oracle.com> Looks fine to me. --Sean On 04/29/2015 08:24 PM, joe darcy wrote: > Hello, > > Please review the patch below to address > > JDK-8079107: Update TestKeyPairGenerator.java to use random number > generator library > > The patch implements the recommendations recently sent to jdk9-dev: > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002164.html > > Thanks, > > -Joe > > diff -r 409888e3ba56 test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java > --- a/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java Wed Apr > 29 16:34:49 2015 -0700 > +++ b/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java Wed Apr > 29 17:22:35 2015 -0700 > @@ -24,9 +24,11 @@ > /** > * @test > * @bug 4856966 > - * @summary Verify that the RSA KeyPairGenerator works > + * @summary Verify that the RSA KeyPairGenerator works (use -Dseed=X to > set PRNG seed) > * @author Andreas Sterbenz > * @library .. > + * @library /lib/testlibrary > + * @build jdk.testlibrary.* > * @run main/othervm TestKeyPairGenerator > * @key intermittent randomness > */ > @@ -106,7 +108,7 @@ > int[] keyLengths = {512, 512, 1024}; > BigInteger[] pubExps = {null, BigInteger.valueOf(3), null}; > KeyPair[] keyPairs = new KeyPair[3]; > - new Random().nextBytes(data); > + RandomFactory.getRandom().nextBytes(data); > KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA", > provider); > for (int i = 0; i < keyLengths.length; i++) { > int len = keyLengths[i]; >