From dean.long at oracle.com Thu Nov 1 00:13:09 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 17:13:09 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> Message-ID: <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> On 10/31/18 4:06 PM, David Holmes wrote: > Hi Dean, > > Looking only at the hotspot changes. The removal of the DoPrivileged > and related privileged_stack code seems okay. I have a few related > comments: > > src/hotspot/share/classfile/systemDictionary.hpp > > You added the java_security_AccessController class after > java_security_AccessControlContext. Did you actually verify where in > the load/initialization order the AccessController class appears > today, and where it appears after your change? (Note the comments at > the start of WK_KLASSES_DO). Changes to the initialization order would > be my biggest concern with this patch. > No, I did not notice that comment and assumed alphabetical order was OK here.? However, these classes appear to be only resolved, not initialized (and AccessController does not have a static initializer), so could you explain how the order in this list can affect initialization order? I only need this in JVM_GetStackAccessControlContext, which is a static JNI method, so I could get the klass* from the incoming jclass instead of using a well-known class entry. > --- > > I'm unclear about the change to the test: > > test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm > > as it still refers to the now non-existent JVM_DoPrivileged in the > summary. Does this test still make sense? Should it be moved to the > Java side now it doesn't actually test anything in the VM? > I think these tests still make sense, unless we have similar coverage somewhere else.? How about if I fix the reference to JVM_DoPrivileged for now and file a separate bug about moving or removing these tests? > --- > > There may be further dead code to remove now: > > vmSymbols.hpp: codesource_permissioncollection_signature is now > unreferenced and can be removed. > > javaClasses.*: > ? - java_lang_System::has_security_manager > ? - java_security_AccessControlContext::is_authorized > > ./share/memory/universe.hpp:? static Method* > protection_domain_implies_method() > Good catches!? I have uploaded a new webrev: http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental diff) dl > --- > > Thanks, > David > > > On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8212605 >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >> >> This change implements AccessController.doPrivileged in Java. This >> gives a performance improvement while also being useful to Project >> Loom by removing the Java --> native --> Java transition.? One reason >> doPrivileged has historically been in native is because of the need >> to guarantee the cleanup of the privileged context when doPrivileged >> returns.? To do that in Java, the information that >> AccessController.getContext needs is pushed onto the Java stack as >> arguments to a method that getContext will recognize during its stack >> walk.? This allows us to remove the native privileged stack while >> guaranteeing that the privileged context goes away when the method >> returns. >> >> Tested with tier1-tier3 hotspot and jdk tests and JCK >> api/java_security tests.? For the first few rounds of testing, I kept >> the old native privileged stack and compared the results of the old >> and new implementations for each getContext call, which did catch >> some early bugs.? The changes were also examined by internal security >> experts and run through additional internal security tests. >> >> The improvement on this [1] doPrivileged microbenchmark is >> approximate 50x. >> >> There is no attempt to optimize getContext() or security permission >> checks in this change, however, this is intended to be a first step >> towards other possible improvements, for example those proposed here >> [2]. >> >> dl >> >> [1] >> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >> >> From david.holmes at oracle.com Thu Nov 1 00:54:58 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Nov 2018 10:54:58 +1000 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> Message-ID: <4fe219c8-7e29-1bfb-839d-1e1caab34efa@oracle.com> Hi Dean, On 1/11/2018 10:13 AM, dean.long at oracle.com wrote: > On 10/31/18 4:06 PM, David Holmes wrote: >> Hi Dean, >> >> Looking only at the hotspot changes. The removal of the DoPrivileged >> and related privileged_stack code seems okay. I have a few related >> comments: >> >> src/hotspot/share/classfile/systemDictionary.hpp >> >> You added the java_security_AccessController class after >> java_security_AccessControlContext. Did you actually verify where in >> the load/initialization order the AccessController class appears >> today, and where it appears after your change? (Note the comments at >> the start of WK_KLASSES_DO). Changes to the initialization order would >> be my biggest concern with this patch. >> > > No, I did not notice that comment and assumed alphabetical order was OK > here.? However, these classes appear to be only resolved, not > initialized (and AccessController does not have a static initializer), > so could you explain how the order in this list can affect > initialization order? You're right it doesn't. There are a couple of comments that refer to "initialization" but it's not static initialization of these classes. I'm unclear how the resolution order in that list may interact with other parts of the startup sequence. > I only need this in JVM_GetStackAccessControlContext, which is a static > JNI method, so I could get the klass* from the incoming jclass instead > of using a well-known class entry. I think it's okay given we have AccessControlContext there anyway. >> --- >> >> I'm unclear about the change to the test: >> >> test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm >> >> as it still refers to the now non-existent JVM_DoPrivileged in the >> summary. Does this test still make sense? Should it be moved to the >> Java side now it doesn't actually test anything in the VM? >> > > I think these tests still make sense, unless we have similar coverage > somewhere else.? How about if I fix the reference to JVM_DoPrivileged > for now and file a separate bug about moving or removing these tests? Yep that's fine. >> --- >> >> There may be further dead code to remove now: >> >> vmSymbols.hpp: codesource_permissioncollection_signature is now >> unreferenced and can be removed. >> >> javaClasses.*: >> ? - java_lang_System::has_security_manager >> ? - java_security_AccessControlContext::is_authorized >> >> ./share/memory/universe.hpp:? static Method* >> protection_domain_implies_method() >> > > Good catches!? I have uploaded a new webrev: > > http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ > http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental diff) Updates all look fine. Thanks, David ----- > dl > >> --- >> >> Thanks, >> David >> >> >> On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>> >>> This change implements AccessController.doPrivileged in Java. This >>> gives a performance improvement while also being useful to Project >>> Loom by removing the Java --> native --> Java transition.? One reason >>> doPrivileged has historically been in native is because of the need >>> to guarantee the cleanup of the privileged context when doPrivileged >>> returns.? To do that in Java, the information that >>> AccessController.getContext needs is pushed onto the Java stack as >>> arguments to a method that getContext will recognize during its stack >>> walk.? This allows us to remove the native privileged stack while >>> guaranteeing that the privileged context goes away when the method >>> returns. >>> >>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>> api/java_security tests.? For the first few rounds of testing, I kept >>> the old native privileged stack and compared the results of the old >>> and new implementations for each getContext call, which did catch >>> some early bugs.? The changes were also examined by internal security >>> experts and run through additional internal security tests. >>> >>> The improvement on this [1] doPrivileged microbenchmark is >>> approximate 50x. >>> >>> There is no attempt to optimize getContext() or security permission >>> checks in this change, however, this is intended to be a first step >>> towards other possible improvements, for example those proposed here >>> [2]. >>> >>> dl >>> >>> [1] >>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>> >>> > From jini at zeus.net.au Thu Nov 1 01:15:05 2018 From: jini at zeus.net.au (Peter) Date: Thu, 01 Nov 2018 11:15:05 +1000 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <4fe219c8-7e29-1bfb-839d-1e1caab34efa@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> <4fe219c8-7e29-1bfb-839d-1e1caab34efa@oracle.com> Message-ID: <5BDA5399.4030509@zeus.net.au> Hello Dean & David, Interesting reading. Is DomainCombiner still being considered for deprecation? Our code makes heavy use of AccessController.doPrivileged. Regards, Peter. "Hot Spots - Method","Self time [%]","Self time","Self time (CPU)","Samples" "java.net.DualStackPlainSocketImpl.accept0[native]()","38.88627","1837851.568 ms","1837851.568 ms","16" "java.net.SocketInputStream.socketRead0[native]()","20.505322","969127.11 ms","969127.11 ms","315" "java.net.TwoStacksPlainDatagramSocketImpl.peekData[native]()","20.19654","954533.467 ms","954533.467 ms","11" "sun.management.ThreadImpl.dumpThreads0[native]()","11.148865","526920.162 ms","526920.162 ms","239" "java.net.TwoStacksPlainDatagramSocketImpl.socketNativeSetOption[native]()","5.3582244","253241.609 ms","253241.609 ms","17" "sun.misc.Unsafe.unpark[native]()","2.6599514","125715.216 ms","125715.216 ms","759" "sun.misc.Unsafe.park[native]()","0.19931908","1.6213131447E7 ms","9420.263 ms","1401" "java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.siftDown()","0.15738875","7438.542 ms","7438.542 ms","71" "java.security.AccessController.doPrivileged[native]()","0.10248028","4843.446 ms","4843.446 ms","715" "java.lang.Thread.isInterrupted[native]()","0.09570652","4523.303 ms","4523.303 ms","40" "java.net.NetworkInterface.getAll[native]()","0.07478044","3534.29 ms","3534.29 ms","4" "java.util.concurrent.ThreadPoolExecutor.runWorker()","0.046051156","2176.48 ms","2176.48 ms","91" "java.lang.SecurityManager.getClassContext[native]()","0.043098312","2036.922 ms","2036.922 ms","20" "java.security.AccessController.getStackAccessControlContext[native]()","0.039155032","1850.554 ms","1850.554 ms","15" "au.net.zeus.collection.ReferenceProcessor$EnqueGarbageTask.run()","0.035316195","1669.122 ms","1669.122 ms","18" "java.net.SocketOutputStream.socketWrite0[native]()","0.03470353","1640.166 ms","1640.166 ms","17" "java.lang.Class.forName0[native]()","0.029112596","1375.926 ms","1375.926 ms","10" "java.lang.Throwable.fillInStackTrace[native]()","0.028279837","1336.568 ms","1336.568 ms","18" "java.lang.Thread.holdsLock[native]()","0.023839759","1126.72 ms","1126.72 ms","7" "java.lang.String.indexOf()","0.019056467","900.651 ms","900.651 ms","1" "au.net.zeus.collection.AbstractReferenceComparator.compare()","0.017307268","817.98 ms","817.98 ms","18" "sun.reflect.Reflection.getCallerClass[native]()","0.017031383","804.941 ms","804.941 ms","11" "java.net.DualStackPlainSocketImpl.available0[native]()","0.015988858","755.669 ms","755.669 ms","14" "java.lang.String.intern[native]()","0.014759737","697.578 ms","697.578 ms","8" "au.net.zeus.collection.ReferenceMap.wrapKey()","0.0139064975","657.252 ms","657.252 ms","4" "org.apache.river.api.net.Uri.toAsciiLowerCase()","0.013079452","618.164 ms","618.164 ms","1" "sun.reflect.DelegatingMethodAccessorImpl.invoke()","0.012204483","576.811 ms","576.811 ms","753" "java.lang.Object.clone[native]()","0.011227106","530.618 ms","530.618 ms","4" "java.lang.Class.getClassLoader0[native]()","0.010788701","509.898 ms","509.898 ms","9" "org.apache.river.impl.thread.SynchronousExecutors$Distributor.run()","0.010243974","484.153 ms","484.153 ms","3" "java.util.concurrent.locks.AbstractQueuedSynchronizer.release()","0.008626911","407.727 ms","407.727 ms","4" "java.util.concurrent.ConcurrentSkipListMap.keyIterator()","0.008402821","397.136 ms","397.136 ms","4" "sun.reflect.misc.ReflectUtil.checkPackageAccess()","0.008291823","391.89 ms","391.89 ms","8" "java.util.concurrent.ScheduledThreadPoolExecutor.schedule()","0.0078934925","373.064 ms","373.064 ms","1" "sun.management.VMManagementImpl.getDaemonThreadCount[native]()","0.007857989","371.386 ms","371.386 ms","1" "java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take()","0.0068998444","326.102 ms","326.102 ms","255" "java.lang.Class.getConstantPool[native]()","0.0065752934","310.763 ms","310.763 ms","2" "net.jini.jeri.connection.ConnectionManager.connect()","0.0060991626","8072.071 ms","288.26 ms","14" "java.util.concurrent.Executors$RunnableAdapter.call()","0.006036745","285.31 ms","285.31 ms","797" "java.util.Collections$SynchronizedCollection.size()","0.0057329717","270.953 ms","270.953 ms","1" "sun.management.ThreadImpl.getThreadInfo1[native]()","0.005478752","258.938 ms","258.938 ms","4" "java.util.concurrent.ScheduledThreadPoolExecutor.reExecutePeriodic()","0.00411447","194.459 ms","194.459 ms","3" "java.lang.reflect.Array.newArray[native]()","0.003456418","163.358 ms","163.358 ms","1" "com.sun.jini.jeri.internal.mux.MuxInputStream.read()","0.003161764","149.432 ms","149.432 ms","17" "net.jini.loader.pref.PreferredClassProvider.lookupLoader()","0.0031255828","147.722 ms","147.722 ms","2" "java.lang.Class.isPrimitive[native]()","0.0030873707","145.916 ms","145.916 ms","2" "au.net.zeus.collection.ReferenceMap.get()","0.0029420536","139.048 ms","139.048 ms","6" "sun.reflect.MethodAccessorGenerator.buildInternalSignature()","0.0029316437","138.556 ms","138.556 ms","1" "sun.management.ThreadImpl.findDeadlockedThreads0[native]()","0.002746041","129.784 ms","129.784 ms","2" "org.apache.river.api.io.AtomicObjectInputStream.readClassDesc()","0.0026871779","127.002 ms","127.002 ms","178" "net.jini.security.GrantPermission.constructName()","0.0026251199","124.069 ms","124.069 ms","1" "java.lang.System.identityHashCode[native]()","0.002610605","123.383 ms","123.383 ms","2" "java.util.concurrent.locks.LockSupport.unpark()","0.0025506418","120.549 ms","120.549 ms","760" "java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync.readerShouldBlock()","0.0025335667","119.742 ms","119.742 ms","2" "java.util.concurrent.ConcurrentSkipListMap.findPredecessor()","0.0024627491","116.395 ms","116.395 ms","4" "java.lang.SecurityManager.checkPackageAccess()","0.0023379137","110.495 ms","110.495 ms","1" "java.lang.Class.checkPackageAccess()","0.0022838535","107.94 ms","107.94 ms","5" "net.jini.loader.LoadClass.forName()","0.002258442","106.739 ms","106.739 ms","163" "java.io.ObjectOutputStream$HandleTable.growSpine()","0.0022080212","104.356 ms","104.356 ms","1" "java.lang.AbstractStringBuilder.deleteCharAt()","0.0021902905","103.518 ms","103.518 ms","1" "javax.management.openmbean.CompositeDataSupport.()","0.0021849375","103.265 ms","103.265 ms","2" "java.io.ObjectStreamClass$FieldReflector.getObjFieldValues()","0.0021076875","99.614 ms","99.614 ms","1" "java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter()","0.0021062698","99.547 ms","99.547 ms","1" "sun.management.ThreadImpl.getThreadInfo()","0.002029676","95.927 ms","95.927 ms","5" "au.net.zeus.collection.AbstractReferrerDecorator.get()","0.0019218308","90.83 ms","90.83 ms","1" "org.apache.river.api.io.AtomicObjectInputStream$GetArgImpl.get()","0.0019038884","89.982 ms","89.982 ms","24" "java.util.concurrent.ConcurrentSkipListMap$Node.appendMarker()","0.0019032748","89.953 ms","89.953 ms","1" "java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire()","0.001819889","86.012 ms","86.012 ms","6" "java.security.Policy.getPolicy()","0.0017857603","84.399 ms","84.399 ms","1" "java.net.URL.toExternalForm()","0.0017011049","80.398 ms","80.398 ms","2" "java.io.ObjectOutputStream$HandleTable.lookup()","0.0016315778","77.112 ms","77.112 ms","2" "java.lang.Class.getSuperclass[native]()","0.0015686523","74.138 ms","74.138 ms","1" "net.jini.loader.pref.PreferredClassLoader.checkPermissions()","0.0015065097","71.201 ms","71.201 ms","14" "org.apache.river.api.security.PermissionComparator.compare()","0.0014423993","68.171 ms","68.171 ms","2" "org.apache.river.api.io.AtomicObjectInputStream.findStreamSuperclass()","0.0013877256","65.587 ms","65.587 ms","1" "java.security.AccessController.getContext()","0.0013715605","64.823 ms","64.823 ms","17" "java.lang.Boolean.equals()","0.0013067942","61.762 ms","61.762 ms","2" "java.lang.String.valueOf()","0.0012928719","61.104 ms","61.104 ms","6" "java.io.ObjectStreamField.()","0.001281023","60.544 ms","60.544 ms","4" "org.apache.river.api.io.AtomicObjectInputStream.getBaseName()","0.0011021064","52.088 ms","52.088 ms","1" On 1/11/2018 10:54 AM, David Holmes wrote: > Hi Dean, > > On 1/11/2018 10:13 AM, dean.long at oracle.com wrote: >> On 10/31/18 4:06 PM, David Holmes wrote: >>> Hi Dean, >>> >>> Looking only at the hotspot changes. The removal of the DoPrivileged >>> and related privileged_stack code seems okay. I have a few related >>> comments: >>> >>> src/hotspot/share/classfile/systemDictionary.hpp >>> >>> You added the java_security_AccessController class after >>> java_security_AccessControlContext. Did you actually verify where in >>> the load/initialization order the AccessController class appears >>> today, and where it appears after your change? (Note the comments at >>> the start of WK_KLASSES_DO). Changes to the initialization order >>> would be my biggest concern with this patch. >>> >> >> No, I did not notice that comment and assumed alphabetical order was >> OK here. However, these classes appear to be only resolved, not >> initialized (and AccessController does not have a static >> initializer), so could you explain how the order in this list can >> affect initialization order? > > You're right it doesn't. There are a couple of comments that refer to > "initialization" but it's not static initialization of these classes. > > I'm unclear how the resolution order in that list may interact with > other parts of the startup sequence. > >> I only need this in JVM_GetStackAccessControlContext, which is a >> static JNI method, so I could get the klass* from the incoming jclass >> instead of using a well-known class entry. > > I think it's okay given we have AccessControlContext there anyway. > >>> --- >>> >>> I'm unclear about the change to the test: >>> >>> test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm >>> >>> as it still refers to the now non-existent JVM_DoPrivileged in the >>> summary. Does this test still make sense? Should it be moved to the >>> Java side now it doesn't actually test anything in the VM? >>> >> >> I think these tests still make sense, unless we have similar coverage >> somewhere else. How about if I fix the reference to JVM_DoPrivileged >> for now and file a separate bug about moving or removing these tests? > > Yep that's fine. > >>> --- >>> >>> There may be further dead code to remove now: >>> >>> vmSymbols.hpp: codesource_permissioncollection_signature is now >>> unreferenced and can be removed. >>> >>> javaClasses.*: >>> - java_lang_System::has_security_manager >>> - java_security_AccessControlContext::is_authorized >>> >>> ./share/memory/universe.hpp: static Method* >>> protection_domain_implies_method() >>> >> >> Good catches! I have uploaded a new webrev: >> >> http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ >> http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental >> diff) > > Updates all look fine. > > Thanks, > David > ----- > >> dl >> >>> --- >>> >>> Thanks, >>> David >>> >>> >>> On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>>> >>>> This change implements AccessController.doPrivileged in Java. This >>>> gives a performance improvement while also being useful to Project >>>> Loom by removing the Java --> native --> Java transition. One >>>> reason doPrivileged has historically been in native is because of >>>> the need to guarantee the cleanup of the privileged context when >>>> doPrivileged returns. To do that in Java, the information that >>>> AccessController.getContext needs is pushed onto the Java stack as >>>> arguments to a method that getContext will recognize during its >>>> stack walk. This allows us to remove the native privileged stack >>>> while guaranteeing that the privileged context goes away when the >>>> method returns. >>>> >>>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>>> api/java_security tests. For the first few rounds of testing, I >>>> kept the old native privileged stack and compared the results of >>>> the old and new implementations for each getContext call, which did >>>> catch some early bugs. The changes were also examined by internal >>>> security experts and run through additional internal security tests. >>>> >>>> The improvement on this [1] doPrivileged microbenchmark is >>>> approximate 50x. >>>> >>>> There is no attempt to optimize getContext() or security permission >>>> checks in this change, however, this is intended to be a first step >>>> towards other possible improvements, for example those proposed >>>> here [2]. >>>> >>>> dl >>>> >>>> [1] >>>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>>> >>>> >> From weijun.wang at oracle.com Thu Nov 1 01:56:44 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 1 Nov 2018 09:56:44 +0800 Subject: RFR [12]: 8191136: Remove deprecated java.security.{Certificate,Identity,IdentityScope,Signer} APIs In-Reply-To: <819BDCA3-07C6-43B3-A741-86F7C21187B6@oracle.com> References: <183dbd3b-8ae6-b446-508e-19a9842f2458@oracle.com> <819BDCA3-07C6-43B3-A741-86F7C21187B6@oracle.com> Message-ID: Hi Sean Do you also plan to remove the IDENTITYDB command and doImportIdentityDatabase() in keytool/Main? The command is undocumented (also not shown in "keytool -help") and the method is a no-op now. There are also 2 strings in keytool/Resources that contain the "identity" word. Thanks Max > On Oct 28, 2018, at 2:54 PM, Weijun Wang wrote: > > Change looks fine, and I added myself a a reviewer in the CSR. > > Thanks > Max > >> On Oct 27, 2018, at 4:10 AM, Sean Mullan wrote: >> >> Please review this change to remove the Certificate, Identity, IdentityScope, and Signer APIs. These APIs were marked for removal in Java SE 10. They have been deprecated since Java SE 1.2, and have long been superseded by other security APIs. Several SecurityPermission targets and one security property that are only applicable to these APIs have also been removed. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191136/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8212916 >> >> --Sean > From dean.long at oracle.com Thu Nov 1 03:57:54 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 20:57:54 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <4fe219c8-7e29-1bfb-839d-1e1caab34efa@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> <4fe219c8-7e29-1bfb-839d-1e1caab34efa@oracle.com> Message-ID: Thanks David. dl On 10/31/18 5:54 PM, David Holmes wrote: > Hi Dean, > > On 1/11/2018 10:13 AM, dean.long at oracle.com wrote: >> On 10/31/18 4:06 PM, David Holmes wrote: >>> Hi Dean, >>> >>> Looking only at the hotspot changes. The removal of the DoPrivileged >>> and related privileged_stack code seems okay. I have a few related >>> comments: >>> >>> src/hotspot/share/classfile/systemDictionary.hpp >>> >>> You added the java_security_AccessController class after >>> java_security_AccessControlContext. Did you actually verify where in >>> the load/initialization order the AccessController class appears >>> today, and where it appears after your change? (Note the comments at >>> the start of WK_KLASSES_DO). Changes to the initialization order >>> would be my biggest concern with this patch. >>> >> >> No, I did not notice that comment and assumed alphabetical order was >> OK here.? However, these classes appear to be only resolved, not >> initialized (and AccessController does not have a static >> initializer), so could you explain how the order in this list can >> affect initialization order? > > You're right it doesn't. There are a couple of comments that refer to > "initialization" but it's not static initialization of these classes. > > I'm unclear how the resolution order in that list may interact with > other parts of the startup sequence. > >> I only need this in JVM_GetStackAccessControlContext, which is a >> static JNI method, so I could get the klass* from the incoming jclass >> instead of using a well-known class entry. > > I think it's okay given we have AccessControlContext there anyway. > >>> --- >>> >>> I'm unclear about the change to the test: >>> >>> test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm >>> >>> as it still refers to the now non-existent JVM_DoPrivileged in the >>> summary. Does this test still make sense? Should it be moved to the >>> Java side now it doesn't actually test anything in the VM? >>> >> >> I think these tests still make sense, unless we have similar coverage >> somewhere else.? How about if I fix the reference to JVM_DoPrivileged >> for now and file a separate bug about moving or removing these tests? > > Yep that's fine. > >>> --- >>> >>> There may be further dead code to remove now: >>> >>> vmSymbols.hpp: codesource_permissioncollection_signature is now >>> unreferenced and can be removed. >>> >>> javaClasses.*: >>> ? - java_lang_System::has_security_manager >>> ? - java_security_AccessControlContext::is_authorized >>> >>> ./share/memory/universe.hpp:? static Method* >>> protection_domain_implies_method() >>> >> >> Good catches!? I have uploaded a new webrev: >> >> http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ >> http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental >> diff) > > Updates all look fine. > > Thanks, > David > ----- > >> dl >> >>> --- >>> >>> Thanks, >>> David >>> >>> >>> On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>>> >>>> This change implements AccessController.doPrivileged in Java. This >>>> gives a performance improvement while also being useful to Project >>>> Loom by removing the Java --> native --> Java transition.? One >>>> reason doPrivileged has historically been in native is because of >>>> the need to guarantee the cleanup of the privileged context when >>>> doPrivileged returns.? To do that in Java, the information that >>>> AccessController.getContext needs is pushed onto the Java stack as >>>> arguments to a method that getContext will recognize during its >>>> stack walk.? This allows us to remove the native privileged stack >>>> while guaranteeing that the privileged context goes away when the >>>> method returns. >>>> >>>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>>> api/java_security tests.? For the first few rounds of testing, I >>>> kept the old native privileged stack and compared the results of >>>> the old and new implementations for each getContext call, which did >>>> catch some early bugs.? The changes were also examined by internal >>>> security experts and run through additional internal security tests. >>>> >>>> The improvement on this [1] doPrivileged microbenchmark is >>>> approximate 50x. >>>> >>>> There is no attempt to optimize getContext() or security permission >>>> checks in this change, however, this is intended to be a first step >>>> towards other possible improvements, for example those proposed >>>> here [2]. >>>> >>>> dl >>>> >>>> [1] >>>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>>> >>>> >> From dean.long at oracle.com Thu Nov 1 03:59:12 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 20:59:12 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <920b1841-53cf-23c1-1f35-365518935ee0@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> <920b1841-53cf-23c1-1f35-365518935ee0@oracle.com> Message-ID: Thanks Ioi. dl On 10/31/18 6:01 PM, Ioi Lam wrote: > > > On 10/31/18 5:13 PM, dean.long at oracle.com wrote: >> On 10/31/18 4:06 PM, David Holmes wrote: >>> Hi Dean, >>> >>> Looking only at the hotspot changes. The removal of the DoPrivileged >>> and related privileged_stack code seems okay. I have a few related >>> comments: >>> >>> src/hotspot/share/classfile/systemDictionary.hpp >>> >>> You added the java_security_AccessController class after >>> java_security_AccessControlContext. Did you actually verify where in >>> the load/initialization order the AccessController class appears >>> today, and where it appears after your change? (Note the comments at >>> the start of WK_KLASSES_DO). Changes to the initialization order >>> would be my biggest concern with this patch. >>> >> >> No, I did not notice that comment and assumed alphabetical order was >> OK here.? However, these classes appear to be only resolved, not >> initialized (and AccessController does not have a static >> initializer), so could you explain how the order in this list can >> affect initialization order? >> >> I only need this in JVM_GetStackAccessControlContext, which is a >> static JNI method, so I could get the klass* from the incoming jclass >> instead of using a well-known class entry. > > Hi Dean, > > You're correct that those classes are only resolved, and not > initialized. So the order shouldn't matter too much. However, the > order of the first few classes is important, as the creation of > Object, Serializable, Cloneable, String, etc, has to be done in a > certain order. > > I'm not sure whether the order of the reference classes, 292 classes, > and box classes are important. I'll experiment of getting rid of the > separate phases after the call to Universe::fixup_mirrors(). This > might be relics from old days where the classes were once indeed > initialized in SystemDictionary::initialize_well_known_classes, which > was the old name for SystemDictionary::resolve_well_known_classes. > > (-XX:+TraceBytecodes shows no Java code is executed before > resolve_well_known_classes returns). > > I filed https://bugs.openjdk.java.net/browse/JDK-8213230 > > For the time being, I think as long as you put the new > AccessController class near the existing class AccessControlContext, > you should be OK. > > Thanks > - Ioi >> >>> --- >>> >>> I'm unclear about the change to the test: >>> >>> test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm >>> >>> as it still refers to the now non-existent JVM_DoPrivileged in the >>> summary. Does this test still make sense? Should it be moved to the >>> Java side now it doesn't actually test anything in the VM? >>> >> >> I think these tests still make sense, unless we have similar coverage >> somewhere else.? How about if I fix the reference to JVM_DoPrivileged >> for now and file a separate bug about moving or removing these tests? >> >>> --- >>> >>> There may be further dead code to remove now: >>> >>> vmSymbols.hpp: codesource_permissioncollection_signature is now >>> unreferenced and can be removed. >>> >>> javaClasses.*: >>> ? - java_lang_System::has_security_manager >>> ? - java_security_AccessControlContext::is_authorized >>> >>> ./share/memory/universe.hpp:? static Method* >>> protection_domain_implies_method() >>> >> >> Good catches!? I have uploaded a new webrev: >> >> http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ >> http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental >> diff) >> >> dl >> >>> --- >>> >>> Thanks, >>> David >>> >>> >>> On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>>> >>>> This change implements AccessController.doPrivileged in Java. This >>>> gives a performance improvement while also being useful to Project >>>> Loom by removing the Java --> native --> Java transition.? One >>>> reason doPrivileged has historically been in native is because of >>>> the need to guarantee the cleanup of the privileged context when >>>> doPrivileged returns.? To do that in Java, the information that >>>> AccessController.getContext needs is pushed onto the Java stack as >>>> arguments to a method that getContext will recognize during its >>>> stack walk.? This allows us to remove the native privileged stack >>>> while guaranteeing that the privileged context goes away when the >>>> method returns. >>>> >>>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>>> api/java_security tests.? For the first few rounds of testing, I >>>> kept the old native privileged stack and compared the results of >>>> the old and new implementations for each getContext call, which did >>>> catch some early bugs.? The changes were also examined by internal >>>> security experts and run through additional internal security tests. >>>> >>>> The improvement on this [1] doPrivileged microbenchmark is >>>> approximate 50x. >>>> >>>> There is no attempt to optimize getContext() or security permission >>>> checks in this change, however, this is intended to be a first step >>>> towards other possible improvements, for example those proposed >>>> here [2]. >>>> >>>> dl >>>> >>>> [1] >>>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>>> >>>> >> > From dean.long at oracle.com Thu Nov 1 04:06:22 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 21:06:22 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> Message-ID: <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> I think it's a good idea, but I believe it would require a CSR request.? Do you mind if I file a separate issue for jdk.internal.vm.annotation.Hidden? dl On 10/31/18 6:11 PM, Vladimir Ivanov wrote: > Dean, > > src/java.base/share/classes/java/security/AccessController.java: > +??? /** > +???? * Internal marker for hidden implementation frames. > +???? */ > +??? /*non-public*/ > +??? @Target(ElementType.METHOD) > +??? @Retention(RetentionPolicy.RUNTIME) > +??? @interface Hidden { > +??? } > > You declare @Hidden, but then map it to _method_Hidden along with > @Hidden from java.lang.invoke.LambdaForm. > > What do you think about moving LambdaForm.Hidden to > jdk.internal.vm.annotation instead and share among all usages? > > Best regards, > Vladimir Ivanov > > On 31/10/2018 15:23, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8212605 >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >> >> This change implements AccessController.doPrivileged in Java. This >> gives a performance improvement while also being useful to Project >> Loom by removing the Java --> native --> Java transition.? One reason >> doPrivileged has historically been in native is because of the need >> to guarantee the cleanup of the privileged context when doPrivileged >> returns.? To do that in Java, the information that >> AccessController.getContext needs is pushed onto the Java stack as >> arguments to a method that getContext will recognize during its stack >> walk.? This allows us to remove the native privileged stack while >> guaranteeing that the privileged context goes away when the method >> returns. >> >> Tested with tier1-tier3 hotspot and jdk tests and JCK >> api/java_security tests.? For the first few rounds of testing, I kept >> the old native privileged stack and compared the results of the old >> and new implementations for each getContext call, which did catch >> some early bugs.? The changes were also examined by internal security >> experts and run through additional internal security tests. >> >> The improvement on this [1] doPrivileged microbenchmark is >> approximate 50x. >> >> There is no attempt to optimize getContext() or security permission >> checks in this change, however, this is intended to be a first step >> towards other possible improvements, for example those proposed here >> [2]. >> >> dl >> >> [1] >> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >> >> From ecki at zusammenkunft.net Thu Nov 1 04:39:08 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 1 Nov 2018 04:39:08 +0000 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com>, <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> Message-ID: http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html In checkContext should the security manager be null checked first instead of last to optimize for the typical case? (If the side effects in that expression are desired it should be documented) I find the tail call optimization comment in wrapException adds only confusion to an otherwise clear helper. But maybe it?s just me who does not understand it. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Vladimir Ivanov Gesendet: Donnerstag, November 1, 2018 5:11 AM An: dean.long at oracle.com; security-dev at openjdk.java.net; core-libs-dev Libs; hotspot-dev developers Betreff: Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged Dean, src/java.base/share/classes/java/security/AccessController.java: + /** + * Internal marker for hidden implementation frames. + */ + /*non-public*/ + @Target(ElementType.METHOD) + @Retention(RetentionPolicy.RUNTIME) + @interface Hidden { + } You declare @Hidden, but then map it to _method_Hidden along with @Hidden from java.lang.invoke.LambdaForm. What do you think about moving LambdaForm.Hidden to jdk.internal.vm.annotation instead and share among all usages? Best regards, Vladimir Ivanov On 31/10/2018 15:23, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8212605 > http://cr.openjdk.java.net/~dlong/8212605/webrev.1 > > This change implements AccessController.doPrivileged in Java. This > gives a performance improvement while also being useful to Project Loom > by removing the Java --> native --> Java transition. One reason > doPrivileged has historically been in native is because of the need to > guarantee the cleanup of the privileged context when doPrivileged > returns. To do that in Java, the information that > AccessController.getContext needs is pushed onto the Java stack as > arguments to a method that getContext will recognize during its stack > walk. This allows us to remove the native privileged stack while > guaranteeing that the privileged context goes away when the method returns. > > Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security > tests. For the first few rounds of testing, I kept the old native > privileged stack and compared the results of the old and new > implementations for each getContext call, which did catch some early > bugs. The changes were also examined by internal security experts and > run through additional internal security tests. > > The improvement on this [1] doPrivileged microbenchmark is approximate 50x. > > There is no attempt to optimize getContext() or security permission > checks in this change, however, this is intended to be a first step > towards other possible improvements, for example those proposed here [2]. > > dl > > [1] > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Thu Nov 1 05:29:24 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 22:29:24 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> Message-ID: <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> Hi Bernd, On 10/31/18 9:39 PM, Bernd Eckenfels wrote: > http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html > > In checkContext should the security manager be null checked first instead of last to optimize for the typical case? (If the side effects in that expression are desired it should be documented) I was following the example of createWrapper.? The side-effects of getInnocuousAcc() will only happen once, so the order shouldn't matter here, except for performance reasons.? I don't have a strong opinion about the order, but it looks like the typical case for createWrapper would also be the typical case for checkContext, so maybe they both should be changed, if indeed a null security manager is the more typical case. > I find the tail call optimization comment in wrapException adds only confusion to an otherwise clear helper. But maybe it?s just me who does not understand it. OK, I'm happy to remove it if it's confusing or not helpful.? The reason for the other @ForceInline and @ReservedStackAccess annotations is to reduce that chance of getting a StackOverflowError, and tail call elimination would also help with that.? Let's see if anyone else finds the comment helpful or confusing. dl > Gruss > Bernd > -- > http://bernd.eckenfels.net > > ________________________________ > Von: core-libs-dev im Auftrag von Vladimir Ivanov > Gesendet: Donnerstag, November 1, 2018 5:11 AM > An: dean.long at oracle.com; security-dev at openjdk.java.net; core-libs-dev Libs; hotspot-dev developers > Betreff: Re: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged > > Dean, > > src/java.base/share/classes/java/security/AccessController.java: > + /** > + * Internal marker for hidden implementation frames. > + */ > + /*non-public*/ > + @Target(ElementType.METHOD) > + @Retention(RetentionPolicy.RUNTIME) > + @interface Hidden { > + } > > You declare @Hidden, but then map it to _method_Hidden along with > @Hidden from java.lang.invoke.LambdaForm. > > What do you think about moving LambdaForm.Hidden to > jdk.internal.vm.annotation instead and share among all usages? > > Best regards, > Vladimir Ivanov > > On 31/10/2018 15:23, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8212605 >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >> >> This change implements AccessController.doPrivileged in Java. This >> gives a performance improvement while also being useful to Project Loom >> by removing the Java --> native --> Java transition. One reason >> doPrivileged has historically been in native is because of the need to >> guarantee the cleanup of the privileged context when doPrivileged >> returns. To do that in Java, the information that >> AccessController.getContext needs is pushed onto the Java stack as >> arguments to a method that getContext will recognize during its stack >> walk. This allows us to remove the native privileged stack while >> guaranteeing that the privileged context goes away when the method returns. >> >> Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security >> tests. For the first few rounds of testing, I kept the old native >> privileged stack and compared the results of the old and new >> implementations for each getContext call, which did catch some early >> bugs. The changes were also examined by internal security experts and >> run through additional internal security tests. >> >> The improvement on this [1] doPrivileged microbenchmark is approximate 50x. >> >> There is no attempt to optimize getContext() or security permission >> checks in this change, however, this is intended to be a first step >> towards other possible improvements, for example those proposed here [2]. >> >> dl >> >> [1] >> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >> >> From weijun.wang at oracle.com Thu Nov 1 08:19:30 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 1 Nov 2018 16:19:30 +0800 Subject: RFR 8212217: JGSS: Don't dispose() of creds too eagerly In-Reply-To: <20181031212504.GI26310@twosigma.com> References: <1dc74431-222d-2b83-1e24-3b7839f85a65@oracle.com> <3A967B4D-BCF7-47E0-AA9C-75111386C3CE@oracle.com> <20181031212504.GI26310@twosigma.com> Message-ID: > On Nov 1, 2018, at 5:25 AM, Nico Williams wrote: > >>> Otherwise looks fine. You will need to add a noreg label if you can't write a test. >> >> Yes. > > Not sure what that means. https://openjdk.java.net/guide/changePlanning.html#noreg. I'll add a noreg-hard due to complex setup. *Sean*, I'll add the braces. Do you have other comments? Thanks Max From weijun.wang at oracle.com Thu Nov 1 08:41:15 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 1 Nov 2018 16:41:15 +0800 Subject: RFR 8026953: Add support for MS Cryptography next generation (CNG) (step 1) In-Reply-To: <93ffbdad-524a-ae6d-91c9-25574fb91ff9@comcast.net> References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <135316bf-6810-d572-b6a5-feee584d596a@comcast.net> <07189124-90E7-4A36-8FCA-14B912AB928E@oracle.com> <93ffbdad-524a-ae6d-91c9-25574fb91ff9@comcast.net> Message-ID: <8B5A532E-DCF5-4406-B638-703FAB8BAA8C@oracle.com> > On Oct 30, 2018, at 2:22 AM, Michael StJohns wrote: > > On 10/25/2018 11:09 PM, Weijun Wang wrote: >> Hi Mike >> >> Thanks for the feedback. >> >> I understand the current SunMSCAPI implementation recognizes RSA keys only and it's certainly incorrect to put something like getModulus() and getPublicExponent() in a general CKey class. They will be fixed later. When I have more sub class names, I'll definitely use them. You can see I've moved some CSignature methods into CSignature$RSA. I just haven't done it everywhere. > OK. >> >> We'll still need a base CKey for a CNG key, no matter what the underlying algorithm is. Since CNG uses the same NCRYPT_KEY_HANDLE type for different types of keys, we will do something similar on the Java side. Since the current CPublicKey and CPrivateKey are very light, it will be easy to move the content into algorithm-specific classes. > This is where I think you need to fix the structure: > > abstract class CKey > > public class CRSAPublicKey extends CKey implements RSAKey, RSAPublicKey, PublicKey > public class CRSAExtractablePrivateKey extends CKey implements RSAKey, RSAPrivateKey, PrivateKey[,RSAMultiPrimePrivateCrt | RSAPrivateCrtKey] > public class CRSAPrivateKey extends CKey implements RSAKey, PrivateKey > > public class CECPublicKey extends CKey implements ECKey, ECPublicKey, PublicKey > public class CECExtractablePrivateKey extends CKey implements ECKey, PrivateKey > public class CECPrivateKey extends CKey implements ECKey, ECPrivateKey, ECPrivateKey Very likely. I'll get the signature signing/verification working first, and then will have time to expose the key info with these classes. > > Note the two different versions of the private keys to match up with the key handling bits as well as some additional interfaces that may be needed to be added to support the underlying provider's requirements for the RSA keys. > > Also, I'm looking ahead a little bit and thinking about how the JCA would use the windows PCP (Platform Crypto Provider) which uses the TPM to enforce hardware security. It would be useful if you didn't have to re-write everything just because of a different underlying Windows provider. (There's a PCP development kit that's got some useful sample code that might help a little bit with refactoring the JCA MSCAPI provider even for the existing code). E.g. eventually supporting an MSCAPI-PCP provider shouldn't require all new code. Great. I really need more sample code to study. > >> >> The main reason I want to take this first step is that after some study on CNG I make some progress and also see some blockers. For example, I am able to expose a EC CNG key stored in Windows-MY now and use it to sign/verify. However, I still don't know how to import external keys inside there (certmgr.exe can so it's possible). Until now, the most requested function is to use existing keys in signatures and I want to start working on it. The first thing I noticed then is that the current class names are unsuitable and I think a refactoring will make them look better. > AFAICT, you're not going to be able to use any external key without importing it or running it through a key factory. The main class you're going to be using is NCryptImportKey (or alternately BCryptImportKeyPair). I tried NCryptCreatePersistedKey and NCryptImportKey but there are always some flags I cannot get right. > >> >> Once I start working on the next step, I'll need to have different sub classes in CKey and CSignature. I even have an alternative plan to ditch CPublicKey and use the PublicKey classes in SunEC and SunRsaSign. This was actually already used in the RSASSA-PSS signature handling in SunMSCAPI we added into JDK 11 in the last minute. > > So you just use software classes in another provider for encrypting/verifying? To be honest this sounds messy and may come back to bite you down the road. In JDK 11 that was a workaround because I don't have time to get the native verifying part correctly. I don't mean that's a better solution. > >> >> As for KeyFactory, we do not have an urgent requirement to use external keys in a CNG Signature object or store them into Windows-MY. Also, we can use the one in SunRsaSign. > Hmm... one of the more common things is to move around .p12 files with your certs and keys. They can be imported by the Windows tools - it would be *really* nice if you can do the same thing with the Java provider. That's how I am testing now. Creating p12 files in Java and import them using certmgr.exe and then see if I can signing from inside Windows. In Java, either there will be a factory class or the CKeyStore::setKey method will need to understand soft keys. Thanks Max > >> >> Thanks again. >> >> --Max >> >>> On Oct 26, 2018, at 1:25 AM, Michael StJohns wrote: >>> >>> Hi Max - >>> >>> For the same reason I was pushing back on Adam's EC provider I think I need to push back here. You're recasting an RSAPublicKey to just a PublicKey and making it difficult to move key material in and out of the MSCAPI proivider. Same thing with the private key. >>> >>> For example, in the CPublicKey class you still have "getModulus()" and "getPublicExponent()", but to get at them you'd have to use CPublicKey rather than PublicKey. >>> >>> And looking forward, I'm not sure how you actually implement the EC classes here using this model. >>> >>> I'd suggest not making the change this way and overloading the existing classes, but instead adding the appropriate provider classes for new key types as you implement support for them. E.g. Keep CRSAKey, CRSAPublicKey and CRSAPrivateKey as distinct classes, add CECKey, CECPublicKey and CECPrivateKey when you get there. >>> >>> Are you missing a KeyFactory class as well? >>> >>> Lastly, you may want to change the subclass/methods for CSignature (and probably other classes) to reflect the type of Signature you're returning: >>> >>>> if (algo.equals("NONEwithRSA")) { >>>> >>>> - return new RSASignature.Raw(); >>>> + return new CSignature.Raw(); >>> Instead: "return new CSignature.RSARaw()" >>> >>> And this definitely isn't going to work if you have even one other Cipher you'll be returning: >>>> if (algo.equals("RSA") || >>>> algo.equals("RSA/ECB/PKCS1Padding")) { >>>> >>>> - return new RSACipher(); >>>> + return new CCipher(); >>>> >>>> } >>>> >>> >>> Later, Mike >>> >>> >>> >>> >>> >>> On 10/25/2018 4:38 AM, Weijun Wang wrote: >>>> Please review the change at >>>> >>>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >>>> >>>> >>>> (I will use a sub-task id for this change but currently JBS is down). >>>> >>>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >>>> >>>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >>>> >>>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >>>> >>>> - Child class named "RSA" of CKeyPairGenerator. >>>> >>>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >>>> >>>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >>>> >>>> Noreg-cleanup. >>>> >>>> Thanks >>>> Max >>>> >>>> [1] >>>> https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier > > From gnu.andrew at redhat.com Thu Nov 1 11:12:14 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 1 Nov 2018 11:12:14 +0000 Subject: [RFR] JDK-8213154: Update copyright headers of files in src tree that are missing Classpath exception In-Reply-To: References: Message-ID: On Tue, 30 Oct 2018 at 18:00, Martin Balao wrote: > > Hi, > > You're right, this is not relevant for a test. > > * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.01 > * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.01.zip > > Thanks, > Martin.- > > On Tue, Oct 30, 2018 at 2:50 PM, Alan Bateman wrote: >> >> On 30/10/2018 17:44, Martin Balao wrote: >> >> Hi, >> >> Can I have a review for JDK-8213154 [1]? >> >> * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.00/ >> * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.00.zip >> >> Did you mean to include a test in this update? Just asking because tests doesn't usually have the Classpath exception. >> >> -Alan > > Classpath exception addition looks fine and appropriate for the JDK code. The "All rights reserved" additions are unnecessary for RH copyrights. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From chris.hegarty at oracle.com Thu Nov 1 11:57:02 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 1 Nov 2018 11:57:02 +0000 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: <55db048d-b47e-deec-839d-ae25e2c70982@oracle.com> References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <55db048d-b47e-deec-839d-ae25e2c70982@oracle.com> Message-ID: <3DDC3134-3C1B-41A0-AE63-98623662C748@oracle.com> > On 31 Oct 2018, at 20:03, Xuelei Fan wrote: >> ... > Yes. I had the same concern about the optional operation. However, I came to a different conclusion if I'm from viewpoint of these users that need to use this new operation. > > If an application have to use this new operation, for example to access the negotiated TLS version, this operation is essential to it. Unfortunately, because of compatibility impact, we cannot force all implementation supports this new added operation. It is a potential problem to those applications that need it. > > It would be nice if an implementation can support this operation as soon as possible. If we just add the operation, providers may not aware there is a need to update their implementation. Unfortunately. there is not much we can do to notify the provider. > > If we deprecated the duplicated methods, it is easier for providers to catch up with this new added operation, and move forward to support it. As the deprecating will show up building warnings, or even error if run in strict building mode. I have no issue with the addition of the new method to access the SSLSession. Unfortunately, due to the evolutionary constraints of this API, the `getSSLSession` method will likely need to be specified to throw UOE. The actual JDK's HTTPS protocol handler implementation will not throw UOE. Clearly there is a desire for non-JDK HTTPS protocol handler implementations to quickly determine the need to update their code and override the default implementation of `getSSLSession` ( to do something useful ), hence the request to deprecate the the existing individual security parameter accessor methods. I don't believe that deprecating these individual security parameter accessors is a good idea for the following reasons: 1) Deprecated warnings are only issued at compile-time, so only HTTPS protocol handler implementations being recompiled may encounter the warnings. Existing binary artifacts will not. 2) More importantly. Forever more, developers wanting access to say, the peer principle or the server's certificate chain, will be encouraged to get them through an optional API ( rather than a non-optional API ). This increases the risk that the code will encounter an UOE. I don't think that this increased risk is justified by the desire to not-have-two-ways-to-do-the-same-thing. I would agree if this were a new API, but it is not. HTTPS protocol handler implementations actively being maintained will likely quickly get requests from their users to provide a better implementation of this new method, as folk move towards TLS 1.3, etc. Maybe such requests will be sufficient to help adoption, at which point the deprecation of these methods could then be re-considered. -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Nov 1 12:17:35 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 08:17:35 -0400 Subject: RFR 8212217: JGSS: Don't dispose() of creds too eagerly In-Reply-To: References: <1dc74431-222d-2b83-1e24-3b7839f85a65@oracle.com> <3A967B4D-BCF7-47E0-AA9C-75111386C3CE@oracle.com> <20181031212504.GI26310@twosigma.com> Message-ID: <06d578eb-e394-d15f-0857-ee1e04b5f05b@oracle.com> On 11/1/18 4:19 AM, Weijun Wang wrote: > >> On Nov 1, 2018, at 5:25 AM, Nico Williams wrote: >> >>>> Otherwise looks fine. You will need to add a noreg label if you can't write a test. >>> >>> Yes. >> >> Not sure what that means. > > https://openjdk.java.net/guide/changePlanning.html#noreg. > > I'll add a noreg-hard due to complex setup. > > *Sean*, I'll add the braces. Do you have other comments? No, looks good. --Sean From sean.mullan at oracle.com Thu Nov 1 14:57:04 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 10:57:04 -0400 Subject: RFR (12): 8212669: Add note to Cipher javadoc about using full transformation and not relying on defaults Message-ID: Please review this javadoc-only change to the Cipher class. An @apiNote has been added to each of the getInstance methods to recommend that the full transformation be specified when creating a Cipher and to avoid relying on the defaults. Also a link to the defaults used by the JDK providers has been added as an @implNote. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8212669/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8212669 Thanks, Sean From xuelei.fan at oracle.com Thu Nov 1 15:27:41 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 1 Nov 2018 08:27:41 -0700 Subject: RFR (12): 8212669: Add note to Cipher javadoc about using full transformation and not relying on defaults In-Reply-To: References: Message-ID: What do you think if adding a note that the default value may be different for each provider, and may be changed from time to time with the development of crypto analysis? Xuelei On 11/1/2018 7:57 AM, Sean Mullan wrote: > Please review this javadoc-only change to the Cipher class. An @apiNote > has been added to each of the getInstance methods to recommend that the > full transformation be specified when creating a Cipher and to avoid > relying on the defaults. Also a link to the defaults used by the JDK > providers has been added as an @implNote. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8212669/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8212669 > > Thanks, > Sean From mbalao at redhat.com Thu Nov 1 15:40:55 2018 From: mbalao at redhat.com (Martin Balao) Date: Thu, 1 Nov 2018 12:40:55 -0300 Subject: [RFR] JDK-8213154: Update copyright headers of files in src tree that are missing Classpath exception In-Reply-To: References: Message-ID: Hi Andrew, Thanks for having a look at this. Webrev.02 without "All rights reserved" and "affiliates" parts: * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.02/ * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.02.zip Are you okay to go? Kind regards, Martin.- On Thu, Nov 1, 2018 at 8:12 AM, Andrew Hughes wrote: > On Tue, 30 Oct 2018 at 18:00, Martin Balao wrote: > > > > Hi, > > > > You're right, this is not relevant for a test. > > > > * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.01 > > * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/ > 8213154.webrev.01.zip > > > > Thanks, > > Martin.- > > > > On Tue, Oct 30, 2018 at 2:50 PM, Alan Bateman > wrote: > >> > >> On 30/10/2018 17:44, Martin Balao wrote: > >> > >> Hi, > >> > >> Can I have a review for JDK-8213154 [1]? > >> > >> * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/ > 8213154.webrev.00/ > >> * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/ > 8213154.webrev.00.zip > >> > >> Did you mean to include a test in this update? Just asking because > tests doesn't usually have the Classpath exception. > >> > >> -Alan > > > > > > Classpath exception addition looks fine and appropriate for the JDK > code. The "All rights reserved" additions are unnecessary for RH > copyrights. > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Web Site: http://fuseyism.com > Twitter: https://twitter.com/gnu_andrew_java > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Nov 1 15:47:12 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 11:47:12 -0400 Subject: RFR (12): 8212669: Add note to Cipher javadoc about using full transformation and not relying on defaults In-Reply-To: References: Message-ID: <5ca32d2d-f2e1-7ae2-9cb2-f814e368921d@oracle.com> On 11/1/18 11:27 AM, Xuelei Fan wrote: > What do you think if adding a note that the default value may be > different for each provider, and may be changed from time to time with > the development of crypto analysis? I didn't want to get too wordy, just to make a concise point that defaults can be problematic and are not recommended. My preference would be to put more wording like that in the security guides. --Sean > > Xuelei > > On 11/1/2018 7:57 AM, Sean Mullan wrote: >> Please review this javadoc-only change to the Cipher class. An >> @apiNote has been added to each of the getInstance methods to >> recommend that the full transformation be specified when creating a >> Cipher and to avoid relying on the defaults. Also a link to the >> defaults used by the JDK providers has been added as an @implNote. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8212669/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8212669 >> >> Thanks, >> Sean From xuelei.fan at oracle.com Thu Nov 1 15:56:14 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 1 Nov 2018 08:56:14 -0700 Subject: RFR (12): 8212669: Add note to Cipher javadoc about using full transformation and not relying on defaults In-Reply-To: <5ca32d2d-f2e1-7ae2-9cb2-f814e368921d@oracle.com> References: <5ca32d2d-f2e1-7ae2-9cb2-f814e368921d@oracle.com> Message-ID: <5feaeb38-ca4e-936b-149b-050a22623ed2@oracle.com> Okay. Looks fine to me. Thanks, Xuelei On 11/1/2018 8:47 AM, Sean Mullan wrote: > On 11/1/18 11:27 AM, Xuelei Fan wrote: >> What do you think if adding a note that the default value may be >> different for each provider, and may be changed from time to time with >> the development of crypto analysis? > > I didn't want to get too wordy, just to make a concise point that > defaults can be problematic and are not recommended. My preference would > be to put more wording like that in the security guides. > > --Sean > >> >> Xuelei >> >> On 11/1/2018 7:57 AM, Sean Mullan wrote: >>> Please review this javadoc-only change to the Cipher class. An >>> @apiNote has been added to each of the getInstance methods to >>> recommend that the full transformation be specified when creating a >>> Cipher and to avoid relying on the defaults. Also a link to the >>> defaults used by the JDK providers has been added as an @implNote. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8212669/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8212669 >>> >>> Thanks, >>> Sean From xuelei.fan at oracle.com Thu Nov 1 16:34:06 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 1 Nov 2018 09:34:06 -0700 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: <3DDC3134-3C1B-41A0-AE63-98623662C748@oracle.com> References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <55db048d-b47e-deec-839d-ae25e2c70982@oracle.com> <3DDC3134-3C1B-41A0-AE63-98623662C748@oracle.com> Message-ID: <00fc9685-b76f-14e4-c96d-f50421ba4d4e@oracle.com> I removed the deprecation parts in the update. Here is the new webrev: http://cr.openjdk.java.net/~xuelei/8212261/webrev.01/ And the CSR was updated accordingly. https://bugs.openjdk.java.net/browse/JDK-8213161 Thanks, Xuelei On 11/1/2018 4:57 AM, Chris Hegarty wrote: > >> On 31 Oct 2018, at 20:03, Xuelei Fan > > wrote: >>> ... >> Yes. ?I had the same concern about the optional operation. ?However, I >> came to a different conclusion if I'm from viewpoint of?these users >> that need to use this new operation. >> >> If an application have to use this new operation, for example to >> access the negotiated TLS version, this operation is essential to?it. >> Unfortunately, because of compatibility impact, we cannot force all >> implementation supports this new added operation. ?It is a?potential >> problem to those applications that need it. >> >> It would be nice if an implementation can support this operation as >> soon as possible. ?If we just add the operation, providers?may not >> aware there is a need to update their implementation. ?Unfortunately. >> there is not much we can do to notify the provider. >> >> If we deprecated the duplicated methods, it is easier for providers to >> catch up with this new added operation, and move forward?to support >> it. As the deprecating will show up building warnings, or even error >> if run in strict building mode. > > I have no issue with the addition of the new method to access the > SSLSession. Unfortunately, due to the evolutionary constraints of this > API, the `getSSLSession` method will likely need to be specified to > throw UOE. The actual JDK's HTTPS protocol handler implementation will > not throw UOE. > > Clearly there is a desire for non-JDK HTTPS protocol handler > implementations to quickly determine the need to update their code and > override the default implementation of `getSSLSession` ( to do something > useful ), hence the request to deprecate the the existing individual > security parameter accessor methods. > > I don't believe that deprecating these individual security parameter > accessors is a good idea for the following reasons: > > 1) Deprecated warnings are only issued at compile-time, so only HTTPS > ? ?protocol handler implementations being recompiled may encounter the > ? ?warnings. Existing binary artifacts will not. > > 2) More importantly. Forever more, developers wanting access to say, > ? ?the peer principle or the server's certificate chain, will be > ? ?encouraged to get them through an optional API ( rather than a > ? ?non-optional API ). This increases the risk that the code will > ? ?encounter an UOE. I don't think that this increased risk is justified > ? ?by the desire to not-have-two-ways-to-do-the-same-thing. I would > ? ?agree if this were a new API, but it is not. > > HTTPS protocol handler implementations actively being maintained will > likely quickly get requests from their users to provide a better > implementation of this new method, as folk move towards TLS 1.3, etc. > Maybe such requests will be sufficient to help adoption, at which point > the deprecation of these methods could then be re-considered. > > -Chris. > > From sean.mullan at oracle.com Thu Nov 1 16:48:57 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 12:48:57 -0400 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> Message-ID: <8c969cca-fab2-4731-3d81-a956c1898677@oracle.com> On 11/1/18 1:29 AM, dean.long at oracle.com wrote: > On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html >> >> >> In checkContext should the security manager be null checked first >> instead of last to optimize for the typical case? (If the side effects >> in that expression are desired it should be documented) > > I was following the example of createWrapper.? The side-effects of > getInnocuousAcc() will only happen once, so the order shouldn't matter > here, except for performance reasons.? I don't have a strong opinion > about the order, but it looks like the typical case for createWrapper > would also be the typical case for checkContext, so maybe they both > should be changed, if indeed a null security manager is the more typical > case. A null SM should be the more common case. I am ok with changing the order so the SM is checked first, but it should be done in both the createWrapper and checkContext methods. Alternatively, we could see if they could be combined to eliminate the duplicate code but that might not be practical from looking at them. --Sean From sean.mullan at oracle.com Thu Nov 1 17:01:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 13:01:26 -0400 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> Message-ID: <670ff93f-e8e0-d7a0-d410-daa42b5a9a32@oracle.com> Some of the copyrights need to be updated to 2018. All else looks good to me as I had reviewed an earlier version of this before. We have talked about doing this for a while now, so I am finally glad we and are able to pretty much eliminate one of the more common SecurityManager related hot-spots and give a performance boost to applications that don't use the SM as well. --Sean On 10/31/18 6:23 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8212605 > http://cr.openjdk.java.net/~dlong/8212605/webrev.1 > > This change implements AccessController.doPrivileged in Java.? This > gives a performance improvement while also being useful to Project Loom > by removing the Java --> native --> Java transition.? One reason > doPrivileged has historically been in native is because of the need to > guarantee the cleanup of the privileged context when doPrivileged > returns.? To do that in Java, the information that > AccessController.getContext needs is pushed onto the Java stack as > arguments to a method that getContext will recognize during its stack > walk.? This allows us to remove the native privileged stack while > guaranteeing that the privileged context goes away when the method returns. > > Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security > tests.? For the first few rounds of testing, I kept the old native > privileged stack and compared the results of the old and new > implementations for each getContext call, which did catch some early > bugs.? The changes were also examined by internal security experts and > run through additional internal security tests. > > The improvement on this [1] doPrivileged microbenchmark is approximate 50x. > > There is no attempt to optimize getContext() or security permission > checks in this change, however, this is intended to be a first step > towards other possible improvements, for example those proposed here [2]. > > dl > > [1] > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html > > From dean.long at oracle.com Thu Nov 1 17:15:30 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 1 Nov 2018 10:15:30 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <5BDA5399.4030509@zeus.net.au> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> <4fe219c8-7e29-1bfb-839d-1e1caab34efa@oracle.com> <5BDA5399.4030509@zeus.net.au> Message-ID: Hi Peter.? Thanks for the input.? I don't know about DomainCombiner, but perhaps someone else on this list does. dl On 10/31/18 6:15 PM, Peter wrote: > Hello Dean & David, > > Interesting reading.?? Is DomainCombiner still being considered for > deprecation? > > Our code makes heavy use of AccessController.doPrivileged. > > Regards, > > Peter. > > "Hot Spots - Method","Self time [%]","Self time","Self time > (CPU)","Samples" > "java.net.DualStackPlainSocketImpl.accept0[native]()","38.88627","1837851.568 > ms","1837851.568 ms","16" > "java.net.SocketInputStream.socketRead0[native]()","20.505322","969127.11 > ms","969127.11 ms","315" > "java.net.TwoStacksPlainDatagramSocketImpl.peekData[native]()","20.19654","954533.467 > ms","954533.467 ms","11" > "sun.management.ThreadImpl.dumpThreads0[native]()","11.148865","526920.162 > ms","526920.162 ms","239" > "java.net.TwoStacksPlainDatagramSocketImpl.socketNativeSetOption[native]()","5.3582244","253241.609 > ms","253241.609 ms","17" > "sun.misc.Unsafe.unpark[native]()","2.6599514","125715.216 > ms","125715.216 ms","759" > "sun.misc.Unsafe.park[native]()","0.19931908","1.6213131447E7 > ms","9420.263 ms","1401" > "java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.siftDown()","0.15738875","7438.542 > ms","7438.542 ms","71" > "java.security.AccessController.doPrivileged[native]()","0.10248028","4843.446 > ms","4843.446 ms","715" > "java.lang.Thread.isInterrupted[native]()","0.09570652","4523.303 > ms","4523.303 ms","40" > "java.net.NetworkInterface.getAll[native]()","0.07478044","3534.29 > ms","3534.29 ms","4" > "java.util.concurrent.ThreadPoolExecutor.runWorker()","0.046051156","2176.48 > ms","2176.48 ms","91" > "java.lang.SecurityManager.getClassContext[native]()","0.043098312","2036.922 > ms","2036.922 ms","20" > "java.security.AccessController.getStackAccessControlContext[native]()","0.039155032","1850.554 > ms","1850.554 ms","15" > "au.net.zeus.collection.ReferenceProcessor$EnqueGarbageTask.run()","0.035316195","1669.122 > ms","1669.122 ms","18" > "java.net.SocketOutputStream.socketWrite0[native]()","0.03470353","1640.166 > ms","1640.166 ms","17" > "java.lang.Class.forName0[native]()","0.029112596","1375.926 > ms","1375.926 ms","10" > "java.lang.Throwable.fillInStackTrace[native]()","0.028279837","1336.568 > ms","1336.568 ms","18" > "java.lang.Thread.holdsLock[native]()","0.023839759","1126.72 > ms","1126.72 ms","7" > "java.lang.String.indexOf()","0.019056467","900.651 ms","900.651 ms","1" > "au.net.zeus.collection.AbstractReferenceComparator.compare()","0.017307268","817.98 > ms","817.98 ms","18" > "sun.reflect.Reflection.getCallerClass[native]()","0.017031383","804.941 > ms","804.941 ms","11" > "java.net.DualStackPlainSocketImpl.available0[native]()","0.015988858","755.669 > ms","755.669 ms","14" > "java.lang.String.intern[native]()","0.014759737","697.578 > ms","697.578 ms","8" > "au.net.zeus.collection.ReferenceMap.wrapKey()","0.0139064975","657.252 > ms","657.252 ms","4" > "org.apache.river.api.net.Uri.toAsciiLowerCase()","0.013079452","618.164 > ms","618.164 ms","1" > "sun.reflect.DelegatingMethodAccessorImpl.invoke()","0.012204483","576.811 > ms","576.811 ms","753" > "java.lang.Object.clone[native]()","0.011227106","530.618 ms","530.618 > ms","4" > "java.lang.Class.getClassLoader0[native]()","0.010788701","509.898 > ms","509.898 ms","9" > "org.apache.river.impl.thread.SynchronousExecutors$Distributor.run()","0.010243974","484.153 > ms","484.153 ms","3" > "java.util.concurrent.locks.AbstractQueuedSynchronizer.release()","0.008626911","407.727 > ms","407.727 ms","4" > "java.util.concurrent.ConcurrentSkipListMap.keyIterator()","0.008402821","397.136 > ms","397.136 ms","4" > "sun.reflect.misc.ReflectUtil.checkPackageAccess()","0.008291823","391.89 > ms","391.89 ms","8" > "java.util.concurrent.ScheduledThreadPoolExecutor.schedule()","0.0078934925","373.064 > ms","373.064 ms","1" > "sun.management.VMManagementImpl.getDaemonThreadCount[native]()","0.007857989","371.386 > ms","371.386 ms","1" > "java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take()","0.0068998444","326.102 > ms","326.102 ms","255" > "java.lang.Class.getConstantPool[native]()","0.0065752934","310.763 > ms","310.763 ms","2" > "net.jini.jeri.connection.ConnectionManager.connect()","0.0060991626","8072.071 > ms","288.26 ms","14" > "java.util.concurrent.Executors$RunnableAdapter.call()","0.006036745","285.31 > ms","285.31 ms","797" > "java.util.Collections$SynchronizedCollection.size()","0.0057329717","270.953 > ms","270.953 ms","1" > "sun.management.ThreadImpl.getThreadInfo1[native]()","0.005478752","258.938 > ms","258.938 ms","4" > "java.util.concurrent.ScheduledThreadPoolExecutor.reExecutePeriodic()","0.00411447","194.459 > ms","194.459 ms","3" > "java.lang.reflect.Array.newArray[native]()","0.003456418","163.358 > ms","163.358 ms","1" > "com.sun.jini.jeri.internal.mux.MuxInputStream.read()","0.003161764","149.432 > ms","149.432 ms","17" > "net.jini.loader.pref.PreferredClassProvider.lookupLoader()","0.0031255828","147.722 > ms","147.722 ms","2" > "java.lang.Class.isPrimitive[native]()","0.0030873707","145.916 > ms","145.916 ms","2" > "au.net.zeus.collection.ReferenceMap.get()","0.0029420536","139.048 > ms","139.048 ms","6" > "sun.reflect.MethodAccessorGenerator.buildInternalSignature()","0.0029316437","138.556 > ms","138.556 ms","1" > "sun.management.ThreadImpl.findDeadlockedThreads0[native]()","0.002746041","129.784 > ms","129.784 ms","2" > "org.apache.river.api.io.AtomicObjectInputStream.readClassDesc()","0.0026871779","127.002 > ms","127.002 ms","178" > "net.jini.security.GrantPermission.constructName()","0.0026251199","124.069 > ms","124.069 ms","1" > "java.lang.System.identityHashCode[native]()","0.002610605","123.383 > ms","123.383 ms","2" > "java.util.concurrent.locks.LockSupport.unpark()","0.0025506418","120.549 > ms","120.549 ms","760" > "java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync.readerShouldBlock()","0.0025335667","119.742 > ms","119.742 ms","2" > "java.util.concurrent.ConcurrentSkipListMap.findPredecessor()","0.0024627491","116.395 > ms","116.395 ms","4" > "java.lang.SecurityManager.checkPackageAccess()","0.0023379137","110.495 > ms","110.495 ms","1" > "java.lang.Class.checkPackageAccess()","0.0022838535","107.94 > ms","107.94 ms","5" > "net.jini.loader.LoadClass.forName()","0.002258442","106.739 > ms","106.739 ms","163" > "java.io.ObjectOutputStream$HandleTable.growSpine()","0.0022080212","104.356 > ms","104.356 ms","1" > "java.lang.AbstractStringBuilder.deleteCharAt()","0.0021902905","103.518 > ms","103.518 ms","1" > "javax.management.openmbean.CompositeDataSupport.()","0.0021849375","103.265 > ms","103.265 ms","2" > "java.io.ObjectStreamClass$FieldReflector.getObjFieldValues()","0.0021076875","99.614 > ms","99.614 ms","1" > "java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter()","0.0021062698","99.547 > ms","99.547 ms","1" > "sun.management.ThreadImpl.getThreadInfo()","0.002029676","95.927 > ms","95.927 ms","5" > "au.net.zeus.collection.AbstractReferrerDecorator.get()","0.0019218308","90.83 > ms","90.83 ms","1" > "org.apache.river.api.io.AtomicObjectInputStream$GetArgImpl.get()","0.0019038884","89.982 > ms","89.982 ms","24" > "java.util.concurrent.ConcurrentSkipListMap$Node.appendMarker()","0.0019032748","89.953 > ms","89.953 ms","1" > "java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire()","0.001819889","86.012 > ms","86.012 ms","6" > "java.security.Policy.getPolicy()","0.0017857603","84.399 ms","84.399 > ms","1" > "java.net.URL.toExternalForm()","0.0017011049","80.398 ms","80.398 > ms","2" > "java.io.ObjectOutputStream$HandleTable.lookup()","0.0016315778","77.112 > ms","77.112 ms","2" > "java.lang.Class.getSuperclass[native]()","0.0015686523","74.138 > ms","74.138 ms","1" > "net.jini.loader.pref.PreferredClassLoader.checkPermissions()","0.0015065097","71.201 > ms","71.201 ms","14" > "org.apache.river.api.security.PermissionComparator.compare()","0.0014423993","68.171 > ms","68.171 ms","2" > "org.apache.river.api.io.AtomicObjectInputStream.findStreamSuperclass()","0.0013877256","65.587 > ms","65.587 ms","1" > "java.security.AccessController.getContext()","0.0013715605","64.823 > ms","64.823 ms","17" > "java.lang.Boolean.equals()","0.0013067942","61.762 ms","61.762 ms","2" > "java.lang.String.valueOf()","0.0012928719","61.104 ms","61.104 ms","6" > "java.io.ObjectStreamField.()","0.001281023","60.544 ms","60.544 > ms","4" > "org.apache.river.api.io.AtomicObjectInputStream.getBaseName()","0.0011021064","52.088 > ms","52.088 ms","1" > > On 1/11/2018 10:54 AM, David Holmes wrote: >> Hi Dean, >> >> On 1/11/2018 10:13 AM, dean.long at oracle.com wrote: >>> On 10/31/18 4:06 PM, David Holmes wrote: >>>> Hi Dean, >>>> >>>> Looking only at the hotspot changes. The removal of the >>>> DoPrivileged and related privileged_stack code seems okay. I have a >>>> few related comments: >>>> >>>> src/hotspot/share/classfile/systemDictionary.hpp >>>> >>>> You added the java_security_AccessController class after >>>> java_security_AccessControlContext. Did you actually verify where >>>> in the load/initialization order the AccessController class appears >>>> today, and where it appears after your change? (Note the comments >>>> at the start of WK_KLASSES_DO). Changes to the initialization order >>>> would be my biggest concern with this patch. >>>> >>> >>> No, I did not notice that comment and assumed alphabetical order was >>> OK here.? However, these classes appear to be only resolved, not >>> initialized (and AccessController does not have a static >>> initializer), so could you explain how the order in this list can >>> affect initialization order? >> >> You're right it doesn't. There are a couple of comments that refer to >> "initialization" but it's not static initialization of these classes. >> >> I'm unclear how the resolution order in that list may interact with >> other parts of the startup sequence. >> >>> I only need this in JVM_GetStackAccessControlContext, which is a >>> static JNI method, so I could get the klass* from the incoming >>> jclass instead of using a well-known class entry. >> >> I think it's okay given we have AccessControlContext there anyway. >> >>>> --- >>>> >>>> I'm unclear about the change to the test: >>>> >>>> test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm >>>> >>>> as it still refers to the now non-existent JVM_DoPrivileged in the >>>> summary. Does this test still make sense? Should it be moved to the >>>> Java side now it doesn't actually test anything in the VM? >>>> >>> >>> I think these tests still make sense, unless we have similar >>> coverage somewhere else.? How about if I fix the reference to >>> JVM_DoPrivileged for now and file a separate bug about moving or >>> removing these tests? >> >> Yep that's fine. >> >>>> --- >>>> >>>> There may be further dead code to remove now: >>>> >>>> vmSymbols.hpp: codesource_permissioncollection_signature is now >>>> unreferenced and can be removed. >>>> >>>> javaClasses.*: >>>> ? - java_lang_System::has_security_manager >>>> ? - java_security_AccessControlContext::is_authorized >>>> >>>> ./share/memory/universe.hpp:? static Method* >>>> protection_domain_implies_method() >>>> >>> >>> Good catches!? I have uploaded a new webrev: >>> >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ >>> (incremental diff) >> >> Updates all look fine. >> >> Thanks, >> David >> ----- >> >>> dl >>> >>>> --- >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>>>> >>>>> This change implements AccessController.doPrivileged in Java. This >>>>> gives a performance improvement while also being useful to Project >>>>> Loom by removing the Java --> native --> Java transition.? One >>>>> reason doPrivileged has historically been in native is because of >>>>> the need to guarantee the cleanup of the privileged context when >>>>> doPrivileged returns.? To do that in Java, the information that >>>>> AccessController.getContext needs is pushed onto the Java stack as >>>>> arguments to a method that getContext will recognize during its >>>>> stack walk.? This allows us to remove the native privileged stack >>>>> while guaranteeing that the privileged context goes away when the >>>>> method returns. >>>>> >>>>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>>>> api/java_security tests.? For the first few rounds of testing, I >>>>> kept the old native privileged stack and compared the results of >>>>> the old and new implementations for each getContext call, which >>>>> did catch some early bugs.? The changes were also examined by >>>>> internal security experts and run through additional internal >>>>> security tests. >>>>> >>>>> The improvement on this [1] doPrivileged microbenchmark is >>>>> approximate 50x. >>>>> >>>>> There is no attempt to optimize getContext() or security >>>>> permission checks in this change, however, this is intended to be >>>>> a first step towards other possible improvements, for example >>>>> those proposed here [2]. >>>>> >>>>> dl >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>>>> >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>>>> >>>>> >>> > From sean.mullan at oracle.com Thu Nov 1 17:32:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 13:32:26 -0400 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <5BDA5399.4030509@zeus.net.au> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> <4fe219c8-7e29-1bfb-839d-1e1caab34efa@oracle.com> <5BDA5399.4030509@zeus.net.au> Message-ID: <48a41f5d-58d3-41c4-4533-7534de74f392@oracle.com> On 10/31/18 9:15 PM, Peter wrote: > Hello Dean & David, > > Interesting reading.?? Is DomainCombiner still being considered for > deprecation? There are no immediate plans to deprecate DomainCombiner, but we are looking at the SecurityManager (SM) and all of its related APIs and evaluating different paths forward, which could include deprecation or simplification. In the near term, we are looking at small SM-related enhancements which improve performance (such as this) or other things like removing legacy SM APIs and/or code. I had expressed some initial thoughts on this topic here and hope to share some more ideas in the near future: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018273.html In the meantime, please let me know if you have any thoughts or ideas on this topic. --Sean From ioi.lam at oracle.com Thu Nov 1 01:01:35 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 31 Oct 2018 18:01:35 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> <9a5a08bf-331d-8def-9f2d-98dd47fcf7ef@oracle.com> Message-ID: <920b1841-53cf-23c1-1f35-365518935ee0@oracle.com> On 10/31/18 5:13 PM, dean.long at oracle.com wrote: > On 10/31/18 4:06 PM, David Holmes wrote: >> Hi Dean, >> >> Looking only at the hotspot changes. The removal of the DoPrivileged >> and related privileged_stack code seems okay. I have a few related >> comments: >> >> src/hotspot/share/classfile/systemDictionary.hpp >> >> You added the java_security_AccessController class after >> java_security_AccessControlContext. Did you actually verify where in >> the load/initialization order the AccessController class appears >> today, and where it appears after your change? (Note the comments at >> the start of WK_KLASSES_DO). Changes to the initialization order >> would be my biggest concern with this patch. >> > > No, I did not notice that comment and assumed alphabetical order was > OK here.? However, these classes appear to be only resolved, not > initialized (and AccessController does not have a static initializer), > so could you explain how the order in this list can affect > initialization order? > > I only need this in JVM_GetStackAccessControlContext, which is a > static JNI method, so I could get the klass* from the incoming jclass > instead of using a well-known class entry. Hi Dean, You're correct that those classes are only resolved, and not initialized. So the order shouldn't matter too much. However, the order of the first few classes is important, as the creation of Object, Serializable, Cloneable, String, etc, has to be done in a certain order. I'm not sure whether the order of the reference classes, 292 classes, and box classes are important. I'll experiment of getting rid of the separate phases after the call to Universe::fixup_mirrors(). This might be relics from old days where the classes were once indeed initialized in SystemDictionary::initialize_well_known_classes, which was the old name for SystemDictionary::resolve_well_known_classes. (-XX:+TraceBytecodes shows no Java code is executed before resolve_well_known_classes returns). I filed https://bugs.openjdk.java.net/browse/JDK-8213230 For the time being, I think as long as you put the new AccessController class near the existing class AccessControlContext, you should be OK. Thanks - Ioi > >> --- >> >> I'm unclear about the change to the test: >> >> test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm >> >> as it still refers to the now non-existent JVM_DoPrivileged in the >> summary. Does this test still make sense? Should it be moved to the >> Java side now it doesn't actually test anything in the VM? >> > > I think these tests still make sense, unless we have similar coverage > somewhere else.? How about if I fix the reference to JVM_DoPrivileged > for now and file a separate bug about moving or removing these tests? > >> --- >> >> There may be further dead code to remove now: >> >> vmSymbols.hpp: codesource_permissioncollection_signature is now >> unreferenced and can be removed. >> >> javaClasses.*: >> ? - java_lang_System::has_security_manager >> ? - java_security_AccessControlContext::is_authorized >> >> ./share/memory/universe.hpp:? static Method* >> protection_domain_implies_method() >> > > Good catches!? I have uploaded a new webrev: > > http://cr.openjdk.java.net/~dlong/8212605/webrev.2/ > http://cr.openjdk.java.net/~dlong/8212605/webrev.2.incr/ (incremental > diff) > > dl > >> --- >> >> Thanks, >> David >> >> >> On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>> >>> This change implements AccessController.doPrivileged in Java. This >>> gives a performance improvement while also being useful to Project >>> Loom by removing the Java --> native --> Java transition.? One >>> reason doPrivileged has historically been in native is because of >>> the need to guarantee the cleanup of the privileged context when >>> doPrivileged returns.? To do that in Java, the information that >>> AccessController.getContext needs is pushed onto the Java stack as >>> arguments to a method that getContext will recognize during its >>> stack walk.? This allows us to remove the native privileged stack >>> while guaranteeing that the privileged context goes away when the >>> method returns. >>> >>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>> api/java_security tests.? For the first few rounds of testing, I >>> kept the old native privileged stack and compared the results of the >>> old and new implementations for each getContext call, which did >>> catch some early bugs.? The changes were also examined by internal >>> security experts and run through additional internal security tests. >>> >>> The improvement on this [1] doPrivileged microbenchmark is >>> approximate 50x. >>> >>> There is no attempt to optimize getContext() or security permission >>> checks in this change, however, this is intended to be a first step >>> towards other possible improvements, for example those proposed here >>> [2]. >>> >>> dl >>> >>> [1] >>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>> >>> > From vladimir.x.ivanov at oracle.com Thu Nov 1 01:11:11 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Oct 2018 18:11:11 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> Message-ID: <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> Dean, src/java.base/share/classes/java/security/AccessController.java: + /** + * Internal marker for hidden implementation frames. + */ + /*non-public*/ + @Target(ElementType.METHOD) + @Retention(RetentionPolicy.RUNTIME) + @interface Hidden { + } You declare @Hidden, but then map it to _method_Hidden along with @Hidden from java.lang.invoke.LambdaForm. What do you think about moving LambdaForm.Hidden to jdk.internal.vm.annotation instead and share among all usages? Best regards, Vladimir Ivanov On 31/10/2018 15:23, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8212605 > http://cr.openjdk.java.net/~dlong/8212605/webrev.1 > > This change implements AccessController.doPrivileged in Java.? This > gives a performance improvement while also being useful to Project Loom > by removing the Java --> native --> Java transition.? One reason > doPrivileged has historically been in native is because of the need to > guarantee the cleanup of the privileged context when doPrivileged > returns.? To do that in Java, the information that > AccessController.getContext needs is pushed onto the Java stack as > arguments to a method that getContext will recognize during its stack > walk.? This allows us to remove the native privileged stack while > guaranteeing that the privileged context goes away when the method returns. > > Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security > tests.? For the first few rounds of testing, I kept the old native > privileged stack and compared the results of the old and new > implementations for each getContext call, which did catch some early > bugs.? The changes were also examined by internal security experts and > run through additional internal security tests. > > The improvement on this [1] doPrivileged microbenchmark is approximate 50x. > > There is no attempt to optimize getContext() or security permission > checks in this change, however, this is intended to be a first step > towards other possible improvements, for example those proposed here [2]. > > dl > > [1] > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html > > From vladimir.x.ivanov at oracle.com Thu Nov 1 08:18:37 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 1 Nov 2018 01:18:37 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> Message-ID: <43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com> > I think it's a good idea, but I believe it would require a CSR request. > Do you mind if I file a separate issue for > jdk.internal.vm.annotation.Hidden? Sure. Most of the annotations in jdk.internal.vm.annotation were originally located in java.lang.invoke. Not sure CSR will be required in this particular case. Best regards, Vladimir Ivanov > On 10/31/18 6:11 PM, Vladimir Ivanov wrote: >> Dean, >> >> src/java.base/share/classes/java/security/AccessController.java: >> +??? /** >> +???? * Internal marker for hidden implementation frames. >> +???? */ >> +??? /*non-public*/ >> +??? @Target(ElementType.METHOD) >> +??? @Retention(RetentionPolicy.RUNTIME) >> +??? @interface Hidden { >> +??? } >> >> You declare @Hidden, but then map it to _method_Hidden along with >> @Hidden from java.lang.invoke.LambdaForm. >> >> What do you think about moving LambdaForm.Hidden to >> jdk.internal.vm.annotation instead and share among all usages? >> >> Best regards, >> Vladimir Ivanov >> >> On 31/10/2018 15:23, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>> >>> This change implements AccessController.doPrivileged in Java. This >>> gives a performance improvement while also being useful to Project >>> Loom by removing the Java --> native --> Java transition.? One reason >>> doPrivileged has historically been in native is because of the need >>> to guarantee the cleanup of the privileged context when doPrivileged >>> returns.? To do that in Java, the information that >>> AccessController.getContext needs is pushed onto the Java stack as >>> arguments to a method that getContext will recognize during its stack >>> walk.? This allows us to remove the native privileged stack while >>> guaranteeing that the privileged context goes away when the method >>> returns. >>> >>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>> api/java_security tests.? For the first few rounds of testing, I kept >>> the old native privileged stack and compared the results of the old >>> and new implementations for each getContext call, which did catch >>> some early bugs.? The changes were also examined by internal security >>> experts and run through additional internal security tests. >>> >>> The improvement on this [1] doPrivileged microbenchmark is >>> approximate 50x. >>> >>> There is no attempt to optimize getContext() or security permission >>> checks in this change, however, this is intended to be a first step >>> towards other possible improvements, for example those proposed here >>> [2]. >>> >>> dl >>> >>> [1] >>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>> >>> [2] >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>> >>> > From sean.mullan at oracle.com Thu Nov 1 18:24:07 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 14:24:07 -0400 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> Message-ID: <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> On 10/31/18 11:52 AM, Chris Hegarty wrote: > Xuelei, > > On 30/10/18 20:55, Xuelei Fan wrote: >> Hi, >> >> For the current HttpsURLConnection, there is not much security >> parameters exposed in the public APIs.? An application may need richer >> information for the underlying TLS connections, for example the >> negotiated TLS protocol version. >> >> Please let me know if you have concerns to add a new method >> HttpsURLConnection.getSSLSession() and deprecate the duplicated >> methods, by the end of Nov. 2, 2018. >> >> Here is the proposal: >> ???? https://bugs.openjdk.java.net/browse/JDK-8213161 Are there any security issues associated with returning the SSLSession, since it is mutable? + * SHOULD override this method with appropriate implementation. s/appropriate/an appropriate/ I would probably not capitalize "SHOULD" and just say "should". "SHOULD" is more common in RFCs. I don't see that much in javadocs. + * @implNote The JDK Reference Implementation supports this operation. + * As an application may have to use this operation for more + * security parameters, it is recommended to support this + * operation in all implementations. I think it should be obvious that the JDK implementation would override this method so not sure that first sentence is necessary. The other sentence seems like it could be combined with the previous sentence, ex: "Subclasses should override this method with an appropriate implementation since an application may need to access additional parameters associated with the SSL session." --Sean From jamil.j.nimeh at oracle.com Thu Nov 1 19:03:13 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 1 Nov 2018 12:03:13 -0700 Subject: TLSv1.3 fails to read cert chain after HTTP redirect In-Reply-To: <5BBBCD48020000BE0009B4B0@prvgwdev-52.provo.novell.com> References: <5BBBCD48020000BE0009B4B0@prvgwdev-52.provo.novell.com> Message-ID: Hi Daniel thanks for bringing this up, this sounds like https://bugs.openjdk.java.net/browse/JDK-8212885.? I'm very close to a fix on this one, just working out a few issues in testing. --Jamil On 10/8/2018 2:34 PM, Daniel Christensen wrote: > I have a custom HostnameVerifier that attempts to examine the > certificate chain using SSLSession#getPeerCertificates(). After > upgrading to Java 11, where it seems that TLSv1.3?is used by default, > I am seeing that getPeerCertificates() throws an > SSLPeerUnverifiedException after an HTTP redirect has occurred. If I > force the protocol to TLSv1.2 this does not occur. If there is no > redirect, then this does not occur. > > Is this a bug in Java or a change in behavior with TLSv1.3? > > The code below demonstrates the problem when 'protocol' is either > 'TLS' or 'TLSv1.3' and path is '/redirect'. > > doTest("TLSv1.3", "/redirect"); // Fails with SSLPeerUnverifiedException > doTest("TLSv1.3", "/content"); // Succeeds > doTest("TLSv1.2", "/redirect"); // Succeeds > doTest("TLSv1.2", "/content"); // Succeeds > > ??? private void doTest(String protocol, String path) throws > IOException, NoSuchAlgorithmException, KeyManagementException > ??? { > ??????? whenHttp(server) > ??????????????? .match(get("/redirect")) > .then(status(HttpStatus.MOVED_PERMANENTLY_301), > contentType("text/html"), header("Location", "/content"), > stringContent("redirected")); > ??????? whenHttp(server) > ??????????????? .match(get("/content")) > ??????????????? .then(ok(), contentType("text/html"), > stringContent("ok")); > > ??????? URL url = new URL("https", "localhost", server.getPort(), path); > ??????? HttpsURLConnection conn = > (HttpsURLConnection)url.openConnection(); > ??????? SSLContext ctx = SSLContext.getInstance(protocol); > ??????? TrustManager[] tms = {new X509TrustManager() > ??????? { > ??????????? @Override public void checkClientTrusted(X509Certificate[] > chain, String authType){} > ??????????? @Override public void checkServerTrusted(X509Certificate[] > chain, String authType){} > ??????????? @Override public X509Certificate[] getAcceptedIssuers() { > return new X509Certificate[0]; } > ??????? }}; > ??????? ctx.init(null, tms, new SecureRandom()); > ??????? conn.setSSLSocketFactory(ctx.getSocketFactory()); > ??????? conn.setHostnameVerifier(new HostnameVerifier() > ??????? { > ??????????? @Override > ??????????? public boolean verify(String hostname, SSLSession session) > ??????????? { > ??????????????? java.security.cert.Certificate[] chain = null; > ??????????????? try > ??????????????? { > ??????????????????? chain = session.getPeerCertificates(); > ??????????????? } > ??????????????? catch (SSLPeerUnverifiedException e) > ??????????????? { > ??????????????????? throw new RuntimeException(e); > ??????????????? } > ??????????????? return true; > ??????????? } > ??????? }); > ??????? int status = conn.getResponseCode(); > ??????? assertEquals(200, status); > ??? } > > > Thanks, > Dan > > Daniel L. Christensen > Distinguished Engineer > Micro Focus > http://www.microfocus.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Thu Nov 1 19:11:02 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 1 Nov 2018 12:11:02 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <670ff93f-e8e0-d7a0-d410-daa42b5a9a32@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <670ff93f-e8e0-d7a0-d410-daa42b5a9a32@oracle.com> Message-ID: <1a5cf1b4-d0ef-1b25-4d69-ecc9f4725c77@oracle.com> On 11/1/18 10:01 AM, Sean Mullan wrote: > Some of the copyrights need to be updated to 2018. > Fixed. > All else looks good to me as I had reviewed an earlier version of this > before. We have talked about doing this for a while now, so I am > finally glad we and are able to pretty much eliminate one of the more > common SecurityManager related hot-spots and give a performance boost > to applications that don't use the SM as well. > Thanks Sean. dl > --Sean > > On 10/31/18 6:23 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8212605 >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >> >> This change implements AccessController.doPrivileged in Java. This >> gives a performance improvement while also being useful to Project >> Loom by removing the Java --> native --> Java transition.? One reason >> doPrivileged has historically been in native is because of the need >> to guarantee the cleanup of the privileged context when doPrivileged >> returns.? To do that in Java, the information that >> AccessController.getContext needs is pushed onto the Java stack as >> arguments to a method that getContext will recognize during its stack >> walk.? This allows us to remove the native privileged stack while >> guaranteeing that the privileged context goes away when the method >> returns. >> >> Tested with tier1-tier3 hotspot and jdk tests and JCK >> api/java_security tests.? For the first few rounds of testing, I kept >> the old native privileged stack and compared the results of the old >> and new implementations for each getContext call, which did catch >> some early bugs.? The changes were also examined by internal security >> experts and run through additional internal security tests. >> >> The improvement on this [1] doPrivileged microbenchmark is >> approximate 50x. >> >> There is no attempt to optimize getContext() or security permission >> checks in this change, however, this is intended to be a first step >> towards other possible improvements, for example those proposed here >> [2]. >> >> dl >> >> [1] >> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >> >> From dean.long at oracle.com Thu Nov 1 19:21:07 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 1 Nov 2018 12:21:07 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <8c969cca-fab2-4731-3d81-a956c1898677@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> <8c969cca-fab2-4731-3d81-a956c1898677@oracle.com> Message-ID: <8a485f73-e942-12e8-9c7d-0944ff0af2de@oracle.com> On 11/1/18 9:48 AM, Sean Mullan wrote: > On 11/1/18 1:29 AM, dean.long at oracle.com wrote: >> On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html >>> >>> >>> In checkContext should the security manager be null checked first >>> instead of last to optimize for the typical case? (If the side >>> effects in that expression are desired it should be documented) >> >> I was following the example of createWrapper.? The side-effects of >> getInnocuousAcc() will only happen once, so the order shouldn't >> matter here, except for performance reasons.? I don't have a strong >> opinion about the order, but it looks like the typical case for >> createWrapper would also be the typical case for checkContext, so >> maybe they both should be changed, if indeed a null security manager >> is the more typical case. > > A null SM should be the more common case. I am ok with changing the > order so the SM is checked first, but it should be done in both the > createWrapper and checkContext methods. Alternatively, we could see if > they could be combined to eliminate the duplicate code but that might > not be practical from looking at them. > I don't see a way to do it without using a lambda or doing extra work in one version, so I just changed the order for now.? I also replaced getCallerPD with the faster getProtectionDomain and removed a stale comment about impliesCreateAccessControlContext being called by the VM.? It should be safe to remove now, but I left it in to minimize changes. http://cr.openjdk.java.net/~dlong/8212605/webrev.3.incr/ http://cr.openjdk.java.net/~dlong/8212605/webrev.3/ dl > --Sean From sean.mullan at oracle.com Thu Nov 1 19:39:41 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Nov 2018 15:39:41 -0400 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <8a485f73-e942-12e8-9c7d-0944ff0af2de@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> <8c969cca-fab2-4731-3d81-a956c1898677@oracle.com> <8a485f73-e942-12e8-9c7d-0944ff0af2de@oracle.com> Message-ID: <72357551-9393-d3e5-ced1-98452354ae9b@oracle.com> On 11/1/18 3:21 PM, dean.long at oracle.com wrote: > On 11/1/18 9:48 AM, Sean Mullan wrote: >> On 11/1/18 1:29 AM, dean.long at oracle.com wrote: >>> On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html >>>> >>>> >>>> In checkContext should the security manager be null checked first >>>> instead of last to optimize for the typical case? (If the side >>>> effects in that expression are desired it should be documented) >>> >>> I was following the example of createWrapper.? The side-effects of >>> getInnocuousAcc() will only happen once, so the order shouldn't >>> matter here, except for performance reasons.? I don't have a strong >>> opinion about the order, but it looks like the typical case for >>> createWrapper would also be the typical case for checkContext, so >>> maybe they both should be changed, if indeed a null security manager >>> is the more typical case. >> >> A null SM should be the more common case. I am ok with changing the >> order so the SM is checked first, but it should be done in both the >> createWrapper and checkContext methods. Alternatively, we could see if >> they could be combined to eliminate the duplicate code but that might >> not be practical from looking at them. >> > > I don't see a way to do it without using a lambda or doing extra work in > one version, so I just changed the order for now. Yes, I was thinking about using a lambda too, but I'm a bit wary of using lambdas in the security checking code. Best to keep the methods separate for now. > I also replaced > getCallerPD with the faster getProtectionDomain and removed a stale > comment about impliesCreateAccessControlContext being called by the VM. > It should be safe to remove now, but I left it in to minimize changes. I would just remove it, so we don't forget about it later. Looks good otherwise. --Sean > http://cr.openjdk.java.net/~dlong/8212605/webrev.3.incr/ > http://cr.openjdk.java.net/~dlong/8212605/webrev.3/ > > dl > >> --Sean > From mandy.chung at oracle.com Thu Nov 1 20:45:37 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Nov 2018 13:45:37 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> <43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com> Message-ID: On 11/1/18 1:18 AM, Vladimir Ivanov wrote: > >> I think it's a good idea, but I believe it would require a CSR >> request. Do you mind if I file a separate issue for >> jdk.internal.vm.annotation.Hidden? > > Sure. > > Most of the annotations in jdk.internal.vm.annotation were originally > located in java.lang.invoke. Not sure CSR will be required in this > particular case. > @Hidden is internal and no CSR is needed. FYI.? JDK-8212620 is the RFE to consider providing a standard mechanism to hide frames from stack trace. Mandy > Best regards, > Vladimir Ivanov > >> On 10/31/18 6:11 PM, Vladimir Ivanov wrote: >>> Dean, >>> >>> src/java.base/share/classes/java/security/AccessController.java: >>> +??? /** >>> +???? * Internal marker for hidden implementation frames. >>> +???? */ >>> +??? /*non-public*/ >>> +??? @Target(ElementType.METHOD) >>> +??? @Retention(RetentionPolicy.RUNTIME) >>> +??? @interface Hidden { >>> +??? } >>> >>> You declare @Hidden, but then map it to _method_Hidden along with >>> @Hidden from java.lang.invoke.LambdaForm. >>> >>> What do you think about moving LambdaForm.Hidden to >>> jdk.internal.vm.annotation instead and share among all usages? >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 31/10/2018 15:23, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>>> >>>> This change implements AccessController.doPrivileged in Java. This >>>> gives a performance improvement while also being useful to Project >>>> Loom by removing the Java --> native --> Java transition.? One >>>> reason doPrivileged has historically been in native is because of >>>> the need to guarantee the cleanup of the privileged context when >>>> doPrivileged returns.? To do that in Java, the information that >>>> AccessController.getContext needs is pushed onto the Java stack as >>>> arguments to a method that getContext will recognize during its >>>> stack walk.? This allows us to remove the native privileged stack >>>> while guaranteeing that the privileged context goes away when the >>>> method returns. >>>> >>>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>>> api/java_security tests.? For the first few rounds of testing, I >>>> kept the old native privileged stack and compared the results of >>>> the old and new implementations for each getContext call, which did >>>> catch some early bugs.? The changes were also examined by internal >>>> security experts and run through additional internal security tests. >>>> >>>> The improvement on this [1] doPrivileged microbenchmark is >>>> approximate 50x. >>>> >>>> There is no attempt to optimize getContext() or security permission >>>> checks in this change, however, this is intended to be a first step >>>> towards other possible improvements, for example those proposed >>>> here [2]. >>>> >>>> dl >>>> >>>> [1] >>>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Thu Nov 1 21:34:33 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 1 Nov 2018 14:34:33 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> <43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com> Message-ID: <4452ed95-c282-0ba7-340a-4566cfbb0095@oracle.com> On 11/1/18 1:45 PM, Mandy Chung wrote: > > > On 11/1/18 1:18 AM, Vladimir Ivanov wrote: >> >>> I think it's a good idea, but I believe it would require a CSR >>> request. Do you mind if I file a separate issue for >>> jdk.internal.vm.annotation.Hidden? >> >> Sure. >> >> Most of the annotations in jdk.internal.vm.annotation were originally >> located in java.lang.invoke. Not sure CSR will be required in this >> particular case. >> > > @Hidden is internal and no CSR is needed. > > FYI.? JDK-8212620 is the RFE to consider providing a standard > mechanism to hide frames from stack trace. > OK, I already filed JDK-8213234 but I think I should just close it as a duplicate of JDK-8212620. dl > Mandy > >> Best regards, >> Vladimir Ivanov >> >>> On 10/31/18 6:11 PM, Vladimir Ivanov wrote: >>>> Dean, >>>> >>>> src/java.base/share/classes/java/security/AccessController.java: >>>> +??? /** >>>> +???? * Internal marker for hidden implementation frames. >>>> +???? */ >>>> +??? /*non-public*/ >>>> +??? @Target(ElementType.METHOD) >>>> +??? @Retention(RetentionPolicy.RUNTIME) >>>> +??? @interface Hidden { >>>> +??? } >>>> >>>> You declare @Hidden, but then map it to _method_Hidden along with >>>> @Hidden from java.lang.invoke.LambdaForm. >>>> >>>> What do you think about moving LambdaForm.Hidden to >>>> jdk.internal.vm.annotation instead and share among all usages? >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 31/10/2018 15:23, dean.long at oracle.com wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8212605 >>>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >>>>> >>>>> This change implements AccessController.doPrivileged in Java. This >>>>> gives a performance improvement while also being useful to Project >>>>> Loom by removing the Java --> native --> Java transition.? One >>>>> reason doPrivileged has historically been in native is because of >>>>> the need to guarantee the cleanup of the privileged context when >>>>> doPrivileged returns.? To do that in Java, the information that >>>>> AccessController.getContext needs is pushed onto the Java stack as >>>>> arguments to a method that getContext will recognize during its >>>>> stack walk.? This allows us to remove the native privileged stack >>>>> while guaranteeing that the privileged context goes away when the >>>>> method returns. >>>>> >>>>> Tested with tier1-tier3 hotspot and jdk tests and JCK >>>>> api/java_security tests.? For the first few rounds of testing, I >>>>> kept the old native privileged stack and compared the results of >>>>> the old and new implementations for each getContext call, which >>>>> did catch some early bugs.? The changes were also examined by >>>>> internal security experts and run through additional internal >>>>> security tests. >>>>> >>>>> The improvement on this [1] doPrivileged microbenchmark is >>>>> approximate 50x. >>>>> >>>>> There is no attempt to optimize getContext() or security >>>>> permission checks in this change, however, this is intended to be >>>>> a first step towards other possible improvements, for example >>>>> those proposed here [2]. >>>>> >>>>> dl >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java >>>>> >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html >>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Nov 1 21:42:45 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Nov 2018 14:42:45 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <4452ed95-c282-0ba7-340a-4566cfbb0095@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <363cd5f9-e143-79cc-9698-6c8cb213ef1e@oracle.com> <43be67e3-c6a5-3ad2-d835-e9c32f90374f@oracle.com> <4452ed95-c282-0ba7-340a-4566cfbb0095@oracle.com> Message-ID: <595b46eb-bd26-7207-77a7-c76c5fc9719f@oracle.com> On 11/1/18 2:34 PM, dean.long at oracle.com wrote: > >> @Hidden is internal and no CSR is needed. >> >> FYI.? JDK-8212620 is the RFE to consider providing a standard >> mechanism to hide frames from stack trace. >> > > OK, I already filed JDK-8213234 but I think I should just close it as > a duplicate of JDK-8212620. > JDK-8212620 likely does not make JDK 12.? I assume Vladimir suggests to do the rename with your fix (or a follow up). Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Thu Nov 1 21:52:05 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 1 Nov 2018 14:52:05 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <72357551-9393-d3e5-ced1-98452354ae9b@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <61f7523d-3fce-023b-f806-aa49a02f6d9c@oracle.com> <8c969cca-fab2-4731-3d81-a956c1898677@oracle.com> <8a485f73-e942-12e8-9c7d-0944ff0af2de@oracle.com> <72357551-9393-d3e5-ced1-98452354ae9b@oracle.com> Message-ID: On 11/1/18 12:39 PM, Sean Mullan wrote: >> I also replaced getCallerPD with the faster getProtectionDomain and >> removed a stale comment about impliesCreateAccessControlContext being >> called by the VM. It should be safe to remove now, but I left it in >> to minimize changes. > > I would just remove it, so we don't forget about it later. OK, I removed it: http://cr.openjdk.java.net/~dlong/8212605/webrev.4.incr/ dl -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Nov 1 23:42:19 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 1 Nov 2018 16:42:19 -0700 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> Message-ID: On 11/1/2018 11:24 AM, Sean Mullan wrote: > On 10/31/18 11:52 AM, Chris Hegarty wrote: >> Xuelei, >> >> On 30/10/18 20:55, Xuelei Fan wrote: >>> Hi, >>> >>> For the current HttpsURLConnection, there is not much security >>> parameters exposed in the public APIs.? An application may need >>> richer information for the underlying TLS connections, for example >>> the negotiated TLS protocol version. >>> >>> Please let me know if you have concerns to add a new method >>> HttpsURLConnection.getSSLSession() and deprecate the duplicated >>> methods, by the end of Nov. 2, 2018. >>> >>> Here is the proposal: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8213161 > > Are there any security issues associated with returning the SSLSession, > since it is mutable? It should be fine. The update APIs of the session (invalidating, bind values) does not impact the connection. > > +???? *?????????? SHOULD override this method with appropriate > implementation. > > s/appropriate/an appropriate/ > > I would probably not capitalize "SHOULD" and just say "should". "SHOULD" > is more common in RFCs. I don't see that much in javadocs. > > +???? * @implNote The JDK Reference Implementation supports this operation. > +???? *?????????? As an application may have to use this operation for more > +???? *?????????? security parameters, it is recommended to support this > +???? *?????????? operation in all implementations. > > I think it should be obvious that the JDK implementation would override > this method so not sure that first sentence is necessary. The other > sentence seems like it could be combined with the previous sentence, ex: > > "Subclasses should override this method with an appropriate > implementation since an application may need to access additional > parameters associated with the SSL session." > Updated accordingly, in the CSR and webrev: https://bugs.openjdk.java.net/browse/JDK-8213161 http://cr.openjdk.java.net/~xuelei/8212261/webrev.02/ Thanks, Xuelei From valerie.peng at oracle.com Fri Nov 2 01:50:56 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 1 Nov 2018 18:50:56 -0700 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> <566016d0-00ba-e938-693f-56948b9013da@oracle.com> Message-ID: <2ee1d1b8-91f5-f0c7-bd9f-31d7d20d472c@oracle.com> Hi Martin, A few comments: 1) The newly added property is causing 41 regression tests to fail due to permission problem. You will need to update src/java.base/share/lib/security/default.policy --- a/src/java.base/share/lib/security/default.policy +++ b/src/java.base/share/lib/security/default.policy @@ -127,6 +127,7 @@ ???? permission java.lang.RuntimePermission "accessClassInPackage.sun.nio.ch"; ???? permission java.lang.RuntimePermission "loadLibrary.j2pkcs11"; ???? permission java.util.PropertyPermission "sun.security.pkcs11.allowSingleThreadedModules", "read"; +??? permission java.util.PropertyPermission "sun.security.pkcs11.enableNativeKeysExtraction", "read"; ???? permission java.util.PropertyPermission "os.name", "read"; ???? permission java.util.PropertyPermission "os.arch", "read"; ???? permission java.util.PropertyPermission "jdk.crypto.KeyAgreement.legacyKDF", "read"; 2) As for p11_keymgmt.c, I agree that the earlier version maybe too strict to check for CKR_OK for the first two C_GetAttributeValue(...) call. Now that we don't check the status, we can probably remove the TRACE0 code (line 190 and 217). BTW, the JNI method signature on line 128 and 397 need to be updated to include the jobject jWrappingMech argument. 3) For the new system property, it will need a CSR. Here are some pointers on CSR and its process, faq, etc. * https://wiki.openjdk.java.net/display/csr/Main * https://wiki.openjdk.java.net/display/csr/CSR+FAQs Thanks, Valerie On 10/26/2018 10:57 AM, Martin Balao wrote: > Hi Valerie, > > I fixed all previously discussed issues in Webrev.13: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.13/ > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.13.zip > > > In addition to that, I fixed a couple of bugs introduced in p11_keymgmt.c. > > In Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo function, > the first call to C_GetAttributeValue (to get CKA_CLASS, CKA_KEY_TYPE, > CKA_SENSITIVE and CKA_NETSCAPE_DB attributes) may fail because the key > may not have a CKA_NETSCAPE_DB attribute. That is fine. It just means > that we are not going to get that attribute -which does not exist- and > it won't be needed for key unwrapping. > > Later in Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo > function, a similar issue happened. The call to get buffer lengths may > return an error if one of the attributes does not exist. This is fine > because length values are obtained anyways and based on that we were > not going to query for non-existent attributes later. > > These bugs were silently making all keys not to be extracted. > > Thanks, > Martin.- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Nov 2 02:14:52 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 1 Nov 2018 19:14:52 -0700 Subject: RFR[12] JDK-8211049 "Second parameter of "initialize" method is not used" Message-ID: <9bc3a901-518f-10e7-a2e6-8222e031c889@oracle.com> Hi, Anyone can help review this trivial fix? Bug: https://bugs.openjdk.java.net/browse/JDK-8211049 Webrev: http://cr.openjdk.java.net/~valeriep/8211049/webrev.00/ Mach5 result with the new regression test is clean. Thanks, Valerie From weijun.wang at oracle.com Fri Nov 2 02:55:01 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 2 Nov 2018 10:55:01 +0800 Subject: RFR[12] JDK-8211049 "Second parameter of "initialize" method is not used" In-Reply-To: <9bc3a901-518f-10e7-a2e6-8222e031c889@oracle.com> References: <9bc3a901-518f-10e7-a2e6-8222e031c889@oracle.com> Message-ID: Hi Valerie Since you are specifically fixing a bug inside the SunRsaSign provider, is it enough to just use the KeyPairGenerator from this provider? The src fix is fine. Thanks Max > On Nov 2, 2018, at 10:14 AM, Valerie Peng wrote: > > Hi, > > Anyone can help review this trivial fix? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211049 > > Webrev: http://cr.openjdk.java.net/~valeriep/8211049/webrev.00/ > > Mach5 result with the new regression test is clean. > > Thanks, > Valerie From chris.hegarty at oracle.com Fri Nov 2 12:58:33 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 2 Nov 2018 12:58:33 +0000 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> Message-ID: Thanks for the updates Xuelei, some minor comments inline.. > On 1 Nov 2018, at 23:42, Xuelei Fan wrote: > > On 11/1/2018 11:24 AM, Sean Mullan wrote: >> On 10/31/18 11:52 AM, Chris Hegarty wrote: >>> Xuelei, >>> >>> On 30/10/18 20:55, Xuelei Fan wrote: >>>> Hi, >>>> >>>> For the current HttpsURLConnection, there is not much security parameters exposed in the public APIs. An application may need richer information for the underlying TLS connections, for example the negotiated TLS protocol version. >>>> >>>> Please let me know if you have concerns to add a new method HttpsURLConnection.getSSLSession() and deprecate the duplicated methods, by the end of Nov. 2, 2018. >>>> >>>> Here is the proposal: >>>> https://bugs.openjdk.java.net/browse/JDK-8213161 >> Are there any security issues associated with returning the SSLSession, since it is mutable? > It should be fine. The update APIs of the session (invalidating, bind values) does not impact the connection. Alternatively, as is done in the new HTTP Client, an immutable SSLSession instance can be returned. >> + * SHOULD override this method with appropriate implementation. >> s/appropriate/an appropriate/ >> I would probably not capitalize "SHOULD" and just say "should". "SHOULD" is more common in RFCs. I don't see that much in javadocs. >> + * @implNote The JDK Reference Implementation supports this operation. >> + * As an application may have to use this operation for more >> + * security parameters, it is recommended to support this >> + * operation in all implementations. >> I think it should be obvious that the JDK implementation would override this method so not sure that first sentence is necessary. The other sentence seems like it could be combined with the previous sentence, ex: >> "Subclasses should override this method with an appropriate implementation since an application may need to access additional parameters associated with the SSL session." > Updated accordingly, in the CSR and webrev: > https://bugs.openjdk.java.net/browse/JDK-8213161 The CSR looks good. I made a few minor edits to the verbiage and added myself as reviewer. The title will need to be updated to reflect the addition of the new method in SecureCacheResponse. Maybe: "Add SSLSession accessors to HttpsURLConnection and SecureCacheResponse" -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Nov 2 18:42:22 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 2 Nov 2018 11:42:22 -0700 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> Message-ID: Thanks for the review and suggestions, Chris and Sean. I just finalized the CSR. Thanks, Xuelei On 11/2/2018 5:58 AM, Chris Hegarty wrote: > Thanks for the updates Xuelei, some minor comments inline.. > >> On 1 Nov 2018, at 23:42, Xuelei Fan > > wrote: >> >> On 11/1/2018 11:24 AM, Sean Mullan wrote: >>> On 10/31/18 11:52 AM, Chris Hegarty wrote: >>>> Xuelei, >>>> >>>> On 30/10/18 20:55, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> For the current HttpsURLConnection, there is not much security >>>>> parameters exposed in the public APIs.? An application may need >>>>> richer information for the underlying TLS connections, for example >>>>> the negotiated TLS protocol version. >>>>> >>>>> Please let me know if you have concerns to add a new method >>>>> HttpsURLConnection.getSSLSession() and deprecate the duplicated >>>>> methods, by the end of Nov. 2, 2018. >>>>> >>>>> Here is the proposal: >>>>> https://bugs.openjdk.java.net/browse/JDK-8213161 >>> Are there any security issues associated with returning the >>> SSLSession, since it is mutable? >> It should be fine. ?The update APIs of the session (invalidating, bind >> values) does not impact the connection. > > Alternatively, as is done in the new HTTP Client, an immutable > SSLSession instance can be returned. > >>> +???? *?????????? SHOULD override this method with appropriate >>> implementation. >>> s/appropriate/an appropriate/ >>> I would probably not capitalize "SHOULD" and just say "should". >>> "SHOULD" is more common in RFCs. I don't see that much in javadocs. >>> +???? * @implNote The JDK Reference Implementation supports this >>> operation. >>> +???? *?????????? As an application may have to use this operation >>> for more >>> +???? *?????????? security parameters, it is recommended to support this >>> +???? *?????????? operation in all implementations. >>> I think it should be obvious that the JDK implementation would >>> override this method so not sure that first sentence is necessary. >>> The other sentence seems like it could be combined with the previous >>> sentence, ex: >>> "Subclasses should override this method with an appropriate >>> implementation since an application may need to access additional >>> parameters associated with the SSL session." >> Updated accordingly, in the CSR and webrev: >> https://bugs.openjdk.java.net/browse/JDK-8213161 > > The CSR looks good. I made a few minor edits to the verbiage > and added myself as reviewer. > > The title will need to be updated to reflect the addition of the > new method in SecureCacheResponse. Maybe: > > "Add?SSLSession accessors to HttpsURLConnection and > SecureCacheResponse" > > -Chris. > > > From mandy.chung at oracle.com Fri Nov 2 20:55:29 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 2 Nov 2018 13:55:29 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> Message-ID: Hi Dean, I reviewed webrev.4 version.? It looks good.? Happy to see moving the doPrivileged support to Java and the performance improvement. On 10/31/18 3:23 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8212605 > http://cr.openjdk.java.net/~dlong/8212605/webrev.1 > > This change implements AccessController.doPrivileged in Java. This > gives a performance improvement while also being useful to Project > Loom by removing the Java --> native --> Java transition.? One reason > doPrivileged has historically been in native is because of the need to > guarantee the cleanup of the privileged context when doPrivileged > returns.? To do that in Java, the information that > AccessController.getContext needs is pushed onto the Java stack as > arguments to a method that getContext will recognize during its stack > walk.? This allows us to remove the native privileged stack while > guaranteeing that the privileged context goes away when the method > returns. > Tested with tier1-tier3 hotspot and jdk tests and JCK > api/java_security tests.? For the first few rounds of testing, I kept > the old native privileged stack and compared the results of the old > and new implementations for each getContext call, which did catch some > early bugs.? The changes were also examined by internal security > experts and run through additional internal security tests. > > The improvement on this [1] doPrivileged microbenchmark is approximate > 50x. > > There is no attempt to optimize getContext() or security permission > checks in this change, however, this is intended to be a first step > towards other possible improvements, for example those proposed here [2]. > FYI.? Sean and I also did some experiment to replace JVM_GetStackAccessControlContext with StackWalker some time ago. Another potential area to move the code from VM to Java for the future as David explored and probably involves? performance work in the stack walker. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Fri Nov 2 21:09:45 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 2 Nov 2018 14:09:45 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> Message-ID: Thanks Mandy.? I also appreciate you noticing (off-list) that I can remove the extra space in "Class " in several places.? I have updated webrev.4 in place. dl On 11/2/18 1:55 PM, Mandy Chung wrote: > Hi Dean, > > I reviewed webrev.4 version.? It looks good.? Happy to see moving the > doPrivileged support to Java and the performance improvement. > > On 10/31/18 3:23 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8212605 >> http://cr.openjdk.java.net/~dlong/8212605/webrev.1 >> >> This change implements AccessController.doPrivileged in Java. This >> gives a performance improvement while also being useful to Project >> Loom by removing the Java --> native --> Java transition.? One reason >> doPrivileged has historically been in native is because of the need >> to guarantee the cleanup of the privileged context when doPrivileged >> returns.? To do that in Java, the information that >> AccessController.getContext needs is pushed onto the Java stack as >> arguments to a method that getContext will recognize during its stack >> walk.? This allows us to remove the native privileged stack while >> guaranteeing that the privileged context goes away when the method >> returns. >> Tested with tier1-tier3 hotspot and jdk tests and JCK >> api/java_security tests.? For the first few rounds of testing, I kept >> the old native privileged stack and compared the results of the old >> and new implementations for each getContext call, which did catch >> some early bugs.? The changes were also examined by internal security >> experts and run through additional internal security tests. >> >> The improvement on this [1] doPrivileged microbenchmark is >> approximate 50x. >> >> There is no attempt to optimize getContext() or security permission >> checks in this change, however, this is intended to be a first step >> towards other possible improvements, for example those proposed here >> [2]. >> > > FYI.? Sean and I also did some experiment to replace > JVM_GetStackAccessControlContext with StackWalker some time ago. > Another potential area to move the code from VM to Java for the future > as David explored and probably involves? performance work in the stack > walker. > > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Sat Nov 3 20:00:30 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sat, 3 Nov 2018 13:00:30 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> Message-ID: <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> I made a pass at improving the comments based on feedback I've received.? I updated webrev.4 in place, along with an incremental diff: http://cr.openjdk.java.net/~dlong/8212605/webrev.4.update/ dl On 10/31/18 9:39 PM, Bernd Eckenfels wrote: > I find the tail call optimization comment in wrapException adds only > confusion to an otherwise clear helper. But maybe it?s just me who > does not understand it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Nov 4 09:03:39 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 4 Nov 2018 09:03:39 +0000 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> Message-ID: <3f15e776-4aae-b3a7-302a-0c451d73a0c1@oracle.com> On 03/11/2018 20:00, dean.long at oracle.com wrote: > I made a pass at improving the comments based on feedback I've > received.? I updated webrev.4 in place, along with an incremental diff: I looked through the updated webrev.4, mostly studying the changes in AccessController.java and jvm.cpp and the changes look good to me. -Alan. From christoph.langer at sap.com Mon Nov 5 07:32:50 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Nov 2018 07:32:50 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions Message-ID: Hi, Ping. May I get reviews/substantial feedback on this zipfs enhancement? Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ Thanks Christoph From: Langer, Christoph Sent: Montag, 29. Oktober 2018 15:55 To: 'Alan Bateman' ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen Cc: Volker Simonis ; nio-dev Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) Hi Alan, security guys, I've proposed a CSR for this change now: https://bugs.openjdk.java.net/browse/JDK-8213082. I also updated the webrev, simplifying jdk.nio.zipfs.ZipUtils.permsFromFlags and eliminating the WeakHashMap: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ Since I've decoupled the changes to java.util.zip and jartool from those in jdk.zipfs, we're discussing only jdk.zipfs here. The implication of my change is that when working with files backed by the nio FileSystemProvider (java.nio.file.spi.FileSystemProvider) named "jar", which is the alias for zipfs, the files will support attributes of type java.nio.file.attribute.PosixFilePermissions ("posix:permissions"). It basically means that some methods of java.nio.file.Files that would return null or UnsupportedOperationException before would find an implementation now. Examples: https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getPosixFilePermissions(java.nio.file.Path,java.nio.file.LinkOption...) https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#setPosixFilePermissions(java.nio.file.Path,java.util.Set) https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#readAttributes(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributes.html https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getFileAttributeView(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributeView.html Thanks in advance for reviewing. Best regards Christoph From: Alan Bateman > Sent: Montag, 29. Oktober 2018 13:06 To: Langer, Christoph >; core-libs-dev >; security-dev at openjdk.java.net; Xueming Shen > Cc: Volker Simonis >; Andrew Luo >; nio-dev > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) On 29/10/2018 09:26, Langer, Christoph wrote: : As per request from Alan, I'm adding security-dev to get a review from security perspective. For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Nov 5 10:22:53 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Nov 2018 10:22:53 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: On 05/11/2018 07:32, Langer, Christoph wrote: > > Hi, > > Ping. > > May I get reviews/substantial feedback on this zipfs enhancement? > > It might be bit early to be asking for a code review on just one piece of this. I think the first step on this feature has to be to put all the issues on the table. There are several discussion points around ZIP vs. JAR, the impact on signed JARs, carrying permissions without a file owner, and the impact on tools. I also think that there will need to be discussion on security-dev as some of these issues around this feature have security concerns. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Nov 5 12:20:11 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 5 Nov 2018 12:20:11 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: <252df43a-41c6-1f9a-8553-5b8153a171f3@oracle.com> Hi Christoph, On 05/11/18 07:32, Langer, Christoph wrote: > .. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 Can you please add a `Scope` value to the CSR? I can't quite tell, but I assume it should be `JDK` or `Implementation`, right? I want to clarify that there is no impact on Java SE. -Chris. From christoph.langer at sap.com Mon Nov 5 12:54:38 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Nov 2018 12:54:38 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <252df43a-41c6-1f9a-8553-5b8153a171f3@oracle.com> References: <252df43a-41c6-1f9a-8553-5b8153a171f3@oracle.com> Message-ID: <0792cdf7824042bc905e952b80bb8b7b@sap.com> Hi Chris, yes, there's no impact on Java SE with this item. No API is changed. I've set the scope to JDK, as it affects the features that are available with the "jar" filesystem provider from module jdk.zipfs. Best regards Christoph > -----Original Message----- > From: Chris Hegarty > Sent: Montag, 5. November 2018 13:20 > To: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; security-dev at openjdk.java.net > Cc: nio-dev > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions > > Hi Christoph, > > On 05/11/18 07:32, Langer, Christoph wrote: > > .. > > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > > Can you please add a `Scope` value to the CSR? > > I can't quite tell, but I assume it should be `JDK` or > `Implementation`, right? I want to clarify that there is > no impact on Java SE. > > -Chris. From christoph.langer at sap.com Mon Nov 5 13:05:22 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Nov 2018 13:05:22 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: Hi Alan, all, I'd welcome a discussion, for sure. Unfortunately there hasn't been so much participation in this yet. I think this is an item where it's hard to have a clear opinion and where it's difficult to oversee all implications it might have. Who'd be willing to have a look from security perspective? Thanks & Best regards Christoph From: Alan Bateman Sent: Montag, 5. November 2018 11:23 To: Langer, Christoph ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen Cc: Volker Simonis ; nio-dev Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions On 05/11/2018 07:32, Langer, Christoph wrote: Hi, Ping. May I get reviews/substantial feedback on this zipfs enhancement? It might be bit early to be asking for a code review on just one piece of this. I think the first step on this feature has to be to put all the issues on the table. There are several discussion points around ZIP vs. JAR, the impact on signed JARs, carrying permissions without a file owner, and the impact on tools. I also think that there will need to be discussion on security-dev as some of these issues around this feature have security concerns. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Nov 5 14:10:52 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 5 Nov 2018 14:10:52 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <0792cdf7824042bc905e952b80bb8b7b@sap.com> References: <252df43a-41c6-1f9a-8553-5b8153a171f3@oracle.com> <0792cdf7824042bc905e952b80bb8b7b@sap.com> Message-ID: <47fe2f75-f251-3ac5-463e-972ae5434659@oracle.com> On 05/11/18 12:54, Langer, Christoph wrote: > Hi Chris, > > yes, there's no impact on Java SE with this item. No API is changed. I've set the scope to JDK, as it affects the features that are available with the "jar" filesystem provider from module jdk.zipfs. > ... The reason I asked about the CSR scope clarification is that it was unclear to me what the ultimate intentions are, given that the previous mails ( linked to from the CSR ) did have Java SE API changes ( in the java.util.zip package ). Are you now happy to reduce the scope of the proposal to be confined to the "jar" filesystem provider, or is this more of an initial step towards ultimately adding new Java SE APIs, to zip, to access these permissions ( as was in previous emails )? As well as possibly updating the tools to add such? -Chris. From christoph.langer at sap.com Mon Nov 5 14:23:22 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 5 Nov 2018 14:23:22 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: <47fe2f75-f251-3ac5-463e-972ae5434659@oracle.com> References: <252df43a-41c6-1f9a-8553-5b8153a171f3@oracle.com> <0792cdf7824042bc905e952b80bb8b7b@sap.com> <47fe2f75-f251-3ac5-463e-972ae5434659@oracle.com> Message-ID: <410f5c58c8934763b3e6e46217efb724@sap.com> Hi Chris > The reason I asked about the CSR scope clarification is that it was > unclear to me what the ultimate intentions are, given that the previous > mails ( linked to from the CSR ) did have Java SE API changes ( in the > java.util.zip package ). > > Are you now happy to reduce the scope of the proposal to be confined to > the "jar" filesystem provider, or is this more of an initial step > towards ultimately adding new Java SE APIs, to zip, to access these > permissions ( as was in previous emails )? As well as possibly updating > the tools to add such? The latter thing is true. I reduced the scope of my initial proposal to the "jar" filesystem provider here with the intention to get in this piece more quickly, if not at all. Maybe changes to java.util.zip and tools aren't feasible - we'll see. Furthermore, assuming changes can be done with JDK12, I consider the jdk.zipfs piece "backportable", at least for our OpenJDK build SapMachine (https://sapmachine.io). So having it separate would definitely ease the backporting into SapMachine 11 - which is the target for a customer of ours. Best Christoph From Roger.Riggs at oracle.com Mon Nov 5 15:21:01 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 5 Nov 2018 10:21:01 -0500 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> Message-ID: <6490c8ce-966d-e056-7da2-c3ab6e8bb845@oracle.com> Hi Dean, typo AccessController line788: "annocations" The implementations of doPrivileged(PrivilegedExceptionAction action) and doPrivileged(PrivilegedAction action) Could be a bit more similar since except for the exception wrapping they are the same. 309 return executePrivileged(action, null, Reflection.getCallerClass()); vs. AccessControlContext context = null; 548 Class caller = Reflection.getCallerClass(); 549 try { 550 return executePrivileged(action, context, caller); The context and caller locals aren't needed. Thanks, Roger On 11/03/2018 04:00 PM, dean.long at oracle.com wrote: > I made a pass at improving the comments based on feedback I've > received.? I updated webrev.4 in place, along with an incremental diff: > > http://cr.openjdk.java.net/~dlong/8212605/webrev.4.update/ > > dl > > On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >> I find the tail call optimization comment in wrapException adds only >> confusion to an otherwise clear helper. But maybe it?s just me who >> does not understand it. > From Alan.Bateman at oracle.com Mon Nov 5 15:59:29 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 5 Nov 2018 15:59:29 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: On 05/11/2018 13:05, Langer, Christoph wrote: > > Hi Alan, all, > > I?d welcome a discussion, for sure. Unfortunately there hasn?t been so > much participation in this yet. I think this is an item where it?s > hard to have a clear opinion and where it?s difficult to oversee all > implications it might have. > > Who?d be willing to have a look from security perspective? > I think you'll need to do a write-up of the overall proposal so that folks can jump in and point out the implications. It's not easy to do this in a code review of a small piece of the solution. I suspect that security-dev will be interested in the details for signed JARs as I don't think the current proposal prevents tampering of the file permissions. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Nov 5 16:19:05 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 5 Nov 2018 16:19:05 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: <1c5801e0-69d9-859b-c5e7-a1304bbff4d8@oracle.com> On 05/11/18 15:59, Alan Bateman wrote: > On 05/11/2018 13:05, Langer, Christoph wrote: >> >>... >> > I think you'll need to do a write-up of the overall proposal so that > folks can jump in and point out the implications. It's not easy to do > this in a code review of a small piece of the solution. Right, that's the main motivation for my previous questions. It is good to get a *complete* view of what is intended before reviewing the code. ( Sorry, if I've missed some of the previous context ). -Chris. From dean.long at oracle.com Mon Nov 5 18:33:20 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 5 Nov 2018 10:33:20 -0800 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <3f15e776-4aae-b3a7-302a-0c451d73a0c1@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> <3f15e776-4aae-b3a7-302a-0c451d73a0c1@oracle.com> Message-ID: <5c9afc7f-3ada-f95c-1110-db9bbc553536@oracle.com> Thanks Alan. dl On 11/4/18 1:03 AM, Alan Bateman wrote: > On 03/11/2018 20:00, dean.long at oracle.com wrote: >> I made a pass at improving the comments based on feedback I've >> received.? I updated webrev.4 in place, along with an incremental diff: > I looked through the updated webrev.4, mostly studying the changes in > AccessController.java and jvm.cpp and the changes look good to me. > > -Alan. From volker.simonis at gmail.com Mon Nov 5 18:38:42 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 Nov 2018 19:38:42 +0100 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions In-Reply-To: References: Message-ID: Hi Christoph, in general your change looks good to me. I need some more time to think about the implications mentioned by Alan and Chris but for the time being please find some comments regarding your implementation below: ZipFileAttributeView.java - can you please throw an AssertionError() for the default branch in the switch expression in the "ZipFileAttributeView.name()". ZipFileSystem.java - please also put @Override annotations on the method implementations from ZipFileAttributes (e.g. "compressedSize()", "crc()", etc...) and a comment at the place where the implementation of the "PosixFileAttributes" methods starts. ZipUtils.java - just a question: isn't it possible to reuse sun.nio.fs.UnixFileModeAttribute.toUnixMode() and the corresponding constants from sun.nio.fs.UnixConstants instead of redefining them here? You could export them from java.base to jdk.zipfs but the problem is probably that at least sun.nio.fs.UnixConstants is a generated class which only gets generated on Unix systems, right ? ZipFileAttributes.java - it seems a little odd that you've added "setPermissions()" to ZipFileAttributes. All the attribute classes (i.e. BasicFileAttributes, PosixFileAttributes) have no setters. Isn't it possible to implement "ZipFileAttributeView.setPermissions()" by calling "path.setPermissions()" (as this is done in "ZipFileAttributeView.setTimes()") and handle everything in ZipFileSyste (as this is done with "setTimes()"). Thanks, Volker On Mon, Nov 5, 2018 at 8:32 AM Langer, Christoph wrote: > > Hi, > > > > Ping. > > > > May I get reviews/substantial feedback on this zipfs enhancement? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ > > > > Thanks > > Christoph > > > > From: Langer, Christoph > Sent: Montag, 29. Oktober 2018 15:55 > To: 'Alan Bateman' ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen > Cc: Volker Simonis ; nio-dev > Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) > > > > Hi Alan, security guys, > > > > I?ve proposed a CSR for this change now: https://bugs.openjdk.java.net/browse/JDK-8213082. > > > > I also updated the webrev, simplifying jdk.nio.zipfs.ZipUtils.permsFromFlags and eliminating the WeakHashMap: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ > > > > Since I?ve decoupled the changes to java.util.zip and jartool from those in jdk.zipfs, we?re discussing only jdk.zipfs here. > > > > The implication of my change is that when working with files backed by the nio FileSystemProvider (java.nio.file.spi.FileSystemProvider) named ?jar?, which is the alias for zipfs, the files will support attributes of type java.nio.file.attribute.PosixFilePermissions (?posix:permissions?). > > > > It basically means that some methods of java.nio.file.Files that would return null or UnsupportedOperationException before would find an implementation now. > > > > Examples: > > https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getPosixFilePermissions(java.nio.file.Path,java.nio.file.LinkOption...) > > https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#setPosixFilePermissions(java.nio.file.Path,java.util.Set) > > https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#readAttributes(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) > > With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributes.html > > https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getFileAttributeView(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) > > With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributeView.html > > > > Thanks in advance for reviewing. > > > > Best regards > > Christoph > > > > > > From: Alan Bateman > Sent: Montag, 29. Oktober 2018 13:06 > To: Langer, Christoph ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen > Cc: Volker Simonis ; Andrew Luo ; nio-dev > Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) > > > > On 29/10/2018 09:26, Langer, Christoph wrote: > > : > > > > As per request from Alan, I?m adding security-dev to get a review from security perspective. > > > > For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. > > -Alan From dean.long at oracle.com Mon Nov 5 18:51:13 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 5 Nov 2018 10:51:13 -0800 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <6490c8ce-966d-e056-7da2-c3ab6e8bb845@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> <6490c8ce-966d-e056-7da2-c3ab6e8bb845@oracle.com> Message-ID: <4942fe9f-8f79-38f1-454b-d8bdc3700fd5@oracle.com> Hi Roger.? Thanks for looking at this. On 11/5/18 7:21 AM, Roger Riggs wrote: > Hi Dean, > > typo AccessController line788: "annocations" > Fixed. > The implementations of > > doPrivileged(PrivilegedExceptionAction action) and > doPrivileged(PrivilegedAction action) > > Could be a bit more similar since except for the exception wrapping > they are the same. > I was trying to make doPrivileged(PrivilegedExceptionAction action)? look like doPrivileged(PrivilegedExceptionAction action, AccessControlContext context), but I didn't see the point in doing that with doPrivileged(PrivilegedAction action).? Do you have a suggestion on how to improve it? > 309 return executePrivileged(action, null, > Reflection.getCallerClass()); vs. AccessControlContext context = null; > 548 Class caller = Reflection.getCallerClass(); > 549 try { > 550 return executePrivileged(action, context, caller); > > The context and caller locals aren't needed. > I agree, if no exception is thrown, but just in case I'd rather not do any extra work inside the "try" that might cause an exception to be wrapped that shouldn't. dl > Thanks, Roger > > On 11/03/2018 04:00 PM, dean.long at oracle.com wrote: >> I made a pass at improving the comments based on feedback I've >> received.? I updated webrev.4 in place, along with an incremental diff: >> >> http://cr.openjdk.java.net/~dlong/8212605/webrev.4.update/ >> >> dl >> >> On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >>> I find the tail call optimization comment in wrapException adds only >>> confusion to an otherwise clear helper. But maybe it?s just me who >>> does not understand it. >> > From xuelei.fan at oracle.com Mon Nov 5 18:52:06 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 5 Nov 2018 10:52:06 -0800 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> Message-ID: Hi Chris and Sean, There are a few feedback for the CSR approval. I updated to use Optional for the returned value. For more details, please refer to: https://bugs.openjdk.java.net/browse/JDK-8213161 http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/ Please let me know if you are OK with this change. Thanks, Xuelei On 11/2/2018 11:42 AM, Xuelei Fan wrote: > Thanks for the review and suggestions, Chris and Sean. > > I just finalized the CSR. > > Thanks, > Xuelei > > On 11/2/2018 5:58 AM, Chris Hegarty wrote: >> Thanks for the updates Xuelei, some minor comments inline.. >> >>> On 1 Nov 2018, at 23:42, Xuelei Fan >> > wrote: >>> >>> On 11/1/2018 11:24 AM, Sean Mullan wrote: >>>> On 10/31/18 11:52 AM, Chris Hegarty wrote: >>>>> Xuelei, >>>>> >>>>> On 30/10/18 20:55, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> For the current HttpsURLConnection, there is not much security >>>>>> parameters exposed in the public APIs.? An application may need >>>>>> richer information for the underlying TLS connections, for example >>>>>> the negotiated TLS protocol version. >>>>>> >>>>>> Please let me know if you have concerns to add a new method >>>>>> HttpsURLConnection.getSSLSession() and deprecate the duplicated >>>>>> methods, by the end of Nov. 2, 2018. >>>>>> >>>>>> Here is the proposal: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213161 >>>> Are there any security issues associated with returning the >>>> SSLSession, since it is mutable? >>> It should be fine. ?The update APIs of the session (invalidating, >>> bind values) does not impact the connection. >> >> Alternatively, as is done in the new HTTP Client, an immutable >> SSLSession instance can be returned. >> >>>> +???? *?????????? SHOULD override this method with appropriate >>>> implementation. >>>> s/appropriate/an appropriate/ >>>> I would probably not capitalize "SHOULD" and just say "should". >>>> "SHOULD" is more common in RFCs. I don't see that much in javadocs. >>>> +???? * @implNote The JDK Reference Implementation supports this >>>> operation. >>>> +???? *?????????? As an application may have to use this operation >>>> for more >>>> +???? *?????????? security parameters, it is recommended to support >>>> this >>>> +???? *?????????? operation in all implementations. >>>> I think it should be obvious that the JDK implementation would >>>> override this method so not sure that first sentence is necessary. >>>> The other sentence seems like it could be combined with the previous >>>> sentence, ex: >>>> "Subclasses should override this method with an appropriate >>>> implementation since an application may need to access additional >>>> parameters associated with the SSL session." >>> Updated accordingly, in the CSR and webrev: >>> https://bugs.openjdk.java.net/browse/JDK-8213161 >> >> The CSR looks good. I made a few minor edits to the verbiage >> and added myself as reviewer. >> >> The title will need to be updated to reflect the addition of the >> new method in SecureCacheResponse. Maybe: >> >> "Add?SSLSession accessors to HttpsURLConnection and >> SecureCacheResponse" >> >> -Chris. >> >> >> From anthony.scarpino at oracle.com Mon Nov 5 18:59:17 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 5 Nov 2018 10:59:17 -0800 Subject: RFR[s] 8211339: NPE during SSL handshake caused by HostnameChecker Message-ID: Hi, I'd like to get a code review of this simple change. It's a simple check to make sure the hostname variable is not null and throw a proper exception. http://cr.openjdk.java.net/~ascarpino/8211339/webrev.00/ Tony From xuelei.fan at oracle.com Mon Nov 5 19:22:55 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 5 Nov 2018 11:22:55 -0800 Subject: RFR[s] 8211339: NPE during SSL handshake caused by HostnameChecker In-Reply-To: References: Message-ID: <98757a39-17a8-46b8-ef45-370fde4f7722@oracle.com> It looks fine to me. Thanks, Xuelei On 11/5/2018 10:59 AM, Anthony Scarpino wrote: > Hi, > > I'd like to get a code review of this simple change.? It's a simple > check to make sure the hostname variable is not null and throw a proper > exception. > > http://cr.openjdk.java.net/~ascarpino/8211339/webrev.00/ > > Tony From norman.maurer at googlemail.com Mon Nov 5 19:49:17 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Mon, 5 Nov 2018 20:49:17 +0100 Subject: RFR[s] 8211339: NPE during SSL handshake caused by HostnameChecker In-Reply-To: <98757a39-17a8-46b8-ef45-370fde4f7722@oracle.com> References: <98757a39-17a8-46b8-ef45-370fde4f7722@oracle.com> Message-ID: <4695544C-2D71-4CE4-8EA1-6BF93B32EE8F@googlemail.com> LGTM as well? thanks a lot! > On 5. Nov 2018, at 20:22, Xuelei Fan wrote: > > It looks fine to me. > > Thanks, > Xuelei > > On 11/5/2018 10:59 AM, Anthony Scarpino wrote: >> Hi, >> I'd like to get a code review of this simple change. It's a simple check to make sure the hostname variable is not null and throw a proper exception. >> http://cr.openjdk.java.net/~ascarpino/8211339/webrev.00/ >> Tony From valerie.peng at oracle.com Mon Nov 5 19:52:53 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 5 Nov 2018 11:52:53 -0800 Subject: RFR[12] JDK-8211049 "Second parameter of "initialize" method is not used" In-Reply-To: References: <9bc3a901-518f-10e7-a2e6-8222e031c889@oracle.com> Message-ID: Sure, I did test only against SunRsaSign provider in my initial version if that's what you prefer. Valerie On 11/1/2018 7:55 PM, Weijun Wang wrote: > Hi Valerie > > Since you are specifically fixing a bug inside the SunRsaSign provider, is it enough to just use the KeyPairGenerator from this provider? > > The src fix is fine. > > Thanks > Max > > >> On Nov 2, 2018, at 10:14 AM, Valerie Peng wrote: >> >> Hi, >> >> Anyone can help review this trivial fix? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211049 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8211049/webrev.00/ >> >> Mach5 result with the new regression test is clean. >> >> Thanks, >> Valerie From Roger.Riggs at oracle.com Mon Nov 5 22:00:58 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 5 Nov 2018 17:00:58 -0500 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <4942fe9f-8f79-38f1-454b-d8bdc3700fd5@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> <6490c8ce-966d-e056-7da2-c3ab6e8bb845@oracle.com> <4942fe9f-8f79-38f1-454b-d8bdc3700fd5@oracle.com> Message-ID: <97dcfd3d-08c6-4627-7da1-64b71de92ee5@oracle.com> Hi Dean, Looks ok, I have no better suggestion. Roger On 11/05/2018 01:51 PM, dean.long at oracle.com wrote: > Hi Roger.? Thanks for looking at this. > > On 11/5/18 7:21 AM, Roger Riggs wrote: >> Hi Dean, >> >> typo AccessController line788: "annocations" >> > > Fixed. > >> The implementations of >> >> doPrivileged(PrivilegedExceptionAction action) and >> doPrivileged(PrivilegedAction action) >> >> Could be a bit more similar since except for the exception wrapping >> they are the same. >> > > I was trying to make doPrivileged(PrivilegedExceptionAction > action)? look like > doPrivileged(PrivilegedExceptionAction action, AccessControlContext > context), but I didn't see the point in doing that with > doPrivileged(PrivilegedAction action).? Do you have a suggestion on > how to improve it? > >> 309 return executePrivileged(action, null, >> Reflection.getCallerClass()); vs. AccessControlContext context = null; >> 548 Class caller = Reflection.getCallerClass(); >> 549 try { >> 550 return executePrivileged(action, context, caller); >> >> The context and caller locals aren't needed. >> > > I agree, if no exception is thrown, but just in case I'd rather not do > any extra work inside the "try" that might cause > an exception to be wrapped that shouldn't. > > dl > >> Thanks, Roger >> >> On 11/03/2018 04:00 PM, dean.long at oracle.com wrote: >>> I made a pass at improving the comments based on feedback I've >>> received.? I updated webrev.4 in place, along with an incremental diff: >>> >>> http://cr.openjdk.java.net/~dlong/8212605/webrev.4.update/ >>> >>> dl >>> >>> On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >>>> I find the tail call optimization comment in wrapException adds >>>> only confusion to an otherwise clear helper. But maybe it?s just me >>>> who does not understand it. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Nov 5 22:26:08 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 5 Nov 2018 14:26:08 -0800 Subject: RFR[12] JDK-8211049 "Second parameter of "initialize" method is not used" In-Reply-To: References: <9bc3a901-518f-10e7-a2e6-8222e031c889@oracle.com> Message-ID: <41848175-01cc-662b-8927-2eb72eeb6bac@oracle.com> Webrev updated at: http://cr.openjdk.java.net/~valeriep/8211049/webrev.01 Thanks, Valerie On 11/5/2018 11:52 AM, Valerie Peng wrote: > > Sure, I did test only against SunRsaSign provider in my initial > version if that's what you prefer. > > Valerie > > > On 11/1/2018 7:55 PM, Weijun Wang wrote: >> Hi Valerie >> >> Since you are specifically fixing a bug inside the SunRsaSign >> provider, is it enough to just use the KeyPairGenerator from this >> provider? >> >> The src fix is fine. >> >> Thanks >> Max >> >> >>> On Nov 2, 2018, at 10:14 AM, Valerie Peng >>> wrote: >>> >>> Hi, >>> >>> Anyone can help review this trivial fix? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211049 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8211049/webrev.00/ >>> >>> Mach5 result with the new regression test is clean. >>> >>> Thanks, >>> Valerie > From dean.long at oracle.com Mon Nov 5 23:54:44 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 5 Nov 2018 15:54:44 -0800 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <97dcfd3d-08c6-4627-7da1-64b71de92ee5@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> <2768f4be-458a-f78d-89ab-55450cec5915@oracle.com> <46bff210-18fb-474e-42f3-0a277d955b84@oracle.com> <6490c8ce-966d-e056-7da2-c3ab6e8bb845@oracle.com> <4942fe9f-8f79-38f1-454b-d8bdc3700fd5@oracle.com> <97dcfd3d-08c6-4627-7da1-64b71de92ee5@oracle.com> Message-ID: <9945ded5-cf9d-1768-1d5f-bade85851b2e@oracle.com> Thanks Roger. dl On 11/5/18 2:00 PM, Roger Riggs wrote: > Hi Dean, > > Looks ok, I have no better suggestion. > > Roger > > > On 11/05/2018 01:51 PM, dean.long at oracle.com wrote: >> Hi Roger.? Thanks for looking at this. >> >> On 11/5/18 7:21 AM, Roger Riggs wrote: >>> Hi Dean, >>> >>> typo AccessController line788: "annocations" >>> >> >> Fixed. >> >>> The implementations of >>> >>> doPrivileged(PrivilegedExceptionAction action) and >>> doPrivileged(PrivilegedAction action) >>> >>> Could be a bit more similar since except for the exception wrapping >>> they are the same. >>> >> >> I was trying to make doPrivileged(PrivilegedExceptionAction >> action)? look like >> doPrivileged(PrivilegedExceptionAction action, >> AccessControlContext context), but I didn't see the point in doing >> that with >> doPrivileged(PrivilegedAction action).? Do you have a suggestion >> on how to improve it? >> >>> 309 return executePrivileged(action, null, >>> Reflection.getCallerClass()); vs. AccessControlContext context = null; >>> 548 Class caller = Reflection.getCallerClass(); >>> 549 try { >>> 550 return executePrivileged(action, context, caller); >>> >>> The context and caller locals aren't needed. >>> >> >> I agree, if no exception is thrown, but just in case I'd rather not >> do any extra work inside the "try" that might cause >> an exception to be wrapped that shouldn't. >> >> dl >> >>> Thanks, Roger >>> >>> On 11/03/2018 04:00 PM, dean.long at oracle.com wrote: >>>> I made a pass at improving the comments based on feedback I've >>>> received.? I updated webrev.4 in place, along with an incremental >>>> diff: >>>> >>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.4.update/ >>>> >>>> dl >>>> >>>> On 10/31/18 9:39 PM, Bernd Eckenfels wrote: >>>>> I find the tail call optimization comment in wrapException adds >>>>> only confusion to an otherwise clear helper. But maybe it?s just >>>>> me who does not understand it. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Nov 6 00:30:38 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 6 Nov 2018 08:30:38 +0800 Subject: RFR[12] JDK-8211049 "Second parameter of "initialize" method is not used" In-Reply-To: <41848175-01cc-662b-8927-2eb72eeb6bac@oracle.com> References: <9bc3a901-518f-10e7-a2e6-8222e031c889@oracle.com> <41848175-01cc-662b-8927-2eb72eeb6bac@oracle.com> Message-ID: Hi Valerie The change looks fine to me. Thanks Max > On Nov 6, 2018, at 6:26 AM, Valerie Peng wrote: > > Webrev updated at: http://cr.openjdk.java.net/~valeriep/8211049/webrev.01 > > Thanks, > > Valerie > > > On 11/5/2018 11:52 AM, Valerie Peng wrote: >> >> Sure, I did test only against SunRsaSign provider in my initial version if that's what you prefer. >> >> Valerie >> >> >> On 11/1/2018 7:55 PM, Weijun Wang wrote: >>> Hi Valerie >>> >>> Since you are specifically fixing a bug inside the SunRsaSign provider, is it enough to just use the KeyPairGenerator from this provider? >>> >>> The src fix is fine. >>> >>> Thanks >>> Max >>> >>> >>>> On Nov 2, 2018, at 10:14 AM, Valerie Peng wrote: >>>> >>>> Hi, >>>> >>>> Anyone can help review this trivial fix? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211049 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8211049/webrev.00/ >>>> >>>> Mach5 result with the new regression test is clean. >>>> >>>> Thanks, >>>> Valerie >> > From valerie.peng at oracle.com Tue Nov 6 02:26:38 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 5 Nov 2018 18:26:38 -0800 Subject: RFR[12] JDK-8211049 "Second parameter of "initialize" method is not used" In-Reply-To: References: <9bc3a901-518f-10e7-a2e6-8222e031c889@oracle.com> <41848175-01cc-662b-8927-2eb72eeb6bac@oracle.com> Message-ID: <967d01ee-15b8-6be6-fa8b-d850659dbe3f@oracle.com> Thanks for the review~ Valerie On 11/5/2018 4:30 PM, Weijun Wang wrote: > Hi Valerie > > The change looks fine to me. > > Thanks > Max > >> On Nov 6, 2018, at 6:26 AM, Valerie Peng wrote: >> >> Webrev updated at: http://cr.openjdk.java.net/~valeriep/8211049/webrev.01 >> >> Thanks, >> >> Valerie >> >> >> On 11/5/2018 11:52 AM, Valerie Peng wrote: >>> Sure, I did test only against SunRsaSign provider in my initial version if that's what you prefer. >>> >>> Valerie >>> >>> >>> On 11/1/2018 7:55 PM, Weijun Wang wrote: >>>> Hi Valerie >>>> >>>> Since you are specifically fixing a bug inside the SunRsaSign provider, is it enough to just use the KeyPairGenerator from this provider? >>>> >>>> The src fix is fine. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> On Nov 2, 2018, at 10:14 AM, Valerie Peng wrote: >>>>> >>>>> Hi, >>>>> >>>>> Anyone can help review this trivial fix? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211049 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8211049/webrev.00/ >>>>> >>>>> Mach5 result with the new regression test is clean. >>>>> >>>>> Thanks, >>>>> Valerie From weijun.wang at oracle.com Tue Nov 6 03:13:17 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 6 Nov 2018 11:13:17 +0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation Message-ID: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> Please take a review at the CSR at https://bugs.openjdk.java.net/browse/JDK-8213401 As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. Another question: in sun.security.util.CurveDB, we have // Return EC parameters for the specified field size. If there are known // NIST recommended parameters for the given length, they are returned. // Otherwise, if there are multiple matches for the given size, an // arbitrary one is returns. // If no parameters are known, the method returns null. // NOTE that this method returns both prime and binary curves. static NamedCurve lookup(int length) { return lengthMap.get(length); } FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? In fact, CurveDB.java seems to have a bug when adding the curves: add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... and now 163 is sect163r2 and 233 is sect233k1. I assume we should always prefer the K- one? Thanks Max From xuelei.fan at oracle.com Tue Nov 6 04:12:12 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 5 Nov 2018 20:12:12 -0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> Message-ID: <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> On 11/5/2018 7:13 PM, Weijun Wang wrote: > Please take a review at the CSR at > > https://bugs.openjdk.java.net/browse/JDK-8213401 > > As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. > Why not use a strict mode: fail if not match. It might be misleading if ignoring unmatched options. > Another question: in sun.security.util.CurveDB, we have > > // Return EC parameters for the specified field size. If there are known > // NIST recommended parameters for the given length, they are returned. > // Otherwise, if there are multiple matches for the given size, an > // arbitrary one is returns. > // If no parameters are known, the method returns null. > // NOTE that this method returns both prime and binary curves. > static NamedCurve lookup(int length) { > return lengthMap.get(length); > } > > FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? > > In fact, CurveDB.java seems to have a bug when adding the curves: > > add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... > add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? > add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... > add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... > > and now 163 is sect163r2 and 233 is sect233k1. > > I assume we should always prefer the K- one? > TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. Do you mean if no -curvename option, there is a need to choose a named curve? Xuelei From weijun.wang at oracle.com Tue Nov 6 04:37:55 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 6 Nov 2018 12:37:55 +0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> Message-ID: > On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote: > > On 11/5/2018 7:13 PM, Weijun Wang wrote: >> Please take a review at the CSR at >> https://bugs.openjdk.java.net/browse/JDK-8213401 >> As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. > Why not use a strict mode: fail if not match. It might be misleading if ignoring unmatched options. We can do that, but misleading to what? That we treat -curvename and -keysize the same important? > >> Another question: in sun.security.util.CurveDB, we have >> // Return EC parameters for the specified field size. If there are known >> // NIST recommended parameters for the given length, they are returned. >> // Otherwise, if there are multiple matches for the given size, an >> // arbitrary one is returns. >> // If no parameters are known, the method returns null. >> // NOTE that this method returns both prime and binary curves. >> static NamedCurve lookup(int length) { >> return lengthMap.get(length); >> } >> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? >> In fact, CurveDB.java seems to have a bug when adding the curves: >> add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... >> add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? >> add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... >> add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... >> and now 163 is sect163r2 and 233 is sect233k1. >> I assume we should always prefer the K- one? > TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. There is no ambiguity for prime curves. > > Do you mean if no -curvename option, there is a need to choose a named curve? ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I just meant if we have a bug here and if we should be more public on what curve is chosen. Thanks Max > > Xuelei From xuelei.fan at oracle.com Tue Nov 6 05:06:19 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 5 Nov 2018 21:06:19 -0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> Message-ID: <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> On 11/5/2018 8:37 PM, Weijun Wang wrote: > >> On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote: >> >> On 11/5/2018 7:13 PM, Weijun Wang wrote: >>> Please take a review at the CSR at >>> https://bugs.openjdk.java.net/browse/JDK-8213401 >>> As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. >> Why not use a strict mode: fail if not match. It might be misleading if ignoring unmatched options. > > We can do that, but misleading to what? That we treat -curvename and -keysize the same important? > If the option "-keysize 256 -curvename sect163k1" work, I may think that the key size if 256 bits. I want to create a 256 bits sect163k1 EC key, and the tool allows this behavior, so I should get a 256 bits sect163k1 EC key. Sure, that's incorrect, but I don't know it is incorrect as the tool ignore the key size. What's the problem of the command, I don't know either unless I clearly understand sect163k1 is not 256 bits. The next question to me, what's the key size actually is? 256 bits or 163 bits? which option are used? It adds more confusing to me. We can ignore the -keysize option, but it is complicated to me to use the tool. >> >>> Another question: in sun.security.util.CurveDB, we have >>> // Return EC parameters for the specified field size. If there are known >>> // NIST recommended parameters for the given length, they are returned. >>> // Otherwise, if there are multiple matches for the given size, an >>> // arbitrary one is returns. >>> // If no parameters are known, the method returns null. >>> // NOTE that this method returns both prime and binary curves. >>> static NamedCurve lookup(int length) { >>> return lengthMap.get(length); >>> } >>> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? >>> In fact, CurveDB.java seems to have a bug when adding the curves: >>> add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... >>> add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? >>> add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... >>> add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... >>> and now 163 is sect163r2 and 233 is sect233k1. >>> I assume we should always prefer the K- one? >> TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. > > There is no ambiguity for prime curves. > >> >> Do you mean if no -curvename option, there is a need to choose a named curve? > > ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I just meant if we have a bug here and if we should be more public on what curve is chosen. > I see your concerns. It might be a potential issue if we use a named curve if no curvename specified. If the compatibility is not serious, I may suggest supported named curves only, or use arbitrary curves but with a warning. Xuelei From martin.choma at gmail.com Tue Nov 6 06:46:34 2018 From: martin.choma at gmail.com (Martin Choma) Date: Tue, 6 Nov 2018 07:46:34 +0100 Subject: java.lang.NoSuchFieldError: state Message-ID: Hey, with upgrade to 1.8.0_191 I hit "java.lang.NoSuchFieldError: state" during SSL handshake. I have found https://bugs.java.com/view_bug.do?bug_id=JDK-8074462 but I couldn find openjdk counterpart. Some more details can be found [1]. Regards, Martin Choma [1] https://issues.jboss.org/browse/ELY-1708 From norman.maurer at googlemail.com Tue Nov 6 07:16:50 2018 From: norman.maurer at googlemail.com (Norman Maurer) Date: Tue, 6 Nov 2018 08:16:50 +0100 Subject: java.lang.NoSuchFieldError: state In-Reply-To: References: Message-ID: <117DBAD8-05BD-4070-9EC2-A9C26C8C7604@googlemail.com> I think this may be caused by using the wrong jetty alpn version. Be sure you use the correct one. For example 2.0.9: https://github.com/jetty-project/jetty-alpn-agent/releases Bye Norman > On 6. Nov 2018, at 07:46, Martin Choma wrote: > > Hey, > > with upgrade to 1.8.0_191 I hit "java.lang.NoSuchFieldError: state" > during SSL handshake. > I have found https://bugs.java.com/view_bug.do?bug_id=JDK-8074462 but > I couldn find openjdk counterpart. Some more details can be found [1]. > > Regards, > Martin Choma > > [1] https://issues.jboss.org/browse/ELY-1708 -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Nov 6 07:18:01 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 6 Nov 2018 15:18:01 +0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> Message-ID: <6FBECFDA-A7C1-4DA1-BD3B-2CBCEFADF33F@oracle.com> > On Nov 6, 2018, at 1:06 PM, Xuelei Fan wrote: > > On 11/5/2018 8:37 PM, Weijun Wang wrote: >>> On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote: >>> >>> On 11/5/2018 7:13 PM, Weijun Wang wrote: >>>> Please take a review at the CSR at >>>> https://bugs.openjdk.java.net/browse/JDK-8213401 >>>> As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. >>> Why not use a strict mode: fail if not match. It might be misleading if ignoring unmatched options. >> We can do that, but misleading to what? That we treat -curvename and -keysize the same important? > If the option "-keysize 256 -curvename sect163k1" work, I may think that the key size if 256 bits. I want to create a 256 bits sect163k1 EC key, and the tool allows this behavior, so I should get a 256 bits sect163k1 EC key. Sure, that's incorrect, but I don't know it is incorrect as the tool ignore the key size. What's the problem of the command, I don't know either unless I clearly understand sect163k1 is not 256 bits. The next question to me, what's the key size actually is? 256 bits or 163 bits? which option are used? It adds more confusing to me. Well explained. I've updated the CSR and this will be an error. > > We can ignore the -keysize option, but it is complicated to me to use the tool. > >>> >>>> Another question: in sun.security.util.CurveDB, we have >>>> // Return EC parameters for the specified field size. If there are known >>>> // NIST recommended parameters for the given length, they are returned. >>>> // Otherwise, if there are multiple matches for the given size, an >>>> // arbitrary one is returns. >>>> // If no parameters are known, the method returns null. >>>> // NOTE that this method returns both prime and binary curves. >>>> static NamedCurve lookup(int length) { >>>> return lengthMap.get(length); >>>> } >>>> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? >>>> In fact, CurveDB.java seems to have a bug when adding the curves: >>>> add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... >>>> add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? >>>> add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... >>>> add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... >>>> and now 163 is sect163r2 and 233 is sect233k1. >>>> I assume we should always prefer the K- one? >>> TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. >> There is no ambiguity for prime curves. >>> >>> Do you mean if no -curvename option, there is a need to choose a named curve? >> ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I just meant if we have a bug here and if we should be more public on what curve is chosen. > I see your concerns. > > It might be a potential issue if we use a named curve if no curvename specified. If the compatibility is not serious, I may suggest supported named curves only, or use arbitrary curves but with a warning. If people only want prime curves then -keysize still works. A warning is enough since in the CSR I've also said "we recommend". Thanks Max > > Xuelei From ecki at zusammenkunft.net Tue Nov 6 07:41:29 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 6 Nov 2018 07:41:29 +0000 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> , <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> Message-ID: Hello, I would agree ignoring an (conflicting) option adds confusion. When specifying a curve is a new feature we don?t need to worry about beeing compatible, therefore I would forbid mixing curve names and keysize at all (even when the size matches). I guess we cannot remove the option to only pass the keysize (to have the generator pick a curve) to stay compatible. But the chosen curve should be printed, and I would also deprecate this usage. I guess clarifying the keysize-only init() method would be a different topic, but something like deprecating it and restricting the selection to ?SunEC only selects NIST prime curves? would be a good thing. Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Xuelei Fan Gesendet: Dienstag, November 6, 2018 7:38 AM An: Weijun Wang Cc: security-dev at openjdk.java.net Betreff: Re: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation On 11/5/2018 8:37 PM, Weijun Wang wrote: > >> On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote: >> >> On 11/5/2018 7:13 PM, Weijun Wang wrote: >>> Please take a review at the CSR at >>> https://bugs.openjdk.java.net/browse/JDK-8213401 >>> As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. >> Why not use a strict mode: fail if not match. It might be misleading if ignoring unmatched options. > > We can do that, but misleading to what? That we treat -curvename and -keysize the same important? > If the option "-keysize 256 -curvename sect163k1" work, I may think that the key size if 256 bits. I want to create a 256 bits sect163k1 EC key, and the tool allows this behavior, so I should get a 256 bits sect163k1 EC key. Sure, that's incorrect, but I don't know it is incorrect as the tool ignore the key size. What's the problem of the command, I don't know either unless I clearly understand sect163k1 is not 256 bits. The next question to me, what's the key size actually is? 256 bits or 163 bits? which option are used? It adds more confusing to me. We can ignore the -keysize option, but it is complicated to me to use the tool. >> >>> Another question: in sun.security.util.CurveDB, we have >>> // Return EC parameters for the specified field size. If there are known >>> // NIST recommended parameters for the given length, they are returned. >>> // Otherwise, if there are multiple matches for the given size, an >>> // arbitrary one is returns. >>> // If no parameters are known, the method returns null. >>> // NOTE that this method returns both prime and binary curves. >>> static NamedCurve lookup(int length) { >>> return lengthMap.get(length); >>> } >>> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? >>> In fact, CurveDB.java seems to have a bug when adding the curves: >>> add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... >>> add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? >>> add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... >>> add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... >>> and now 163 is sect163r2 and 233 is sect233k1. >>> I assume we should always prefer the K- one? >> TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. > > There is no ambiguity for prime curves. > >> >> Do you mean if no -curvename option, there is a need to choose a named curve? > > ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I just meant if we have a bug here and if we should be more public on what curve is chosen. > I see your concerns. It might be a potential issue if we use a named curve if no curvename specified. If the compatibility is not serious, I may suggest supported named curves only, or use arbitrary curves but with a warning. Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Tue Nov 6 07:51:43 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 5 Nov 2018 23:51:43 -0800 Subject: RFR, JDK-8212885: TLS 1.3 resumed session does not retain peer certificate chain Message-ID: <5f37d700-8859-da3c-c524-23bae8b24b5c@oracle.com> Hello all, This fixes an issue where TLS 1.3 resumed sessions were not carrying forward many of the parameters from the parent session, namely the peer certificates, but also the local certificates and a few other SSLSessionImpl fields.? This also moves the fix from an earlier, related issue with SNI names (JDK-8211806) into this new solution. JBS: https://bugs.openjdk.java.net/browse/JDK-8212885 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.01 Thanks, --Jamil From sean.coffey at oracle.com Tue Nov 6 08:46:27 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 6 Nov 2018 08:46:27 +0000 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> Message-ID: <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> With JDK-8203629 now pushed, I've re-based my patch on latest jdk/jdk code. Some modifications also made based on off-thread suggestions : src/java.base/share/classes/java/security/Security.java * Only record JDK security properties for now (i.e. those in java.security conf file) ? - we can consider a new event to record non-JDK security events if demand comes about ? - new event renamed to *Jdk*SecurityPropertyModificationEvent src/java.base/share/classes/sun/security/x509/X509CertImpl.java * Use hashCode() equality test for storing certs in List. Tests updated to capture these changes src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java * Verify that self signed certs exercise the modified code paths I've added new test functionality to test use of self signed cert. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v7/webrev/ Regards, Sean. On 17/10/18 11:25, Se?n Coffey wrote: > I'd like to re-boot this review. I've been working with Erik off > thread who's been helping with code and test design. > > Some of the main changes worthy of highlighting : > > * Separate out the tests for JFR and Logger events > * Rename some events > * Normalize the data view for X509ValidationEvent (old event name : > CertChainEvent) > * Introduce CertificateSerialNumber type to make use of the > @Relational JFR annotation. > * Keep calls for JFR event operations local to call site to optimize > jvm compilation > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v6/webrev/ > > This code is dependent on the JDK-8203629 enhancement being integrated. > > Regards, > Sean. > > On 10/07/18 13:50, Se?n Coffey wrote: >> Erik, >> >> After some trial edits, I'm not so sure if moving the event & logger >> commit code into the class where it's used works too well after all. >> >> In the code you suggested, there's an assumption that calls such as >> EventHelper.certificateChain(..) are low cost. While that might be >> the case here, it's something we can't always assume. It's called >> once for the JFR operation and once for the Logger operation. That >> pattern multiplies itself further in other Events. i.e. set up and >> assign the variables for a JFR event without knowing whether they'll >> be needed again for the Logger call. We could work around it by >> setting up some local variables and re-using them in the Logger code >> but then, we're back to where we were. The current EventHelper design >> eliminates this problem and also helps to abstract the >> recording/logging functionality away from the functionality of the >> class itself. >> >> It also becomes a problem where we record events in multiple >> different classes (e.g. SecurityPropertyEvent). While we could leave >> the code in EventHelper for this case, we then have a mixed design >> pattern. >> >> Are you ok with leaving as is for now? A future wish might be one >> where JFR would handle Logger via its own framework/API in a future >> JDK release. >> >> I've removed the variable names using underscore. Also optimized some >> variable assignments in X509Impl.commitEvent(..) >> >> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ >> >> regards, >> Sean. >> >> On 09/07/2018 18:01, Se?n Coffey wrote: >>> Erik, >>> >>> Thanks for reviewing. Comments inline.. >>> >>> On 09/07/18 17:21, Erik Gahlin wrote: >>>> Thanks Sean. >>>> >>>> Some feedback on the code in the security libraries. >>>> >>>> - We should use camel case naming convention for variables (not >>>> underscore). >>> Sure. I see two offending variable names which I'll fix up. >>>> >>>> - Looking at sun/security/ssl/Finished.java, >>>> >>>> I wonder if it wouldn't be less code and more easy to read, if we >>>> would commit the event in a local private function and then use the >>>> EventHelper class for common functionality. >>> I'm fine with your suggested approach. I figured that tucking the >>> recording/logging logic away in a helper class also had benefits but >>> I'll re-factor to your suggested style unless I hear objections. >>> >>> regards, >>> Sean. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Nov 6 09:22:35 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 6 Nov 2018 09:22:35 +0000 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> Message-ID: > On 5 Nov 2018, at 18:52, Xuelei Fan wrote: > > Hi Chris and Sean, > > There are a few feedback for the CSR approval. I updated to use Optional for the returned value. For more details, please refer to: > https://bugs.openjdk.java.net/browse/JDK-8213161 > http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/ Looks ok to me. -Chris. From martin.choma at gmail.com Tue Nov 6 11:13:28 2018 From: martin.choma at gmail.com (Martin Choma) Date: Tue, 6 Nov 2018 12:13:28 +0100 Subject: java.lang.NoSuchFieldError: state In-Reply-To: <117DBAD8-05BD-4070-9EC2-A9C26C8C7604@googlemail.com> References: <117DBAD8-05BD-4070-9EC2-A9C26C8C7604@googlemail.com> Message-ID: You are right. Upgrade to [1] helped in my case. Thank you for your help. [1] https://mvnrepository.com/artifact/org.mortbay.jetty.alpn/alpn-boot/8.1.13.v20181017 On Tue, 6 Nov 2018 at 08:17, Norman Maurer wrote: > > I think this may be caused by using the wrong jetty alpn version. > > Be sure you use the correct one. For example 2.0.9: > > https://github.com/jetty-project/jetty-alpn-agent/releases > > Bye > Norman > > > On 6. Nov 2018, at 07:46, Martin Choma wrote: > > Hey, > > with upgrade to 1.8.0_191 I hit "java.lang.NoSuchFieldError: state" > during SSL handshake. > I have found https://bugs.java.com/view_bug.do?bug_id=JDK-8074462 but > I couldn find openjdk counterpart. Some more details can be found [1]. > > Regards, > Martin Choma > > [1] https://issues.jboss.org/browse/ELY-1708 > > From adam.petcher at oracle.com Tue Nov 6 14:57:00 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 6 Nov 2018 09:57:00 -0500 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <6FBECFDA-A7C1-4DA1-BD3B-2CBCEFADF33F@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <6FBECFDA-A7C1-4DA1-BD3B-2CBCEFADF33F@oracle.com> Message-ID: <5c19a6d0-91ec-cedb-ccf5-ebf885dcf16d@oracle.com> On 11/6/2018 2:18 AM, Weijun Wang wrote: >> On Nov 6, 2018, at 1:06 PM, Xuelei Fan wrote: >> >> If the option "-keysize 256 -curvename sect163k1" work, I may think that the key size if 256 bits. I want to create a 256 bits sect163k1 EC key, and the tool allows this behavior, so I should get a 256 bits sect163k1 EC key. Sure, that's incorrect, but I don't know it is incorrect as the tool ignore the key size. What's the problem of the command, I don't know either unless I clearly understand sect163k1 is not 256 bits. The next question to me, what's the key size actually is? 256 bits or 163 bits? which option are used? It adds more confusing to me. > Well explained. I've updated the CSR and this will be an error. This is a good improvement. If you like, you could even go one step further and error out any time -curvename and -keysize are used at the same time, even if the size is correct. This would simplify things and discourage use of -keysize for EC keys. > (curve ambiguity issue with -keysize) > > Thanks > Max > I don't think it is worthwhile to add any code to choose some particular curve when only -keysize is used (or KeyPairGenerator.init(int)). Keeping the current behavior and choosing an arbitrary curve of the specified size is fine. Emitting a warning is a good idea, and if you plan to do this, you might want to emit a warning any time -keysize is used with an EC key, regardless of whether there are (currently) multiple curves of the specified size. From xuelei.fan at oracle.com Tue Nov 6 15:36:28 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 6 Nov 2018 07:36:28 -0800 Subject: RFR, JDK-8212885: TLS 1.3 resumed session does not retain peer certificate chain In-Reply-To: <5f37d700-8859-da3c-c524-23bae8b24b5c@oracle.com> References: <5f37d700-8859-da3c-c524-23bae8b24b5c@oracle.com> Message-ID: <0b9dec8a-f4b3-4fbc-dfc8-3fcf492f91f5@oracle.com> Nice update! For the update in ClientHello.java, I may suggest moving it to pre_shared_key extension class. It may be a little bit safer if the extension can be loaded in other places. Thanks, Xuelei On 11/5/2018 11:51 PM, Jamil Nimeh wrote: > Hello all, > > This fixes an issue where TLS 1.3 resumed sessions were not carrying > forward many of the parameters from the parent session, namely the peer > certificates, but also the local certificates and a few other > SSLSessionImpl fields.? This also moves the fix from an earlier, related > issue with SNI names (JDK-8211806) into this new solution. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8212885 > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.01 > > Thanks, > > --Jamil > From xuelei.fan at oracle.com Tue Nov 6 16:00:03 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 6 Nov 2018 08:00:03 -0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> Message-ID: <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> As -curvename is a new option, I would second the comments that don't allow mixing curve names and keysize at the same time. Xuelei On 11/5/2018 11:41 PM, Bernd Eckenfels wrote: > Hello, > > I would agree ignoring an (conflicting) option adds confusion. When > specifying a curve is a new feature we don?t need to worry about beeing > compatible, therefore I would ?forbid mixing curve names and keysize at > all (even when the size matches). > > I guess we cannot remove the option to only pass the keysize (to have > the generator pick a curve) to stay compatible. But the chosen curve > should be printed, and I would also deprecate this usage. > > I guess clarifying the keysize-only init() method would be a different > topic, but something like deprecating it and restricting the selection > to ?SunEC only selects NIST prime curves? would be a good thing. > > Gruss > Bernd > > > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Xuelei Fan > *Gesendet:* Dienstag, November 6, 2018 7:38 AM > *An:* Weijun Wang > *Cc:* security-dev at openjdk.java.net > *Betreff:* Re: RFR CSR for 8213400: Support choosing curve name in > keytool keypair generation > On 11/5/2018 8:37 PM, Weijun Wang wrote: > > > >> On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote: > >> > >> On 11/5/2018 7:13 PM, Weijun Wang wrote: > >>> Please take a review at the CSR at > >>> https://bugs.openjdk.java.net/browse/JDK-8213401 > >>> As for implementation, I intend to report an error when -keyalg is > not EC but -curvename is provided. If both -curvename and -keysize are > provided, I intend to ignore -keysize no matter if they match or not. > >> Why not use a strict mode: fail if not match. It might be misleading > if ignoring unmatched options. > > > > We can do that, but misleading to what? That we treat -curvename and > -keysize the same important? > > > If the option "-keysize 256 -curvename sect163k1" work, I may think that > the key size if 256 bits. I want to create a 256 bits sect163k1 EC key, > and the tool allows this behavior, so I should get a 256 bits sect163k1 > EC key. Sure, that's incorrect, but I don't know it is incorrect as the > tool ignore the key size. What's the problem of the command, I don't > know either unless I clearly understand sect163k1 is not 256 bits. The > next question to me, what's the key size actually is? 256 bits or 163 > bits? which option are used? It adds more confusing to me. > > We can ignore the -keysize option, but it is complicated to me to use > the tool. > > >> > >>> Another question: in sun.security.util.CurveDB, we have > >>> // Return EC parameters for the specified field size. If there are > known > >>> // NIST recommended parameters for the given length, they are > returned. > >>> // Otherwise, if there are multiple matches for the given size, an > >>> // arbitrary one is returns. > >>> // If no parameters are known, the method returns null. > >>> // NOTE that this method returns both prime and binary curves. > >>> static NamedCurve lookup(int length) { > >>> return lengthMap.get(length); > >>> } > >>> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve > field size. Do we have a choice? > >>> In fact, CurveDB.java seems to have a bug when adding the curves: > >>> add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... > >>> add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another > default? > >>> add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... > >>> add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... > >>> and now 163 is sect163r2 and 233 is sect233k1. > >>> I assume we should always prefer the K- one? > >> TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. > > > > There is no ambiguity for prime curves. > > > >> > >> Do you mean if no -curvename option, there is a need to choose a > named curve? > > > > ECKeyPairGenerator::initialize(int) will choose one and keytool will > use it. I just meant if we have a bug here and if we should be more > public on what curve is chosen. > > > I see your concerns. > > It might be a potential issue if we use a named curve if no curvename > specified. If the compatibility is not serious, I may suggest supported > named curves only, or use arbitrary curves but with a warning. > > Xuelei From weijun.wang at oracle.com Tue Nov 6 16:13:13 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Nov 2018 00:13:13 +0800 Subject: RFR 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> Message-ID: <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> Webrev updated at https://cr.openjdk.java.net/~weijun/8213009/webrev.00/ The subtask id is now used. The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back. Thanks Max > On Oct 25, 2018, at 4:38 PM, Weijun Wang wrote: > > Please review the change at > > https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ > > (I will use a sub-task id for this change but currently JBS is down). > > The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. > > Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: > > - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. > > - Child class named "RSA" of CKeyPairGenerator. > > - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. > > - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. > > Noreg-cleanup. > > Thanks > Max > > [1] https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier From weijun.wang at oracle.com Tue Nov 6 16:31:56 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Nov 2018 00:31:56 +0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> Message-ID: <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> Thanks everyone. CSR updated, and I describe the behavior in the Solution part. If you are all happy I'll start coding. And yes, KeyPairGenerator::init(int) needs some clarification, but I don't know in which class/method we should add it. Maybe the JDK Provider Doc? --Max > On Nov 7, 2018, at 12:00 AM, Xuelei Fan wrote: > > As -curvename is a new option, I would second the comments that don't allow mixing curve names and keysize at the same time. > > Xuelei > > On 11/5/2018 11:41 PM, Bernd Eckenfels wrote: >> Hello, >> I would agree ignoring an (conflicting) option adds confusion. When specifying a curve is a new feature we don?t need to worry about beeing compatible, therefore I would forbid mixing curve names and keysize at all (even when the size matches). >> I guess we cannot remove the option to only pass the keysize (to have the generator pick a curve) to stay compatible. But the chosen curve should be printed, and I would also deprecate this usage. >> I guess clarifying the keysize-only init() method would be a different topic, but something like deprecating it and restricting the selection to ?SunEC only selects NIST prime curves? would be a good thing. >> Gruss >> Bernd >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ------------------------------------------------------------------------ >> *Von:* security-dev im Auftrag von Xuelei Fan >> *Gesendet:* Dienstag, November 6, 2018 7:38 AM >> *An:* Weijun Wang >> *Cc:* security-dev at openjdk.java.net >> *Betreff:* Re: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation >> On 11/5/2018 8:37 PM, Weijun Wang wrote: >> > >> >> On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote: >> >> >> >> On 11/5/2018 7:13 PM, Weijun Wang wrote: >> >>> Please take a review at the CSR at >> >>> https://bugs.openjdk.java.net/browse/JDK-8213401 >> >>> As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. >> >> Why not use a strict mode: fail if not match. It might be misleading if ignoring unmatched options. >> > >> > We can do that, but misleading to what? That we treat -curvename and -keysize the same important? >> > >> If the option "-keysize 256 -curvename sect163k1" work, I may think that >> the key size if 256 bits. I want to create a 256 bits sect163k1 EC key, >> and the tool allows this behavior, so I should get a 256 bits sect163k1 >> EC key. Sure, that's incorrect, but I don't know it is incorrect as the >> tool ignore the key size. What's the problem of the command, I don't >> know either unless I clearly understand sect163k1 is not 256 bits. The >> next question to me, what's the key size actually is? 256 bits or 163 >> bits? which option are used? It adds more confusing to me. >> We can ignore the -keysize option, but it is complicated to me to use >> the tool. >> >> >> >>> Another question: in sun.security.util.CurveDB, we have >> >>> // Return EC parameters for the specified field size. If there are known >> >>> // NIST recommended parameters for the given length, they are returned. >> >>> // Otherwise, if there are multiple matches for the given size, an >> >>> // arbitrary one is returns. >> >>> // If no parameters are known, the method returns null. >> >>> // NOTE that this method returns both prime and binary curves. >> >>> static NamedCurve lookup(int length) { >> >>> return lengthMap.get(length); >> >>> } >> >>> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? >> >>> In fact, CurveDB.java seems to have a bug when adding the curves: >> >>> add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... >> >>> add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? >> >>> add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... >> >>> add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... >> >>> and now 163 is sect163r2 and 233 is sect233k1. >> >>> I assume we should always prefer the K- one? >> >> TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. >> > >> > There is no ambiguity for prime curves. >> > >> >> >> >> Do you mean if no -curvename option, there is a need to choose a named curve? >> > >> > ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I just meant if we have a bug here and if we should be more public on what curve is chosen. >> > >> I see your concerns. >> It might be a potential issue if we use a named curve if no curvename >> specified. If the compatibility is not serious, I may suggest supported >> named curves only, or use arbitrary curves but with a warning. >> Xuelei From xuelei.fan at oracle.com Tue Nov 6 16:47:15 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 6 Nov 2018 08:47:15 -0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> Message-ID: Some typos: "When multiple curves have the same field size, and one of them is a prime curve or a Koblitz curve, it will be used." Which one will be used? prime curve or Koblitz curve. It will not be documented, right? Otherwise, there are may be more curve categories. As it is not the recommended option, I may just remove this and the following one sentence. Xuelei On 11/6/2018 8:31 AM, Weijun Wang wrote: > Thanks everyone. CSR updated, and I describe the behavior in the Solution part. If you are all happy I'll start coding. > > And yes, KeyPairGenerator::init(int) needs some clarification, but I don't know in which class/method we should add it. Maybe the JDK Provider Doc? > > --Max > >> On Nov 7, 2018, at 12:00 AM, Xuelei Fan wrote: >> >> As -curvename is a new option, I would second the comments that don't allow mixing curve names and keysize at the same time. >> >> Xuelei >> >> On 11/5/2018 11:41 PM, Bernd Eckenfels wrote: >>> Hello, >>> I would agree ignoring an (conflicting) option adds confusion. When specifying a curve is a new feature we don?t need to worry about beeing compatible, therefore I would forbid mixing curve names and keysize at all (even when the size matches). >>> I guess we cannot remove the option to only pass the keysize (to have the generator pick a curve) to stay compatible. But the chosen curve should be printed, and I would also deprecate this usage. >>> I guess clarifying the keysize-only init() method would be a different topic, but something like deprecating it and restricting the selection to ?SunEC only selects NIST prime curves? would be a good thing. >>> Gruss >>> Bernd >>> Gruss >>> Bernd >>> -- >>> http://bernd.eckenfels.net >>> ------------------------------------------------------------------------ >>> *Von:* security-dev im Auftrag von Xuelei Fan >>> *Gesendet:* Dienstag, November 6, 2018 7:38 AM >>> *An:* Weijun Wang >>> *Cc:* security-dev at openjdk.java.net >>> *Betreff:* Re: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation >>> On 11/5/2018 8:37 PM, Weijun Wang wrote: >>>> >>>>> On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote: >>>>> >>>>> On 11/5/2018 7:13 PM, Weijun Wang wrote: >>>>>> Please take a review at the CSR at >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213401 >>>>>> As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. >>>>> Why not use a strict mode: fail if not match. It might be misleading if ignoring unmatched options. >>>> >>>> We can do that, but misleading to what? That we treat -curvename and -keysize the same important? >>>> >>> If the option "-keysize 256 -curvename sect163k1" work, I may think that >>> the key size if 256 bits. I want to create a 256 bits sect163k1 EC key, >>> and the tool allows this behavior, so I should get a 256 bits sect163k1 >>> EC key. Sure, that's incorrect, but I don't know it is incorrect as the >>> tool ignore the key size. What's the problem of the command, I don't >>> know either unless I clearly understand sect163k1 is not 256 bits. The >>> next question to me, what's the key size actually is? 256 bits or 163 >>> bits? which option are used? It adds more confusing to me. >>> We can ignore the -keysize option, but it is complicated to me to use >>> the tool. >>>>> >>>>>> Another question: in sun.security.util.CurveDB, we have >>>>>> // Return EC parameters for the specified field size. If there are known >>>>>> // NIST recommended parameters for the given length, they are returned. >>>>>> // Otherwise, if there are multiple matches for the given size, an >>>>>> // arbitrary one is returns. >>>>>> // If no parameters are known, the method returns null. >>>>>> // NOTE that this method returns both prime and binary curves. >>>>>> static NamedCurve lookup(int length) { >>>>>> return lengthMap.get(length); >>>>>> } >>>>>> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? >>>>>> In fact, CurveDB.java seems to have a bug when adding the curves: >>>>>> add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... >>>>>> add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? >>>>>> add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... >>>>>> add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... >>>>>> and now 163 is sect163r2 and 233 is sect233k1. >>>>>> I assume we should always prefer the K- one? >>>>> TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. >>>> >>>> There is no ambiguity for prime curves. >>>> >>>>> >>>>> Do you mean if no -curvename option, there is a need to choose a named curve? >>>> >>>> ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I just meant if we have a bug here and if we should be more public on what curve is chosen. >>>> >>> I see your concerns. >>> It might be a potential issue if we use a named curve if no curvename >>> specified. If the compatibility is not serious, I may suggest supported >>> named curves only, or use arbitrary curves but with a warning. >>> Xuelei > From mbalao at redhat.com Tue Nov 6 18:12:04 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 6 Nov 2018 15:12:04 -0300 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: <2ee1d1b8-91f5-f0c7-bd9f-31d7d20d472c@oracle.com> References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> <566016d0-00ba-e938-693f-56948b9013da@oracle.com> <2ee1d1b8-91f5-f0c7-bd9f-31d7d20d472c@oracle.com> Message-ID: Hi Valerie, Thanks for having a look at this. Here it's Webrev.14 with that fixed: * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.14/ * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.14.zip I'll start the CSR process now. Kind regards, Martin.- From jamil.j.nimeh at oracle.com Tue Nov 6 18:11:55 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 6 Nov 2018 10:11:55 -0800 Subject: RFR, JDK-8212885: TLS 1.3 resumed session does not retain peer certificate chain In-Reply-To: <0b9dec8a-f4b3-4fbc-dfc8-3fcf492f91f5@oracle.com> References: <5f37d700-8859-da3c-c524-23bae8b24b5c@oracle.com> <0b9dec8a-f4b3-4fbc-dfc8-3fcf492f91f5@oracle.com> Message-ID: Okay, I can move this into PreSharedKeyExtension.java and re-run the local tests that were having issues with it.? Should work pretty well. I'll put out another code review shortly. Thanks, --Jamil On 11/6/2018 7:36 AM, Xuelei Fan wrote: > Nice update! > > For the update in ClientHello.java, I may suggest moving it to > pre_shared_key extension class.? It may be a little bit safer if the > extension can be loaded in other places. > > Thanks, > Xuelei > > On 11/5/2018 11:51 PM, Jamil Nimeh wrote: >> Hello all, >> >> This fixes an issue where TLS 1.3 resumed sessions were not carrying >> forward many of the parameters from the parent session, namely the >> peer certificates, but also the local certificates and a few other >> SSLSessionImpl fields.? This also moves the fix from an earlier, >> related issue with SNI names (JDK-8211806) into this new solution. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8212885 >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.01 >> >> Thanks, >> >> --Jamil >> From jamil.j.nimeh at oracle.com Tue Nov 6 19:05:05 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 6 Nov 2018 11:05:05 -0800 Subject: RFR, JDK-8212885: TLS 1.3 resumed session does not retain peer certificate chain In-Reply-To: References: <5f37d700-8859-da3c-c524-23bae8b24b5c@oracle.com> <0b9dec8a-f4b3-4fbc-dfc8-3fcf492f91f5@oracle.com> Message-ID: <5f56a6e2-87b5-451f-6c8e-807f3cee4da7@oracle.com> Hi Xuelei, updated review here: http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.02 I followed your suggestions and also cleaned up some remnant comments and removed a double-semicolon...just cosmetic stuff. --Jamil On 11/6/18 10:11 AM, Jamil Nimeh wrote: > Okay, I can move this into PreSharedKeyExtension.java and re-run the > local tests that were having issues with it.? Should work pretty well. > > I'll put out another code review shortly. > > Thanks, > --Jamil > > On 11/6/2018 7:36 AM, Xuelei Fan wrote: >> Nice update! >> >> For the update in ClientHello.java, I may suggest moving it to >> pre_shared_key extension class.? It may be a little bit safer if the >> extension can be loaded in other places. >> >> Thanks, >> Xuelei >> >> On 11/5/2018 11:51 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This fixes an issue where TLS 1.3 resumed sessions were not carrying >>> forward many of the parameters from the parent session, namely the >>> peer certificates, but also the local certificates and a few other >>> SSLSessionImpl fields.? This also moves the fix from an earlier, >>> related issue with SNI names (JDK-8211806) into this new solution. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212885 >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.01 >>> >>> Thanks, >>> >>> --Jamil >>> > From xuelei.fan at oracle.com Tue Nov 6 19:29:42 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 6 Nov 2018 11:29:42 -0800 Subject: RFR, JDK-8212885: TLS 1.3 resumed session does not retain peer certificate chain In-Reply-To: <5f56a6e2-87b5-451f-6c8e-807f3cee4da7@oracle.com> References: <5f37d700-8859-da3c-c524-23bae8b24b5c@oracle.com> <0b9dec8a-f4b3-4fbc-dfc8-3fcf492f91f5@oracle.com> <5f56a6e2-87b5-451f-6c8e-807f3cee4da7@oracle.com> Message-ID: <427b9e24-fbc5-65e0-d3f3-385c0a1b6236@oracle.com> Looks fine to me. As you are already there, would you mind have an additional improvement in PreSharedKeyExtension.java? - MessageDigest md = MessageDigest.getInstance(hashAlg.toString());; + MessageDigest md = MessageDigest.getInstance(hashAlg.toString()); Normally, the toString() is not a reliable method to get the precise algorithm name. Would you mind update to use hashAlg.name instead? - MessageDigest md = MessageDigest.getInstance(hashAlg.toString());; + MessageDigest md = MessageDigest.getInstance(hashAlg.name); Thanks, Xuelei On 11/6/2018 11:05 AM, Jamil Nimeh wrote: > Hi Xuelei, updated review here: > > http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.02 > > I followed your suggestions and also cleaned up some remnant comments > and removed a double-semicolon...just cosmetic stuff. > > --Jamil > > On 11/6/18 10:11 AM, Jamil Nimeh wrote: >> Okay, I can move this into PreSharedKeyExtension.java and re-run the >> local tests that were having issues with it.? Should work pretty well. >> >> I'll put out another code review shortly. >> >> Thanks, >> --Jamil >> >> On 11/6/2018 7:36 AM, Xuelei Fan wrote: >>> Nice update! >>> >>> For the update in ClientHello.java, I may suggest moving it to >>> pre_shared_key extension class.? It may be a little bit safer if the >>> extension can be loaded in other places. >>> >>> Thanks, >>> Xuelei >>> >>> On 11/5/2018 11:51 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> This fixes an issue where TLS 1.3 resumed sessions were not carrying >>>> forward many of the parameters from the parent session, namely the >>>> peer certificates, but also the local certificates and a few other >>>> SSLSessionImpl fields.? This also moves the fix from an earlier, >>>> related issue with SNI names (JDK-8211806) into this new solution. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212885 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.01 >>>> >>>> Thanks, >>>> >>>> --Jamil >>>> >> From jamil.j.nimeh at oracle.com Tue Nov 6 19:38:40 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 6 Nov 2018 11:38:40 -0800 Subject: RFR, JDK-8212885: TLS 1.3 resumed session does not retain peer certificate chain In-Reply-To: <427b9e24-fbc5-65e0-d3f3-385c0a1b6236@oracle.com> References: <5f37d700-8859-da3c-c524-23bae8b24b5c@oracle.com> <0b9dec8a-f4b3-4fbc-dfc8-3fcf492f91f5@oracle.com> <5f56a6e2-87b5-451f-6c8e-807f3cee4da7@oracle.com> <427b9e24-fbc5-65e0-d3f3-385c0a1b6236@oracle.com> Message-ID: <2214d548-1437-2156-7448-ce84527b176d@oracle.com> Hi Xuelei, I've made the change.? I think in this specific case CipherSuite.hashAlg.toString is just a simple return of the name field so it should be no less reliable than hitting the name field directly.? Changing it does make it more consistent with other places in the method, so that's good. http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.03 --Jamil On 11/6/2018 11:29 AM, Xuelei Fan wrote: > Looks fine to me. > > As you are already there, would you mind have an additional > improvement in PreSharedKeyExtension.java? > > -?? MessageDigest md = MessageDigest.getInstance(hashAlg.toString());; > +?? MessageDigest md = MessageDigest.getInstance(hashAlg.toString()); > > Normally, the toString() is not a reliable method to get the precise > algorithm name.? Would you mind update to use hashAlg.name instead? > > -?? MessageDigest md = MessageDigest.getInstance(hashAlg.toString());; > +?? MessageDigest md = MessageDigest.getInstance(hashAlg.name); > > > Thanks, > Xuelei > > > On 11/6/2018 11:05 AM, Jamil Nimeh wrote: >> Hi Xuelei, updated review here: >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.02 >> >> I followed your suggestions and also cleaned up some remnant comments >> and removed a double-semicolon...just cosmetic stuff. >> >> --Jamil >> >> On 11/6/18 10:11 AM, Jamil Nimeh wrote: >>> Okay, I can move this into PreSharedKeyExtension.java and re-run the >>> local tests that were having issues with it.? Should work pretty well. >>> >>> I'll put out another code review shortly. >>> >>> Thanks, >>> --Jamil >>> >>> On 11/6/2018 7:36 AM, Xuelei Fan wrote: >>>> Nice update! >>>> >>>> For the update in ClientHello.java, I may suggest moving it to >>>> pre_shared_key extension class.? It may be a little bit safer if >>>> the extension can be loaded in other places. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 11/5/2018 11:51 PM, Jamil Nimeh wrote: >>>>> Hello all, >>>>> >>>>> This fixes an issue where TLS 1.3 resumed sessions were not >>>>> carrying forward many of the parameters from the parent session, >>>>> namely the peer certificates, but also the local certificates and >>>>> a few other SSLSessionImpl fields. This also moves the fix from an >>>>> earlier, related issue with SNI names (JDK-8211806) into this new >>>>> solution. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212885 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.01 >>>>> >>>>> Thanks, >>>>> >>>>> --Jamil >>>>> >>> From xuelei.fan at oracle.com Tue Nov 6 20:01:41 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 6 Nov 2018 12:01:41 -0800 Subject: RFR, JDK-8212885: TLS 1.3 resumed session does not retain peer certificate chain In-Reply-To: <2214d548-1437-2156-7448-ce84527b176d@oracle.com> References: <5f37d700-8859-da3c-c524-23bae8b24b5c@oracle.com> <0b9dec8a-f4b3-4fbc-dfc8-3fcf492f91f5@oracle.com> <5f56a6e2-87b5-451f-6c8e-807f3cee4da7@oracle.com> <427b9e24-fbc5-65e0-d3f3-385c0a1b6236@oracle.com> <2214d548-1437-2156-7448-ce84527b176d@oracle.com> Message-ID: Thanks for the update! No more comments from me. Xuelei On 11/6/2018 11:38 AM, Jamil Nimeh wrote: > Hi Xuelei, > > I've made the change.? I think in this specific case > CipherSuite.hashAlg.toString is just a simple return of the name field > so it should be no less reliable than hitting the name field directly. > Changing it does make it more consistent with other places in the > method, so that's good. > > http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.03 > > --Jamil > > On 11/6/2018 11:29 AM, Xuelei Fan wrote: >> Looks fine to me. >> >> As you are already there, would you mind have an additional >> improvement in PreSharedKeyExtension.java? >> >> -?? MessageDigest md = MessageDigest.getInstance(hashAlg.toString());; >> +?? MessageDigest md = MessageDigest.getInstance(hashAlg.toString()); >> >> Normally, the toString() is not a reliable method to get the precise >> algorithm name.? Would you mind update to use hashAlg.name instead? >> >> -?? MessageDigest md = MessageDigest.getInstance(hashAlg.toString());; >> +?? MessageDigest md = MessageDigest.getInstance(hashAlg.name); >> >> >> Thanks, >> Xuelei >> >> >> On 11/6/2018 11:05 AM, Jamil Nimeh wrote: >>> Hi Xuelei, updated review here: >>> >>> http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.02 >>> >>> I followed your suggestions and also cleaned up some remnant comments >>> and removed a double-semicolon...just cosmetic stuff. >>> >>> --Jamil >>> >>> On 11/6/18 10:11 AM, Jamil Nimeh wrote: >>>> Okay, I can move this into PreSharedKeyExtension.java and re-run the >>>> local tests that were having issues with it.? Should work pretty well. >>>> >>>> I'll put out another code review shortly. >>>> >>>> Thanks, >>>> --Jamil >>>> >>>> On 11/6/2018 7:36 AM, Xuelei Fan wrote: >>>>> Nice update! >>>>> >>>>> For the update in ClientHello.java, I may suggest moving it to >>>>> pre_shared_key extension class.? It may be a little bit safer if >>>>> the extension can be loaded in other places. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 11/5/2018 11:51 PM, Jamil Nimeh wrote: >>>>>> Hello all, >>>>>> >>>>>> This fixes an issue where TLS 1.3 resumed sessions were not >>>>>> carrying forward many of the parameters from the parent session, >>>>>> namely the peer certificates, but also the local certificates and >>>>>> a few other SSLSessionImpl fields. This also moves the fix from an >>>>>> earlier, related issue with SNI names (JDK-8211806) into this new >>>>>> solution. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212885 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.01 >>>>>> >>>>>> Thanks, >>>>>> >>>>>> --Jamil >>>>>> >>>> > From weijun.wang at oracle.com Wed Nov 7 00:59:03 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Nov 2018 08:59:03 +0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> Message-ID: > On Nov 7, 2018, at 12:47 AM, Xuelei Fan wrote: > > Some typos: > > "When multiple curves have the same field size, and one of them is a prime curve or a Koblitz curve, it will be used." > > Which one will be used? prime curve or Koblitz curve. I am not an ECC expert, but what I observed from FIPS 186-4 is that no prime curve and Koblitz curve use the same field size. The current impl chooses prime curve first, simply because they add added earlier. > It will not be documented, right? No. > Otherwise, there are may be more curve categories. As it is not the recommended option, I may just remove this and the following one sentence. I'll just leave it there as a FYI since it's not part of the spec. Thanks Max > > Xuelei > > > > On 11/6/2018 8:31 AM, Weijun Wang wrote: >> Thanks everyone. CSR updated, and I describe the behavior in the Solution part. If you are all happy I'll start coding. >> And yes, KeyPairGenerator::init(int) needs some clarification, but I don't know in which class/method we should add it. Maybe the JDK Provider Doc? >> --Max >>> On Nov 7, 2018, at 12:00 AM, Xuelei Fan wrote: >>> >>> As -curvename is a new option, I would second the comments that don't allow mixing curve names and keysize at the same time. >>> >>> Xuelei >>> >>> On 11/5/2018 11:41 PM, Bernd Eckenfels wrote: >>>> Hello, >>>> I would agree ignoring an (conflicting) option adds confusion. When specifying a curve is a new feature we don?t need to worry about beeing compatible, therefore I would forbid mixing curve names and keysize at all (even when the size matches). >>>> I guess we cannot remove the option to only pass the keysize (to have the generator pick a curve) to stay compatible. But the chosen curve should be printed, and I would also deprecate this usage. >>>> I guess clarifying the keysize-only init() method would be a different topic, but something like deprecating it and restricting the selection to ?SunEC only selects NIST prime curves? would be a good thing. >>>> Gruss >>>> Bernd >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> ------------------------------------------------------------------------ >>>> *Von:* security-dev im Auftrag von Xuelei Fan >>>> *Gesendet:* Dienstag, November 6, 2018 7:38 AM >>>> *An:* Weijun Wang >>>> *Cc:* security-dev at openjdk.java.net >>>> *Betreff:* Re: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation >>>> On 11/5/2018 8:37 PM, Weijun Wang wrote: >>>>> >>>>>> On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote: >>>>>> >>>>>> On 11/5/2018 7:13 PM, Weijun Wang wrote: >>>>>>> Please take a review at the CSR at >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213401 >>>>>>> As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. >>>>>> Why not use a strict mode: fail if not match. It might be misleading if ignoring unmatched options. >>>>> >>>>> We can do that, but misleading to what? That we treat -curvename and -keysize the same important? >>>>> >>>> If the option "-keysize 256 -curvename sect163k1" work, I may think that >>>> the key size if 256 bits. I want to create a 256 bits sect163k1 EC key, >>>> and the tool allows this behavior, so I should get a 256 bits sect163k1 >>>> EC key. Sure, that's incorrect, but I don't know it is incorrect as the >>>> tool ignore the key size. What's the problem of the command, I don't >>>> know either unless I clearly understand sect163k1 is not 256 bits. The >>>> next question to me, what's the key size actually is? 256 bits or 163 >>>> bits? which option are used? It adds more confusing to me. >>>> We can ignore the -keysize option, but it is complicated to me to use >>>> the tool. >>>>>> >>>>>>> Another question: in sun.security.util.CurveDB, we have >>>>>>> // Return EC parameters for the specified field size. If there are known >>>>>>> // NIST recommended parameters for the given length, they are returned. >>>>>>> // Otherwise, if there are multiple matches for the given size, an >>>>>>> // arbitrary one is returns. >>>>>>> // If no parameters are known, the method returns null. >>>>>>> // NOTE that this method returns both prime and binary curves. >>>>>>> static NamedCurve lookup(int length) { >>>>>>> return lengthMap.get(length); >>>>>>> } >>>>>>> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? >>>>>>> In fact, CurveDB.java seems to have a bug when adding the curves: >>>>>>> add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... >>>>>>> add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? >>>>>>> add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... >>>>>>> add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... >>>>>>> and now 163 is sect163r2 and 233 is sect233k1. >>>>>>> I assume we should always prefer the K- one? >>>>>> TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. >>>>> >>>>> There is no ambiguity for prime curves. >>>>> >>>>>> >>>>>> Do you mean if no -curvename option, there is a need to choose a named curve? >>>>> >>>>> ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I just meant if we have a bug here and if we should be more public on what curve is chosen. >>>>> >>>> I see your concerns. >>>> It might be a potential issue if we use a named curve if no curvename >>>> specified. If the compatibility is not serious, I may suggest supported >>>> named curves only, or use arbitrary curves but with a warning. >>>> Xuelei From gnu.andrew at redhat.com Wed Nov 7 01:25:04 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 7 Nov 2018 01:25:04 +0000 Subject: [RFR] JDK-8213154: Update copyright headers of files in src tree that are missing Classpath exception In-Reply-To: References: Message-ID: On Thu, 1 Nov 2018 at 15:41, Martin Balao wrote: > > Hi Andrew, > > Thanks for having a look at this. > > Webrev.02 without "All rights reserved" and "affiliates" parts: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.02/ > * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.02.zip > > Are you okay to go? > > Kind regards, > Martin.- > Looks good. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From weijun.wang at oracle.com Wed Nov 7 01:27:16 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Nov 2018 09:27:16 +0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> Message-ID: <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> After some discussion, we decided to cover -keysize and -sigalg in this deprecation process too. Please review the updated CSR at https://bugs.openjdk.java.net/browse/JDK-8212111 No webrev available yet. Thanks Max > On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: > > Please review the code change and CSR for > > JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 > > at > > webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 > > When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. > > A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. > > A Mach5 job on tier1 and tier2 running now. > > Thanks > Max > From mstjohns at comcast.net Wed Nov 7 08:05:35 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 7 Nov 2018 03:05:35 -0500 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <6FBECFDA-A7C1-4DA1-BD3B-2CBCEFADF33F@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <6FBECFDA-A7C1-4DA1-BD3B-2CBCEFADF33F@oracle.com> Message-ID: <41412106-b7cd-eab5-793e-ef716f16905c@comcast.net> Inline below. On 11/6/2018 2:18 AM, Weijun Wang wrote: > >> On Nov 6, 2018, at 1:06 PM, Xuelei Fan wrote: >> >> On 11/5/2018 8:37 PM, Weijun Wang wrote: >>>> On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote: >>>> >>>> On 11/5/2018 7:13 PM, Weijun Wang wrote: >>>>> Please take a review at the CSR at >>>>> https://bugs.openjdk.java.net/browse/JDK-8213401 >>>>> As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. >>>> Why not use a strict mode: fail if not match. It might be misleading if ignoring unmatched options. >>> We can do that, but misleading to what? That we treat -curvename and -keysize the same important? >> If the option "-keysize 256 -curvename sect163k1" work, I may think that the key size if 256 bits. I want to create a 256 bits sect163k1 EC key, and the tool allows this behavior, so I should get a 256 bits sect163k1 EC key. Sure, that's incorrect, but I don't know it is incorrect as the tool ignore the key size. What's the problem of the command, I don't know either unless I clearly understand sect163k1 is not 256 bits. The next question to me, what's the key size actually is? 256 bits or 163 bits? which option are used? It adds more confusing to me. > Well explained. I've updated the CSR and this will be an error. Sorry to drop in late. Basically, for EC private keys - either binary or prime curves, you will reduce whatever initial random value you generate mod n of the curve to get the final private key.? The generation logic should take care of this.??? You could use key size as a way of controlling how many extra bits are generated(see FIPS 186-4, section B.4.1) and error only if key size was less than the size of the curve's n. So 1) generate a random value of keysize length or if not specified the length of the N of the curve plus 64, 2) reduce mod N. Mime. > >> We can ignore the -keysize option, but it is complicated to me to use the tool. >> >>>>> Another question: in sun.security.util.CurveDB, we have >>>>> // Return EC parameters for the specified field size. If there are known >>>>> // NIST recommended parameters for the given length, they are returned. >>>>> // Otherwise, if there are multiple matches for the given size, an >>>>> // arbitrary one is returns. >>>>> // If no parameters are known, the method returns null. >>>>> // NOTE that this method returns both prime and binary curves. >>>>> static NamedCurve lookup(int length) { >>>>> return lengthMap.get(length); >>>>> } >>>>> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? >>>>> In fact, CurveDB.java seems to have a bug when adding the curves: >>>>> add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... >>>>> add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? >>>>> add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... >>>>> add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... >>>>> and now 163 is sect163r2 and 233 is sect233k1. >>>>> I assume we should always prefer the K- one? >>>> TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. >>> There is no ambiguity for prime curves. >>>> Do you mean if no -curvename option, there is a need to choose a named curve? >>> ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I just meant if we have a bug here and if we should be more public on what curve is chosen. >> I see your concerns. >> >> It might be a potential issue if we use a named curve if no curvename specified. If the compatibility is not serious, I may suggest supported named curves only, or use arbitrary curves but with a warning. > If people only want prime curves then -keysize still works. A warning is enough since in the CSR I've also said "we recommend". > > Thanks > Max > >> Xuelei From matthias.baesken at sap.com Wed Nov 7 08:52:28 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 7 Nov 2018 08:52:28 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> Message-ID: > Sorry, I haven't had time to look at this in more detail yet. But, let's > take a step back first. Can you or Matthias explain in more detail why > this fix is necessary? What are the use cases and motivation? Hello, adding paths (or maybe more details) to exception messages just makes analyzing errors easier. You do not get just "Bad path", but also the real bad path which gives you a hint where to look and analyze further . That's why we introduced it in our JVM ages ago. I have to agree that additionally printing cwd / user.dir is a bit special, so I omit that from this revision of the patch. This makes the patch more simple. New revision : http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.1/ Unfortunately the usage of sun.security.util.SecurityProperties (which was considered) in the static { ... } class initializers (e.g. UnixFileSystem.java) just does not work. It fails with already in the build (!) with : Error occurred during initialization of boot layer java.lang.ExceptionInInitializerError Caused by: java.lang.NullPointerException (seems it is too early in the game for SecurityProperties). (btw. this is another NOT very helpful exception error message) So I unfortunately had to go back to using system properties. Btw. another question regarding path output in exceptions : you seem to consider it a bad thing to (unconditionally) print paths in the exception messages, but then on the other hand we have it already in OpenJDK UnixFileSystem_md.c : 269 JNIEXPORT jboolean JNICALL 270 Java_java_io_UnixFileSystem_createFileExclusively(JNIEnv *env, jclass cls, 271 jstring pathname) 272 { ....... 277 /* The root directory always exists */ 278 if (strcmp (path, "/")) { 279 fd = handleOpen(path, O_RDWR | O_CREAT | O_EXCL, 0666); 280 if (fd < 0) { 281 if (errno != EEXIST) 282 JNU_ThrowIOExceptionWithLastError(env, path); 283 } else { 284 if (close(fd) == -1) 285 JNU_ThrowIOExceptionWithLastError(env, path); Why is it fine here for a long time , but considered harmful at the other places ? If we want to be consistent, we should then write "Bad path" here (or allow the path output at the other places too ). Thanks, Matthias > -----Original Message----- > From: Sean Mullan > Sent: Freitag, 12. Oktober 2018 17:19 > To: Langer, Christoph ; Baesken, Matthias > ; Alan Bateman ; > security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - > enhance some IOExceptions with path causing the issue > > On 10/12/18 10:33 AM, Langer, Christoph wrote: > > Sean, what is your take on this? > > Sorry, I haven't had time to look at this in more detail yet. But, let's > take a step back first. Can you or Matthias explain in more detail why > this fix is necessary? What are the use cases and motivation? The bug > report doesn't go into any detail about that and there isn't anything > in the initial RFR email that explains why this change is useful or > necessary. As a general guideline or advice, RFEs should include this > type of information so that Reviewers understand more of the context and > motivation behind the change. > > Thanks, > Sean From lars.francke at gmail.com Wed Nov 7 11:40:14 2018 From: lars.francke at gmail.com (Lars Francke) Date: Wed, 7 Nov 2018 12:40:14 +0100 Subject: Additional debug log message in KeyTab Message-ID: Hi, I have to preface this by saying that this would be my first contribution to OpenJDK and I'm still learning the ways. Not sure for example if this is the correct mailing list or if a more generic JDK one would be appropriate. While working on Hadoop based systems I frequently need to debug Kerberos related issues. And while there are sun.security.krb5.debug and sun.security.spnego.debug the error messages could be more helpful at times. One of these instance is sun.security.krb5.internal.ktab.Keytab#readServiceKeys. It logs that it's looking for keys but (at least for me) it would be very helpful if it also logged how many keys it found after the for-loop. If it finds keys it also logs them but if it can't find any then there's no message so it's easy to miss. What do you think? Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Nov 7 12:44:37 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 7 Nov 2018 12:44:37 +0000 Subject: Additional debug log message in KeyTab In-Reply-To: References: Message-ID: <46100718-891e-9840-a044-c89321896a39@oracle.com> Looks like a reasonable minor enhancement to me. To contribute, you'll need to sign the OCA first. More information at : https://openjdk.java.net/contribute/ Regards, Sean. On 07/11/18 11:40, Lars Francke wrote: > Hi, > > I have to preface this by saying that this would be my first > contribution to OpenJDK and I'm still learning the ways. Not sure for > example if this is the correct mailing list or if a more generic JDK > one would be appropriate. > > While working on Hadoop based systems I frequently need to debug > Kerberos related issues. And while there are sun.security.krb5.debug > and sun.security.spnego.debug the error messages could be more helpful > at times. > > One of these instance > is sun.security.krb5.internal.ktab.Keytab#readServiceKeys. > > It logs that it's looking for keys but (at least for me) it would be > very helpful if it also logged how many keys it found after the for-loop. > > If it finds keys it also logs them but if it can't find any then > there's no message so it's easy to miss. > > What do you think? > > Cheers, > Lars From lars.francke at gmail.com Wed Nov 7 13:12:15 2018 From: lars.francke at gmail.com (Lars Francke) Date: Wed, 7 Nov 2018 14:12:15 +0100 Subject: Additional debug log message in KeyTab In-Reply-To: <46100718-891e-9840-a044-c89321896a39@oracle.com> References: <46100718-891e-9840-a044-c89321896a39@oracle.com> Message-ID: Se?n, thank you! I've already sent the OCA and am in the process of getting it filed. According to the docs[0] the next step would be to provide a patch to this mailing list. I have to admit that I'm a bit overwhelmed still (having never built OpenJDK myself) so it'll take a while. Would this patch also require a test? Assuming it's just of the form if (debug) { System.out.println(...);; } Cheers, Lars On Wed, Nov 7, 2018 at 1:44 PM Se?n Coffey wrote: > Looks like a reasonable minor enhancement to me. > > To contribute, you'll need to sign the OCA first. More information at : > > https://openjdk.java.net/contribute/ > > Regards, > Sean. > > On 07/11/18 11:40, Lars Francke wrote: > > Hi, > > > > I have to preface this by saying that this would be my first > > contribution to OpenJDK and I'm still learning the ways. Not sure for > > example if this is the correct mailing list or if a more generic JDK > > one would be appropriate. > > > > While working on Hadoop based systems I frequently need to debug > > Kerberos related issues. And while there are sun.security.krb5.debug > > and sun.security.spnego.debug the error messages could be more helpful > > at times. > > > > One of these instance > > is sun.security.krb5.internal.ktab.Keytab#readServiceKeys. > > > > It logs that it's looking for keys but (at least for me) it would be > > very helpful if it also logged how many keys it found after the for-loop. > > > > If it finds keys it also logs them but if it can't find any then > > there's no message so it's easy to miss. > > > > What do you think? > > > > Cheers, > > Lars > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Wed Nov 7 14:36:12 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 7 Nov 2018 09:36:12 -0500 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> Message-ID: One issue that just came to me: How will this work for EdDSA? I think the CSR could be generalized a bit: 1) Make the first item in the "Solution" more general. Instead of limiting it to "EC" allow any valid algorithm/curve combination. 2) (Optional) Use -groupname instead of -curvename and change "curve" to "group" everywhere in the CSR. Then this mechanism can also be used for DSA (with named groups) and other algorithms that use groups that aren't curves. Also, see below for a comment about curve ambiguity. On 11/6/2018 7:59 PM, Weijun Wang wrote: >> Otherwise, there are may be more curve categories. As it is not the recommended option, I may just remove this and the following one sentence. > I'll just leave it there as a FYI since it's not part of the spec. I agree with Xuelei that this part should be removed. Unless you are planning on implementing this curve selection logic in keytool, then we can't control which curve is selected, and it wholly depends on the behavior of the providers. We can't even guarantee that there is any relationship between "key size" and the field size of the curve. Also, we shouldn't use the word "random" here unless we plan to actually randomize the selection of the curve at runtime (similar to random iteration order for maps/sets). I suggest something more general and vague like: If only |-keysize| is specified, an arbitrary curve of the specified size is used -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Nov 7 15:04:58 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 7 Nov 2018 15:04:58 +0000 Subject: Additional debug log message in KeyTab In-Reply-To: References: <46100718-891e-9840-a044-c89321896a39@oracle.com> Message-ID: On 07/11/18 13:12, Lars Francke wrote: > Se?n, > > thank you! > > I've already sent the OCA and am in the process of getting it filed. > According to the docs[0] the next step would be to provide a patch to > this mailing list. > > I have to admit that I'm a bit overwhelmed still (having never built > OpenJDK myself) so it'll take a while. > > Would this patch also require a test? you might get away without a test and add the noreg-trivial to the eventual bug report. However, it might be no harm to examine the current test code to see if the debug flag is exercised. If it is, it might be the case of a simple edit to an existing test. regards, Sean. > > Assuming it's just of the form > if (debug) { > System.out.println(...);; > } > > Cheers, > Lars > > > > On Wed, Nov 7, 2018 at 1:44 PM Se?n Coffey > wrote: > > Looks like a reasonable minor enhancement to me. > > To contribute, you'll need to sign the OCA first. More information > at : > > https://openjdk.java.net/contribute/ > > Regards, > Sean. > > On 07/11/18 11:40, Lars Francke wrote: > > Hi, > > > > I have to preface this by saying that this would be my first > > contribution to OpenJDK and I'm still learning the ways. Not > sure for > > example if this is the correct mailing list or if a more generic > JDK > > one would be appropriate. > > > > While working on Hadoop based systems I frequently need to debug > > Kerberos related issues. And while there are > sun.security.krb5.debug > > and sun.security.spnego.debug the error messages could be more > helpful > > at times. > > > > One of these instance > > is sun.security.krb5.internal.ktab.Keytab#readServiceKeys. > > > > It logs that it's looking for keys but (at least for me) it > would be > > very helpful if it also logged how many keys it found after the > for-loop. > > > > If it finds keys it also logs them but if it can't find any then > > there's no message so it's easy to miss. > > > > What do you think? > > > > Cheers, > > Lars > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Nov 7 15:08:04 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Nov 2018 23:08:04 +0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <41412106-b7cd-eab5-793e-ef716f16905c@comcast.net> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <6FBECFDA-A7C1-4DA1-BD3B-2CBCEFADF33F@oracle.com> <41412106-b7cd-eab5-793e-ef716f16905c@comcast.net> Message-ID: I don't think there is any current AlgorithmParameterSpec that allow this for a KeyPairGenerator. When a curve name is used, keysize is calculated from the field size. --Max > On Nov 7, 2018, at 4:05 PM, Michael StJohns wrote: > > Inline below. > > On 11/6/2018 2:18 AM, Weijun Wang wrote: >> >>> On Nov 6, 2018, at 1:06 PM, Xuelei Fan wrote: >>> >>> On 11/5/2018 8:37 PM, Weijun Wang wrote: >>>>> On Nov 6, 2018, at 12:12 PM, Xuelei Fan wrote: >>>>> >>>>> On 11/5/2018 7:13 PM, Weijun Wang wrote: >>>>>> Please take a review at the CSR at >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213401 >>>>>> As for implementation, I intend to report an error when -keyalg is not EC but -curvename is provided. If both -curvename and -keysize are provided, I intend to ignore -keysize no matter if they match or not. >>>>> Why not use a strict mode: fail if not match. It might be misleading if ignoring unmatched options. >>>> We can do that, but misleading to what? That we treat -curvename and -keysize the same important? >>> If the option "-keysize 256 -curvename sect163k1" work, I may think that the key size if 256 bits. I want to create a 256 bits sect163k1 EC key, and the tool allows this behavior, so I should get a 256 bits sect163k1 EC key. Sure, that's incorrect, but I don't know it is incorrect as the tool ignore the key size. What's the problem of the command, I don't know either unless I clearly understand sect163k1 is not 256 bits. The next question to me, what's the key size actually is? 256 bits or 163 bits? which option are used? It adds more confusing to me. >> Well explained. I've updated the CSR and this will be an error. > > Sorry to drop in late. > > Basically, for EC private keys - either binary or prime curves, you will reduce whatever initial random value you generate mod n of the curve to get the final private key. The generation logic should take care of this. You could use key size as a way of controlling how many extra bits are generated(see FIPS 186-4, section B.4.1) and error only if key size was less than the size of the curve's n. > > So 1) generate a random value of keysize length or if not specified the length of the N of the curve plus 64, 2) reduce mod N. > > Mime. > >> >>> We can ignore the -keysize option, but it is complicated to me to use the tool. >>> >>>>>> Another question: in sun.security.util.CurveDB, we have >>>>>> // Return EC parameters for the specified field size. If there are known >>>>>> // NIST recommended parameters for the given length, they are returned. >>>>>> // Otherwise, if there are multiple matches for the given size, an >>>>>> // arbitrary one is returns. >>>>>> // If no parameters are known, the method returns null. >>>>>> // NOTE that this method returns both prime and binary curves. >>>>>> static NamedCurve lookup(int length) { >>>>>> return lengthMap.get(length); >>>>>> } >>>>>> FIPS 186-4 has 2 recommendations (K- and B-) for a binary curve field size. Do we have a choice? >>>>>> In fact, CurveDB.java seems to have a bug when adding the curves: >>>>>> add("sect163k1 [NIST K-163]", "1.3.132.0.1", BD,... >>>>>> add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,... // Another default? >>>>>> add("sect233k1 [NIST K-233]", "1.3.132.0.26", BD,... >>>>>> add("sect233r1 [NIST B-233]", "1.3.132.0.27", B,... >>>>>> and now 163 is sect163r2 and 233 is sect233k1. >>>>>> I assume we should always prefer the K- one? >>>>> TLS 1.3 uses secp256r1/secp384r1/secp521r1, no K- curves. >>>> There is no ambiguity for prime curves. >>>>> Do you mean if no -curvename option, there is a need to choose a named curve? >>>> ECKeyPairGenerator::initialize(int) will choose one and keytool will use it. I just meant if we have a bug here and if we should be more public on what curve is chosen. >>> I see your concerns. >>> >>> It might be a potential issue if we use a named curve if no curvename specified. If the compatibility is not serious, I may suggest supported named curves only, or use arbitrary curves but with a warning. >> If people only want prime curves then -keysize still works. A warning is enough since in the CSR I've also said "we recommend". >> >> Thanks >> Max >> >>> Xuelei From weijun.wang at oracle.com Wed Nov 7 15:48:11 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Nov 2018 23:48:11 +0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> Message-ID: <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> CSR updated. With such a generalized option, I won't recommend -groupname over -keysize now, although I still intend to print some warning for EC. Please take a review. Thanks Max > On Nov 7, 2018, at 10:36 PM, Adam Petcher wrote: > > One issue that just came to me: How will this work for EdDSA? I think the CSR could be generalized a bit: > > 1) Make the first item in the "Solution" more general. Instead of limiting it to "EC" allow any valid algorithm/curve combination. > 2) (Optional) Use -groupname instead of -curvename and change "curve" to "group" everywhere in the CSR. Then this mechanism can also be used for DSA (with named groups) and other algorithms that use groups that aren't curves. > Also, see below for a comment about curve ambiguity. > On 11/6/2018 7:59 PM, Weijun Wang wrote: >>> Otherwise, there are may be more curve categories. As it is not the recommended option, I may just remove this and the following one sentence. >>> >> I'll just leave it there as a FYI since it's not part of the spec. > > I agree with Xuelei that this part should be removed. Unless you are planning on implementing this curve selection logic in keytool, then we can't control which curve is selected, and it wholly depends on the behavior of the providers. We can't even guarantee that there is any relationship between "key size" and the field size of the curve. Also, we shouldn't use the word "random" here unless we plan to actually randomize the selection of the curve at runtime (similar to random iteration order for maps/sets). I suggest something more general and vague like: > > If only -keysize is specified, an arbitrary curve of the specified size is used > From weijun.wang at oracle.com Wed Nov 7 15:51:22 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 7 Nov 2018 23:51:22 +0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> Message-ID: Oops, I take this back. The CSR needs more update. Sorry if you have already start reading it. Thanks Max > On Nov 7, 2018, at 9:27 AM, Weijun Wang wrote: > > After some discussion, we decided to cover -keysize and -sigalg in this deprecation process too. > > Please review the updated CSR at > > https://bugs.openjdk.java.net/browse/JDK-8212111 > > No webrev available yet. > > Thanks > Max > > >> On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: >> >> Please review the code change and CSR for >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 >> >> at >> >> webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 >> >> When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. >> >> A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. >> >> A Mach5 job on tier1 and tier2 running now. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Wed Nov 7 16:14:41 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 8 Nov 2018 00:14:41 +0800 Subject: NamedCurve.getName() Message-ID: <61D7F3F3-BE52-4B9A-AA2B-B7A25F0C4260@oracle.com> This method returns "secp256r1 [NIST P-256, X9.62 prime256v1]" because that's how we added it in CurveDB: add("secp256r1 [NIST P-256, X9.62 prime256v1]", "1.2.840.10045.3.1.7", PD, "FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF", "FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFC", "5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B", "6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296", "4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5", "FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551", 1, nameSplitPattern); Maybe it should be getNames()? Thanks Max From xuelei.fan at oracle.com Wed Nov 7 17:47:52 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 7 Nov 2018 09:47:52 -0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> Message-ID: Maybe, the -groupname/-curvename option can be replaced by extending the existing -keyalg option: -keyalg secp256r1 Then there is no conflict between the curve/group name and the key alg. Xuelei On 11/7/2018 7:48 AM, Weijun Wang wrote: > CSR updated. With such a generalized option, I won't recommend -groupname over -keysize now, although I still intend to print some warning for EC. > > Please take a review. > > Thanks > Max > > >> On Nov 7, 2018, at 10:36 PM, Adam Petcher wrote: >> >> One issue that just came to me: How will this work for EdDSA? I think the CSR could be generalized a bit: >> >> 1) Make the first item in the "Solution" more general. Instead of limiting it to "EC" allow any valid algorithm/curve combination. >> 2) (Optional) Use -groupname instead of -curvename and change "curve" to "group" everywhere in the CSR. Then this mechanism can also be used for DSA (with named groups) and other algorithms that use groups that aren't curves. >> Also, see below for a comment about curve ambiguity. >> On 11/6/2018 7:59 PM, Weijun Wang wrote: >>>> Otherwise, there are may be more curve categories. As it is not the recommended option, I may just remove this and the following one sentence. >>>> >>> I'll just leave it there as a FYI since it's not part of the spec. >> >> I agree with Xuelei that this part should be removed. Unless you are planning on implementing this curve selection logic in keytool, then we can't control which curve is selected, and it wholly depends on the behavior of the providers. We can't even guarantee that there is any relationship between "key size" and the field size of the curve. Also, we shouldn't use the word "random" here unless we plan to actually randomize the selection of the curve at runtime (similar to random iteration order for maps/sets). I suggest something more general and vague like: >> >> If only -keysize is specified, an arbitrary curve of the specified size is used >> > From sean.mullan at oracle.com Wed Nov 7 21:30:12 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 7 Nov 2018 16:30:12 -0500 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> Message-ID: On 11/5/18 1:52 PM, Xuelei Fan wrote: > Hi Chris and Sean, > > There are a few feedback for the CSR approval.? I updated to use > Optional for the returned value.? For more details, please > refer to: > ? https://bugs.openjdk.java.net/browse/JDK-8213161 > ? http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/ I didn't see a test for SecureCacheResponse - is it possible? You could also add a test case for IllegalStateExc. lines 108-113 of HttpsSession.java should be indented 4 more spaces. Otherwise looks ok to me. --Sean > > > Please let me know if you are OK with this change. > > Thanks, > Xuelei > > On 11/2/2018 11:42 AM, Xuelei Fan wrote: >> Thanks for the review and suggestions, Chris and Sean. >> >> I just finalized the CSR. >> >> Thanks, >> Xuelei >> >> On 11/2/2018 5:58 AM, Chris Hegarty wrote: >>> Thanks for the updates Xuelei, some minor comments inline.. >>> >>>> On 1 Nov 2018, at 23:42, Xuelei Fan >>> > wrote: >>>> >>>> On 11/1/2018 11:24 AM, Sean Mullan wrote: >>>>> On 10/31/18 11:52 AM, Chris Hegarty wrote: >>>>>> Xuelei, >>>>>> >>>>>> On 30/10/18 20:55, Xuelei Fan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> For the current HttpsURLConnection, there is not much security >>>>>>> parameters exposed in the public APIs.? An application may need >>>>>>> richer information for the underlying TLS connections, for >>>>>>> example the negotiated TLS protocol version. >>>>>>> >>>>>>> Please let me know if you have concerns to add a new method >>>>>>> HttpsURLConnection.getSSLSession() and deprecate the duplicated >>>>>>> methods, by the end of Nov. 2, 2018. >>>>>>> >>>>>>> Here is the proposal: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213161 >>>>> Are there any security issues associated with returning the >>>>> SSLSession, since it is mutable? >>>> It should be fine. ?The update APIs of the session (invalidating, >>>> bind values) does not impact the connection. >>> >>> Alternatively, as is done in the new HTTP Client, an immutable >>> SSLSession instance can be returned. >>> >>>>> +???? *?????????? SHOULD override this method with appropriate >>>>> implementation. >>>>> s/appropriate/an appropriate/ >>>>> I would probably not capitalize "SHOULD" and just say "should". >>>>> "SHOULD" is more common in RFCs. I don't see that much in javadocs. >>>>> +???? * @implNote The JDK Reference Implementation supports this >>>>> operation. >>>>> +???? *?????????? As an application may have to use this operation >>>>> for more >>>>> +???? *?????????? security parameters, it is recommended to support >>>>> this >>>>> +???? *?????????? operation in all implementations. >>>>> I think it should be obvious that the JDK implementation would >>>>> override this method so not sure that first sentence is necessary. >>>>> The other sentence seems like it could be combined with the >>>>> previous sentence, ex: >>>>> "Subclasses should override this method with an appropriate >>>>> implementation since an application may need to access additional >>>>> parameters associated with the SSL session." >>>> Updated accordingly, in the CSR and webrev: >>>> https://bugs.openjdk.java.net/browse/JDK-8213161 >>> >>> The CSR looks good. I made a few minor edits to the verbiage >>> and added myself as reviewer. >>> >>> The title will need to be updated to reflect the addition of the >>> new method in SecureCacheResponse. Maybe: >>> >>> "Add?SSLSession accessors to HttpsURLConnection and >>> SecureCacheResponse" >>> >>> -Chris. >>> >>> >>> From weijun.wang at oracle.com Wed Nov 7 23:38:13 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 8 Nov 2018 07:38:13 +0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> Message-ID: <1D08F1B4-5DCB-4FDD-A6FB-FA430AD927CC@oracle.com> This sounds a little misleading to me. Alg name and alg params are 2 different things. This is like asking user to call KeyPairGenerator.getInstance("secp256r1"). --Max > On Nov 8, 2018, at 1:47 AM, Xuelei Fan wrote: > > Maybe, the -groupname/-curvename option can be replaced by extending the existing -keyalg option: > -keyalg secp256r1 > > Then there is no conflict between the curve/group name and the key alg. > > Xuelei > > On 11/7/2018 7:48 AM, Weijun Wang wrote: >> CSR updated. With such a generalized option, I won't recommend -groupname over -keysize now, although I still intend to print some warning for EC. >> Please take a review. >> Thanks >> Max >>> On Nov 7, 2018, at 10:36 PM, Adam Petcher wrote: >>> >>> One issue that just came to me: How will this work for EdDSA? I think the CSR could be generalized a bit: >>> >>> 1) Make the first item in the "Solution" more general. Instead of limiting it to "EC" allow any valid algorithm/curve combination. >>> 2) (Optional) Use -groupname instead of -curvename and change "curve" to "group" everywhere in the CSR. Then this mechanism can also be used for DSA (with named groups) and other algorithms that use groups that aren't curves. >>> Also, see below for a comment about curve ambiguity. >>> On 11/6/2018 7:59 PM, Weijun Wang wrote: >>>>> Otherwise, there are may be more curve categories. As it is not the recommended option, I may just remove this and the following one sentence. >>>>> >>>> I'll just leave it there as a FYI since it's not part of the spec. >>> >>> I agree with Xuelei that this part should be removed. Unless you are planning on implementing this curve selection logic in keytool, then we can't control which curve is selected, and it wholly depends on the behavior of the providers. We can't even guarantee that there is any relationship between "key size" and the field size of the curve. Also, we shouldn't use the word "random" here unless we plan to actually randomize the selection of the curve at runtime (similar to random iteration order for maps/sets). I suggest something more general and vague like: >>> >>> If only -keysize is specified, an arbitrary curve of the specified size is used >>> From xuelei.fan at oracle.com Thu Nov 8 00:01:53 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 7 Nov 2018 16:01:53 -0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <1D08F1B4-5DCB-4FDD-A6FB-FA430AD927CC@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <1D08F1B4-5DCB-4FDD-A6FB-FA430AD927CC@oracle.com> Message-ID: <4a27f689-345c-e69f-7224-090e321baa89@oracle.com> On 11/7/2018 3:38 PM, Weijun Wang wrote: > This sounds a little misleading to me. Alg name and alg params are 2 different things. This is like asking user to call KeyPairGenerator.getInstance("secp256r1"). Well, KeyPairGenerator.getInstance("x25519") is a case that JDK 11 has supported now. Otherwise, there is a need to check the conflict of alg name and group name. Xuelei > > --Max > >> On Nov 8, 2018, at 1:47 AM, Xuelei Fan wrote: >> >> Maybe, the -groupname/-curvename option can be replaced by extending the existing -keyalg option: >> -keyalg secp256r1 >> >> Then there is no conflict between the curve/group name and the key alg. >> >> Xuelei >> >> On 11/7/2018 7:48 AM, Weijun Wang wrote: >>> CSR updated. With such a generalized option, I won't recommend -groupname over -keysize now, although I still intend to print some warning for EC. >>> Please take a review. >>> Thanks >>> Max >>>> On Nov 7, 2018, at 10:36 PM, Adam Petcher wrote: >>>> >>>> One issue that just came to me: How will this work for EdDSA? I think the CSR could be generalized a bit: >>>> >>>> 1) Make the first item in the "Solution" more general. Instead of limiting it to "EC" allow any valid algorithm/curve combination. >>>> 2) (Optional) Use -groupname instead of -curvename and change "curve" to "group" everywhere in the CSR. Then this mechanism can also be used for DSA (with named groups) and other algorithms that use groups that aren't curves. >>>> Also, see below for a comment about curve ambiguity. >>>> On 11/6/2018 7:59 PM, Weijun Wang wrote: >>>>>> Otherwise, there are may be more curve categories. As it is not the recommended option, I may just remove this and the following one sentence. >>>>>> >>>>> I'll just leave it there as a FYI since it's not part of the spec. >>>> >>>> I agree with Xuelei that this part should be removed. Unless you are planning on implementing this curve selection logic in keytool, then we can't control which curve is selected, and it wholly depends on the behavior of the providers. We can't even guarantee that there is any relationship between "key size" and the field size of the curve. Also, we shouldn't use the word "random" here unless we plan to actually randomize the selection of the curve at runtime (similar to random iteration order for maps/sets). I suggest something more general and vague like: >>>> >>>> If only -keysize is specified, an arbitrary curve of the specified size is used >>>> > From xuelei.fan at oracle.com Thu Nov 8 00:22:32 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 7 Nov 2018 16:22:32 -0800 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> Message-ID: <42631146-f45b-9dbf-328f-20b995d2f7ef@oracle.com> On 11/7/2018 1:30 PM, Sean Mullan wrote: >> ?? https://bugs.openjdk.java.net/browse/JDK-8213161 >> ?? http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/ > > I didn't see a test for SecureCacheResponse - is it possible? JDK does not have the reference implementation of SecureCacheResponse. > You could also add a test case for IllegalStateExc. > Added in the same test file. > lines 108-113 of HttpsSession.java should be indented 4 more spaces. > Otherwise looks ok to me. > Updated. New webrev: http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/ Thanks, Xuelei From weijun.wang at oracle.com Thu Nov 8 01:53:08 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 8 Nov 2018 09:53:08 +0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <4a27f689-345c-e69f-7224-090e321baa89@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <1D08F1B4-5DCB-4FDD-A6FB-FA430AD927CC@oracle.com> <4a27f689-345c-e69f-7224-090e321baa89@oracle.com> Message-ID: <4F40E173-B76D-404C-85A4-CD43A1F6A34F@oracle.com> Oh, I didn't know that. To make sure -keyalg matches KeyPairGenerator.getInstance(), I'd like to support it. If I read the impl correctly, you don't need to initialize it anymore and if you really want to initialize it the params must be the same. Currently keytool always calls initialize(). In this case, there will be no default -keysize, and initializa() will be not be called if user has not specified one. If user provides -groupname or -keysize just use it and keytool fails if API call fails. Thanks Max > On Nov 8, 2018, at 8:01 AM, Xuelei Fan wrote: > > On 11/7/2018 3:38 PM, Weijun Wang wrote: >> This sounds a little misleading to me. Alg name and alg params are 2 different things. This is like asking user to call KeyPairGenerator.getInstance("secp256r1"). > Well, KeyPairGenerator.getInstance("x25519") is a case that JDK 11 has supported now. > > Otherwise, there is a need to check the conflict of alg name and group name. > > Xuelei > >> --Max >>> On Nov 8, 2018, at 1:47 AM, Xuelei Fan wrote: >>> >>> Maybe, the -groupname/-curvename option can be replaced by extending the existing -keyalg option: >>> -keyalg secp256r1 >>> >>> Then there is no conflict between the curve/group name and the key alg. >>> >>> Xuelei >>> >>> On 11/7/2018 7:48 AM, Weijun Wang wrote: >>>> CSR updated. With such a generalized option, I won't recommend -groupname over -keysize now, although I still intend to print some warning for EC. >>>> Please take a review. >>>> Thanks >>>> Max >>>>> On Nov 7, 2018, at 10:36 PM, Adam Petcher wrote: >>>>> >>>>> One issue that just came to me: How will this work for EdDSA? I think the CSR could be generalized a bit: >>>>> >>>>> 1) Make the first item in the "Solution" more general. Instead of limiting it to "EC" allow any valid algorithm/curve combination. >>>>> 2) (Optional) Use -groupname instead of -curvename and change "curve" to "group" everywhere in the CSR. Then this mechanism can also be used for DSA (with named groups) and other algorithms that use groups that aren't curves. >>>>> Also, see below for a comment about curve ambiguity. >>>>> On 11/6/2018 7:59 PM, Weijun Wang wrote: >>>>>>> Otherwise, there are may be more curve categories. As it is not the recommended option, I may just remove this and the following one sentence. >>>>>>> >>>>>> I'll just leave it there as a FYI since it's not part of the spec. >>>>> >>>>> I agree with Xuelei that this part should be removed. Unless you are planning on implementing this curve selection logic in keytool, then we can't control which curve is selected, and it wholly depends on the behavior of the providers. We can't even guarantee that there is any relationship between "key size" and the field size of the curve. Also, we shouldn't use the word "random" here unless we plan to actually randomize the selection of the curve at runtime (similar to random iteration order for maps/sets). I suggest something more general and vague like: >>>>> >>>>> If only -keysize is specified, an arbitrary curve of the specified size is used >>>>> From weijun.wang at oracle.com Thu Nov 8 03:05:48 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 8 Nov 2018 11:05:48 +0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> Message-ID: In CurveDB.java, we have add("secp256r1 [NIST P-256, X9.62 prime256v1]", "1.2.840.10045.3.1.7", PD, "FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF", "FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFC", "5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B", "6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296", "4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5", "FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551", 1, nameSplitPattern); So the aliases of secp256r1 are now "NIST P-256" and "X9.62 prime256v1". Do we really want to keep the organization name prefix after JDK-8208156? The alias can be used in ECGenParameterSpec and the proposed keytool -groupname option. The following shows this behavior. > jshell> KeyPairGenerator.getInstance("EC") > $3 ==> java.security.KeyPairGenerator$Delegate at 64bfbc86 > > jshell> $3.initialize(new ECGenParameterSpec("secp256r1")) > > jshell> $3.initialize(new ECGenParameterSpec("prime256v1")) > | Exception java.security.InvalidAlgorithmParameterException: Unknown curve name: prime256v1 > | at ECKeyPairGenerator.initialize (ECKeyPairGenerator.java:103) > | at KeyPairGenerator$Delegate.initialize (KeyPairGenerator.java:699) > | at KeyPairGenerator.initialize (KeyPairGenerator.java:436) > | at (#6:1) > > jshell> $3.initialize(new ECGenParameterSpec("X9.62 prime256v1")) Thanks Max > On Nov 7, 2018, at 11:48 PM, Weijun Wang wrote: > > CSR updated. With such a generalized option, I won't recommend -groupname over -keysize now, although I still intend to print some warning for EC. > > Please take a review. > > Thanks > Max > From xuelei.fan at oracle.com Thu Nov 8 03:31:35 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 7 Nov 2018 19:31:35 -0800 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> Message-ID: I don't think the underlying provider is ready to support named curves. Additional RFEs may be required to standardize the names and improve the underlying provider. Xuelei On 11/7/2018 7:05 PM, Weijun Wang wrote: > In CurveDB.java, we have > > add("secp256r1 [NIST P-256, X9.62 prime256v1]", "1.2.840.10045.3.1.7", PD, > "FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF", > "FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFC", > "5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B", > "6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296", > "4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5", > "FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551", > 1, nameSplitPattern); > > So the aliases of secp256r1 are now "NIST P-256" and "X9.62 prime256v1". Do we really want to keep the organization name prefix after JDK-8208156? The alias can be used in ECGenParameterSpec and the proposed keytool -groupname option. > > The following shows this behavior. > >> jshell> KeyPairGenerator.getInstance("EC") >> $3 ==> java.security.KeyPairGenerator$Delegate at 64bfbc86 >> >> jshell> $3.initialize(new ECGenParameterSpec("secp256r1")) >> >> jshell> $3.initialize(new ECGenParameterSpec("prime256v1")) >> | Exception java.security.InvalidAlgorithmParameterException: Unknown curve name: prime256v1 >> | at ECKeyPairGenerator.initialize (ECKeyPairGenerator.java:103) >> | at KeyPairGenerator$Delegate.initialize (KeyPairGenerator.java:699) >> | at KeyPairGenerator.initialize (KeyPairGenerator.java:436) >> | at (#6:1) >> >> jshell> $3.initialize(new ECGenParameterSpec("X9.62 prime256v1")) > > Thanks > Max > >> On Nov 7, 2018, at 11:48 PM, Weijun Wang wrote: >> >> CSR updated. With such a generalized option, I won't recommend -groupname over -keysize now, although I still intend to print some warning for EC. >> >> Please take a review. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Thu Nov 8 13:10:57 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 8 Nov 2018 21:10:57 +0800 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> Message-ID: <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> Please also review the code change at https://cr.openjdk.java.net/~weijun/8213400/webrev.00/ Notes: - CertAndKeyGen.java: generate(String name): + try { + keyGen.initialize(new NamedParameterSpec(name), prng); + } catch (InvalidAlgorithmParameterException e) { + if (keyType.equalsIgnoreCase("EC")) { + // EC has another NamedParameterSpec + keyGen.initialize(new ECGenParameterSpec(name), prng); + } else { + throw e; + } + } This is for future algorithms that accept -groupname. In fact, our own ECKeyPairGenerator should have accepted NamedParameterSpec too. generate (int keyBits) allows keyBits == -1. This is for future algorithms that do not have a default -keysize. - keytool/Main.java: + private String ecGroupNameForSize(int size) throws Exception { + AlgorithmParameters ap = AlgorithmParameters.getInstance("EC"); + ap.init(new ECKeySizeParameterSpec(size)); + // The following line assumes the toString value is "name (oid)" + return ap.toString().split(" ")[0]; + } Hopefully the ap.toString().split(" ")[0] return value is not too ugly, but the toString() might contain alternative names. - CurveDB.java: - add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD, + add("sect163r2 [NIST B-163]", "1.3.132.0.15", B, All other NIST B-*** curves do not have BD. This should have been a typo. - NamedCurve.java: A new field commonNames added, which is used by the new GroupName.java test. Thanks Max From sean.mullan at oracle.com Thu Nov 8 15:03:06 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 8 Nov 2018 10:03:06 -0500 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: <42631146-f45b-9dbf-328f-20b995d2f7ef@oracle.com> References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> <42631146-f45b-9dbf-328f-20b995d2f7ef@oracle.com> Message-ID: On 11/7/18 7:22 PM, Xuelei Fan wrote: > On 11/7/2018 1:30 PM, Sean Mullan wrote: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8213161 >>> ?? http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/ >> >> I didn't see a test for SecureCacheResponse - is it possible? > JDK does not have the reference implementation of SecureCacheResponse. Ah, I see. I am sure there is a good reason, but why doesn't it have an implementation? >> You could also add a test case for IllegalStateExc. >> > Added in the same test file. > >> lines 108-113 of HttpsSession.java should be indented 4 more spaces. >> Otherwise looks ok to me. >> > Updated. > > New webrev: > http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/ Looks good. --Sean From adam.petcher at oracle.com Thu Nov 8 15:03:36 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 8 Nov 2018 10:03:36 -0500 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <4F40E173-B76D-404C-85A4-CD43A1F6A34F@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <1D08F1B4-5DCB-4FDD-A6FB-FA430AD927CC@oracle.com> <4a27f689-345c-e69f-7224-090e321baa89@oracle.com> <4F40E173-B76D-404C-85A4-CD43A1F6A34F@oracle.com> Message-ID: <827a8fd8-d22c-2be5-7654-87f500140c86@oracle.com> On 11/7/2018 8:53 PM, Weijun Wang wrote: > Oh, I didn't know that. > > To make sure -keyalg matches KeyPairGenerator.getInstance(), I'd like to support it. If I read the impl correctly, you don't need to initialize it anymore and if you really want to initialize it the params must be the same. Currently keytool always calls initialize(). In this case, there will be no default -keysize, and initializa() will be not be called if user has not specified one. If user provides -groupname or -keysize just use it and keytool fails if API call fails. This is correct. If you are using the "X25519" and "X448" algorithm name, then there is no need to initialize with parameters, because they are decided by the algorithm name. You can still initialize, and different providers may be more permissive than others if you try to use different parameters than what is specified by the algorithm name. For example: KeyPairGenerator.getInstance("X448").initialize(255). SunEC is very strict, and will not allow this sort of thing. X25519/X448 keys can only be used for KeyAgreement, so they aren't supported in keytool anyway, right? If this is the case, then you don't need to worry about adding any code to keytool for them. Though I expect EdDSA to work in a similar way (algorithm names "Ed25519" and "Ed448"). Still, I don't know if it is worthwhile to add special code for it. For all algorithms, if no -keysize or -groupname is specified, then keytool could skip the initialize on the KPG, and the implementation defaults (if available) will be used. The hard part is deciding whether to emit a warning in this case, and that will probably be algorithm-specific. >> On Nov 8, 2018, at 8:01 AM, Xuelei Fan wrote: >> >> On 11/7/2018 3:38 PM, Weijun Wang wrote: >>> This sounds a little misleading to me. Alg name and alg params are 2 different things. This is like asking user to call KeyPairGenerator.getInstance("secp256r1"). >> Well, KeyPairGenerator.getInstance("x25519") is a case that JDK 11 has supported now. >> >> Otherwise, there is a need to check the conflict of alg name and group name. This only works because "X25519" (and "X448") is both an algorithm name and a parameter spec name. This makes sense for X25519/X448, but not for all algorithms. I don't think there is any need to check for algorithm/group conflicts in keytool, because it is checked in the crypto provider already. All keytool needs to do is pass down the algorithm name and group name (as a NamedParameterSpec/ECGenParameterSpec) and see if it works. If we want to support "secp256r1" in -keyalg, then we can accomplish that by adding it as an algorithm name for KeyPairGenerator. Though I'm not sure this is a good idea. From erik.gahlin at oracle.com Thu Nov 8 15:12:06 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 8 Nov 2018 16:12:06 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> Message-ID: <5BE45246.3050603@oracle.com> Hi Sean, I think we could still call the event "jdk.SecurityPropertyModification", but add a @Description that explains that events are only emitted for the JDK due to security concerns. If we at a later stage want to include user events, we could add those and remove the @Description, possibly with a setting where you can specify scope, or perhaps a new event all together. Perhaps we could find a better name for the field validationEventNumber? It sounds like we have an event number, which is not really the case. We have a counter for the validation id. I noticed that you use hashCode as an id. I assume this is to simplify the implementation? That is probably OK, the risk of a collision is perhaps low, but could you make the field a long, so we in the future could add something more unique (Flight Recorder uses compressed integers, so a long uses the same amount of disk space as an int). Could you also rename the field and the annotation, perhaps certificationId could work, so we don't leak how the id was implemented. I could not find the file: test/lib/jdk/test/lib/security/TestJdkSecurityPropertyModification.java Thanks Erik > With JDK-8203629 now pushed, I've re-based my patch on latest jdk/jdk > code. > > Some modifications also made based on off-thread suggestions : > > src/java.base/share/classes/java/security/Security.java > > * Only record JDK security properties for now (i.e. those in > java.security conf file) > - we can consider a new event to record non-JDK security events if > demand comes about > - new event renamed to *Jdk*SecurityPropertyModificationEvent > > src/java.base/share/classes/sun/security/x509/X509CertImpl.java > > * Use hashCode() equality test for storing certs in List. > > Tests updated to capture these changes > > src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java > > * Verify that self signed certs exercise the modified code paths > > I've added new test functionality to test use of self signed cert. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v7/webrev/ > > Regards, > Sean. > On 17/10/18 11:25, Se?n Coffey wrote: >> I'd like to re-boot this review. I've been working with Erik off >> thread who's been helping with code and test design. >> >> Some of the main changes worthy of highlighting : >> >> * Separate out the tests for JFR and Logger events >> * Rename some events >> * Normalize the data view for X509ValidationEvent (old event name : >> CertChainEvent) >> * Introduce CertificateSerialNumber type to make use of the >> @Relational JFR annotation. >> * Keep calls for JFR event operations local to call site to optimize >> jvm compilation >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v6/webrev/ >> >> This code is dependent on the JDK-8203629 enhancement being integrated. >> >> Regards, >> Sean. >> >> On 10/07/18 13:50, Se?n Coffey wrote: >>> Erik, >>> >>> After some trial edits, I'm not so sure if moving the event & logger >>> commit code into the class where it's used works too well after all. >>> >>> In the code you suggested, there's an assumption that calls such as >>> EventHelper.certificateChain(..) are low cost. While that might be >>> the case here, it's something we can't always assume. It's called >>> once for the JFR operation and once for the Logger operation. That >>> pattern multiplies itself further in other Events. i.e. set up and >>> assign the variables for a JFR event without knowing whether they'll >>> be needed again for the Logger call. We could work around it by >>> setting up some local variables and re-using them in the Logger code >>> but then, we're back to where we were. The current EventHelper >>> design eliminates this problem and also helps to abstract the >>> recording/logging functionality away from the functionality of the >>> class itself. >>> >>> It also becomes a problem where we record events in multiple >>> different classes (e.g. SecurityPropertyEvent). While we could leave >>> the code in EventHelper for this case, we then have a mixed design >>> pattern. >>> >>> Are you ok with leaving as is for now? A future wish might be one >>> where JFR would handle Logger via its own framework/API in a future >>> JDK release. >>> >>> I've removed the variable names using underscore. Also optimized >>> some variable assignments in X509Impl.commitEvent(..) >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ >>> >>> regards, >>> Sean. >>> >>> On 09/07/2018 18:01, Se?n Coffey wrote: >>>> Erik, >>>> >>>> Thanks for reviewing. Comments inline.. >>>> >>>> On 09/07/18 17:21, Erik Gahlin wrote: >>>>> Thanks Sean. >>>>> >>>>> Some feedback on the code in the security libraries. >>>>> >>>>> - We should use camel case naming convention for variables (not >>>>> underscore). >>>> Sure. I see two offending variable names which I'll fix up. >>>>> >>>>> - Looking at sun/security/ssl/Finished.java, >>>>> >>>>> I wonder if it wouldn't be less code and more easy to read, if we >>>>> would commit the event in a local private function and then use >>>>> the EventHelper class for common functionality. >>>> I'm fine with your suggested approach. I figured that tucking the >>>> recording/logging logic away in a helper class also had benefits >>>> but I'll re-factor to your suggested style unless I hear objections. >>>> >>>> regards, >>>> Sean. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Thu Nov 8 15:21:59 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 8 Nov 2018 10:21:59 -0500 Subject: RFR CSR for 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> Message-ID: <09874d51-d55e-4942-b241-6ed6cbd9cf0f@oracle.com> I'm missing the motivation behind this question. Is the current set of aliases causing some problem? Are they incomplete? Why is it bad that "X9.62 prime256v1" works but "prime256v1" doesn't? On 11/7/2018 10:05 PM, Weijun Wang wrote: > In CurveDB.java, we have > > add("secp256r1 [NIST P-256, X9.62 prime256v1]", "1.2.840.10045.3.1.7", PD, > "FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF", > "FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFC", > "5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B", > "6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296", > "4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5", > "FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551", > 1, nameSplitPattern); > > So the aliases of secp256r1 are now "NIST P-256" and "X9.62 prime256v1". Do we really want to keep the organization name prefix after JDK-8208156? The alias can be used in ECGenParameterSpec and the proposed keytool -groupname option. > > The following shows this behavior. > >> jshell> KeyPairGenerator.getInstance("EC") >> $3 ==> java.security.KeyPairGenerator$Delegate at 64bfbc86 >> >> jshell> $3.initialize(new ECGenParameterSpec("secp256r1")) >> >> jshell> $3.initialize(new ECGenParameterSpec("prime256v1")) >> | Exception java.security.InvalidAlgorithmParameterException: Unknown curve name: prime256v1 >> | at ECKeyPairGenerator.initialize (ECKeyPairGenerator.java:103) >> | at KeyPairGenerator$Delegate.initialize (KeyPairGenerator.java:699) >> | at KeyPairGenerator.initialize (KeyPairGenerator.java:436) >> | at (#6:1) >> >> jshell> $3.initialize(new ECGenParameterSpec("X9.62 prime256v1")) > Thanks > Max > >> On Nov 7, 2018, at 11:48 PM, Weijun Wang wrote: >> >> CSR updated. With such a generalized option, I won't recommend -groupname over -keysize now, although I still intend to print some warning for EC. >> >> Please take a review. >> >> Thanks >> Max >> From adam.petcher at oracle.com Thu Nov 8 16:28:03 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 8 Nov 2018 11:28:03 -0500 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> Message-ID: <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> On 11/8/2018 8:10 AM, Weijun Wang wrote: > - CurveDB.java: > > - add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD, > + add("sect163r2 [NIST B-163]", "1.3.132.0.15", B, > > All other NIST B-*** curves do not have BD. This should have been a typo. I think this will change the default 163-bit curve from sect163r2 to sect163k1. We shouldn't change these defaults without a compelling reason. > > - NamedCurve.java: > > A new field commonNames added, which is used by the new GroupName.java test. I don't see why this is necessary. The test is using this list of common names to make sure the correct named curve is used. Why not just check the value returned by NamedCurve.getName() against the expected (canonical) name of the curve? Or check the OID? From daniel.fuchs at oracle.com Thu Nov 8 16:31:30 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 8 Nov 2018 16:31:30 +0000 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> <42631146-f45b-9dbf-328f-20b995d2f7ef@oracle.com> Message-ID: On 08/11/2018 15:03, Sean Mullan wrote: > Ah, I see. I am sure there is a good reason, but why doesn't it have an > implementation? > IIRC there was an implementation in the deploy code. best regards, -- daniel From adam.petcher at oracle.com Thu Nov 8 16:43:31 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 8 Nov 2018 11:43:31 -0500 Subject: RFR 8213363: X25519 private key PKCS#8 encoding/decoding is incorrect Message-ID: webrev: http://cr.openjdk.java.net/~apetcher/8213363/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8213493 This change fixes a bug related to the encoded format of X25519/X448 private keys. The new code will not preserve compatibility with the improperly-formatted keys produced by the existing code. I expect the compatibility impact of this change to be minimal, as described in the CSR ticket. From adam.petcher at oracle.com Thu Nov 8 16:51:44 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 8 Nov 2018 11:51:44 -0500 Subject: RFR 8213363: X25519 private key PKCS#8 encoding/decoding is incorrect In-Reply-To: References: Message-ID: <39ab9a36-6aff-a363-793a-a160d5b77f2e@oracle.com> Oops. And the JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8213363 On 11/8/2018 11:43 AM, Adam Petcher wrote: > webrev: http://cr.openjdk.java.net/~apetcher/8213363/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8213493 > > This change fixes a bug related to the encoded format of X25519/X448 > private keys. The new code will not preserve compatibility with the > improperly-formatted keys produced by the existing code. I expect the > compatibility impact of this change to be minimal, as described in the > CSR ticket. > From sean.mullan at oracle.com Thu Nov 8 19:36:09 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 8 Nov 2018 14:36:09 -0500 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> Message-ID: <1e3d7e3f-f99e-36c3-20f1-6d707b2e2c94@oracle.com> On 11/7/18 3:52 AM, Baesken, Matthias wrote: >> Sorry, I haven't had time to look at this in more detail yet. But, let's >> take a step back first. Can you or Matthias explain in more detail why >> this fix is necessary? What are the use cases and motivation? > > Hello, > adding paths (or maybe more details) to exception messages just makes analyzing errors easier. > You do not get just "Bad path", but also the real bad path which gives you a hint where to look and analyze further . File paths are, in general, always something that demands extra scrutiny as it can be the source of security issues (privacy leaks, traversal attacks, etc). It's not just me that thinks that way, you can do a search on the Internet and find lots of references. > That's why we introduced it in our JVM ages ago. > I have to agree that additionally printing cwd / user.dir is a bit special, so I omit that from this revision of the patch. > This makes the patch more simple. > New revision : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.1/ > > > Unfortunately the usage of sun.security.util.SecurityProperties (which was considered) in the static { ... } > class initializers (e.g. UnixFileSystem.java) just does not work. > It fails with already in the build (!) with : > > Error occurred during initialization of boot layer > java.lang.ExceptionInInitializerError > Caused by: java.lang.NullPointerException > > (seems it is too early in the game for SecurityProperties). > (btw. this is another NOT very helpful exception error message) > > > So I unfortunately had to go back to using system properties. > > > Btw. another question regarding path output in exceptions : > you seem to consider it a bad thing to (unconditionally) print paths in the exception messages, > but then on the other hand we have it already in OpenJDK UnixFileSystem_md.c : > > 269 JNIEXPORT jboolean JNICALL > 270 Java_java_io_UnixFileSystem_createFileExclusively(JNIEnv *env, jclass cls, > 271 jstring pathname) > 272 { > ....... > 277 /* The root directory always exists */ > 278 if (strcmp (path, "/")) { > 279 fd = handleOpen(path, O_RDWR | O_CREAT | O_EXCL, 0666); > 280 if (fd < 0) { > 281 if (errno != EEXIST) > 282 JNU_ThrowIOExceptionWithLastError(env, path); > 283 } else { > 284 if (close(fd) == -1) > 285 JNU_ThrowIOExceptionWithLastError(env, path); > > > Why is it fine here for a long time , but considered harmful at the other places ? > If we want to be consistent, we should then write "Bad path" here (or allow the path output at the other places too ). It might be perfectly fine and your usage might be ok too. But I'll need some time to evaluate it further. I am not familiar with the code in this part of the JDK. I would also see if you can think about the security issues as well. Where do these paths come from? What are the application use cases that invoke these lower methods? From application code or elsewhere? Are relative paths used? Are paths containing ".." canonicalized? Are they arbitrary paths or a fixed set of paths? Do they ever contain sensitive information like home directory user names, etc? Once we understand if there are any security issues, then we can decide if allowing that via a system property is acceptable or not, and if so the security risks that we would have to document for that property. Thanks, Sean > > > Thanks, Matthias > > > >> -----Original Message----- >> From: Sean Mullan >> Sent: Freitag, 12. Oktober 2018 17:19 >> To: Langer, Christoph ; Baesken, Matthias >> ; Alan Bateman ; >> security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - >> enhance some IOExceptions with path causing the issue >> >> On 10/12/18 10:33 AM, Langer, Christoph wrote: >>> Sean, what is your take on this? >> >> Sorry, I haven't had time to look at this in more detail yet. But, let's >> take a step back first. Can you or Matthias explain in more detail why >> this fix is necessary? What are the use cases and motivation? The bug >> report doesn't go into any detail about that and there isn't anything >> in the initial RFR email that explains why this change is useful or >> necessary. As a general guideline or advice, RFEs should include this >> type of information so that Reviewers understand more of the context and >> motivation behind the change. >> >> Thanks, >> Sean From xuelei.fan at oracle.com Thu Nov 8 21:06:42 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 8 Nov 2018 13:06:42 -0800 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> <42631146-f45b-9dbf-328f-20b995d2f7ef@oracle.com> Message-ID: To make sure the SecureCacheResponse class work, two new tests are added (DefaultCacheResponse for default implementation, DummyCacheResponse for a test implementation): http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/ Thanks, Xuelei On 11/8/2018 7:03 AM, Sean Mullan wrote: > On 11/7/18 7:22 PM, Xuelei Fan wrote: >> On 11/7/2018 1:30 PM, Sean Mullan wrote: >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8213161 >>>> ?? http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/ >>> >>> I didn't see a test for SecureCacheResponse - is it possible? >> JDK does not have the reference implementation of SecureCacheResponse. > > Ah, I see. I am sure there is a good reason, but why doesn't it have an > implementation? > >>> You could also add a test case for IllegalStateExc. >>> >> Added in the same test file. >> >>> lines 108-113 of HttpsSession.java should be indented 4 more spaces. >>> Otherwise looks ok to me. >>> >> Updated. >> >> New webrev: >> http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/ > > Looks good. > > --Sean From weijun.wang at oracle.com Fri Nov 9 03:30:31 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 9 Nov 2018 11:30:31 +0800 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> Message-ID: > On Nov 9, 2018, at 12:28 AM, Adam Petcher wrote: > > On 11/8/2018 8:10 AM, Weijun Wang wrote: > >> - CurveDB.java: >> >> - add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD, >> + add("sect163r2 [NIST B-163]", "1.3.132.0.15", B, >> >> All other NIST B-*** curves do not have BD. This should have been a typo. > > I think this will change the default 163-bit curve from sect163r2 to sect163k1. We shouldn't change these defaults without a compelling reason. I think this is a bug, as there should not be 2 curves with the same field size both having BD. I can file another bug on this. Maybe it needs it own CSR. > >> >> - NamedCurve.java: >> >> A new field commonNames added, which is used by the new GroupName.java test. > > I don't see why this is necessary. The test is using this list of common names to make sure the correct named curve is used. Why not just check the value returned by NamedCurve.getName() against the expected (canonical) name of the curve? Or check the OID? NamedCurve.getName() returns "secp256r1 [NIST P-256, X9.62 prime256v1]". I don't want to canonicalize the name (how? returning NamedCurve.getName()?) or use an OID. The test is about making sure the curve used matches the one user specified. What if I am making the same error inside keytool and this canonicalization or string-to-oid method? In fact, I had wanted to add lines using "alternative names" like "-groupname prime256v1" in the test but later I found out it must be `-groupname "X9.62 prime256v1"` which is not easy to write in the test. (the SecurityTools.keytool() method does not like spaces inside an argument). You might say since I have already called split(" ")[0] in src/ I can also call it here in a test. But then I still want to have the chance to try out any alternative name later, especially after we think "prime256v1" is better than "X9.62 prime256v1". Thanks Max > > From xuelei.fan at oracle.com Fri Nov 9 04:00:58 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 8 Nov 2018 20:00:58 -0800 Subject: CSR Review Request, JDK-8213577, Update the default SSL session cache size to 20480 Message-ID: Hi, Please review the proposal to update the default SSL session cache size from infinite to 20480. https://bugs.openjdk.java.net/browse/JDK-8213577 I know that the default 20480 does not fit all. I'd appreciate your feedback if the value is acceptable. Thanks, Xuelei From sean.coffey at oracle.com Fri Nov 9 11:18:52 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 9 Nov 2018 11:18:52 +0000 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <5BE45246.3050603@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> <5BE45246.3050603@oracle.com> Message-ID: Erik, comments inline.. On 08/11/18 15:12, Erik Gahlin wrote: > Hi Sean, > > I think we could still call the event > "jdk.SecurityPropertyModification", but add a @Description that > explains that events are only emitted for the JDK due to security > concerns. If we at a later stage want to include user events, we could > add those and remove the @Description, possibly with a setting where > you can specify scope, or perhaps a new event all together. sounds fine. I've made those changes. > > Perhaps we could find a better name for the field > validationEventNumber? It sounds like we have an event number, which > is not really the case. We have a counter for the validation id. How about 'validationCounter' ? > > I noticed that you use hashCode as an id. I assume this is to simplify > the implementation? That is probably OK, the risk of a collision is > perhaps low, but could you make the field a long, so we in the future > could add something more unique (Flight Recorder uses compressed > integers, so a long uses the same amount of disk space as an int). > Could you also rename the field and the annotation, perhaps > certificationId could work, so we don't leak how the id was implemented. Yes - originally, I was using the certificate serial number but that may not always be unique (esp. for test generated certs). I've changed the variable name to 'certificateId' and made it a long. Renamed the annotation also. > > I could not find the file: > test/lib/jdk/test/lib/security/TestJdkSecurityPropertyModification.java whoops - forgot to add it to mercurial tracking. there now : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v8/webrev/ regards, Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Nov 9 13:19:59 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 9 Nov 2018 08:19:59 -0500 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> <784da7db-5826-5817-1a15-0ef5620e21a0@oracle.com> <42631146-f45b-9dbf-328f-20b995d2f7ef@oracle.com> Message-ID: On 11/8/18 4:06 PM, Xuelei Fan wrote: > To make sure the SecureCacheResponse class work, two new tests are added > (DefaultCacheResponse for default implementation, DummyCacheResponse for > a test implementation): > ??? http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/ I think you mean http://cr.openjdk.java.net/~xuelei/8212261/webrev.05/ Looks good. --Sean > > Thanks, > Xuelei > > On 11/8/2018 7:03 AM, Sean Mullan wrote: >> On 11/7/18 7:22 PM, Xuelei Fan wrote: >>> On 11/7/2018 1:30 PM, Sean Mullan wrote: >>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8213161 >>>>> ?? http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/ >>>> >>>> I didn't see a test for SecureCacheResponse - is it possible? >>> JDK does not have the reference implementation of SecureCacheResponse. >> >> Ah, I see. I am sure there is a good reason, but why doesn't it have >> an implementation? >> >>>> You could also add a test case for IllegalStateExc. >>>> >>> Added in the same test file. >>> >>>> lines 108-113 of HttpsSession.java should be indented 4 more spaces. >>>> Otherwise looks ok to me. >>>> >>> Updated. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/ >> >> Looks good. >> >> --Sean From adam.petcher at oracle.com Fri Nov 9 15:33:43 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 9 Nov 2018 10:33:43 -0500 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> Message-ID: <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> On 11/8/2018 10:30 PM, Weijun Wang wrote: >> On Nov 9, 2018, at 12:28 AM, Adam Petcher wrote: >> >> On 11/8/2018 8:10 AM, Weijun Wang wrote: >> >>> - CurveDB.java: >>> >>> - add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD, >>> + add("sect163r2 [NIST B-163]", "1.3.132.0.15", B, >>> >>> All other NIST B-*** curves do not have BD. This should have been a typo. >> I think this will change the default 163-bit curve from sect163r2 to sect163k1. We shouldn't change these defaults without a compelling reason. > I think this is a bug, as there should not be 2 curves with the same field size both having BD. > > I can file another bug on this. Maybe it needs it own CSR. Yes, it's probably a bug/typo. You can also fix it by changing sect163k1 from BD to B, since this won't change the behavior (though this would need to be tested). But I wouldn't worry about it. You can create a separate ticket if you like, but I would expect that fixing this is very low priority. The current behavior may even be correct (or at least "as intended"), and this is just a code cleanup issue. >>> - NamedCurve.java: >>> >>> A new field commonNames added, which is used by the new GroupName.java test. >> I don't see why this is necessary. The test is using this list of common names to make sure the correct named curve is used. Why not just check the value returned by NamedCurve.getName() against the expected (canonical) name of the curve? Or check the OID? > NamedCurve.getName() returns "secp256r1 [NIST P-256, X9.62 prime256v1]". > > I don't want to canonicalize the name (how? returning NamedCurve.getName()?) or use an OID. The test is about making sure the curve used matches the one user specified. What if I am making the same error inside keytool and this canonicalization or string-to-oid method? > > I think what I am suggesting is map from common name to canonical name or OID in the test. Then you can test that the correct common name is used, and that the mapping from common name to curve is correct. If you don't want to write out this map, then you can implement it by looking up the common name in the EC AlgorithmParameters, and then converting to an ECParameterSpec. This just moves the complexity from CurveDB to the test, but I think that is better. Though I don't have very strong feelings about this. Perhaps the list of common names in the NamedCurve will be useful for other things. If you prefer it the way that it is, then I am okay with it. From xuelei.fan at oracle.com Fri Nov 9 16:43:39 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 9 Nov 2018 08:43:39 -0800 Subject: Code Review Request : JDK-8213694 : Test Timeout.java should run in othervm mode Message-ID: Hi, Could I get the following small change reviewed please? http://cr.openjdk.java.net/~xuelei/8213694/webrev.00/ The test SSLSessionContextImpl/Timeout.java is running in the default mode. As the test initializes the SSLContext with the current System Properties, while the SunJSSE provider does not support dynamic System Properties, this test may impact other test cases running in samevm/agentvm mode. The impact is very hard to debugging. I updated the test to run in othervm mode, and cleanup the code by removing commented out codes and close the server socket with a try-with-resource. Thanks, Xuelei From jamil.j.nimeh at oracle.com Fri Nov 9 17:17:48 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 9 Nov 2018 09:17:48 -0800 Subject: Code Review Request : JDK-8213694 : Test Timeout.java should run in othervm mode In-Reply-To: References: Message-ID: Looks fine to me. On 11/9/2018 8:43 AM, Xuelei Fan wrote: > Hi, > > Could I get the following small change reviewed please? > ?? http://cr.openjdk.java.net/~xuelei/8213694/webrev.00/ > > The test SSLSessionContextImpl/Timeout.java is running in the default > mode. As the test initializes the SSLContext with the current System > Properties, while the SunJSSE provider does not support dynamic System > Properties, this test may impact other test cases running in > samevm/agentvm mode.? The impact is very hard to debugging. > > I updated the test to run in othervm mode, and cleanup the code by > removing commented out codes and close the server socket with a > try-with-resource. > > Thanks, > Xuelei From jamil.j.nimeh at oracle.com Fri Nov 9 17:34:00 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 9 Nov 2018 09:34:00 -0800 Subject: CSR Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: References: Message-ID: Hi Xuelei, Content looks good.? I'd remove specific references to Amazon from the CSR (it's fine to leave it in the source bug though).? Where'd you get the 20480 session cache limit from?? I saw a similar limit using the builtin SSL session cache from NGINX, is that where that number comes from?? Or is that common to other TLS library or webserver cache sizes? --Jamil On 11/8/2018 8:00 PM, Xuelei Fan wrote: > Hi, > > Please review the proposal to update the default SSL session cache > size from infinite to 20480. > ? https://bugs.openjdk.java.net/browse/JDK-8213577 > > I know that the default 20480 does not fit all.? I'd appreciate your > feedback if the value is acceptable. > > Thanks, > Xuelei From xuelei.fan at oracle.com Fri Nov 9 18:13:25 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 9 Nov 2018 10:13:25 -0800 Subject: CSR Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: References: Message-ID: <3666bdf4-605c-b01d-2ebd-ab34e0767a52@oracle.com> On 11/9/2018 9:34 AM, Jamil Nimeh wrote: > Hi Xuelei, > > Content looks good.? I'd remove specific references to Amazon from the > CSR (it's fine to leave it in the source bug though). Removed. > Where'd you get > the 20480 session cache limit from?? I saw a similar limit using the > builtin SSL session cache from NGINX, is that where that number comes > from?? Or is that common to other TLS library or webserver cache sizes? > The number is coming from what NGINX is using. In the bug description, it is said 10K could be a good one. However, the number is really depends on the platform resources. I'd like to use a bigger one so that the performance impact of the existing applications is as minimal as possible. Thanks, Xuelei > --Jamil > > On 11/8/2018 8:00 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the proposal to update the default SSL session cache >> size from infinite to 20480. >> ? https://bugs.openjdk.java.net/browse/JDK-8213577 >> >> I know that the default 20480 does not fit all.? I'd appreciate your >> feedback if the value is acceptable. >> >> Thanks, >> Xuelei > From jamil.j.nimeh at oracle.com Fri Nov 9 18:48:06 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 9 Nov 2018 10:48:06 -0800 Subject: CSR Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: <3666bdf4-605c-b01d-2ebd-ab34e0767a52@oracle.com> References: <3666bdf4-605c-b01d-2ebd-ab34e0767a52@oracle.com> Message-ID: I think that's fine as a default.? It can be tuned for those sites that need something larger or smaller. --Jamil On 11/9/2018 10:13 AM, Xuelei Fan wrote: > On 11/9/2018 9:34 AM, Jamil Nimeh wrote: >> Hi Xuelei, >> >> Content looks good.? I'd remove specific references to Amazon from >> the CSR (it's fine to leave it in the source bug though). > Removed. > >> Where'd you get the 20480 session cache limit from?? I saw a similar >> limit using the builtin SSL session cache from NGINX, is that where >> that number comes from?? Or is that common to other TLS library or >> webserver cache sizes? >> > The number is coming from what NGINX is using.? In the bug > description, it is said 10K could be a good one.? However, the number > is really depends on the platform resources.? I'd like to use a bigger > one so that the performance impact of the existing applications is as > minimal as possible. > > Thanks, > Xuelei > >> --Jamil >> >> On 11/8/2018 8:00 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the proposal to update the default SSL session cache >>> size from infinite to 20480. >>> ? https://bugs.openjdk.java.net/browse/JDK-8213577 >>> >>> I know that the default 20480 does not fit all.? I'd appreciate your >>> feedback if the value is acceptable. >>> >>> Thanks, >>> Xuelei >> From adam.petcher at oracle.com Fri Nov 9 19:09:06 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 9 Nov 2018 14:09:06 -0500 Subject: RFR 8213202: Possible race condition in TLS 1.3 session resumption Message-ID: <73adb4a8-a7c3-58f5-a2a6-93e58aa4df13@oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8213202 webrev: http://cr.openjdk.java.net/~apetcher/8213202/webrev.00/ This change fixes a bug that allows multiple clients thread to offer the same PSK to the server, even though only one thread may actually use the PSK to resume the session. The other threads will fail to connect and throw an exception. This is noreg-hard because the bug doesn't happen with the JDK TLS server, and we don't have a regression test harness that allows us to simulate some particular server behavior. I tested the fix by connecting multiple JDK clients to an openssl server. From coderaptor at gmail.com Fri Nov 9 19:17:40 2018 From: coderaptor at gmail.com (coderaptor) Date: Fri, 9 Nov 2018 11:17:40 -0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> Message-ID: The CSR looks fine to me. Thanks. -coderaptor On Wed, Nov 7, 2018 at 7:53 AM Weijun Wang wrote: > > Oops, I take this back. The CSR needs more update. > > Sorry if you have already start reading it. > > Thanks > Max > > > > On Nov 7, 2018, at 9:27 AM, Weijun Wang wrote: > > > > After some discussion, we decided to cover -keysize and -sigalg in this deprecation process too. > > > > Please review the updated CSR at > > > > https://bugs.openjdk.java.net/browse/JDK-8212111 > > > > No webrev available yet. > > > > Thanks > > Max > > > > > >> On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: > >> > >> Please review the code change and CSR for > >> > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 > >> > >> at > >> > >> webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ > >> CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 > >> > >> When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. > >> > >> A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. > >> > >> A Mach5 job on tier1 and tier2 running now. > >> > >> Thanks > >> Max > >> > > > From jamil.j.nimeh at oracle.com Fri Nov 9 21:48:11 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 9 Nov 2018 13:48:11 -0800 Subject: CSR Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: <3666bdf4-605c-b01d-2ebd-ab34e0767a52@oracle.com> References: <3666bdf4-605c-b01d-2ebd-ab34e0767a52@oracle.com> Message-ID: <6eeee816-1c2c-315a-fc77-e4d4ed783c59@oracle.com> Hi Xuelei, I've added myself as a reviewer. --Jamil On 11/9/2018 10:13 AM, Xuelei Fan wrote: > On 11/9/2018 9:34 AM, Jamil Nimeh wrote: >> Hi Xuelei, >> >> Content looks good.? I'd remove specific references to Amazon from >> the CSR (it's fine to leave it in the source bug though). > Removed. > >> Where'd you get the 20480 session cache limit from?? I saw a similar >> limit using the builtin SSL session cache from NGINX, is that where >> that number comes from?? Or is that common to other TLS library or >> webserver cache sizes? >> > The number is coming from what NGINX is using.? In the bug > description, it is said 10K could be a good one.? However, the number > is really depends on the platform resources.? I'd like to use a bigger > one so that the performance impact of the existing applications is as > minimal as possible. > > Thanks, > Xuelei > >> --Jamil >> >> On 11/8/2018 8:00 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the proposal to update the default SSL session cache >>> size from infinite to 20480. >>> ? https://bugs.openjdk.java.net/browse/JDK-8213577 >>> >>> I know that the default 20480 does not fit all.? I'd appreciate your >>> feedback if the value is acceptable. >>> >>> Thanks, >>> Xuelei >> From weijun.wang at oracle.com Sun Nov 11 15:30:10 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 11 Nov 2018 23:30:10 +0800 Subject: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow Message-ID: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8210476/webrev.00/ Before this fix, every PRNG::nextBytes calls all of CryptAcquireContext, CryptGenRandom, and CryptReleaseContext. Now, CryptAcquireContext is called once in PRNG::new, and CryptReleaseContext is called by a Cleaner, and nextBytes only calls CryptGenRandom. I haven't read about thread-safety in any MS document, the current Windows-PRNG service is marked ThreadSafe=true (in SunMSCAPI.java). If we cannot be really sure, we can change it to false. I've downloaded nearly 1000 Mach5 runs of this test, the enhancement is so good that I adjusted the test to be stricter. Before After ------ ----- Count 897 74 Min 0.38 0.008 Ave 0.97 0.011 Max 5.81 0.021 Please advise me if the following usage of Cleaner is correct because I really haven't observed the releaseContext method being called. + Cleaner.create().register(this, + () -> releaseContext(ctxt)); Thanks Max From weijun.wang at oracle.com Mon Nov 12 01:08:52 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 12 Nov 2018 09:08:52 +0800 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> Message-ID: <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> Webrev updated at https://cr.openjdk.java.net/~weijun/8213400/webrev.01/ Please review again. I've removed the change to CurveDB and NamedCurve. The test now simply looks at key.getParams().toString(). This is implementation dependent but it works within OpenJDK. No change on other files. I filed https://bugs.openjdk.java.net/browse/JDK-8213719 for the double BD issue. Thanks Max > On Nov 9, 2018, at 11:33 PM, Adam Petcher wrote: > > On 11/8/2018 10:30 PM, Weijun Wang wrote: > >>> On Nov 9, 2018, at 12:28 AM, Adam Petcher wrote: >>> >>> On 11/8/2018 8:10 AM, Weijun Wang wrote: >>> >>>> - CurveDB.java: >>>> >>>> - add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD, >>>> + add("sect163r2 [NIST B-163]", "1.3.132.0.15", B, >>>> >>>> All other NIST B-*** curves do not have BD. This should have been a typo. >>> I think this will change the default 163-bit curve from sect163r2 to sect163k1. We shouldn't change these defaults without a compelling reason. >> I think this is a bug, as there should not be 2 curves with the same field size both having BD. >> >> I can file another bug on this. Maybe it needs it own CSR. > > Yes, it's probably a bug/typo. You can also fix it by changing sect163k1 from BD to B, since this won't change the behavior (though this would need to be tested). But I wouldn't worry about it. You can create a separate ticket if you like, but I would expect that fixing this is very low priority. The current behavior may even be correct (or at least "as intended"), and this is just a code cleanup issue. > >>>> - NamedCurve.java: >>>> >>>> A new field commonNames added, which is used by the new GroupName.java test. >>> I don't see why this is necessary. The test is using this list of common names to make sure the correct named curve is used. Why not just check the value returned by NamedCurve.getName() against the expected (canonical) name of the curve? Or check the OID? >> NamedCurve.getName() returns "secp256r1 [NIST P-256, X9.62 prime256v1]". >> >> I don't want to canonicalize the name (how? returning NamedCurve.getName()?) or use an OID. The test is about making sure the curve used matches the one user specified. What if I am making the same error inside keytool and this canonicalization or string-to-oid method? >> >> > > I think what I am suggesting is map from common name to canonical name or OID in the test. Then you can test that the correct common name is used, and that the mapping from common name to curve is correct. If you don't want to write out this map, then you can implement it by looking up the common name in the EC AlgorithmParameters, and then converting to an ECParameterSpec. This just moves the complexity from CurveDB to the test, but I think that is better. > > Though I don't have very strong feelings about this. Perhaps the list of common names in the NamedCurve will be useful for other things. If you prefer it the way that it is, then I am okay with it. From jamil.j.nimeh at oracle.com Tue Nov 13 07:46:03 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 12 Nov 2018 23:46:03 -0800 Subject: RFR, JDK-8212885: TLS 1.3 resumed session does not retain peer certificate chain In-Reply-To: <2214d548-1437-2156-7448-ce84527b176d@oracle.com> References: <5f37d700-8859-da3c-c524-23bae8b24b5c@oracle.com> <0b9dec8a-f4b3-4fbc-dfc8-3fcf492f91f5@oracle.com> <5f56a6e2-87b5-451f-6c8e-807f3cee4da7@oracle.com> <427b9e24-fbc5-65e0-d3f3-385c0a1b6236@oracle.com> <2214d548-1437-2156-7448-ce84527b176d@oracle.com> Message-ID: <70dd0aba-e508-c117-3810-367e69ea6428@oracle.com> Hello all, This is an update that addresses a few additional fields that needed to be carried over into the new SSLSession, as well as adding some more testing on the retrieved resumed SSLSession object. http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.04/ Thanks, --Jamil From adam.petcher at oracle.com Tue Nov 13 15:02:44 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 13 Nov 2018 10:02:44 -0500 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> Message-ID: <564a9a5a-352e-d21f-ec84-feb6562adcf1@oracle.com> This change looks good to me. Thanks. On 11/11/2018 8:08 PM, Weijun Wang wrote: > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8213400/webrev.01/ > > Please review again. > > I've removed the change to CurveDB and NamedCurve. The test now simply looks at key.getParams().toString(). This is implementation dependent but it works within OpenJDK. > > No change on other files. > > I filed https://bugs.openjdk.java.net/browse/JDK-8213719 for the double BD issue. > > Thanks > Max > > >> On Nov 9, 2018, at 11:33 PM, Adam Petcher wrote: >> >> On 11/8/2018 10:30 PM, Weijun Wang wrote: >> >>>> On Nov 9, 2018, at 12:28 AM, Adam Petcher wrote: >>>> >>>> On 11/8/2018 8:10 AM, Weijun Wang wrote: >>>> >>>>> - CurveDB.java: >>>>> >>>>> - add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD, >>>>> + add("sect163r2 [NIST B-163]", "1.3.132.0.15", B, >>>>> >>>>> All other NIST B-*** curves do not have BD. This should have been a typo. >>>> I think this will change the default 163-bit curve from sect163r2 to sect163k1. We shouldn't change these defaults without a compelling reason. >>> I think this is a bug, as there should not be 2 curves with the same field size both having BD. >>> >>> I can file another bug on this. Maybe it needs it own CSR. >> Yes, it's probably a bug/typo. You can also fix it by changing sect163k1 from BD to B, since this won't change the behavior (though this would need to be tested). But I wouldn't worry about it. You can create a separate ticket if you like, but I would expect that fixing this is very low priority. The current behavior may even be correct (or at least "as intended"), and this is just a code cleanup issue. >> >>>>> - NamedCurve.java: >>>>> >>>>> A new field commonNames added, which is used by the new GroupName.java test. >>>> I don't see why this is necessary. The test is using this list of common names to make sure the correct named curve is used. Why not just check the value returned by NamedCurve.getName() against the expected (canonical) name of the curve? Or check the OID? >>> NamedCurve.getName() returns "secp256r1 [NIST P-256, X9.62 prime256v1]". >>> >>> I don't want to canonicalize the name (how? returning NamedCurve.getName()?) or use an OID. The test is about making sure the curve used matches the one user specified. What if I am making the same error inside keytool and this canonicalization or string-to-oid method? >>> >>> >> I think what I am suggesting is map from common name to canonical name or OID in the test. Then you can test that the correct common name is used, and that the mapping from common name to curve is correct. If you don't want to write out this map, then you can implement it by looking up the common name in the EC AlgorithmParameters, and then converting to an ECParameterSpec. This just moves the complexity from CurveDB to the test, but I think that is better. >> >> Though I don't have very strong feelings about this. Perhaps the list of common names in the NamedCurve will be useful for other things. If you prefer it the way that it is, then I am okay with it. From xuelei.fan at oracle.com Tue Nov 13 15:13:53 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 13 Nov 2018 07:13:53 -0800 Subject: RFR, JDK-8212885: TLS 1.3 resumed session does not retain peer certificate chain In-Reply-To: <70dd0aba-e508-c117-3810-367e69ea6428@oracle.com> References: <5f37d700-8859-da3c-c524-23bae8b24b5c@oracle.com> <0b9dec8a-f4b3-4fbc-dfc8-3fcf492f91f5@oracle.com> <5f56a6e2-87b5-451f-6c8e-807f3cee4da7@oracle.com> <427b9e24-fbc5-65e0-d3f3-385c0a1b6236@oracle.com> <2214d548-1437-2156-7448-ce84527b176d@oracle.com> <70dd0aba-e508-c117-3810-367e69ea6428@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 11/12/2018 11:46 PM, Jamil Nimeh wrote: > Hello all, > > This is an update that addresses a few additional fields that needed to > be carried over into the new SSLSession, as well as adding some more > testing on the retrieved resumed SSLSession object. > > http://cr.openjdk.java.net/~jnimeh/reviews/8212885/webrev.04/ > > Thanks, > > --Jamil > From sean.mullan at oracle.com Tue Nov 13 18:53:09 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 13 Nov 2018 13:53:09 -0500 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> Message-ID: <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> Looking good, a couple of comments/questions: * src/java.base/share/classes/java/security/Security.java The isJdkSecurityProperty method could return false positives, for example there may be a non-JDK property starting with "security.". I was thinking it would be better to put all the JDK property names in a HashSet which is populated by the static initialize() method, and only if event logging is enabled. Then setProperty can just check if the property name is in this set. * src/java.base/share/classes/sun/security/x509/X509CertImpl.java 158 // Event recording cache list 159 private List recordedCerts; Shouldn't this be static? Otherwise each certificate would have it's own instance and duplicates would not be detected. The rest of my comments are mostly minor stuff, and nits: * src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java 245 if(xve.shouldCommit() || EventHelper.isLoggingSecurity()) { add space before "(xve" * src/java.base/share/classes/sun/security/ssl/Finished.java 1097 } indent 1098 if(event.shouldCommit()) { add space before "(event" * src/java.base/share/classes/sun/security/x509/X509CertImpl.java update copyright * src/java.base/share/classes/jdk/internal/event/EventHelper.java 35 * A helper class to have events logged to a JDK Event Logger Add '.' at end of sentence. * src/java.base/share/classes/jdk/internal/event/TLSHandshakeEvent.java 38: remove blank line * src/java.base/share/classes/jdk/internal/event/X509ValidationEvent.java 30 * used in X509 cert path validation Add '.' at end of sentence. * src/jdk.jfr/share/classes/jdk/jfr/events/X509ValidationEvent.java 47: remove blank line * test/jdk/jdk/security/logging/TestTLSHandshakeLog.java 45 l.addExpected("SunJSSE Test Serivce"); Is that a typo? "Serivce" * test/jdk/jdk/security/logging/TestX509ValidationLog.java 54: remove blank line * test/lib/jdk/test/lib/security/SSLSocketTest.java Why is this file included? It looks like a duplicate of SSLSocketTemplate. --Sean On 11/6/18 3:46 AM, Se?n Coffey wrote: > With JDK-8203629 now pushed, I've re-based my patch on latest jdk/jdk code. > > Some modifications also made based on off-thread suggestions : > > src/java.base/share/classes/java/security/Security.java > > * Only record JDK security properties for now (i.e. those in > java.security conf file) > ? - we can consider a new event to record non-JDK security events if > demand comes about > ? - new event renamed to *Jdk*SecurityPropertyModificationEvent > > src/java.base/share/classes/sun/security/x509/X509CertImpl.java > > * Use hashCode() equality test for storing certs in List. > > Tests updated to capture these changes > > src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java > > > * Verify that self signed certs exercise the modified code paths > > I've added new test functionality to test use of self signed cert. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v7/webrev/ > > Regards, > Sean. > > On 17/10/18 11:25, Se?n Coffey wrote: >> I'd like to re-boot this review. I've been working with Erik off >> thread who's been helping with code and test design. >> >> Some of the main changes worthy of highlighting : >> >> * Separate out the tests for JFR and Logger events >> * Rename some events >> * Normalize the data view for X509ValidationEvent (old event name : >> CertChainEvent) >> * Introduce CertificateSerialNumber type to make use of the >> @Relational JFR annotation. >> * Keep calls for JFR event operations local to call site to optimize >> jvm compilation >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v6/webrev/ >> >> This code is dependent on the JDK-8203629 enhancement being integrated. >> >> Regards, >> Sean. >> >> On 10/07/18 13:50, Se?n Coffey wrote: >>> Erik, >>> >>> After some trial edits, I'm not so sure if moving the event & logger >>> commit code into the class where it's used works too well after all. >>> >>> In the code you suggested, there's an assumption that calls such as >>> EventHelper.certificateChain(..) are low cost. While that might be >>> the case here, it's something we can't always assume. It's called >>> once for the JFR operation and once for the Logger operation. That >>> pattern multiplies itself further in other Events. i.e. set up and >>> assign the variables for a JFR event without knowing whether they'll >>> be needed again for the Logger call. We could work around it by >>> setting up some local variables and re-using them in the Logger code >>> but then, we're back to where we were. The current EventHelper design >>> eliminates this problem and also helps to abstract the >>> recording/logging functionality away from the functionality of the >>> class itself. >>> >>> It also becomes a problem where we record events in multiple >>> different classes (e.g. SecurityPropertyEvent). While we could leave >>> the code in EventHelper for this case, we then have a mixed design >>> pattern. >>> >>> Are you ok with leaving as is for now? A future wish might be one >>> where JFR would handle Logger via its own framework/API in a future >>> JDK release. >>> >>> I've removed the variable names using underscore. Also optimized some >>> variable assignments in X509Impl.commitEvent(..) >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ >>> >>> regards, >>> Sean. >>> >>> On 09/07/2018 18:01, Se?n Coffey wrote: >>>> Erik, >>>> >>>> Thanks for reviewing. Comments inline.. >>>> >>>> On 09/07/18 17:21, Erik Gahlin wrote: >>>>> Thanks Sean. >>>>> >>>>> Some feedback on the code in the security libraries. >>>>> >>>>> - We should use camel case naming convention for variables (not >>>>> underscore). >>>> Sure. I see two offending variable names which I'll fix up. >>>>> >>>>> - Looking at sun/security/ssl/Finished.java, >>>>> >>>>> I wonder if it wouldn't be less code and more easy to read, if we >>>>> would commit the event in a local private function and then use the >>>>> EventHelper class for common functionality. >>>> I'm fine with your suggested approach. I figured that tucking the >>>> recording/logging logic away in a helper class also had benefits but >>>> I'll re-factor to your suggested style unless I hear objections. >>>> >>>> regards, >>>> Sean. >>>> >>> >> > From weijun.wang at oracle.com Wed Nov 14 00:56:57 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 14 Nov 2018 08:56:57 +0800 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <564a9a5a-352e-d21f-ec84-feb6562adcf1@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> <564a9a5a-352e-d21f-ec84-feb6562adcf1@oracle.com> Message-ID: Thanks. Please also take a look at the release note at https://bugs.openjdk.java.net/browse/JDK-8213821. --Max > On Nov 13, 2018, at 11:02 PM, Adam Petcher wrote: > > This change looks good to me. Thanks. > From weijun.wang at oracle.com Wed Nov 14 01:11:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 14 Nov 2018 09:11:40 +0800 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> Message-ID: Confused. Aren't all Security properties security-related? This is not about normal system properties. And the method name in the latest webrev is "isSecurityProperty" without the "JDK" word. I assume this means you don't care about the difference between SE properties and JDK properties. --Max > On Nov 14, 2018, at 2:53 AM, Sean Mullan wrote: > > * src/java.base/share/classes/java/security/Security.java > > The isJdkSecurityProperty method could return false positives, for example there may be a non-JDK property starting with "security.". I was thinking it would be better to put all the JDK property names in a HashSet which is populated by the static initialize() method, and only if event logging is enabled. Then setProperty can just check if the property name is in this set. From weijun.wang at oracle.com Wed Nov 14 10:07:55 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 14 Nov 2018 18:07:55 +0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> Message-ID: The CSR is re-opened. It is now focusing on -keyalg only. Please take a review: https://bugs.openjdk.java.net/browse/JDK-8212111 Thanks Max > On Nov 7, 2018, at 11:51 PM, Weijun Wang wrote: > > Oops, I take this back. The CSR needs more update. > > Sorry if you have already start reading it. > > Thanks > Max > > >> On Nov 7, 2018, at 9:27 AM, Weijun Wang wrote: >> >> After some discussion, we decided to cover -keysize and -sigalg in this deprecation process too. >> >> Please review the updated CSR at >> >> https://bugs.openjdk.java.net/browse/JDK-8212111 >> >> No webrev available yet. >> >> Thanks >> Max >> >> >>> On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: >>> >>> Please review the code change and CSR for >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 >>> >>> at >>> >>> webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 >>> >>> When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. >>> >>> A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. >>> >>> A Mach5 job on tier1 and tier2 running now. >>> >>> Thanks >>> Max >>> >> > From sibabrata.sahoo at oracle.com Wed Nov 14 10:21:02 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 14 Nov 2018 02:21:02 -0800 (PST) Subject: [12] RFR: 8211787: javax/net/ssl/TLSCommon/TLSTest.java throws java.net.SocketTimeoutException: Read timed out Message-ID: <902e63af-16ca-40f0-a818-c500953ab66d@default> Hi Xuelei, Please review a minor fix for, JBS: https://bugs.openjdk.java.net/browse/JDK-8211787 Webrev: http://cr.openjdk.java.net/~ssahoo/8211787/webrev.00/ The original intention to "setSoTimeout()" is on serverSocket where the server will fail with timeout if it exceed certain amount of time before accepting a client connection. But by mistake it was set on wrong socket object which is created from accept() and causing a timeout if the InputStream exceed certain amount of time. I have corrected to setSoTimeout() to be set through serverSocket only. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Nov 14 13:06:05 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 14 Nov 2018 08:06:05 -0500 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> Message-ID: On 11/13/18 8:11 PM, Weijun Wang wrote: > Confused. Aren't all Security properties security-related? This is not about normal system properties. Although probably not that common, an application could create their own security properties, ex: Security.setProperty("security.myPassword", "abc123"); We want to avoid logging those. We just want to record changes to the JDK security properties. > And the method name in the latest webrev is "isSecurityProperty" without the "JDK" word. I assume this means you don't care about the difference between SE properties and JDK properties. Hmm, I was reviewing v7, and the name was changed in v8. I think isJdkSecurityProperty method is a better name. --Sean > > --Max > >> On Nov 14, 2018, at 2:53 AM, Sean Mullan wrote: >> >> * src/java.base/share/classes/java/security/Security.java >> >> The isJdkSecurityProperty method could return false positives, for example there may be a non-JDK property starting with "security.". I was thinking it would be better to put all the JDK property names in a HashSet which is populated by the static initialize() method, and only if event logging is enabled. Then setProperty can just check if the property name is in this set. > From sean.mullan at oracle.com Wed Nov 14 13:15:41 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 14 Nov 2018 08:15:41 -0500 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> Message-ID: <92a56f91-f556-acef-8889-415fd16c6991@oracle.com> On 11/13/18 1:53 PM, Sean Mullan wrote: > * src/java.base/share/classes/sun/security/x509/X509CertImpl.java > > ?158???? // Event recording cache list > ?159???? private List recordedCerts; > > Shouldn't this be static? Otherwise each certificate would have it's own > instance and duplicates would not be detected. Thinking more about this, this List has the potential to contain a lot of entries if there are many certificates and there is no way to control the size. It might be better to leverage the existing in-memory certificate cache in sun/security/provider/X509Factory.java: private static final Cache certCache = Cache.newSoftMemoryCache(750); Could you look into moving the code from X509CertImpl to X509Factory instead? In engineGenerateCertificate, you could do the commit only if it is added to the cache: try { byte[] encoding = readOneBlock(is); if (encoding != null) { X509CertImpl cert = getFromCache(certCache, encoding); if (cert != null) { return cert; } cert = new X509CertImpl(encoding); addToCache(certCache, cert.getEncodedInternal(), cert); commitEvent(); return cert; This way you could leverage the same cache. Duplicates could get recorded but only if the constraints on the cache are exceeded. This seems like a fair tradeoff. --Sean From sgehwolf at redhat.com Wed Nov 14 14:49:12 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 14 Nov 2018 15:49:12 +0100 Subject: Problems with AES-GCM native acceleration In-Reply-To: References: Message-ID: <92a16009b9e047eacf102b006bc0612bac4a2cfb.camel@redhat.com> Dropping hotspot-dev and adding security-dev. On Wed, 2018-11-14 at 14:39 +0200, Gidon Gershinsky wrote: > Hi, > > We are working on an encryption mechanism at the Apache Parquet - > that will enable efficient analytics on encrypted data by frameworks > such as Apache Spark. > https://github.com/apache/parquet-format/blob/encryption/Encryption.md > https://www.slideshare.net/databricks/efficient-spark-analytics-on-encrypted-data-with-gidon-gershinsky > > We came across an AES-related issue in the Java HostSpot engine that > looks like a substantial problem for us in both Spark and Parquet > workloads. The bug report had been accepted a while ago: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8201633 > > The fix should hopefully be rather straightforward though. > Could you help us with that? I have a couple of small samples > reproducing the problem. > > (If I'm writing to a wrong mailing list - I apologize, please point > me in the right direction). > > Cheers, Gidon. From xuelei.fan at oracle.com Wed Nov 14 16:19:51 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 14 Nov 2018 08:19:51 -0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> Message-ID: I may want to have the warning message with more explicit guide to cleanup the warning. For example: Warning: No -keyalg option. The default key algorithm ... Otherwise, looks fine to me. I added myself as the reviewer. Thanks, Xuelei On 11/14/2018 2:07 AM, Weijun Wang wrote: > The CSR is re-opened. It is now focusing on -keyalg only. Please take a review: > > https://bugs.openjdk.java.net/browse/JDK-8212111 > > Thanks > Max > >> On Nov 7, 2018, at 11:51 PM, Weijun Wang wrote: >> >> Oops, I take this back. The CSR needs more update. >> >> Sorry if you have already start reading it. >> >> Thanks >> Max >> >> >>> On Nov 7, 2018, at 9:27 AM, Weijun Wang wrote: >>> >>> After some discussion, we decided to cover -keysize and -sigalg in this deprecation process too. >>> >>> Please review the updated CSR at >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212111 >>> >>> No webrev available yet. >>> >>> Thanks >>> Max >>> >>> >>>> On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: >>>> >>>> Please review the code change and CSR for >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 >>>> >>>> at >>>> >>>> webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 >>>> >>>> When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. >>>> >>>> A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. >>>> >>>> A Mach5 job on tier1 and tier2 running now. >>>> >>>> Thanks >>>> Max >>>> >>> >> > From xuelei.fan at oracle.com Wed Nov 14 16:23:44 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 14 Nov 2018 08:23:44 -0800 Subject: [12] RFR: 8211787: javax/net/ssl/TLSCommon/TLSTest.java throws java.net.SocketTimeoutException: Read timed out In-Reply-To: <902e63af-16ca-40f0-a818-c500953ab66d@default> References: <902e63af-16ca-40f0-a818-c500953ab66d@default> Message-ID: Looks fine to me. Thanks, Xuelei On 11/14/2018 2:21 AM, Sibabrata Sahoo wrote: > Hi Xuelei, > > Please review a minor fix for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211787 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8211787/webrev.00/ > > The original intention to ?setSoTimeout()? is on serverSocket where the > server will fail with timeout if it exceed certain amount of time before > accepting a client connection. But by mistake it was set on wrong socket > object which is created from accept() and causing a timeout if the > InputStream exceed certain amount of time. I have corrected to > setSoTimeout() to be set through serverSocket only. > > Thanks, > > Siba > From adam.petcher at oracle.com Wed Nov 14 16:41:01 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 14 Nov 2018 11:41:01 -0500 Subject: Problems with AES-GCM native acceleration In-Reply-To: <92a16009b9e047eacf102b006bc0612bac4a2cfb.camel@redhat.com> References: <92a16009b9e047eacf102b006bc0612bac4a2cfb.camel@redhat.com> Message-ID: <1b1fe9e4-ad71-7d48-13eb-48dbe267962e@oracle.com> I'm adding back in hotspot-dev, because this is a somewhat tricky topic related to intrinsics and JIT. Hopefully, a Hotspot expert can correct anything that I say below that is wrong, and suggest any solutions that I missed. The AES acceleration is implemented in a HotSpot intrinsic. In order for it to kick in, the code must be JIT compiled by the VM. As I understand it, this only happens to some particular method after it has been called a certain number of times. The rules that determine this number are somewhat complicated, but I think you can guarantee JIT in the default configuration by calling a method 10,000 times. The doFinal method calls the update method, so either one should trigger the acceleration as long as you call it enough. Breaking the message up into smaller chunks and calling update on each one works only because it ends up calling the update method more. You should be able to trigger the acceleration by calling doFinal more, too. The reason why the workaround doesn't work with decryption is that the decryption routine buffers the ciphertext and then decrypts it all at the end. So calling update multiple times and then calling doFinal at the end is essentially the same as calling doFinal once with the entire ciphertext. So here are some solutions that you may want to try: 1) In your benchmark, run at least 10,000 "warmup" iterations of whatever you are trying to do at the beginning, without timing it. This is a good idea for benchmarks, anyway. If it helps, you can try using smaller buffers in your "warmup" phase in order to get it to complete faster. 2) Try -XX:CompileThreshold=(some number smaller than 10000) as an argument to java. This will make JIT kick in sooner across the board. Obviously, this should be done carefully in production, since it will impact the performance of the entire program. 3) I haven't tried this, but running with an AOTed java.base module may also help. See the section titled "Steps to generate and use an AOT library for the java.base module" in the AOT JEP[1]. "Fixing" this issue in the JDK is non-trivial, because it gets into the behavior of the VM and JIT. I don't really like the idea of modifying doFinal (to break up the operation into multiple update calls) or modifying the decryption operation (to decrypt immediately and buffer plaintext) in order to work around this issue. Perhaps there is a better way for the VM to handle cases like this, in which a method is not called often, but the interpreted execution takes a long time to complete when it is called. Perhaps a VM expert will have some additional thoughts here. [1] https://openjdk.java.net/jeps/295 On 11/14/2018 9:49 AM, Severin Gehwolf wrote: > Dropping hotspot-dev and adding security-dev. > > On Wed, 2018-11-14 at 14:39 +0200, Gidon Gershinsky wrote: >> Hi, >> >> We are working on an encryption mechanism at the Apache Parquet - >> that will enable efficient analytics on encrypted data by frameworks >> such as Apache Spark. >> https://github.com/apache/parquet-format/blob/encryption/Encryption.md >> https://www.slideshare.net/databricks/efficient-spark-analytics-on-encrypted-data-with-gidon-gershinsky >> >> We came across an AES-related issue in the Java HostSpot engine that >> looks like a substantial problem for us in both Spark and Parquet >> workloads. The bug report had been accepted a while ago: >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8201633 >> >> The fix should hopefully be rather straightforward though. >> Could you help us with that? I have a couple of small samples >> reproducing the problem. >> >> (If I'm writing to a wrong mailing list - I apologize, please point >> me in the right direction). >> >> Cheers, Gidon. From xuelei.fan at oracle.com Wed Nov 14 16:59:44 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 14 Nov 2018 08:59:44 -0800 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 Message-ID: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> Hi, Please review this simple update: http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ The default value for the maximum number of entries in the SSL session cache (SSLSessionContext.getSessionCacheSize()) is infinite now. In the request, the default value is updated to 20480 for performance consideration. For the detailed behavior update, please refer to CSR: https://bugs.openjdk.java.net/browse/JDK-8213577 Thanks, Xuelei From jamil.j.nimeh at oracle.com Wed Nov 14 17:16:16 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 14 Nov 2018 09:16:16 -0800 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> Message-ID: Hi Xuelei, The fix looks fine to me.? I think it would be good to have an else branch off of the check on line 205 so any < 0 value has a warning log entry stating that an invalid value was detected and the cache is getting set to DEFAULT_MAX_CACHE_SIZE. --Jamil On 11/14/2018 8:59 AM, Xuelei Fan wrote: > Hi, > > Please review this simple update: > ??? http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ > > The default value for the maximum number of entries in the SSL session > cache (SSLSessionContext.getSessionCacheSize()) is infinite now.? In > the request, the default value is updated to 20480 for performance > consideration. > > For the detailed behavior update, please refer to CSR: > ??? https://bugs.openjdk.java.net/browse/JDK-8213577 > > Thanks, > Xuelei From vladimir.kozlov at oracle.com Wed Nov 14 17:56:33 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Nov 2018 09:56:33 -0800 Subject: Problems with AES-GCM native acceleration In-Reply-To: References: Message-ID: CCing to core-libs and security. Based on last comment corresponding java code may need to be re-factored. It is not simple. To trigger x64 AES instructions usage early (before JIT compilation kicks in) we may consider call optimized code from Interpreter similar to CRC32 code. It is also very big investment. Regards, Vladimir On 11/14/18 4:39 AM, Gidon Gershinsky wrote: > Hi, > > We are working on an encryption mechanism at the Apache?Parquet - that will enable efficient analytics on encrypted data > by?frameworks such as Apache Spark. > https://github.com/apache/parquet-format/blob/encryption/Encryption.md > https://www.slideshare.net/databricks/efficient-spark-analytics-on-encrypted-data-with-gidon-gershinsky > > We came across an AES-related issue in the Java HostSpot?engine?that looks like a substantial problem for us in both > Spark and Parquet workloads.?The bug report had been accepted a while ago: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8201633 > > The fix should hopefully be rather straightforward though. Could?you?help us with that? I have a couple of small samples > reproducing the problem. > > (If I'm writing to a wrong mailing list - I apologize, please point me in?the right direction). > > Cheers, Gidon. From xuelei.fan at oracle.com Wed Nov 14 19:00:29 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 14 Nov 2018 11:00:29 -0800 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> Message-ID: On 11/14/2018 9:16 AM, Jamil Nimeh wrote: > Hi Xuelei, > > The fix looks fine to me.? I think it would be good to have an else > branch off of the check on line 205 so any < 0 value has a warning log > entry stating that an invalid value was detected and the cache is > getting set to DEFAULT_MAX_CACHE_SIZE. > Good point! I updated with warnings of invalid property: http://cr.openjdk.java.net/~xuelei/8210985/webrev.01/ Xuelei > --Jamil > > On 11/14/2018 8:59 AM, Xuelei Fan wrote: >> Hi, >> >> Please review this simple update: >> ??? http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ >> >> The default value for the maximum number of entries in the SSL session >> cache (SSLSessionContext.getSessionCacheSize()) is infinite now.? In >> the request, the default value is updated to 20480 for performance >> consideration. >> >> For the detailed behavior update, please refer to CSR: >> ??? https://bugs.openjdk.java.net/browse/JDK-8213577 >> >> Thanks, >> Xuelei > From adam.petcher at oracle.com Wed Nov 14 19:53:05 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 14 Nov 2018 14:53:05 -0500 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> <564a9a5a-352e-d21f-ec84-feb6562adcf1@oracle.com> Message-ID: <4bc04440-2b58-a993-db3e-1c488b001b67@oracle.com> This looks good to me, though I made a couple of trivial editorial changes. It's fine as is, but you may want to consider using secp384r1 instead of brainpool256r1 in your example. I worry that people will experiment with the new feature using your example, and then we'll get bug tickets because the resulting keystore doesn't work with TLS. On 11/13/2018 7:56 PM, Weijun Wang wrote: > Thanks. Please also take a look at the release note at https://bugs.openjdk.java.net/browse/JDK-8213821. > > --Max > >> On Nov 13, 2018, at 11:02 PM, Adam Petcher wrote: >> >> This change looks good to me. Thanks. >> From sean.coffey at oracle.com Wed Nov 14 21:09:55 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 14 Nov 2018 21:09:55 +0000 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> Message-ID: Hi Sean, comments inline.. On 13/11/2018 18:53, Sean Mullan wrote: > Looking good, a couple of comments/questions: > > * src/java.base/share/classes/java/security/Security.java > > The isJdkSecurityProperty method could return false positives, for > example there may be a non-JDK property starting with "security.". I > was thinking it would be better to put all the JDK property names in a > HashSet which is populated by the static initialize() method, and only > if event logging is enabled. Then setProperty can just check if the > property name is in this set. after further discussion, we've decided to log all properties operated on via Security.setProperty(String, String). It think it makes sense. The contents of a JFR recording should always be treated as sensitive. Keep in mind also that these new JFR Events will be off by default. > > * src/java.base/share/classes/sun/security/x509/X509CertImpl.java Good points here. I've taken on board your suggestion to move this code logic to the sun/security/provider/X509Factory.java class as per your later email suggestion. > 45???????? l.addExpected("SunJSSE Test Serivce"); > > Is that a typo? "Serivce" > That's a typo in the test certificate details. We should fix it up via another bug record. > * test/jdk/jdk/security/logging/TestX509ValidationLog.java > > 54: remove blank line > > * test/lib/jdk/test/lib/security/SSLSocketTest.java > > Why is this file included? It looks like a duplicate of > SSLSocketTemplate. Yes - it's almost identical to SSLSocketTemplate except that SSLSocketTemplate doesn't belong to a package. I had a hard time incorporating its use into the jtreg tests via the @lib syntax. I think it's best if we open another JBS issue to migrate other uses of SSLSocketTemplate to jdk.test.lib.security.SSLSocketTemplate I've cleaned up the various typo/syntax issues that you've highlighted also. http://cr.openjdk.java.net/~coffeys/webrev.8148188.v9/webrev/index.html regards, Sean. > The rest of my comments are mostly minor stuff, and nits: > > * > src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java > > 245???????? if(xve.shouldCommit() || EventHelper.isLoggingSecurity()) { > > add space before "(xve" > > * src/java.base/share/classes/sun/security/ssl/Finished.java > > 1097 } > > indent > > 1098???????????? if(event.shouldCommit()) { > > add space before "(event" > > * src/java.base/share/classes/sun/security/x509/X509CertImpl.java > > update copyright > > * src/java.base/share/classes/jdk/internal/event/EventHelper.java > > 35? * A helper class to have events logged to a JDK Event Logger > > Add '.' at end of sentence. > > * src/java.base/share/classes/jdk/internal/event/TLSHandshakeEvent.java > > 38: remove blank line > > * src/java.base/share/classes/jdk/internal/event/X509ValidationEvent.java > > 30? * used in X509 cert path validation > > Add '.' at end of sentence. > > * src/jdk.jfr/share/classes/jdk/jfr/events/X509ValidationEvent.java > > 47: remove blank line > > * test/jdk/jdk/security/logging/TestTLSHandshakeLog.java > > > --Sean > > > On 11/6/18 3:46 AM, Se?n Coffey wrote: >> With JDK-8203629 now pushed, I've re-based my patch on latest jdk/jdk >> code. >> >> Some modifications also made based on off-thread suggestions : >> >> src/java.base/share/classes/java/security/Security.java >> >> * Only record JDK security properties for now (i.e. those in >> java.security conf file) >> ?? - we can consider a new event to record non-JDK security events if >> demand comes about >> ?? - new event renamed to *Jdk*SecurityPropertyModificationEvent >> >> src/java.base/share/classes/sun/security/x509/X509CertImpl.java >> >> * Use hashCode() equality test for storing certs in List. >> >> Tests updated to capture these changes >> >> src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java >> >> >> * Verify that self signed certs exercise the modified code paths >> >> I've added new test functionality to test use of self signed cert. >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v7/webrev/ >> >> Regards, >> Sean. >> >> On 17/10/18 11:25, Se?n Coffey wrote: >>> I'd like to re-boot this review. I've been working with Erik off >>> thread who's been helping with code and test design. >>> >>> Some of the main changes worthy of highlighting : >>> >>> * Separate out the tests for JFR and Logger events >>> * Rename some events >>> * Normalize the data view for X509ValidationEvent (old event name : >>> CertChainEvent) >>> * Introduce CertificateSerialNumber type to make use of the >>> @Relational JFR annotation. >>> * Keep calls for JFR event operations local to call site to optimize >>> jvm compilation >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v6/webrev/ >>> >>> This code is dependent on the JDK-8203629 enhancement being integrated. >>> >>> Regards, >>> Sean. >>> >>> On 10/07/18 13:50, Se?n Coffey wrote: >>>> Erik, >>>> >>>> After some trial edits, I'm not so sure if moving the event & >>>> logger commit code into the class where it's used works too well >>>> after all. >>>> >>>> In the code you suggested, there's an assumption that calls such as >>>> EventHelper.certificateChain(..) are low cost. While that might be >>>> the case here, it's something we can't always assume. It's called >>>> once for the JFR operation and once for the Logger operation. That >>>> pattern multiplies itself further in other Events. i.e. set up and >>>> assign the variables for a JFR event without knowing whether >>>> they'll be needed again for the Logger call. We could work around >>>> it by setting up some local variables and re-using them in the >>>> Logger code but then, we're back to where we were. The current >>>> EventHelper design eliminates this problem and also helps to >>>> abstract the recording/logging functionality away from the >>>> functionality of the class itself. >>>> >>>> It also becomes a problem where we record events in multiple >>>> different classes (e.g. SecurityPropertyEvent). While we could >>>> leave the code in EventHelper for this case, we then have a mixed >>>> design pattern. >>>> >>>> Are you ok with leaving as is for now? A future wish might be one >>>> where JFR would handle Logger via its own framework/API in a future >>>> JDK release. >>>> >>>> I've removed the variable names using underscore. Also optimized >>>> some variable assignments in X509Impl.commitEvent(..) >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >>>> On 09/07/2018 18:01, Se?n Coffey wrote: >>>>> Erik, >>>>> >>>>> Thanks for reviewing. Comments inline.. >>>>> >>>>> On 09/07/18 17:21, Erik Gahlin wrote: >>>>>> Thanks Sean. >>>>>> >>>>>> Some feedback on the code in the security libraries. >>>>>> >>>>>> - We should use camel case naming convention for variables (not >>>>>> underscore). >>>>> Sure. I see two offending variable names which I'll fix up. >>>>>> >>>>>> - Looking at sun/security/ssl/Finished.java, >>>>>> >>>>>> I wonder if it wouldn't be less code and more easy to read, if we >>>>>> would commit the event in a local private function and then use >>>>>> the EventHelper class for common functionality. >>>>> I'm fine with your suggested approach. I figured that tucking the >>>>> recording/logging logic away in a helper class also had benefits >>>>> but I'll re-factor to your suggested style unless I hear objections. >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>> >>> >> From sean.coffey at oracle.com Wed Nov 14 21:11:58 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 14 Nov 2018 21:11:58 +0000 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> Message-ID: <3f5ad2ca-0e27-4874-22d9-c9c66434a360@oracle.com> Thanks for the comments Weijun. As per other review thread, I'm now recording all properties set via Security.setProperty(String, String). regards, Sean. On 14/11/2018 01:11, Weijun Wang wrote: > Confused. Aren't all Security properties security-related? This is not about normal system properties. > > And the method name in the latest webrev is "isSecurityProperty" without the "JDK" word. I assume this means you don't care about the difference between SE properties and JDK properties. > > --Max From sean.mullan at oracle.com Wed Nov 14 21:29:27 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 14 Nov 2018 16:29:27 -0500 Subject: RFR 8213363: X25519 private key PKCS#8 encoding/decoding is incorrect In-Reply-To: <39ab9a36-6aff-a363-793a-a160d5b77f2e@oracle.com> References: <39ab9a36-6aff-a363-793a-a160d5b77f2e@oracle.com> Message-ID: The fix and the CSR look good. Please also add a release note. --Sean On 11/8/18 11:51 AM, Adam Petcher wrote: > Oops. And the JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8213363 > > > On 11/8/2018 11:43 AM, Adam Petcher wrote: >> webrev: http://cr.openjdk.java.net/~apetcher/8213363/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8213493 >> >> This change fixes a bug related to the encoded format of X25519/X448 >> private keys. The new code will not preserve compatibility with the >> improperly-formatted keys produced by the existing code. I expect the >> compatibility impact of this change to be minimal, as described in the >> CSR ticket. >> > From sean.mullan at oracle.com Wed Nov 14 21:55:13 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 14 Nov 2018 16:55:13 -0500 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> Message-ID: <0f19dc4b-6b65-7a22-6b3f-ab0b1dd95010@oracle.com> For 12, I think we should also document the group names in the std. alg names document so we have somewhere to point to for what names can be specified, otherwise users will be guessing. So I targeted this to 12: https://bugs.openjdk.java.net/browse/JDK-8210755 --Sean On 11/11/18 8:08 PM, Weijun Wang wrote: > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8213400/webrev.01/ > > Please review again. > > I've removed the change to CurveDB and NamedCurve. The test now simply looks at key.getParams().toString(). This is implementation dependent but it works within OpenJDK. > > No change on other files. > > I filed https://bugs.openjdk.java.net/browse/JDK-8213719 for the double BD issue. > > Thanks > Max > > >> On Nov 9, 2018, at 11:33 PM, Adam Petcher wrote: >> >> On 11/8/2018 10:30 PM, Weijun Wang wrote: >> >>>> On Nov 9, 2018, at 12:28 AM, Adam Petcher wrote: >>>> >>>> On 11/8/2018 8:10 AM, Weijun Wang wrote: >>>> >>>>> - CurveDB.java: >>>>> >>>>> - add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD, >>>>> + add("sect163r2 [NIST B-163]", "1.3.132.0.15", B, >>>>> >>>>> All other NIST B-*** curves do not have BD. This should have been a typo. >>>> I think this will change the default 163-bit curve from sect163r2 to sect163k1. We shouldn't change these defaults without a compelling reason. >>> I think this is a bug, as there should not be 2 curves with the same field size both having BD. >>> >>> I can file another bug on this. Maybe it needs it own CSR. >> >> Yes, it's probably a bug/typo. You can also fix it by changing sect163k1 from BD to B, since this won't change the behavior (though this would need to be tested). But I wouldn't worry about it. You can create a separate ticket if you like, but I would expect that fixing this is very low priority. The current behavior may even be correct (or at least "as intended"), and this is just a code cleanup issue. >> >>>>> - NamedCurve.java: >>>>> >>>>> A new field commonNames added, which is used by the new GroupName.java test. >>>> I don't see why this is necessary. The test is using this list of common names to make sure the correct named curve is used. Why not just check the value returned by NamedCurve.getName() against the expected (canonical) name of the curve? Or check the OID? >>> NamedCurve.getName() returns "secp256r1 [NIST P-256, X9.62 prime256v1]". >>> >>> I don't want to canonicalize the name (how? returning NamedCurve.getName()?) or use an OID. The test is about making sure the curve used matches the one user specified. What if I am making the same error inside keytool and this canonicalization or string-to-oid method? >>> >>> >> >> I think what I am suggesting is map from common name to canonical name or OID in the test. Then you can test that the correct common name is used, and that the mapping from common name to curve is correct. If you don't want to write out this map, then you can implement it by looking up the common name in the EC AlgorithmParameters, and then converting to an ECParameterSpec. This just moves the complexity from CurveDB to the test, but I think that is better. >> >> Though I don't have very strong feelings about this. Perhaps the list of common names in the NamedCurve will be useful for other things. If you prefer it the way that it is, then I am okay with it. > From sean.mullan at oracle.com Wed Nov 14 22:16:28 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 14 Nov 2018 17:16:28 -0500 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> Message-ID: <2b2398d7-ceda-4d9a-cd03-f21d73bc163b@oracle.com> On 11/14/18 5:07 AM, Weijun Wang wrote: > The CSR is re-opened. It is now focusing on -keyalg only. Please take a review: > > https://bugs.openjdk.java.net/browse/JDK-8212111 I think the CSR should also include an example of the informational text showing what algs and size were used. Looks good otherwise. --Sean > > Thanks > Max > >> On Nov 7, 2018, at 11:51 PM, Weijun Wang wrote: >> >> Oops, I take this back. The CSR needs more update. >> >> Sorry if you have already start reading it. >> >> Thanks >> Max >> >> >>> On Nov 7, 2018, at 9:27 AM, Weijun Wang wrote: >>> >>> After some discussion, we decided to cover -keysize and -sigalg in this deprecation process too. >>> >>> Please review the updated CSR at >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212111 >>> >>> No webrev available yet. >>> >>> Thanks >>> Max >>> >>> >>>> On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: >>>> >>>> Please review the code change and CSR for >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 >>>> >>>> at >>>> >>>> webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 >>>> >>>> When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. >>>> >>>> A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. >>>> >>>> A Mach5 job on tier1 and tier2 running now. >>>> >>>> Thanks >>>> Max >>>> >>> >> > From jonathan.gibbons at oracle.com Wed Nov 14 22:27:47 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 14 Nov 2018 14:27:47 -0800 Subject: FYI: new javadoc tag to document system properties Message-ID: <27d8d3ed-143b-dbcb-0ad2-d904f54db1d7@oracle.com> This is an FYI to announce some initial, long-overdue support in javadoc for documenting system properties (JDK-5076751). Currently, system properties are just documented using ad-hoc narrative text, which is fine if you know where to look for any given property. JDK 12 introduces a new inline javadoc tag, {@systemProperty /property-name/} which can be used to "declare" the name of a system property. You can use this tag as a drop-in replacement for the plain-text property name; it will have no overt effect on the narrative text, but it will cause the property name to be put into the search index and the A-Z index. Thus, property names will become searchable, to allow users to easily find the definition of any such system property. Adding support into javadoc is only part of the story. Now that the support is in javadoc, we want to update the API documentation, so that the documentation is updated for all Java SE and JDK system properties. Where should the tag be used?? The tag should be used in the text of the defining instance of the property.? This is where the characteristics of the system property are described, which may include information like: "what is the property for", "how and when is it set", "can it be modified", and so on. For example, it could be used in the docs for System.getProperties [1] or Networking Properties [2] In general, it should -not- be used in situations that merely refer to the system property by name.? For example, the docs for Path.toAbsolutePath [3] make a reference to the system property user.dir, but that is not a definition of the property. Going forward, in future releases, we expect to explore some enhancements to this feature. Here are some of the ideas that have been suggested: * Create a "summary page" that lists all the system properties. This would be somewhat similar to the current top-level "Constant Values" page. * Add information regarding the "scope" of the definition: is it defined by the Java SE specification, or JDK, or JavaFX, etc. This information could be used to organize the content on the summary page. * Update @see and {@link} to be able to refer to system properties. * Allow a short description to be included in the {@systemProperty} tag. This text could be included in the search index, the A-Z index, and the summary page. -- Jon [1]: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/System.html#getProperties() [2]: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/doc-files/net-properties.html [3]: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#toAbsolutePath() -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Nov 14 22:34:22 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 14 Nov 2018 14:34:22 -0800 Subject: FYI: new javadoc tag to document system properties In-Reply-To: <27d8d3ed-143b-dbcb-0ad2-d904f54db1d7@oracle.com> References: <27d8d3ed-143b-dbcb-0ad2-d904f54db1d7@oracle.com> Message-ID: <5BECA2EE.8080207@oracle.com> Hello, For future CSR requests involving system properties, please document the properties using these javadoc facilities. Thanks, -Joe On 11/14/2018 2:27 PM, Jonathan Gibbons wrote: > This is an FYI to announce some initial, long-overdue support in > javadoc for documenting system properties (JDK-5076751). > > Currently, system properties are just documented using ad-hoc > narrative text, which is fine if you know where to look for any given > property. > > JDK 12 introduces a new inline javadoc tag, {@systemProperty > /property-name/} which can be used to "declare" the name of a system > property. You can use this tag as a drop-in replacement for the > plain-text property name; it will have no overt effect on the > narrative text, but it will cause the property name to be put into the > search index and the A-Z index. Thus, property names will become > searchable, to allow users to easily find the definition of any such > system property. > > Adding support into javadoc is only part of the story. Now that the > support is in javadoc, we want to update the API documentation, so > that the documentation is updated for all Java SE and JDK system > properties. > > Where should the tag be used? The tag should be used in the text of > the defining instance of the property. This is where the > characteristics of the system property are described, which may > include information like: "what is the property for", "how and when is > it set", "can it be modified", and so on. For example, it could be > used in the docs for System.getProperties [1] or Networking Properties > [2] In general, it should -not- be used in situations that merely > refer to the system property by name. For example, the docs for > Path.toAbsolutePath [3] make a reference to the system property > user.dir, but that is not a definition of the property. > > Going forward, in future releases, we expect to explore some > enhancements to this feature. Here are some of the ideas that have > been suggested: > > * Create a "summary page" that lists all the system properties. This > would be somewhat similar to the current top-level "Constant Values" > page. > * Add information regarding the "scope" of the definition: is it > defined by the Java SE specification, or JDK, or JavaFX, etc. This > information could be used to organize the content on the summary page. > * Update @see and {@link} to be able to refer to system properties. > * Allow a short description to be included in the {@systemProperty} > tag. This text could be included in the search index, the A-Z index, > and the summary page. > > -- Jon > > > [1]: > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/System.html#getProperties() > [2]: > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/doc-files/net-properties.html > [3]: > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#toAbsolutePath() > > From weijun.wang at oracle.com Thu Nov 15 01:19:56 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 15 Nov 2018 09:19:56 +0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: <2b2398d7-ceda-4d9a-cd03-f21d73bc163b@oracle.com> References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> <2b2398d7-ceda-4d9a-cd03-f21d73bc163b@oracle.com> Message-ID: <8688672F-A601-4B71-81D3-7B2EFDAEDCFD@oracle.com> Thanks to Xuelei and Sean. I added your recommended words and proposed the CSR. > On Nov 15, 2018, at 6:16 AM, Sean Mullan wrote: > > On 11/14/18 5:07 AM, Weijun Wang wrote: >> The CSR is re-opened. It is now focusing on -keyalg only. Please take a review: >> https://bugs.openjdk.java.net/browse/JDK-8212111 > > I think the CSR should also include an example of the informational text showing what algs and size were used. Looks good otherwise. > > --Sean > >> Thanks >> Max >>> On Nov 7, 2018, at 11:51 PM, Weijun Wang wrote: >>> >>> Oops, I take this back. The CSR needs more update. >>> >>> Sorry if you have already start reading it. >>> >>> Thanks >>> Max >>> >>> >>>> On Nov 7, 2018, at 9:27 AM, Weijun Wang wrote: >>>> >>>> After some discussion, we decided to cover -keysize and -sigalg in this deprecation process too. >>>> >>>> Please review the updated CSR at >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8212111 >>>> >>>> No webrev available yet. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: >>>>> >>>>> Please review the code change and CSR for >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 >>>>> >>>>> at >>>>> >>>>> webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 >>>>> >>>>> When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. >>>>> >>>>> A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. >>>>> >>>>> A Mach5 job on tier1 and tier2 running now. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>> >>> From weijun.wang at oracle.com Thu Nov 15 01:24:15 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 15 Nov 2018 09:24:15 +0800 Subject: RFR 8213400: Support choosing curve name in keytool keypair generation In-Reply-To: <4bc04440-2b58-a993-db3e-1c488b001b67@oracle.com> References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com> <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com> <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com> <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com> <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com> <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com> <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com> <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com> <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com> <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com> <564a9a5a-352e-d21f-ec84-feb6562adcf1@oracle.com> <4bc04440-2b58-a993-db3e-1c488b001b67@oracle.com> Message-ID: > On Nov 15, 2018, at 3:53 AM, Adam Petcher wrote: > > This looks good to me, though I made a couple of trivial editorial changes. It's fine as is, but you may want to consider using secp384r1 instead of brainpool256r1 in your example. I worry that people will experiment with the new feature using your example, and then we'll get bug tickets because the resulting keystore doesn't work with TLS. This is exactly the advice I need from an expert. However, secp384r1 is already the default choice for `-keysize 384`. Do you have another recommendation that has to be set with `-groupname`? Thanks Max > > On 11/13/2018 7:56 PM, Weijun Wang wrote: >> Thanks. Please also take a look at the release note at https://bugs.openjdk.java.net/browse/JDK-8213821. >> >> --Max >> >>> On Nov 13, 2018, at 11:02 PM, Adam Petcher wrote: >>> >>> This change looks good to me. Thanks. >>> From anthony.scarpino at oracle.com Thu Nov 15 01:33:27 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 14 Nov 2018 17:33:27 -0800 Subject: Problems with AES-GCM native acceleration In-Reply-To: <1b1fe9e4-ad71-7d48-13eb-48dbe267962e@oracle.com> References: <92a16009b9e047eacf102b006bc0612bac4a2cfb.camel@redhat.com> <1b1fe9e4-ad71-7d48-13eb-48dbe267962e@oracle.com> Message-ID: <864a763d-0d67-d894-234c-fbbef78e0320@oracle.com> I agree with Adam that this is more of a tuning issue and not a problem with the crypto. Sending multiple updates is a hack. I've been aware of this bug for a while and I do not understand why this is a significant problem. The stackoverflow comments say it takes 50 seconds to trigger the intrinsic. If this is a long running server application slowness for the first 50 seconds is trivial. For smaller operations, those are commonly small transactions, not decrypting a 3GB file. If it cannot be resolved by commandline options and this is occurring in a real world situation, please explain it fully. If this is only for benchmarking, then that's not a real world situation. Tony On 11/14/18 8:41 AM, Adam Petcher wrote: > I'm adding back in hotspot-dev, because this is a somewhat tricky topic > related to intrinsics and JIT. Hopefully, a Hotspot expert can correct > anything that I say below that is wrong, and suggest any solutions that > I missed. > > The AES acceleration is implemented in a HotSpot intrinsic. In order for > it to kick in, the code must be JIT compiled by the VM. As I understand > it, this only happens to some particular method after it has been called > a certain number of times. The rules that determine this number are > somewhat complicated, but I think you can guarantee JIT in the default > configuration by calling a method 10,000 times. > > The doFinal method calls the update method, so either one should trigger > the acceleration as long as you call it enough. Breaking the message up > into smaller chunks and calling update on each one works only because it > ends up calling the update method more. You should be able to trigger > the acceleration by calling doFinal more, too. > > The reason why the workaround doesn't work with decryption is that the > decryption routine buffers the ciphertext and then decrypts it all at > the end. So calling update multiple times and then calling doFinal at > the end is essentially the same as calling doFinal once with the entire > ciphertext. > > So here are some solutions that you may want to try: > > 1) In your benchmark, run at least 10,000 "warmup" iterations of > whatever you are trying to do at the beginning, without timing it. This > is a good idea for benchmarks, anyway. If it helps, you can try using > smaller buffers in your "warmup" phase in order to get it to complete > faster. > > 2) Try -XX:CompileThreshold=(some number smaller than 10000) as an > argument to java. This will make JIT kick in sooner across the board. > Obviously, this should be done carefully in production, since it will > impact the performance of the entire program. > > 3) I haven't tried this, but running with an AOTed java.base module may > also help. See the section titled "Steps to generate and use an AOT > library for the java.base module" in the AOT JEP[1]. > > "Fixing" this issue in the JDK is non-trivial, because it gets into the > behavior of the VM and JIT. I don't really like the idea of modifying > doFinal (to break up the operation into multiple update calls) or > modifying the decryption operation (to decrypt immediately and buffer > plaintext) in order to work around this issue. Perhaps there is a better > way for the VM to handle cases like this, in which a method is not > called often, but the interpreted execution takes a long time to > complete when it is called. Perhaps a VM expert will have some > additional thoughts here. > > [1] https://openjdk.java.net/jeps/295 > > On 11/14/2018 9:49 AM, Severin Gehwolf wrote: >> Dropping hotspot-dev and adding security-dev. >> >> On Wed, 2018-11-14 at 14:39 +0200, Gidon Gershinsky wrote: >>> Hi, >>> >>> We are working on an encryption mechanism at the Apache Parquet - >>> that will enable efficient analytics on encrypted data by frameworks >>> such as Apache Spark. >>> https://github.com/apache/parquet-format/blob/encryption/Encryption.md >>> https://www.slideshare.net/databricks/efficient-spark-analytics-on-encrypted-data-with-gidon-gershinsky >>> >>> >>> We came across an AES-related issue in the Java HostSpot engine that >>> looks like a substantial problem for us in both Spark and Parquet >>> workloads. The bug report had been accepted a while ago: >>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8201633 >>> >>> The fix should hopefully be rather straightforward though. >>> Could you help us with that? I have a couple of small samples >>> reproducing the problem. >>> >>> (If I'm writing to a wrong mailing list - I apologize, please point >>> me in the right direction). >>> >>> Cheers, Gidon. From gg5070 at gmail.com Thu Nov 15 10:42:37 2018 From: gg5070 at gmail.com (Gidon Gershinsky) Date: Thu, 15 Nov 2018 12:42:37 +0200 Subject: Problems with AES-GCM native acceleration In-Reply-To: <864a763d-0d67-d894-234c-fbbef78e0320@oracle.com> References: <92a16009b9e047eacf102b006bc0612bac4a2cfb.camel@redhat.com> <1b1fe9e4-ad71-7d48-13eb-48dbe267962e@oracle.com> <864a763d-0d67-d894-234c-fbbef78e0320@oracle.com> Message-ID: Hi all, Thanks for the prompt feedback on this stuff, appreciated. 1. Analytic queries are often interactive or one-off. A data scientist would get an on-demand notebook with a Spark cluster (spawned as a K8s pod), and run a number of queries. The cluster will be then closed either explicitly, or after a timeout. This is done both for a better resource utilization, and for security reasons. Re-using JVM for another user/tenant might leak the sensitive data and encryption keys, kept in the JVM memory. I'm not saying its the only way to solve this, there are architectures based on a long running service. But this short-lived approach is real and needs to be addressed. Even if the data scientist keeps the cluster alive for a few hours - having to wait a long time for the results of the first few queries (because the decryption is not warmed up yet) is a problem, since the things are interactive and expected to be done in real time. 2. Analytics and AI workloads work with ~ 64MB blocks; sometimes, they are broken in ~1MB pieces (like in Parquet). Still, taking even the minimal size of 1MB, and waiting the 10,000 rounds to get the decryption acceleration, means we process the first ~10GB at a slow rate. Sounds harsh. Both in absolute numbers, and in comparison to ENcryption, which kicks in after warming up with say 1KB chunks (created by breaking 1MB blocks into many update calls) - meaning ~1,000x faster than DEcryption. 3. Adam has mentioned an approach of "modifying the decryption operation (to decrypt immediately and buffer plaintext)" (in a negative context, though :). To me, it looks like a sound solution. However, I don't know how much effort does it require (?) - but it makes decryption implementation similar to encryption, and solves the problem at hand. Maybe there are other options, though. 4. AOT sounds interesting, I'll check it out. But its experimental for now. Moreover, both AOT and command line options require extra care in production, as correctly pointed out below. They will be a hard sell in real production environments. The same is true (or even worse) for manual warm-up with a repeated decryption of small blocks. This is indeed a benchmarking hack, I don't see it been used in production. Having the decryption optimized in the HotSpot engine would be ideal. Cheers, Gidon. On Thu, Nov 15, 2018 at 3:33 AM Anthony Scarpino < anthony.scarpino at oracle.com> wrote: > I agree with Adam that this is more of a tuning issue and not a problem > with the crypto. Sending multiple updates is a hack. > > I've been aware of this bug for a while and I do not understand why this > is a significant problem. The stackoverflow comments say it takes 50 > seconds to trigger the intrinsic. If this is a long running server > application slowness for the first 50 seconds is trivial. For smaller > operations, those are commonly small transactions, not decrypting a 3GB > file. > > If it cannot be resolved by commandline options and this is occurring in > a real world situation, please explain it fully. If this is only for > benchmarking, then that's not a real world situation. > > Tony > > On 11/14/18 8:41 AM, Adam Petcher wrote: > > I'm adding back in hotspot-dev, because this is a somewhat tricky topic > > related to intrinsics and JIT. Hopefully, a Hotspot expert can correct > > anything that I say below that is wrong, and suggest any solutions that > > I missed. > > > > The AES acceleration is implemented in a HotSpot intrinsic. In order for > > it to kick in, the code must be JIT compiled by the VM. As I understand > > it, this only happens to some particular method after it has been called > > a certain number of times. The rules that determine this number are > > somewhat complicated, but I think you can guarantee JIT in the default > > configuration by calling a method 10,000 times. > > > > The doFinal method calls the update method, so either one should trigger > > the acceleration as long as you call it enough. Breaking the message up > > into smaller chunks and calling update on each one works only because it > > ends up calling the update method more. You should be able to trigger > > the acceleration by calling doFinal more, too. > > > > The reason why the workaround doesn't work with decryption is that the > > decryption routine buffers the ciphertext and then decrypts it all at > > the end. So calling update multiple times and then calling doFinal at > > the end is essentially the same as calling doFinal once with the entire > > ciphertext. > > > > So here are some solutions that you may want to try: > > > > 1) In your benchmark, run at least 10,000 "warmup" iterations of > > whatever you are trying to do at the beginning, without timing it. This > > is a good idea for benchmarks, anyway. If it helps, you can try using > > smaller buffers in your "warmup" phase in order to get it to complete > > faster. > > > > 2) Try -XX:CompileThreshold=(some number smaller than 10000) as an > > argument to java. This will make JIT kick in sooner across the board. > > Obviously, this should be done carefully in production, since it will > > impact the performance of the entire program. > > > > 3) I haven't tried this, but running with an AOTed java.base module may > > also help. See the section titled "Steps to generate and use an AOT > > library for the java.base module" in the AOT JEP[1]. > > > > "Fixing" this issue in the JDK is non-trivial, because it gets into the > > behavior of the VM and JIT. I don't really like the idea of modifying > > doFinal (to break up the operation into multiple update calls) or > > modifying the decryption operation (to decrypt immediately and buffer > > plaintext) in order to work around this issue. Perhaps there is a better > > way for the VM to handle cases like this, in which a method is not > > called often, but the interpreted execution takes a long time to > > complete when it is called. Perhaps a VM expert will have some > > additional thoughts here. > > > > [1] https://openjdk.java.net/jeps/295 > > > > On 11/14/2018 9:49 AM, Severin Gehwolf wrote: > >> Dropping hotspot-dev and adding security-dev. > >> > >> On Wed, 2018-11-14 at 14:39 +0200, Gidon Gershinsky wrote: > >>> Hi, > >>> > >>> We are working on an encryption mechanism at the Apache Parquet - > >>> that will enable efficient analytics on encrypted data by frameworks > >>> such as Apache Spark. > >>> https://github.com/apache/parquet-format/blob/encryption/Encryption.md > >>> > https://www.slideshare.net/databricks/efficient-spark-analytics-on-encrypted-data-with-gidon-gershinsky > >>> > >>> > >>> We came across an AES-related issue in the Java HostSpot engine that > >>> looks like a substantial problem for us in both Spark and Parquet > >>> workloads. The bug report had been accepted a while ago: > >>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8201633 > >>> > >>> The fix should hopefully be rather straightforward though. > >>> Could you help us with that? I have a couple of small samples > >>> reproducing the problem. > >>> > >>> (If I'm writing to a wrong mailing list - I apologize, please point > >>> me in the right direction). > >>> > >>> Cheers, Gidon. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Thu Nov 15 15:33:00 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 15 Nov 2018 10:33:00 -0500 Subject: RFR 8213363: X25519 private key PKCS#8 encoding/decoding is incorrect In-Reply-To: References: <39ab9a36-6aff-a363-793a-a160d5b77f2e@oracle.com> Message-ID: Done[1]. Please take a look when you have a chance. [1] https://bugs.openjdk.java.net/browse/JDK-8213946 On 11/14/2018 4:29 PM, Sean Mullan wrote: > The fix and the CSR look good. Please also add a release note. > > --Sean > > On 11/8/18 11:51 AM, Adam Petcher wrote: >> Oops. And the JBS ticket: >> https://bugs.openjdk.java.net/browse/JDK-8213363 >> >> >> On 11/8/2018 11:43 AM, Adam Petcher wrote: >>> webrev: http://cr.openjdk.java.net/~apetcher/8213363/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8213493 >>> >>> This change fixes a bug related to the encoded format of X25519/X448 >>> private keys. The new code will not preserve compatibility with the >>> improperly-formatted keys produced by the existing code. I expect >>> the compatibility impact of this change to be minimal, as described >>> in the CSR ticket. >>> >> From weijun.wang at oracle.com Thu Nov 15 15:38:48 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 15 Nov 2018 23:38:48 +0800 Subject: RFR 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> Message-ID: Webrev updated at Asserts.assertTrue(pr.getAlgorithm().equals("RSA")); More refactorings: - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey. - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA. - CPublicKey and CPrivateKey now have a static of() method that can return a child instance. - CCipher renamed to CRSACipher. I realized there won't be CECCipher. Thanks Max > On Nov 7, 2018, at 12:13 AM, Weijun Wang wrote: > > Webrev updated at > > https://cr.openjdk.java.net/~weijun/8213009/webrev.00/ > > The subtask id is now used. > > The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back. > > Thanks > Max > >> On Oct 25, 2018, at 4:38 PM, Weijun Wang wrote: >> >> Please review the change at >> >> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >> >> (I will use a sub-task id for this change but currently JBS is down). >> >> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >> >> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >> >> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >> >> - Child class named "RSA" of CKeyPairGenerator. >> >> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >> >> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >> >> Noreg-cleanup. >> >> Thanks >> Max >> >> [1] https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier > From weijun.wang at oracle.com Thu Nov 15 15:40:56 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 15 Nov 2018 23:40:56 +0800 Subject: RFR 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> Message-ID: Oops, my copy/paste sequence goes wrong. > On Nov 15, 2018, at 11:38 PM, Weijun Wang wrote: > > Webrev updated at > https://cr.openjdk.java.net/~weijun/8213009/webrev.01/ > > More refactorings: > > - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey. > > - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA. > > - CPublicKey and CPrivateKey now have a static of() method that can return a child instance. > > - CCipher renamed to CRSACipher. I realized there won't be CECCipher. > > Thanks > Max > > >> On Nov 7, 2018, at 12:13 AM, Weijun Wang wrote: >> >> Webrev updated at >> >> https://cr.openjdk.java.net/~weijun/8213009/webrev.00/ >> >> The subtask id is now used. >> >> The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back. >> >> Thanks >> Max >> >>> On Oct 25, 2018, at 4:38 PM, Weijun Wang wrote: >>> >>> Please review the change at >>> >>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >>> >>> (I will use a sub-task id for this change but currently JBS is down). >>> >>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >>> >>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >>> >>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >>> >>> - Child class named "RSA" of CKeyPairGenerator. >>> >>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >>> >>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >>> >>> Noreg-cleanup. >>> >>> Thanks >>> Max >>> >>> [1] https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier >> > From xuelei.fan at oracle.com Thu Nov 15 16:17:55 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 15 Nov 2018 08:17:55 -0800 Subject: FYI: new javadoc tag to document system properties In-Reply-To: <27d8d3ed-143b-dbcb-0ad2-d904f54db1d7@oracle.com> References: <27d8d3ed-143b-dbcb-0ad2-d904f54db1d7@oracle.com> Message-ID: <9e6bf54a-3193-fcb9-a523-9411ae83e952@oracle.com> In JCE and JSSE, the public APIs definition (javax.net.ssl) and the internal implementation (sun.security.ssl) are separated. The system property can be defined in the internal implementation classes. I think we should add the @systemProperty on the public APIs, right? The public API class and the implementation class may be not a one-to-one map. Multiple public APIs may be impacted by the system property. How to handle such cases? Thanks, Xuelei On 11/14/2018 2:27 PM, Jonathan Gibbons wrote: > This is an FYI to announce some initial, long-overdue support in javadoc > for documenting system properties (JDK-5076751). > > Currently, system properties are just documented using ad-hoc narrative > text, which is fine if you know where to look for any given property. > > JDK 12 introduces a new inline javadoc tag, {@systemProperty > /property-name/} which can be used to "declare" the name of a system > property. You can use this tag as a drop-in replacement for the > plain-text property name; it will have no overt effect on the narrative > text, but it will cause the property name to be put into the search > index and the A-Z index. Thus, property names will become searchable, to > allow users to easily find the definition of any such system property. > > Adding support into javadoc is only part of the story. Now that the > support is in javadoc, we want to update the API documentation, so that > the documentation is updated for all Java SE and JDK system properties. > > Where should the tag be used?? The tag should be used in the text of the > defining instance of the property.? This is where the characteristics of > the system property are described, which may include information like: > "what is the property for", "how and when is it set", "can it be > modified", and so on. For example, it could be used in the docs for > System.getProperties [1] or Networking Properties [2] In general, it > should -not- be used in situations that merely refer to the system > property by name.? For example, the docs for Path.toAbsolutePath [3] > make a reference to the system property user.dir, but that is not a > definition of the property. > > Going forward, in future releases, we expect to explore some > enhancements to this feature. Here are some of the ideas that have been > suggested: > > ?* Create a "summary page" that lists all the system properties. This > ?? would be somewhat similar to the current top-level "Constant Values" > ?? page. > ?* Add information regarding the "scope" of the definition: is it > ?? defined by the Java SE specification, or JDK, or JavaFX, etc. This > ?? information could be used to organize the content on the summary page. > ?* Update @see and {@link} to be able to refer to system properties. > ?* Allow a short description to be included in the {@systemProperty} > ?? tag. This text could be included in the search index, the A-Z index, > ?? and the summary page. > > -- Jon > > > [1]: > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/System.html#getProperties() > > [2]: > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/doc-files/net-properties.html > > [3]: > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#toAbsolutePath() > > > From sean.coffey at oracle.com Thu Nov 15 16:35:42 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 15 Nov 2018 16:35:42 +0000 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() Message-ID: A simple enhancement to override toString() for javax.crypto.Cipher class https://bugs.openjdk.java.net/browse/JDK-8210838 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ regards, Sean. From sean.mullan at oracle.com Thu Nov 15 19:55:00 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 15 Nov 2018 14:55:00 -0500 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> Message-ID: This is a good opportunity to document the javax.net.ssl.sessionCacheSize system property in the SSLSessionContext API (and use the new @systemProperty tag) in an @implNote, for example: /** * Returns the size of the cache used for storing * SSLSession objects grouped under this * SSLSessionContext. * * @implNote The JDK implementation returns the cache size as set by * the {@code setSessionCacheSize method}, or if not set, the value * of the {@systemProperty javax.net.ssl.sessionCacheSize} system * property. If neither is set, it returns a default value of 20480. * * @return size of the session cache; zero means there is no size limit. * @see #setSessionCacheSize */ public int getSessionCacheSize(); On 11/14/18 11:59 AM, Xuelei Fan wrote: > Hi, > > Please review this simple update: > ??? http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ > > The default value for the maximum number of entries in the SSL session > cache (SSLSessionContext.getSessionCacheSize()) is infinite now.? In the > request, the default value is updated to 20480 for performance > consideration. > > For the detailed behavior update, please refer to CSR: > ??? https://bugs.openjdk.java.net/browse/JDK-8213577 > > Thanks, > Xuelei From xuelei.fan at oracle.com Thu Nov 15 20:37:17 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 15 Nov 2018 12:37:17 -0800 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> Message-ID: Hi Sean, Are you OK if we do it later? I'm waiting for the @systemProperty tag, proposed within JDK-5076751. I will file a bug to use the tag for more cleanup. Thanks, Xuelei On 11/15/2018 11:55 AM, Sean Mullan wrote: > This is a good opportunity to document the > javax.net.ssl.sessionCacheSize system property in the SSLSessionContext > API (and use the new @systemProperty tag) in an @implNote, for example: > > ??? /** > ???? * Returns the size of the cache used for storing > ???? * SSLSession objects grouped under this > ???? * SSLSessionContext. > ???? * > ???? * @implNote The JDK implementation returns the cache size as set by > ???? * the {@code setSessionCacheSize method}, or if not set, the value > ???? * of the {@systemProperty javax.net.ssl.sessionCacheSize} system > ???? * property. If neither is set, it returns a default value of 20480. > ???? * > ???? * @return size of the session cache; zero means there is no size > limit. > ???? * @see #setSessionCacheSize > ???? */ > ??? public int getSessionCacheSize(); > > On 11/14/18 11:59 AM, Xuelei Fan wrote: >> Hi, >> >> Please review this simple update: >> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ >> >> The default value for the maximum number of entries in the SSL session >> cache (SSLSessionContext.getSessionCacheSize()) is infinite now.? In >> the request, the default value is updated to 20480 for performance >> consideration. >> >> For the detailed behavior update, please refer to CSR: >> ???? https://bugs.openjdk.java.net/browse/JDK-8213577 >> >> Thanks, >> Xuelei From weijun.wang at oracle.com Fri Nov 16 03:20:35 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 16 Nov 2018 11:20:35 +0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: <8688672F-A601-4B71-81D3-7B2EFDAEDCFD@oracle.com> References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> <2b2398d7-ceda-4d9a-cd03-f21d73bc163b@oracle.com> <8688672F-A601-4B71-81D3-7B2EFDAEDCFD@oracle.com> Message-ID: Would like also please review the release note here? https://bugs.openjdk.java.net/browse/JDK-8213965 I had thought about using RN-Deprecated but there is no API here. If you think it's better, I'll use it and also change all "obsolete" into "deprecate" in the description and title of the release note/CSR/bug. Thanks Max > On Nov 15, 2018, at 9:19 AM, Weijun Wang wrote: > > Thanks to Xuelei and Sean. I added your recommended words and proposed the CSR. > >> On Nov 15, 2018, at 6:16 AM, Sean Mullan wrote: >> >> On 11/14/18 5:07 AM, Weijun Wang wrote: >>> The CSR is re-opened. It is now focusing on -keyalg only. Please take a review: >>> https://bugs.openjdk.java.net/browse/JDK-8212111 >> >> I think the CSR should also include an example of the informational text showing what algs and size were used. Looks good otherwise. >> >> --Sean >> >>> Thanks >>> Max >>>> On Nov 7, 2018, at 11:51 PM, Weijun Wang wrote: >>>> >>>> Oops, I take this back. The CSR needs more update. >>>> >>>> Sorry if you have already start reading it. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> On Nov 7, 2018, at 9:27 AM, Weijun Wang wrote: >>>>> >>>>> After some discussion, we decided to cover -keysize and -sigalg in this deprecation process too. >>>>> >>>>> Please review the updated CSR at >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8212111 >>>>> >>>>> No webrev available yet. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>>> On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: >>>>>> >>>>>> Please review the code change and CSR for >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 >>>>>> >>>>>> at >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 >>>>>> >>>>>> When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. >>>>>> >>>>>> A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. >>>>>> >>>>>> A Mach5 job on tier1 and tier2 running now. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>> >>>> > From weijun.wang at oracle.com Fri Nov 16 03:35:15 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 16 Nov 2018 11:35:15 +0800 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() In-Reply-To: References: Message-ID: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> Signature's toString looks like public String toString() { String initState = ""; switch (state) { case UNINITIALIZED: initState = ""; break; case VERIFY: initState = ""; break; case SIGN: initState = ""; break; } return "Signature object: " + getAlgorithm() + initState; } Maybe you can add some similar info. In fact, it looks like you can extract the debug output at the end of each init() methods into a new toString() method. Thanks Max > On Nov 16, 2018, at 12:35 AM, Se?n Coffey wrote: > > A simple enhancement to override toString() for javax.crypto.Cipher class > > https://bugs.openjdk.java.net/browse/JDK-8210838 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ > > regards, > Sean. > From sean.coffey at oracle.com Fri Nov 16 09:54:28 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 16 Nov 2018 09:54:28 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 Message-ID: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> Looking to make an adjustment to DNSName constructor to help comply with RFC 1123 https://bugs.openjdk.java.net/browse/JDK-8213952 http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ regards, Sean. From ecki at zusammenkunft.net Fri Nov 16 12:40:07 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 16 Nov 2018 12:40:07 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> Message-ID: You could also add (a..b, false) and (.a, false), (a., false) to the testcases. I noticed that there are different types of Exception messages (DNS name, DNSName, DNS Name or name constrained, DNS name and SAN), would be good if all of them have the same keyword? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Se?n Coffey Gesendet: Freitag, November 16, 2018 12:25 PM An: OpenJDK Dev list Betreff: RFR: 8213952: Relax DNSName restriction as per RFC 1123 Looking to make an adjustment to DNSName constructor to help comply with RFC 1123 https://bugs.openjdk.java.net/browse/JDK-8213952 http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ regards, Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Fri Nov 16 14:04:28 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 16 Nov 2018 14:04:28 +0000 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() In-Reply-To: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> References: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> Message-ID: <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> That's a good example and point Max. How does this revision look ? http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ Regards, Sean. On 16/11/18 03:35, Weijun Wang wrote: > Signature's toString looks like > > public String toString() { > String initState = ""; > switch (state) { > case UNINITIALIZED: > initState = ""; > break; > case VERIFY: > initState = ""; > break; > case SIGN: > initState = ""; > break; > } > return "Signature object: " + getAlgorithm() + initState; > } > > Maybe you can add some similar info. > > In fact, it looks like you can extract the debug output at the end of each init() methods into a new toString() method. > > Thanks > Max > >> On Nov 16, 2018, at 12:35 AM, Se?n Coffey wrote: >> >> A simple enhancement to override toString() for javax.crypto.Cipher class >> >> https://bugs.openjdk.java.net/browse/JDK-8210838 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ >> >> regards, >> Sean. >> From goetz.lindenmaier at sap.com Fri Nov 16 14:07:07 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 16 Nov 2018 14:07:07 +0000 Subject: downport of JDK-8209965 / JDK-8210005 Message-ID: <066e1004c4bd4e9a86d30d545f971e15@sap.com> Hi, we have a user running into jdk-8209965. The downport change has been opened in August, but not yet been worked on. Will this be downported to jdk11u? If this is not being worked on by Oracle, I would request a downport. But I don't want to interfere with your work. https://bugs.openjdk.java.net/browse/JDK-8209965 https://bugs.openjdk.java.net/browse/JDK-8210005 Best regards, Goetz. From weijun.wang at oracle.com Fri Nov 16 14:19:37 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 16 Nov 2018 22:19:37 +0800 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() In-Reply-To: <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> References: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> Message-ID: Do you want to update the init() methods to make use of this new toString() output? This avoids duplicated code and we can even inline the getOpmodeString() method. --Max > On Nov 16, 2018, at 10:04 PM, Se?n Coffey wrote: > > That's a good example and point Max. How does this revision look ? > > http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ > > Regards, > Sean. > > On 16/11/18 03:35, Weijun Wang wrote: >> Signature's toString looks like >> >> public String toString() { >> String initState = ""; >> switch (state) { >> case UNINITIALIZED: >> initState = ""; >> break; >> case VERIFY: >> initState = ""; >> break; >> case SIGN: >> initState = ""; >> break; >> } >> return "Signature object: " + getAlgorithm() + initState; >> } >> >> Maybe you can add some similar info. >> >> In fact, it looks like you can extract the debug output at the end of each init() methods into a new toString() method. >> >> Thanks >> Max >> >>> On Nov 16, 2018, at 12:35 AM, Se?n Coffey wrote: >>> >>> A simple enhancement to override toString() for javax.crypto.Cipher class >>> >>> https://bugs.openjdk.java.net/browse/JDK-8210838 >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ >>> >>> regards, >>> Sean. >>> > From weijun.wang at oracle.com Fri Nov 16 14:35:45 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 16 Nov 2018 22:35:45 +0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option Message-ID: Please take a review at https://cr.openjdk.java.net/~weijun/8212003/webrev.00/ Here, a warning is added when -keyalg is not specified, and some informational text output that were only available in verbose mode is now always printed. Below are the exact output you will see after this change. Please note that we can only create DES SecretKey in JCEKS keystore. Also, depending on whether the subject is provided through -dname or entered interactively, the warning on the default -keyalg option appears in different places. In the interactive mode, it appears at the beginning so that user can exit earlier if the default -keyalg value is not preferred. $ keytool -genseckey -alias a -keystore jceks -storepass changeit -storetype jceks -keypass changeit Generated 56-bit DES secret key Warning: No -keyalg option. The default key algorithm (DES) is a legacy algorithm and is no longer recommended. In a subsequent release of the JDK, the default will be removed and the -keyalg option must be specified. The JCEKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore jceks -destkeystore jceks -deststoretype pkcs12". c $ keytool -genkeypair -alias c -keystore /tmp/p12 -storepass changeit Warning: No -keyalg option. The default key algorithm (DSA) is a legacy algorithm and is no longer recommended. In a subsequent release of the JDK, the default will be removed and the -keyalg option must be specified. What is your first and last name? [Unknown]: Duke What is the name of your organizational unit? [Unknown]: Java What is the name of your organization? [Unknown]: Oracle What is the name of your City or Locality? [Unknown]: Santa Clara What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US Is CN=Duke, OU=Java, O=Oracle, L=Santa Clara, ST=CA, C=US correct? [no]: yes Generating 2,048 bit DSA key pair and self-signed certificate (SHA256withDSA) with a validity of 90 days for: CN=Duke, OU=Java, O=Oracle, L=Santa Clara, ST=CA, C=US c $ keytool -genkeypair -alias d -keystore /tmp/p12 -storepass changeit -dname CN=A Generating 2,048 bit DSA key pair and self-signed certificate (SHA256withDSA) with a validity of 90 days for: CN=A Warning: No -keyalg option. The default key algorithm (DSA) is a legacy algorithm and is no longer recommended. In a subsequent release of the JDK, the default will be removed and the -keyalg option must be specified. Thanks Max From sean.coffey at oracle.com Fri Nov 16 15:31:54 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 16 Nov 2018 15:31:54 +0000 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> Message-ID: <43511665-c19d-70cc-f9fd-dbb805cd32cf@oracle.com> I've renamed the 'peerCertificateId' variable and label in TLSHandshakeEvent to 'certificateId'. This allows the event data to be co-displayed in JMC views which share the same type of data (@CertificateId). I've uploaded an example screenshot [1] I've also made an adjustment to the TestModuleEvents test to disregard the jdk.proxy1 module for test purposes. http://cr.openjdk.java.net/~coffeys/webrev.8148188.v10/webrev/ [1] http://cr.openjdk.java.net/~coffeys/jmc_screenshots/shared_selection_certificateId.png/Screenshot%20from%202018-11-16%2015%3a28%3a59.png Regards, Sean. On 14/11/18 21:09, Se?n Coffey wrote: > Hi Sean, > > comments inline.. > > On 13/11/2018 18:53, Sean Mullan wrote: >> Looking good, a couple of comments/questions: >> >> * src/java.base/share/classes/java/security/Security.java >> >> The isJdkSecurityProperty method could return false positives, for >> example there may be a non-JDK property starting with "security.". I >> was thinking it would be better to put all the JDK property names in >> a HashSet which is populated by the static initialize() method, and >> only if event logging is enabled. Then setProperty can just check if >> the property name is in this set. > after further discussion, we've decided to log all properties operated > on via Security.setProperty(String, String). It think it makes sense. > The contents of a JFR recording should always be treated as sensitive. > Keep in mind also that these new JFR Events will be off by default. >> >> * src/java.base/share/classes/sun/security/x509/X509CertImpl.java > Good points here. I've taken on board your suggestion to move this > code logic to the sun/security/provider/X509Factory.java class as per > your later email suggestion. > >> 45 l.addExpected("SunJSSE Test Serivce"); >> >> Is that a typo? "Serivce" >> > That's a typo in the test certificate details. We should fix it up via > another bug record. > >> * test/jdk/jdk/security/logging/TestX509ValidationLog.java >> >> 54: remove blank line >> >> * test/lib/jdk/test/lib/security/SSLSocketTest.java >> >> Why is this file included? It looks like a duplicate of >> SSLSocketTemplate. > Yes - it's almost identical to SSLSocketTemplate except that > SSLSocketTemplate doesn't belong to a package. I had a hard time > incorporating its use into the jtreg tests via the @lib syntax. I > think it's best if we open another JBS issue to migrate other uses of > SSLSocketTemplate to jdk.test.lib.security.SSLSocketTemplate > > I've cleaned up the various typo/syntax issues that you've highlighted > also. > http://cr.openjdk.java.net/~coffeys/webrev.8148188.v9/webrev/index.html > > regards, > Sean. > >> The rest of my comments are mostly minor stuff, and nits: >> >> * >> src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java >> >> 245 if(xve.shouldCommit() || EventHelper.isLoggingSecurity()) { >> >> add space before "(xve" >> >> * src/java.base/share/classes/sun/security/ssl/Finished.java >> >> 1097 } >> >> indent >> >> 1098 if(event.shouldCommit()) { >> >> add space before "(event" >> >> * src/java.base/share/classes/sun/security/x509/X509CertImpl.java >> >> update copyright >> >> * src/java.base/share/classes/jdk/internal/event/EventHelper.java >> >> 35 * A helper class to have events logged to a JDK Event Logger >> >> Add '.' at end of sentence. >> >> * src/java.base/share/classes/jdk/internal/event/TLSHandshakeEvent.java >> >> 38: remove blank line >> >> * >> src/java.base/share/classes/jdk/internal/event/X509ValidationEvent.java >> >> 30 * used in X509 cert path validation >> >> Add '.' at end of sentence. >> >> * src/jdk.jfr/share/classes/jdk/jfr/events/X509ValidationEvent.java >> >> 47: remove blank line >> >> * test/jdk/jdk/security/logging/TestTLSHandshakeLog.java >> >> >> --Sean >> >> >> On 11/6/18 3:46 AM, Se?n Coffey wrote: >>> With JDK-8203629 now pushed, I've re-based my patch on latest >>> jdk/jdk code. >>> >>> Some modifications also made based on off-thread suggestions : >>> >>> src/java.base/share/classes/java/security/Security.java >>> >>> * Only record JDK security properties for now (i.e. those in >>> java.security conf file) >>> - we can consider a new event to record non-JDK security events >>> if demand comes about >>> - new event renamed to *Jdk*SecurityPropertyModificationEvent >>> >>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java >>> >>> * Use hashCode() equality test for storing certs in List. >>> >>> Tests updated to capture these changes >>> >>> src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java >>> >>> >>> * Verify that self signed certs exercise the modified code paths >>> >>> I've added new test functionality to test use of self signed cert. >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v7/webrev/ >>> >>> Regards, >>> Sean. >>> >>> On 17/10/18 11:25, Se?n Coffey wrote: >>>> I'd like to re-boot this review. I've been working with Erik off >>>> thread who's been helping with code and test design. >>>> >>>> Some of the main changes worthy of highlighting : >>>> >>>> * Separate out the tests for JFR and Logger events >>>> * Rename some events >>>> * Normalize the data view for X509ValidationEvent (old event name : >>>> CertChainEvent) >>>> * Introduce CertificateSerialNumber type to make use of the >>>> @Relational JFR annotation. >>>> * Keep calls for JFR event operations local to call site to >>>> optimize jvm compilation >>>> >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v6/webrev/ >>>> >>>> This code is dependent on the JDK-8203629 enhancement being >>>> integrated. >>>> >>>> Regards, >>>> Sean. >>>> >>>> On 10/07/18 13:50, Se?n Coffey wrote: >>>>> Erik, >>>>> >>>>> After some trial edits, I'm not so sure if moving the event & >>>>> logger commit code into the class where it's used works too well >>>>> after all. >>>>> >>>>> In the code you suggested, there's an assumption that calls such >>>>> as EventHelper.certificateChain(..) are low cost. While that might >>>>> be the case here, it's something we can't always assume. It's >>>>> called once for the JFR operation and once for the Logger >>>>> operation. That pattern multiplies itself further in other Events. >>>>> i.e. set up and assign the variables for a JFR event without >>>>> knowing whether they'll be needed again for the Logger call. We >>>>> could work around it by setting up some local variables and >>>>> re-using them in the Logger code but then, we're back to where we >>>>> were. The current EventHelper design eliminates this problem and >>>>> also helps to abstract the recording/logging functionality away >>>>> from the functionality of the class itself. >>>>> >>>>> It also becomes a problem where we record events in multiple >>>>> different classes (e.g. SecurityPropertyEvent). While we could >>>>> leave the code in EventHelper for this case, we then have a mixed >>>>> design pattern. >>>>> >>>>> Are you ok with leaving as is for now? A future wish might be one >>>>> where JFR would handle Logger via its own framework/API in a >>>>> future JDK release. >>>>> >>>>> I've removed the variable names using underscore. Also optimized >>>>> some variable assignments in X509Impl.commitEvent(..) >>>>> >>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> On 09/07/2018 18:01, Se?n Coffey wrote: >>>>>> Erik, >>>>>> >>>>>> Thanks for reviewing. Comments inline.. >>>>>> >>>>>> On 09/07/18 17:21, Erik Gahlin wrote: >>>>>>> Thanks Sean. >>>>>>> >>>>>>> Some feedback on the code in the security libraries. >>>>>>> >>>>>>> - We should use camel case naming convention for variables (not >>>>>>> underscore). >>>>>> Sure. I see two offending variable names which I'll fix up. >>>>>>> >>>>>>> - Looking at sun/security/ssl/Finished.java, >>>>>>> >>>>>>> I wonder if it wouldn't be less code and more easy to read, if >>>>>>> we would commit the event in a local private function and then >>>>>>> use the EventHelper class for common functionality. >>>>>> I'm fine with your suggested approach. I figured that tucking the >>>>>> recording/logging logic away in a helper class also had benefits >>>>>> but I'll re-factor to your suggested style unless I hear objections. >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>> >>>> >>> > From sean.mullan at oracle.com Fri Nov 16 15:48:12 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Nov 2018 10:48:12 -0500 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> <2b2398d7-ceda-4d9a-cd03-f21d73bc163b@oracle.com> <8688672F-A601-4B71-81D3-7B2EFDAEDCFD@oracle.com> Message-ID: On 11/15/18 10:20 PM, Weijun Wang wrote: > Would like also please review the release note here? > > https://bugs.openjdk.java.net/browse/JDK-8213965 I made a few changes. I think it is important to also say that we will be removing support for the default values in a subsequent release. > > I had thought about using RN-Deprecated but there is no API here. If you think it's better, I'll use it and also change all "obsolete" into "deprecate" in the description and title of the release note/CSR/bug. I think "deprecate" is probably better, even though this isn't an API, because I think it is a better way to tell the user that it is not good to rely on the default values anymore. "Obsoleted" is probably ok too, but I don't hear it used much so it doesn't have the same meaning to me. --Sean > > Thanks > Max > >> On Nov 15, 2018, at 9:19 AM, Weijun Wang wrote: >> >> Thanks to Xuelei and Sean. I added your recommended words and proposed the CSR. >> >>> On Nov 15, 2018, at 6:16 AM, Sean Mullan wrote: >>> >>> On 11/14/18 5:07 AM, Weijun Wang wrote: >>>> The CSR is re-opened. It is now focusing on -keyalg only. Please take a review: >>>> https://bugs.openjdk.java.net/browse/JDK-8212111 >>> >>> I think the CSR should also include an example of the informational text showing what algs and size were used. Looks good otherwise. >>> >>> --Sean >>> >>>> Thanks >>>> Max >>>>> On Nov 7, 2018, at 11:51 PM, Weijun Wang wrote: >>>>> >>>>> Oops, I take this back. The CSR needs more update. >>>>> >>>>> Sorry if you have already start reading it. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>>> On Nov 7, 2018, at 9:27 AM, Weijun Wang wrote: >>>>>> >>>>>> After some discussion, we decided to cover -keysize and -sigalg in this deprecation process too. >>>>>> >>>>>> Please review the updated CSR at >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212111 >>>>>> >>>>>> No webrev available yet. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>>> On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: >>>>>>> >>>>>>> Please review the code change and CSR for >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 >>>>>>> >>>>>>> at >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 >>>>>>> >>>>>>> When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. >>>>>>> >>>>>>> A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. >>>>>>> >>>>>>> A Mach5 job on tier1 and tier2 running now. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>> >>>>> >> > From weijun.wang at oracle.com Fri Nov 16 16:01:52 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 17 Nov 2018 00:01:52 +0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> <080D8907-9F13-4C61-ADA5-CB11D19D2A2F@oracle.com> <2b2398d7-ceda-4d9a-cd03-f21d73bc163b@oracle.com> <8688672F-A601-4B71-81D3-7B2EFDAEDCFD@oracle.com> Message-ID: <0FE5EB8B-87A6-4880-82A3-B6F82662276D@oracle.com> > On Nov 16, 2018, at 11:48 PM, Sean Mullan wrote: > > On 11/15/18 10:20 PM, Weijun Wang wrote: >> Would like also please review the release note here? >> https://bugs.openjdk.java.net/browse/JDK-8213965 > > I made a few changes. I think it is important to also say that we will be removing support for the default values in a subsequent release. Thanks. > >> I had thought about using RN-Deprecated but there is no API here. If you think it's better, I'll use it and also change all "obsolete" into "deprecate" in the description and title of the release note/CSR/bug. > > I think "deprecate" is probably better, even though this isn't an API, because I think it is a better way to tell the user that it is not good to rely on the default values anymore. "Obsoleted" is probably ok too, but I don't hear it used much so it doesn't have the same meaning to me. I s/obsolete/deprecate/ everywhere. The webrev is also updated in place. --Max > > --Sean > >> Thanks >> Max >>> On Nov 15, 2018, at 9:19 AM, Weijun Wang wrote: >>> >>> Thanks to Xuelei and Sean. I added your recommended words and proposed the CSR. >>> >>>> On Nov 15, 2018, at 6:16 AM, Sean Mullan wrote: >>>> >>>> On 11/14/18 5:07 AM, Weijun Wang wrote: >>>>> The CSR is re-opened. It is now focusing on -keyalg only. Please take a review: >>>>> https://bugs.openjdk.java.net/browse/JDK-8212111 >>>> >>>> I think the CSR should also include an example of the informational text showing what algs and size were used. Looks good otherwise. >>>> >>>> --Sean >>>> >>>>> Thanks >>>>> Max >>>>>> On Nov 7, 2018, at 11:51 PM, Weijun Wang wrote: >>>>>> >>>>>> Oops, I take this back. The CSR needs more update. >>>>>> >>>>>> Sorry if you have already start reading it. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>>> On Nov 7, 2018, at 9:27 AM, Weijun Wang wrote: >>>>>>> >>>>>>> After some discussion, we decided to cover -keysize and -sigalg in this deprecation process too. >>>>>>> >>>>>>> Please review the updated CSR at >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8212111 >>>>>>> >>>>>>> No webrev available yet. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>>> On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: >>>>>>>> >>>>>>>> Please review the code change and CSR for >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 >>>>>>>> >>>>>>>> at >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 >>>>>>>> >>>>>>>> When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. >>>>>>>> >>>>>>>> A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. >>>>>>>> >>>>>>>> A Mach5 job on tier1 and tier2 running now. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>> >>>>>> >>> From sean.mullan at oracle.com Fri Nov 16 16:05:10 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Nov 2018 11:05:10 -0500 Subject: RFR 8213363: X25519 private key PKCS#8 encoding/decoding is incorrect In-Reply-To: References: <39ab9a36-6aff-a363-793a-a160d5b77f2e@oracle.com> Message-ID: On 11/15/18 10:33 AM, Adam Petcher wrote: > Done[1]. Please take a look when you have a chance. > > [1] https://bugs.openjdk.java.net/browse/JDK-8213946 Looks fine. --Sean > > On 11/14/2018 4:29 PM, Sean Mullan wrote: >> The fix and the CSR look good. Please also add a release note. >> >> --Sean >> >> On 11/8/18 11:51 AM, Adam Petcher wrote: >>> Oops. And the JBS ticket: >>> https://bugs.openjdk.java.net/browse/JDK-8213363 >>> >>> >>> On 11/8/2018 11:43 AM, Adam Petcher wrote: >>>> webrev: http://cr.openjdk.java.net/~apetcher/8213363/webrev.00/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8213493 >>>> >>>> This change fixes a bug related to the encoded format of X25519/X448 >>>> private keys. The new code will not preserve compatibility with the >>>> improperly-formatted keys produced by the existing code. I expect >>>> the compatibility impact of this change to be minimal, as described >>>> in the CSR ticket. >>>> >>> From sean.coffey at oracle.com Fri Nov 16 16:10:02 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 16 Nov 2018 16:10:02 +0000 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() In-Reply-To: References: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> Message-ID: <345dbea2-d6c6-ab72-8115-5e3bb5a1efa9@oracle.com> webrev updated! http://cr.openjdk.java.net/~coffeys/webrev.8210838.v3/webrev/ Regards, Sean. On 16/11/18 14:19, Weijun Wang wrote: > Do you want to update the init() methods to make use of this new toString() output? This avoids duplicated code and we can even inline the getOpmodeString() method. > > --Max > >> On Nov 16, 2018, at 10:04 PM, Se?n Coffey wrote: >> >> That's a good example and point Max. How does this revision look ? >> >> http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ >> >> Regards, >> Sean. >> >> On 16/11/18 03:35, Weijun Wang wrote: >>> Signature's toString looks like >>> >>> public String toString() { >>> String initState = ""; >>> switch (state) { >>> case UNINITIALIZED: >>> initState = ""; >>> break; >>> case VERIFY: >>> initState = ""; >>> break; >>> case SIGN: >>> initState = ""; >>> break; >>> } >>> return "Signature object: " + getAlgorithm() + initState; >>> } >>> >>> Maybe you can add some similar info. >>> >>> In fact, it looks like you can extract the debug output at the end of each init() methods into a new toString() method. >>> >>> Thanks >>> Max >>> >>>> On Nov 16, 2018, at 12:35 AM, Se?n Coffey wrote: >>>> >>>> A simple enhancement to override toString() for javax.crypto.Cipher class >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8210838 >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ >>>> >>>> regards, >>>> Sean. >>>> From sean.coffey at oracle.com Fri Nov 16 16:13:04 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 16 Nov 2018 16:13:04 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> Message-ID: <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> Thanks for the comments Bernd. comments inline.. On 16/11/18 12:40, Bernd Eckenfels wrote: > You could also add (a..b, false) and (.a, false), (a., false) to the > testcases. good point. test updated. > > I noticed that there are different types of Exception messages (DNS > name, DNSName, DNS Name or name constrained, DNS name and SAN), would > be good if all of them have the same keyword? I cleaned up some other references to DNSName in the sun.security.x509 package. I'm not sure what classes you were referencing the above examples from. new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ regards, Sean. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Se?n Coffey > *Gesendet:* Freitag, November 16, 2018 12:25 PM > *An:* OpenJDK Dev list > *Betreff:* RFR: 8213952: Relax DNSName restriction as per RFC 1123 > Looking to make an adjustment to DNSName constructor to help comply with > RFC 1123 > > https://bugs.openjdk.java.net/browse/JDK-8213952 > http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ > > regards, > Sean. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Nov 16 16:16:02 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Nov 2018 11:16:02 -0500 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() In-Reply-To: <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> References: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> Message-ID: <70c76a9c-43b0-a144-fe1d-5874abad0934@oracle.com> On 11/16/18 9:04 AM, Se?n Coffey wrote: > That's a good example and point Max. How does this revision look ? > > http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ 2832 * This implementation returns a String containing the transformation 2833 * used by this Cipher, the Cipher mode and the Cipher Provider. I would suggest rewording this as: "This implementation returns a String containing the transformation, mode, and provider of this Cipher." 2840 String m = "not initialized"; 2841 if (initialized) 2842 m = getOpmodeString(opmode); Or: String m = initialized ? getOpmodeString(opmode) : "not initialized"; Also, it might be worthwhile to use a StringBuilder if you think this method may be called often. --Sean > > Regards, > Sean. > > On 16/11/18 03:35, Weijun Wang wrote: >> Signature's toString looks like >> >> public String toString() { >> ???? String initState = ""; >> ???? switch (state) { >> ???? case UNINITIALIZED: >> ???????? initState = ""; >> ???????? break; >> ???? case VERIFY: >> ???????? initState = ""; >> ???????? break; >> ???? case SIGN: >> ???????? initState = ""; >> ???????? break; >> ???? } >> ???? return "Signature object: " + getAlgorithm() + initState; >> } >> >> Maybe you can add some similar info. >> >> In fact, it looks like you can extract the debug output at the end of >> each init() methods into a new toString() method. >> >> Thanks >> Max >> >>> On Nov 16, 2018, at 12:35 AM, Se?n Coffey >>> wrote: >>> >>> A simple enhancement to override toString() for javax.crypto.Cipher >>> class >>> >>> https://bugs.openjdk.java.net/browse/JDK-8210838 >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ >>> >>> regards, >>> Sean. >>> > From sean.mullan at oracle.com Fri Nov 16 16:19:41 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Nov 2018 11:19:41 -0500 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> Message-ID: On 11/15/18 3:37 PM, Xuelei Fan wrote: > Hi Sean, > > Are you OK if we do it later?? I'm waiting for the @systemProperty tag, > proposed within JDK-5076751.? I will file a bug to use the tag for more > cleanup. JDK-5076751 is completed and pushed to JDK 12, so you can use the new tag now. I think it would be easier to do it now, it seems pretty simple and that way there is no need to worry about it later. --Sean > > Thanks, > Xuelei > > On 11/15/2018 11:55 AM, Sean Mullan wrote: >> This is a good opportunity to document the >> javax.net.ssl.sessionCacheSize system property in the >> SSLSessionContext API (and use the new @systemProperty tag) in an >> @implNote, for example: >> >> ???? /** >> ????? * Returns the size of the cache used for storing >> ????? * SSLSession objects grouped under this >> ????? * SSLSessionContext. >> ????? * >> ????? * @implNote The JDK implementation returns the cache size as set by >> ????? * the {@code setSessionCacheSize method}, or if not set, the value >> ????? * of the {@systemProperty javax.net.ssl.sessionCacheSize} system >> ????? * property. If neither is set, it returns a default value of 20480. >> ????? * >> ????? * @return size of the session cache; zero means there is no size >> limit. >> ????? * @see #setSessionCacheSize >> ????? */ >> ???? public int getSessionCacheSize(); >> >> On 11/14/18 11:59 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review this simple update: >>> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ >>> >>> The default value for the maximum number of entries in the SSL >>> session cache (SSLSessionContext.getSessionCacheSize()) is infinite >>> now.? In the request, the default value is updated to 20480 for >>> performance consideration. >>> >>> For the detailed behavior update, please refer to CSR: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8213577 >>> >>> Thanks, >>> Xuelei From sean.coffey at oracle.com Fri Nov 16 16:35:29 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 16 Nov 2018 16:35:29 +0000 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() In-Reply-To: <70c76a9c-43b0-a144-fe1d-5874abad0934@oracle.com> References: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> <70c76a9c-43b0-a144-fe1d-5874abad0934@oracle.com> Message-ID: On 16/11/18 16:16, Sean Mullan wrote: > On 11/16/18 9:04 AM, Se?n Coffey wrote: >> That's a good example and point Max. How does this revision look ? >> >> http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ > > 2832 * This implementation returns a String containing the > transformation > 2833 * used by this Cipher, the Cipher mode and the Cipher Provider. > > I would suggest rewording this as: "This implementation returns a > String containing the transformation, mode, and provider of this Cipher." Good suggestion. Changed. > > 2840 String m = "not initialized"; > 2841 if (initialized) > 2842 m = getOpmodeString(opmode); > > Or: > > String m = initialized ? getOpmodeString(opmode) : "not initialized"; I've moved the switch expression into the toString() call now as per suggestion from Max. I've just seen that we should never have an unexpected opmode given the checkOpmode(int) method check. I've let an unexpected opmode register with "error" in the switch statement. // should never happen. webrev updated in place: http://cr.openjdk.java.net/~coffeys/webrev.8210838.v3/webrev/ regards, Sean. > > Also, it might be worthwhile to use a StringBuilder if you think this > method may be called often. > > --Sean > >> >> Regards, >> Sean. >> >> On 16/11/18 03:35, Weijun Wang wrote: >>> Signature's toString looks like >>> >>> public String toString() { >>> String initState = ""; >>> switch (state) { >>> case UNINITIALIZED: >>> initState = ""; >>> break; >>> case VERIFY: >>> initState = ""; >>> break; >>> case SIGN: >>> initState = ""; >>> break; >>> } >>> return "Signature object: " + getAlgorithm() + initState; >>> } >>> >>> Maybe you can add some similar info. >>> >>> In fact, it looks like you can extract the debug output at the end >>> of each init() methods into a new toString() method. >>> >>> Thanks >>> Max >>> >>>> On Nov 16, 2018, at 12:35 AM, Se?n Coffey >>>> wrote: >>>> >>>> A simple enhancement to override toString() for javax.crypto.Cipher >>>> class >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8210838 >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >> From sean.mullan at oracle.com Fri Nov 16 17:33:34 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Nov 2018 12:33:34 -0500 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() In-Reply-To: References: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> <70c76a9c-43b0-a144-fe1d-5874abad0934@oracle.com> Message-ID: <0ffbddf2-7ee6-90c2-5315-5142aeaf3fe2@oracle.com> Looks ok. If there are no disadvantages to using a StringBuilder, I would probably do that, since you are creating 4-5 separate Strings in the toString method. --Sean On 11/16/18 11:35 AM, Se?n Coffey wrote: > > On 16/11/18 16:16, Sean Mullan wrote: >> On 11/16/18 9:04 AM, Se?n Coffey wrote: >>> That's a good example and point Max. How does this revision look ? >>> >>> http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ >> >> 2832????? * This implementation returns a String containing the >> transformation >> 2833????? * used by this Cipher, the Cipher mode and the Cipher Provider. >> >> I would suggest rewording this as: "This implementation returns a >> String containing the transformation, mode, and provider of this Cipher." > Good suggestion. Changed. >> >> 2840???????? String m = "not initialized"; >> 2841???????? if (initialized) >> 2842???????????? m = getOpmodeString(opmode); >> >> Or: >> >> String m = initialized ? getOpmodeString(opmode) : "not initialized"; > I've moved the switch expression into the toString() call now as per > suggestion from Max. I've just > seen that we should never have an unexpected opmode given the > checkOpmode(int) method check. > I've let an unexpected opmode register with "error" in the switch > statement. // should never happen. > > webrev updated in place: > ?http://cr.openjdk.java.net/~coffeys/webrev.8210838.v3/webrev/ > > regards, > Sean. > >> >> Also, it might be worthwhile to use a StringBuilder if you think this >> method may be called often. >> >> --Sean >> >>> >>> Regards, >>> Sean. >>> >>> On 16/11/18 03:35, Weijun Wang wrote: >>>> Signature's toString looks like >>>> >>>> public String toString() { >>>> ???? String initState = ""; >>>> ???? switch (state) { >>>> ???? case UNINITIALIZED: >>>> ???????? initState = ""; >>>> ???????? break; >>>> ???? case VERIFY: >>>> ???????? initState = ""; >>>> ???????? break; >>>> ???? case SIGN: >>>> ???????? initState = ""; >>>> ???????? break; >>>> ???? } >>>> ???? return "Signature object: " + getAlgorithm() + initState; >>>> } >>>> >>>> Maybe you can add some similar info. >>>> >>>> In fact, it looks like you can extract the debug output at the end >>>> of each init() methods into a new toString() method. >>>> >>>> Thanks >>>> Max >>>> >>>>> On Nov 16, 2018, at 12:35 AM, Se?n Coffey >>>>> wrote: >>>>> >>>>> A simple enhancement to override toString() for javax.crypto.Cipher >>>>> class >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8210838 >>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ >>>>> >>>>> regards, >>>>> Sean. >>>>> >>> > From sean.coffey at oracle.com Fri Nov 16 17:56:14 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 16 Nov 2018 17:56:14 +0000 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() In-Reply-To: <0ffbddf2-7ee6-90c2-5315-5142aeaf3fe2@oracle.com> References: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> <70c76a9c-43b0-a144-fe1d-5874abad0934@oracle.com> <0ffbddf2-7ee6-90c2-5315-5142aeaf3fe2@oracle.com> Message-ID: <4a9fe64c-77b2-6580-e0eb-d9546f453190@oracle.com> Thanks Sean. StringBuilder use added : http://cr.openjdk.java.net/~coffeys/webrev.8210838.v4/webrev/ Regards, Sean. On 16/11/18 17:33, Sean Mullan wrote: > Looks ok. If there are no disadvantages to using a StringBuilder, I > would probably do that, since you are creating 4-5 separate Strings in > the toString method. > > --Sean > > On 11/16/18 11:35 AM, Se?n Coffey wrote: >> >> On 16/11/18 16:16, Sean Mullan wrote: >>> On 11/16/18 9:04 AM, Se?n Coffey wrote: >>>> That's a good example and point Max. How does this revision look ? >>>> >>>> http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ >>> >>> 2832 * This implementation returns a String containing the >>> transformation >>> 2833 * used by this Cipher, the Cipher mode and the Cipher >>> Provider. >>> >>> I would suggest rewording this as: "This implementation returns a >>> String containing the transformation, mode, and provider of this >>> Cipher." >> Good suggestion. Changed. >>> >>> 2840 String m = "not initialized"; >>> 2841 if (initialized) >>> 2842 m = getOpmodeString(opmode); >>> >>> Or: >>> >>> String m = initialized ? getOpmodeString(opmode) : "not initialized"; >> I've moved the switch expression into the toString() call now as per >> suggestion from Max. I've just >> seen that we should never have an unexpected opmode given the >> checkOpmode(int) method check. >> I've let an unexpected opmode register with "error" in the switch >> statement. // should never happen. >> >> webrev updated in place: >> http://cr.openjdk.java.net/~coffeys/webrev.8210838.v3/webrev/ >> >> regards, >> Sean. >> >>> >>> Also, it might be worthwhile to use a StringBuilder if you think >>> this method may be called often. >>> >>> --Sean >>> >>>> >>>> Regards, >>>> Sean. >>>> >>>> On 16/11/18 03:35, Weijun Wang wrote: >>>>> Signature's toString looks like >>>>> >>>>> public String toString() { >>>>> String initState = ""; >>>>> switch (state) { >>>>> case UNINITIALIZED: >>>>> initState = ""; >>>>> break; >>>>> case VERIFY: >>>>> initState = ""; >>>>> break; >>>>> case SIGN: >>>>> initState = ""; >>>>> break; >>>>> } >>>>> return "Signature object: " + getAlgorithm() + initState; >>>>> } >>>>> >>>>> Maybe you can add some similar info. >>>>> >>>>> In fact, it looks like you can extract the debug output at the end >>>>> of each init() methods into a new toString() method. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Nov 16, 2018, at 12:35 AM, Se?n Coffey >>>>>> wrote: >>>>>> >>>>>> A simple enhancement to override toString() for >>>>>> javax.crypto.Cipher class >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8210838 >>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>> >> From sean.mullan at oracle.com Fri Nov 16 18:12:17 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Nov 2018 13:12:17 -0500 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: <43511665-c19d-70cc-f9fd-dbb805cd32cf@oracle.com> References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> <43073e02-7e92-9e93-398d-d37a778a56d3@oracle.com> <477535a2-9345-b134-e5b8-4f86b60870ce@oracle.com> <43511665-c19d-70cc-f9fd-dbb805cd32cf@oracle.com> Message-ID: <090e901d-4977-f60d-5085-6e47a8f5c9af@oracle.com> Updated webrev looks good. --Sean On 11/16/18 10:31 AM, Se?n Coffey wrote: > I've renamed the 'peerCertificateId' variable and label in > TLSHandshakeEvent to 'certificateId'. This allows the event data to be > co-displayed in JMC views which share the same type of data > (@CertificateId). I've uploaded an example screenshot [1] > > I've also made an adjustment to the TestModuleEvents test to disregard > the jdk.proxy1 module for test purposes. > > http://cr.openjdk.java.net/~coffeys/webrev.8148188.v10/webrev/ > > [1] > http://cr.openjdk.java.net/~coffeys/jmc_screenshots/shared_selection_certificateId.png/Screenshot%20from%202018-11-16%2015%3a28%3a59.png > > > Regards, > Sean. > > On 14/11/18 21:09, Se?n Coffey wrote: >> Hi Sean, >> >> comments inline.. >> >> On 13/11/2018 18:53, Sean Mullan wrote: >>> Looking good, a couple of comments/questions: >>> >>> * src/java.base/share/classes/java/security/Security.java >>> >>> The isJdkSecurityProperty method could return false positives, for >>> example there may be a non-JDK property starting with "security.". I >>> was thinking it would be better to put all the JDK property names in >>> a HashSet which is populated by the static initialize() method, and >>> only if event logging is enabled. Then setProperty can just check if >>> the property name is in this set. >> after further discussion, we've decided to log all properties operated >> on via Security.setProperty(String, String). It think it makes sense. >> The contents of a JFR recording should always be treated as sensitive. >> Keep in mind also that these new JFR Events will be off by default. >>> >>> * src/java.base/share/classes/sun/security/x509/X509CertImpl.java >> Good points here. I've taken on board your suggestion to move this >> code logic to the sun/security/provider/X509Factory.java class as per >> your later email suggestion. >> >>> 45???????? l.addExpected("SunJSSE Test Serivce"); >>> >>> Is that a typo? "Serivce" >>> >> That's a typo in the test certificate details. We should fix it up via >> another bug record. >> >>> * test/jdk/jdk/security/logging/TestX509ValidationLog.java >>> >>> 54: remove blank line >>> >>> * test/lib/jdk/test/lib/security/SSLSocketTest.java >>> >>> Why is this file included? It looks like a duplicate of >>> SSLSocketTemplate. >> Yes - it's almost identical to SSLSocketTemplate except that >> SSLSocketTemplate doesn't belong to a package. I had a hard time >> incorporating its use into the jtreg tests via the @lib syntax. I >> think it's best if we open another JBS issue to migrate other uses of >> SSLSocketTemplate to jdk.test.lib.security.SSLSocketTemplate >> >> I've cleaned up the various typo/syntax issues that you've highlighted >> also. >> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v9/webrev/index.html >> >> regards, >> Sean. >> >>> The rest of my comments are mostly minor stuff, and nits: >>> >>> * >>> src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java >>> >>> >>> 245???????? if(xve.shouldCommit() || EventHelper.isLoggingSecurity()) { >>> >>> add space before "(xve" >>> >>> * src/java.base/share/classes/sun/security/ssl/Finished.java >>> >>> 1097 } >>> >>> indent >>> >>> 1098???????????? if(event.shouldCommit()) { >>> >>> add space before "(event" >>> >>> * src/java.base/share/classes/sun/security/x509/X509CertImpl.java >>> >>> update copyright >>> >>> * src/java.base/share/classes/jdk/internal/event/EventHelper.java >>> >>> 35? * A helper class to have events logged to a JDK Event Logger >>> >>> Add '.' at end of sentence. >>> >>> * src/java.base/share/classes/jdk/internal/event/TLSHandshakeEvent.java >>> >>> 38: remove blank line >>> >>> * >>> src/java.base/share/classes/jdk/internal/event/X509ValidationEvent.java >>> >>> 30? * used in X509 cert path validation >>> >>> Add '.' at end of sentence. >>> >>> * src/jdk.jfr/share/classes/jdk/jfr/events/X509ValidationEvent.java >>> >>> 47: remove blank line >>> >>> * test/jdk/jdk/security/logging/TestTLSHandshakeLog.java >>> >>> >>> --Sean >>> >>> >>> On 11/6/18 3:46 AM, Se?n Coffey wrote: >>>> With JDK-8203629 now pushed, I've re-based my patch on latest >>>> jdk/jdk code. >>>> >>>> Some modifications also made based on off-thread suggestions : >>>> >>>> src/java.base/share/classes/java/security/Security.java >>>> >>>> * Only record JDK security properties for now (i.e. those in >>>> java.security conf file) >>>> ?? - we can consider a new event to record non-JDK security events >>>> if demand comes about >>>> ?? - new event renamed to *Jdk*SecurityPropertyModificationEvent >>>> >>>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java >>>> >>>> * Use hashCode() equality test for storing certs in List. >>>> >>>> Tests updated to capture these changes >>>> >>>> src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java >>>> >>>> >>>> * Verify that self signed certs exercise the modified code paths >>>> >>>> I've added new test functionality to test use of self signed cert. >>>> >>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v7/webrev/ >>>> >>>> Regards, >>>> Sean. >>>> >>>> On 17/10/18 11:25, Se?n Coffey wrote: >>>>> I'd like to re-boot this review. I've been working with Erik off >>>>> thread who's been helping with code and test design. >>>>> >>>>> Some of the main changes worthy of highlighting : >>>>> >>>>> * Separate out the tests for JFR and Logger events >>>>> * Rename some events >>>>> * Normalize the data view for X509ValidationEvent (old event name : >>>>> CertChainEvent) >>>>> * Introduce CertificateSerialNumber type to make use of the >>>>> @Relational JFR annotation. >>>>> * Keep calls for JFR event operations local to call site to >>>>> optimize jvm compilation >>>>> >>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v6/webrev/ >>>>> >>>>> This code is dependent on the JDK-8203629 enhancement being >>>>> integrated. >>>>> >>>>> Regards, >>>>> Sean. >>>>> >>>>> On 10/07/18 13:50, Se?n Coffey wrote: >>>>>> Erik, >>>>>> >>>>>> After some trial edits, I'm not so sure if moving the event & >>>>>> logger commit code into the class where it's used works too well >>>>>> after all. >>>>>> >>>>>> In the code you suggested, there's an assumption that calls such >>>>>> as EventHelper.certificateChain(..) are low cost. While that might >>>>>> be the case here, it's something we can't always assume. It's >>>>>> called once for the JFR operation and once for the Logger >>>>>> operation. That pattern multiplies itself further in other Events. >>>>>> i.e. set up and assign the variables for a JFR event without >>>>>> knowing whether they'll be needed again for the Logger call. We >>>>>> could work around it by setting up some local variables and >>>>>> re-using them in the Logger code but then, we're back to where we >>>>>> were. The current EventHelper design eliminates this problem and >>>>>> also helps to abstract the recording/logging functionality away >>>>>> from the functionality of the class itself. >>>>>> >>>>>> It also becomes a problem where we record events in multiple >>>>>> different classes (e.g. SecurityPropertyEvent). While we could >>>>>> leave the code in EventHelper for this case, we then have a mixed >>>>>> design pattern. >>>>>> >>>>>> Are you ok with leaving as is for now? A future wish might be one >>>>>> where JFR would handle Logger via its own framework/API in a >>>>>> future JDK release. >>>>>> >>>>>> I've removed the variable names using underscore. Also optimized >>>>>> some variable assignments in X509Impl.commitEvent(..) >>>>>> >>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> On 09/07/2018 18:01, Se?n Coffey wrote: >>>>>>> Erik, >>>>>>> >>>>>>> Thanks for reviewing. Comments inline.. >>>>>>> >>>>>>> On 09/07/18 17:21, Erik Gahlin wrote: >>>>>>>> Thanks Sean. >>>>>>>> >>>>>>>> Some feedback on the code in the security libraries. >>>>>>>> >>>>>>>> - We should use camel case naming convention for variables (not >>>>>>>> underscore). >>>>>>> Sure. I see two offending variable names which I'll fix up. >>>>>>>> >>>>>>>> - Looking at sun/security/ssl/Finished.java, >>>>>>>> >>>>>>>> I wonder if it wouldn't be less code and more easy to read, if >>>>>>>> we would commit the event in a local private function and then >>>>>>>> use the EventHelper class for common functionality. >>>>>>> I'm fine with your suggested approach. I figured that tucking the >>>>>>> recording/logging logic away in a helper class also had benefits >>>>>>> but I'll re-factor to your suggested style unless I hear objections. >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>> >>>>>> >>>>> >>>> >> > From xuelei.fan at oracle.com Fri Nov 16 18:30:22 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 16 Nov 2018 10:30:22 -0800 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> Message-ID: <228516ab-aaca-5a4e-f709-3b4f44a82101@oracle.com> It's time to use the systemProperty tag as it is ready. As we are already there, I also update the setSessionCacheSize() for more clarification. Please review both CSR and webrev: https://bugs.openjdk.java.net/browse/JDK-8213577 http://cr.openjdk.java.net/~xuelei/8210985/webrev.02/ Thanks, Xuelei On 11/16/2018 8:19 AM, Sean Mullan wrote: > On 11/15/18 3:37 PM, Xuelei Fan wrote: >> Hi Sean, >> >> Are you OK if we do it later?? I'm waiting for the @systemProperty >> tag, proposed within JDK-5076751.? I will file a bug to use the tag >> for more cleanup. > > JDK-5076751 is completed and pushed to JDK 12, so you can use the new > tag now. > > I think it would be easier to do it now, it seems pretty simple and that > way there is no need to worry about it later. > > --Sean > >> >> Thanks, >> Xuelei >> >> On 11/15/2018 11:55 AM, Sean Mullan wrote: >>> This is a good opportunity to document the >>> javax.net.ssl.sessionCacheSize system property in the >>> SSLSessionContext API (and use the new @systemProperty tag) in an >>> @implNote, for example: >>> >>> ???? /** >>> ????? * Returns the size of the cache used for storing >>> ????? * SSLSession objects grouped under this >>> ????? * SSLSessionContext. >>> ????? * >>> ????? * @implNote The JDK implementation returns the cache size as >>> set by >>> ????? * the {@code setSessionCacheSize method}, or if not set, the value >>> ????? * of the {@systemProperty javax.net.ssl.sessionCacheSize} system >>> ????? * property. If neither is set, it returns a default value of >>> 20480. >>> ????? * >>> ????? * @return size of the session cache; zero means there is no >>> size limit. >>> ????? * @see #setSessionCacheSize >>> ????? */ >>> ???? public int getSessionCacheSize(); >>> >>> On 11/14/18 11:59 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review this simple update: >>>> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ >>>> >>>> The default value for the maximum number of entries in the SSL >>>> session cache (SSLSessionContext.getSessionCacheSize()) is infinite >>>> now.? In the request, the default value is updated to 20480 for >>>> performance consideration. >>>> >>>> For the detailed behavior update, please refer to CSR: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8213577 >>>> >>>> Thanks, >>>> Xuelei From sean.mullan at oracle.com Fri Nov 16 19:33:59 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Nov 2018 14:33:59 -0500 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: <228516ab-aaca-5a4e-f709-3b4f44a82101@oracle.com> References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> <228516ab-aaca-5a4e-f709-3b4f44a82101@oracle.com> Message-ID: 122 * @apiNote Both the session timeout and cache size impact performance 123 * of future connections. It is not recommended to use too big 124 * or too small timeout or cache size limit. Applications should 125 * carefully weigh the limits and performance for the specific 126 * circumstances. I am not really sure if the @apiNote is that useful or appropriate, but it seems a bit odd to talk about the session timeout in this method. If you still want to add this, I would add an @apiNote to each of the setSessionCacheSize and setSessionTimeout methods and just discuss each property separately. Also, unless you say what "too big" or "too small" is, I would avoid giving this advice. --Sean On 11/16/18 1:30 PM, Xuelei Fan wrote: > It's time to use the systemProperty tag as it is ready. > > As we are already there, I also update the setSessionCacheSize() for > more clarification. > > Please review both CSR and webrev: > ??? https://bugs.openjdk.java.net/browse/JDK-8213577 > ??? http://cr.openjdk.java.net/~xuelei/8210985/webrev.02/ > > Thanks, > Xuelei > > On 11/16/2018 8:19 AM, Sean Mullan wrote: >> On 11/15/18 3:37 PM, Xuelei Fan wrote: >>> Hi Sean, >>> >>> Are you OK if we do it later?? I'm waiting for the @systemProperty >>> tag, proposed within JDK-5076751.? I will file a bug to use the tag >>> for more cleanup. >> >> JDK-5076751 is completed and pushed to JDK 12, so you can use the new >> tag now. >> >> I think it would be easier to do it now, it seems pretty simple and >> that way there is no need to worry about it later. >> >> --Sean >> >>> >>> Thanks, >>> Xuelei >>> >>> On 11/15/2018 11:55 AM, Sean Mullan wrote: >>>> This is a good opportunity to document the >>>> javax.net.ssl.sessionCacheSize system property in the >>>> SSLSessionContext API (and use the new @systemProperty tag) in an >>>> @implNote, for example: >>>> >>>> ???? /** >>>> ????? * Returns the size of the cache used for storing >>>> ????? * SSLSession objects grouped under this >>>> ????? * SSLSessionContext. >>>> ????? * >>>> ????? * @implNote The JDK implementation returns the cache size as >>>> set by >>>> ????? * the {@code setSessionCacheSize method}, or if not set, the >>>> value >>>> ????? * of the {@systemProperty javax.net.ssl.sessionCacheSize} system >>>> ????? * property. If neither is set, it returns a default value of >>>> 20480. >>>> ????? * >>>> ????? * @return size of the session cache; zero means there is no >>>> size limit. >>>> ????? * @see #setSessionCacheSize >>>> ????? */ >>>> ???? public int getSessionCacheSize(); >>>> >>>> On 11/14/18 11:59 AM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review this simple update: >>>>> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ >>>>> >>>>> The default value for the maximum number of entries in the SSL >>>>> session cache (SSLSessionContext.getSessionCacheSize()) is infinite >>>>> now.? In the request, the default value is updated to 20480 for >>>>> performance consideration. >>>>> >>>>> For the detailed behavior update, please refer to CSR: >>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8213577 >>>>> >>>>> Thanks, >>>>> Xuelei From jamil.j.nimeh at oracle.com Fri Nov 16 19:31:27 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 16 Nov 2018 11:31:27 -0800 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: <228516ab-aaca-5a4e-f709-3b4f44a82101@oracle.com> References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> <228516ab-aaca-5a4e-f709-3b4f44a82101@oracle.com> Message-ID: Hi Xuelei, A little wordsmithing, nit picky stuff (sorry for not seeing this earlier): * @apiNote for setSessionCacheSize: The sentence beginning, "It is not recommended to use too big..." needs a slight grammatical change o Suggestion: "It is recommended that applications tune their timeout and cache size values so they are neither too small nor too large." o If you decide to change the language in the CSR then change it in SSLSessionContext.java, too. * @implNote for getSessionCacheSize: bring the closing brace in from "{@code setSessionCacheSize method}" to put the word method outside the braces. o This should change in the code review, SSLSessionContext.java:143 The rest is fine. --Jamil On 11/16/2018 10:30 AM, Xuelei Fan wrote: > It's time to use the systemProperty tag as it is ready. > > As we are already there, I also update the setSessionCacheSize() for > more clarification. > > Please review both CSR and webrev: > ??? https://bugs.openjdk.java.net/browse/JDK-8213577 > ??? http://cr.openjdk.java.net/~xuelei/8210985/webrev.02/ > > Thanks, > Xuelei > > On 11/16/2018 8:19 AM, Sean Mullan wrote: >> On 11/15/18 3:37 PM, Xuelei Fan wrote: >>> Hi Sean, >>> >>> Are you OK if we do it later?? I'm waiting for the @systemProperty >>> tag, proposed within JDK-5076751.? I will file a bug to use the tag >>> for more cleanup. >> >> JDK-5076751 is completed and pushed to JDK 12, so you can use the new >> tag now. >> >> I think it would be easier to do it now, it seems pretty simple and >> that way there is no need to worry about it later. >> >> --Sean >> >>> >>> Thanks, >>> Xuelei >>> >>> On 11/15/2018 11:55 AM, Sean Mullan wrote: >>>> This is a good opportunity to document the >>>> javax.net.ssl.sessionCacheSize system property in the >>>> SSLSessionContext API (and use the new @systemProperty tag) in an >>>> @implNote, for example: >>>> >>>> ???? /** >>>> ????? * Returns the size of the cache used for storing >>>> ????? * SSLSession objects grouped under this >>>> ????? * SSLSessionContext. >>>> ????? * >>>> ????? * @implNote The JDK implementation returns the cache size as >>>> set by >>>> ????? * the {@code setSessionCacheSize method}, or if not set, the >>>> value >>>> ????? * of the {@systemProperty javax.net.ssl.sessionCacheSize} system >>>> ????? * property. If neither is set, it returns a default value of >>>> 20480. >>>> ????? * >>>> ????? * @return size of the session cache; zero means there is no >>>> size limit. >>>> ????? * @see #setSessionCacheSize >>>> ????? */ >>>> ???? public int getSessionCacheSize(); >>>> >>>> On 11/14/18 11:59 AM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review this simple update: >>>>> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ >>>>> >>>>> The default value for the maximum number of entries in the SSL >>>>> session cache (SSLSessionContext.getSessionCacheSize()) is >>>>> infinite now.? In the request, the default value is updated to >>>>> 20480 for performance consideration. >>>>> >>>>> For the detailed behavior update, please refer to CSR: >>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8213577 >>>>> >>>>> Thanks, >>>>> Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Nov 16 19:56:21 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Nov 2018 14:56:21 -0500 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: References: Message-ID: Looks good. Please file a follow-on issue to remove the defaults. --Sean On 11/16/18 9:35 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8212003/webrev.00/ > > Here, a warning is added when -keyalg is not specified, and some informational text output that were only available in verbose mode is now always printed. > > Below are the exact output you will see after this change. Please note that we can only create DES SecretKey in JCEKS keystore. Also, depending on whether the subject is provided through -dname or entered interactively, the warning on the default -keyalg option appears in different places. In the interactive mode, it appears at the beginning so that user can exit earlier if the default -keyalg value is not preferred. > > $ keytool -genseckey -alias a -keystore jceks -storepass changeit -storetype jceks -keypass changeit > Generated 56-bit DES secret key > > Warning: > No -keyalg option. The default key algorithm (DES) is a legacy algorithm and is no longer recommended. In a subsequent release of the JDK, the default will be removed and the -keyalg option must be specified. > The JCEKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore jceks -destkeystore jceks -deststoretype pkcs12". > > c $ keytool -genkeypair -alias c -keystore /tmp/p12 -storepass changeit > > Warning: > No -keyalg option. The default key algorithm (DSA) is a legacy algorithm and is no longer recommended. In a subsequent release of the JDK, the default will be removed and the -keyalg option must be specified. > > What is your first and last name? > [Unknown]: Duke > What is the name of your organizational unit? > [Unknown]: Java > What is the name of your organization? > [Unknown]: Oracle > What is the name of your City or Locality? > [Unknown]: Santa Clara > What is the name of your State or Province? > [Unknown]: CA > What is the two-letter country code for this unit? > [Unknown]: US > Is CN=Duke, OU=Java, O=Oracle, L=Santa Clara, ST=CA, C=US correct? > [no]: yes > > Generating 2,048 bit DSA key pair and self-signed certificate (SHA256withDSA) with a validity of 90 days > for: CN=Duke, OU=Java, O=Oracle, L=Santa Clara, ST=CA, C=US > > c $ keytool -genkeypair -alias d -keystore /tmp/p12 -storepass changeit -dname CN=A > Generating 2,048 bit DSA key pair and self-signed certificate (SHA256withDSA) with a validity of 90 days > for: CN=A > > Warning: > No -keyalg option. The default key algorithm (DSA) is a legacy algorithm and is no longer recommended. In a subsequent release of the JDK, the default will be removed and the -keyalg option must be specified. > > Thanks > Max > From xuelei.fan at oracle.com Fri Nov 16 20:19:47 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 16 Nov 2018 12:19:47 -0800 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> <228516ab-aaca-5a4e-f709-3b4f44a82101@oracle.com> Message-ID: <0ed3fc6a-e338-3c4b-3a9a-0d3123946e0c@oracle.com> Thanks for the review, Jmail & Sean. New webrev: http://cr.openjdk.java.net/~xuelei/8210985/webrev.03/ I will update CSR when we come to an agreement. On 11/16/2018 11:33 AM, Sean Mullan wrote: > ?122????? * @apiNote Both the session timeout and cache size impact > performance > ?123????? *????????? of future connections.? It is not recommended to > use too big > ?124????? *????????? or too small timeout or cache size limit. > Applications should > ?125????? *????????? carefully weigh the limits and performance for the > specific > ?126????? *????????? circumstances. > > I am not really sure if the @apiNote is that useful or appropriate, I worry about the default value actually. A new bug may be filed again and argue if the default value is not a proper one. The default value of session timeout and cache size really depends on the real world circumstances. I think we'd better make a clarification in the spec, and remind application tune them accordingly. > but > it seems a bit odd to talk about the session timeout in this method. The performance impact is a combination of the session timeout limit and cache size. I would like application consider them together if need to tune the values, but not individually. > If > you still want to add this, I would add an @apiNote to each of the > setSessionCacheSize and setSessionTimeout methods and just discuss each > property separately. > I added the update spec to both setSessionCacheSize and setSessionTimeout. > Also, unless you say what "too big" or "too small" is, I would avoid > giving this advice. > It makes sense to me. Thanks, Xuelei > --Sean > > > On 11/16/18 1:30 PM, Xuelei Fan wrote: >> It's time to use the systemProperty tag as it is ready. >> >> As we are already there, I also update the setSessionCacheSize() for >> more clarification. >> >> Please review both CSR and webrev: >> ???? https://bugs.openjdk.java.net/browse/JDK-8213577 >> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.02/ >> >> Thanks, >> Xuelei >> >> On 11/16/2018 8:19 AM, Sean Mullan wrote: >>> On 11/15/18 3:37 PM, Xuelei Fan wrote: >>>> Hi Sean, >>>> >>>> Are you OK if we do it later?? I'm waiting for the @systemProperty >>>> tag, proposed within JDK-5076751.? I will file a bug to use the tag >>>> for more cleanup. >>> >>> JDK-5076751 is completed and pushed to JDK 12, so you can use the new >>> tag now. >>> >>> I think it would be easier to do it now, it seems pretty simple and >>> that way there is no need to worry about it later. >>> >>> --Sean >>> >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 11/15/2018 11:55 AM, Sean Mullan wrote: >>>>> This is a good opportunity to document the >>>>> javax.net.ssl.sessionCacheSize system property in the >>>>> SSLSessionContext API (and use the new @systemProperty tag) in an >>>>> @implNote, for example: >>>>> >>>>> ???? /** >>>>> ????? * Returns the size of the cache used for storing >>>>> ????? * SSLSession objects grouped under this >>>>> ????? * SSLSessionContext. >>>>> ????? * >>>>> ????? * @implNote The JDK implementation returns the cache size as >>>>> set by >>>>> ????? * the {@code setSessionCacheSize method}, or if not set, the >>>>> value >>>>> ????? * of the {@systemProperty javax.net.ssl.sessionCacheSize} system >>>>> ????? * property. If neither is set, it returns a default value of >>>>> 20480. >>>>> ????? * >>>>> ????? * @return size of the session cache; zero means there is no >>>>> size limit. >>>>> ????? * @see #setSessionCacheSize >>>>> ????? */ >>>>> ???? public int getSessionCacheSize(); >>>>> >>>>> On 11/14/18 11:59 AM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this simple update: >>>>>> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ >>>>>> >>>>>> The default value for the maximum number of entries in the SSL >>>>>> session cache (SSLSessionContext.getSessionCacheSize()) is >>>>>> infinite now.? In the request, the default value is updated to >>>>>> 20480 for performance consideration. >>>>>> >>>>>> For the detailed behavior update, please refer to CSR: >>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8213577 >>>>>> >>>>>> Thanks, >>>>>> Xuelei From ecki at zusammenkunft.net Fri Nov 16 21:27:25 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 16 Nov 2018 21:27:25 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> , <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> Message-ID: Hello Sean, I was only looking at the inspected DNSName class, it still has some variations (but start now with DNSNames which is good already): 76 throw new IOException("DNSName must not be null or empty"); 78 throw new IOException("DNSNames or NameConstraints with blank components are not permitted"); 80 throw new IOException("DNSNames or NameConstraints may not begin or end with a ."); 92 throw new IOException("DNSName SubjectAltNames with empty components are not permitted"); 96 throw new IOException("DNSName components must begin with a letter or digit"); 101 throw new IOException("DNSName components must consist of letters, digits, and hyphens"); I did not check if those exceptions are catched and rethrown with something like ?while validating the SubjectAltName Extension of certificate ...?, in my experience it helps if you do not have to find and review the actual certificates (in this case it might not be a problem if SAN is only in the end entity). You can probably remove ?or NameConstraints? and ?SubjectAltNames? from lines 78-92 (this is good if DNsName applies to SAN or NameConstrained context and the validation logic does not know ? so it?s not only more unified but also less missleading) BTW: probably not inthe scope of this fix but a subtype for validation errors which have getters for context/location and maybe error code and getValue() would allow callers to print nicer validation reports without relying on the message or Stacktraces. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Se?n Coffey Gesendet: Freitag, November 16, 2018 5:15 PM An: Bernd Eckenfels; security-dev at openjdk.java.net Betreff: Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123 Thanks for the comments Bernd. comments inline.. On 16/11/18 12:40, Bernd Eckenfels wrote: You could also add (a..b, false) and (.a, false), (a., false) to the testcases. good point. test updated. I noticed that there are different types of Exception messages (DNS name, DNSName, DNS Name or name constrained, DNS name and SAN), would be good if all of them have the same keyword? I cleaned up some other references to DNSName in the sun.security.x509 package. I'm not sure what classes you were referencing the above examples from. new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ regards, Sean. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Se?n Coffey Gesendet: Freitag, November 16, 2018 12:25 PM An: OpenJDK Dev list Betreff: RFR: 8213952: Relax DNSName restriction as per RFC 1123 Looking to make an adjustment to DNSName constructor to help comply with RFC 1123 https://bugs.openjdk.java.net/browse/JDK-8213952 http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ regards, Sean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sat Nov 17 10:20:35 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 17 Nov 2018 18:20:35 +0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: References: Message-ID: <1BB66450-6501-4A44-B760-E156B71B61AA@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8214024 filed. Thanks Max > On Nov 17, 2018, at 3:56 AM, Sean Mullan wrote: > > Looks good. Please file a follow-on issue to remove the defaults. > > --Sean > > On 11/16/18 9:35 AM, Weijun Wang wrote: >> Please take a review at >> https://cr.openjdk.java.net/~weijun/8212003/webrev.00/ From weijun.wang at oracle.com Sun Nov 18 07:36:57 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 18 Nov 2018 15:36:57 +0800 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() In-Reply-To: <4a9fe64c-77b2-6580-e0eb-d9546f453190@oracle.com> References: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> <70c76a9c-43b0-a144-fe1d-5874abad0934@oracle.com> <0ffbddf2-7ee6-90c2-5315-5142aeaf3fe2@oracle.com> <4a9fe64c-77b2-6580-e0eb-d9546f453190@oracle.com> Message-ID: The version looks fine. Thanks. > On Nov 17, 2018, at 1:56 AM, Se?n Coffey wrote: > > Thanks Sean. StringBuilder use added : > > http://cr.openjdk.java.net/~coffeys/webrev.8210838.v4/webrev/ > > Regards, > Sean. > > On 16/11/18 17:33, Sean Mullan wrote: >> Looks ok. If there are no disadvantages to using a StringBuilder, I would probably do that, since you are creating 4-5 separate Strings in the toString method. >> >> --Sean >> >> On 11/16/18 11:35 AM, Se?n Coffey wrote: >>> >>> On 16/11/18 16:16, Sean Mullan wrote: >>>> On 11/16/18 9:04 AM, Se?n Coffey wrote: >>>>> That's a good example and point Max. How does this revision look ? >>>>> >>>>> http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ >>>> >>>> 2832 * This implementation returns a String containing the transformation >>>> 2833 * used by this Cipher, the Cipher mode and the Cipher Provider. >>>> >>>> I would suggest rewording this as: "This implementation returns a String containing the transformation, mode, and provider of this Cipher." >>> Good suggestion. Changed. >>>> >>>> 2840 String m = "not initialized"; >>>> 2841 if (initialized) >>>> 2842 m = getOpmodeString(opmode); >>>> >>>> Or: >>>> >>>> String m = initialized ? getOpmodeString(opmode) : "not initialized"; >>> I've moved the switch expression into the toString() call now as per suggestion from Max. I've just >>> seen that we should never have an unexpected opmode given the checkOpmode(int) method check. >>> I've let an unexpected opmode register with "error" in the switch statement. // should never happen. >>> >>> webrev updated in place: >>> http://cr.openjdk.java.net/~coffeys/webrev.8210838.v3/webrev/ >>> >>> regards, >>> Sean. >>> >>>> >>>> Also, it might be worthwhile to use a StringBuilder if you think this method may be called often. >>>> >>>> --Sean >>>> >>>>> >>>>> Regards, >>>>> Sean. >>>>> >>>>> On 16/11/18 03:35, Weijun Wang wrote: >>>>>> Signature's toString looks like >>>>>> >>>>>> public String toString() { >>>>>> String initState = ""; >>>>>> switch (state) { >>>>>> case UNINITIALIZED: >>>>>> initState = ""; >>>>>> break; >>>>>> case VERIFY: >>>>>> initState = ""; >>>>>> break; >>>>>> case SIGN: >>>>>> initState = ""; >>>>>> break; >>>>>> } >>>>>> return "Signature object: " + getAlgorithm() + initState; >>>>>> } >>>>>> >>>>>> Maybe you can add some similar info. >>>>>> >>>>>> In fact, it looks like you can extract the debug output at the end of each init() methods into a new toString() method. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> On Nov 16, 2018, at 12:35 AM, Se?n Coffey wrote: >>>>>>> >>>>>>> A simple enhancement to override toString() for javax.crypto.Cipher class >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210838 >>>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>> >>>>> >>> > From sean.mullan at oracle.com Mon Nov 19 15:39:35 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Nov 2018 10:39:35 -0500 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: <0ed3fc6a-e338-3c4b-3a9a-0d3123946e0c@oracle.com> References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> <228516ab-aaca-5a4e-f709-3b4f44a82101@oracle.com> <0ed3fc6a-e338-3c4b-3a9a-0d3123946e0c@oracle.com> Message-ID: On 11/16/18 3:19 PM, Xuelei Fan wrote: > Thanks for the review, Jmail & Sean. > > New webrev: > ??? http://cr.openjdk.java.net/~xuelei/8210985/webrev.03/ > > I will update CSR when we come to an agreement. > > On 11/16/2018 11:33 AM, Sean Mullan wrote: >> ??122????? * @apiNote Both the session timeout and cache size impact >> performance >> ??123????? *????????? of future connections.? It is not recommended to >> use too big >> ??124????? *????????? or too small timeout or cache size limit. >> Applications should >> ??125????? *????????? carefully weigh the limits and performance for >> the specific >> ??126????? *????????? circumstances. >> >> I am not really sure if the @apiNote is that useful or appropriate, > I worry about the default value actually. Then maybe the default is what you should be discussing in this apiNote. Right now I don't think the apiNote adds much. To me, all you are really saying is that these are methods that can be used to tune performance, which I think should be obvious from their name and description. Maybe the apiNote should say something like: "Note that the JDK Implementation uses default values for both the session cache size and timeout. See getSessionCacheSize and getSessionTimeout for more information. Applications should consider their performance requirements and override the defaults if necessary." Also I think you should add a similar @implNote for getSessionTimeout which describes the default value (86400 seconds or 24 hours), ex: @implNote The JDK implementation returns the session timeout as set by the {@code setSessionTimeout} method, or if not set, a default value of 86400 seconds (24 hours). >? A new bug may be filed again > and argue if the default value is not a proper one.? The default value > of session timeout and cache size really depends on the real world > circumstances.? I think we'd better make a clarification in the spec, > and remind application tune them accordingly. Ok, but the apiNote above says nothing about the default value. --Sean > >> but it seems a bit odd to talk about the session timeout in this method. > The performance impact is a combination of the session timeout limit and > cache size.? I would like application consider them together if need to > tune the values, but not individually. > >> If you still want to add this, I would add an @apiNote to each of the >> setSessionCacheSize and setSessionTimeout methods and just discuss >> each property separately. >> > I added the update spec to both setSessionCacheSize and setSessionTimeout. > >> Also, unless you say what "too big" or "too small" is, I would avoid >> giving this advice. >> > It makes sense to me. > > Thanks, > Xuelei > >> --Sean >> >> >> On 11/16/18 1:30 PM, Xuelei Fan wrote: >>> It's time to use the systemProperty tag as it is ready. >>> >>> As we are already there, I also update the setSessionCacheSize() for >>> more clarification. >>> >>> Please review both CSR and webrev: >>> ???? https://bugs.openjdk.java.net/browse/JDK-8213577 >>> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.02/ >>> >>> Thanks, >>> Xuelei >>> >>> On 11/16/2018 8:19 AM, Sean Mullan wrote: >>>> On 11/15/18 3:37 PM, Xuelei Fan wrote: >>>>> Hi Sean, >>>>> >>>>> Are you OK if we do it later?? I'm waiting for the @systemProperty >>>>> tag, proposed within JDK-5076751.? I will file a bug to use the tag >>>>> for more cleanup. >>>> >>>> JDK-5076751 is completed and pushed to JDK 12, so you can use the >>>> new tag now. >>>> >>>> I think it would be easier to do it now, it seems pretty simple and >>>> that way there is no need to worry about it later. >>>> >>>> --Sean >>>> >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 11/15/2018 11:55 AM, Sean Mullan wrote: >>>>>> This is a good opportunity to document the >>>>>> javax.net.ssl.sessionCacheSize system property in the >>>>>> SSLSessionContext API (and use the new @systemProperty tag) in an >>>>>> @implNote, for example: >>>>>> >>>>>> ???? /** >>>>>> ????? * Returns the size of the cache used for storing >>>>>> ????? * SSLSession objects grouped under this >>>>>> ????? * SSLSessionContext. >>>>>> ????? * >>>>>> ????? * @implNote The JDK implementation returns the cache size as >>>>>> set by >>>>>> ????? * the {@code setSessionCacheSize method}, or if not set, the >>>>>> value >>>>>> ????? * of the {@systemProperty javax.net.ssl.sessionCacheSize} >>>>>> system >>>>>> ????? * property. If neither is set, it returns a default value of >>>>>> 20480. >>>>>> ????? * >>>>>> ????? * @return size of the session cache; zero means there is no >>>>>> size limit. >>>>>> ????? * @see #setSessionCacheSize >>>>>> ????? */ >>>>>> ???? public int getSessionCacheSize(); >>>>>> >>>>>> On 11/14/18 11:59 AM, Xuelei Fan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this simple update: >>>>>>> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ >>>>>>> >>>>>>> The default value for the maximum number of entries in the SSL >>>>>>> session cache (SSLSessionContext.getSessionCacheSize()) is >>>>>>> infinite now.? In the request, the default value is updated to >>>>>>> 20480 for performance consideration. >>>>>>> >>>>>>> For the detailed behavior update, please refer to CSR: >>>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8213577 >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei From ecki at zusammenkunft.net Mon Nov 19 22:26:38 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 19 Nov 2018 22:26:38 +0000 Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions In-Reply-To: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com> Message-ID: Hello, What is the purpose of setting some of them to 0 twice? (It?s a new array which should be all-0 anyway.) + for (int i = 1; i < 9 ; i++) { + subkeyHtbl[2*i] = 0; + subkeyHtbl[2*i+1] = 0; + } Also, is the subkeyH no longer be needed (or can be redesigned to use subkeyHtbl[0] and 1? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Kamath, Smita Gesendet: Montag, November 19, 2018 10:52 PM An: 'Vladimir Kozlov' Cc: Anthony Scarpino; core-libs-dev at openjdk.java.net; hotspot compiler Betreff: RFR(S)JDK-8214074: Ghash optimization using AVX instructions Hi Vladimir, I'd like to contribute an optimization for GHASH Algorithm using AVX Instructions. I have tested this optimization on SKX x86_64 platform and it shows ~20-30% performance improvement for larger message sizes (for example 8k). I, smita.kamath at intel.com , Shay Gueuron, (shay.gueron at intel.com) and Regev Shemy (regev.shemy at intel.com) are contributors to this code. Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074 Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/ For testing the implementation, I have executed TestAESMain.java. I have executed Jtreg tests and tested this code on 64 bit Windows and Linux platforms. Please review and let me know if you have any comments. Thanks and Regards, Smita -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Mon Nov 19 23:30:37 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 19 Nov 2018 15:30:37 -0800 Subject: RFR 8213202: Possible race condition in TLS 1.3 session resumption In-Reply-To: <73adb4a8-a7c3-58f5-a2a6-93e58aa4df13@oracle.com> References: <73adb4a8-a7c3-58f5-a2a6-93e58aa4df13@oracle.com> Message-ID: <3fe05880-745d-4074-248c-7e89c00d33d7@oracle.com> Hi Adam, I think this looks good. On 11/9/2018 11:09 AM, Adam Petcher wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8213202 > webrev: http://cr.openjdk.java.net/~apetcher/8213202/webrev.00/ > > This change fixes a bug that allows multiple clients thread to offer > the same PSK to the server, even though only one thread may actually > use the PSK to resume the session. The other threads will fail to > connect and throw an exception. This is noreg-hard because the bug > doesn't happen with the JDK TLS server, and we don't have a regression > test harness that allows us to simulate some particular server > behavior. I tested the fix by connecting multiple JDK clients to an > openssl server. > From weijun.wang at oracle.com Tue Nov 20 01:56:36 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 20 Nov 2018 09:56:36 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider Message-ID: Please take a review at https://cr.openjdk.java.net/~weijun/6722928/webrev.01/ We ported [1] the native GSS bridge to Windows in JDK 11, but user still have to download and install a native GSS-API library. This code change provides a native GSS-API library inside JDK that can be used without setting the "sun.security.jgss.lib" system property. It is based on Windows SSPI and now only supports the client side using the default credentials. No regression tests included. A Windows Active Directory server is needed. Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8200468 From weijun.wang at oracle.com Tue Nov 20 09:33:33 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 20 Nov 2018 17:33:33 +0800 Subject: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow In-Reply-To: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com> References: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com> Message-ID: <26F3E48B-FD8A-46AF-B054-749DD6CBD2EE@oracle.com> Webrev updated at https://cr.openjdk.java.net/~weijun/8210476/webrev.01/ The only change is that there is a single Cleaner now for the whole PRNG class. Otherwise, each will maintain its own thread. Thanks Max > On Nov 11, 2018, at 11:30 PM, Weijun Wang wrote: > > Please take a review at > > https://cr.openjdk.java.net/~weijun/8210476/webrev.00/ > > Before this fix, every PRNG::nextBytes calls all of CryptAcquireContext, CryptGenRandom, and CryptReleaseContext. Now, CryptAcquireContext is called once in PRNG::new, and CryptReleaseContext is called by a Cleaner, and nextBytes only calls CryptGenRandom. > > I haven't read about thread-safety in any MS document, the current Windows-PRNG service is marked ThreadSafe=true (in SunMSCAPI.java). If we cannot be really sure, we can change it to false. > > I've downloaded nearly 1000 Mach5 runs of this test, the enhancement is so good that I adjusted the test to be stricter. > > Before After > ------ ----- > Count 897 74 > Min 0.38 0.008 > Ave 0.97 0.011 > Max 5.81 0.021 > > Please advise me if the following usage of Cleaner is correct because I really haven't observed the releaseContext method being called. > > + Cleaner.create().register(this, > + () -> releaseContext(ctxt)); > > Thanks > Max > From Nico.Williams at twosigma.com Tue Nov 20 17:51:20 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Tue, 20 Nov 2018 17:51:20 +0000 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: References: Message-ID: <20181120175120.GJ26310@twosigma.com> On Tue, Nov 20, 2018 at 09:56:36AM +0800, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/6722928/webrev.01/ > > We ported [1] the native GSS bridge to Windows in JDK 11, but user still have > to download and install a native GSS-API library. This code change provides a > native GSS-API library inside JDK that can be used without setting the > "sun.security.jgss.lib" system property. It is based on Windows SSPI and now > only supports the client side using the default credentials. > > No regression tests included. A Windows Active Directory server is needed. I'll review soon. Nico -- From valerie.peng at oracle.com Tue Nov 20 22:57:20 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 20 Nov 2018 14:57:20 -0800 Subject: RFR: 8210838: Override javax.crypto.Cipher.toString() In-Reply-To: References: <05A7D985-F725-42C9-92F1-9E340417BBCF@oracle.com> <586f6532-95e1-bc86-abc0-23e740684474@oracle.com> <70c76a9c-43b0-a144-fe1d-5874abad0934@oracle.com> <0ffbddf2-7ee6-90c2-5315-5142aeaf3fe2@oracle.com> <4a9fe64c-77b2-6580-e0eb-d9546f453190@oracle.com> Message-ID: I saw you've integrated this. Just want to add that, instead of mode (which is used also for part of the transformation, e.g. CBC, GCM), maybe we can use "operation" or "operating mode". Something to keep in mind for future changes, I guess. Regards, Valerie On 11/17/2018 11:36 PM, Weijun Wang wrote: > The version looks fine. Thanks. > >> On Nov 17, 2018, at 1:56 AM, Se?n Coffey wrote: >> >> Thanks Sean. StringBuilder use added : >> >> http://cr.openjdk.java.net/~coffeys/webrev.8210838.v4/webrev/ >> >> Regards, >> Sean. >> >> On 16/11/18 17:33, Sean Mullan wrote: >>> Looks ok. If there are no disadvantages to using a StringBuilder, I would probably do that, since you are creating 4-5 separate Strings in the toString method. >>> >>> --Sean >>> >>> On 11/16/18 11:35 AM, Se?n Coffey wrote: >>>> On 16/11/18 16:16, Sean Mullan wrote: >>>>> On 11/16/18 9:04 AM, Se?n Coffey wrote: >>>>>> That's a good example and point Max. How does this revision look ? >>>>>> >>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8210838.v2/webrev/ >>>>> 2832 * This implementation returns a String containing the transformation >>>>> 2833 * used by this Cipher, the Cipher mode and the Cipher Provider. >>>>> >>>>> I would suggest rewording this as: "This implementation returns a String containing the transformation, mode, and provider of this Cipher." >>>> Good suggestion. Changed. >>>>> 2840 String m = "not initialized"; >>>>> 2841 if (initialized) >>>>> 2842 m = getOpmodeString(opmode); >>>>> >>>>> Or: >>>>> >>>>> String m = initialized ? getOpmodeString(opmode) : "not initialized"; >>>> I've moved the switch expression into the toString() call now as per suggestion from Max. I've just >>>> seen that we should never have an unexpected opmode given the checkOpmode(int) method check. >>>> I've let an unexpected opmode register with "error" in the switch statement. // should never happen. >>>> >>>> webrev updated in place: >>>> http://cr.openjdk.java.net/~coffeys/webrev.8210838.v3/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >>>>> Also, it might be worthwhile to use a StringBuilder if you think this method may be called often. >>>>> >>>>> --Sean >>>>> >>>>>> Regards, >>>>>> Sean. >>>>>> >>>>>> On 16/11/18 03:35, Weijun Wang wrote: >>>>>>> Signature's toString looks like >>>>>>> >>>>>>> public String toString() { >>>>>>> String initState = ""; >>>>>>> switch (state) { >>>>>>> case UNINITIALIZED: >>>>>>> initState = ""; >>>>>>> break; >>>>>>> case VERIFY: >>>>>>> initState = ""; >>>>>>> break; >>>>>>> case SIGN: >>>>>>> initState = ""; >>>>>>> break; >>>>>>> } >>>>>>> return "Signature object: " + getAlgorithm() + initState; >>>>>>> } >>>>>>> >>>>>>> Maybe you can add some similar info. >>>>>>> >>>>>>> In fact, it looks like you can extract the debug output at the end of each init() methods into a new toString() method. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> On Nov 16, 2018, at 12:35 AM, Se?n Coffey wrote: >>>>>>>> >>>>>>>> A simple enhancement to override toString() for javax.crypto.Cipher class >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210838 >>>>>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8210838/webrev/ >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>> From weijun.wang at oracle.com Wed Nov 21 02:55:25 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 21 Nov 2018 10:55:25 +0800 Subject: RFR 6722928: Support SSPI as a native GSS-API provider In-Reply-To: <20181120175120.GJ26310@twosigma.com> References: <20181120175120.GJ26310@twosigma.com> Message-ID: <641597EA-2B13-48BB-9658-84B30F44E9CA@oracle.com> Thanks. I'll be very glad to hear your opinions are the handling of names. They are complicated. > On Nov 21, 2018, at 1:51 AM, Nico Williams wrote: > > On Tue, Nov 20, 2018 at 09:56:36AM +0800, Weijun Wang wrote: >> Please take a review at >> >> https://cr.openjdk.java.net/~weijun/6722928/webrev.01/ >> >> We ported [1] the native GSS bridge to Windows in JDK 11, but user still have >> to download and install a native GSS-API library. This code change provides a >> native GSS-API library inside JDK that can be used without setting the >> "sun.security.jgss.lib" system property. It is based on Windows SSPI and now >> only supports the client side using the default credentials. >> >> No regression tests included. A Windows Active Directory server is needed. > > I'll review soon. > > Nico > -- From goetz.lindenmaier at sap.com Wed Nov 21 08:10:08 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Nov 2018 08:10:08 +0000 Subject: downport of JDK-8209965 / JDK-8210005 In-Reply-To: <066e1004c4bd4e9a86d30d545f971e15@sap.com> References: <066e1004c4bd4e9a86d30d545f971e15@sap.com> Message-ID: <15c410d2ac094caaa87a1c155b406ffb@sap.com> Hi, thanks for working on this issue! But I'm not clear what it means that you did. Do I understand correctly that tag CPU19_01-critical-SQE-OK in 8209965 means it will be fixed in the January 2019 release of jdk11? I.e., the change will show up on January 15th 2019 in the open repository jdk-updates/jdk11u? https://bugs.openjdk.java.net/browse/JDK-8210005 has Fix Version 11.0.3-oracle. What does that again mean? Does it mean you pushed the change to an internal repository that will be used to build the commercial OracleJDK release in April 2019? As I understand, the jdk 11.0.3 repo prepared by Oracle will not be released to the open. These two pieces of information don't fit together in my mind :) Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 16. November 2018 15:07 > To: 'Xuelei Fan' ; 'Prasadrao Koppula' > > Cc: Alan Bateman (alan.bateman at oracle.com) > ; security-dev at openjdk.java.net > Subject: downport of JDK-8209965 / JDK-8210005 > > Hi, > > we have a user running into jdk-8209965. > The downport change has been opened in August, but > not yet been worked on. > > Will this be downported to jdk11u? If this is not being worked > on by Oracle, I would request a downport. But I don't want > to interfere with your work. > > https://bugs.openjdk.java.net/browse/JDK-8209965 > https://bugs.openjdk.java.net/browse/JDK-8210005 > > Best regards, > Goetz. From weijun.wang at oracle.com Wed Nov 21 13:56:00 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 21 Nov 2018 21:56:00 +0800 Subject: RFR 8214179: Add groupname info into keytool -list and -genkeypair output Message-ID: Please take a review at https://cr.openjdk.java.net/~weijun/8214179/webrev.00/ Before this change, `keytool -genkeypair -keyalg EC -groupname brainpoolP256r1` shows Generating -1 bit EC key pair and self-signed certificate... With this change, the message becomes Generating brainpoolP256r1 EC key pair and self-signed certificate... Also, `keytool -list -v` can show Subject Public Key Algorithm: 256-bit EC(brainpoolP256r1) key Thanks Max From sean.coffey at oracle.com Wed Nov 21 15:42:15 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 21 Nov 2018 15:42:15 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> Message-ID: <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> Thanks for the comments Bernd. Comments inline.. On 16/11/18 21:27, Bernd Eckenfels wrote: > Hello Sean, > > I was only looking at the inspected DNSName class, it still has some > variations (but start now with DNSNames which is good already): > > 76 throw new IOException("DNSName must not be null or empty"); > 78 throw new IOException("*DNSNames or NameConstraints* with blank > components are not permitted"); > 80 throw new IOException("*DNSNames or NameConstraints* may not > begin or end with a ."); > 92 throw new IOException("*DNSName SubjectAltNames* with empty > components are not permitted"); > 96 throw new IOException("DNSName components must begin with a letter > or digit"); > 101 throw new IOException("DNSName components must consist of letters, > digits, and hyphens"); > > I did not check if those exceptions are catched and rethrown with > something like ?while validating the SubjectAltName Extension of > certificate ...?, in my experience it helps if you do not > have to find and review the actual certificates (in this case it might > not be a problem if SAN is only in the end entity). You can probably > remove ?or NameConstraints? and ?SubjectAltNames? from lines 78-92 > (this is good if DNsNa Ok - I've cleaned up the exception messages on line 78, 80, 92. webrev updated in place : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ > me applies to SAN or NameConstrained context and the validation logic > does not know ? so it?s not only more unified but also less missleading) > > BTW: probably not inthe scope of this fix but a subtype for validation > errors which have getters for context/location and maybe error code > and getValue() would allow callers to print nicer validation reports > without relying on the message or Stacktraces. That's a nice idea and one that should be followed up in separate enhancement. We could lean on the new `jdk.includeInExceptions` Security property which other component areas have started to use lately. e.g. https://bugs.openjdk.java.net/browse/JDK-8207768 regards, Sean. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* Se?n Coffey > *Gesendet:* Freitag, November 16, 2018 5:15 PM > *An:* Bernd Eckenfels; security-dev at openjdk.java.net > *Betreff:* Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123 > > Thanks for the comments Bernd. comments inline.. > > On 16/11/18 12:40, Bernd Eckenfels wrote: >> You could also add (a..b, false) and (.a, false), (a., false) to the >> testcases. > good point. test updated. >> >> I noticed that there are different types of Exception messages (DNS >> name, DNSName, DNS Name or name constrained, DNS name and SAN), would >> be good if all of them have the same keyword? > I cleaned up some other references to DNSName in the sun.security.x509 > package. I'm not sure what classes you were referencing the above > examples from. > > new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ > > regards, > Sean. >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ------------------------------------------------------------------------ >> *Von:* security-dev im >> Auftrag von Se?n Coffey >> *Gesendet:* Freitag, November 16, 2018 12:25 PM >> *An:* OpenJDK Dev list >> *Betreff:* RFR: 8213952: Relax DNSName restriction as per RFC 1123 >> Looking to make an adjustment to DNSName constructor to help comply with >> RFC 1123 >> >> https://bugs.openjdk.java.net/browse/JDK-8213952 >> http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ >> >> regards, >> Sean. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.mckenna at oracle.com Wed Nov 21 16:13:42 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 21 Nov 2018 16:13:42 +0000 Subject: downport of JDK-8209965 / JDK-8210005 In-Reply-To: <15c410d2ac094caaa87a1c155b406ffb@sap.com> References: <066e1004c4bd4e9a86d30d545f971e15@sap.com> <15c410d2ac094caaa87a1c155b406ffb@sap.com> Message-ID: <20181121161342.GA8225@vimes> Hi Goetz, The CPUXX_YY-critical-request indicates that the engineer is attempting to get this fix approved for inclusion in 11.0.2. This may or may not be successful (though the SQE-OK label indicates it has overcome one of the bigger hurdles) If approval is secured the fix will be pushed to the stabilization forest for 11.0.2 which in turn will have its contents pushed to the OpenJDK repo in January. -Rob On 21/11/18 08:10, Lindenmaier, Goetz wrote: > Hi, > > thanks for working on this issue! > But I'm not clear what it means that you did. > > Do I understand correctly that tag CPU19_01-critical-SQE-OK > in 8209965 means it will be fixed in the January 2019 release > of jdk11? > I.e., the change will show up on January 15th 2019 in the > open repository jdk-updates/jdk11u? > > https://bugs.openjdk.java.net/browse/JDK-8210005 > has Fix Version 11.0.3-oracle. > What does that again mean? Does it mean you pushed > the change to an internal repository that will be used > to build the commercial OracleJDK release in April 2019? > As I understand, the jdk 11.0.3 repo prepared by Oracle > will not be released to the open. > > These two pieces of information don't fit together in > my mind :) > > Best regards, > Goetz. > > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Freitag, 16. November 2018 15:07 > > To: 'Xuelei Fan' ; 'Prasadrao Koppula' > > > > Cc: Alan Bateman (alan.bateman at oracle.com) > > ; security-dev at openjdk.java.net > > Subject: downport of JDK-8209965 / JDK-8210005 > > > > Hi, > > > > we have a user running into jdk-8209965. > > The downport change has been opened in August, but > > not yet been worked on. > > > > Will this be downported to jdk11u? If this is not being worked > > on by Oracle, I would request a downport. But I don't want > > to interfere with your work. > > > > https://bugs.openjdk.java.net/browse/JDK-8209965 > > https://bugs.openjdk.java.net/browse/JDK-8210005 > > > > Best regards, > > Goetz. From rob.mckenna at oracle.com Wed Nov 21 16:35:28 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 21 Nov 2018 16:35:28 +0000 Subject: downport of JDK-8209965 / JDK-8210005 In-Reply-To: <20181121161342.GA8225@vimes> References: <066e1004c4bd4e9a86d30d545f971e15@sap.com> <15c410d2ac094caaa87a1c155b406ffb@sap.com> <20181121161342.GA8225@vimes> Message-ID: <20181121163528.GA10801@vimes> ..11.0.3-oracle represents the Oracle JDK release scheduled for April 2019 as you correctly note. -Rob On 21/11/18 16:13, Rob McKenna wrote: > Hi Goetz, > > The CPUXX_YY-critical-request indicates that the engineer is attempting > to get this fix approved for inclusion in 11.0.2. This may or may not > be successful (though the SQE-OK label indicates it has overcome one of > the bigger hurdles) If approval is secured the fix will be pushed to the > stabilization forest for 11.0.2 which in turn will have its contents > pushed to the OpenJDK repo in January. > > -Rob > > On 21/11/18 08:10, Lindenmaier, Goetz wrote: > > Hi, > > > > thanks for working on this issue! > > But I'm not clear what it means that you did. > > > > Do I understand correctly that tag CPU19_01-critical-SQE-OK > > in 8209965 means it will be fixed in the January 2019 release > > of jdk11? > > I.e., the change will show up on January 15th 2019 in the > > open repository jdk-updates/jdk11u? > > > > https://bugs.openjdk.java.net/browse/JDK-8210005 > > has Fix Version 11.0.3-oracle. > > What does that again mean? Does it mean you pushed > > the change to an internal repository that will be used > > to build the commercial OracleJDK release in April 2019? > > As I understand, the jdk 11.0.3 repo prepared by Oracle > > will not be released to the open. > > > > These two pieces of information don't fit together in > > my mind :) > > > > Best regards, > > Goetz. > > > > > > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz > > > Sent: Freitag, 16. November 2018 15:07 > > > To: 'Xuelei Fan' ; 'Prasadrao Koppula' > > > > > > Cc: Alan Bateman (alan.bateman at oracle.com) > > > ; security-dev at openjdk.java.net > > > Subject: downport of JDK-8209965 / JDK-8210005 > > > > > > Hi, > > > > > > we have a user running into jdk-8209965. > > > The downport change has been opened in August, but > > > not yet been worked on. > > > > > > Will this be downported to jdk11u? If this is not being worked > > > on by Oracle, I would request a downport. But I don't want > > > to interfere with your work. > > > > > > https://bugs.openjdk.java.net/browse/JDK-8209965 > > > https://bugs.openjdk.java.net/browse/JDK-8210005 > > > > > > Best regards, > > > Goetz. From sean.coffey at oracle.com Wed Nov 21 16:51:09 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 21 Nov 2018 16:51:09 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> Message-ID: p.s I've updated the testcase to test the IOException message for presence of "DNSName". Webrev updated in place. Regards, Sean. On 21/11/18 15:42, Se?n Coffey wrote: > > Thanks for the comments Bernd. Comments inline.. > > On 16/11/18 21:27, Bernd Eckenfels wrote: >> Hello Sean, >> >> I was only looking at the inspected DNSName class, it still has some >> variations (but start now with DNSNames which is good already): >> >> 76 throw new IOException("DNSName must not be null or empty"); >> 78 throw new IOException("*DNSNames or NameConstraints* with blank >> components are not permitted"); >> 80 throw new IOException("*DNSNames or NameConstraints* may not >> begin or end with a ."); >> 92 throw new IOException("*DNSName SubjectAltNames* with empty >> components are not permitted"); >> 96 throw new IOException("DNSName components must begin with a >> letter or digit"); >> 101 throw new IOException("DNSName components must consist of >> letters, digits, and hyphens"); >> >> I did not check if those exceptions are catched and rethrown with >> something like ?while validating the SubjectAltName Extension >> of certificate ...?, in my experience it helps if you do not >> have to find and review the actual certificates (in this case it >> might not be a problem if SAN is only in the end entity). You can >> probably remove ?or NameConstraints? and ?SubjectAltNames? from lines >> 78-92 (this is good if DNsNa > Ok - I've cleaned up the exception messages on line 78, 80, 92. > webrev updated in place : > http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ > > >> me applies to SAN or NameConstrained context and the validation logic >> does not know ? so it?s not only more unified but also less missleading) >> >> BTW: probably not inthe scope of this fix but a subtype for >> validation errors which have getters for context/location and maybe >> error code and getValue() would allow callers to print nicer >> validation reports without relying on the message or Stacktraces. > > That's a nice idea and one that should be followed up in separate > enhancement. We could lean on the new `jdk.includeInExceptions` > Security property which other component areas have started to use lately. > > e.g. https://bugs.openjdk.java.net/browse/JDK-8207768 > > regards, > Sean. >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> ------------------------------------------------------------------------ >> *Von:* Se?n Coffey >> *Gesendet:* Freitag, November 16, 2018 5:15 PM >> *An:* Bernd Eckenfels; security-dev at openjdk.java.net >> *Betreff:* Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123 >> >> Thanks for the comments Bernd. comments inline.. >> >> On 16/11/18 12:40, Bernd Eckenfels wrote: >>> You could also add (a..b, false) and (.a, false), (a., false) to the >>> testcases. >> good point. test updated. >>> >>> I noticed that there are different types of Exception messages (DNS >>> name, DNSName, DNS Name or name constrained, DNS name and SAN), >>> would be good if all of them have the same keyword? >> I cleaned up some other references to DNSName in the >> sun.security.x509 package. I'm not sure what classes you were >> referencing the above examples from. >> >> new webrev : >> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >> >> regards, >> Sean. >>> >>> Gruss >>> Bernd >>> -- >>> http://bernd.eckenfels.net >>> ------------------------------------------------------------------------ >>> *Von:* security-dev im >>> Auftrag von Se?n Coffey >>> *Gesendet:* Freitag, November 16, 2018 12:25 PM >>> *An:* OpenJDK Dev list >>> *Betreff:* RFR: 8213952: Relax DNSName restriction as per RFC 1123 >>> Looking to make an adjustment to DNSName constructor to help comply >>> with >>> RFC 1123 >>> >>> https://bugs.openjdk.java.net/browse/JDK-8213952 >>> http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ >>> >>> regards, >>> Sean. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Nov 21 17:37:05 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Nov 2018 17:37:05 +0000 Subject: Problems with AES-GCM native acceleration In-Reply-To: References: <92a16009b9e047eacf102b006bc0612bac4a2cfb.camel@redhat.com> <1b1fe9e4-ad71-7d48-13eb-48dbe267962e@oracle.com> <864a763d-0d67-d894-234c-fbbef78e0320@oracle.com> Message-ID: On 11/15/18 10:42 AM, Gidon Gershinsky wrote: > Having the decryption optimized in the HotSpot engine would be ideal. I agree with you. I did a few experiments, and it can take a very long time for C2 compilation to kick in, especially because GCM is glacially slow until the intrinsics are used. I think this would be a generally useful enhancement to HotSpot, and I'm kicking around an experimental patch which adds the intrinsics to c1 and the interpreter. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From valerie.peng at oracle.com Wed Nov 21 18:05:53 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 21 Nov 2018 10:05:53 -0800 Subject: RFR JDK-7092821 "java.security.Provider.getService() is synchronized and became scalability bottleneck" Message-ID: <74e5734e-9c33-6bd4-e3b4-551c975a39a6@oracle.com> Hi, Can someone help reviewing this fix? Besides changing the Provider class to use ConcurrentHashMap in order to reduce the lock contention on Provider.getService() calls, I also changed the security providers in java.base module to register through putService(...) calls. Performance is manually verified and mach5 run is clean. Bug: https://bugs.openjdk.java.net/browse/JDK-7092821 Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Thu Nov 22 01:14:12 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 21 Nov 2018 17:14:12 -0800 Subject: RFR 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> Message-ID: <1ede21e9-b40d-2044-f7ec-5a6230913231@oracle.com> Hi Max, Here are some comments: - line 39, add PSS here as well. - line 97, CSignature ctr, better to initialize all fields - line 109, has key algorithm been checked by JCA already? If not, it should be checked here. Same goes for line 414, and 560 - with the class renaming, I think it's clearer to include "RSA" as part of the subclass names, e.g. "MD2withRSA" instead of just "MD2" - line 681: can be static, right? pkg-private? - line 120: maybe a ProviderException instead of IllegalArgumentException as the 'alg' is not from user but rather inside the provider. - line 127, add @Override - line 140, must getPublicKeyBob be public? Maybe pkg private? - line 119: why not just use RSAPrivateCrtKey instead of Key? The caller has already did an instanceof check before this method. - would be nice to have a String constant for "RSA". Rest looks fine. Thanks, Valerie On 11/15/2018 7:40 AM, Weijun Wang wrote: > Oops, my copy/paste sequence goes wrong. > >> On Nov 15, 2018, at 11:38 PM, Weijun Wang wrote: >> >> Webrev updated at >> > https://cr.openjdk.java.net/~weijun/8213009/webrev.01/ > >> More refactorings: >> >> - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey. >> >> - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA. >> >> - CPublicKey and CPrivateKey now have a static of() method that can return a child instance. >> >> - CCipher renamed to CRSACipher. I realized there won't be CECCipher. >> >> Thanks >> Max >> >> >>> On Nov 7, 2018, at 12:13 AM, Weijun Wang wrote: >>> >>> Webrev updated at >>> >>> https://cr.openjdk.java.net/~weijun/8213009/webrev.00/ >>> >>> The subtask id is now used. >>> >>> The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back. >>> >>> Thanks >>> Max >>> >>>> On Oct 25, 2018, at 4:38 PM, Weijun Wang wrote: >>>> >>>> Please review the change at >>>> >>>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >>>> >>>> (I will use a sub-task id for this change but currently JBS is down). >>>> >>>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >>>> >>>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >>>> >>>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >>>> >>>> - Child class named "RSA" of CKeyPairGenerator. >>>> >>>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >>>> >>>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >>>> >>>> Noreg-cleanup. >>>> >>>> Thanks >>>> Max >>>> >>>> [1] https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier From goetz.lindenmaier at sap.com Thu Nov 22 07:51:15 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 22 Nov 2018 07:51:15 +0000 Subject: downport of JDK-8209965 / JDK-8210005 In-Reply-To: <20181121163528.GA10801@vimes> References: <066e1004c4bd4e9a86d30d545f971e15@sap.com> <15c410d2ac094caaa87a1c155b406ffb@sap.com> <20181121161342.GA8225@vimes> <20181121163528.GA10801@vimes> Message-ID: <5c9c25d3d95f405893854bc26d425b02@sap.com> HI Rob, thanks for the update! Seems it was accepted for 11.0.2 ... So I don't need to take action. Best regards, Goetz. > -----Original Message----- > From: Rob McKenna > Sent: Mittwoch, 21. November 2018 17:35 > To: Lindenmaier, Goetz > Cc: security-dev at openjdk.java.net > Subject: Re: downport of JDK-8209965 / JDK-8210005 > > ..11.0.3-oracle represents the Oracle JDK release scheduled for April 2019 > as you correctly note. > > -Rob > > On 21/11/18 16:13, Rob McKenna wrote: > > Hi Goetz, > > > > The CPUXX_YY-critical-request indicates that the engineer is attempting > > to get this fix approved for inclusion in 11.0.2. This may or may not > > be successful (though the SQE-OK label indicates it has overcome one of > > the bigger hurdles) If approval is secured the fix will be pushed to the > > stabilization forest for 11.0.2 which in turn will have its contents > > pushed to the OpenJDK repo in January. > > > > -Rob > > > > On 21/11/18 08:10, Lindenmaier, Goetz wrote: > > > Hi, > > > > > > thanks for working on this issue! > > > But I'm not clear what it means that you did. > > > > > > Do I understand correctly that tag CPU19_01-critical-SQE-OK > > > in 8209965 means it will be fixed in the January 2019 release > > > of jdk11? > > > I.e., the change will show up on January 15th 2019 in the > > > open repository jdk-updates/jdk11u? > > > > > > https://bugs.openjdk.java.net/browse/JDK-8210005 > > > has Fix Version 11.0.3-oracle. > > > What does that again mean? Does it mean you pushed > > > the change to an internal repository that will be used > > > to build the commercial OracleJDK release in April 2019? > > > As I understand, the jdk 11.0.3 repo prepared by Oracle > > > will not be released to the open. > > > > > > These two pieces of information don't fit together in > > > my mind :) > > > > > > Best regards, > > > Goetz. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Lindenmaier, Goetz > > > > Sent: Freitag, 16. November 2018 15:07 > > > > To: 'Xuelei Fan' ; 'Prasadrao Koppula' > > > > > > > > Cc: Alan Bateman (alan.bateman at oracle.com) > > > > ; security-dev at openjdk.java.net > > > > Subject: downport of JDK-8209965 / JDK-8210005 > > > > > > > > Hi, > > > > > > > > we have a user running into jdk-8209965. > > > > The downport change has been opened in August, but > > > > not yet been worked on. > > > > > > > > Will this be downported to jdk11u? If this is not being worked > > > > on by Oracle, I would request a downport. But I don't want > > > > to interfere with your work. > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8209965 > > > > https://bugs.openjdk.java.net/browse/JDK-8210005 > > > > > > > > Best regards, > > > > Goetz. From weijun.wang at oracle.com Thu Nov 22 13:12:16 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 22 Nov 2018 21:12:16 +0800 Subject: RFR 8214100: use of keystore probing results in unnecessary exception thrown Message-ID: Please take a review at https://cr.openjdk.java.net/~weijun/8214100/webrev.00/ Some exception handling codes are added to keytool when the keystore type does not support probing. Thanks Max From weijun.wang at oracle.com Thu Nov 22 14:04:48 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 22 Nov 2018 22:04:48 +0800 Subject: RFR 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: <1ede21e9-b40d-2044-f7ec-5a6230913231@oracle.com> References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> <1ede21e9-b40d-2044-f7ec-5a6230913231@oracle.com> Message-ID: > On Nov 22, 2018, at 9:14 AM, Valerie Peng wrote: > > Hi Max, > > Here are some comments: > > > - line 39, add PSS here as well. > - line 97, CSignature ctr, better to initialize all fields Which particular ones are you thinking about? privateKey and publicKey will be initialized later and messageDigest/messageDigestAlgorithm/needsReset will be useless when digestName == null. > - line 109, has key algorithm been checked by JCA already? If not, it should be checked here. Same goes for line 414, and 560 Can I do this later? This sub-task is meant to be a cleanup. But I think I need to move more RSA related methods into the RSA subclass. > - with the class renaming, I think it's clearer to include "RSA" as part of the subclass names, e.g. "MD2withRSA" instead of just "MD2" OK. > - line 681: can be static, right? pkg-private? Yes. Looks like it can be private. > > > - line 120: maybe a ProviderException instead of IllegalArgumentException as the 'alg' is not from user but rather inside the provider. Either is OK for me. Since it's only called inside the provider, it can even be an AssertionError. > - line 127, add @Override OK. > - line 140, must getPublicKeyBob be public? Maybe pkg private? Correct. > > > - line 119: why not just use RSAPrivateCrtKey instead of Key? The caller has already did an instanceof check before this method. Correct. I think I should rename both setPrivateKey and generatePrivateKeyBlob to setRSAPrivateKey and generateRSAPrivateKeyBlob. If one day I starts supporting EC keys the methods will be quite different. > > > - would be nice to have a String constant for "RSA". Sure. Thanks Max > > Rest looks fine. > Thanks, > Valerie > > > On 11/15/2018 7:40 AM, Weijun Wang wrote: >> Oops, my copy/paste sequence goes wrong. >> >>> On Nov 15, 2018, at 11:38 PM, Weijun Wang wrote: >>> >>> Webrev updated at >>> >> https://cr.openjdk.java.net/~weijun/8213009/webrev.01/ >> >>> More refactorings: >>> >>> - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey. >>> >>> - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA. >>> >>> - CPublicKey and CPrivateKey now have a static of() method that can return a child instance. >>> >>> - CCipher renamed to CRSACipher. I realized there won't be CECCipher. >>> >>> Thanks >>> Max >>> >>> >>>> On Nov 7, 2018, at 12:13 AM, Weijun Wang wrote: >>>> >>>> Webrev updated at >>>> >>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.00/ >>>> >>>> The subtask id is now used. >>>> >>>> The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back. >>>> >>>> Thanks >>>> Max >>>> >>>>> On Oct 25, 2018, at 4:38 PM, Weijun Wang wrote: >>>>> >>>>> Please review the change at >>>>> >>>>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >>>>> >>>>> (I will use a sub-task id for this change but currently JBS is down). >>>>> >>>>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >>>>> >>>>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >>>>> >>>>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >>>>> >>>>> - Child class named "RSA" of CKeyPairGenerator. >>>>> >>>>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >>>>> >>>>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >>>>> >>>>> Noreg-cleanup. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> [1] https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier > From weijun.wang at oracle.com Thu Nov 22 14:49:49 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 22 Nov 2018 22:49:49 +0800 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> Message-ID: <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com> * DNSName.java: 91 if ((endIndex - startIndex) < 1) No need for inner parentheses. And, is there really a need to define alphaDigitsAndHyphen? How about just (== '-' || inside alphaDigits)? * DNSNameTest.java: Space cannot appear anywhere, please add a test case like "a c.com". BTW, I assume you want to reuse this test for other sub-tasks of JDK-8054380? I see the @summary is more general. No other comments. Thanks Max > On Nov 22, 2018, at 12:51 AM, Se?n Coffey wrote: > > p.s I've updated the testcase to test the IOException message for presence of "DNSName". Webrev updated in place. > > Regards, > Sean. > > On 21/11/18 15:42, Se?n Coffey wrote: >> Thanks for the comments Bernd. Comments inline.. >> >> On 16/11/18 21:27, Bernd Eckenfels wrote: >>> Hello Sean, >>> >>> I was only looking at the inspected DNSName class, it still has some variations (but start now with DNSNames which is good already): >>> >>> 76 throw new IOException("DNSName must not be null or empty"); >>> 78 throw new IOException("DNSNames or NameConstraints with blank components are not permitted"); >>> 80 throw new IOException("DNSNames or NameConstraints may not begin or end with a ."); >>> 92 throw new IOException("DNSName SubjectAltNames with empty components are not permitted"); >>> 96 throw new IOException("DNSName components must begin with a letter or digit"); >>> 101 throw new IOException("DNSName components must consist of letters, digits, and hyphens"); >>> >>> I did not check if those exceptions are catched and rethrown with something like ?while validating the SubjectAltName Extension of certificate ...?, in my experience it helps if you do not have to find and review the actual certificates (in this case it might not be a problem if SAN is only in the end entity). You can probably remove ?or NameConstraints? and ?SubjectAltNames? from lines 78-92 (this is good if DNsNa >> Ok - I've cleaned up the exception messages on line 78, 80, 92. >> webrev updated in place : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >> >> >>> me applies to SAN or NameConstrained context and the validation logic does not know ? so it?s not only more unified but also less missleading) >>> >>> BTW: probably not inthe scope of this fix but a subtype for validation errors which have getters for context/location and maybe error code and getValue() would allow callers to print nicer validation reports without relying on the message or Stacktraces. >> >> That's a nice idea and one that should be followed up in separate enhancement. We could lean on the new `jdk.includeInExceptions` Security property which other component areas have started to use lately. >> >> e.g. https://bugs.openjdk.java.net/browse/JDK-8207768 >> >> regards, >> Sean. >>> >>> Gruss >>> Bernd >>> -- >>> http://bernd.eckenfels.net >>> >>> Von: Se?n Coffey >>> Gesendet: Freitag, November 16, 2018 5:15 PM >>> An: Bernd Eckenfels; security-dev at openjdk.java.net >>> Betreff: Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123 >>> >>> Thanks for the comments Bernd. comments inline.. >>> >>> On 16/11/18 12:40, Bernd Eckenfels wrote: >>>> You could also add (a..b, false) and (.a, false), (a., false) to the testcases. >>> good point. test updated. >>>> >>>> I noticed that there are different types of Exception messages (DNS name, DNSName, DNS Name or name constrained, DNS name and SAN), would be good if all of them have the same keyword? >>> I cleaned up some other references to DNSName in the sun.security.x509 package. I'm not sure what classes you were referencing the above examples from. >>> >>> new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >>> >>> regards, >>> Sean. >>>> >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> >>>> Von: security-dev im Auftrag von Se?n Coffey >>>> Gesendet: Freitag, November 16, 2018 12:25 PM >>>> An: OpenJDK Dev list >>>> Betreff: RFR: 8213952: Relax DNSName restriction as per RFC 1123 >>>> >>>> Looking to make an adjustment to DNSName constructor to help comply with >>>> RFC 1123 >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8213952 >>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >>> >> > > From weijun.wang at oracle.com Fri Nov 23 14:31:12 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 23 Nov 2018 22:31:12 +0800 Subject: RFR 8214262: SunEC native code does not compile with debug on Message-ID: I was curious in some SunEC internals and turned EC_DEBUG on, and found out the library cannot be built. It looks like back when we switched to warnings-as-errors some codes are not updated. Here is the patch: diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c --- a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c +++ b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c @@ -109,16 +109,16 @@ printf("\n"); if (k1 != NULL) { - mp_tohex(k1, mpstr); + mp_tohex((mp_int*)k1, mpstr); printf("ec_points_mul: scalar k1: %s\n", mpstr); - mp_todecimal(k1, mpstr); + mp_todecimal((mp_int*)k1, mpstr); printf("ec_points_mul: scalar k1: %s (dec)\n", mpstr); } if (k2 != NULL) { - mp_tohex(k2, mpstr); + mp_tohex((mp_int*)k2, mpstr); printf("ec_points_mul: scalar k2: %s\n", mpstr); - mp_todecimal(k2, mpstr); + mp_todecimal((mp_int*)k2, mpstr); printf("ec_points_mul: scalar k2: %s (dec)\n", mpstr); } diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c b/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c --- a/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c +++ b/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c @@ -55,6 +55,9 @@ #include "ecl-curve.h" #include "ecc_impl.h" +#if EC_DEBUG +#include +#endif #define MAX_ECKEY_LEN 72 #define SEC_ASN1_OBJECT_ID 0x06 In the first file, k1 and k2 are defined as const mp_int * but mp_tohex accepts a mp_int* as its 1st argument. In the second file, there is a printf call in a EC_DEBUG block. Noreg-cleanup. Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Fri Nov 23 16:45:20 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 23 Nov 2018 16:45:20 +0000 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com> References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com> Message-ID: <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com> Thanks for your review Max. I've made the suggested edits. http://cr.openjdk.java.net/~coffeys/webrev.8213952.v3/webrev/ I've also submitted a CSR for this change just to cover the behavioural aspect of the edit. Will push if/once that's approved by CSR team. Regards, Sean. On 22/11/18 14:49, Weijun Wang wrote: > * DNSName.java: > > 91 if ((endIndex - startIndex) < 1) > > No need for inner parentheses. > > And, is there really a need to define alphaDigitsAndHyphen? How about just (== '-' || inside alphaDigits)? > > * DNSNameTest.java: > > Space cannot appear anywhere, please add a test case like "a c.com". > > BTW, I assume you want to reuse this test for other sub-tasks of JDK-8054380? I see the @summary is more general. > > No other comments. > > Thanks > Max > >> On Nov 22, 2018, at 12:51 AM, Se?n Coffey wrote: >> >> p.s I've updated the testcase to test the IOException message for presence of "DNSName". Webrev updated in place. >> >> Regards, >> Sean. >> >> On 21/11/18 15:42, Se?n Coffey wrote: >>> Thanks for the comments Bernd. Comments inline.. >>> >>> On 16/11/18 21:27, Bernd Eckenfels wrote: >>>> Hello Sean, >>>> >>>> I was only looking at the inspected DNSName class, it still has some variations (but start now with DNSNames which is good already): >>>> >>>> 76 throw new IOException("DNSName must not be null or empty"); >>>> 78 throw new IOException("DNSNames or NameConstraints with blank components are not permitted"); >>>> 80 throw new IOException("DNSNames or NameConstraints may not begin or end with a ."); >>>> 92 throw new IOException("DNSName SubjectAltNames with empty components are not permitted"); >>>> 96 throw new IOException("DNSName components must begin with a letter or digit"); >>>> 101 throw new IOException("DNSName components must consist of letters, digits, and hyphens"); >>>> >>>> I did not check if those exceptions are catched and rethrown with something like ?while validating the SubjectAltName Extension of certificate ...?, in my experience it helps if you do not have to find and review the actual certificates (in this case it might not be a problem if SAN is only in the end entity). You can probably remove ?or NameConstraints? and ?SubjectAltNames? from lines 78-92 (this is good if DNsNa >>> Ok - I've cleaned up the exception messages on line 78, 80, 92. >>> webrev updated in place : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >>> >>> >>>> me applies to SAN or NameConstrained context and the validation logic does not know ? so it?s not only more unified but also less missleading) >>>> >>>> BTW: probably not inthe scope of this fix but a subtype for validation errors which have getters for context/location and maybe error code and getValue() would allow callers to print nicer validation reports without relying on the message or Stacktraces. >>> That's a nice idea and one that should be followed up in separate enhancement. We could lean on the new `jdk.includeInExceptions` Security property which other component areas have started to use lately. >>> >>> e.g. https://bugs.openjdk.java.net/browse/JDK-8207768 >>> >>> regards, >>> Sean. >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> >>>> Von: Se?n Coffey >>>> Gesendet: Freitag, November 16, 2018 5:15 PM >>>> An: Bernd Eckenfels; security-dev at openjdk.java.net >>>> Betreff: Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123 >>>> >>>> Thanks for the comments Bernd. comments inline.. >>>> >>>> On 16/11/18 12:40, Bernd Eckenfels wrote: >>>>> You could also add (a..b, false) and (.a, false), (a., false) to the testcases. >>>> good point. test updated. >>>>> I noticed that there are different types of Exception messages (DNS name, DNSName, DNS Name or name constrained, DNS name and SAN), would be good if all of them have the same keyword? >>>> I cleaned up some other references to DNSName in the sun.security.x509 package. I'm not sure what classes you were referencing the above examples from. >>>> >>>> new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >>>> >>>> regards, >>>> Sean. >>>>> Gruss >>>>> Bernd >>>>> -- >>>>> http://bernd.eckenfels.net >>>>> >>>>> Von: security-dev im Auftrag von Se?n Coffey >>>>> Gesendet: Freitag, November 16, 2018 12:25 PM >>>>> An: OpenJDK Dev list >>>>> Betreff: RFR: 8213952: Relax DNSName restriction as per RFC 1123 >>>>> >>>>> Looking to make an adjustment to DNSName constructor to help comply with >>>>> RFC 1123 >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8213952 >>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ >>>>> >>>>> regards, >>>>> Sean. >>>>> >> From weijun.wang at oracle.com Sat Nov 24 15:03:12 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 24 Nov 2018 23:03:12 +0800 Subject: RFR 8214262: SunEC native code does not compile with debug on In-Reply-To: References: Message-ID: Oops, when EC_DEBUG is 1 build fails on Windows. Looks like ec.c also calls printf and stdio.h is not included on Windows. Patch updated below. I would just include stdio.h unconditionally. Thanks Max diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c --- a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c +++ b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c @@ -43,11 +43,11 @@ #include #ifndef _KERNEL +#include #include #include #ifndef _WIN32 -#include #include #endif /* _WIN32 */ @@ -109,16 +109,16 @@ printf("\n"); if (k1 != NULL) { - mp_tohex(k1, mpstr); + mp_tohex((mp_int*)k1, mpstr); printf("ec_points_mul: scalar k1: %s\n", mpstr); - mp_todecimal(k1, mpstr); + mp_todecimal((mp_int*)k1, mpstr); printf("ec_points_mul: scalar k1: %s (dec)\n", mpstr); } if (k2 != NULL) { - mp_tohex(k2, mpstr); + mp_tohex((mp_int*)k2, mpstr); printf("ec_points_mul: scalar k2: %s\n", mpstr); - mp_todecimal(k2, mpstr); + mp_todecimal((mp_int*)k2, mpstr); printf("ec_points_mul: scalar k2: %s (dec)\n", mpstr); } diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c b/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c --- a/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c +++ b/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c @@ -49,6 +49,7 @@ #ifdef _KERNEL #include #else +#include #include #endif #include "ec.h" Thanks Max > On Nov 23, 2018, at 10:31 PM, Weijun Wang wrote: > > I was curious in some SunEC internals and turned EC_DEBUG on, and found out the library cannot be built. It looks like back when we switched to warnings-as-errors some codes are not updated. Here is the patch: > > diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c > --- a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c > +++ b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c > @@ -109,16 +109,16 @@ > printf("\n"); > > if (k1 != NULL) { > - mp_tohex(k1, mpstr); > + mp_tohex((mp_int*)k1, mpstr); > printf("ec_points_mul: scalar k1: %s\n", mpstr); > - mp_todecimal(k1, mpstr); > + mp_todecimal((mp_int*)k1, mpstr); > printf("ec_points_mul: scalar k1: %s (dec)\n", mpstr); > } > > if (k2 != NULL) { > - mp_tohex(k2, mpstr); > + mp_tohex((mp_int*)k2, mpstr); > printf("ec_points_mul: scalar k2: %s\n", mpstr); > - mp_todecimal(k2, mpstr); > + mp_todecimal((mp_int*)k2, mpstr); > printf("ec_points_mul: scalar k2: %s (dec)\n", mpstr); > } > > diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c b/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c > --- a/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c > +++ b/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c > @@ -55,6 +55,9 @@ > #include "ecl-curve.h" > #include "ecc_impl.h" > > +#if EC_DEBUG > +#include > +#endif > #define MAX_ECKEY_LEN 72 > #define SEC_ASN1_OBJECT_ID 0x06 > > In the first file, k1 and k2 are defined as const mp_int * but mp_tohex accepts a mp_int* as its 1st argument. > > In the second file, there is a printf call in a EC_DEBUG block. > > Noreg-cleanup. > > Thanks > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Sun Nov 25 05:50:43 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 24 Nov 2018 21:50:43 -0800 Subject: RFR 8214262: SunEC native code does not compile with debug on In-Reply-To: References: Message-ID: Hi Max, The changes look fine.? I did notice in the files that there is a header block comment that has a last modified date from the original code.? Should those be updated to 2018? --Jamil On 11/23/2018 6:31 AM, Weijun Wang wrote: > I was curious in some SunEC internals and turned EC_DEBUG on, and > found out the library cannot be built. It looks like back when we > switched to warnings-as-errors some codes are not updated. Here is the > patch: > > *diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c > b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c* > *--- a/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c* > *+++ b/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c* > @@ -109,16 +109,16 @@ > ? printf("\n"); > > > ? ? ? if (k1 != NULL) { > - ? ? ? ? ? ? ? mp_tohex(k1, mpstr); > + ? ? ? ? ? ? ? mp_tohex((mp_int*)k1, mpstr); > ? ? ? ? ? ? ? printf("ec_points_mul: scalar k1: %s\n", mpstr); > - ? ? ? ? ? ? ? mp_todecimal(k1, mpstr); > + ? ? ? ? ? ? ? mp_todecimal((mp_int*)k1, mpstr); > ? ? ? ? ? ? ? printf("ec_points_mul: scalar k1: %s (dec)\n", mpstr); > ? ? ? } > > > ? ? ? if (k2 != NULL) { > - ? ? ? ? ? ? ? mp_tohex(k2, mpstr); > + ? ? ? ? ? ? ? mp_tohex((mp_int*)k2, mpstr); > ? ? ? ? ? ? ? printf("ec_points_mul: scalar k2: %s\n", mpstr); > - ? ? ? ? ? ? ? mp_todecimal(k2, mpstr); > + ? ? ? ? ? ? ? mp_todecimal((mp_int*)k2, mpstr); > ? ? ? ? ? ? ? printf("ec_points_mul: scalar k2: %s (dec)\n", mpstr); > ? ? ? } > > > *diff --git a/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c > b/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c* > *--- a/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c* > *+++ b/src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c* > @@ -55,6 +55,9 @@ > ?#include "ecl-curve.h" > ?#include "ecc_impl.h" > > > +#if EC_DEBUG > +#include > +#endif > ?#define MAX_ECKEY_LEN ? ? ? ? ? 72 > ?#define SEC_ASN1_OBJECT_ID? ? ? 0x06 > > In the first file, k1 and k2 are defined as const?mp_int * but > mp_tohex accepts a mp_int* as its 1st argument. > > In the second file, there is a printf call in a EC_DEBUG block. > > Noreg-cleanup. > > Thanks > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Nov 26 03:07:39 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 26 Nov 2018 11:07:39 +0800 Subject: RFR 8213009: Refactoring existing SunMSCAPI classes In-Reply-To: References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com> <1ede21e9-b40d-2044-f7ec-5a6230913231@oracle.com> Message-ID: Hi Valerie Updated webrev at https://cr.openjdk.java.net/~weijun/8213009/webrev.02 Changes: - CSignature.java: * Mentions "RSASSA-PSS" in class spec of CSignature. * CSignature.RSA child classes renamed, For example, Raw -> NONEwithRSA, SHA1 -> SHA1withRSA. References (both class name and string) also updated in SunMSCAPI.java. * Move CSignature::generatePublicKeyBlob into child class, CSignature$RSA::generatePublicKeyBlob. * Move CSignature::engineInitVerify into child class, CSignature$RSA::engineInitVerify - CKeyStore.java *Rename generatePrivateKeyBlob to generateRSAPrivateKeyBlob and setPrivateKey to setRSAPrivateKey (thus no more instanceof check). - CPublicKey.java * When CPublicKey.of(alg,...) sees an unknown alg, AssertionError("Unsupported algorithm: " + alg) is now thrown. * Add @Override to toString. * Make CPublicKey::getPublicKeyBlob package private. - Extract "RSA" as a constant in the test. - Many coding style changes, especially, moving open braces to the end of the previous lines. Thanks Max > On Nov 22, 2018, at 10:04 PM, Weijun Wang wrote: > > > >> On Nov 22, 2018, at 9:14 AM, Valerie Peng wrote: >> >> Hi Max, >> >> Here are some comments: >> >> >> - line 39, add PSS here as well. >> - line 97, CSignature ctr, better to initialize all fields > > Which particular ones are you thinking about? privateKey and publicKey will be initialized later and messageDigest/messageDigestAlgorithm/needsReset will be useless when digestName == null. > >> - line 109, has key algorithm been checked by JCA already? If not, it should be checked here. Same goes for line 414, and 560 > > Can I do this later? This sub-task is meant to be a cleanup. > > But I think I need to move more RSA related methods into the RSA subclass. > >> - with the class renaming, I think it's clearer to include "RSA" as part of the subclass names, e.g. "MD2withRSA" instead of just "MD2" > > OK. > >> - line 681: can be static, right? pkg-private? > > Yes. Looks like it can be private. > >> >> >> - line 120: maybe a ProviderException instead of IllegalArgumentException as the 'alg' is not from user but rather inside the provider. > > Either is OK for me. Since it's only called inside the provider, it can even be an AssertionError. > >> - line 127, add @Override > > OK. > >> - line 140, must getPublicKeyBob be public? Maybe pkg private? > > Correct. > >> >> >> - line 119: why not just use RSAPrivateCrtKey instead of Key? The caller has already did an instanceof check before this method. > > Correct. I think I should rename both setPrivateKey and generatePrivateKeyBlob to setRSAPrivateKey and generateRSAPrivateKeyBlob. If one day I starts supporting EC keys the methods will be quite different. > >> >> >> - would be nice to have a String constant for "RSA". > > Sure. > > Thanks > Max > >> >> Rest looks fine. >> Thanks, >> Valerie >> >> >> On 11/15/2018 7:40 AM, Weijun Wang wrote: >>> Oops, my copy/paste sequence goes wrong. >>> >>>> On Nov 15, 2018, at 11:38 PM, Weijun Wang wrote: >>>> >>>> Webrev updated at >>>> >>> https://cr.openjdk.java.net/~weijun/8213009/webrev.01/ >>> >>>> More refactorings: >>>> >>>> - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey. >>>> >>>> - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA. >>>> >>>> - CPublicKey and CPrivateKey now have a static of() method that can return a child instance. >>>> >>>> - CCipher renamed to CRSACipher. I realized there won't be CECCipher. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>>> On Nov 7, 2018, at 12:13 AM, Weijun Wang wrote: >>>>> >>>>> Webrev updated at >>>>> >>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.00/ >>>>> >>>>> The subtask id is now used. >>>>> >>>>> The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Oct 25, 2018, at 4:38 PM, Weijun Wang wrote: >>>>>> >>>>>> Please review the change at >>>>>> >>>>>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >>>>>> >>>>>> (I will use a sub-task id for this change but currently JBS is down). >>>>>> >>>>>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >>>>>> >>>>>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >>>>>> >>>>>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >>>>>> >>>>>> - Child class named "RSA" of CKeyPairGenerator. >>>>>> >>>>>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >>>>>> >>>>>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >>>>>> >>>>>> Noreg-cleanup. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> [1] https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier >> > From weijun.wang at oracle.com Mon Nov 26 03:15:58 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 26 Nov 2018 11:15:58 +0800 Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123 In-Reply-To: <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com> References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com> <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com> <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com> <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com> <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com> Message-ID: > On Nov 24, 2018, at 12:45 AM, Se?n Coffey wrote: > > Thanks for your review Max. I've made the suggested edits. > http://cr.openjdk.java.net/~coffeys/webrev.8213952.v3/webrev/ The change looks fine. Thanks. > > I've also submitted a CSR for this change just to cover the behavioural aspect of the edit. Will push if/once that's approved by CSR team. The CSR focuses on keytool but this is actually a library change. There is no change with "add/remove/modify command line option" at all. I would suggest talking about the DNSName class instead of keytool. I understand it's internal but we can describe this change as a non-minimal change on behavior so it's still worth a CSR. Or, you can consult Joe what the best way is. Maybe he can spare you from filing a CSR at all. BTW, you did try out keytool after this code change and "-ext dns=1abc.com" is working now, right? Thanks Max > > Regards, > Sean. > > On 22/11/18 14:49, Weijun Wang wrote: >> * DNSName.java: >> >> 91 if ((endIndex - startIndex) < 1) >> >> No need for inner parentheses. >> >> And, is there really a need to define alphaDigitsAndHyphen? How about just (== '-' || inside alphaDigits)? >> >> * DNSNameTest.java: >> >> Space cannot appear anywhere, please add a test case like "a c.com". >> >> BTW, I assume you want to reuse this test for other sub-tasks of JDK-8054380? I see the @summary is more general. >> >> No other comments. >> >> Thanks >> Max >> >>> On Nov 22, 2018, at 12:51 AM, Se?n Coffey wrote: >>> >>> p.s I've updated the testcase to test the IOException message for presence of "DNSName". Webrev updated in place. >>> >>> Regards, >>> Sean. >>> >>> On 21/11/18 15:42, Se?n Coffey wrote: >>>> Thanks for the comments Bernd. Comments inline.. >>>> >>>> On 16/11/18 21:27, Bernd Eckenfels wrote: >>>>> Hello Sean, >>>>> >>>>> I was only looking at the inspected DNSName class, it still has some variations (but start now with DNSNames which is good already): >>>>> >>>>> 76 throw new IOException("DNSName must not be null or empty"); >>>>> 78 throw new IOException("DNSNames or NameConstraints with blank components are not permitted"); >>>>> 80 throw new IOException("DNSNames or NameConstraints may not begin or end with a ."); >>>>> 92 throw new IOException("DNSName SubjectAltNames with empty components are not permitted"); >>>>> 96 throw new IOException("DNSName components must begin with a letter or digit"); >>>>> 101 throw new IOException("DNSName components must consist of letters, digits, and hyphens"); >>>>> >>>>> I did not check if those exceptions are catched and rethrown with something like ?while validating the SubjectAltName Extension of certificate ...?, in my experience it helps if you do not have to find and review the actual certificates (in this case it might not be a problem if SAN is only in the end entity). You can probably remove ?or NameConstraints? and ?SubjectAltNames? from lines 78-92 (this is good if DNsNa >>>> Ok - I've cleaned up the exception messages on line 78, 80, 92. >>>> webrev updated in place : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >>>> >>>> >>>>> me applies to SAN or NameConstrained context and the validation logic does not know ? so it?s not only more unified but also less missleading) >>>>> >>>>> BTW: probably not inthe scope of this fix but a subtype for validation errors which have getters for context/location and maybe error code and getValue() would allow callers to print nicer validation reports without relying on the message or Stacktraces. >>>> That's a nice idea and one that should be followed up in separate enhancement. We could lean on the new `jdk.includeInExceptions` Security property which other component areas have started to use lately. >>>> >>>> e.g. https://bugs.openjdk.java.net/browse/JDK-8207768 >>>> >>>> regards, >>>> Sean. >>>>> Gruss >>>>> Bernd >>>>> -- >>>>> http://bernd.eckenfels.net >>>>> Von: Se?n Coffey >>>>> Gesendet: Freitag, November 16, 2018 5:15 PM >>>>> An: Bernd Eckenfels; security-dev at openjdk.java.net >>>>> Betreff: Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123 >>>>> Thanks for the comments Bernd. comments inline.. >>>>> >>>>> On 16/11/18 12:40, Bernd Eckenfels wrote: >>>>>> You could also add (a..b, false) and (.a, false), (a., false) to the testcases. >>>>> good point. test updated. >>>>>> I noticed that there are different types of Exception messages (DNS name, DNSName, DNS Name or name constrained, DNS name and SAN), would be good if all of them have the same keyword? >>>>> I cleaned up some other references to DNSName in the sun.security.x509 package. I'm not sure what classes you were referencing the above examples from. >>>>> >>>>> new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/ >>>>> >>>>> regards, >>>>> Sean. >>>>>> Gruss >>>>>> Bernd >>>>>> -- >>>>>> http://bernd.eckenfels.net >>>>>> Von: security-dev im Auftrag von Se?n Coffey >>>>>> Gesendet: Freitag, November 16, 2018 12:25 PM >>>>>> An: OpenJDK Dev list >>>>>> Betreff: RFR: 8213952: Relax DNSName restriction as per RFC 1123 >>>>>> Looking to make an adjustment to DNSName constructor to help comply with >>>>>> RFC 1123 >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213952 >>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/ >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>> > From matthias.baesken at sap.com Mon Nov 26 12:51:17 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 26 Nov 2018 12:51:17 +0000 Subject: jdk11u and jdk/jdk : jtreg test error in security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java Message-ID: Hello, since 18th / 19th November we notice an error in the jtreg test security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java (on all platforms, for example linux x86_64 ). Has anyone else seen the issue, or is it just us ? Thanks, Matthias Error (stderr) output is : :stdErr: Mon Nov 19 10:39:26 CET 2018 certpath: PKIXCertPathValidator.engineValidate()... certpath: X509CertSelector.match(SN: 36122296c5e338a520a1d25f4cd70954 Issuer: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA Subject: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 3c9131cb1ff6d01b0e9ab8d044bf12be Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Subject: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 570a119742c4e3cc Issuer: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT Subject: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT) certpath: X509CertSelector.match returning: true certpath: YES - try this trustedCert certpath: anchor.getTrustedCert().getSubjectX500Principal() = CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: Constraints: MD2 certpath: Constraints: MD5 certpath: Constraints: SHA1 jdkCA & usage TLSServer certpath: Constraints set to jdkCA. certpath: Constraints usage length is 1 certpath: Constraints: RSA keySize < 1024 certpath: Constraints set to keySize: keySize < 1024 certpath: Constraints: DSA keySize < 1024 certpath: Constraints set to keySize: keySize < 1024 certpath: Constraints: EC keySize < 224 certpath: Constraints set to keySize: keySize < 224 certpath: AlgorithmChecker.contains: SHA256withRSA certpath: AnchorCertificate.contains: matched CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: trustedMatch = true certpath: -------------------------------------------------------------- certpath: Executing PKIX certification path validation algorithm. certpath: Checking cert1 - Subject: CN=Actalis Extended Validation Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19} certpath: -Using checker1 ... [sun.security.provider.certpath.UntrustedChecker] certpath: -checker1 validation succeeded certpath: -Using checker2 ... [sun.security.provider.certpath.AlgorithmChecker] certpath: Constraints.permits(): SHA256withRSA Variant: generic certpath: KeySizeConstraints.permits(): RSA certpath: -checker2 validation succeeded certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker] certpath: KeyChecker.verifyCAKeyUsage() ---checking CA key usage... certpath: KeyChecker.verifyCAKeyUsage() CA key usage verified. certpath: -checker3 validation succeeded certpath: -Using checker4 ... [sun.security.provider.certpath.ConstraintsChecker] certpath: ---checking basic constraints... certpath: i = 1, maxPathLength = 2 certpath: after processing, maxPathLength = 1 certpath: basic constraints verified. certpath: ---checking name constraints... certpath: prevNC = null, newNC = null certpath: mergedNC = null certpath: name constraints verified. certpath: -checker4 validation succeeded certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker] certpath: PolicyChecker.checkPolicy() ---checking certificate policies... certpath: PolicyChecker.checkPolicy() certIndex = 1 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 3 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 3 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: inhibitAnyPolicy = 3 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = anyPolicy ROOT certpath: PolicyChecker.processPolicies() policiesCritical = false certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true certpath: PolicyChecker.processPolicies() processing policy: 2.5.29.32.0 certpath: PolicyChecker.processParents(): matchAny = true certpath: PolicyChecker.processParents() found parent: anyPolicy ROOT certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = anyPolicy ROOT anyPolicy CRIT: false EP: anyPolicy (1) certpath: PolicyChecker.checkPolicy() certificate policies verified certpath: -checker5 validation succeeded certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker] certpath: ---checking validity:Mon Nov 19 10:39:24 CET 2018... certpath: validity verified. certpath: ---checking subject/issuer name chaining... certpath: subject/issuer name chaining verified. certpath: ---checking signature... certpath: signature verified. certpath: BasicChecker.updateState issuer: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT; subject: CN=Actalis Extended Validation Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT; serial#: 3663163709977533131 certpath: -checker6 validation succeeded certpath: -Using checker7 ... [sun.security.provider.certpath.RevocationChecker] certpath: RevocationChecker.check: checking cert SN: 32d62bfc 67501acb Subject: CN=Actalis Extended Validation Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT Issuer: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: connecting to OCSP service at: http://ocsp05.actalis.it/VA/AUTH-ROOT certpath: OCSP response status: SUCCESSFUL certpath: OCSP response type: basic certpath: Responder ID: byName: CN=Actalis Authentication Root CA - OCSP Responder, O=Actalis S.p.A./03358520967, C=IT certpath: OCSP response produced at: Mon Nov 19 10:39:24 CET 2018 certpath: OCSP number of SingleResponses: 1 certpath: thisUpdate: Fri Oct 19 14:29:36 CEST 2018 certpath: nextUpdate: Thu Jan 17 13:29:36 CET 2019 certpath: OCSP response cert #1: CN=Actalis Authentication Root CA - OCSP Responder, O=Actalis S.p.A./03358520967, C=IT certpath: Status of certificate (with serial number 3663163709977533131) is: GOOD certpath: AlgorithmChecker.contains: SHA256withRSA certpath: AnchorCertificate.contains: matched CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: trustedMatch = true certpath: Constraints.permits(): SHA256withRSA Variant: generic certpath: KeySizeConstraints.permits(): RSA certpath: Responder's certificate includes the extension id-pkix-ocsp-nocheck. certpath: OCSP response is signed by an Authorized Responder certpath: Constraints.permits(): SHA1withRSA Variant: generic certpath: jdkCAConstraints.permits(): SHA1 certpath: Verified signature of OCSP Response certpath: OCSP response validity interval is from Fri Oct 19 14:29:36 CEST 2018 until Thu Jan 17 13:29:36 CET 2019 certpath: Checking validity of OCSP response on: Mon Nov 19 10:39:24 CET 2018 certpath: -checker7 validation succeeded certpath: cert1 validation succeeded. certpath: Checking cert2 - Subject: OID.1.3.6.1.4.1.311.60.2.1.3=IT, STREET=Via S. Clemente 53, OID.2.5.4.15=Private Organization, CN=www.actalis.it, SERIALNUMBER=03358520967, O=Actalis S.p.A., L=Ponte San Pietro, ST=Bergamo, C=IT certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19} certpath: -Using checker1 ... [sun.security.provider.certpath.UntrustedChecker] certpath: -checker1 validation succeeded certpath: -Using checker2 ... [sun.security.provider.certpath.AlgorithmChecker] certpath: Constraints.permits(): SHA256withRSA Variant: generic certpath: KeySizeConstraints.permits(): RSA certpath: -checker2 validation succeeded certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker] certpath: -checker3 validation succeeded certpath: -Using checker4 ... [sun.security.provider.certpath.ConstraintsChecker] certpath: ---checking basic constraints... certpath: i = 2, maxPathLength = 1 certpath: after processing, maxPathLength = 1 certpath: basic constraints verified. certpath: ---checking name constraints... certpath: prevNC = null, newNC = null certpath: mergedNC = null certpath: name constraints verified. certpath: -checker4 validation succeeded certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker] certpath: PolicyChecker.checkPolicy() ---checking certificate policies... certpath: PolicyChecker.checkPolicy() certIndex = 2 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 2 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 2 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: inhibitAnyPolicy = 2 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = anyPolicy ROOT anyPolicy CRIT: false EP: anyPolicy (1) certpath: PolicyChecker.processPolicies() policiesCritical = false certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true certpath: PolicyChecker.processPolicies() processing policy: 1.3.159.1.17.1 certpath: PolicyChecker.processParents(): matchAny = false certpath: PolicyChecker.processParents(): matchAny = true certpath: PolicyChecker.processParents() found parent: anyPolicy CRIT: false EP: anyPolicy (1) certpath: PolicyChecker.processPolicies() processing policy: 2.23.140.1.1 certpath: PolicyChecker.processParents(): matchAny = false certpath: PolicyChecker.processParents(): matchAny = true certpath: PolicyChecker.processParents() found parent: anyPolicy CRIT: false EP: anyPolicy (1) certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = anyPolicy ROOT anyPolicy CRIT: false EP: anyPolicy (1) 1.3.159.1.17.1 CRIT: false EP: 1.3.159.1.17.1 (2) 2.23.140.1.1 CRIT: false EP: 2.23.140.1.1 (2) certpath: PolicyChecker.checkPolicy() certificate policies verified certpath: -checker5 validation succeeded certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker] certpath: ---checking validity:Mon Nov 19 10:39:24 CET 2018... certpath: validity verified. certpath: ---checking subject/issuer name chaining... certpath: subject/issuer name chaining verified. certpath: ---checking signature... certpath: signature verified. certpath: BasicChecker.updateState issuer: CN=Actalis Extended Validation Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT; subject: OID.1.3.6.1.4.1.311.60.2.1.3=IT, STREET=Via S. Clemente 53, OID.2.5.4.15=Private Organization, CN=www.actalis.it, SERIALNUMBER=03358520967, O=Actalis S.p.A., L=Ponte San Pietro, ST=Bergamo, C=IT; serial#: 1076059514591231458 certpath: -checker6 validation succeeded certpath: -Using checker7 ... [sun.security.provider.certpath.RevocationChecker] certpath: RevocationChecker.check: checking cert SN: 0eeeee6d 6463bde2 Subject: OID.1.3.6.1.4.1.311.60.2.1.3=IT, STREET=Via S. Clemente 53, OID.2.5.4.15=Private Organization, CN=www.actalis.it, SERIALNUMBER=03358520967, O=Actalis S.p.A., L=Ponte San Pietro, ST=Bergamo, C=IT Issuer: CN=Actalis Extended Validation Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT certpath: connecting to OCSP service at: http://ocsp05.actalis.it/VA/AUTHEV-G1 certpath: OCSP response status: SUCCESSFUL certpath: OCSP response type: basic certpath: Responder ID: byName: CN=Actalis Extended Validation Server CA G1 - OCSP Responder, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT certpath: OCSP response produced at: Mon Nov 19 10:39:24 CET 2018 certpath: OCSP number of SingleResponses: 1 certpath: thisUpdate: Mon Nov 19 07:19:26 CET 2018 certpath: nextUpdate: Tue Nov 20 07:19:26 CET 2018 certpath: OCSP response cert #1: CN=Actalis Extended Validation Server CA G1 - OCSP Responder, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT certpath: Status of certificate (with serial number 1076059514591231458) is: GOOD certpath: AlgorithmChecker.contains: SHA256withRSA certpath: AnchorCertificate.contains: matched CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: trustedMatch = true certpath: Constraints.permits(): SHA256withRSA Variant: generic certpath: KeySizeConstraints.permits(): RSA certpath: Responder's certificate includes the extension id-pkix-ocsp-nocheck. certpath: OCSP response is signed by an Authorized Responder certpath: Constraints.permits(): SHA1withRSA Variant: generic certpath: jdkCAConstraints.permits(): SHA1 certpath: Verified signature of OCSP Response certpath: OCSP response validity interval is from Mon Nov 19 07:19:26 CET 2018 until Tue Nov 20 07:19:26 CET 2018 certpath: Checking validity of OCSP response on: Mon Nov 19 10:39:25 CET 2018 certpath: -checker7 validation succeeded certpath: cert2 validation succeeded. certpath: Cert path validation succeeded. (PKIX validation algorithm) certpath: -------------------------------------------------------------- certpath: PKIXCertPathValidator.engineValidate()... certpath: X509CertSelector.match(SN: 3c9131cb1ff6d01b0e9ab8d044bf12be Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Subject: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 7dd9fe07cfa81eb7107967fba78934c6 Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 570a119742c4e3cc Issuer: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT Subject: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT) certpath: X509CertSelector.match returning: true certpath: YES - try this trustedCert certpath: anchor.getTrustedCert().getSubjectX500Principal() = CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: AlgorithmChecker.contains: SHA256withRSA certpath: AnchorCertificate.contains: matched CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: trustedMatch = true certpath: -------------------------------------------------------------- certpath: Executing PKIX certification path validation algorithm. certpath: Checking cert1 - Subject: CN=Actalis Authentication CA G3, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19} certpath: -Using checker1 ... [sun.security.provider.certpath.UntrustedChecker] certpath: -checker1 validation succeeded certpath: -Using checker2 ... [sun.security.provider.certpath.AlgorithmChecker] certpath: Constraints.permits(): SHA256withRSA Variant: generic certpath: KeySizeConstraints.permits(): RSA certpath: -checker2 validation succeeded certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker] certpath: KeyChecker.verifyCAKeyUsage() ---checking CA key usage... certpath: KeyChecker.verifyCAKeyUsage() CA key usage verified. certpath: -checker3 validation succeeded certpath: -Using checker4 ... [sun.security.provider.certpath.ConstraintsChecker] certpath: ---checking basic constraints... certpath: i = 1, maxPathLength = 2 certpath: after processing, maxPathLength = 1 certpath: basic constraints verified. certpath: ---checking name constraints... certpath: prevNC = null, newNC = null certpath: mergedNC = null certpath: name constraints verified. certpath: -checker4 validation succeeded certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker] certpath: PolicyChecker.checkPolicy() ---checking certificate policies... certpath: PolicyChecker.checkPolicy() certIndex = 1 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 3 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 3 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: inhibitAnyPolicy = 3 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = anyPolicy ROOT certpath: PolicyChecker.processPolicies() policiesCritical = false certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true certpath: PolicyChecker.processPolicies() processing policy: 2.5.29.32.0 certpath: PolicyChecker.processParents(): matchAny = true certpath: PolicyChecker.processParents() found parent: anyPolicy ROOT certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = anyPolicy ROOT anyPolicy CRIT: false EP: anyPolicy (1) certpath: PolicyChecker.checkPolicy() certificate policies verified certpath: -checker5 validation succeeded certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker] certpath: ---checking validity:Fri Jul 01 00:00:00 CEST 2016... certpath: validity verified. certpath: ---checking subject/issuer name chaining... certpath: subject/issuer name chaining verified. certpath: ---checking signature... certpath: signature verified. certpath: BasicChecker.updateState issuer: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT; subject: CN=Actalis Authentication CA G3, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT; serial#: 8366940759504193212 certpath: -checker6 validation succeeded certpath: -Using checker7 ... [sun.security.provider.certpath.RevocationChecker] certpath: RevocationChecker.check: checking cert SN: 741d584a 72fc06bc Subject: CN=Actalis Authentication CA G3, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT Issuer: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: connecting to OCSP service at: http://portal.actalis.it/VA/AUTH-ROOT certpath: OCSP response status: SUCCESSFUL certpath: OCSP response type: basic certpath: Responder ID: byName: CN=Actalis Authentication Root CA - OCSP Responder, O=Actalis S.p.A./03358520967, C=IT certpath: OCSP response produced at: Mon Nov 19 10:39:25 CET 2018 certpath: OCSP number of SingleResponses: 1 certpath: thisUpdate: Fri Oct 19 14:29:36 CEST 2018 certpath: nextUpdate: Thu Jan 17 13:29:36 CET 2019 certpath: OCSP response cert #1: CN=Actalis Authentication Root CA - OCSP Responder, O=Actalis S.p.A./03358520967, C=IT certpath: Status of certificate (with serial number 8366940759504193212) is: GOOD certpath: AlgorithmChecker.contains: SHA256withRSA certpath: AnchorCertificate.contains: matched CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: trustedMatch = true certpath: Constraints.permits(): SHA256withRSA Variant: generic certpath: KeySizeConstraints.permits(): RSA certpath: Responder's certificate includes the extension id-pkix-ocsp-nocheck. certpath: OCSP response is signed by an Authorized Responder certpath: Constraints.permits(): SHA1withRSA Variant: generic certpath: jdkCAConstraints.permits(): SHA1 certpath: Verified signature of OCSP Response certpath: OCSP response validity interval is from Fri Oct 19 14:29:36 CEST 2018 until Thu Jan 17 13:29:36 CET 2019 certpath: Checking validity of OCSP response on: Mon Nov 19 10:39:25 CET 2018 certpath: -checker7 validation succeeded certpath: cert1 validation succeeded. certpath: Checking cert2 - Subject: CN=ssltest-r.actalis.it, O=Actalis S.p.A., L=Ponte San Pietro, ST=Bergamo, C=IT certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19} certpath: -Using checker1 ... [sun.security.provider.certpath.UntrustedChecker] certpath: -checker1 validation succeeded certpath: -Using checker2 ... [sun.security.provider.certpath.AlgorithmChecker] certpath: Constraints.permits(): SHA256withRSA Variant: generic certpath: KeySizeConstraints.permits(): RSA certpath: -checker2 validation succeeded certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker] certpath: -checker3 validation succeeded certpath: -Using checker4 ... [sun.security.provider.certpath.ConstraintsChecker] certpath: ---checking basic constraints... certpath: i = 2, maxPathLength = 1 certpath: after processing, maxPathLength = 1 certpath: basic constraints verified. certpath: ---checking name constraints... certpath: prevNC = null, newNC = null certpath: mergedNC = null certpath: name constraints verified. certpath: -checker4 validation succeeded certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker] certpath: PolicyChecker.checkPolicy() ---checking certificate policies... certpath: PolicyChecker.checkPolicy() certIndex = 2 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 2 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 2 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: inhibitAnyPolicy = 2 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = anyPolicy ROOT anyPolicy CRIT: false EP: anyPolicy (1) certpath: PolicyChecker.processPolicies() policiesCritical = false certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true certpath: PolicyChecker.processPolicies() processing policy: 1.3.159.1.20.1 certpath: PolicyChecker.processParents(): matchAny = false certpath: PolicyChecker.processParents(): matchAny = true certpath: PolicyChecker.processParents() found parent: anyPolicy CRIT: false EP: anyPolicy (1) certpath: PolicyChecker.processPolicies() processing policy: 2.23.140.1.2.2 certpath: PolicyChecker.processParents(): matchAny = false certpath: PolicyChecker.processParents(): matchAny = true certpath: PolicyChecker.processParents() found parent: anyPolicy CRIT: false EP: anyPolicy (1) certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = anyPolicy ROOT anyPolicy CRIT: false EP: anyPolicy (1) 2.23.140.1.2.2 CRIT: false EP: 2.23.140.1.2.2 (2) 1.3.159.1.20.1 CRIT: false EP: 1.3.159.1.20.1 (2) certpath: PolicyChecker.checkPolicy() certificate policies verified certpath: -checker5 validation succeeded certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker] certpath: ---checking validity:Fri Jul 01 00:00:00 CEST 2016... certpath: validity verified. certpath: ---checking subject/issuer name chaining... certpath: subject/issuer name chaining verified. certpath: ---checking signature... certpath: signature verified. certpath: BasicChecker.updateState issuer: CN=Actalis Authentication CA G3, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT; subject: CN=ssltest-r.actalis.it, O=Actalis S.p.A., L=Ponte San Pietro, ST=Bergamo, C=IT; serial#: 312400490844506479 certpath: -checker6 validation succeeded certpath: -Using checker7 ... [sun.security.provider.certpath.RevocationChecker] certpath: RevocationChecker.check: checking cert SN: 0455de97 5c71c96f Subject: CN=ssltest-r.actalis.it, O=Actalis S.p.A., L=Ponte San Pietro, ST=Bergamo, C=IT Issuer: CN=Actalis Authentication CA G3, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT certpath: connecting to OCSP service at: http://ocsp03.actalis.it/VA/AUTH-G3 certpath: OCSP response status: SUCCESSFUL certpath: OCSP response type: basic certpath: Responder ID: byName: CN=Actalis Authentication CA G3 - OCSP Responder, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT certpath: OCSP response produced at: Mon Nov 19 10:39:25 CET 2018 certpath: OCSP number of SingleResponses: 1 certpath: Revocation time: Fri Jan 29 10:06:42 CET 2016 certpath: Revocation reason: CESSATION_OF_OPERATION certpath: thisUpdate: Mon Nov 19 06:46:50 CET 2018 certpath: nextUpdate: Tue Nov 20 06:46:50 CET 2018 certpath: OCSP response cert #1: CN=Actalis Authentication CA G3 - OCSP Responder, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT certpath: Status of certificate (with serial number 312400490844506479) is: REVOKED certpath: AlgorithmChecker.contains: SHA256withRSA certpath: AnchorCertificate.contains: matched CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: trustedMatch = true certpath: Constraints.permits(): SHA256withRSA Variant: generic certpath: KeySizeConstraints.permits(): RSA certpath: Responder's certificate includes the extension id-pkix-ocsp-nocheck. certpath: OCSP response is signed by an Authorized Responder certpath: Constraints.permits(): SHA1withRSA Variant: generic certpath: jdkCAConstraints.permits(): SHA1 certpath: Verified signature of OCSP Response certpath: OCSP response validity interval is from Mon Nov 19 06:46:50 CET 2018 until Tue Nov 20 06:46:50 CET 2018 certpath: Checking validity of OCSP response on: Mon Nov 19 10:39:25 CET 2018 certpath: X509CertSelector.match(SN: 1a5 Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US Subject: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 9b7e0649a33e62b9d5ee90487129ef57 Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Subject: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: b92f60cc889fa17a4609b85b706c8aaf Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 67c8e1e8e3be1cbdfc913b8ea6238749 Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA Subject: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 10020 Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL Subject: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 36122296c5e338a520a1d25f4cd70954 Issuer: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA Subject: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA) certpath: X509CertSelector.match: subject DNs don't match STATUS:Passed. -------------------------------- certpath: PKIXCertPathValidator.engineValidate()... certpath: X509CertSelector.match(SN: 9b7e0649a33e62b9d5ee90487129ef57 Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US Subject: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 1a5 Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US Subject: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 10020 Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL Subject: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 7dd9fe07cfa81eb7107967fba78934c6 Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 36122296c5e338a520a1d25f4cd70954 Issuer: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA Subject: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: b92f60cc889fa17a4609b85b706c8aaf Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 570a119742c4e3cc Issuer: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT Subject: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT) certpath: X509CertSelector.match returning: true certpath: YES - try this trustedCert certpath: anchor.getTrustedCert().getSubjectX500Principal() = CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: Constraints: MD2 certpath: Constraints: MD5 certpath: Constraints: SHA1 jdkCA & usage TLSServer certpath: Constraints set to jdkCA. certpath: Constraints usage length is 1 certpath: Constraints: RSA keySize < 1024 certpath: Constraints set to keySize: keySize < 1024 certpath: Constraints: DSA keySize < 1024 certpath: Constraints set to keySize: keySize < 1024 certpath: Constraints: EC keySize < 224 certpath: Constraints set to keySize: keySize < 224 certpath: AlgorithmChecker.contains: SHA256withRSA certpath: AnchorCertificate.contains: matched CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: trustedMatch = true certpath: -------------------------------------------------------------- certpath: Executing PKIX certification path validation algorithm. certpath: Checking cert1 - Subject: CN=Actalis Extended Validation Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19} certpath: -Using checker1 ... [sun.security.provider.certpath.UntrustedChecker] certpath: -checker1 validation succeeded certpath: -Using checker2 ... [sun.security.provider.certpath.AlgorithmChecker] certpath: Constraints.permits(): SHA256withRSA Variant: generic certpath: KeySizeConstraints.permits(): RSA certpath: -checker2 validation succeeded certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker] certpath: KeyChecker.verifyCAKeyUsage() ---checking CA key usage... certpath: KeyChecker.verifyCAKeyUsage() CA key usage verified. certpath: -checker3 validation succeeded certpath: -Using checker4 ... [sun.security.provider.certpath.ConstraintsChecker] certpath: ---checking basic constraints... certpath: i = 1, maxPathLength = 2 certpath: after processing, maxPathLength = 1 certpath: basic constraints verified. certpath: ---checking name constraints... certpath: prevNC = null, newNC = null certpath: mergedNC = null certpath: name constraints verified. certpath: -checker4 validation succeeded certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker] certpath: PolicyChecker.checkPolicy() ---checking certificate policies... certpath: PolicyChecker.checkPolicy() certIndex = 1 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 3 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 3 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: inhibitAnyPolicy = 3 certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = anyPolicy ROOT certpath: PolicyChecker.processPolicies() policiesCritical = false certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true certpath: PolicyChecker.processPolicies() processing policy: 2.5.29.32.0 certpath: PolicyChecker.processParents(): matchAny = true certpath: PolicyChecker.processParents() found parent: anyPolicy ROOT certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2 certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = anyPolicy ROOT anyPolicy CRIT: false EP: anyPolicy (1) certpath: PolicyChecker.checkPolicy() certificate policies verified certpath: -checker5 validation succeeded certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker] certpath: ---checking validity:Mon Nov 19 10:39:25 CET 2018... certpath: validity verified. certpath: ---checking subject/issuer name chaining... certpath: subject/issuer name chaining verified. certpath: ---checking signature... certpath: signature verified. certpath: BasicChecker.updateState issuer: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT; subject: CN=Actalis Extended Validation Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT; serial#: 3663163709977533131 certpath: -checker6 validation succeeded certpath: -Using checker7 ... [sun.security.provider.certpath.RevocationChecker] certpath: RevocationChecker.check: checking cert SN: 32d62bfc 67501acb Subject: CN=Actalis Extended Validation Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT Issuer: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT certpath: RevocationChecker.checkCRLs() ---checking revocation status ... certpath: RevocationChecker.checkCRLs() possible crls.size() = 0 certpath: RevocationChecker.checkCRLs() approved crls.size() = 0 certpath: DistributionPointFetcher.getCRLs: Checking CRLDPs for CN=Actalis Extended Validation Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT certpath: Trying to fetch CRL from DP ldap://ldap05.actalis.it/cn%3dActalis%20Authentication%20Root%20CA,o%3dActalis%20S.p.A.%2f03358520967,c%3dIT?certificateRevocationList;binary certpath: CertStore URI:ldap://ldap05.actalis.it/cn%3dActalis%20Authentication%20Root%20CA,o%3dActalis%20S.p.A.%2f03358520967,c%3dIT?certificateRevocationList;binary certpath: LDAPCertStore.engineGetCRLs() selector: null certpath: X509CertSelector.match(SN: 3c9131cb1ff6d01b0e9ab8d044bf12be Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US Subject: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US) certpath: X509CertSelector.match: subject DNs don't match certpath: X509CertSelector.match(SN: 67c8e1e8e3be1cbdfc913b8ea6238749 Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA Subject: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA) certpath: X509CertSelector.match: subject DNs don't match java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status at ValidatePathWithParams.validate(ValidatePathWithParams.java:177) at ActalisCA.main(ActalisCA.java:235) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:834) JavaTest Message: Test threw exception: java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.RuntimeException: TEST FAILED: couldn't determine EE certificate status -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Nov 26 13:24:13 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 26 Nov 2018 08:24:13 -0500 Subject: jdk11u and jdk/jdk : jtreg test error in security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java In-Reply-To: References: Message-ID: <29e2f8e4-ce23-d5a1-211b-ef578bc05188@oracle.com> On 11/26/18 7:51 AM, Baesken, Matthias wrote: > Hello, since 18th / 19th? November we notice an error in the jtreg test > > > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java > > (on all platforms, for example linux x86_64 ). > > Has anyone else seen the issue, or is it just us ? Yes, this is a known issue, see https://bugs.openjdk.java.net/browse/JDK-8202651 --Sean > > Thanks, Matthias > > Error? (stderr)? output is : > > :stdErr: > > Mon Nov 19 10:39:26 CET 2018 > > certpath: PKIXCertPathValidator.engineValidate()... > > certpath: X509CertSelector.match(SN: 36122296c5e338a520a1d25f4cd70954 > > ? Issuer: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium > Server CA, OU=Certification Services Division, O=Thawte Consulting cc, > L=Cape Town, ST=Western Cape, C=ZA > > ? Subject: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium > Server CA, OU=Certification Services Division, O=Thawte Consulting cc, > L=Cape Town, ST=Western Cape, C=ZA) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 3c9131cb1ff6d01b0e9ab8d044bf12be > > ? Issuer: OU=Class 3 Public Primary Certification Authority, > O="VeriSign, Inc.", C=US > > ? Subject: OU=Class 3 Public Primary Certification Authority, > O="VeriSign, Inc.", C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 570a119742c4e3cc > > ? Issuer: CN=Actalis Authentication Root CA, O=Actalis > S.p.A./03358520967, L=Milan, C=IT > > ? Subject: CN=Actalis Authentication Root CA, O=Actalis > S.p.A./03358520967, L=Milan, C=IT) > > certpath: X509CertSelector.match returning: true > > certpath: YES - try this trustedCert > > certpath: anchor.getTrustedCert().getSubjectX500Principal() = CN=Actalis > Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT > > certpath: Constraints: MD2 > > certpath: Constraints: MD5 > > certpath: Constraints: SHA1 jdkCA & usage TLSServer > > certpath: Constraints set to jdkCA. > > certpath: Constraints usage length is 1 > > certpath: Constraints: RSA keySize < 1024 > > certpath: Constraints set to keySize: keySize < 1024 > > certpath: Constraints: DSA keySize < 1024 > > certpath: Constraints set to keySize: keySize < 1024 > > certpath: Constraints: EC keySize < 224 > > certpath: Constraints set to keySize: keySize < 224 > > certpath: AlgorithmChecker.contains: SHA256withRSA > > certpath: AnchorCertificate.contains: matched CN=Actalis Authentication > Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT > > certpath: trustedMatch = true > > certpath: -------------------------------------------------------------- > > certpath: Executing PKIX certification path validation algorithm. > > certpath: Checking cert1 - Subject: CN=Actalis Extended Validation > Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19} > > certpath: -Using checker1 ... > [sun.security.provider.certpath.UntrustedChecker] > > certpath: -checker1 validation succeeded > > certpath: -Using checker2 ... > [sun.security.provider.certpath.AlgorithmChecker] > > certpath: Constraints.permits(): SHA256withRSA Variant: generic > > certpath: KeySizeConstraints.permits(): RSA > > certpath: -checker2 validation succeeded > > certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker] > > certpath: KeyChecker.verifyCAKeyUsage() ---checking CA key usage... > > certpath: KeyChecker.verifyCAKeyUsage() CA key usage verified. > > certpath: -checker3 validation succeeded > > certpath: -Using checker4 ... > [sun.security.provider.certpath.ConstraintsChecker] > > certpath: ---checking basic constraints... > > certpath: i = 1, maxPathLength = 2 > > certpath: after processing, maxPathLength = 1 > > certpath: basic constraints verified. > > certpath: ---checking name constraints... > > certpath: prevNC = null, newNC = null > > certpath: mergedNC = null > > certpath: name constraints verified. > > certpath: -checker4 validation succeeded > > certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker] > > certpath: PolicyChecker.checkPolicy() ---checking certificate policies... > > certpath: PolicyChecker.checkPolicy() certIndex = 1 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 3 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 3 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: > inhibitAnyPolicy = 3 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = > anyPolicy? ROOT > > certpath: PolicyChecker.processPolicies() policiesCritical = false > > certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true > > certpath: PolicyChecker.processPolicies() processing policy: 2.5.29.32.0 > > certpath: PolicyChecker.processParents(): matchAny = true > > certpath: PolicyChecker.processParents() found parent: > > anyPolicy? ROOT > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = > anyPolicy? ROOT > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > certpath: PolicyChecker.checkPolicy() certificate policies verified > > certpath: -checker5 validation succeeded > > certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker] > > certpath: ---checking validity:Mon Nov 19 10:39:24 CET 2018... > > certpath: validity verified. > > certpath: ---checking subject/issuer name chaining... > > certpath: subject/issuer name chaining verified. > > certpath: ---checking signature... > > certpath: signature verified. > > certpath: BasicChecker.updateState issuer: CN=Actalis Authentication > Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT; subject: > CN=Actalis Extended Validation Server CA G1, O=Actalis > S.p.A./03358520967, L=Milano, ST=Milano, C=IT; serial#: 3663163709977533131 > > certpath: -checker6 validation succeeded > > certpath: -Using checker7 ... > [sun.security.provider.certpath.RevocationChecker] > > certpath: RevocationChecker.check: checking cert > > ? SN:???? 32d62bfc 67501acb > > ? Subject: CN=Actalis Extended Validation Server CA G1, O=Actalis > S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > ? Issuer: CN=Actalis Authentication Root CA, O=Actalis > S.p.A./03358520967, L=Milan, C=IT > > certpath: connecting to OCSP service at: > http://ocsp05.actalis.it/VA/AUTH-ROOT > > certpath: OCSP response status: SUCCESSFUL > > certpath: OCSP response type: basic > > certpath: Responder ID: byName: CN=Actalis Authentication Root CA - OCSP > Responder, O=Actalis S.p.A./03358520967, C=IT > > certpath: OCSP response produced at: Mon Nov 19 10:39:24 CET 2018 > > certpath: OCSP number of SingleResponses: 1 > > certpath: thisUpdate: Fri Oct 19 14:29:36 CEST 2018 > > certpath: nextUpdate: Thu Jan 17 13:29:36 CET 2019 > > certpath: OCSP response cert #1: CN=Actalis Authentication Root CA - > OCSP Responder, O=Actalis S.p.A./03358520967, C=IT > > certpath: Status of certificate (with serial number 3663163709977533131) > is: GOOD > > certpath: AlgorithmChecker.contains: SHA256withRSA > > certpath: AnchorCertificate.contains: matched CN=Actalis Authentication > Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT > > certpath: trustedMatch = true > > certpath: Constraints.permits(): SHA256withRSA Variant: generic > > certpath: KeySizeConstraints.permits(): RSA > > certpath: Responder's certificate includes the extension > id-pkix-ocsp-nocheck. > > certpath: OCSP response is signed by an Authorized Responder > > certpath: Constraints.permits(): SHA1withRSA Variant: generic > > certpath: jdkCAConstraints.permits(): SHA1 > > certpath: Verified signature of OCSP Response > > certpath: OCSP response validity interval is from Fri Oct 19 14:29:36 > CEST 2018 until Thu Jan 17 13:29:36 CET 2019 > > certpath: Checking validity of OCSP response on: Mon Nov 19 10:39:24 CET > 2018 > > certpath: -checker7 validation succeeded > > certpath: > > cert1 validation succeeded. > > certpath: Checking cert2 - Subject: OID.1.3.6.1.4.1.311.60.2.1.3=IT, > STREET=Via S. Clemente 53, OID.2.5.4.15=Private Organization, > CN=www.actalis.it, SERIALNUMBER=03358520967, O=Actalis S.p.A., L=Ponte > San Pietro, ST=Bergamo, C=IT > > certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19} > > certpath: -Using checker1 ... > [sun.security.provider.certpath.UntrustedChecker] > > certpath: -checker1 validation succeeded > > certpath: -Using checker2 ... > [sun.security.provider.certpath.AlgorithmChecker] > > certpath: Constraints.permits(): SHA256withRSA Variant: generic > > certpath: KeySizeConstraints.permits(): RSA > > certpath: -checker2 validation succeeded > > certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker] > > certpath: -checker3 validation succeeded > > certpath: -Using checker4 ... > [sun.security.provider.certpath.ConstraintsChecker] > > certpath: ---checking basic constraints... > > certpath: i = 2, maxPathLength = 1 > > certpath: after processing, maxPathLength = 1 > > certpath: basic constraints verified. > > certpath: ---checking name constraints... > > certpath: prevNC = null, newNC = null > > certpath: mergedNC = null > > certpath: name constraints verified. > > certpath: -checker4 validation succeeded > > certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker] > > certpath: PolicyChecker.checkPolicy() ---checking certificate policies... > > certpath: PolicyChecker.checkPolicy() certIndex = 2 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 2 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 2 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: > inhibitAnyPolicy = 2 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = > anyPolicy? ROOT > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > certpath: PolicyChecker.processPolicies() policiesCritical = false > > certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true > > certpath: PolicyChecker.processPolicies() processing policy: 1.3.159.1.17.1 > > certpath: PolicyChecker.processParents(): matchAny = false > > certpath: PolicyChecker.processParents(): matchAny = true > > certpath: PolicyChecker.processParents() found parent: > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > certpath: PolicyChecker.processPolicies() processing policy: 2.23.140.1.1 > > certpath: PolicyChecker.processParents(): matchAny = false > > certpath: PolicyChecker.processParents(): matchAny = true > > certpath: PolicyChecker.processParents() found parent: > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = > anyPolicy? ROOT > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > ??? 1.3.159.1.17.1? CRIT: false? EP: 1.3.159.1.17.1? (2) > > ??? 2.23.140.1.1? CRIT: false? EP: 2.23.140.1.1? (2) > > certpath: PolicyChecker.checkPolicy() certificate policies verified > > certpath: -checker5 validation succeeded > > certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker] > > certpath: ---checking validity:Mon Nov 19 10:39:24 CET 2018... > > certpath: validity verified. > > certpath: ---checking subject/issuer name chaining... > > certpath: subject/issuer name chaining verified. > > certpath: ---checking signature... > > certpath: signature verified. > > certpath: BasicChecker.updateState issuer: CN=Actalis Extended > Validation Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, > ST=Milano, C=IT; subject: OID.1.3.6.1.4.1.311.60.2.1.3=IT, STREET=Via S. > Clemente 53, OID.2.5.4.15=Private Organization, CN=www.actalis.it, > SERIALNUMBER=03358520967, O=Actalis S.p.A., L=Ponte San Pietro, > ST=Bergamo, C=IT; serial#: 1076059514591231458 > > certpath: -checker6 validation succeeded > > certpath: -Using checker7 ... > [sun.security.provider.certpath.RevocationChecker] > > certpath: RevocationChecker.check: checking cert > > ? SN:???? 0eeeee6d 6463bde2 > > ? Subject: OID.1.3.6.1.4.1.311.60.2.1.3=IT, STREET=Via S. Clemente 53, > OID.2.5.4.15=Private Organization, CN=www.actalis.it, > SERIALNUMBER=03358520967, O=Actalis S.p.A., L=Ponte San Pietro, > ST=Bergamo, C=IT > > ? Issuer: CN=Actalis Extended Validation Server CA G1, O=Actalis > S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > certpath: connecting to OCSP service at: > http://ocsp05.actalis.it/VA/AUTHEV-G1 > > certpath: OCSP response status: SUCCESSFUL > > certpath: OCSP response type: basic > > certpath: Responder ID: byName: CN=Actalis Extended Validation Server CA > G1 - OCSP Responder, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > certpath: OCSP response produced at: Mon Nov 19 10:39:24 CET 2018 > > certpath: OCSP number of SingleResponses: 1 > > certpath: thisUpdate: Mon Nov 19 07:19:26 CET 2018 > > certpath: nextUpdate: Tue Nov 20 07:19:26 CET 2018 > > certpath: OCSP response cert #1: CN=Actalis Extended Validation Server > CA G1 - OCSP Responder, O=Actalis S.p.A./03358520967, L=Milano, > ST=Milano, C=IT > > certpath: Status of certificate (with serial number 1076059514591231458) > is: GOOD > > certpath: AlgorithmChecker.contains: SHA256withRSA > > certpath: AnchorCertificate.contains: matched CN=Actalis Authentication > Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT > > certpath: trustedMatch = true > > certpath: Constraints.permits(): SHA256withRSA Variant: generic > > certpath: KeySizeConstraints.permits(): RSA > > certpath: Responder's certificate includes the extension > id-pkix-ocsp-nocheck. > > certpath: OCSP response is signed by an Authorized Responder > > certpath: Constraints.permits(): SHA1withRSA Variant: generic > > certpath: jdkCAConstraints.permits(): SHA1 > > certpath: Verified signature of OCSP Response > > certpath: OCSP response validity interval is from Mon Nov 19 07:19:26 > CET 2018 until Tue Nov 20 07:19:26 CET 2018 > > certpath: Checking validity of OCSP response on: Mon Nov 19 10:39:25 CET > 2018 > > certpath: -checker7 validation succeeded > > certpath: > > cert2 validation succeeded. > > certpath: Cert path validation succeeded. (PKIX validation algorithm) > > certpath: -------------------------------------------------------------- > > certpath: PKIXCertPathValidator.engineValidate()... > > certpath: X509CertSelector.match(SN: 3c9131cb1ff6d01b0e9ab8d044bf12be > > ? Issuer: OU=Class 3 Public Primary Certification Authority, > O="VeriSign, Inc.", C=US > > ? Subject: OU=Class 3 Public Primary Certification Authority, > O="VeriSign, Inc.", C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 7dd9fe07cfa81eb7107967fba78934c6 > > ? Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For > authorized use only", OU=Class 3 Public Primary Certification Authority > - G2, O="VeriSign, Inc.", C=US > > ? Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For > authorized use only", OU=Class 3 Public Primary Certification Authority > - G2, O="VeriSign, Inc.", C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 570a119742c4e3cc > > ? Issuer: CN=Actalis Authentication Root CA, O=Actalis > S.p.A./03358520967, L=Milan, C=IT > > ? Subject: CN=Actalis Authentication Root CA, O=Actalis > S.p.A./03358520967, L=Milan, C=IT) > > certpath: X509CertSelector.match returning: true > > certpath: YES - try this trustedCert > > certpath: anchor.getTrustedCert().getSubjectX500Principal() = CN=Actalis > Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT > > certpath: AlgorithmChecker.contains: SHA256withRSA > > certpath: AnchorCertificate.contains: matched CN=Actalis Authentication > Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT > > certpath: trustedMatch = true > > certpath: -------------------------------------------------------------- > > certpath: Executing PKIX certification path validation algorithm. > > certpath: Checking cert1 - Subject: CN=Actalis Authentication CA G3, > O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19} > > certpath: -Using checker1 ... > [sun.security.provider.certpath.UntrustedChecker] > > certpath: -checker1 validation succeeded > > certpath: -Using checker2 ... > [sun.security.provider.certpath.AlgorithmChecker] > > certpath: Constraints.permits(): SHA256withRSA Variant: generic > > certpath: KeySizeConstraints.permits(): RSA > > certpath: -checker2 validation succeeded > > certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker] > > certpath: KeyChecker.verifyCAKeyUsage() ---checking CA key usage... > > certpath: KeyChecker.verifyCAKeyUsage() CA key usage verified. > > certpath: -checker3 validation succeeded > > certpath: -Using checker4 ... > [sun.security.provider.certpath.ConstraintsChecker] > > certpath: ---checking basic constraints... > > certpath: i = 1, maxPathLength = 2 > > certpath: after processing, maxPathLength = 1 > > certpath: basic constraints verified. > > certpath: ---checking name constraints... > > certpath: prevNC = null, newNC = null > > certpath: mergedNC = null > > certpath: name constraints verified. > > certpath: -checker4 validation succeeded > > certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker] > > certpath: PolicyChecker.checkPolicy() ---checking certificate policies... > > certpath: PolicyChecker.checkPolicy() certIndex = 1 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 3 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 3 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: > inhibitAnyPolicy = 3 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = > anyPolicy? ROOT > > certpath: PolicyChecker.processPolicies() policiesCritical = false > > certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true > > certpath: PolicyChecker.processPolicies() processing policy: 2.5.29.32.0 > > certpath: PolicyChecker.processParents(): matchAny = true > > certpath: PolicyChecker.processParents() found parent: > > anyPolicy? ROOT > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = > anyPolicy? ROOT > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > certpath: PolicyChecker.checkPolicy() certificate policies verified > > certpath: -checker5 validation succeeded > > certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker] > > certpath: ---checking validity:Fri Jul 01 00:00:00 CEST 2016... > > certpath: validity verified. > > certpath: ---checking subject/issuer name chaining... > > certpath: subject/issuer name chaining verified. > > certpath: ---checking signature... > > certpath: signature verified. > > certpath: BasicChecker.updateState issuer: CN=Actalis Authentication > Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT; subject: > CN=Actalis Authentication CA G3, O=Actalis S.p.A./03358520967, L=Milano, > ST=Milano, C=IT; serial#: 8366940759504193212 > > certpath: -checker6 validation succeeded > > certpath: -Using checker7 ... > [sun.security.provider.certpath.RevocationChecker] > > certpath: RevocationChecker.check: checking cert > > ? SN:???? 741d584a 72fc06bc > > ? Subject: CN=Actalis Authentication CA G3, O=Actalis > S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > ? Issuer: CN=Actalis Authentication Root CA, O=Actalis > S.p.A./03358520967, L=Milan, C=IT > > certpath: connecting to OCSP service at: > http://portal.actalis.it/VA/AUTH-ROOT > > certpath: OCSP response status: SUCCESSFUL > > certpath: OCSP response type: basic > > certpath: Responder ID: byName: CN=Actalis Authentication Root CA - OCSP > Responder, O=Actalis S.p.A./03358520967, C=IT > > certpath: OCSP response produced at: Mon Nov 19 10:39:25 CET 2018 > > certpath: OCSP number of SingleResponses: 1 > > certpath: thisUpdate: Fri Oct 19 14:29:36 CEST 2018 > > certpath: nextUpdate: Thu Jan 17 13:29:36 CET 2019 > > certpath: OCSP response cert #1: CN=Actalis Authentication Root CA - > OCSP Responder, O=Actalis S.p.A./03358520967, C=IT > > certpath: Status of certificate (with serial number 8366940759504193212) > is: GOOD > > certpath: AlgorithmChecker.contains: SHA256withRSA > > certpath: AnchorCertificate.contains: matched CN=Actalis Authentication > Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT > > certpath: trustedMatch = true > > certpath: Constraints.permits(): SHA256withRSA Variant: generic > > certpath: KeySizeConstraints.permits(): RSA > > certpath: Responder's certificate includes the extension > id-pkix-ocsp-nocheck. > > certpath: OCSP response is signed by an Authorized Responder > > certpath: Constraints.permits(): SHA1withRSA Variant: generic > > certpath: jdkCAConstraints.permits(): SHA1 > > certpath: Verified signature of OCSP Response > > certpath: OCSP response validity interval is from Fri Oct 19 14:29:36 > CEST 2018 until Thu Jan 17 13:29:36 CET 2019 > > certpath: Checking validity of OCSP response on: Mon Nov 19 10:39:25 CET > 2018 > > certpath: -checker7 validation succeeded > > certpath: > > cert1 validation succeeded. > > certpath: Checking cert2 - Subject: CN=ssltest-r.actalis.it, O=Actalis > S.p.A., L=Ponte San Pietro, ST=Bergamo, C=IT > > certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19} > > certpath: -Using checker1 ... > [sun.security.provider.certpath.UntrustedChecker] > > certpath: -checker1 validation succeeded > > certpath: -Using checker2 ... > [sun.security.provider.certpath.AlgorithmChecker] > > certpath: Constraints.permits(): SHA256withRSA Variant: generic > > certpath: KeySizeConstraints.permits(): RSA > > certpath: -checker2 validation succeeded > > certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker] > > certpath: -checker3 validation succeeded > > certpath: -Using checker4 ... > [sun.security.provider.certpath.ConstraintsChecker] > > certpath: ---checking basic constraints... > > certpath: i = 2, maxPathLength = 1 > > certpath: after processing, maxPathLength = 1 > > certpath: basic constraints verified. > > certpath: ---checking name constraints... > > certpath: prevNC = null, newNC = null > > certpath: mergedNC = null > > certpath: name constraints verified. > > certpath: -checker4 validation succeeded > > certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker] > > certpath: PolicyChecker.checkPolicy() ---checking certificate policies... > > certpath: PolicyChecker.checkPolicy() certIndex = 2 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 2 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 2 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: > inhibitAnyPolicy = 2 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = > anyPolicy? ROOT > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > certpath: PolicyChecker.processPolicies() policiesCritical = false > > certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true > > certpath: PolicyChecker.processPolicies() processing policy: 1.3.159.1.20.1 > > certpath: PolicyChecker.processParents(): matchAny = false > > certpath: PolicyChecker.processParents(): matchAny = true > > certpath: PolicyChecker.processParents() found parent: > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > certpath: PolicyChecker.processPolicies() processing policy: 2.23.140.1.2.2 > > certpath: PolicyChecker.processParents(): matchAny = false > > certpath: PolicyChecker.processParents(): matchAny = true > > certpath: PolicyChecker.processParents() found parent: > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = > anyPolicy? ROOT > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > ??? 2.23.140.1.2.2? CRIT: false? EP: 2.23.140.1.2.2? (2) > > ??? 1.3.159.1.20.1? CRIT: false? EP: 1.3.159.1.20.1? (2) > > certpath: PolicyChecker.checkPolicy() certificate policies verified > > certpath: -checker5 validation succeeded > > certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker] > > certpath: ---checking validity:Fri Jul 01 00:00:00 CEST 2016... > > certpath: validity verified. > > certpath: ---checking subject/issuer name chaining... > > certpath: subject/issuer name chaining verified. > > certpath: ---checking signature... > > certpath: signature verified. > > certpath: BasicChecker.updateState issuer: CN=Actalis Authentication CA > G3, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT; subject: > CN=ssltest-r.actalis.it, O=Actalis S.p.A., L=Ponte San Pietro, > ST=Bergamo, C=IT; serial#: 312400490844506479 > > certpath: -checker6 validation succeeded > > certpath: -Using checker7 ... > [sun.security.provider.certpath.RevocationChecker] > > certpath: RevocationChecker.check: checking cert > > ? SN:???? 0455de97 5c71c96f > > ? Subject: CN=ssltest-r.actalis.it, O=Actalis S.p.A., L=Ponte San > Pietro, ST=Bergamo, C=IT > > ? Issuer: CN=Actalis Authentication CA G3, O=Actalis > S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > certpath: connecting to OCSP service at: http://ocsp03.actalis.it/VA/AUTH-G3 > > certpath: OCSP response status: SUCCESSFUL > > certpath: OCSP response type: basic > > certpath: Responder ID: byName: CN=Actalis Authentication CA G3 - OCSP > Responder, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > certpath: OCSP response produced at: Mon Nov 19 10:39:25 CET 2018 > > certpath: OCSP number of SingleResponses: 1 > > certpath: Revocation time: Fri Jan 29 10:06:42 CET 2016 > > certpath: Revocation reason: CESSATION_OF_OPERATION > > certpath: thisUpdate: Mon Nov 19 06:46:50 CET 2018 > > certpath: nextUpdate: Tue Nov 20 06:46:50 CET 2018 > > certpath: OCSP response cert #1: CN=Actalis Authentication CA G3 - OCSP > Responder, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > certpath: Status of certificate (with serial number 312400490844506479) > is: REVOKED > > certpath: AlgorithmChecker.contains: SHA256withRSA > > certpath: AnchorCertificate.contains: matched CN=Actalis Authentication > Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT > > certpath: trustedMatch = true > > certpath: Constraints.permits(): SHA256withRSA Variant: generic > > certpath: KeySizeConstraints.permits(): RSA > > certpath: Responder's certificate includes the extension > id-pkix-ocsp-nocheck. > > certpath: OCSP response is signed by an Authorized Responder > > certpath: Constraints.permits(): SHA1withRSA Variant: generic > > certpath: jdkCAConstraints.permits(): SHA1 > > certpath: Verified signature of OCSP Response > > certpath: OCSP response validity interval is from Mon Nov 19 06:46:50 > CET 2018 until Tue Nov 20 06:46:50 CET 2018 > > certpath: Checking validity of OCSP response on: Mon Nov 19 10:39:25 CET > 2018 > > certpath: X509CertSelector.match(SN: 1a5 > > ? Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, > Inc.", O=GTE Corporation, C=US > > ? Subject: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, > Inc.", O=GTE Corporation, C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 9b7e0649a33e62b9d5ee90487129ef57 > > ? Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - > G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign > Trust Network, O="VeriSign, Inc.", C=US > > ? Subject: CN=VeriSign Class 3 Public Primary Certification Authority - > G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign > Trust Network, O="VeriSign, Inc.", C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: b92f60cc889fa17a4609b85b706c8aaf > > ? Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For > authorized use only", OU=Class 2 Public Primary Certification Authority > - G2, O="VeriSign, Inc.", C=US > > ? Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For > authorized use only", OU=Class 2 Public Primary Certification Authority > - G2, O="VeriSign, Inc.", C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 67c8e1e8e3be1cbdfc913b8ea6238749 > > ? Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, > L=Durbanville, ST=Western Cape, C=ZA > > ? Subject: CN=Thawte Timestamping CA, OU=Thawte Certification, > O=Thawte, L=Durbanville, ST=Western Cape, C=ZA) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 10020 > > ? Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL > > ? Subject: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 36122296c5e338a520a1d25f4cd70954 > > ? Issuer: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium > Server CA, OU=Certification Services Division, O=Thawte Consulting cc, > L=Cape Town, ST=Western Cape, C=ZA > > ? Subject: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium > Server CA, OU=Certification Services Division, O=Thawte Consulting cc, > L=Cape Town, ST=Western Cape, C=ZA) > > certpath: X509CertSelector.match: subject DNs don't match > > STATUS:Passed. > > -------------------------------- > > certpath: PKIXCertPathValidator.engineValidate()... > > certpath: X509CertSelector.match(SN: 9b7e0649a33e62b9d5ee90487129ef57 > > ? Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - > G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign > Trust Network, O="VeriSign, Inc.", C=US > > ? Subject: CN=VeriSign Class 3 Public Primary Certification Authority - > G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign > Trust Network, O="VeriSign, Inc.", C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 1a5 > > ? Issuer: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, > Inc.", O=GTE Corporation, C=US > > ? Subject: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, > Inc.", O=GTE Corporation, C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 10020 > > ? Issuer: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL > > ? Subject: CN=Certum CA, O=Unizeto Sp. z o.o., C=PL) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 7dd9fe07cfa81eb7107967fba78934c6 > > ? Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For > authorized use only", OU=Class 3 Public Primary Certification Authority > - G2, O="VeriSign, Inc.", C=US > > ? Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For > authorized use only", OU=Class 3 Public Primary Certification Authority > - G2, O="VeriSign, Inc.", C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 36122296c5e338a520a1d25f4cd70954 > > ? Issuer: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium > Server CA, OU=Certification Services Division, O=Thawte Consulting cc, > L=Cape Town, ST=Western Cape, C=ZA > > ? Subject: EMAILADDRESS=premium-server at thawte.com, CN=Thawte Premium > Server CA, OU=Certification Services Division, O=Thawte Consulting cc, > L=Cape Town, ST=Western Cape, C=ZA) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: b92f60cc889fa17a4609b85b706c8aaf > > ? Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For > authorized use only", OU=Class 2 Public Primary Certification Authority > - G2, O="VeriSign, Inc.", C=US > > ? Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For > authorized use only", OU=Class 2 Public Primary Certification Authority > - G2, O="VeriSign, Inc.", C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 570a119742c4e3cc > > ? Issuer: CN=Actalis Authentication Root CA, O=Actalis > S.p.A./03358520967, L=Milan, C=IT > > ? Subject: CN=Actalis Authentication Root CA, O=Actalis > S.p.A./03358520967, L=Milan, C=IT) > > certpath: X509CertSelector.match returning: true > > certpath: YES - try this trustedCert > > certpath: anchor.getTrustedCert().getSubjectX500Principal() = CN=Actalis > Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT > > certpath: Constraints: MD2 > > certpath: Constraints: MD5 > > certpath: Constraints: SHA1 jdkCA & usage TLSServer > > certpath: Constraints set to jdkCA. > > certpath: Constraints usage length is 1 > > certpath: Constraints: RSA keySize < 1024 > > certpath: Constraints set to keySize: keySize < 1024 > > certpath: Constraints: DSA keySize < 1024 > > certpath: Constraints set to keySize: keySize < 1024 > > certpath: Constraints: EC keySize < 224 > > certpath: Constraints set to keySize: keySize < 224 > > certpath: AlgorithmChecker.contains: SHA256withRSA > > certpath: AnchorCertificate.contains: matched CN=Actalis Authentication > Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT > > certpath: trustedMatch = true > > certpath: -------------------------------------------------------------- > > certpath: Executing PKIX certification path validation algorithm. > > certpath: Checking cert1 - Subject: CN=Actalis Extended Validation > Server CA G1, O=Actalis S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > certpath: Set of critical extensions: {2.5.29.15, 2.5.29.19} > > certpath: -Using checker1 ... > [sun.security.provider.certpath.UntrustedChecker] > > certpath: -checker1 validation succeeded > > certpath: -Using checker2 ... > [sun.security.provider.certpath.AlgorithmChecker] > > certpath: Constraints.permits(): SHA256withRSA Variant: generic > > certpath: KeySizeConstraints.permits(): RSA > > certpath: -checker2 validation succeeded > > certpath: -Using checker3 ... [sun.security.provider.certpath.KeyChecker] > > certpath: KeyChecker.verifyCAKeyUsage() ---checking CA key usage... > > certpath: KeyChecker.verifyCAKeyUsage() CA key usage verified. > > certpath: -checker3 validation succeeded > > certpath: -Using checker4 ... > [sun.security.provider.certpath.ConstraintsChecker] > > certpath: ---checking basic constraints... > > certpath: i = 1, maxPathLength = 2 > > certpath: after processing, maxPathLength = 1 > > certpath: basic constraints verified. > > certpath: ---checking name constraints... > > certpath: prevNC = null, newNC = null > > certpath: mergedNC = null > > certpath: name constraints verified. > > certpath: -checker4 validation succeeded > > certpath: -Using checker5 ... [sun.security.provider.certpath.PolicyChecker] > > certpath: PolicyChecker.checkPolicy() ---checking certificate policies... > > certpath: PolicyChecker.checkPolicy() certIndex = 1 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: explicitPolicy = 3 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyMapping = 3 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: > inhibitAnyPolicy = 3 > > certpath: PolicyChecker.checkPolicy() BEFORE PROCESSING: policyTree = > anyPolicy? ROOT > > certpath: PolicyChecker.processPolicies() policiesCritical = false > > certpath: PolicyChecker.processPolicies() rejectPolicyQualifiers = true > > certpath: PolicyChecker.processPolicies() processing policy: 2.5.29.32.0 > > certpath: PolicyChecker.processParents(): matchAny = true > > certpath: PolicyChecker.processParents() found parent: > > anyPolicy? ROOT > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: explicitPolicy = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyMapping = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: inhibitAnyPolicy = 2 > > certpath: PolicyChecker.checkPolicy() AFTER PROCESSING: policyTree = > anyPolicy? ROOT > > ? anyPolicy? CRIT: false? EP: anyPolicy? (1) > > certpath: PolicyChecker.checkPolicy() certificate policies verified > > certpath: -checker5 validation succeeded > > certpath: -Using checker6 ... [sun.security.provider.certpath.BasicChecker] > > certpath: ---checking validity:Mon Nov 19 10:39:25 CET 2018... > > certpath: validity verified. > > certpath: ---checking subject/issuer name chaining... > > certpath: subject/issuer name chaining verified. > > certpath: ---checking signature... > > certpath: signature verified. > > certpath: BasicChecker.updateState issuer: CN=Actalis Authentication > Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT; subject: > CN=Actalis Extended Validation Server CA G1, O=Actalis > S.p.A./03358520967, L=Milano, ST=Milano, C=IT; serial#: 3663163709977533131 > > certpath: -checker6 validation succeeded > > certpath: -Using checker7 ... > [sun.security.provider.certpath.RevocationChecker] > > certpath: RevocationChecker.check: checking cert > > ? SN:???? 32d62bfc 67501acb > > ? Subject: CN=Actalis Extended Validation Server CA G1, O=Actalis > S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > ? Issuer: CN=Actalis Authentication Root CA, O=Actalis > S.p.A./03358520967, L=Milan, C=IT > > certpath: RevocationChecker.checkCRLs() ---checking revocation status ... > > certpath: RevocationChecker.checkCRLs() possible crls.size() = 0 > > certpath: RevocationChecker.checkCRLs() approved crls.size() = 0 > > certpath: DistributionPointFetcher.getCRLs: Checking CRLDPs for > CN=Actalis Extended Validation Server CA G1, O=Actalis > S.p.A./03358520967, L=Milano, ST=Milano, C=IT > > certpath: Trying to fetch CRL from DP > ldap://ldap05.actalis.it/cn%3dActalis%20Authentication%20Root%20CA,o%3dActalis%20S.p.A.%2f03358520967,c%3dIT?certificateRevocationList;binary > > certpath: CertStore > URI:ldap://ldap05.actalis.it/cn%3dActalis%20Authentication%20Root%20CA,o%3dActalis%20S.p.A.%2f03358520967,c%3dIT?certificateRevocationList;binary > > certpath: LDAPCertStore.engineGetCRLs() selector: null > > certpath: X509CertSelector.match(SN: 3c9131cb1ff6d01b0e9ab8d044bf12be > > ? Issuer: OU=Class 3 Public Primary Certification Authority, > O="VeriSign, Inc.", C=US > > ? Subject: OU=Class 3 Public Primary Certification Authority, > O="VeriSign, Inc.", C=US) > > certpath: X509CertSelector.match: subject DNs don't match > > certpath: X509CertSelector.match(SN: 67c8e1e8e3be1cbdfc913b8ea6238749 > > ? Issuer: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, > L=Durbanville, ST=Western Cape, C=ZA > > ? Subject: CN=Thawte Timestamping CA, OU=Thawte Certification, > O=Thawte, L=Durbanville, ST=Western Cape, C=ZA) > > certpath: X509CertSelector.match: subject DNs don't match > > java.lang.RuntimeException: TEST FAILED: couldn't determine EE > certificate status > > ??????????????? at > ValidatePathWithParams.validate(ValidatePathWithParams.java:177) > > ??????????????? at ActalisCA.main(ActalisCA.java:235) > > ??????????????? at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > ??????????????? at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > ??????????????? at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > ??????????????? at > java.base/java.lang.reflect.Method.invoke(Method.java:566) > > ??????????????? at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) > > ??????????????? at java.base/java.lang.Thread.run(Thread.java:834) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: TEST > FAILED: couldn't determine EE certificate status > > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.RuntimeException: TEST > FAILED: couldn't determine EE certificate status > From matthias.baesken at sap.com Mon Nov 26 13:44:54 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 26 Nov 2018 13:44:54 +0000 Subject: jdk11u and jdk/jdk : jtreg test error in security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java In-Reply-To: <29e2f8e4-ce23-d5a1-211b-ef578bc05188@oracle.com> References: <29e2f8e4-ce23-d5a1-211b-ef578bc05188@oracle.com> Message-ID: Hi Sean thanks for the info . Strange that the bug https://bugs.openjdk.java.net/browse/JDK-8202651 is from May , but we only see the issue since last week ?! Best regards, Matthias > -----Original Message----- > From: Sean Mullan > Sent: Montag, 26. November 2018 14:24 > To: Baesken, Matthias ; security- > dev at openjdk.java.net > Subject: Re: jdk11u and jdk/jdk : jtreg test error in > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja > va > > On 11/26/18 7:51 AM, Baesken, Matthias wrote: > > Hello, since 18th / 19th? November we notice an error in the jtreg test > > > > > > > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja > va > > > > (on all platforms, for example linux x86_64 ). > > > > Has anyone else seen the issue, or is it just us ? > > Yes, this is a known issue, see > https://bugs.openjdk.java.net/browse/JDK-8202651 > > --Sean > From sean.mullan at oracle.com Mon Nov 26 14:56:37 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 26 Nov 2018 09:56:37 -0500 Subject: jdk11u and jdk/jdk : jtreg test error in security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java In-Reply-To: References: <29e2f8e4-ce23-d5a1-211b-ef578bc05188@oracle.com> Message-ID: <5cba20d6-6790-fe7e-7bf3-20d320fb24a8@oracle.com> On 11/26/18 8:44 AM, Baesken, Matthias wrote: > Hi Sean thanks for the info . > > Strange that the bug https://bugs.openjdk.java.net/browse/JDK-8202651 is from May , but we only see the issue since last week ?! It was marked Confidential for some reason, possibly by accident because these tests used to be closed before we open sourced them in JDK 10. I opened up the bug today. --Sean From xuelei.fan at oracle.com Mon Nov 26 18:14:30 2018 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Mon, 26 Nov 2018 10:14:30 -0800 Subject: Code Review Request, JDK-8213577, Update the default SSL session cache size to 20480 In-Reply-To: References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com> <228516ab-aaca-5a4e-f709-3b4f44a82101@oracle.com> <0ed3fc6a-e338-3c4b-3a9a-0d3123946e0c@oracle.com> Message-ID: I made the update accordingly: ? http://cr.openjdk.java.net/~xuelei/8210985/webrev.04/ Thanks, Xuelei On 11/19/2018 7:39 AM, Sean Mullan wrote: > On 11/16/18 3:19 PM, Xuelei Fan wrote: >> Thanks for the review, Jmail & Sean. >> >> New webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.03/ >> >> I will update CSR when we come to an agreement. >> >> On 11/16/2018 11:33 AM, Sean Mullan wrote: >>> ??122????? * @apiNote Both the session timeout and cache size impact >>> performance >>> ??123????? *????????? of future connections.? It is not recommended >>> to use too big >>> ??124????? *????????? or too small timeout or cache size limit. >>> Applications should >>> ??125????? *????????? carefully weigh the limits and performance for >>> the specific >>> ??126????? *????????? circumstances. >>> >>> I am not really sure if the @apiNote is that useful or appropriate, >> I worry about the default value actually. > > Then maybe the default is what you should be discussing in this > apiNote. Right now I don't think the apiNote adds much. To me, all you > are really saying is that these are methods that can be used to tune > performance, which I think should be obvious from their name and > description. Maybe the apiNote should say something like: > > "Note that the JDK Implementation uses default values for both the > session cache size and timeout. See getSessionCacheSize and > getSessionTimeout for more information. Applications should consider > their performance requirements and override the defaults if necessary." > > Also I think you should add a similar @implNote for getSessionTimeout > which describes the default value (86400 seconds or 24 hours), ex: > > @implNote The JDK implementation returns the session timeout as set by > ?????? the {@code setSessionTimeout} method, or if not set, a default > value of 86400 seconds (24 hours). > >> ? A new bug may be filed again and argue if the default value is not >> a proper one.? The default value of session timeout and cache size >> really depends on the real world circumstances.? I think we'd better >> make a clarification in the spec, and remind application tune them >> accordingly. > > Ok, but the apiNote above says nothing about the default value. > > --Sean > >> >>> but it seems a bit odd to talk about the session timeout in this >>> method. >> The performance impact is a combination of the session timeout limit >> and cache size.? I would like application consider them together if >> need to tune the values, but not individually. >> >>> If you still want to add this, I would add an @apiNote to each of >>> the setSessionCacheSize and setSessionTimeout methods and just >>> discuss each property separately. >>> >> I added the update spec to both setSessionCacheSize and >> setSessionTimeout. >> >>> Also, unless you say what "too big" or "too small" is, I would avoid >>> giving this advice. >>> >> It makes sense to me. >> >> Thanks, >> Xuelei >> >>> --Sean >>> >>> >>> On 11/16/18 1:30 PM, Xuelei Fan wrote: >>>> It's time to use the systemProperty tag as it is ready. >>>> >>>> As we are already there, I also update the setSessionCacheSize() >>>> for more clarification. >>>> >>>> Please review both CSR and webrev: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8213577 >>>> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.02/ >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 11/16/2018 8:19 AM, Sean Mullan wrote: >>>>> On 11/15/18 3:37 PM, Xuelei Fan wrote: >>>>>> Hi Sean, >>>>>> >>>>>> Are you OK if we do it later?? I'm waiting for the >>>>>> @systemProperty tag, proposed within JDK-5076751.? I will file a >>>>>> bug to use the tag for more cleanup. >>>>> >>>>> JDK-5076751 is completed and pushed to JDK 12, so you can use the >>>>> new tag now. >>>>> >>>>> I think it would be easier to do it now, it seems pretty simple >>>>> and that way there is no need to worry about it later. >>>>> >>>>> --Sean >>>>> >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 11/15/2018 11:55 AM, Sean Mullan wrote: >>>>>>> This is a good opportunity to document the >>>>>>> javax.net.ssl.sessionCacheSize system property in the >>>>>>> SSLSessionContext API (and use the new @systemProperty tag) in >>>>>>> an @implNote, for example: >>>>>>> >>>>>>> ???? /** >>>>>>> ????? * Returns the size of the cache used for storing >>>>>>> ????? * SSLSession objects grouped under this >>>>>>> ????? * SSLSessionContext. >>>>>>> ????? * >>>>>>> ????? * @implNote The JDK implementation returns the cache size >>>>>>> as set by >>>>>>> ????? * the {@code setSessionCacheSize method}, or if not set, >>>>>>> the value >>>>>>> ????? * of the {@systemProperty javax.net.ssl.sessionCacheSize} >>>>>>> system >>>>>>> ????? * property. If neither is set, it returns a default value >>>>>>> of 20480. >>>>>>> ????? * >>>>>>> ????? * @return size of the session cache; zero means there is >>>>>>> no size limit. >>>>>>> ????? * @see #setSessionCacheSize >>>>>>> ????? */ >>>>>>> ???? public int getSessionCacheSize(); >>>>>>> >>>>>>> On 11/14/18 11:59 AM, Xuelei Fan wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this simple update: >>>>>>>> http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/ >>>>>>>> >>>>>>>> The default value for the maximum number of entries in the SSL >>>>>>>> session cache (SSLSessionContext.getSessionCacheSize()) is >>>>>>>> infinite now.? In the request, the default value is updated to >>>>>>>> 20480 for performance consideration. >>>>>>>> >>>>>>>> For the detailed behavior update, please refer to CSR: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213577 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei From sean.mullan at oracle.com Mon Nov 26 19:56:06 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 26 Nov 2018 14:56:06 -0500 Subject: RFR 8214100: use of keystore probing results in unnecessary exception thrown In-Reply-To: References: Message-ID: <328a93b4-5cca-00fe-f163-a91caf7b0514@oracle.com> Looks good. --Sean On 11/22/18 8:12 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8214100/webrev.00/ > > Some exception handling codes are added to keytool when the keystore type does not support probing. > > Thanks > Max > From joe.darcy at oracle.com Mon Nov 26 21:38:32 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 26 Nov 2018 13:38:32 -0800 Subject: JDK 12 RFR of JDK-8213911: Use example.com in java.net and other examples Message-ID: <072b68a2-38ee-890c-c0e3-84afa4b641db@oracle.com> Hello, Please review a simple doc-only change to address: ??? JDK-8213911: Use example.com in java.net and other examples ??? http://cr.openjdk.java.net/~darcy/8213911.0/ Patch below. Thanks, -Joe --- old/src/java.base/share/classes/java/net/HostPortrange.java 2018-11-26 13:32:47.078000000 -0800 +++ new/src/java.base/share/classes/java/net/HostPortrange.java 2018-11-26 13:32:46.902000000 -0800 @@ -60,7 +60,7 @@ ???? HostPortrange(String scheme, String str) { ???????? // Parse the host name.? A name has up to three components, the ???????? // hostname, a port number, or two numbers representing a port -??????? // range.?? "www.sun.com:8080-9090" is a valid host name. +??????? // range.?? "www.example.com:8080-9090" is a valid host name. ???????? // With IPv6 an address can be 2010:836B:4179::836B:4179 ???????? // An IPv6 address needs to be enclose in [] --- old/src/java.base/share/classes/java/net/InetAddress.java 2018-11-26 13:32:47.474000000 -0800 +++ new/src/java.base/share/classes/java/net/InetAddress.java 2018-11-26 13:32:47.298000000 -0800 @@ -1168,7 +1168,7 @@ ????? * No name service is checked for the validity of the address. ????? * ????? *

The host name can either be a machine name, such as -???? * "{@code java.sun.com}", or a textual representation of its IP +???? * "{@code www.example.com}", or a textual representation of its IP ????? * address. ????? *

No validity checking is done on the host name either. ????? * @@ -1213,7 +1213,7 @@ ????? * Determines the IP address of a host, given the host's name. ????? * ????? *

The host name can either be a machine name, such as -???? * "{@code java.sun.com}", or a textual representation of its +???? * "{@code www.example.com}", or a textual representation of its ????? * IP address. If a literal IP address is supplied, only the ????? * validity of the address format is checked. ????? * @@ -1259,7 +1259,7 @@ ????? * based on the configured name service on the system. ????? * ????? *

The host name can either be a machine name, such as -???? * "{@code java.sun.com}", or a textual representation of its IP +???? * "{@code www.example.com}", or a textual representation of its IP ????? * address. If a literal IP address is supplied, only the ????? * validity of the address format is checked. ????? * --- old/src/java.base/share/classes/java/net/SocketPermission.java 2018-11-26 13:32:47.850000000 -0800 +++ new/src/java.base/share/classes/java/net/SocketPermission.java 2018-11-26 13:32:47.678000000 -0800 @@ -63,7 +63,7 @@ ? * or as "localhost" (for the local machine). ? * The wildcard "*" may be included once in a DNS name host ? * specification. If it is included, it must be in the leftmost - * position, as in "*.sun.com". + * position, as in "*.example.com". ? *

? * The format of the IPv6reference should follow that specified in RFC 2732: Format @@ -115,11 +115,11 @@ ? * note that if the following permission: ? * ? * 

- *?? p1 = new SocketPermission("puffin.eng.sun.com:7777", 
"connect,accept");
+ *?? p1 = new SocketPermission("foo.example.com:7777", "connect,accept");
 ? *
? * ? * is granted to some code, it allows that code to connect to port 7777 on - * {@code puffin.eng.sun.com}, and to accept connections on that port. + * {@code foo.example.com}, and to accept connections on that port. ? * ? *

Similarly, if the following permission: ? * @@ -211,7 +211,7 @@ ???? // all the IP addresses of the host ???? private transient InetAddress[] addresses; -??? // true if the hostname is a wildcard (e.g. "*.sun.com") +??? // true if the hostname is a wildcard (e.g. "*.example.com") ???? private transient boolean wildcard; ???? // true if we were initialized with a single numeric IP address @@ -274,9 +274,9 @@ ????? *

????? * Examples of SocketPermission instantiation are the following: ????? * 

-???? *??? nr = new SocketPermission("www.catalog.com", "connect");
-???? *??? nr = new SocketPermission("www.sun.com:80", "connect");
-???? *??? nr = new SocketPermission("*.sun.com", "connect");
+???? *??? nr = new SocketPermission("www.example.com", "connect");
+???? *??? nr = new SocketPermission("www.example.com:80", "connect");
+???? *??? nr = new SocketPermission("*.example.com", "connect");
 ????? *??? nr = new SocketPermission("*.edu", "resolve");
 ????? *??? nr = new SocketPermission("204.160.241.0", "connect");
 ????? *??? nr = new SocketPermission("localhost:1024-65535", "listen");
@@ -400,7 +400,7 @@

 ???????? // Parse the host name.? A name has up to three components, the
 ???????? // hostname, a port number, or two numbers representing a port
-??????? // range.?? "www.sun.com:8080-9090" is a valid host name.
+??????? // range.?? "www.example.com:8080-9090" is a valid host name.

 ???????? // With IPv6 an address can be 2010:836B:4179::836B:4179
 ???????? // An IPv6 address needs to be enclose in []
@@ -835,10 +835,10 @@
 ????? * 
    
 ????? * 
  •  If this object was initialized with a single IP address 
and one of p's
 ????? * IP addresses is equal to this object's IP address.
-???? * 
  • If this object is a wildcard domain (such as *.sun.com), and
+???? * 
  • If this object is a wildcard domain (such as *.example.com), and
 ????? * p's canonical name (the name without any preceding *)
-???? * ends with this object's canonical host name. For example, *.sun.com
-???? * implies *.eng.sun.com.
+???? * ends with this object's canonical host name. For example, 
*.example.com
+???? * implies *.foo.example.com.
 ????? * 
  • If this object was not initialized with a single IP 
address, and one of this
 ????? * object's IP addresses equals one of p's IP addresses.
 ????? * 
  • If this canonical name equals p's canonical name.
@@ -878,7 +878,7 @@
 ????? * 
  •  Checks that "p"'s port range is included in this port range
 ????? * 
  •  If this object was initialized with an IP address, checks that
 ????? *????? one of "p"'s IP addresses is equal to this object's IP 
address.
-???? * 
  •  If either object is a wildcard domain (i.e., "*.sun.com"),
+???? * 
  •  If either object is a wildcard domain (i.e., "*.example.com"),
 ????? *????? attempt to match based on the wildcard.
 ????? * 
  •  If this object was not initialized with an IP address, attempt
 ????? *????? to find a match based on the IP addresses in both objects.
@@ -944,8 +944,8 @@
 ???????????? // check and see if we have any wildcards...
 ???????????? if (this.wildcard || that.wildcard) {
 ???????????????? // if they are both wildcards, return true iff
-??????????????? // that's cname ends with this cname (i.e., *.sun.com
-??????????????? // implies *.eng.sun.com)
+??????????????? // that's cname ends with this cname (i.e., *.example.com
+??????????????? // implies *.foo.example.com)
 ???????????????? if (this.wildcard && that.wildcard)
 ???????????????????? return (that.cname.endsWith(this.cname));

@@ -1057,7 +1057,7 @@
 ???????? // "1.2.3.4" equal to "1.2.3.4.", or
 ???????? //? "*.edu" equal to "*.edu", but it
 ???????? //? does not catch "crypto" equal to
-??????? // "crypto.eng.sun.com".
+??????? // "crypto.foo.example.com".

 ???????? if (this.getName().equalsIgnoreCase(that.getName())) {
 ???????????? return true;
@@ -1313,7 +1313,7 @@
 ???????? SocketPermissionCollection nps = new SocketPermissionCollection();
 ???????? nps.add(this_);
 ???????? nps.add(new 
SocketPermission("www-leland.stanford.edu","connect"));
-??????? nps.add(new SocketPermission("www-sun.com","connect"));
+??????? nps.add(new SocketPermission("www-example.com","connect"));
 ???????? System.out.println("nps.implies(that) = " + nps.implies(that_));
 ???????? System.out.println("-----\n");
 ???? }
--- old/src/java.base/share/classes/java/net/URI.java 2018-11-26 
13:32:48.246000000 -0800
+++ new/src/java.base/share/classes/java/net/URI.java 2018-11-26 
13:32:48.070000000 -0800
@@ -83,7 +83,7 @@
 ? * subject to further parsing.? Some examples of opaque URIs are:
 ? *
 ? * 
      
- * 
    • {@code mailto:java-net at java.sun.com}
      • 
+ * 
    • {@code mailto:java-net at www.example.com}
      • 
 ? * 
    • {@code news:comp.lang.java}
      • 
 ? * 
    • {@code urn:isbn:096139210x}
      • 
 ? * 
    
@@ -399,7 +399,7 @@
 ? * For any URI u that does not contain redundant syntax such as two
 ? * slashes before an empty authority (as in {@code 
file:///tmp/} ) or a
 ? * colon following a host name but no port (as in
- * {@code http://java.sun.com:} ), and that does not encode characters
+ * {@code http://www.example.com:} ), and that does not encode 
characters
 ? * except those that must be quoted, the following identities also hold:
 ? * 
     ? *???? new URI(u.getScheme(),
--- old/src/java.base/share/classes/java/net/URL.java 2018-11-26 
13:32:48.658000000 -0800
+++ new/src/java.base/share/classes/java/net/URL.java 2018-11-26 
13:32:48.490000000 -0800
@@ -95,7 +95,7 @@
 ? * as a "ref" or a "reference". The fragment is indicated by the sharp
 ? * sign character "#" followed by more characters. For example,
 ? * 
    - *???? http://java.sun.com/index.html#chapter1
+ *???? http://www.example.com/index.html#chapter1
 ? * 
    
 ? * 
    
 ? * This fragment is not technically part of the URL. Rather, it
@@ -109,7 +109,7 @@
 ? * relative to another URL. Relative URLs are frequently used within
 ? * HTML pages. For example, if the contents of the URL:
 ? * 
    - *???? http://java.sun.com/index.html
+ *???? http://www.example.com/index.html
 ? * 
    
 ? * contained within it the relative URL:
 ? * 
    @@ -117,7 +117,7 @@
 ? * 
    
 ? * it would be a shorthand for:
 ? * 
    - *???? http://java.sun.com/FAQ.html
+ *???? http://www.example.com/FAQ.html
 ? * 
    
 ? * 
    
 ? * The relative URL need not specify all the components of a URL. If
--- old/src/java.base/share/classes/java/net/URLPermission.java 
2018-11-26 13:32:49.050000000 -0800
+++ new/src/java.base/share/classes/java/net/URLPermission.java 
2018-11-26 13:32:48.874000000 -0800
@@ -57,7 +57,7 @@
 ? * RFC 2732. Literal IPv6 addresses must however, be enclosed in 
'[]' characters.
 ? * The dnsname specification can be preceded by "*." which means
 ? * the name will match any hostname whose right-most domain labels are 
the same as
- * this name. For example, "*.oracle.com" matches "foo.bar.oracle.com"
+ * this name. For example, "*.example.com" matches "foo.bar.example.com"
 ? * 
    
 ? * portrange is used to specify a port number, or a bounded or 
unbounded range of ports
 ? * that this permission applies to. If portrange is absent or invalid, 
then a default
@@ -78,18 +78,18 @@
 ? * Example urlDescription
 ? * 
 ? * 
- * http://www.oracle.com/a/b/c.html
+ * http://www.example.com/a/b/c.html
 ? *?? A url which identifies a specific (single) resource
 ? * 
- * http://www.oracle.com/a/b/*
+ * http://www.example.com/a/b/*
 ? *?? The '*' character refers to all resources in the same 
"directory" - in
 ? *?????? other words all resources with the same number of path 
components, and
 ? *?????? which only differ in the final path component, represented by 
the '*'.
 ? *?? 
 ? * 
- * http://www.oracle.com/a/b/-
+ * http://www.example.com/a/b/-
 ? *?? The '-' character refers to all resources recursively below the
- *?????? preceding path (e.g. http://www.oracle.com/a/b/c/d/e.html 
matches this
+ *?????? preceding path (e.g. http://www.example.com/a/b/c/d/e.html 
matches this
 ? *?????? example).
 ? *?? 
 ? * 
@@ -267,9 +267,9 @@
 ????? * 
  • if this's url scheme is not equal to p's url scheme return 
false
    • 
 ????? * 
  • if the scheme specific part of this's url is '*' return 
true
    • 
 ????? * 
  • if the set of hosts defined by p's url hostrange is not a 
subset of
-???? *???? this's url hostrange then return false. For example, 
"*.foo.oracle.com"
-???? *???? is a subset of "*.oracle.com". "foo.bar.oracle.com" is not
-???? *???? a subset of "*.foo.oracle.com"
    • 
+???? *???? this's url hostrange then return false. For example, 
"*.foo.example.com"
+???? *???? is a subset of "*.example.com". "foo.bar.example.com" is not
+???? *???? a subset of "*.foo.example.com"
    • 
 ????? * 
  • if the portrange defined by p's url is not a subset of the
 ????? *???? portrange defined by this's url then return false.
 ????? * 
  • if the path or paths specified by p's url are contained in the
--- old/src/java.base/share/classes/java/net/package-info.java 
2018-11-26 13:32:49.438000000 -0800
+++ new/src/java.base/share/classes/java/net/package-info.java 
2018-11-26 13:32:49.262000000 -0800
@@ -131,7 +131,7 @@
 ? *??? InputStream.
 ? * 
    Here is an example:
    
 ? * 
    - * URI uri = new URI("http://java.sun.com/");
+ * URI uri = new URI("http://www.example.com/");
 ? * URL url = uri.toURL();
 ? * InputStream in = url.openStream();
 ? * 
    
--- old/src/java.base/share/classes/java/nio/file/Files.java 2018-11-26 
13:32:49.798000000 -0800
+++ new/src/java.base/share/classes/java/nio/file/Files.java 2018-11-26 
13:32:49.630000000 -0800
@@ -3067,7 +3067,7 @@
 ????? * it to a file:
 ????? * 
     ????? *???? Path path = ...
-???? *???? URI u = URI.create("http://java.sun.com/");
+???? *???? URI u = URI.create("http://www.example.com/");
 ????? *???? try (InputStream in = u.toURL().openStream()) {
 ????? *???????? Files.copy(in, path);
 ????? *???? }
--- old/src/java.base/share/classes/java/security/CodeSource.java 
2018-11-26 13:32:50.206000000 -0800
+++ new/src/java.base/share/classes/java/security/CodeSource.java 
2018-11-26 13:32:50.042000000 -0800
@@ -309,13 +309,13 @@
 ????? * 
    
 ????? * For example, the codesource objects with the following locations
 ????? * and null certificates all imply
-???? * the codesource with the location 
"http://java.sun.com/classes/foo.jar"
+???? * the codesource with the location 
"http://www.example.com/classes/foo.jar"
 ????? * and null certificates:
 ????? * 
     ????? *???? http:
-???? *???? http://*.sun.com/classes/*
-???? *???? http://java.sun.com/classes/-
-???? *???? http://java.sun.com/classes/foo.jar
+???? *???? http://*.example.com/classes/*
+???? *???? http://www.example.com/classes/-
+???? *???? http://www.example.com/classes/foo.jar
 ????? * 
    
 ????? *
 ????? * Note that if this CodeSource has a null location and a null


From xuelei.fan at oracle.com  Tue Nov 27 00:14:12 2018
From: xuelei.fan at oracle.com (Xue-Lei Fan)
Date: Mon, 26 Nov 2018 16:14:12 -0800
Subject: Code Review Request, JDK-8214321: Misleading code in SSLCipher
Message-ID: <0bcc1900-5520-b998-939a-d89e4c90fe99@oracle.com>

Hi,

Please review this code cleanup in SSLCipher.java:
    http://cr.openjdk.java.net/~xuelei/8214321/webrev.00/

The code should be fine as readCipherGenerators.length and 
writeCipherGenerators.length are the same value in the implementation. 
However, it is misleading to use readCipherGenerators when it is 
intended to use writeCipherGenerators.  It's nice to have a code cleanup 
for readability.

Thanks,
Xuelei


From gg5070 at gmail.com  Thu Nov 15 09:44:44 2018
From: gg5070 at gmail.com (Gidon Gershinsky)
Date: Thu, 15 Nov 2018 11:44:44 +0200
Subject: Problems with AES-GCM native acceleration
In-Reply-To: <864a763d-0d67-d894-234c-fbbef78e0320@oracle.com>
References: 
 <92a16009b9e047eacf102b006bc0612bac4a2cfb.camel@redhat.com>
 <1b1fe9e4-ad71-7d48-13eb-48dbe267962e@oracle.com>
 <864a763d-0d67-d894-234c-fbbef78e0320@oracle.com>
Message-ID: 

Hi all,

Thanks for the prompt feedback on this stuff, appreciated.

1.  Analytic queries are often interactive or one-off. A data scientist
would get an on-demand notebook with a Spark cluster (spawned as a K8s
pod), and run a number of queries.
The cluster will be then closed either explicitly, or after a timeout. This
is done both for a better resource utilization, and for security reasons.
Re-using JVM for another user/tenant
might leak the sensitive data and encryption keys, kept in the JVM memory.
I'm not saying its the only way to solve this, there are architectures
based on a long running service. But this short-lived approach is real and
needs to be addressed.
Even if the data scientist keeps the cluster alive for a few hours - having
to wait a long time for the results of the first few queries (because the
decryption is not warmed up yet) is a problem,
since the things are interactive and expected to be done in real time.

2. Analytics and AI workloads work with ~ 64MB blocks; sometimes, they are
broken in ~1MB pieces (like in Parquet). Still, taking even the minimal
size of 1MB, and waiting the 10,000 rounds to
get the decryption acceleration, means we process the first ~10GB at a slow
rate. Sounds harsh. Both in absolute numbers, and in comparison to
ENcryption, which kicks in after warming up with say 1KB
chunks (created by breaking 1MB blocks into many update calls) - meaning
~1,000x faster than DEcryption.

3. Adam has mentioned an approach of "modifying the decryption operation
(to decrypt immediately and buffer plaintext)" (in a negative context,
though :).
To me, it looks like a sound solution. However, I don't know how much
effort does it require (?) - but it makes decryption implementation similar
to encryption, and solves the problem at hand.
Maybe there are other options, though.

4. AOT sounds interesting, I'll check it out. But its experimental for now.
Moreover, both AOT and command line options require extra care in
production, as correctly pointed out below.
They will be a hard sell in real production environments. The same is true
(or even worse) for manual warm-up with a repeated decryption of small
blocks. This is indeed a benchmarking hack,
I don't see it been used in production.

Having the decryption optimized in the HotSpot engine would be ideal.

Cheers, Gidon.

On Thu, Nov 15, 2018 at 3:33 AM Anthony Scarpino <
anthony.scarpino at oracle.com> wrote:

> I agree with Adam that this is more of a tuning issue and not a problem
> with the crypto.  Sending multiple updates is a hack.
>
> I've been aware of this bug for a while and I do not understand why this
> is a significant problem.  The stackoverflow comments say it takes 50
> seconds to trigger the intrinsic.  If this is a long running server
> application slowness for the first 50 seconds is trivial.  For smaller
> operations, those are commonly small transactions, not decrypting a 3GB
> file.
>
> If it cannot be resolved by commandline options and this is occurring in
> a real world situation, please explain it fully.  If this is only for
> benchmarking, then that's not a real world situation.
>
> Tony
>
> On 11/14/18 8:41 AM, Adam Petcher wrote:
> > I'm adding back in hotspot-dev, because this is a somewhat tricky topic
> > related to intrinsics and JIT. Hopefully, a Hotspot expert can correct
> > anything that I say below that is wrong, and suggest any solutions that
> > I missed.
> >
> > The AES acceleration is implemented in a HotSpot intrinsic. In order for
> > it to kick in, the code must be JIT compiled by the VM. As I understand
> > it, this only happens to some particular method after it has been called
> > a certain number of times. The rules that determine this number are
> > somewhat complicated, but I think you can guarantee JIT in the default
> > configuration by calling a method 10,000 times.
> >
> > The doFinal method calls the update method, so either one should trigger
> > the acceleration as long as you call it enough. Breaking the message up
> > into smaller chunks and calling update on each one works only because it
> > ends up calling the update method more. You should be able to trigger
> > the acceleration by calling doFinal more, too.
> >
> > The reason why the workaround doesn't work with decryption is that the
> > decryption routine buffers the ciphertext and then decrypts it all at
> > the end. So calling update multiple times and then calling doFinal at
> > the end is essentially the same as calling doFinal once with the entire
> > ciphertext.
> >
> > So here are some solutions that you may want to try:
> >
> > 1) In your benchmark, run at least 10,000 "warmup" iterations of
> > whatever you are trying to do at the beginning, without timing it. This
> > is a good idea for benchmarks, anyway. If it helps, you can try using
> > smaller buffers in your "warmup" phase in order to get it to complete
> > faster.
> >
> > 2) Try -XX:CompileThreshold=(some number smaller than 10000) as an
> > argument to java. This will make JIT kick in sooner across the board.
> > Obviously, this should be done carefully in production, since it will
> > impact the performance of the entire program.
> >
> > 3) I haven't tried this, but running with an AOTed java.base module may
> > also help. See the section titled "Steps to generate and use an AOT
> > library for the java.base module" in the AOT JEP[1].
> >
> > "Fixing" this issue in the JDK is non-trivial, because it gets into the
> > behavior of the VM and JIT. I don't really like the idea of modifying
> > doFinal (to break up the operation into multiple update calls) or
> > modifying the decryption operation (to decrypt immediately and buffer
> > plaintext) in order to work around this issue. Perhaps there is a better
> > way for the VM to handle cases like this, in which a method is not
> > called often, but the interpreted execution takes a long time to
> > complete when it is called. Perhaps a VM expert will have some
> > additional thoughts here.
> >
> > [1] https://openjdk.java.net/jeps/295
> >
> > On 11/14/2018 9:49 AM, Severin Gehwolf wrote:
> >> Dropping hotspot-dev and adding security-dev.
> >>
> >> On Wed, 2018-11-14 at 14:39 +0200, Gidon Gershinsky wrote:
> >>> Hi,
> >>>
> >>> We are working on an encryption mechanism at the Apache Parquet -
> >>> that will enable efficient analytics on encrypted data by frameworks
> >>> such as Apache Spark.
> >>> https://github.com/apache/parquet-format/blob/encryption/Encryption.md
> >>>
> https://www.slideshare.net/databricks/efficient-spark-analytics-on-encrypted-data-with-gidon-gershinsky
> >>>
> >>>
> >>> We came across an AES-related issue in the Java HostSpot engine that
> >>> looks like a substantial problem for us in both Spark and Parquet
> >>> workloads. The bug report had been accepted a while ago:
> >>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8201633
> >>>
> >>> The fix should hopefully be rather straightforward though.
> >>> Could you help us with that? I have a couple of small samples
> >>> reproducing the problem.
> >>>
> >>> (If I'm writing to a wrong mailing list - I apologize, please point
> >>> me in the right direction).
> >>>
> >>> Cheers, Gidon.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Roger.Riggs at oracle.com  Thu Nov 15 16:31:04 2018
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 15 Nov 2018 11:31:04 -0500
Subject: FYI: new javadoc tag to document system properties
In-Reply-To: <9e6bf54a-3193-fcb9-a523-9411ae83e952@oracle.com>
References: <27d8d3ed-143b-dbcb-0ad2-d904f54db1d7@oracle.com>
 <9e6bf54a-3193-fcb9-a523-9411ae83e952@oracle.com>
Message-ID: 

Hi,

If a system property is defined and specified as supported then it needs 
a public declaration and specification as part of the public class or 
package documentation.
Checking for and adding the tag will be a good way to reconfirm property 
definitions are in the right place.

Would it be reasonable to use only core-libs-dev for any remaining 
discussion?
Seeing it on 5 aliases doesn't seem productive.

$.02, Roger


On 11/15/2018 11:17 AM, Xuelei Fan wrote:
> In JCE and JSSE, the public APIs definition (javax.net.ssl) and the 
> internal implementation (sun.security.ssl) are separated.? The system 
> property can be defined in the internal implementation classes.? I 
> think we should add the @systemProperty on the public APIs, right?
>
> The public API class and the implementation class may be not a 
> one-to-one map.? Multiple public APIs may be impacted by the system 
> property.? How to handle such cases?
>
> Thanks,
> Xuelei
>
> On 11/14/2018 2:27 PM, Jonathan Gibbons wrote:
>> This is an FYI to announce some initial, long-overdue support in 
>> javadoc for documenting system properties (JDK-5076751).
>>
>> Currently, system properties are just documented using ad-hoc 
>> narrative text, which is fine if you know where to look for any given 
>> property.
>>
>> JDK 12 introduces a new inline javadoc tag, {@systemProperty 
>> /property-name/} which can be used to "declare" the name of a system 
>> property. You can use this tag as a drop-in replacement for the 
>> plain-text property name; it will have no overt effect on the 
>> narrative text, but it will cause the property name to be put into 
>> the search index and the A-Z index. Thus, property names will become 
>> searchable, to allow users to easily find the definition of any such 
>> system property.
>>
>> Adding support into javadoc is only part of the story. Now that the 
>> support is in javadoc, we want to update the API documentation, so 
>> that the documentation is updated for all Java SE and JDK system 
>> properties.
>>
>> Where should the tag be used?? The tag should be used in the text of 
>> the defining instance of the property.? This is where the 
>> characteristics of the system property are described, which may 
>> include information like: "what is the property for", "how and when 
>> is it set", "can it be modified", and so on. For example, it could be 
>> used in the docs for System.getProperties [1] or Networking 
>> Properties [2] In general, it should -not- be used in situations that 
>> merely refer to the system property by name.? For example, the docs 
>> for Path.toAbsolutePath [3] make a reference to the system property 
>> user.dir, but that is not a definition of the property.
>>
>> Going forward, in future releases, we expect to explore some 
>> enhancements to this feature. Here are some of the ideas that have 
>> been suggested:
>>
>> ??* Create a "summary page" that lists all the system properties. This
>> ??? would be somewhat similar to the current top-level "Constant Values"
>> ??? page.
>> ??* Add information regarding the "scope" of the definition: is it
>> ??? defined by the Java SE specification, or JDK, or JavaFX, etc. This
>> ??? information could be used to organize the content on the summary 
>> page.
>> ??* Update @see and {@link} to be able to refer to system properties.
>> ??* Allow a short description to be included in the {@systemProperty}
>> ??? tag. This text could be included in the search index, the A-Z index,
>> ??? and the summary page.
>>
>> -- Jon
>>
>>
>> [1]: 
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/System.html#getProperties() 
>>
>> [2]: 
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/doc-files/net-properties.html 
>>
>> [3]: 
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Path.html#toAbsolutePath() 
>>
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From smita.kamath at intel.com  Tue Nov 20 17:58:31 2018
From: smita.kamath at intel.com (Kamath, Smita)
Date: Tue, 20 Nov 2018 17:58:31 +0000
Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions
In-Reply-To: 
References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com>
 
Message-ID: <6563F381B547594081EF9DE181D0791288A18C24@FMSMSX119.amr.corp.intel.com>

Hi Bernd,

I agree to both of your comments and will update my code with the changes.

Thanks,
Smita

From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net]
Sent: Monday, November 19, 2018 2:27 PM
To: Kamath, Smita ; 'Vladimir Kozlov' 
Cc: core-libs-dev at openjdk.java.net; security-dev at openjdk.java.net
Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

Hello,

What is the purpose of setting some of them to 0 twice? (It's a new array which should be all-0 anyway.)

+      for (int i = 1; i < 9 ; i++) {
+            subkeyHtbl[2*i] = 0;
+            subkeyHtbl[2*i+1] = 0;
+        }

Also, is the subkeyH no longer be needed (or can be redesigned to use subkeyHtbl[0] and 1?

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: core-libs-dev > im Auftrag von Kamath, Smita >
Gesendet: Montag, November 19, 2018 10:52 PM
An: 'Vladimir Kozlov'
Cc: Anthony Scarpino; core-libs-dev at openjdk.java.net; hotspot compiler
Betreff: RFR(S)JDK-8214074: Ghash optimization using AVX instructions

Hi Vladimir,

I'd like to contribute an optimization for GHASH Algorithm using AVX Instructions. I have tested this optimization on SKX x86_64 platform and it shows ~20-30% performance improvement for larger message sizes (for example 8k).

I, smita.kamath at intel.com> , Shay Gueuron, (shay.gueron at intel.com>) and Regev Shemy (regev.shemy at intel.com>) are contributors to this code.

Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074

Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/

For testing the implementation, I have executed TestAESMain.java. I have executed Jtreg tests and tested this code on 64 bit Windows and Linux platforms.

Please review and let me know if you have any comments.

Thanks and Regards,
Smita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pavel.rappo at oracle.com  Mon Nov 26 23:27:52 2018
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 26 Nov 2018 23:27:52 +0000
Subject: JDK 12 RFR of JDK-8213911: Use example.com in java.net and other
 examples
In-Reply-To: <072b68a2-38ee-890c-c0e3-84afa4b641db@oracle.com>
References: <072b68a2-38ee-890c-c0e3-84afa4b641db@oracle.com>
Message-ID: <5C96DC91-8C21-4754-A68E-6463B9B86BDB@oracle.com>

Looks good to me.

-Pavel



From anthony.scarpino at oracle.com  Tue Nov 27 00:23:47 2018
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 26 Nov 2018 16:23:47 -0800
Subject: Code Review Request, JDK-8214321: Misleading code in SSLCipher
In-Reply-To: <0bcc1900-5520-b998-939a-d89e4c90fe99@oracle.com>
References: <0bcc1900-5520-b998-939a-d89e4c90fe99@oracle.com>
Message-ID: 

On 11/26/18 4:14 PM, Xue-Lei Fan wrote:
> Hi,
> 
> Please review this code cleanup in SSLCipher.java:
>  ?? http://cr.openjdk.java.net/~xuelei/8214321/webrev.00/
> 
> The code should be fine as readCipherGenerators.length and 
> writeCipherGenerators.length are the same value in the implementation. 
> However, it is misleading to use readCipherGenerators when it is 
> intended to use writeCipherGenerators.? It's nice to have a code cleanup 
> for readability.
> 
> Thanks,
> Xuelei

looks fine.. you'll probably want to put noreg-trivial on the bug

Tony



From weijun.wang at oracle.com  Tue Nov 27 01:30:17 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 27 Nov 2018 09:30:17 +0800
Subject: RFR 8214179: Add groupname info into keytool -list and
 -genkeypair output
In-Reply-To: 
References: 
Message-ID: <9A04B026-DBE0-4E53-856F-584EAE5407F1@oracle.com>

Ping

> On Nov 21, 2018, at 9:56 PM, Weijun Wang  wrote:
> 
> Please take a review at
> 
>  https://cr.openjdk.java.net/~weijun/8214179/webrev.00/
> 
> Before this change, `keytool -genkeypair -keyalg EC -groupname brainpoolP256r1` shows
> 
>  Generating -1 bit EC key pair and self-signed certificate...
> 
> With this change, the message becomes
> 
>  Generating brainpoolP256r1 EC key pair and self-signed certificate...
> 
> Also, `keytool -list -v` can show
> 
>  Subject Public Key Algorithm: 256-bit EC(brainpoolP256r1) key
> 
> Thanks
> Max
> 



From weijun.wang at oracle.com  Tue Nov 27 01:29:40 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 27 Nov 2018 09:29:40 +0800
Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123
In-Reply-To: 
References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com>
 
 <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com>
 
 <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com>
 
 <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com>
 <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com>
 
Message-ID: 



> On Nov 26, 2018, at 11:15 AM, Weijun Wang  wrote:
> 
> 
> 
>> On Nov 24, 2018, at 12:45 AM, Se?n Coffey  wrote:
>> 
>> Thanks for your review Max. I've made the suggested edits.
>> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v3/webrev/
> 
> The change looks fine. Thanks.
> 
>> 
>> I've also submitted a CSR for this change just to cover the behavioural aspect of the edit. Will push if/once that's approved by CSR team.
> 
> The CSR focuses on keytool but this is actually a library change. There is no change with "add/remove/modify command line option" at all.
> 
> I would suggest talking about the DNSName class instead of keytool. I understand it's internal but we can describe this change as a non-minimal change on behavior so it's still worth a CSR. Or, you can consult Joe what the best way is. Maybe he can spare you from filing a CSR at all.
> 
> BTW, you did try out keytool after this code change and "-ext dns=1abc.com" is working now, right?

You can add an extra line after line 1437 of test/jdk/sun/security/tools/keytool/KeyToolTest.java.

> 
> Thanks
> Max
> 
>> 
>> Regards,
>> Sean.
>> 
>> On 22/11/18 14:49, Weijun Wang wrote:
>>> * DNSName.java:
>>> 
>>>  91             if ((endIndex - startIndex) < 1)
>>> 
>>> No need for inner parentheses.
>>> 
>>> And, is there really a need to define alphaDigitsAndHyphen? How about just (== '-' || inside alphaDigits)?
>>> 
>>> * DNSNameTest.java:
>>> 
>>> Space cannot appear anywhere, please add a test case like "a c.com".
>>> 
>>> BTW, I assume you want to reuse this test for other sub-tasks of JDK-8054380? I see the @summary is more general.
>>> 
>>> No other comments.
>>> 
>>> Thanks
>>> Max
>>> 
>>>> On Nov 22, 2018, at 12:51 AM, Se?n Coffey  wrote:
>>>> 
>>>> p.s I've updated the testcase to test the IOException message for presence of "DNSName". Webrev updated in place.
>>>> 
>>>> Regards,
>>>> Sean.
>>>> 
>>>> On 21/11/18 15:42, Se?n Coffey wrote:
>>>>> Thanks for the comments Bernd. Comments inline..
>>>>> 
>>>>> On 16/11/18 21:27, Bernd Eckenfels wrote:
>>>>>> Hello Sean,
>>>>>> 
>>>>>> I was only looking at the inspected DNSName class, it still has some variations (but start now with DNSNames which is good already):
>>>>>> 
>>>>>>  76 throw new IOException("DNSName must not be null or empty");
>>>>>>  78 throw new IOException("DNSNames or NameConstraints with blank components are not permitted");
>>>>>>  80 throw new IOException("DNSNames or NameConstraints may not begin or end with a .");
>>>>>>  92 throw new IOException("DNSName SubjectAltNames with empty components are not permitted");
>>>>>> 96 throw new IOException("DNSName components must begin with a letter or digit");
>>>>>> 101 throw new IOException("DNSName components must consist of letters, digits, and hyphens");
>>>>>> 
>>>>>> I did not check if those exceptions are catched and rethrown with something like ?while validating the SubjectAltName Extension  of certificate ...?, in my experience it helps if you do not have to find and review the actual certificates (in this case it might not be a problem if SAN is only in the end entity). You can probably remove ?or NameConstraints? and ?SubjectAltNames? from lines 78-92 (this is good if DNsNa
>>>>> Ok - I've cleaned up the exception messages on line 78, 80, 92.
>>>>> webrev updated in place : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/
>>>>> 
>>>>> 
>>>>>> me applies to SAN or NameConstrained context and the validation logic does not know ? so it?s not only more unified but also less missleading)
>>>>>> 
>>>>>> BTW: probably not inthe scope of this fix but a subtype for validation errors which have getters for context/location and maybe error code and getValue() would allow callers to print nicer validation reports without relying on the message or Stacktraces.
>>>>> That's a nice idea and one that should be followed up in separate enhancement. We could lean on the new `jdk.includeInExceptions` Security property which other component areas have started to use lately.
>>>>> 
>>>>> e.g. https://bugs.openjdk.java.net/browse/JDK-8207768
>>>>> 
>>>>> regards,
>>>>> Sean.
>>>>>> Gruss
>>>>>> Bernd
>>>>>> --
>>>>>> http://bernd.eckenfels.net
>>>>>> Von: Se?n Coffey 
>>>>>> Gesendet: Freitag, November 16, 2018 5:15 PM
>>>>>> An: Bernd Eckenfels; security-dev at openjdk.java.net
>>>>>> Betreff: Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123
>>>>>> Thanks for the comments Bernd. comments inline..
>>>>>> 
>>>>>> On 16/11/18 12:40, Bernd Eckenfels wrote:
>>>>>>> You could also add (a..b, false) and (.a, false), (a., false) to the testcases.
>>>>>> good point. test updated.
>>>>>>> I noticed that there are different types of Exception messages (DNS name, DNSName, DNS Name or name constrained, DNS name and SAN), would be good if all of them have the same keyword?
>>>>>> I cleaned up some other references to DNSName in the sun.security.x509 package. I'm not sure what classes you were referencing the above examples from.
>>>>>> 
>>>>>> new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/
>>>>>> 
>>>>>> regards,
>>>>>> Sean.
>>>>>>> Gruss
>>>>>>> Bernd
>>>>>>> --
>>>>>>> http://bernd.eckenfels.net
>>>>>>> Von: security-dev  im Auftrag von Se?n Coffey 
>>>>>>> Gesendet: Freitag, November 16, 2018 12:25 PM
>>>>>>> An: OpenJDK Dev list
>>>>>>> Betreff: RFR: 8213952: Relax DNSName restriction as per RFC 1123
>>>>>>> Looking to make an adjustment to DNSName constructor to help comply with
>>>>>>> RFC 1123
>>>>>>> 
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213952
>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/
>>>>>>> 
>>>>>>> regards,
>>>>>>> Sean.
>>>>>>> 
>>>> 
>> 
> 



From weijun.wang at oracle.com  Tue Nov 27 01:33:33 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 27 Nov 2018 09:33:33 +0800
Subject: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still
 too slow
In-Reply-To: <26F3E48B-FD8A-46AF-B054-749DD6CBD2EE@oracle.com>
References: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com>
 <26F3E48B-FD8A-46AF-B054-749DD6CBD2EE@oracle.com>
Message-ID: 

Ping again

> On Nov 20, 2018, at 5:33 PM, Weijun Wang  wrote:
> 
> Webrev updated at
> 
>   https://cr.openjdk.java.net/~weijun/8210476/webrev.01/
> 
> The only change is that there is a single Cleaner now for the whole PRNG class. Otherwise, each will maintain its own thread.
> 
> Thanks
> Max
> 
>> On Nov 11, 2018, at 11:30 PM, Weijun Wang  wrote:
>> 
>> Please take a review at
>> 
>>  https://cr.openjdk.java.net/~weijun/8210476/webrev.00/
>> 
>> Before this fix, every PRNG::nextBytes calls all of CryptAcquireContext, CryptGenRandom, and CryptReleaseContext. Now, CryptAcquireContext is called once in PRNG::new, and CryptReleaseContext is called by a Cleaner, and nextBytes only calls CryptGenRandom.
>> 
>> I haven't read about thread-safety in any MS document, the current Windows-PRNG service is marked ThreadSafe=true (in SunMSCAPI.java). If we cannot be really sure, we can change it to false.
>> 
>> I've downloaded nearly 1000 Mach5 runs of this test, the enhancement is so good that I adjusted the test to be stricter.
>> 
>> 	Before	After
>> 	------	-----
>> Count	897	74
>> Min	0.38	0.008
>> Ave	0.97	0.011
>> Max	5.81	0.021
>> 
>> Please advise me if the following usage of Cleaner is correct because I really haven't observed the releaseContext method being called.
>> 
>> +        Cleaner.create().register(this,
>> +                () -> releaseContext(ctxt));
>> 
>> Thanks
>> Max
>> 
> 



From weijun.wang at oracle.com  Tue Nov 27 01:32:44 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 27 Nov 2018 09:32:44 +0800
Subject: RFR 8213400: Support choosing curve name in keytool keypair
 generation
In-Reply-To: 
References: <37BC39C9-A05C-4E60-913B-B38A130F4BF4@oracle.com>
 <23004dd9-f070-1402-2845-d3af3440ea23@oracle.com>
 
 <187d5f28-5074-fb89-3ec0-30299c4823f4@oracle.com>
 
 <7361f3f0-10de-78c1-a41b-07286ac355e9@oracle.com>
 <69D287E4-B95F-445B-8F0B-4E6FAD5F1BE6@oracle.com>
 
 
 
 <34816858-E398-428D-B739-EC3BF7DE2D54@oracle.com>
 
 <003184DF-2626-47EF-8D28-A8A625115DC7@oracle.com>
 <0af3ad26-0223-6be8-16f3-afef93be3919@oracle.com>
 
 <4d745521-bbf6-e3f6-82fb-4f45e6301e68@oracle.com>
 <87DE3460-EB16-4F53-8C03-E104BC495F59@oracle.com>
 <564a9a5a-352e-d21f-ec84-feb6562adcf1@oracle.com>
 
 <4bc04440-2b58-a993-db3e-1c488b001b67@oracle.com>
 
Message-ID: 

Ping

> On Nov 15, 2018, at 9:24 AM, Weijun Wang  wrote:
> 
> 
> 
>> On Nov 15, 2018, at 3:53 AM, Adam Petcher  wrote:
>> 
>> This looks good to me, though I made a couple of trivial editorial changes. It's fine as is, but you may want to consider using secp384r1 instead of brainpool256r1 in your example. I worry that people will experiment with the new feature using your example, and then we'll get bug tickets because the resulting keystore doesn't work with TLS.
> 
> This is exactly the advice I need from an expert.
> 
> However, secp384r1 is already the default choice for `-keysize 384`. Do you have another recommendation that has to be set with `-groupname`?
> 
> Thanks
> Max
> 
>> 
>> On 11/13/2018 7:56 PM, Weijun Wang wrote:
>>> Thanks. Please also take a look at the release note at https://bugs.openjdk.java.net/browse/JDK-8213821.
>>> 
>>> --Max
>>> 
>>>> On Nov 13, 2018, at 11:02 PM, Adam Petcher  wrote:
>>>> 
>>>> This change looks good to me. Thanks.
>>>> 
> 



From valerie.peng at oracle.com  Tue Nov 27 01:55:01 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 26 Nov 2018 17:55:01 -0800
Subject: RFR 8213009: Refactoring existing SunMSCAPI classes
In-Reply-To: 
References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com>
 <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com>
 
 
 <1ede21e9-b40d-2044-f7ec-5a6230913231@oracle.com>
 
Message-ID: <75aae853-4cc9-c241-e302-42ff8bd0fced@oracle.com>

Hi Max,

Please find comments in line.

On 11/22/2018 6:04 AM, Weijun Wang wrote:
>> On Nov 22, 2018, at 9:14 AM, Valerie Peng  wrote:
>>
>> Hi Max,
>>
>> Here are some comments:
>>
>> 
>> - line 39, add PSS here as well.
>> - line 97, CSignature ctr, better to initialize all fields
> Which particular ones are you thinking about? privateKey and publicKey will be initialized later and messageDigest/messageDigestAlgorithm/needsReset will be useless when digestName == null.
I was referring messageDigest/messageDigestAlgorithm/needsReset. My 
general preference is to set them to null/false even when not used, may 
help catch future coding problems.
>> - line 109, has key algorithm been checked by JCA already? If not, it should be checked here. Same goes for line 414, and 560
> Can I do this later? This sub-task is meant to be a cleanup.

My point for checking the key algorithm is to ensure that the specified 
key object is RSA type. After this cleanup and refactoring, the 
specified key should be checked to be of RSA type, i.e. line 111, 130. 
Otherwise, the casting to various RSA public/private key interfaces, 
e.g. java.security.interfaces.RSAPublicKey, may fail.

Updates look fine.

Regards,

Valerie

> But I think I need to move more RSA related methods into the RSA subclass.
>
>> - with the class renaming, I think it's clearer to include "RSA" as part of the subclass names, e.g. "MD2withRSA" instead of just "MD2"
> OK.
>
>> - line 681: can be static, right? pkg-private?
> Yes. Looks like it can be private.
>
>> 
>> - line 120: maybe a ProviderException instead of IllegalArgumentException as the 'alg' is not from user but rather inside the provider.
> Either is OK for me. Since it's only called inside the provider, it can even be an AssertionError.
>
>> - line 127, add @Override
> OK.
>
>> - line 140, must getPublicKeyBob be public? Maybe pkg private?
> Correct.
>
>> 
>> - line 119: why not just use RSAPrivateCrtKey instead of Key? The caller has already did an instanceof check before this method.
> Correct. I think I should rename both setPrivateKey and generatePrivateKeyBlob to setRSAPrivateKey and generateRSAPrivateKeyBlob. If one day I starts supporting EC keys the methods will be quite different.
>
>> 
>> - would be nice to have a String constant for "RSA".
> Sure.
>
> Thanks
> Max
>
>> Rest looks fine.
>> Thanks,
>> Valerie
>>
>>
>> On 11/15/2018 7:40 AM, Weijun Wang wrote:
>>> Oops, my copy/paste sequence goes wrong.
>>>
>>>> On Nov 15, 2018, at 11:38 PM, Weijun Wang  wrote:
>>>>
>>>> Webrev updated at
>>>>
>>>     https://cr.openjdk.java.net/~weijun/8213009/webrev.01/
>>>
>>>> More refactorings:
>>>>
>>>> - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey.
>>>>
>>>> - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA.
>>>>
>>>> - CPublicKey and CPrivateKey now have a static of() method that can return a child instance.
>>>>
>>>> - CCipher renamed to CRSACipher. I realized there won't be CECCipher.
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>
>>>>> On Nov 7, 2018, at 12:13 AM, Weijun Wang  wrote:
>>>>>
>>>>> Webrev updated at
>>>>>
>>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.00/
>>>>>
>>>>> The subtask id is now used.
>>>>>
>>>>> The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back.
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>>> On Oct 25, 2018, at 4:38 PM, Weijun Wang  wrote:
>>>>>>
>>>>>> Please review the change at
>>>>>>
>>>>>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/
>>>>>>
>>>>>> (I will use a sub-task id for this change but currently JBS is down).
>>>>>>
>>>>>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart.
>>>>>>
>>>>>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include:
>>>>>>
>>>>>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1].
>>>>>>
>>>>>> - Child class named "RSA" of CKeyPairGenerator.
>>>>>>
>>>>>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods.
>>>>>>
>>>>>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now.
>>>>>>
>>>>>> Noreg-cleanup.
>>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>>
>>>>>> [1] https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Tue Nov 27 02:27:24 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 27 Nov 2018 10:27:24 +0800
Subject: RFR CSR for 8200400 Restrict Sasl mechanisms
Message-ID: <344B0080-FA26-4D9C-969E-C7C85E5AB0FC@oracle.com>

Please review the CSR at

   https://bugs.openjdk.java.net/browse/JDK-8214331

One concern:

When a disabled mechanism is requested, Sasl.createClient and Sasl.createServer might silently return null and if a user has already taken for granted that a client should be returned an NPE will thrown somewhere. This is not quite friendly.

Thanks
Max

From matthias.baesken at sap.com  Tue Nov 27 12:36:46 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 27 Nov 2018 12:36:46 +0000
Subject: jdk11u and jdk/jdk : jtreg test error in
 security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
In-Reply-To: <5cba20d6-6790-fe7e-7bf3-20d320fb24a8@oracle.com>
References: 
 <29e2f8e4-ce23-d5a1-211b-ef578bc05188@oracle.com>
 
 <5cba20d6-6790-fe7e-7bf3-20d320fb24a8@oracle.com>
Message-ID: 

Hi Sean ,  maybe I was not clear enough   -   when I  said  " but we only see the issue  since last week"    I meant we  started to see the issue  in our local  jtreg  test runs
 for jdk11u  and for jdk/jdk  .

Do you think  security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java   should be set on the exclude list  for now  (until  JDK-8202651 is resolved) ?


Best regards, Matthias

> -----Original Message-----
> From: Sean Mullan 
> Sent: Montag, 26. November 2018 15:57
> To: Baesken, Matthias ; security-
> dev at openjdk.java.net
> Cc: Lindenmaier, Goetz 
> Subject: Re: jdk11u and jdk/jdk : jtreg test error in
> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja
> va
> 
> On 11/26/18 8:44 AM, Baesken, Matthias wrote:
> > Hi Sean thanks for the info .
> >
> > Strange that  the bug   https://bugs.openjdk.java.net/browse/JDK-8202651
> is from  May  ,  but we only see the issue  since last week ?!
> 
> It was marked Confidential for some reason, possibly by accident because
> these tests used to be closed before we open sourced them in JDK 10. I
> opened up the bug today.
> 
> --Sean

From sean.mullan at oracle.com  Tue Nov 27 12:47:35 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 27 Nov 2018 07:47:35 -0500
Subject: jdk11u and jdk/jdk : jtreg test error in
 security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
In-Reply-To: 
References: 
 <29e2f8e4-ce23-d5a1-211b-ef578bc05188@oracle.com>
 
 <5cba20d6-6790-fe7e-7bf3-20d320fb24a8@oracle.com>
 
Message-ID: 

On 11/27/18 7:36 AM, Baesken, Matthias wrote:
> Hi Sean ,  maybe I was not clear enough   -   when I  said  " but we only see the issue  since last week"    I meant we  started to see the issue  in our local  jtreg  test runs
>   for jdk11u  and for jdk/jdk  .

Oh, I see. I have not looked at this issue myself. Maybe Siba (the RE) 
can offer some suggestions.

> 
> Do you think  security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java   should be set on the exclude list  for now  (until  JDK-8202651 is resolved) ?

Sure, if Siba does not have any plans to fix this soon.

--Sean

> 
> 
> Best regards, Matthias
> 
>> -----Original Message-----
>> From: Sean Mullan 
>> Sent: Montag, 26. November 2018 15:57
>> To: Baesken, Matthias ; security-
>> dev at openjdk.java.net
>> Cc: Lindenmaier, Goetz 
>> Subject: Re: jdk11u and jdk/jdk : jtreg test error in
>> security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.ja
>> va
>>
>> On 11/26/18 8:44 AM, Baesken, Matthias wrote:
>>> Hi Sean thanks for the info .
>>>
>>> Strange that  the bug   https://bugs.openjdk.java.net/browse/JDK-8202651
>> is from  May  ,  but we only see the issue  since last week ?!
>>
>> It was marked Confidential for some reason, possibly by accident because
>> these tests used to be closed before we open sourced them in JDK 10. I
>> opened up the bug today.
>>
>> --Sean


From sean.mullan at oracle.com  Tue Nov 27 13:03:52 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 27 Nov 2018 08:03:52 -0500
Subject: JDK 12 RFR of JDK-8213911: Use example.com in java.net and other
 examples
In-Reply-To: <072b68a2-38ee-890c-c0e3-84afa4b641db@oracle.com>
References: <072b68a2-38ee-890c-c0e3-84afa4b641db@oracle.com>
Message-ID: <5f5af4d5-6c2b-0088-2540-589e86e70aa4@oracle.com>

Looks fine to me.

--Sean

On 11/26/18 4:38 PM, joe darcy wrote:
> Hello,
> 
> Please review a simple doc-only change to address:
> 
>  ??? JDK-8213911: Use example.com in java.net and other examples
>  ??? http://cr.openjdk.java.net/~darcy/8213911.0/
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> 
> --- old/src/java.base/share/classes/java/net/HostPortrange.java 
> 2018-11-26 13:32:47.078000000 -0800
> +++ new/src/java.base/share/classes/java/net/HostPortrange.java 
> 2018-11-26 13:32:46.902000000 -0800
> @@ -60,7 +60,7 @@
>  ???? HostPortrange(String scheme, String str) {
>  ???????? // Parse the host name.? A name has up to three components, the
>  ???????? // hostname, a port number, or two numbers representing a port
> -??????? // range.?? "www.sun.com:8080-9090" is a valid host name.
> +??????? // range.?? "www.example.com:8080-9090" is a valid host name.
> 
>  ???????? // With IPv6 an address can be 2010:836B:4179::836B:4179
>  ???????? // An IPv6 address needs to be enclose in []
> --- old/src/java.base/share/classes/java/net/InetAddress.java 2018-11-26 
> 13:32:47.474000000 -0800
> +++ new/src/java.base/share/classes/java/net/InetAddress.java 2018-11-26 
> 13:32:47.298000000 -0800
> @@ -1168,7 +1168,7 @@
>  ????? * No name service is checked for the validity of the address.
>  ????? *
>  ????? * 
     The host name can either be a machine name, such as
> -???? * "{@code java.sun.com}", or a textual representation of its IP
> +???? * "{@code www.example.com}", or a textual representation of its IP
>  ????? * address.
>  ????? * 
     No validity checking is done on the host name either.
>  ????? *
> @@ -1213,7 +1213,7 @@
>  ????? * Determines the IP address of a host, given the host's name.
>  ????? *
>  ????? * 
     The host name can either be a machine name, such as
> -???? * "{@code java.sun.com}", or a textual representation of its
> +???? * "{@code www.example.com}", or a textual representation of its
>  ????? * IP address. If a literal IP address is supplied, only the
>  ????? * validity of the address format is checked.
>  ????? *
> @@ -1259,7 +1259,7 @@
>  ????? * based on the configured name service on the system.
>  ????? *
>  ????? * 
     The host name can either be a machine name, such as
> -???? * "{@code java.sun.com}", or a textual representation of its IP
> +???? * "{@code www.example.com}", or a textual representation of its IP
>  ????? * address. If a literal IP address is supplied, only the
>  ????? * validity of the address format is checked.
>  ????? *
> --- old/src/java.base/share/classes/java/net/SocketPermission.java 
> 2018-11-26 13:32:47.850000000 -0800
> +++ new/src/java.base/share/classes/java/net/SocketPermission.java 
> 2018-11-26 13:32:47.678000000 -0800
> @@ -63,7 +63,7 @@
>  ? * or as "localhost" (for the local machine).
>  ? * The wildcard "*" may be included once in a DNS name host
>  ? * specification. If it is included, it must be in the leftmost
> - * position, as in "*.sun.com".
> + * position, as in "*.example.com".
>  ? * 
    
>  ? * The format of the IPv6reference should follow that specified in   ? * href="http://www.ietf.org/rfc/rfc2732.txt">RFC 2732: Format
> @@ -115,11 +115,11 @@
>  ? * note that if the following permission:
>  ? *
>  ? * 
    > - *?? p1 = new SocketPermission("puffin.eng.sun.com:7777", 
> "connect,accept");
> + *?? p1 = new SocketPermission("foo.example.com:7777", "connect,accept");
>  ? * 
    
>  ? *
>  ? * is granted to some code, it allows that code to connect to port 
> 7777 on
> - * {@code puffin.eng.sun.com}, and to accept connections on that port.
> + * {@code foo.example.com}, and to accept connections on that port.
>  ? *
>  ? * 
    Similarly, if the following permission:
>  ? *
> @@ -211,7 +211,7 @@
>  ???? // all the IP addresses of the host
>  ???? private transient InetAddress[] addresses;
> 
> -??? // true if the hostname is a wildcard (e.g. "*.sun.com")
> +??? // true if the hostname is a wildcard (e.g. "*.example.com")
>  ???? private transient boolean wildcard;
> 
>  ???? // true if we were initialized with a single numeric IP address
> @@ -274,9 +274,9 @@
>  ????? * 
    
>  ????? * Examples of SocketPermission instantiation are the following:
>  ????? * 
    > -???? *??? nr = new SocketPermission("www.catalog.com", "connect");
> -???? *??? nr = new SocketPermission("www.sun.com:80", "connect");
> -???? *??? nr = new SocketPermission("*.sun.com", "connect");
> +???? *??? nr = new SocketPermission("www.example.com", "connect");
> +???? *??? nr = new SocketPermission("www.example.com:80", "connect");
> +???? *??? nr = new SocketPermission("*.example.com", "connect");
>  ????? *??? nr = new SocketPermission("*.edu", "resolve");
>  ????? *??? nr = new SocketPermission("204.160.241.0", "connect");
>  ????? *??? nr = new SocketPermission("localhost:1024-65535", "listen");
> @@ -400,7 +400,7 @@
> 
>  ???????? // Parse the host name.? A name has up to three components, the
>  ???????? // hostname, a port number, or two numbers representing a port
> -??????? // range.?? "www.sun.com:8080-9090" is a valid host name.
> +??????? // range.?? "www.example.com:8080-9090" is a valid host name.
> 
>  ???????? // With IPv6 an address can be 2010:836B:4179::836B:4179
>  ???????? // An IPv6 address needs to be enclose in []
> @@ -835,10 +835,10 @@
>  ????? * 
      
>  ????? * 
    •  If this object was initialized with a single IP address 
> and one of p's
>  ????? * IP addresses is equal to this object's IP address.
> -???? * 
    • If this object is a wildcard domain (such as *.sun.com), and
> +???? * 
    • If this object is a wildcard domain (such as *.example.com), 
> and
>  ????? * p's canonical name (the name without any preceding *)
> -???? * ends with this object's canonical host name. For example, *.sun.com
> -???? * implies *.eng.sun.com.
> +???? * ends with this object's canonical host name. For example, 
> *.example.com
> +???? * implies *.foo.example.com.
>  ????? * 
    • If this object was not initialized with a single IP 
> address, and one of this
>  ????? * object's IP addresses equals one of p's IP addresses.
>  ????? * 
    • If this canonical name equals p's canonical name.
> @@ -878,7 +878,7 @@
>  ????? * 
    •  Checks that "p"'s port range is included in this port range
>  ????? * 
    •  If this object was initialized with an IP address, checks 
> that
>  ????? *????? one of "p"'s IP addresses is equal to this object's IP 
> address.
> -???? * 
    •  If either object is a wildcard domain (i.e., "*.sun.com"),
> +???? * 
    •  If either object is a wildcard domain (i.e., "*.example.com"),
>  ????? *????? attempt to match based on the wildcard.
>  ????? * 
    •  If this object was not initialized with an IP address, 
> attempt
>  ????? *????? to find a match based on the IP addresses in both objects.
> @@ -944,8 +944,8 @@
>  ???????????? // check and see if we have any wildcards...
>  ???????????? if (this.wildcard || that.wildcard) {
>  ???????????????? // if they are both wildcards, return true iff
> -??????????????? // that's cname ends with this cname (i.e., *.sun.com
> -??????????????? // implies *.eng.sun.com)
> +??????????????? // that's cname ends with this cname (i.e., *.example.com
> +??????????????? // implies *.foo.example.com)
>  ???????????????? if (this.wildcard && that.wildcard)
>  ???????????????????? return (that.cname.endsWith(this.cname));
> 
> @@ -1057,7 +1057,7 @@
>  ???????? // "1.2.3.4" equal to "1.2.3.4.", or
>  ???????? //? "*.edu" equal to "*.edu", but it
>  ???????? //? does not catch "crypto" equal to
> -??????? // "crypto.eng.sun.com".
> +??????? // "crypto.foo.example.com".
> 
>  ???????? if (this.getName().equalsIgnoreCase(that.getName())) {
>  ???????????? return true;
> @@ -1313,7 +1313,7 @@
>  ???????? SocketPermissionCollection nps = new 
> SocketPermissionCollection();
>  ???????? nps.add(this_);
>  ???????? nps.add(new 
> SocketPermission("www-leland.stanford.edu","connect"));
> -??????? nps.add(new SocketPermission("www-sun.com","connect"));
> +??????? nps.add(new SocketPermission("www-example.com","connect"));
>  ???????? System.out.println("nps.implies(that) = " + nps.implies(that_));
>  ???????? System.out.println("-----\n");
>  ???? }
> --- old/src/java.base/share/classes/java/net/URI.java 2018-11-26 
> 13:32:48.246000000 -0800
> +++ new/src/java.base/share/classes/java/net/URI.java 2018-11-26 
> 13:32:48.070000000 -0800
> @@ -83,7 +83,7 @@
>  ? * subject to further parsing.? Some examples of opaque URIs are:
>  ? *
>  ? * 
        
> - * 
      • {@code mailto:java-net at java.sun.com}
        • 
> + * 
      • {@code mailto:java-net at www.example.com}
        • 
>  ? * 
      • {@code news:comp.lang.java}
        • 
>  ? * 
      • {@code urn:isbn:096139210x}
        • 
>  ? * 
      
> @@ -399,7 +399,7 @@
>  ? * For any URI u that does not contain redundant syntax such as 
> two
>  ? * slashes before an empty authority (as in {@code 
> file:///tmp/} ) or a
>  ? * colon following a host name but no port (as in
> - * {@code http://java.sun.com:} ), and that does not encode 
> characters
> + * {@code http://www.example.com:} ), and that does not encode 
> characters
>  ? * except those that must be quoted, the following identities also hold:
>  ? * 
      >  ? *???? new URI(u.getScheme(),
> --- old/src/java.base/share/classes/java/net/URL.java 2018-11-26 
> 13:32:48.658000000 -0800
> +++ new/src/java.base/share/classes/java/net/URL.java 2018-11-26 
> 13:32:48.490000000 -0800
> @@ -95,7 +95,7 @@
>  ? * as a "ref" or a "reference". The fragment is indicated by the sharp
>  ? * sign character "#" followed by more characters. For example,
>  ? * 
      > - *???? http://java.sun.com/index.html#chapter1
> + *???? http://www.example.com/index.html#chapter1
>  ? * 
      
>  ? * 
      
>  ? * This fragment is not technically part of the URL. Rather, it
> @@ -109,7 +109,7 @@
>  ? * relative to another URL. Relative URLs are frequently used within
>  ? * HTML pages. For example, if the contents of the URL:
>  ? * 
      > - *???? http://java.sun.com/index.html
> + *???? http://www.example.com/index.html
>  ? * 
      
>  ? * contained within it the relative URL:
>  ? * 
      > @@ -117,7 +117,7 @@
>  ? * 
      
>  ? * it would be a shorthand for:
>  ? * 
      > - *???? http://java.sun.com/FAQ.html
> + *???? http://www.example.com/FAQ.html
>  ? * 
      
>  ? * 
      
>  ? * The relative URL need not specify all the components of a URL. If
> --- old/src/java.base/share/classes/java/net/URLPermission.java 
> 2018-11-26 13:32:49.050000000 -0800
> +++ new/src/java.base/share/classes/java/net/URLPermission.java 
> 2018-11-26 13:32:48.874000000 -0800
> @@ -57,7 +57,7 @@
>  ? * RFC 2732. Literal IPv6 addresses must however, be enclosed in 
> '[]' characters.
>  ? * The dnsname specification can be preceded by "*." which means
>  ? * the name will match any hostname whose right-most domain labels are 
> the same as
> - * this name. For example, "*.oracle.com" matches "foo.bar.oracle.com"
> + * this name. For example, "*.example.com" matches "foo.bar.example.com"
>  ? * 
      
>  ? * portrange is used to specify a port number, or a bounded or 
> unbounded range of ports
>  ? * that this permission applies to. If portrange is absent or invalid, 
> then a default
> @@ -78,18 +78,18 @@
>  ? * Example url scope="col">Description
>  ? * 
>  ? * 
> - *  style="white-space:nowrap;">http://www.oracle.com/a/b/c.html
> + *  style="white-space:nowrap;">http://www.example.com/a/b/c.html
>  ? *?? A url which identifies a specific (single) resource
>  ? * 
> - * http://www.oracle.com/a/b/*
> + * http://www.example.com/a/b/*
>  ? *?? The '*' character refers to all resources in the same 
> "directory" - in
>  ? *?????? other words all resources with the same number of path 
> components, and
>  ? *?????? which only differ in the final path component, represented by 
> the '*'.
>  ? *?? 
>  ? * 
> - * http://www.oracle.com/a/b/-
> + * http://www.example.com/a/b/-
>  ? *?? The '-' character refers to all resources recursively below the
> - *?????? preceding path (e.g. http://www.oracle.com/a/b/c/d/e.html 
> matches this
> + *?????? preceding path (e.g. http://www.example.com/a/b/c/d/e.html 
> matches this
>  ? *?????? example).
>  ? *?? 
>  ? * 
> @@ -267,9 +267,9 @@
>  ????? * 
    • if this's url scheme is not equal to p's url scheme return 
> false
      • 
>  ????? * 
    • if the scheme specific part of this's url is '*' return 
> true
      • 
>  ????? * 
    • if the set of hosts defined by p's url hostrange is not a 
> subset of
> -???? *???? this's url hostrange then return false. For example, 
> "*.foo.oracle.com"
> -???? *???? is a subset of "*.oracle.com". "foo.bar.oracle.com" is not
> -???? *???? a subset of "*.foo.oracle.com"
      • 
> +???? *???? this's url hostrange then return false. For example, 
> "*.foo.example.com"
> +???? *???? is a subset of "*.example.com". "foo.bar.example.com" is not
> +???? *???? a subset of "*.foo.example.com"
      • 
>  ????? * 
    • if the portrange defined by p's url is not a subset of the
>  ????? *???? portrange defined by this's url then return false.
>  ????? * 
    • if the path or paths specified by p's url are contained in the
> --- old/src/java.base/share/classes/java/net/package-info.java 
> 2018-11-26 13:32:49.438000000 -0800
> +++ new/src/java.base/share/classes/java/net/package-info.java 
> 2018-11-26 13:32:49.262000000 -0800
> @@ -131,7 +131,7 @@
>  ? *??? InputStream.
>  ? * 
      Here is an example:
      
>  ? * 
      > - * URI uri = new URI("http://java.sun.com/");
> + * URI uri = new URI("http://www.example.com/");
>  ? * URL url = uri.toURL();
>  ? * InputStream in = url.openStream();
>  ? * 
      
> --- old/src/java.base/share/classes/java/nio/file/Files.java 2018-11-26 
> 13:32:49.798000000 -0800
> +++ new/src/java.base/share/classes/java/nio/file/Files.java 2018-11-26 
> 13:32:49.630000000 -0800
> @@ -3067,7 +3067,7 @@
>  ????? * it to a file:
>  ????? * 
      >  ????? *???? Path path = ...
> -???? *???? URI u = URI.create("http://java.sun.com/");
> +???? *???? URI u = URI.create("http://www.example.com/");
>  ????? *???? try (InputStream in = u.toURL().openStream()) {
>  ????? *???????? Files.copy(in, path);
>  ????? *???? }
> --- old/src/java.base/share/classes/java/security/CodeSource.java 
> 2018-11-26 13:32:50.206000000 -0800
> +++ new/src/java.base/share/classes/java/security/CodeSource.java 
> 2018-11-26 13:32:50.042000000 -0800
> @@ -309,13 +309,13 @@
>  ????? * 
      
>  ????? * For example, the codesource objects with the following locations
>  ????? * and null certificates all imply
> -???? * the codesource with the location 
> "http://java.sun.com/classes/foo.jar"
> +???? * the codesource with the location 
> "http://www.example.com/classes/foo.jar"
>  ????? * and null certificates:
>  ????? * 
      >  ????? *???? http:
> -???? *???? http://*.sun.com/classes/*
> -???? *???? http://java.sun.com/classes/-
> -???? *???? http://java.sun.com/classes/foo.jar
> +???? *???? http://*.example.com/classes/*
> +???? *???? http://www.example.com/classes/-
> +???? *???? http://www.example.com/classes/foo.jar
>  ????? * 
      
>  ????? *
>  ????? * Note that if this CodeSource has a null location and a null
> 

From chris.hegarty at oracle.com  Tue Nov 27 13:11:35 2018
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 27 Nov 2018 13:11:35 +0000
Subject: JDK 12 RFR of JDK-8213911: Use example.com in java.net and other
 examples
In-Reply-To: <072b68a2-38ee-890c-c0e3-84afa4b641db@oracle.com>
References: <072b68a2-38ee-890c-c0e3-84afa4b641db@oracle.com>
Message-ID: <3c5f8177-7c57-6688-9662-2e9210bf4153@oracle.com>

Looks ok to me.

-Chris.

On 26/11/2018 21:38, joe darcy wrote:
> Hello,
> 
> Please review a simple doc-only change to address:
> 
>  ??? JDK-8213911: Use example.com in java.net and other examples
>  ??? http://cr.openjdk.java.net/~darcy/8213911.0/
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> 
> --- old/src/java.base/share/classes/java/net/HostPortrange.java 
> 2018-11-26 13:32:47.078000000 -0800
> +++ new/src/java.base/share/classes/java/net/HostPortrange.java 
> 2018-11-26 13:32:46.902000000 -0800
> @@ -60,7 +60,7 @@
>  ???? HostPortrange(String scheme, String str) {
>  ???????? // Parse the host name.? A name has up to three components, the
>  ???????? // hostname, a port number, or two numbers representing a port
> -??????? // range.?? "www.sun.com:8080-9090" is a valid host name.
> +??????? // range.?? "www.example.com:8080-9090" is a valid host name.
> 
>  ???????? // With IPv6 an address can be 2010:836B:4179::836B:4179
>  ???????? // An IPv6 address needs to be enclose in []
> --- old/src/java.base/share/classes/java/net/InetAddress.java 2018-11-26 
> 13:32:47.474000000 -0800
> +++ new/src/java.base/share/classes/java/net/InetAddress.java 2018-11-26 
> 13:32:47.298000000 -0800
> @@ -1168,7 +1168,7 @@
>  ????? * No name service is checked for the validity of the address.
>  ????? *
>  ????? * 
       The host name can either be a machine name, such as
> -???? * "{@code java.sun.com}", or a textual representation of its IP
> +???? * "{@code www.example.com}", or a textual representation of its IP
>  ????? * address.
>  ????? * 
       No validity checking is done on the host name either.
>  ????? *
> @@ -1213,7 +1213,7 @@
>  ????? * Determines the IP address of a host, given the host's name.
>  ????? *
>  ????? * 
       The host name can either be a machine name, such as
> -???? * "{@code java.sun.com}", or a textual representation of its
> +???? * "{@code www.example.com}", or a textual representation of its
>  ????? * IP address. If a literal IP address is supplied, only the
>  ????? * validity of the address format is checked.
>  ????? *
> @@ -1259,7 +1259,7 @@
>  ????? * based on the configured name service on the system.
>  ????? *
>  ????? * 
       The host name can either be a machine name, such as
> -???? * "{@code java.sun.com}", or a textual representation of its IP
> +???? * "{@code www.example.com}", or a textual representation of its IP
>  ????? * address. If a literal IP address is supplied, only the
>  ????? * validity of the address format is checked.
>  ????? *
> --- old/src/java.base/share/classes/java/net/SocketPermission.java 
> 2018-11-26 13:32:47.850000000 -0800
> +++ new/src/java.base/share/classes/java/net/SocketPermission.java 
> 2018-11-26 13:32:47.678000000 -0800
> @@ -63,7 +63,7 @@
>  ? * or as "localhost" (for the local machine).
>  ? * The wildcard "*" may be included once in a DNS name host
>  ? * specification. If it is included, it must be in the leftmost
> - * position, as in "*.sun.com".
> + * position, as in "*.example.com".
>  ? * 
      
>  ? * The format of the IPv6reference should follow that specified in   ? * href="http://www.ietf.org/rfc/rfc2732.txt">RFC 2732: Format
> @@ -115,11 +115,11 @@
>  ? * note that if the following permission:
>  ? *
>  ? * 
      > - *?? p1 = new SocketPermission("puffin.eng.sun.com:7777", 
> "connect,accept");
> + *?? p1 = new SocketPermission("foo.example.com:7777", "connect,accept");
>  ? * 
      
>  ? *
>  ? * is granted to some code, it allows that code to connect to port 
> 7777 on
> - * {@code puffin.eng.sun.com}, and to accept connections on that port.
> + * {@code foo.example.com}, and to accept connections on that port.
>  ? *
>  ? * 
      Similarly, if the following permission:
>  ? *
> @@ -211,7 +211,7 @@
>  ???? // all the IP addresses of the host
>  ???? private transient InetAddress[] addresses;
> 
> -??? // true if the hostname is a wildcard (e.g. "*.sun.com")
> +??? // true if the hostname is a wildcard (e.g. "*.example.com")
>  ???? private transient boolean wildcard;
> 
>  ???? // true if we were initialized with a single numeric IP address
> @@ -274,9 +274,9 @@
>  ????? * 
      
>  ????? * Examples of SocketPermission instantiation are the following:
>  ????? * 
      > -???? *??? nr = new SocketPermission("www.catalog.com", "connect");
> -???? *??? nr = new SocketPermission("www.sun.com:80", "connect");
> -???? *??? nr = new SocketPermission("*.sun.com", "connect");
> +???? *??? nr = new SocketPermission("www.example.com", "connect");
> +???? *??? nr = new SocketPermission("www.example.com:80", "connect");
> +???? *??? nr = new SocketPermission("*.example.com", "connect");
>  ????? *??? nr = new SocketPermission("*.edu", "resolve");
>  ????? *??? nr = new SocketPermission("204.160.241.0", "connect");
>  ????? *??? nr = new SocketPermission("localhost:1024-65535", "listen");
> @@ -400,7 +400,7 @@
> 
>  ???????? // Parse the host name.? A name has up to three components, the
>  ???????? // hostname, a port number, or two numbers representing a port
> -??????? // range.?? "www.sun.com:8080-9090" is a valid host name.
> +??????? // range.?? "www.example.com:8080-9090" is a valid host name.
> 
>  ???????? // With IPv6 an address can be 2010:836B:4179::836B:4179
>  ???????? // An IPv6 address needs to be enclose in []
> @@ -835,10 +835,10 @@
>  ????? * 
        
>  ????? * 
      •  If this object was initialized with a single IP address 
> and one of p's
>  ????? * IP addresses is equal to this object's IP address.
> -???? * 
      • If this object is a wildcard domain (such as *.sun.com), and
> +???? * 
      • If this object is a wildcard domain (such as *.example.com), 
> and
>  ????? * p's canonical name (the name without any preceding *)
> -???? * ends with this object's canonical host name. For example, *.sun.com
> -???? * implies *.eng.sun.com.
> +???? * ends with this object's canonical host name. For example, 
> *.example.com
> +???? * implies *.foo.example.com.
>  ????? * 
      • If this object was not initialized with a single IP 
> address, and one of this
>  ????? * object's IP addresses equals one of p's IP addresses.
>  ????? * 
      • If this canonical name equals p's canonical name.
> @@ -878,7 +878,7 @@
>  ????? * 
      •  Checks that "p"'s port range is included in this port range
>  ????? * 
      •  If this object was initialized with an IP address, checks 
> that
>  ????? *????? one of "p"'s IP addresses is equal to this object's IP 
> address.
> -???? * 
      •  If either object is a wildcard domain (i.e., "*.sun.com"),
> +???? * 
      •  If either object is a wildcard domain (i.e., "*.example.com"),
>  ????? *????? attempt to match based on the wildcard.
>  ????? * 
      •  If this object was not initialized with an IP address, 
> attempt
>  ????? *????? to find a match based on the IP addresses in both objects.
> @@ -944,8 +944,8 @@
>  ???????????? // check and see if we have any wildcards...
>  ???????????? if (this.wildcard || that.wildcard) {
>  ???????????????? // if they are both wildcards, return true iff
> -??????????????? // that's cname ends with this cname (i.e., *.sun.com
> -??????????????? // implies *.eng.sun.com)
> +??????????????? // that's cname ends with this cname (i.e., *.example.com
> +??????????????? // implies *.foo.example.com)
>  ???????????????? if (this.wildcard && that.wildcard)
>  ???????????????????? return (that.cname.endsWith(this.cname));
> 
> @@ -1057,7 +1057,7 @@
>  ???????? // "1.2.3.4" equal to "1.2.3.4.", or
>  ???????? //? "*.edu" equal to "*.edu", but it
>  ???????? //? does not catch "crypto" equal to
> -??????? // "crypto.eng.sun.com".
> +??????? // "crypto.foo.example.com".
> 
>  ???????? if (this.getName().equalsIgnoreCase(that.getName())) {
>  ???????????? return true;
> @@ -1313,7 +1313,7 @@
>  ???????? SocketPermissionCollection nps = new 
> SocketPermissionCollection();
>  ???????? nps.add(this_);
>  ???????? nps.add(new 
> SocketPermission("www-leland.stanford.edu","connect"));
> -??????? nps.add(new SocketPermission("www-sun.com","connect"));
> +??????? nps.add(new SocketPermission("www-example.com","connect"));
>  ???????? System.out.println("nps.implies(that) = " + nps.implies(that_));
>  ???????? System.out.println("-----\n");
>  ???? }
> --- old/src/java.base/share/classes/java/net/URI.java 2018-11-26 
> 13:32:48.246000000 -0800
> +++ new/src/java.base/share/classes/java/net/URI.java 2018-11-26 
> 13:32:48.070000000 -0800
> @@ -83,7 +83,7 @@
>  ? * subject to further parsing.? Some examples of opaque URIs are:
>  ? *
>  ? * 
          
> - * 
        • {@code mailto:java-net at java.sun.com}
          • 
> + * 
        • {@code mailto:java-net at www.example.com}
          • 
>  ? * 
        • {@code news:comp.lang.java}
          • 
>  ? * 
        • {@code urn:isbn:096139210x}
          • 
>  ? * 
        
> @@ -399,7 +399,7 @@
>  ? * For any URI u that does not contain redundant syntax such as 
> two
>  ? * slashes before an empty authority (as in {@code 
> file:///tmp/} ) or a
>  ? * colon following a host name but no port (as in
> - * {@code http://java.sun.com:} ), and that does not encode 
> characters
> + * {@code http://www.example.com:} ), and that does not encode 
> characters
>  ? * except those that must be quoted, the following identities also hold:
>  ? * 
        >  ? *???? new URI(u.getScheme(),
> --- old/src/java.base/share/classes/java/net/URL.java 2018-11-26 
> 13:32:48.658000000 -0800
> +++ new/src/java.base/share/classes/java/net/URL.java 2018-11-26 
> 13:32:48.490000000 -0800
> @@ -95,7 +95,7 @@
>  ? * as a "ref" or a "reference". The fragment is indicated by the sharp
>  ? * sign character "#" followed by more characters. For example,
>  ? * 
        > - *???? http://java.sun.com/index.html#chapter1
> + *???? http://www.example.com/index.html#chapter1
>  ? * 
        
>  ? * 
        
>  ? * This fragment is not technically part of the URL. Rather, it
> @@ -109,7 +109,7 @@
>  ? * relative to another URL. Relative URLs are frequently used within
>  ? * HTML pages. For example, if the contents of the URL:
>  ? * 
        > - *???? http://java.sun.com/index.html
> + *???? http://www.example.com/index.html
>  ? * 
        
>  ? * contained within it the relative URL:
>  ? * 
        > @@ -117,7 +117,7 @@
>  ? * 
        
>  ? * it would be a shorthand for:
>  ? * 
        > - *???? http://java.sun.com/FAQ.html
> + *???? http://www.example.com/FAQ.html
>  ? * 
        
>  ? * 
        
>  ? * The relative URL need not specify all the components of a URL. If
> --- old/src/java.base/share/classes/java/net/URLPermission.java 
> 2018-11-26 13:32:49.050000000 -0800
> +++ new/src/java.base/share/classes/java/net/URLPermission.java 
> 2018-11-26 13:32:48.874000000 -0800
> @@ -57,7 +57,7 @@
>  ? * RFC 2732. Literal IPv6 addresses must however, be enclosed in 
> '[]' characters.
>  ? * The dnsname specification can be preceded by "*." which means
>  ? * the name will match any hostname whose right-most domain labels are 
> the same as
> - * this name. For example, "*.oracle.com" matches "foo.bar.oracle.com"
> + * this name. For example, "*.example.com" matches "foo.bar.example.com"
>  ? * 
        
>  ? * portrange is used to specify a port number, or a bounded or 
> unbounded range of ports
>  ? * that this permission applies to. If portrange is absent or invalid, 
> then a default
> @@ -78,18 +78,18 @@
>  ? * Example url scope="col">Description
>  ? * 
>  ? * 
> - *  style="white-space:nowrap;">http://www.oracle.com/a/b/c.html
> + *  style="white-space:nowrap;">http://www.example.com/a/b/c.html
>  ? *?? A url which identifies a specific (single) resource
>  ? * 
> - * http://www.oracle.com/a/b/*
> + * http://www.example.com/a/b/*
>  ? *?? The '*' character refers to all resources in the same 
> "directory" - in
>  ? *?????? other words all resources with the same number of path 
> components, and
>  ? *?????? which only differ in the final path component, represented by 
> the '*'.
>  ? *?? 
>  ? * 
> - * http://www.oracle.com/a/b/-
> + * http://www.example.com/a/b/-
>  ? *?? The '-' character refers to all resources recursively below the
> - *?????? preceding path (e.g. http://www.oracle.com/a/b/c/d/e.html 
> matches this
> + *?????? preceding path (e.g. http://www.example.com/a/b/c/d/e.html 
> matches this
>  ? *?????? example).
>  ? *?? 
>  ? * 
> @@ -267,9 +267,9 @@
>  ????? * 
      • if this's url scheme is not equal to p's url scheme return 
> false
        • 
>  ????? * 
      • if the scheme specific part of this's url is '*' return 
> true
        • 
>  ????? * 
      • if the set of hosts defined by p's url hostrange is not a 
> subset of
> -???? *???? this's url hostrange then return false. For example, 
> "*.foo.oracle.com"
> -???? *???? is a subset of "*.oracle.com". "foo.bar.oracle.com" is not
> -???? *???? a subset of "*.foo.oracle.com"
        • 
> +???? *???? this's url hostrange then return false. For example, 
> "*.foo.example.com"
> +???? *???? is a subset of "*.example.com". "foo.bar.example.com" is not
> +???? *???? a subset of "*.foo.example.com"
        • 
>  ????? * 
      • if the portrange defined by p's url is not a subset of the
>  ????? *???? portrange defined by this's url then return false.
>  ????? * 
      • if the path or paths specified by p's url are contained in the
> --- old/src/java.base/share/classes/java/net/package-info.java 
> 2018-11-26 13:32:49.438000000 -0800
> +++ new/src/java.base/share/classes/java/net/package-info.java 
> 2018-11-26 13:32:49.262000000 -0800
> @@ -131,7 +131,7 @@
>  ? *??? InputStream.
>  ? * 
        Here is an example:
        
>  ? * 
        > - * URI uri = new URI("http://java.sun.com/");
> + * URI uri = new URI("http://www.example.com/");
>  ? * URL url = uri.toURL();
>  ? * InputStream in = url.openStream();
>  ? * 
        
> --- old/src/java.base/share/classes/java/nio/file/Files.java 2018-11-26 
> 13:32:49.798000000 -0800
> +++ new/src/java.base/share/classes/java/nio/file/Files.java 2018-11-26 
> 13:32:49.630000000 -0800
> @@ -3067,7 +3067,7 @@
>  ????? * it to a file:
>  ????? * 
        >  ????? *???? Path path = ...
> -???? *???? URI u = URI.create("http://java.sun.com/");
> +???? *???? URI u = URI.create("http://www.example.com/");
>  ????? *???? try (InputStream in = u.toURL().openStream()) {
>  ????? *???????? Files.copy(in, path);
>  ????? *???? }
> --- old/src/java.base/share/classes/java/security/CodeSource.java 
> 2018-11-26 13:32:50.206000000 -0800
> +++ new/src/java.base/share/classes/java/security/CodeSource.java 
> 2018-11-26 13:32:50.042000000 -0800
> @@ -309,13 +309,13 @@
>  ????? * 
        
>  ????? * For example, the codesource objects with the following locations
>  ????? * and null certificates all imply
> -???? * the codesource with the location 
> "http://java.sun.com/classes/foo.jar"
> +???? * the codesource with the location 
> "http://www.example.com/classes/foo.jar"
>  ????? * and null certificates:
>  ????? * 
        >  ????? *???? http:
> -???? *???? http://*.sun.com/classes/*
> -???? *???? http://java.sun.com/classes/-
> -???? *???? http://java.sun.com/classes/foo.jar
> +???? *???? http://*.example.com/classes/*
> +???? *???? http://www.example.com/classes/-
> +???? *???? http://www.example.com/classes/foo.jar
>  ????? * 
        
>  ????? *
>  ????? * Note that if this CodeSource has a null location and a null
> 

From weijun.wang at oracle.com  Tue Nov 27 14:13:12 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 27 Nov 2018 22:13:12 +0800
Subject: RFR 8213009: Refactoring existing SunMSCAPI classes
In-Reply-To: <75aae853-4cc9-c241-e302-42ff8bd0fced@oracle.com>
References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com>
 <38AC3F35-E670-4A37-AEA2-5B0E22DAAD92@oracle.com>
 
 
 <1ede21e9-b40d-2044-f7ec-5a6230913231@oracle.com>
 
 <75aae853-4cc9-c241-e302-42ff8bd0fced@oracle.com>
Message-ID: <18E5958C-3C3B-453A-A653-21FBE252259E@oracle.com>



> On Nov 27, 2018, at 9:55 AM, Valerie Peng  wrote:
> 
> Hi Max,
> 
> Please find comments in line.
> On 11/22/2018 6:04 AM, Weijun Wang wrote:
>>> On Nov 22, 2018, at 9:14 AM, Valerie Peng 
>>>  wrote:
>>> 
>>> Hi Max,
>>> 
>>> Here are some comments:
>>> 
>>> 
>>> - line 39, add PSS here as well.
>>> - line 97, CSignature ctr, better to initialize all fields
>>> 
>> Which particular ones are you thinking about? privateKey and publicKey will be initialized later and messageDigest/messageDigestAlgorithm/needsReset will be useless when digestName == null.
>> 
> I was referring messageDigest/messageDigestAlgorithm/needsReset. My general preference is to set them to null/false even when not used, may help catch future coding problems. 

OK.

>>> - line 109, has key algorithm been checked by JCA already? If not, it should be checked here. Same goes for line 414, and 560
>>> 
>> Can I do this later? This sub-task is meant to be a cleanup.
> My point for checking the key algorithm is to ensure that the specified key object is RSA type. After this cleanup and refactoring, the specified key should be checked to be of RSA type, i.e. line 111, 130. Otherwise, the casting to various RSA public/private key interfaces, e.g. java.security.interfaces.RSAPublicKey, may fail.

OK, I can check for RSAPublicKey.

On the other hand, if I create a subclass for CRSAPublicKey, its getModulus() and getPrivateExponent() can only throw out a ProviderException if the key is unextractable, and this breaks some existing code inside JDK.

Thanks
Max

> 
> Updates look fine.
> 
> Regards,
> 
> Valerie
> 
>> But I think I need to move more RSA related methods into the RSA subclass.
>> 
>> 
>>> - with the class renaming, I think it's clearer to include "RSA" as part of the subclass names, e.g. "MD2withRSA" instead of just "MD2"
>>> 
>> OK.
>> 
>> 
>>> - line 681: can be static, right? pkg-private?
>>> 
>> Yes. Looks like it can be private.
>> 
>> 
>>> 
>>> - line 120: maybe a ProviderException instead of IllegalArgumentException as the 'alg' is not from user but rather inside the provider.
>>> 
>> Either is OK for me. Since it's only called inside the provider, it can even be an AssertionError.
>> 
>> 
>>> - line 127, add @Override
>>> 
>> OK.
>> 
>> 
>>> - line 140, must getPublicKeyBob be public? Maybe pkg private?
>>> 
>> Correct.
>> 
>> 
>>> 
>>> - line 119: why not just use RSAPrivateCrtKey instead of Key? The caller has already did an instanceof check before this method.
>>> 
>> Correct. I think I should rename both setPrivateKey and generatePrivateKeyBlob to setRSAPrivateKey and generateRSAPrivateKeyBlob. If one day I starts supporting EC keys the methods will be quite different.
>> 
>> 
>>> 
>>> - would be nice to have a String constant for "RSA".
>>> 
>> Sure.
>> 
>> Thanks
>> Max
>> 
>> 
>>> Rest looks fine.
>>> Thanks,
>>> Valerie
>>> 
>>> 
>>> On 11/15/2018 7:40 AM, Weijun Wang wrote:
>>> 
>>>> Oops, my copy/paste sequence goes wrong.
>>>> 
>>>> 
>>>>> On Nov 15, 2018, at 11:38 PM, Weijun Wang 
>>>>>  wrote:
>>>>> 
>>>>> Webrev updated at
>>>>> 
>>>>> 
>>>>    https://cr.openjdk.java.net/~weijun/8213009/webrev.01/
>>>> 
>>>> 
>>>> 
>>>>> More refactorings:
>>>>> 
>>>>> - getEncoded and getFormat of CKey removed, implemented in CPublicKey and CPrivateKey.
>>>>> 
>>>>> - CPublicKey has child class CRSAPublicKey, CKeyPairGenerator has child class RSA.
>>>>> 
>>>>> - CPublicKey and CPrivateKey now have a static of() method that can return a child instance.
>>>>> 
>>>>> - CCipher renamed to CRSACipher. I realized there won't be CECCipher.
>>>>> 
>>>>> Thanks
>>>>> Max
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Nov 7, 2018, at 12:13 AM, Weijun Wang 
>>>>>>  wrote:
>>>>>> 
>>>>>> Webrev updated at
>>>>>> 
>>>>>> 
>>>>>> https://cr.openjdk.java.net/~weijun/8213009/webrev.00/
>>>>>> 
>>>>>> 
>>>>>> The subtask id is now used.
>>>>>> 
>>>>>> The previous refactoring has removed the "RSA" algorithm info from some keys. This update adds them back.
>>>>>> 
>>>>>> Thanks
>>>>>> Max
>>>>>> 
>>>>>> 
>>>>>>> On Oct 25, 2018, at 4:38 PM, Weijun Wang 
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Please review the change at
>>>>>>> 
>>>>>>> 
>>>>>>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/
>>>>>>> 
>>>>>>> 
>>>>>>> (I will use a sub-task id for this change but currently JBS is down).
>>>>>>> 
>>>>>>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart.
>>>>>>> 
>>>>>>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include:
>>>>>>> 
>>>>>>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1].
>>>>>>> 
>>>>>>> - Child class named "RSA" of CKeyPairGenerator.
>>>>>>> 
>>>>>>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods.
>>>>>>> 
>>>>>>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now.
>>>>>>> 
>>>>>>> Noreg-cleanup.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Max
>>>>>>> 
>>>>>>> [1] 
>>>>>>> https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier



From sean.coffey at oracle.com  Tue Nov 27 14:27:28 2018
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 27 Nov 2018 14:27:28 +0000
Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123
In-Reply-To: 
References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com>
 
 <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com>
 
 <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com>
 
 <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com>
 <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com>
 
 
Message-ID: <868a73e0-0981-ffda-f070-7acc008f6baa@oracle.com>

Thanks for the feedback Max. I'll ping Joe Darcy and check if a CSR is 
required for this type of change. I'll revert back to this list once I 
have an answer.

keytool works well with the new change. I've modified the test as per 
your suggestion :

--- a/test/jdk/sun/security/tools/keytool/KeyToolTest.java
+++ b/test/jdk/sun/security/tools/keytool/KeyToolTest.java
@@ -1436,6 +1436,7 @@
          testOK("", pre+"san3 -ext san=dns:me.org");
          testOK("", pre+"san4 -ext san=ip:192.168.0.1");
          testOK("", pre+"san5 -ext san=oid:1.2.3.4");
+        testOK("", pre+"san6 -ext san=dns:1abc.com"); //begin with digit
          testOK("", pre+"san235 -ext 
san=uri:http://me.org,dns:me.org,oid:1.2.3.4");

Regards,
Sean.

On 27/11/18 01:29, Weijun Wang wrote:
>
>> On Nov 26, 2018, at 11:15 AM, Weijun Wang  wrote:
>>
>>
>>
>>> On Nov 24, 2018, at 12:45 AM, Se?n Coffey  wrote:
>>>
>>> Thanks for your review Max. I've made the suggested edits.
>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v3/webrev/
>> The change looks fine. Thanks.
>>
>>> I've also submitted a CSR for this change just to cover the behavioural aspect of the edit. Will push if/once that's approved by CSR team.
>> The CSR focuses on keytool but this is actually a library change. There is no change with "add/remove/modify command line option" at all.
>>
>> I would suggest talking about the DNSName class instead of keytool. I understand it's internal but we can describe this change as a non-minimal change on behavior so it's still worth a CSR. Or, you can consult Joe what the best way is. Maybe he can spare you from filing a CSR at all.
>>
>> BTW, you did try out keytool after this code change and "-ext dns=1abc.com" is working now, right?
> You can add an extra line after line 1437 of test/jdk/sun/security/tools/keytool/KeyToolTest.java.
>
>> Thanks
>> Max
>>
>>> Regards,
>>> Sean.
>>>
>>> On 22/11/18 14:49, Weijun Wang wrote:
>>>> * DNSName.java:
>>>>
>>>>   91             if ((endIndex - startIndex) < 1)
>>>>
>>>> No need for inner parentheses.
>>>>
>>>> And, is there really a need to define alphaDigitsAndHyphen? How about just (== '-' || inside alphaDigits)?
>>>>
>>>> * DNSNameTest.java:
>>>>
>>>> Space cannot appear anywhere, please add a test case like "a c.com".
>>>>
>>>> BTW, I assume you want to reuse this test for other sub-tasks of JDK-8054380? I see the @summary is more general.
>>>>
>>>> No other comments.
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>> On Nov 22, 2018, at 12:51 AM, Se?n Coffey  wrote:
>>>>>
>>>>> p.s I've updated the testcase to test the IOException message for presence of "DNSName". Webrev updated in place.
>>>>>
>>>>> Regards,
>>>>> Sean.
>>>>>
>>>>> On 21/11/18 15:42, Se?n Coffey wrote:
>>>>>> Thanks for the comments Bernd. Comments inline..
>>>>>>
>>>>>> On 16/11/18 21:27, Bernd Eckenfels wrote:
>>>>>>> Hello Sean,
>>>>>>>
>>>>>>> I was only looking at the inspected DNSName class, it still has some variations (but start now with DNSNames which is good already):
>>>>>>>
>>>>>>>   76 throw new IOException("DNSName must not be null or empty");
>>>>>>>   78 throw new IOException("DNSNames or NameConstraints with blank components are not permitted");
>>>>>>>   80 throw new IOException("DNSNames or NameConstraints may not begin or end with a .");
>>>>>>>   92 throw new IOException("DNSName SubjectAltNames with empty components are not permitted");
>>>>>>> 96 throw new IOException("DNSName components must begin with a letter or digit");
>>>>>>> 101 throw new IOException("DNSName components must consist of letters, digits, and hyphens");
>>>>>>>
>>>>>>> I did not check if those exceptions are catched and rethrown with something like ?while validating the SubjectAltName Extension  of certificate ...?, in my experience it helps if you do not have to find and review the actual certificates (in this case it might not be a problem if SAN is only in the end entity). You can probably remove ?or NameConstraints? and ?SubjectAltNames? from lines 78-92 (this is good if DNsNa
>>>>>> Ok - I've cleaned up the exception messages on line 78, 80, 92.
>>>>>> webrev updated in place : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/
>>>>>>
>>>>>>
>>>>>>> me applies to SAN or NameConstrained context and the validation logic does not know ? so it?s not only more unified but also less missleading)
>>>>>>>
>>>>>>> BTW: probably not inthe scope of this fix but a subtype for validation errors which have getters for context/location and maybe error code and getValue() would allow callers to print nicer validation reports without relying on the message or Stacktraces.
>>>>>> That's a nice idea and one that should be followed up in separate enhancement. We could lean on the new `jdk.includeInExceptions` Security property which other component areas have started to use lately.
>>>>>>
>>>>>> e.g. https://bugs.openjdk.java.net/browse/JDK-8207768
>>>>>>
>>>>>> regards,
>>>>>> Sean.
>>>>>>> Gruss
>>>>>>> Bernd
>>>>>>> --
>>>>>>> http://bernd.eckenfels.net
>>>>>>> Von: Se?n Coffey 
>>>>>>> Gesendet: Freitag, November 16, 2018 5:15 PM
>>>>>>> An: Bernd Eckenfels; security-dev at openjdk.java.net
>>>>>>> Betreff: Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123
>>>>>>> Thanks for the comments Bernd. comments inline..
>>>>>>>
>>>>>>> On 16/11/18 12:40, Bernd Eckenfels wrote:
>>>>>>>> You could also add (a..b, false) and (.a, false), (a., false) to the testcases.
>>>>>>> good point. test updated.
>>>>>>>> I noticed that there are different types of Exception messages (DNS name, DNSName, DNS Name or name constrained, DNS name and SAN), would be good if all of them have the same keyword?
>>>>>>> I cleaned up some other references to DNSName in the sun.security.x509 package. I'm not sure what classes you were referencing the above examples from.
>>>>>>>
>>>>>>> new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/
>>>>>>>
>>>>>>> regards,
>>>>>>> Sean.
>>>>>>>> Gruss
>>>>>>>> Bernd
>>>>>>>> --
>>>>>>>> http://bernd.eckenfels.net
>>>>>>>> Von: security-dev  im Auftrag von Se?n Coffey 
>>>>>>>> Gesendet: Freitag, November 16, 2018 12:25 PM
>>>>>>>> An: OpenJDK Dev list
>>>>>>>> Betreff: RFR: 8213952: Relax DNSName restriction as per RFC 1123
>>>>>>>> Looking to make an adjustment to DNSName constructor to help comply with
>>>>>>>> RFC 1123
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213952
>>>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> Sean.
>>>>>>>>



From Roger.Riggs at oracle.com  Tue Nov 27 14:48:00 2018
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 27 Nov 2018 09:48:00 -0500
Subject: JDK 12 RFR of JDK-8213911: Use example.com in java.net and other
 examples
In-Reply-To: <072b68a2-38ee-890c-c0e3-84afa4b641db@oracle.com>
References: <072b68a2-38ee-890c-c0e3-84afa4b641db@oracle.com>
Message-ID: <562dc2ad-f94b-8330-c47f-506ee356db05@oracle.com>

Looks fine Joe

I hadn't realized example.com was registered for that purpose.? :)


On 11/26/2018 04:38 PM, joe darcy wrote:
> Hello,
>
> Please review a simple doc-only change to address:
>
> ??? JDK-8213911: Use example.com in java.net and other examples
> ??? http://cr.openjdk.java.net/~darcy/8213911.0/
>
> Patch below.
>
> Thanks,
>
> -Joe
>
>
> --- old/src/java.base/share/classes/java/net/HostPortrange.java 
> 2018-11-26 13:32:47.078000000 -0800
> +++ new/src/java.base/share/classes/java/net/HostPortrange.java 
> 2018-11-26 13:32:46.902000000 -0800
> @@ -60,7 +60,7 @@
> ???? HostPortrange(String scheme, String str) {
> ???????? // Parse the host name.? A name has up to three components, the
> ???????? // hostname, a port number, or two numbers representing a port
> -??????? // range.?? "www.sun.com:8080-9090" is a valid host name.
> +??????? // range.?? "www.example.com:8080-9090" is a valid host name.
>
> ???????? // With IPv6 an address can be 2010:836B:4179::836B:4179
> ???????? // An IPv6 address needs to be enclose in []
> --- old/src/java.base/share/classes/java/net/InetAddress.java 
> 2018-11-26 13:32:47.474000000 -0800
> +++ new/src/java.base/share/classes/java/net/InetAddress.java 
> 2018-11-26 13:32:47.298000000 -0800
> @@ -1168,7 +1168,7 @@
> ????? * No name service is checked for the validity of the address.
> ????? *
> ????? * 
         The host name can either be a machine name, such as
> -???? * "{@code java.sun.com}", or a textual representation of its IP
> +???? * "{@code www.example.com}", or a textual representation of its IP
> ????? * address.
> ????? * 
         No validity checking is done on the host name either.
> ????? *
> @@ -1213,7 +1213,7 @@
> ????? * Determines the IP address of a host, given the host's name.
> ????? *
> ????? * 
         The host name can either be a machine name, such as
> -???? * "{@code java.sun.com}", or a textual representation of its
> +???? * "{@code www.example.com}", or a textual representation of its
> ????? * IP address. If a literal IP address is supplied, only the
> ????? * validity of the address format is checked.
> ????? *
> @@ -1259,7 +1259,7 @@
> ????? * based on the configured name service on the system.
> ????? *
> ????? * 
         The host name can either be a machine name, such as
> -???? * "{@code java.sun.com}", or a textual representation of its IP
> +???? * "{@code www.example.com}", or a textual representation of its IP
> ????? * address. If a literal IP address is supplied, only the
> ????? * validity of the address format is checked.
> ????? *
> --- old/src/java.base/share/classes/java/net/SocketPermission.java 
> 2018-11-26 13:32:47.850000000 -0800
> +++ new/src/java.base/share/classes/java/net/SocketPermission.java 
> 2018-11-26 13:32:47.678000000 -0800
> @@ -63,7 +63,7 @@
> ? * or as "localhost" (for the local machine).
> ? * The wildcard "*" may be included once in a DNS name host
> ? * specification. If it is included, it must be in the leftmost
> - * position, as in "*.sun.com".
> + * position, as in "*.example.com".
> ? * 
        
> ? * The format of the IPv6reference should follow that specified in  ? * href="http://www.ietf.org/rfc/rfc2732.txt">RFC 2732: Format
> @@ -115,11 +115,11 @@
> ? * note that if the following permission:
> ? *
> ? * 
        > - *?? p1 = new SocketPermission("puffin.eng.sun.com:7777", 
> "connect,accept");
> + *?? p1 = new SocketPermission("foo.example.com:7777", 
> "connect,accept");
> ? * 
        
> ? *
> ? * is granted to some code, it allows that code to connect to port 
> 7777 on
> - * {@code puffin.eng.sun.com}, and to accept connections on that port.
> + * {@code foo.example.com}, and to accept connections on that port.
> ? *
> ? * 
        Similarly, if the following permission:
> ? *
> @@ -211,7 +211,7 @@
> ???? // all the IP addresses of the host
> ???? private transient InetAddress[] addresses;
>
> -??? // true if the hostname is a wildcard (e.g. "*.sun.com")
> +??? // true if the hostname is a wildcard (e.g. "*.example.com")
> ???? private transient boolean wildcard;
>
> ???? // true if we were initialized with a single numeric IP address
> @@ -274,9 +274,9 @@
> ????? * 
        
> ????? * Examples of SocketPermission instantiation are the following:
> ????? * 
        > -???? *??? nr = new SocketPermission("www.catalog.com", "connect");
> -???? *??? nr = new SocketPermission("www.sun.com:80", "connect");
> -???? *??? nr = new SocketPermission("*.sun.com", "connect");
> +???? *??? nr = new SocketPermission("www.example.com", "connect");
> +???? *??? nr = new SocketPermission("www.example.com:80", "connect");
> +???? *??? nr = new SocketPermission("*.example.com", "connect");
> ????? *??? nr = new SocketPermission("*.edu", "resolve");
> ????? *??? nr = new SocketPermission("204.160.241.0", "connect");
> ????? *??? nr = new SocketPermission("localhost:1024-65535", "listen");
> @@ -400,7 +400,7 @@
>
> ???????? // Parse the host name.? A name has up to three components, the
> ???????? // hostname, a port number, or two numbers representing a port
> -??????? // range.?? "www.sun.com:8080-9090" is a valid host name.
> +??????? // range.?? "www.example.com:8080-9090" is a valid host name.
>
> ???????? // With IPv6 an address can be 2010:836B:4179::836B:4179
> ???????? // An IPv6 address needs to be enclose in []
> @@ -835,10 +835,10 @@
> ????? * 
          
> ????? * 
        •  If this object was initialized with a single IP address 
> and one of p's
> ????? * IP addresses is equal to this object's IP address.
> -???? * 
        • If this object is a wildcard domain (such as *.sun.com), and
> +???? * 
        • If this object is a wildcard domain (such as 
> *.example.com), and
> ????? * p's canonical name (the name without any preceding *)
> -???? * ends with this object's canonical host name. For example, 
> *.sun.com
> -???? * implies *.eng.sun.com.
> +???? * ends with this object's canonical host name. For example, 
> *.example.com
> +???? * implies *.foo.example.com.
> ????? * 
        • If this object was not initialized with a single IP 
> address, and one of this
> ????? * object's IP addresses equals one of p's IP addresses.
> ????? * 
        • If this canonical name equals p's canonical name.
> @@ -878,7 +878,7 @@
> ????? * 
        •  Checks that "p"'s port range is included in this port range
> ????? * 
        •  If this object was initialized with an IP address, checks 
> that
> ????? *????? one of "p"'s IP addresses is equal to this object's IP 
> address.
> -???? * 
        •  If either object is a wildcard domain (i.e., "*.sun.com"),
> +???? * 
        •  If either object is a wildcard domain (i.e., 
> "*.example.com"),
> ????? *????? attempt to match based on the wildcard.
> ????? * 
        •  If this object was not initialized with an IP address, 
> attempt
> ????? *????? to find a match based on the IP addresses in both objects.
> @@ -944,8 +944,8 @@
> ???????????? // check and see if we have any wildcards...
> ???????????? if (this.wildcard || that.wildcard) {
> ???????????????? // if they are both wildcards, return true iff
> -??????????????? // that's cname ends with this cname (i.e., *.sun.com
> -??????????????? // implies *.eng.sun.com)
> +??????????????? // that's cname ends with this cname (i.e., 
> *.example.com
> +??????????????? // implies *.foo.example.com)
> ???????????????? if (this.wildcard && that.wildcard)
> ???????????????????? return (that.cname.endsWith(this.cname));
>
> @@ -1057,7 +1057,7 @@
> ???????? // "1.2.3.4" equal to "1.2.3.4.", or
> ???????? //? "*.edu" equal to "*.edu", but it
> ???????? //? does not catch "crypto" equal to
> -??????? // "crypto.eng.sun.com".
> +??????? // "crypto.foo.example.com".
>
> ???????? if (this.getName().equalsIgnoreCase(that.getName())) {
> ???????????? return true;
> @@ -1313,7 +1313,7 @@
> ???????? SocketPermissionCollection nps = new 
> SocketPermissionCollection();
> ???????? nps.add(this_);
> ???????? nps.add(new 
> SocketPermission("www-leland.stanford.edu","connect"));
> -??????? nps.add(new SocketPermission("www-sun.com","connect"));
> +??????? nps.add(new SocketPermission("www-example.com","connect"));
> ???????? System.out.println("nps.implies(that) = " + nps.implies(that_));
> ???????? System.out.println("-----\n");
> ???? }
> --- old/src/java.base/share/classes/java/net/URI.java 2018-11-26 
> 13:32:48.246000000 -0800
> +++ new/src/java.base/share/classes/java/net/URI.java 2018-11-26 
> 13:32:48.070000000 -0800
> @@ -83,7 +83,7 @@
> ? * subject to further parsing.? Some examples of opaque URIs are:
> ? *
> ? * 
            
> - * 
          • {@code mailto:java-net at java.sun.com}
            • 
> + * 
          • {@code mailto:java-net at www.example.com}
            • 
> ? * 
          • {@code news:comp.lang.java}
            • 
> ? * 
          • {@code urn:isbn:096139210x}
            • 
> ? * 
          
> @@ -399,7 +399,7 @@
> ? * For any URI u that does not contain redundant syntax such 
> as two
> ? * slashes before an empty authority (as in {@code 
> file:///tmp/} ) or a
> ? * colon following a host name but no port (as in
> - * {@code http://java.sun.com:} ), and that does not encode 
> characters
> + * {@code http://www.example.com:} ), and that does not encode 
> characters
> ? * except those that must be quoted, the following identities also hold:
> ? * 
          > ? *???? new URI(u.getScheme(),
> --- old/src/java.base/share/classes/java/net/URL.java 2018-11-26 
> 13:32:48.658000000 -0800
> +++ new/src/java.base/share/classes/java/net/URL.java 2018-11-26 
> 13:32:48.490000000 -0800
> @@ -95,7 +95,7 @@
> ? * as a "ref" or a "reference". The fragment is indicated by the sharp
> ? * sign character "#" followed by more characters. For example,
> ? * 
          > - *???? http://java.sun.com/index.html#chapter1
> + *???? http://www.example.com/index.html#chapter1
> ? * 
          
> ? * 
          
> ? * This fragment is not technically part of the URL. Rather, it
> @@ -109,7 +109,7 @@
> ? * relative to another URL. Relative URLs are frequently used within
> ? * HTML pages. For example, if the contents of the URL:
> ? * 
          > - *???? http://java.sun.com/index.html
> + *???? http://www.example.com/index.html
> ? * 
          
> ? * contained within it the relative URL:
> ? * 
          > @@ -117,7 +117,7 @@
> ? * 
          
> ? * it would be a shorthand for:
> ? * 
          > - *???? http://java.sun.com/FAQ.html
> + *???? http://www.example.com/FAQ.html
> ? * 
          
> ? * 
          
> ? * The relative URL need not specify all the components of a URL. If
> --- old/src/java.base/share/classes/java/net/URLPermission.java 
> 2018-11-26 13:32:49.050000000 -0800
> +++ new/src/java.base/share/classes/java/net/URLPermission.java 
> 2018-11-26 13:32:48.874000000 -0800
> @@ -57,7 +57,7 @@
> ? * RFC 2732. Literal IPv6 addresses must however, be enclosed in 
> '[]' characters.
> ? * The dnsname specification can be preceded by "*." which means
> ? * the name will match any hostname whose right-most domain labels 
> are the same as
> - * this name. For example, "*.oracle.com" matches "foo.bar.oracle.com"
> + * this name. For example, "*.example.com" matches "foo.bar.example.com"
> ? * 
          
> ? * portrange is used to specify a port number, or a bounded or 
> unbounded range of ports
> ? * that this permission applies to. If portrange is absent or 
> invalid, then a default
> @@ -78,18 +78,18 @@
> ? * Example url scope="col">Description
> ? * 
> ? * 
> - *  style="white-space:nowrap;">http://www.oracle.com/a/b/c.html
> + *  style="white-space:nowrap;">http://www.example.com/a/b/c.html
> ? *?? A url which identifies a specific (single) resource
> ? * 
> - * http://www.oracle.com/a/b/*
> + * http://www.example.com/a/b/*
> ? *?? The '*' character refers to all resources in the same 
> "directory" - in
> ? *?????? other words all resources with the same number of path 
> components, and
> ? *?????? which only differ in the final path component, represented 
> by the '*'.
> ? *?? 
> ? * 
> - * http://www.oracle.com/a/b/-
> + * http://www.example.com/a/b/-
> ? *?? The '-' character refers to all resources recursively below the
> - *?????? preceding path (e.g. http://www.oracle.com/a/b/c/d/e.html 
> matches this
> + *?????? preceding path (e.g. http://www.example.com/a/b/c/d/e.html 
> matches this
> ? *?????? example).
> ? *?? 
> ? * 
> @@ -267,9 +267,9 @@
> ????? * 
        • if this's url scheme is not equal to p's url scheme return 
> false
          • 
> ????? * 
        • if the scheme specific part of this's url is '*' return 
> true
          • 
> ????? * 
        • if the set of hosts defined by p's url hostrange is not a 
> subset of
> -???? *???? this's url hostrange then return false. For example, 
> "*.foo.oracle.com"
> -???? *???? is a subset of "*.oracle.com". "foo.bar.oracle.com" is not
> -???? *???? a subset of "*.foo.oracle.com"
          • 
> +???? *???? this's url hostrange then return false. For example, 
> "*.foo.example.com"
> +???? *???? is a subset of "*.example.com". "foo.bar.example.com" is not
> +???? *???? a subset of "*.foo.example.com"
          • 
> ????? * 
        • if the portrange defined by p's url is not a subset of the
> ????? *???? portrange defined by this's url then return false.
> ????? * 
        • if the path or paths specified by p's url are contained in 
> the
> --- old/src/java.base/share/classes/java/net/package-info.java 
> 2018-11-26 13:32:49.438000000 -0800
> +++ new/src/java.base/share/classes/java/net/package-info.java 
> 2018-11-26 13:32:49.262000000 -0800
> @@ -131,7 +131,7 @@
> ? *??? InputStream.
> ? * 
          Here is an example:
          
> ? * 
          > - * URI uri = new URI("http://java.sun.com/");
> + * URI uri = new URI("http://www.example.com/");
> ? * URL url = uri.toURL();
> ? * InputStream in = url.openStream();
> ? * 
          
> --- old/src/java.base/share/classes/java/nio/file/Files.java 
> 2018-11-26 13:32:49.798000000 -0800
> +++ new/src/java.base/share/classes/java/nio/file/Files.java 
> 2018-11-26 13:32:49.630000000 -0800
> @@ -3067,7 +3067,7 @@
> ????? * it to a file:
> ????? * 
          > ????? *???? Path path = ...
> -???? *???? URI u = URI.create("http://java.sun.com/");
> +???? *???? URI u = URI.create("http://www.example.com/");
> ????? *???? try (InputStream in = u.toURL().openStream()) {
> ????? *???????? Files.copy(in, path);
> ????? *???? }
> --- old/src/java.base/share/classes/java/security/CodeSource.java 
> 2018-11-26 13:32:50.206000000 -0800
> +++ new/src/java.base/share/classes/java/security/CodeSource.java 
> 2018-11-26 13:32:50.042000000 -0800
> @@ -309,13 +309,13 @@
> ????? * 
          
> ????? * For example, the codesource objects with the following locations
> ????? * and null certificates all imply
> -???? * the codesource with the location 
> "http://java.sun.com/classes/foo.jar"
> +???? * the codesource with the location 
> "http://www.example.com/classes/foo.jar"
> ????? * and null certificates:
> ????? * 
          > ????? *???? http:
> -???? *???? http://*.sun.com/classes/*
> -???? *???? http://java.sun.com/classes/-
> -???? *???? http://java.sun.com/classes/foo.jar
> +???? *???? http://*.example.com/classes/*
> +???? *???? http://www.example.com/classes/-
> +???? *???? http://www.example.com/classes/foo.jar
> ????? * 
          
> ????? *
> ????? * Note that if this CodeSource has a null location and a null
>


From sean.mullan at oracle.com  Tue Nov 27 19:36:09 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 27 Nov 2018 14:36:09 -0500
Subject: Code Review Request, JDK-8213577, Update the default SSL session
 cache size to 20480
In-Reply-To: 
References: <32aba2fc-73a9-d685-ce5c-61a399395496@oracle.com>
 
 
 
 <228516ab-aaca-5a4e-f709-3b4f44a82101@oracle.com>
 
 <0ed3fc6a-e338-3c4b-3a9a-0d3123946e0c@oracle.com>
 
 
Message-ID: 

Looks good. My only question is whether the apiNote should be an 
implNote instead since it refers to what the JDK Implementation does. 
But either way seems ok.

--Sean

On 11/26/18 1:14 PM, Xue-Lei Fan wrote:
> I made the update accordingly:
> 
>  ? http://cr.openjdk.java.net/~xuelei/8210985/webrev.04/
> 
> Thanks,
> 
> Xuelei
> 
> On 11/19/2018 7:39 AM, Sean Mullan wrote:
>> On 11/16/18 3:19 PM, Xuelei Fan wrote:
>>> Thanks for the review, Jmail & Sean.
>>>
>>> New webrev:
>>> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.03/
>>>
>>> I will update CSR when we come to an agreement.
>>>
>>> On 11/16/2018 11:33 AM, Sean Mullan wrote:
>>>> ??122????? * @apiNote Both the session timeout and cache size impact 
>>>> performance
>>>> ??123????? *????????? of future connections.? It is not recommended 
>>>> to use too big
>>>> ??124????? *????????? or too small timeout or cache size limit. 
>>>> Applications should
>>>> ??125????? *????????? carefully weigh the limits and performance for 
>>>> the specific
>>>> ??126????? *????????? circumstances.
>>>>
>>>> I am not really sure if the @apiNote is that useful or appropriate,
>>> I worry about the default value actually.
>>
>> Then maybe the default is what you should be discussing in this 
>> apiNote. Right now I don't think the apiNote adds much. To me, all you 
>> are really saying is that these are methods that can be used to tune 
>> performance, which I think should be obvious from their name and 
>> description. Maybe the apiNote should say something like:
>>
>> "Note that the JDK Implementation uses default values for both the 
>> session cache size and timeout. See getSessionCacheSize and 
>> getSessionTimeout for more information. Applications should consider 
>> their performance requirements and override the defaults if necessary."
>>
>> Also I think you should add a similar @implNote for getSessionTimeout 
>> which describes the default value (86400 seconds or 24 hours), ex:
>>
>> @implNote The JDK implementation returns the session timeout as set by 
>> ?????? the {@code setSessionTimeout} method, or if not set, a default 
>> value of 86400 seconds (24 hours).
>>
>>> ? A new bug may be filed again and argue if the default value is not 
>>> a proper one.? The default value of session timeout and cache size 
>>> really depends on the real world circumstances.? I think we'd better 
>>> make a clarification in the spec, and remind application tune them 
>>> accordingly.
>>
>> Ok, but the apiNote above says nothing about the default value.
>>
>> --Sean
>>
>>>
>>>> but it seems a bit odd to talk about the session timeout in this 
>>>> method. 
>>> The performance impact is a combination of the session timeout limit 
>>> and cache size.? I would like application consider them together if 
>>> need to tune the values, but not individually.
>>>
>>>> If you still want to add this, I would add an @apiNote to each of 
>>>> the setSessionCacheSize and setSessionTimeout methods and just 
>>>> discuss each property separately.
>>>>
>>> I added the update spec to both setSessionCacheSize and 
>>> setSessionTimeout.
>>>
>>>> Also, unless you say what "too big" or "too small" is, I would avoid 
>>>> giving this advice.
>>>>
>>> It makes sense to me.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>> --Sean
>>>>
>>>>
>>>> On 11/16/18 1:30 PM, Xuelei Fan wrote:
>>>>> It's time to use the systemProperty tag as it is ready.
>>>>>
>>>>> As we are already there, I also update the setSessionCacheSize() 
>>>>> for more clarification.
>>>>>
>>>>> Please review both CSR and webrev:
>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8213577
>>>>> ???? http://cr.openjdk.java.net/~xuelei/8210985/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>> On 11/16/2018 8:19 AM, Sean Mullan wrote:
>>>>>> On 11/15/18 3:37 PM, Xuelei Fan wrote:
>>>>>>> Hi Sean,
>>>>>>>
>>>>>>> Are you OK if we do it later?? I'm waiting for the 
>>>>>>> @systemProperty tag, proposed within JDK-5076751.? I will file a 
>>>>>>> bug to use the tag for more cleanup.
>>>>>>
>>>>>> JDK-5076751 is completed and pushed to JDK 12, so you can use the 
>>>>>> new tag now.
>>>>>>
>>>>>> I think it would be easier to do it now, it seems pretty simple 
>>>>>> and that way there is no need to worry about it later.
>>>>>>
>>>>>> --Sean
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Xuelei
>>>>>>>
>>>>>>> On 11/15/2018 11:55 AM, Sean Mullan wrote:
>>>>>>>> This is a good opportunity to document the 
>>>>>>>> javax.net.ssl.sessionCacheSize system property in the 
>>>>>>>> SSLSessionContext API (and use the new @systemProperty tag) in 
>>>>>>>> an @implNote, for example:
>>>>>>>>
>>>>>>>> ???? /**
>>>>>>>> ????? * Returns the size of the cache used for storing
>>>>>>>> ????? * SSLSession objects grouped under this
>>>>>>>> ????? * SSLSessionContext.
>>>>>>>> ????? *
>>>>>>>> ????? * @implNote The JDK implementation returns the cache size 
>>>>>>>> as set by
>>>>>>>> ????? * the {@code setSessionCacheSize method}, or if not set, 
>>>>>>>> the value
>>>>>>>> ????? * of the {@systemProperty javax.net.ssl.sessionCacheSize} 
>>>>>>>> system
>>>>>>>> ????? * property. If neither is set, it returns a default value 
>>>>>>>> of 20480.
>>>>>>>> ????? *
>>>>>>>> ????? * @return size of the session cache; zero means there is 
>>>>>>>> no size limit.
>>>>>>>> ????? * @see #setSessionCacheSize
>>>>>>>> ????? */
>>>>>>>> ???? public int getSessionCacheSize();
>>>>>>>>
>>>>>>>> On 11/14/18 11:59 AM, Xuelei Fan wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review this simple update:
>>>>>>>>> http://cr.openjdk.java.net/~xuelei/8210985/webrev.00/
>>>>>>>>>
>>>>>>>>> The default value for the maximum number of entries in the SSL 
>>>>>>>>> session cache (SSLSessionContext.getSessionCacheSize()) is 
>>>>>>>>> infinite now.? In the request, the default value is updated to 
>>>>>>>>> 20480 for performance consideration.
>>>>>>>>>
>>>>>>>>> For the detailed behavior update, please refer to CSR:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213577
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Xuelei


From Nico.Williams at twosigma.com  Wed Nov 28 17:55:51 2018
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Wed, 28 Nov 2018 17:55:51 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: 
References: 
Message-ID: <20181128175551.GA13826@twosigma.com>

On Tue, Nov 20, 2018 at 09:56:36AM +0800, Weijun Wang wrote:
> Please take a review at
> 
>    https://cr.openjdk.java.net/~weijun/6722928/webrev.01/
> 
> We ported [1] the native GSS bridge to Windows in JDK 11, but user still have
> to download and install a native GSS-API library. This code change provides a
> native GSS-API library inside JDK that can be used without setting the
> "sun.security.jgss.lib" system property. It is based on Windows SSPI and now
> only supports the client side using the default credentials.
> 
> No regression tests included. A Windows Active Directory server is needed.

This is my initial round of comments, and it's mostly high-level:

 - Right now this looks very basic, and you won't get support for any
   mechanism other than Kerberos.  That's fine though, as NTLM is dead,
   you're willing to implement SPNEGO yourself, and there are no other
   GSS mechs on Windows at this time (so far as I know).

 - You're constructing SPNEGO tokens yourself.  I'll have to review that
   very carefully.

   It would be better to let Windows provide SPNEGO though...

 - I've checked the DER-encoded OID constants.  They are correct.

 - The name type OID for GSS_KRB5_NT_PRINCIPAL_NAME is not implemented but is
   used elsewhere (e.g., in one GSSNameElement constructor).  Look for
   GSSUtil.NT_GSS_KRB5_PRINCIPAL.

 - gss_canonicalize_name() is not fully implemented.  This will be noticeable
   to callers of GSSNameElement's getKrbName().  In particular, permissions
   checks will fail (e.g., in GSSCredElement's doServicePermCheck(); similarly
   in NativeGSSContext).

   At minimum you absolutely must parse generic GSS name type names into
   Kerberos-style names (e.g., service at hostname -> service/hostname@).

   When an MN is displayed, you need to output the Kerberos-style name.

   (For those following along, "MN" means "mechanism name", which means
   a GSSName / gss_name_t instance which is "canonical" and whose
   display form will be mechanism-specific.  gss_canonicalize_name() is
   supposed to output a "canonical" version of its input.)

   You'll also have to determine a realm for the parsed principal names.

   You won't need a realm for services.  Use an empty realm name for
   services -- that's the Heimdal/MIT (and Solaris) convention for when
   you're willing to rely on KDC referrals.

   (I would also urge you to NOT attempt any DNS canonicalization of
   hostnames.  Let's not further spread that mistake.)

   For user principals it's trickier, and I think you might need some notion of
   default realm, but a) maybe you can get away with an empty realm here on
   Windows, b) I'm not sure where you'd a default realm on Windows.

   What we do to determine the default realm for user names in our
   patched version of Martin Rex's GSS->SSPI bridge is call
   AcquireCredentialsHandle() or QueryCredentialsAttributesW() to
   get/query the default credential and get its name, and from that the
   realm, and we use that as the default realm.

   I'll have to look and see how we handle host-based service names
   (Martin's original code has a domain_realm table in the registry, but
   we removed all of that and rely on referrals instead.)

 - If you can get Legal approval for including / distributing a fork of
   Martin Rex's bridge, you'll get all of the above functionality and
   also acceptor functionality.

Nico
-- 


From sean.mullan at oracle.com  Wed Nov 28 19:30:34 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 28 Nov 2018 14:30:34 -0500
Subject: RFR [12]: 8214140: Remove TLS v1 and v1.1 from SSLContext required
 algorithms
Message-ID: <583021c2-46c8-f7e9-b5ce-f2e185482dbe@oracle.com>

Please review this change to remove TLS v1 and v1.1 from the SE required 
algorithms for SSLContext. These TLS protocols have various weaknesses 
and are no longer recommended and are being phased out, and thus should 
be removed as requirements.

CSR: https://bugs.openjdk.java.net/browse/JDK-8214443
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8214140/webrev.00/

Thanks,
Sean


From xuelei.fan at oracle.com  Wed Nov 28 20:31:13 2018
From: xuelei.fan at oracle.com (Xue-Lei Fan)
Date: Wed, 28 Nov 2018 12:31:13 -0800
Subject: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still
 too slow
In-Reply-To: 
References: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com>
 <26F3E48B-FD8A-46AF-B054-749DD6CBD2EE@oracle.com>
 
Message-ID: <56387755-fb82-3285-7682-d48a77efd14e@oracle.com>

Do you know, is there any other way except Cleaner and finalize() to 
clean up the allocated resources?

I'm not very sure of the use of static Cleaner:
1. a daemon thread will run underlying.
2. the number of registered actions could be huge in some circumstances.

I'm not very sure if it could be a scalability bottleneck or not.

Xuelei


On 11/26/2018 5:33 PM, Weijun Wang wrote:
> Ping again
> 
>> On Nov 20, 2018, at 5:33 PM, Weijun Wang  wrote:
>>
>> Webrev updated at
>>
>>    https://cr.openjdk.java.net/~weijun/8210476/webrev.01/
>>
>> The only change is that there is a single Cleaner now for the whole PRNG class. Otherwise, each will maintain its own thread.
>>
>> Thanks
>> Max
>>
>>> On Nov 11, 2018, at 11:30 PM, Weijun Wang  wrote:
>>>
>>> Please take a review at
>>>
>>>   https://cr.openjdk.java.net/~weijun/8210476/webrev.00/
>>>
>>> Before this fix, every PRNG::nextBytes calls all of CryptAcquireContext, CryptGenRandom, and CryptReleaseContext. Now, CryptAcquireContext is called once in PRNG::new, and CryptReleaseContext is called by a Cleaner, and nextBytes only calls CryptGenRandom.
>>>
>>> I haven't read about thread-safety in any MS document, the current Windows-PRNG service is marked ThreadSafe=true (in SunMSCAPI.java). If we cannot be really sure, we can change it to false.
>>>
>>> I've downloaded nearly 1000 Mach5 runs of this test, the enhancement is so good that I adjusted the test to be stricter.
>>>
>>> 	Before	After
>>> 	------	-----
>>> Count	897	74
>>> Min	0.38	0.008
>>> Ave	0.97	0.011
>>> Max	5.81	0.021
>>>
>>> Please advise me if the following usage of Cleaner is correct because I really haven't observed the releaseContext method being called.
>>>
>>> +        Cleaner.create().register(this,
>>> +                () -> releaseContext(ctxt));
>>>
>>> Thanks
>>> Max
>>>
>>
> 


From xuelei.fan at oracle.com  Wed Nov 28 20:44:15 2018
From: xuelei.fan at oracle.com (Xue-Lei Fan)
Date: Wed, 28 Nov 2018 12:44:15 -0800
Subject: RFR [12]: 8214140: Remove TLS v1 and v1.1 from SSLContext
 required algorithms
In-Reply-To: <583021c2-46c8-f7e9-b5ce-f2e185482dbe@oracle.com>
References: <583021c2-46c8-f7e9-b5ce-f2e185482dbe@oracle.com>
Message-ID: <0b35cc44-57c1-91b4-a03d-79ca405c8b46@oracle.com>

Looks fine to me.  I added myself as Reviewer of the CSR.

Xuelei

On 11/28/2018 11:30 AM, Sean Mullan wrote:
> Please review this change to remove TLS v1 and v1.1 from the SE required 
> algorithms for SSLContext. These TLS protocols have various weaknesses 
> and are no longer recommended and are being phased out, and thus should 
> be removed as requirements.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8214443
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8214140/webrev.00/
> 
> Thanks,
> Sean


From sean.mullan at oracle.com  Wed Nov 28 22:35:20 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 28 Nov 2018 17:35:20 -0500
Subject: RFR: 8213952: Relax DNSName restriction as per RFC 1123
In-Reply-To: <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com>
References: <203198ea-c9e1-ea50-0869-88d5a14485ba@oracle.com>
 
 <4a0a8d4c-f8a3-c3c2-c8fb-67cabbe18dbb@oracle.com>
 
 <3ca19172-f2e3-b2d2-5b03-513a37a9ea53@oracle.com>
 
 <2485E367-942A-4BEA-91C0-7BEAC484C8BB@oracle.com>
 <9c313c47-7f42-1898-ddf9-bb5b37fffcaf@oracle.com>
Message-ID: <973bb6e9-c5a1-de53-c772-649164a10be7@oracle.com>

Just a nit:

77             throw new IOException("DNSNames with blank components are 
not permitted");
79             throw new IOException("DNSNames may not begin or end with 
a .");

Use the singular "DNSName" to be consistent with the other exception 
messages.

--Sean

On 11/23/18 11:45 AM, Se?n Coffey wrote:
> Thanks for your review Max. I've made the suggested edits.
> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v3/webrev/
> 
> I've also submitted a CSR for this change just to cover the behavioural 
> aspect of the edit. Will push if/once that's approved by CSR team.
> 
> Regards,
> Sean.
> 
> On 22/11/18 14:49, Weijun Wang wrote:
>> * DNSName.java:
>>
>> ?? 91???????????? if ((endIndex - startIndex) < 1)
>>
>> No need for inner parentheses.
>>
>> And, is there really a need to define alphaDigitsAndHyphen? How about 
>> just (== '-' || inside alphaDigits)?
>>
>> * DNSNameTest.java:
>>
>> Space cannot appear anywhere, please add a test case like "a c.com".
>>
>> BTW, I assume you want to reuse this test for other sub-tasks of 
>> JDK-8054380? I see the @summary is more general.
>>
>> No other comments.
>>
>> Thanks
>> Max
>>
>>> On Nov 22, 2018, at 12:51 AM, Se?n Coffey  
>>> wrote:
>>>
>>> p.s I've updated the testcase to test the IOException message for 
>>> presence of "DNSName". Webrev updated in place.
>>>
>>> Regards,
>>> Sean.
>>>
>>> On 21/11/18 15:42, Se?n Coffey wrote:
>>>> Thanks for the comments Bernd. Comments inline..
>>>>
>>>> On 16/11/18 21:27, Bernd Eckenfels wrote:
>>>>> Hello Sean,
>>>>>
>>>>> I was only looking at the inspected DNSName class, it still has 
>>>>> some variations (but start now with DNSNames which is good already):
>>>>>
>>>>> ?? 76 throw new IOException("DNSName must not be null or empty");
>>>>> ?? 78 throw new IOException("DNSNames or NameConstraints with blank 
>>>>> components are not permitted");
>>>>> ?? 80 throw new IOException("DNSNames or NameConstraints may not 
>>>>> begin or end with a .");
>>>>> ?? 92 throw new IOException("DNSName SubjectAltNames with empty 
>>>>> components are not permitted");
>>>>> ? 96 throw new IOException("DNSName components must begin with a 
>>>>> letter or digit");
>>>>> 101 throw new IOException("DNSName components must consist of 
>>>>> letters, digits, and hyphens");
>>>>>
>>>>> I did not check if those exceptions are catched and rethrown with 
>>>>> something like ?while validating the SubjectAltName Extension  
>>>>> of certificate ...?, in my experience it helps if you do 
>>>>> not have to find and review the actual certificates (in this case 
>>>>> it might not be a problem if SAN is only in the end entity). You 
>>>>> can probably remove ?or NameConstraints? and ?SubjectAltNames? from 
>>>>> lines 78-92 (this is good if DNsNa
>>>> Ok - I've cleaned up the exception messages on line 78, 80, 92.
>>>> webrev updated in place : 
>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/
>>>>
>>>>
>>>>> me applies to SAN or NameConstrained context and the validation 
>>>>> logic does not know ? so it?s not only more unified but also less 
>>>>> missleading)
>>>>>
>>>>> BTW: probably not inthe scope of this fix but a subtype for 
>>>>> validation errors which have getters for context/location and maybe 
>>>>> error code and getValue() would allow callers to print nicer 
>>>>> validation reports without relying on the message or Stacktraces.
>>>> That's a nice idea and one that should be followed up in separate 
>>>> enhancement. We could lean on the new `jdk.includeInExceptions` 
>>>> Security property which other component areas have started to use 
>>>> lately.
>>>>
>>>> e.g. https://bugs.openjdk.java.net/browse/JDK-8207768
>>>>
>>>> regards,
>>>> Sean.
>>>>> Gruss
>>>>> Bernd
>>>>> -- 
>>>>> http://bernd.eckenfels.net
>>>>> Von: Se?n Coffey 
>>>>> Gesendet: Freitag, November 16, 2018 5:15 PM
>>>>> An: Bernd Eckenfels; security-dev at openjdk.java.net
>>>>> Betreff: Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123
>>>>> Thanks for the comments Bernd. comments inline..
>>>>>
>>>>> On 16/11/18 12:40, Bernd Eckenfels wrote:
>>>>>> You could also add (a..b, false) and (.a, false), (a., false) to 
>>>>>> the testcases.
>>>>> good point. test updated.
>>>>>> I noticed that there are different types of Exception messages 
>>>>>> (DNS name, DNSName, DNS Name or name constrained, DNS name and 
>>>>>> SAN), would be good if all of them have the same keyword?
>>>>> I cleaned up some other references to DNSName in the 
>>>>> sun.security.x509 package. I'm not sure what classes you were 
>>>>> referencing the above examples from.
>>>>>
>>>>> new webrev : 
>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952.v2/webrev/
>>>>>
>>>>> regards,
>>>>> Sean.
>>>>>> Gruss
>>>>>> Bernd
>>>>>> -- 
>>>>>> http://bernd.eckenfels.net
>>>>>> Von: security-dev  im 
>>>>>> Auftrag von Se?n Coffey 
>>>>>> Gesendet: Freitag, November 16, 2018 12:25 PM
>>>>>> An: OpenJDK Dev list
>>>>>> Betreff: RFR: 8213952: Relax DNSName restriction as per RFC 1123
>>>>>> Looking to make an adjustment to DNSName constructor to help 
>>>>>> comply with
>>>>>> RFC 1123
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213952
>>>>>> http://cr.openjdk.java.net/~coffeys/webrev.8213952/webrev/
>>>>>>
>>>>>> regards,
>>>>>> Sean.
>>>>>>
>>>
> 


From ivan.gerasimov at oracle.com  Thu Nov 29 00:37:01 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 28 Nov 2018 16:37:01 -0800
Subject: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still
 too slow
In-Reply-To: 
References: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com>
 <26F3E48B-FD8A-46AF-B054-749DD6CBD2EE@oracle.com>
 
Message-ID: 

Hi Weijun!

A few comments.

1)

Since PRNG is Serializable, shouldn't `ctxt` be declared transient?


2)

The documentation of Cleaner [1] suggests not to use lambdas for 
cleaning actions, as it may accidentally capture a reference to the 
object  being cleaned.

[1] 
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/Cleaner.html 



3)

Do you know if it is true that the context handle might be used 
concurrently?

I couldn't find in the MSDN online documentation specific promises 
(there is a link to "Threading Issues with Cryptographic Service 
Providers" article, but the page is empty).

Would it make sense to maintain the only context handler in a static 
WeakReference field?

So that it is reused with all instances of PRNG and is cleared when the 
last instance of PRNG is gone.

Not sure if it is really necessary, as a normal application wouldn't 
probably need several instances of PRNG, but could prevent 
out-of-available-handles trouble in some extreme cases.


With kind regards,

Ivan.


On 11/26/18 5:33 PM, Weijun Wang wrote:
> Ping again
>
>> On Nov 20, 2018, at 5:33 PM, Weijun Wang  wrote:
>>
>> Webrev updated at
>>
>>    https://cr.openjdk.java.net/~weijun/8210476/webrev.01/
>>
>> The only change is that there is a single Cleaner now for the whole PRNG class. Otherwise, each will maintain its own thread.
>>
>> Thanks
>> Max
>>
>>> On Nov 11, 2018, at 11:30 PM, Weijun Wang  wrote:
>>>
>>> Please take a review at
>>>
>>>   https://cr.openjdk.java.net/~weijun/8210476/webrev.00/
>>>
>>> Before this fix, every PRNG::nextBytes calls all of CryptAcquireContext, CryptGenRandom, and CryptReleaseContext. Now, CryptAcquireContext is called once in PRNG::new, and CryptReleaseContext is called by a Cleaner, and nextBytes only calls CryptGenRandom.
>>>
>>> I haven't read about thread-safety in any MS document, the current Windows-PRNG service is marked ThreadSafe=true (in SunMSCAPI.java). If we cannot be really sure, we can change it to false.
>>>
>>> I've downloaded nearly 1000 Mach5 runs of this test, the enhancement is so good that I adjusted the test to be stricter.
>>>
>>> 	Before	After
>>> 	------	-----
>>> Count	897	74
>>> Min	0.38	0.008
>>> Ave	0.97	0.011
>>> Max	5.81	0.021
>>>
>>> Please advise me if the following usage of Cleaner is correct because I really haven't observed the releaseContext method being called.
>>>
>>> +        Cleaner.create().register(this,
>>> +                () -> releaseContext(ctxt));
>>>
>>> Thanks
>>> Max
>>>
>

-- 
With kind regards,
Ivan Gerasimov



From weijun.wang at oracle.com  Thu Nov 29 02:00:02 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 29 Nov 2018 10:00:02 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20181128175551.GA13826@twosigma.com>
References: 
 <20181128175551.GA13826@twosigma.com>
Message-ID: <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com>

Thanks a lot. Some comments inline.

> On Nov 29, 2018, at 1:55 AM, Nico Williams  wrote:
> 
> On Tue, Nov 20, 2018 at 09:56:36AM +0800, Weijun Wang wrote:
>> Please take a review at
>> 
>>   https://cr.openjdk.java.net/~weijun/6722928/webrev.01/
>> 
>> We ported [1] the native GSS bridge to Windows in JDK 11, but user still have
>> to download and install a native GSS-API library. This code change provides a
>> native GSS-API library inside JDK that can be used without setting the
>> "sun.security.jgss.lib" system property. It is based on Windows SSPI and now
>> only supports the client side using the default credentials.
>> 
>> No regression tests included. A Windows Active Directory server is needed.
> 
> This is my initial round of comments, and it's mostly high-level:
> 
> - Right now this looks very basic, and you won't get support for any
>   mechanism other than Kerberos.  That's fine though, as NTLM is dead,
>   you're willing to implement SPNEGO yourself, and there are no other
>   GSS mechs on Windows at this time (so far as I know).
> 
> - You're constructing SPNEGO tokens yourself.  I'll have to review that
>   very carefully.

I wrapped the outgoing token into NetTokenInit and extracted in incoming NegTokenTarg. This might fail if there are multiple rounds, but I think for kerberos it's OK.

> 
>   It would be better to let Windows provide SPNEGO though...

But it might promote NTLM.

> 
> - I've checked the DER-encoded OID constants.  They are correct.
> 
> - The name type OID for GSS_KRB5_NT_PRINCIPAL_NAME is not implemented but is
>   used elsewhere (e.g., in one GSSNameElement constructor).  Look for
>   GSSUtil.NT_GSS_KRB5_PRINCIPAL.
> 
> - gss_canonicalize_name() is not fully implemented.  This will be noticeable
>   to callers of GSSNameElement's getKrbName().  In particular, permissions
>   checks will fail (e.g., in GSSCredElement's doServicePermCheck(); similarly
>   in NativeGSSContext).
> 
>   At minimum you absolutely must parse generic GSS name type names into
>   Kerberos-style names (e.g., service at hostname -> service/hostname@).

OK.

> 
>   When an MN is displayed, you need to output the Kerberos-style name.
> 
>   (For those following along, "MN" means "mechanism name", which means
>   a GSSName / gss_name_t instance which is "canonical" and whose
>   display form will be mechanism-specific.  gss_canonicalize_name() is
>   supposed to output a "canonical" version of its input.)
> 
>   You'll also have to determine a realm for the parsed principal names.
> 
>   You won't need a realm for services.  Use an empty realm name for
>   services -- that's the Heimdal/MIT (and Solaris) convention for when
>   you're willing to rely on KDC referrals.
> 
>   (I would also urge you to NOT attempt any DNS canonicalization of
>   hostnames.  Let's not further spread that mistake.)

I didn't.

> 
>   For user principals it's trickier, and I think you might need some notion of
>   default realm, but a) maybe you can get away with an empty realm here on
>   Windows, b) I'm not sure where you'd a default realm on Windows.

I'm using the environment variable USERDNSDOMAIN now.

> 
>   What we do to determine the default realm for user names in our
>   patched version of Martin Rex's GSS->SSPI bridge is call
>   AcquireCredentialsHandle() or QueryCredentialsAttributesW() to
>   get/query the default credential and get its name, and from that the
>   realm, and we use that as the default realm.
> 
>   I'll have to look and see how we handle host-based service names
>   (Martin's original code has a domain_realm table in the registry, but
>   we removed all of that and rely on referrals instead.)
> 
> - If you can get Legal approval for including / distributing a fork of
>   Martin Rex's bridge, you'll get all of the above functionality and
>   also acceptor functionality.

Anyway, one can use his bridge with -Dsun.security.jgss.lib.

Thanks
Max

> 
> Nico
> -- 



From sha.jiang at oracle.com  Thu Nov 29 06:35:28 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Thu, 29 Nov 2018 14:35:28 +0800
Subject: RFR[12] JDK-8214459: NSS source should be removed
Message-ID: 

Hi,
The NSS 3.16 source in test/jdk/sun/security/pkcs11/nss/src is not 
needed anymore, so just remove it.

diff -r 1d520c376105 
test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz
Binary file 
test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz 
has changed
diff -r 1d520c376105 
test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256
--- 
a/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 
Wed Nov 28 18:16:39 2018 -0800
+++ /dev/null??? Thu Jan 01 00:00:00 1970 +0000
@@ -1,1 +0,0 @@
-9d23633683ab3cea14519a22a997bc7f5d8d9664b6342df492c194966184ce0d 
nss-3.16-with-nspr-4.10.4.tar.gz

Best regards,
John Jiang



From Nico.Williams at twosigma.com  Thu Nov 29 16:38:45 2018
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Thu, 29 Nov 2018 16:38:45 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com>
References: 
 <20181128175551.GA13826@twosigma.com>
 <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com>
Message-ID: <20181129163845.GB13826@twosigma.com>

On Thu, Nov 29, 2018 at 10:00:02AM +0800, Weijun Wang wrote:
> > - You're constructing SPNEGO tokens yourself.  I'll have to review that
> >   very carefully.
> 
> I wrapped the outgoing token into NetTokenInit and extracted in incoming
> NegTokenTarg. This might fail if there are multiple rounds, but I think for
> kerberos it's OK.

Kinda.  We'd like to add an option for multiple round trips to the
Kerberos mechanism to make it easier to recover from various errors.
You shouldn't assume that Kerberos will always be just one round trip.
Of course, the chances that MSFT will implement our multi-round trip
extension are probably so close to zero that you can get away with it :/

You could still support multiple round trips just fine, of course, but
how to test it?

One thing I've wanted to be able to do is to use concrete mechanisms via
the JGSS JNI native C interface, but SPNEGO being JGSS native Java
coded.  That would allow multiple native JNI C providers for different
mechanisms!  (I'm sure Martin Rex / SAP would love that.  They have a
GSS mechanism provider building toolkit that SAP customers use to build
many many custom mechanisms.)  The JGSS mechglue needs additional work
to make that possible, and if I remember correctly I left a few
breadcrumb comments about that in our contribution.

> >   It would be better to let Windows provide SPNEGO though...
> 
> But it might promote NTLM.

You can make sure it doesn't get used.

> >   (I would also urge you to NOT attempt any DNS canonicalization of
> >   hostnames.  Let's not further spread that mistake.)
> 
> I didn't.

I know.  I meant that when you get around to parsing generic syntax
names you might get tempted to do that, but if you are tempted, don't do
it :)

> >   For user principals it's trickier, and I think you might need some notion of
> >   default realm, but a) maybe you can get away with an empty realm here on
> >   Windows, b) I'm not sure where you'd a default realm on Windows.
> 
> I'm using the environment variable USERDNSDOMAIN now.

Sure, that works for now.

> >   What we do to determine the default realm for user names in our
> >   patched version of Martin Rex's GSS->SSPI bridge is call
> >   AcquireCredentialsHandle() or QueryCredentialsAttributesW() to
> >   get/query the default credential and get its name, and from that the
> >   realm, and we use that as the default realm.
> > 
> >   I'll have to look and see how we handle host-based service names
> >   (Martin's original code has a domain_realm table in the registry, but
> >   we removed all of that and rely on referrals instead.)
> > 
> > - If you can get Legal approval for including / distributing a fork of
> >   Martin Rex's bridge, you'll get all of the above functionality and
> >   also acceptor functionality.
> 
> Anyway, one can use his bridge with -Dsun.security.jgss.lib.

Indeed, one can!

That reminds me, we need to publish our changes to it.

A very cut-down (initiator-only) SSPI bridge will probably do for you
for now.  I wouldn't insist on acceptor functionality.

But it is important that the bridge work with JAAS.  Unfortunately a lot
of projects (many of them Apache ones) have cargo-culted the use of JGSS
w/ JAAS.  Indeed, that is the main motivator for our contribution: that
the use of JGSS w/ JAAS meant the native GSS providers couldn't be used
because GSSName is not a Principal and because there was no
GssLoginModule.

I will ask for permission to exfiltrate a handful of test programs we
use for testing basic JGSS w/ JAAS functionality.  You should test the
SSPI bridge with our patches and these programs.

Note though that we don't actually test with any policies that would
restrict what credentials the test program can use.  In general we find
JAAS to be pretty useless in a world with no applets -- no untrusted
code.  All the ServicePermission stuff is very Kerberos-specific and
there is no support for other mechanisms :(

Nico
-- 


From Nico.Williams at twosigma.com  Thu Nov 29 16:44:56 2018
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Thu, 29 Nov 2018 16:44:56 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com>
References: 
 <20181128175551.GA13826@twosigma.com>
 <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com>
Message-ID: <20181129164456.GC13826@twosigma.com>

On Thu, Nov 29, 2018 at 10:00:02AM +0800, Weijun Wang wrote:
> > - If you can get Legal approval for including / distributing a fork of
> >   Martin Rex's bridge, you'll get all of the above functionality and
> >   also acceptor functionality.
> 
> Anyway, one can use his bridge with -Dsun.security.jgss.lib.

Oh, speaking of this, we wanted to be able to use the registry for this
so our users don't have to specify the -Dsun.security.jgss.lib on the
command-line.  The JDK does have a generic interface to the registry,
the Preferences interface and its implementations, but because some
implementations have support for remote stores, it depends on all of
security/ being built first, which means I couldn't use it :/

There are places where there is native C/C++ code to use the registry
because of this, and I thought of copying that pattern.  But I never got
around to doing that.

It'd be nice if Preferences, or a cut-down version for private in-JDK
use, supported access to local prefs from security components of the
JDK.  I'm not entirely sure how to make that happen, but it would be a
good project for someone, I'm sure :)

Nico
-- 


From mbalao at redhat.com  Thu Nov 29 16:45:50 2018
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 29 Nov 2018 13:45:50 -0300
Subject: RFR 6913047: SunPKCS11 memory leak
In-Reply-To: 
References: 
 
 
 
 
 <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com>
 <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com>
 <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com>
 
 <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com>
 
 <566016d0-00ba-e938-693f-56948b9013da@oracle.com>
 
 
 
 <2ee1d1b8-91f5-f0c7-bd9f-31d7d20d472c@oracle.com>
 
Message-ID: 

Hi Valerie,

Webrev.15

 * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.15/
 * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.15.zip

Property to disable this fix has been renamed to
"sun.security.pkcs11.disableKeyExtraction", as requested in the CSR [1].

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8213430


From sean.mullan at oracle.com  Thu Nov 29 19:36:29 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 29 Nov 2018 14:36:29 -0500
Subject: RFR 8214179: Add groupname info into keytool -list and
 -genkeypair output
In-Reply-To: <9A04B026-DBE0-4E53-856F-584EAE5407F1@oracle.com>
References: 
 <9A04B026-DBE0-4E53-856F-584EAE5407F1@oracle.com>
Message-ID: 

On 11/26/18 8:30 PM, Weijun Wang wrote:
> Ping
> 
>> On Nov 21, 2018, at 9:56 PM, Weijun Wang  wrote:
>>
>> Please take a review at
>>
>>   https://cr.openjdk.java.net/~weijun/8214179/webrev.00/
>>
>> Before this change, `keytool -genkeypair -keyalg EC -groupname brainpoolP256r1` shows
>>
>>   Generating -1 bit EC key pair and self-signed certificate...
>>
>> With this change, the message becomes
>>
>>   Generating brainpoolP256r1 EC key pair and self-signed certificate...

For the above, I would prefer to also see the size of the key, like in 
the message below, ex:

Generating 256-bit EC (brainpoolP256r1) key pair and self-signed 
certificate...

>>
>> Also, `keytool -list -v` can show
>>
>>   Subject Public Key Algorithm: 256-bit EC(brainpoolP256r1) key

I would put a space between "EC" and "(".

--Sean

>>
>> Thanks
>> Max
>>
> 


From anthony.scarpino at oracle.com  Thu Nov 29 20:08:11 2018
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 29 Nov 2018 12:08:11 -0800
Subject: RFR(S)JDK-8214074: Ghash optimization using AVX instructions
In-Reply-To: <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com>
References: <6563F381B547594081EF9DE181D0791288A181E1@FMSMSX119.amr.corp.intel.com>
 
 <6563F381B547594081EF9DE181D0791288A19566@FMSMSX119.amr.corp.intel.com>
Message-ID: <6bc7947f-2f1c-4119-7b75-06e87dc6a57a@oracle.com>

[removed core-libs, added security-dev]

I'm fine with the jdk changes and solaris-sparc appears to work fine 
with the existing security and intrinsic tests.  I do not feel 
comfortable reviewing the hotspot changes, so either Vladimir or someone 
else from the hotspot team would need to look at it.

Tony

On 11/20/18 6:45 PM, Kamath, Smita wrote:
> Hi Tony,
> 
> Thanks for your comments.
> 
> 1)  This intrinsic is also used with solaris-sparc, has there been a sanity check by anyone to make sure this does not break the sparc intrinsic? It may work as the code is now since the sparc intrinsic will only use the first two longs in the subkeyHtbl.
> Would it be possible to help with this sanity check?  I don't have the required set-up to test this scenario.
> 
> 2) I have changed the code so that subkeyH corresponds to the first two entries of subkeyHtbl.  Please find the updated webrev link.
> 
> Bug link: https://bugs.openjdk.java.net/browse/JDK-8214074
> 
> Webrev link: http://cr.openjdk.java.net/~svkamath/ghash/webrev01/
> 
> Thanks and Regards,
> Smita
> 
> 
> 
> -----Original Message-----
> From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com]
> Sent: Tuesday, November 20, 2018 2:05 PM
> To: Kamath, Smita ; 'Vladimir Kozlov' 
> Cc: Viswanathan, Sandhya ; core-libs-dev at openjdk.java.net; hotspot compiler 
> Subject: Re: RFR(S)JDK-8214074: Ghash optimization using AVX instructions
> 
> On 11/19/18 12:50 PM, Kamath, Smita wrote:
>> Hi Vladimir,
>>
>> I'd like to contribute an optimization for GHASH Algorithm using AVX
>> Instructions. I have tested this optimization on SKX x86_64 platform
>> and it shows ~20-30% performance improvement for larger message sizes
>> (for example 8k).
>>
>> I, smita.kamath at intel.com  , Shay
>> Gueuron, (shay.gueron at intel.com )and
>> Regev Shemy (regev.shemy at intel.com ) are
>> contributors to this code.
>>
>> Link to Bug: https://bugs.openjdk.java.net/browse/JDK-8214074
>>
>> Link to webrev: http://cr.openjdk.java.net/~svkamath/ghash/webrev/
>>
>> For testing the implementation, I have executed TestAESMain.java. I
>> have executed Jtreg tests and tested this code on 64 bit Windows and
>> Linux platforms.
>>
>> Please review and let me know if you have any comments.
>>
>> Thanks and Regards,
>>
>> Smita
>>
> 
> Hi,
> 
> This intrinsic is also used with solaris-sparc, has there been a sanity check by anyone to make sure this does not break the sparc intrinsic?
> It may work as the code is now since the sparc intrinsic will only use the first two longs in the subkeyHtbl.
> 
> In that same idea, have you consider combining the subkeyH to be the first two of subkeyHtbl for the non-avx operations?  It would eliminate an extra two longs per instance.
> 
> Tony
> 



From weijun.wang at oracle.com  Fri Nov 30 02:12:12 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 30 Nov 2018 10:12:12 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20181129164456.GC13826@twosigma.com>
References: 
 <20181128175551.GA13826@twosigma.com>
 <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com>
 <20181129164456.GC13826@twosigma.com>
Message-ID: 

Nowadays whenever we introduce a new security-related property, we are thinking about whether it can also be both a system property and a security property. If so, it can be set "permanently" in conf/security/java.security or "temporarily" as a system property. See https://hg.openjdk.java.net/jdk/jdk/file/d488477865c0/src/java.base/share/classes/sun/security/util/SecurityProperties.java#l45.

--Max

> On Nov 30, 2018, at 12:44 AM, Nico Williams  wrote:
> 
> On Thu, Nov 29, 2018 at 10:00:02AM +0800, Weijun Wang wrote:
>>> - If you can get Legal approval for including / distributing a fork of
>>>  Martin Rex's bridge, you'll get all of the above functionality and
>>>  also acceptor functionality.
>> 
>> Anyway, one can use his bridge with -Dsun.security.jgss.lib.
> 
> Oh, speaking of this, we wanted to be able to use the registry for this
> so our users don't have to specify the -Dsun.security.jgss.lib on the
> command-line.  The JDK does have a generic interface to the registry,
> the Preferences interface and its implementations, but because some
> implementations have support for remote stores, it depends on all of
> security/ being built first, which means I couldn't use it :/
> 
> There are places where there is native C/C++ code to use the registry
> because of this, and I thought of copying that pattern.  But I never got
> around to doing that.
> 
> It'd be nice if Preferences, or a cut-down version for private in-JDK
> use, supported access to local prefs from security components of the
> JDK.  I'm not entirely sure how to make that happen, but it would be a
> good project for someone, I'm sure :)
> 
> Nico
> -- 



From weijun.wang at oracle.com  Fri Nov 30 02:19:14 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 30 Nov 2018 10:19:14 +0800
Subject: RFR 8214179: Add groupname info into keytool -list and
 -genkeypair output
In-Reply-To: 
References: 
 <9A04B026-DBE0-4E53-856F-584EAE5407F1@oracle.com>
 
Message-ID: <006B5616-9535-4BCD-9E5A-D55981AC14F5@oracle.com>

Webrev updated at

  https://cr.openjdk.java.net/~weijun/8214179/webrev.01/

Very glad to remove the change of Resources.java.

Thanks
Max

> On Nov 30, 2018, at 3:36 AM, Sean Mullan  wrote:
> 
> On 11/26/18 8:30 PM, Weijun Wang wrote:
>> Ping
>>> On Nov 21, 2018, at 9:56 PM, Weijun Wang  wrote:
>>> 
>>> Please take a review at
>>> 
>>>  https://cr.openjdk.java.net/~weijun/8214179/webrev.00/
>>> 
>>> Before this change, `keytool -genkeypair -keyalg EC -groupname brainpoolP256r1` shows
>>> 
>>>  Generating -1 bit EC key pair and self-signed certificate...
>>> 
>>> With this change, the message becomes
>>> 
>>>  Generating brainpoolP256r1 EC key pair and self-signed certificate...
> 
> For the above, I would prefer to also see the size of the key, like in the message below, ex:
> 
> Generating 256-bit EC (brainpoolP256r1) key pair and self-signed certificate...
> 
>>> 
>>> Also, `keytool -list -v` can show
>>> 
>>>  Subject Public Key Algorithm: 256-bit EC(brainpoolP256r1) key
> 
> I would put a space between "EC" and "(".
> 
> --Sean
> 
>>> 
>>> Thanks
>>> Max
>>> 



From valerie.peng at oracle.com  Fri Nov 30 02:28:39 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 29 Nov 2018 18:28:39 -0800
Subject: RFR[12] JDK-8214459: NSS source should be removed
In-Reply-To: 
References: 
Message-ID: <93a9d031-a1ff-4092-b496-6231a09bbf6c@oracle.com>

I assume not just the two files, their containing src directory will be 
removed, right?

Valerie

On 11/28/2018 10:35 PM, sha.jiang at oracle.com wrote:
> Hi,
> The NSS 3.16 source in test/jdk/sun/security/pkcs11/nss/src is not 
> needed anymore, so just remove it.
>
> diff -r 1d520c376105 
> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz
> Binary file 
> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz 
> has changed
> diff -r 1d520c376105 
> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256
> --- 
> a/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 
> Wed Nov 28 18:16:39 2018 -0800
> +++ /dev/null??? Thu Jan 01 00:00:00 1970 +0000
> @@ -1,1 +0,0 @@
> -9d23633683ab3cea14519a22a997bc7f5d8d9664b6342df492c194966184ce0d 
> nss-3.16-with-nspr-4.10.4.tar.gz
>
> Best regards,
> John Jiang
>


From sha.jiang at oracle.com  Fri Nov 30 02:49:09 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Fri, 30 Nov 2018 10:49:09 +0800
Subject: RFR[12] JDK-8214459: NSS source should be removed
In-Reply-To: <93a9d031-a1ff-4092-b496-6231a09bbf6c@oracle.com>
References: 
 <93a9d031-a1ff-4092-b496-6231a09bbf6c@oracle.com>
Message-ID: <7f3ed67c-9284-5436-591a-c0a009c5a0ef@oracle.com>

Hi Valerie,

On 2018/11/30 10:28, Valerie Peng wrote:
> I assume not just the two files, their containing src directory will 
> be removed, right?

Yes. This directory also will be removed.

Best regards,
John Jiang

>
> Valerie
>
> On 11/28/2018 10:35 PM, sha.jiang at oracle.com wrote:
>> Hi,
>> The NSS 3.16 source in test/jdk/sun/security/pkcs11/nss/src is not 
>> needed anymore, so just remove it.
>>
>> diff -r 1d520c376105 
>> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz
>> Binary file 
>> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz 
>> has changed
>> diff -r 1d520c376105 
>> test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256
>> --- 
>> a/test/jdk/sun/security/pkcs11/nss/src/nss-3.16-with-nspr-4.10.4.tar.gz.sha256 
>> Wed Nov 28 18:16:39 2018 -0800
>> +++ /dev/null??? Thu Jan 01 00:00:00 1970 +0000
>> @@ -1,1 +0,0 @@
>> -9d23633683ab3cea14519a22a997bc7f5d8d9664b6342df492c194966184ce0d 
>> nss-3.16-with-nspr-4.10.4.tar.gz
>>
>> Best regards,
>> John Jiang
>>
>


From weijun.wang at oracle.com  Fri Nov 30 11:47:44 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 30 Nov 2018 19:47:44 +0800
Subject: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still
 too slow
In-Reply-To: <56387755-fb82-3285-7682-d48a77efd14e@oracle.com>
References: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com>
 <26F3E48B-FD8A-46AF-B054-749DD6CBD2EE@oracle.com>
 
 <56387755-fb82-3285-7682-d48a77efd14e@oracle.com>
Message-ID: <5C26D428-73D3-4595-9534-5AC079FBE8E5@oracle.com>

Hi Xuelei, and Ivan who replied in another mail,

> On Nov 29, 2018, at 4:31 AM, Xue-Lei Fan  wrote:
> 
> Do you know, is there any other way except Cleaner and finalize() to clean up the allocated resources?

I don't know any other automatic mechanisms. There is AutoClosable but SecureRandom has not implemented it and we cannot expect people using try-with-resources on it.

> 
> I'm not very sure of the use of static Cleaner:
> 1. a daemon thread will run underlying.
> 2. the number of registered actions could be huge in some circumstances.

Anyway, I think any fix that reuses the context is to change a time performance issue into a resource performance issue because we cannot precisely control the resource cleanup.

I don't have enough data on how often people use Windows-PRNG, how many objects they create, how many nextBytes they call on a single object, and how they use it in multiple threads. So it's quite clueless to determine which solution is the best.

Both this bug and the previous one (JDK-6449335) are not reported by external customers. Therefore I prefer retargeting the bug to the next release and problem list the test at the moment. In the last 1700 mach5 jobs with this test, there were 4 timeouts.

Thanks
Max

p.s. We might reimplement using CNG but CNG also has its own problem (no easy way to implement setSeed).

> 
> I'm not very sure if it could be a scalability bottleneck or not.
> 
> Xuelei
> 
> 
> On 11/26/2018 5:33 PM, Weijun Wang wrote:
>> Ping again
>>> On Nov 20, 2018, at 5:33 PM, Weijun Wang  wrote:
>>> 
>>> Webrev updated at
>>> 
>>>   https://cr.openjdk.java.net/~weijun/8210476/webrev.01/
>>> 
>>> The only change is that there is a single Cleaner now for the whole PRNG class. Otherwise, each will maintain its own thread.
>>> 
>>> Thanks
>>> Max
>>> 
>>>> On Nov 11, 2018, at 11:30 PM, Weijun Wang  wrote:
>>>> 
>>>> Please take a review at
>>>> 
>>>>  https://cr.openjdk.java.net/~weijun/8210476/webrev.00/
>>>> 
>>>> Before this fix, every PRNG::nextBytes calls all of CryptAcquireContext, CryptGenRandom, and CryptReleaseContext. Now, CryptAcquireContext is called once in PRNG::new, and CryptReleaseContext is called by a Cleaner, and nextBytes only calls CryptGenRandom.
>>>> 
>>>> I haven't read about thread-safety in any MS document, the current Windows-PRNG service is marked ThreadSafe=true (in SunMSCAPI.java). If we cannot be really sure, we can change it to false.
>>>> 
>>>> I've downloaded nearly 1000 Mach5 runs of this test, the enhancement is so good that I adjusted the test to be stricter.
>>>> 
>>>> 	Before	After
>>>> 	------	-----
>>>> Count	897	74
>>>> Min	0.38	0.008
>>>> Ave	0.97	0.011
>>>> Max	5.81	0.021
>>>> 
>>>> Please advise me if the following usage of Cleaner is correct because I really haven't observed the releaseContext method being called.
>>>> 
>>>> +        Cleaner.create().register(this,
>>>> +                () -> releaseContext(ctxt));
>>>> 
>>>> Thanks
>>>> Max
>>>> 
>>> 



From aph at redhat.com  Fri Nov 30 16:10:09 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 30 Nov 2018 16:10:09 +0000
Subject: Problems with AES-GCM native acceleration
In-Reply-To: 
References: 
 <92a16009b9e047eacf102b006bc0612bac4a2cfb.camel@redhat.com>
 <1b1fe9e4-ad71-7d48-13eb-48dbe267962e@oracle.com>
 <864a763d-0d67-d894-234c-fbbef78e0320@oracle.com>
 
 
Message-ID: 

On 11/21/18 5:37 PM, Andrew Haley wrote:
> On 11/15/18 10:42 AM, Gidon Gershinsky wrote:
>> Having the decryption optimized in the HotSpot engine would be ideal.
> 
> I agree with you. I did a few experiments, and it can take a very
> long time for C2 compilation to kick in, especially because GCM is
> glacially slow until the intrinsics are used.
> 
> I think this would be a generally useful enhancement to HotSpot,
> and I'm kicking around an experimental patch which adds the
> intrinsics to c1 and the interpreter.

There's a proof-of-concept patch at http://cr.openjdk.java.net/~aph/gctr/
It's all rather hacky but it works.

The patch is rather more complicated than I would have liked. We
could simplify it somewhat by getting rid of the C1 intrinsic, and
instead making C1 call the interpreter implementation.

There also a jmh benchmark in that directory. Test results for 1Mb
look like this:

Interp:

Benchmark              Mode  Cnt     Score   Error  Units
AESGCMUpdateAAD2.test  avgt    5  1426.275 ? 8.778  us/op

C1:

Benchmark              Mode  Cnt     Score   Error  Units
AESGCMUpdateAAD2.test  avgt    5  1359.367 ? 8.196  us/op

C2:

Benchmark              Mode  Cnt     Score    Error  Units
AESGCMUpdateAAD2.test  avgt    5  1333.863 ? 18.385  us/op

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From Nico.Williams at twosigma.com  Fri Nov 30 16:37:56 2018
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Fri, 30 Nov 2018 16:37:56 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: 
References: 
 <20181128175551.GA13826@twosigma.com>
 <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com>
 <20181129164456.GC13826@twosigma.com>
 
Message-ID: <20181130163756.GD13826@twosigma.com>

On Fri, Nov 30, 2018 at 10:12:12AM +0800, Weijun Wang wrote:
> Nowadays whenever we introduce a new security-related property, we are
> thinking about whether it can also be both a system property and a
> security property. If so, it can be set "permanently" in
> conf/security/java.security or "temporarily" as a system property. See
> https://hg.openjdk.java.net/jdk/jdk/file/d488477865c0/src/java.base/share/classes/sun/security/util/SecurityProperties.java#l45.

I don't see where that allows something like this property to be set via
some configuration file in /etc or via the registry on Windows.

Even if it does allow setting this via a config file in /etc, on Windows
it would be really nice to be able to use the registry.  E.g., because
there's better tooling for managing the registry than for managing
config files.

More generally, and to avoid unnecessary duplication, it'd be really
nice to be able to use Preferences, obviously in a cut-down way such
that only local files or the registry can be used.  I understand that
implementing such a thing for local XML files would be... difficult.  An
alternative might be to permit the ciruclar dependency, resolve it
somehow in the build system (e.g., move the Preferences interface /
abstract class into security but leave the implementations in utils),
and disallow access to anything other than local files and the registry
at run-time when invoked from security classes (to avoid infinite
loops) (e.g., using thread-local state).

IMO that would provide an excellent opportunity to improve usability
while also allowing the removal of all the registry access JNI code
outside Preferences.

Nico
-- 


From xuelei.fan at oracle.com  Fri Nov 30 18:03:15 2018
From: xuelei.fan at oracle.com (Xue-Lei Fan)
Date: Fri, 30 Nov 2018 10:03:15 -0800
Subject: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still
 too slow
In-Reply-To: <5C26D428-73D3-4595-9534-5AC079FBE8E5@oracle.com>
References: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com>
 <26F3E48B-FD8A-46AF-B054-749DD6CBD2EE@oracle.com>
 
 <56387755-fb82-3285-7682-d48a77efd14e@oracle.com>
 <5C26D428-73D3-4595-9534-5AC079FBE8E5@oracle.com>
Message-ID: 

Hi Weijun,

I think you made a significant improvement of the performance, with less 
timing and resources.  I don't think my concerns are strong enough to 
prevent this fix from moving forward.

I'm fine with your update.  You can move forward as it is, or using 
finalize() instead.

For my concerns, if you go with Cleaner, we can open a new RFE for the 
tracking if we have a good idea in the future.

Thanks,
Xuelei

On 11/30/2018 3:47 AM, Weijun Wang wrote:
> Hi Xuelei, and Ivan who replied in another mail,
> 
>> On Nov 29, 2018, at 4:31 AM, Xue-Lei Fan  wrote:
>>
>> Do you know, is there any other way except Cleaner and finalize() to clean up the allocated resources?
> 
> I don't know any other automatic mechanisms. There is AutoClosable but SecureRandom has not implemented it and we cannot expect people using try-with-resources on it.
> 
>>
>> I'm not very sure of the use of static Cleaner:
>> 1. a daemon thread will run underlying.
>> 2. the number of registered actions could be huge in some circumstances.
> 
> Anyway, I think any fix that reuses the context is to change a time performance issue into a resource performance issue because we cannot precisely control the resource cleanup.
> 
> I don't have enough data on how often people use Windows-PRNG, how many objects they create, how many nextBytes they call on a single object, and how they use it in multiple threads. So it's quite clueless to determine which solution is the best.
> 
> Both this bug and the previous one (JDK-6449335) are not reported by external customers. Therefore I prefer retargeting the bug to the next release and problem list the test at the moment. In the last 1700 mach5 jobs with this test, there were 4 timeouts.
> 
> Thanks
> Max
> 
> p.s. We might reimplement using CNG but CNG also has its own problem (no easy way to implement setSeed).
> 
>>
>> I'm not very sure if it could be a scalability bottleneck or not.
>>
>> Xuelei
>>
>>
>> On 11/26/2018 5:33 PM, Weijun Wang wrote:
>>> Ping again
>>>> On Nov 20, 2018, at 5:33 PM, Weijun Wang  wrote:
>>>>
>>>> Webrev updated at
>>>>
>>>>    https://cr.openjdk.java.net/~weijun/8210476/webrev.01/
>>>>
>>>> The only change is that there is a single Cleaner now for the whole PRNG class. Otherwise, each will maintain its own thread.
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>> On Nov 11, 2018, at 11:30 PM, Weijun Wang  wrote:
>>>>>
>>>>> Please take a review at
>>>>>
>>>>>   https://cr.openjdk.java.net/~weijun/8210476/webrev.00/
>>>>>
>>>>> Before this fix, every PRNG::nextBytes calls all of CryptAcquireContext, CryptGenRandom, and CryptReleaseContext. Now, CryptAcquireContext is called once in PRNG::new, and CryptReleaseContext is called by a Cleaner, and nextBytes only calls CryptGenRandom.
>>>>>
>>>>> I haven't read about thread-safety in any MS document, the current Windows-PRNG service is marked ThreadSafe=true (in SunMSCAPI.java). If we cannot be really sure, we can change it to false.
>>>>>
>>>>> I've downloaded nearly 1000 Mach5 runs of this test, the enhancement is so good that I adjusted the test to be stricter.
>>>>>
>>>>> 	Before	After
>>>>> 	------	-----
>>>>> Count	897	74
>>>>> Min	0.38	0.008
>>>>> Ave	0.97	0.011
>>>>> Max	5.81	0.021
>>>>>
>>>>> Please advise me if the following usage of Cleaner is correct because I really haven't observed the releaseContext method being called.
>>>>>
>>>>> +        Cleaner.create().register(this,
>>>>> +                () -> releaseContext(ctxt));
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>
> 


From Roger.Riggs at oracle.com  Fri Nov 30 18:43:58 2018
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 30 Nov 2018 13:43:58 -0500
Subject: RFR 8210476: sun/security/mscapi/PrngSlow.java fails with Still
 too slow
In-Reply-To: 
References: <3E4E161C-F53C-4E09-B69A-50C0F74C2204@oracle.com>
 <26F3E48B-FD8A-46AF-B054-749DD6CBD2EE@oracle.com>
 
 <56387755-fb82-3285-7682-d48a77efd14e@oracle.com>
 <5C26D428-73D3-4595-9534-5AC079FBE8E5@oracle.com>
 
Message-ID: 

Hi,

The Cleaner approach should be reasonable and we'd like to avoid
introducing new uses of finalize that will need to be removed later.
Tracking it to see if there are any issues is a good idea.

Thanks, Roger


On 11/30/2018 01:03 PM, Xue-Lei Fan wrote:
> Hi Weijun,
>
> I think you made a significant improvement of the performance, with 
> less timing and resources.? I don't think my concerns are strong 
> enough to prevent this fix from moving forward.
>
> I'm fine with your update.? You can move forward as it is, or using 
> finalize() instead.
>
> For my concerns, if you go with Cleaner, we can open a new RFE for the 
> tracking if we have a good idea in the future.
>
> Thanks,
> Xuelei
>
> On 11/30/2018 3:47 AM, Weijun Wang wrote:
>> Hi Xuelei, and Ivan who replied in another mail,
>>
>>> On Nov 29, 2018, at 4:31 AM, Xue-Lei Fan  wrote:
>>>
>>> Do you know, is there any other way except Cleaner and finalize() to 
>>> clean up the allocated resources?
>>
>> I don't know any other automatic mechanisms. There is AutoClosable 
>> but SecureRandom has not implemented it and we cannot expect people 
>> using try-with-resources on it.
>>
>>>
>>> I'm not very sure of the use of static Cleaner:
>>> 1. a daemon thread will run underlying.
>>> 2. the number of registered actions could be huge in some 
>>> circumstances.
>>
>> Anyway, I think any fix that reuses the context is to change a time 
>> performance issue into a resource performance issue because we cannot 
>> precisely control the resource cleanup.
>>
>> I don't have enough data on how often people use Windows-PRNG, how 
>> many objects they create, how many nextBytes they call on a single 
>> object, and how they use it in multiple threads. So it's quite 
>> clueless to determine which solution is the best.
>>
>> Both this bug and the previous one (JDK-6449335) are not reported by 
>> external customers. Therefore I prefer retargeting the bug to the 
>> next release and problem list the test at the moment. In the last 
>> 1700 mach5 jobs with this test, there were 4 timeouts.
>>
>> Thanks
>> Max
>>
>> p.s. We might reimplement using CNG but CNG also has its own problem 
>> (no easy way to implement setSeed).
>>
>>>
>>> I'm not very sure if it could be a scalability bottleneck or not.
>>>
>>> Xuelei
>>>
>>>
>>> On 11/26/2018 5:33 PM, Weijun Wang wrote:
>>>> Ping again
>>>>> On Nov 20, 2018, at 5:33 PM, Weijun Wang  
>>>>> wrote:
>>>>>
>>>>> Webrev updated at
>>>>>
>>>>> ?? https://cr.openjdk.java.net/~weijun/8210476/webrev.01/
>>>>>
>>>>> The only change is that there is a single Cleaner now for the 
>>>>> whole PRNG class. Otherwise, each will maintain its own thread.
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>>> On Nov 11, 2018, at 11:30 PM, Weijun Wang 
>>>>>>  wrote:
>>>>>>
>>>>>> Please take a review at
>>>>>>
>>>>>> ? https://cr.openjdk.java.net/~weijun/8210476/webrev.00/
>>>>>>
>>>>>> Before this fix, every PRNG::nextBytes calls all of 
>>>>>> CryptAcquireContext, CryptGenRandom, and CryptReleaseContext. 
>>>>>> Now, CryptAcquireContext is called once in PRNG::new, and 
>>>>>> CryptReleaseContext is called by a Cleaner, and nextBytes only 
>>>>>> calls CryptGenRandom.
>>>>>>
>>>>>> I haven't read about thread-safety in any MS document, the 
>>>>>> current Windows-PRNG service is marked ThreadSafe=true (in 
>>>>>> SunMSCAPI.java). If we cannot be really sure, we can change it to 
>>>>>> false.
>>>>>>
>>>>>> I've downloaded nearly 1000 Mach5 runs of this test, the 
>>>>>> enhancement is so good that I adjusted the test to be stricter.
>>>>>>
>>>>>> ????Before??? After
>>>>>> ????------??? -----
>>>>>> Count??? 897??? 74
>>>>>> Min??? 0.38??? 0.008
>>>>>> Ave??? 0.97??? 0.011
>>>>>> Max??? 5.81??? 0.021
>>>>>>
>>>>>> Please advise me if the following usage of Cleaner is correct 
>>>>>> because I really haven't observed the releaseContext method being 
>>>>>> called.
>>>>>>
>>>>>> +??????? Cleaner.create().register(this,
>>>>>> +??????????????? () -> releaseContext(ctxt));
>>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>>
>>>>>
>>



From adam.petcher at oracle.com  Fri Nov 30 19:59:19 2018
From: adam.petcher at oracle.com (Adam Petcher)
Date: Fri, 30 Nov 2018 14:59:19 -0500
Subject: RFR 8208648: ECC Field Arithmetic Enhancements
Message-ID: 

JBS: https://bugs.openjdk.java.net/browse/JDK-8208648
webrev: http://cr.openjdk.java.net/~apetcher/8208648/webrev.00/

This changeset includes the enhancements to the finite field arithmetic 
library that are necessary for the new implementation of ECDSA and 
ECDH[1]. The actual ECDH and ECDSA changes will be reviewed separately. 
Please see the JBS tickets for more information about the changes, and 
here are some additional notes:

1) This change includes a code generator that produces finite field 
implementations. The generated code is included in the review, and it 
will be checked in to the repository with a comment indicating that it 
is generated and should not be modified directly. Another option is to 
put the code generator into the build process so the generated code does 
not need to be checked in, but it's not clear whether this is a better 
option.
2) Reviewing every line of the generated code is probably not necessary, 
and it is probably better to focus on the code generator itself 
(Fieldgen.jsh). Of course, it is probably a good idea to review the 
generated code for its structure and for opportunities for improvement.



[1] https://bugs.openjdk.java.net/browse/JDK-8208698



From adam.petcher at oracle.com  Fri Nov 30 20:01:20 2018
From: adam.petcher at oracle.com (Adam Petcher)
Date: Fri, 30 Nov 2018 15:01:20 -0500
Subject: RFR 8208698: Improved ECC Implementation
Message-ID: 

JBS: https://bugs.openjdk.java.net/browse/JDK-8208698
webrev: http://cr.openjdk.java.net/~apetcher/8208698/webrev.00/

This is a re-implementation of ECDH and ECDSA that is designed to be 
resilient against side-channel attacks. The implementation only supports 
the 256-bit, 384-bit, and 521-bit NIST curves, and only key pair 
generation, key agreement, and signature is implemented. For other 
curves/algorithms, the existing native ECC implementation will be used. 
This change depends on a separate change (reviewed concurrently) that 
enhances the finite field arithmetic library. The implementation is 
intended to follow the recommendations in FIPS 186-4 and SP 800-56A. 
More information on the techniques used can be found in the JBS ticket.

There is no new signature verification implementation, because signature 
verification typically does not involve secret inputs. If anyone has any 
desire for branchless signature verification, please let me know.

I tested this change by running all the existing regression tests, and 
by checking it against some additional test vectors. I've done some 
initial benchmarking on two platforms: a Linux VM with a Skylake CPU, 
and a Macbook with a Haswell CPU. In general, the performance of the new 
implementation is 20-30% faster than the existing native implementation. 
Though the performance of the 521-bit curve is actually around 10% 
slower on Mac/Haswell. I think this regression is acceptable, because 
the 521-bit curve is not used as much as the others, and it is only used 
if lower performance is acceptable. I plan to do some additional 
benchmarking while the review is in progress.

This change includes a new (internal) class hierarchy for EC points in 
various coordinate systems. It may seem a little over-complicated, since 
the only type of point used in the implementation (other than affine) is 
ProjectivePoint. But it is common for different curves to use different 
coordinate systems, even within the same ECC algorithm/implementation. 
The EdDSA prototype also uses these point classes, and it uses extended 
homogeneous coordinates, in addition to projective coordinates.



From sean.mullan at oracle.com  Fri Nov 30 21:28:29 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 30 Nov 2018 16:28:29 -0500
Subject: RFR 8214179: Add groupname info into keytool -list and
 -genkeypair output
In-Reply-To: <006B5616-9535-4BCD-9E5A-D55981AC14F5@oracle.com>
References: 
 <9A04B026-DBE0-4E53-856F-584EAE5407F1@oracle.com>
 
 <006B5616-9535-4BCD-9E5A-D55981AC14F5@oracle.com>
Message-ID: <2524552f-8515-b62f-c020-d4d7bd25e9cf@oracle.com>

Looks good.

--Sean

On 11/29/18 9:19 PM, Weijun Wang wrote:
> Webrev updated at
> 
>    https://cr.openjdk.java.net/~weijun/8214179/webrev.01/
> 
> Very glad to remove the change of Resources.java.
> 
> Thanks
> Max
> 
>> On Nov 30, 2018, at 3:36 AM, Sean Mullan  wrote:
>>
>> On 11/26/18 8:30 PM, Weijun Wang wrote:
>>> Ping
>>>> On Nov 21, 2018, at 9:56 PM, Weijun Wang  wrote:
>>>>
>>>> Please take a review at
>>>>
>>>>   https://cr.openjdk.java.net/~weijun/8214179/webrev.00/
>>>>
>>>> Before this change, `keytool -genkeypair -keyalg EC -groupname brainpoolP256r1` shows
>>>>
>>>>   Generating -1 bit EC key pair and self-signed certificate...
>>>>
>>>> With this change, the message becomes
>>>>
>>>>   Generating brainpoolP256r1 EC key pair and self-signed certificate...
>>
>> For the above, I would prefer to also see the size of the key, like in the message below, ex:
>>
>> Generating 256-bit EC (brainpoolP256r1) key pair and self-signed certificate...
>>
>>>>
>>>> Also, `keytool -list -v` can show
>>>>
>>>>   Subject Public Key Algorithm: 256-bit EC(brainpoolP256r1) key
>>
>> I would put a space between "EC" and "(".
>>
>> --Sean
>>
>>>>
>>>> Thanks
>>>> Max
>>>>
>