From bradford.wetmore at oracle.com Thu Jan 1 00:11:26 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 31 Dec 2014 16:11:26 -0800 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <54A20475.3040206@oracle.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A20475.3040206@oracle.com> Message-ID: <54A490AE.5090103@oracle.com> Just to followup, I've analyzed the whole PIT run. The second one's call stack is identical to: JDK-8067344: Adjust java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent changes in java.lang.invoke So, really the only problem is the use of Asserts in your test case. Brad >>> Looks like you have a committer status, will you be pushing this? >> >> I can, yes. As soon as we clear-out the remaining questions, right? > > Yes. The comments below are minor and shouldn't need another review > cycle. I have started a JPRT job for you, I'll run it through "core" > target which will give us: > > jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, jdk_security*, > jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools. > > Anything else? I'm off tomorrow, I should have full results Wed. > > Here are the preliminary results for the jobs that have finished. > jdk.testlibrary.Asserts is causing compilation errors, additional > comments below: > > /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:33: > error: package jdk.testlibrary does not exist > import static jdk.testlibrary.Asserts.*; > ^ > /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:52: > error: cannot find symbol > assertEquals(bytes.length, nread, "short read"); > ^ > symbol: method assertEquals(int,int,String) > location: class FileInputStreamPoolTest > /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:53: > error: cannot find symbol > assertTrue(Arrays.equals(readBytes, bytes), > ^ > symbol: method assertTrue(boolean,String) > location: class FileInputStreamPoolTest > 3 errors > > TEST RESULT: Failed. Compilation failed: Compilation failed > > I'm also getting failures in the following test. I unfortunately have > to leave now, so don't have time to look at this. But it did mention > "seed" so I'm mentioning it here. > > TEST: java/lang/invoke/LFCaching/LFGarbageCollectedTest.java > > ACTION: main -- Failed. Execution failed: `main' threw exception: > java.lang.Error: 36 of 39 test cases FAILED! Rerun the test with the > same "-Dseed=" option as in the log file! > REASON: User specified action: run main/othervm LFGarbageCollectedTest > TIME: 213.406 seconds > messages: > command: main LFGarbageCollectedTest > reason: User specified action: run main/othervm LFGarbageCollectedTest > elapsed time (seconds): 213.406 > STDOUT: > -Dseed=6102311124531075592 > -DtestLimit=2000 > Number of iterations according to -DtestLimit is 153 (1989 cases) > Code cache size is 251658240 bytes > Non-profiled code cache size is 123058253 bytes > Number of iterations limited by code cache size is 84 (1092 cases) > Number of iterations limited by non-profiled code cache size is 41 (533 > cases) > Number of iterations is set to 41 (533 cases) > Not enough time to continue execution. Interrupted. > STDERR: > Iteration 0: > Tested LF caching feature with MethodHandles.foldArguments method. > java.lang.AssertionError: Error: Lambda form is not garbage collected > at LFGarbageCollectedTest.doTest(LFGarbageCollectedTest.java:81) > at > LambdaFormTestCase$TestRun.doIteration(LambdaFormTestCase.java:139) > at LambdaFormTestCase$$Lambda$2/5042013.call(Unknown Source) > at > jdk.testlibrary.TimeLimitedRunner.call(TimeLimitedRunner.java:71) > at LambdaFormTestCase.runTests(LambdaFormTestCase.java:201) > at LFGarbageCollectedTest.main(LFGarbageCollectedTest.java:105) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) From peter.levart at gmail.com Thu Jan 1 19:21:48 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 01 Jan 2015 20:21:48 +0100 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <54A17899.4060304@oracle.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A119FF.4060103@oracle.com> <54A122AA.3010004@gmail.com> <54A17899.4060304@oracle.com> Message-ID: <54A59E4C.1050603@gmail.com> On 12/29/2014 04:51 PM, Alan Bateman wrote: > On 29/12/2014 09:45, Peter Levart wrote: >> >> Thanks for looking at this, Alan. >> >> You're right about File.getCanonicalFile(). It already checks read >> permission for a file. The additional explicit check is superfluous. >> I have removed it. >> >> With explicit check I wanted the API to behave uniformly regardless >> of whether the returned stream is opened by getInputStream() call or >> an already opened stream is just returned. getCannonicalFile() >> already takes care of it. Here's the updated webrev: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/ >> > Updated patch looks good to me. > > -Alan. Thanks, Alan. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Jan 1 19:56:08 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 1 Jan 2015 19:56:08 +0000 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <54A59E4C.1050603@gmail.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A119FF.4060103@oracle.com> <54A122AA.3010004@gmail.com> <54A17899.4060304@oracle.com> <54A59E4C.1050603@gmail.com> Message-ID: <83431B89-27FD-4087-B643-5FDF4052D8BF@oracle.com> This looks very nice Peter. Just a small comment on the test; it may avoid future problems if the test use deleteFileWithRetry, from the test library [1], rather than file.delete(). -Chris. [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/test/lib/testlibrary/jdk/testlibrary/FileUtils.java On 1 Jan 2015, at 19:21, Peter Levart wrote: > > On 12/29/2014 04:51 PM, Alan Bateman wrote: >> On 29/12/2014 09:45, Peter Levart wrote: >>> >>> Thanks for looking at this, Alan. >>> >>> You're right about File.getCanonicalFile(). It already checks read permission for a file. The additional explicit check is superfluous. I have removed it. >>> >>> With explicit check I wanted the API to behave uniformly regardless of whether the returned stream is opened by getInputStream() call or an already opened stream is just returned. getCannonicalFile() already takes care of it. Here's the updated webrev: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/ >> Updated patch looks good to me. >> >> -Alan. > > Thanks, Alan. > > Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Thu Jan 1 20:22:20 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 01 Jan 2015 21:22:20 +0100 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <54A20475.3040206@oracle.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A20475.3040206@oracle.com> Message-ID: <54A5AC7C.5010806@gmail.com> Hi Brad, Here's next webrev which tries to cover all your comments: http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.04/ Answers inline... On 12/30/2014 02:48 AM, Bradford Wetmore wrote: > I'm looking at this version of the webrev. > > http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/ > > > I just assigned 8047769 to you. My username is wetmore, Alan is alanb. I'll note you both as reviewers in the changeset. > > On 12/24/2014 3:37 AM, Peter Levart wrote: > >>> Looks like you have a committer status, will you be pushing this? >> >> I can, yes. As soon as we clear-out the remaining questions, right? > > Yes. The comments below are minor and shouldn't need another review > cycle. I'm worried about the failure of the test you observed while running from NetBeans. Perhaps a 0.5s wait is sometimes not enough for ReferenceHandler thread to process (enqueue) a WeakReference. Since there is already a facility in place to help ReferenceHandler thread instead of wait for it, I used it in new version of the test. > I have started a JPRT job for you, I'll run it through "core" target > which will give us: > > jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, jdk_security*, > jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools. > > Anything else? I'm off tomorrow, I should have full results Wed. > > Here are the preliminary results for the jobs that have finished. > jdk.testlibrary.Asserts is causing compilation errors, additional > comments below: > > /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:33: > error: package jdk.testlibrary does not exist > import static jdk.testlibrary.Asserts.*; > ^ > /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:52: > error: cannot find symbol > assertEquals(bytes.length, nread, "short read"); > ^ > symbol: method assertEquals(int,int,String) > location: class FileInputStreamPoolTest > /opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:53: > error: cannot find symbol > assertTrue(Arrays.equals(readBytes, bytes), > ^ > symbol: method assertTrue(boolean,String) > location: class FileInputStreamPoolTest > 3 errors > > TEST RESULT: Failed. Compilation failed: Compilation failed I changed the test to be self-contained now so one can run it without testlib in classpath. > > I'm also getting failures in the following test. I unfortunately have > to leave now, so don't have time to look at this. But it did mention > "seed" so I'm mentioning it here. > > TEST: java/lang/invoke/LFCaching/LFGarbageCollectedTest.java > > ACTION: main -- Failed. Execution failed: `main' threw exception: > java.lang.Error: 36 of 39 test cases FAILED! Rerun the test with the > same "-Dseed=" option as in the log file! > REASON: User specified action: run main/othervm LFGarbageCollectedTest > TIME: 213.406 seconds > messages: > command: main LFGarbageCollectedTest > reason: User specified action: run main/othervm LFGarbageCollectedTest > elapsed time (seconds): 213.406 > STDOUT: > -Dseed=6102311124531075592 > -DtestLimit=2000 > Number of iterations according to -DtestLimit is 153 (1989 cases) > Code cache size is 251658240 bytes > Non-profiled code cache size is 123058253 bytes > Number of iterations limited by code cache size is 84 (1092 cases) > Number of iterations limited by non-profiled code cache size is 41 > (533 cases) > Number of iterations is set to 41 (533 cases) > Not enough time to continue execution. Interrupted. > STDERR: > Iteration 0: > Tested LF caching feature with MethodHandles.foldArguments method. > java.lang.AssertionError: Error: Lambda form is not garbage collected > at LFGarbageCollectedTest.doTest(LFGarbageCollectedTest.java:81) > at > LambdaFormTestCase$TestRun.doIteration(LambdaFormTestCase.java:139) > at LambdaFormTestCase$$Lambda$2/5042013.call(Unknown Source) > at > jdk.testlibrary.TimeLimitedRunner.call(TimeLimitedRunner.java:71) > at LambdaFormTestCase.runTests(LambdaFormTestCase.java:201) > at LFGarbageCollectedTest.main(LFGarbageCollectedTest.java:105) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >>> In a couple places, there are a few lines > 80 chars. (It's a pet >>> peeve of mine, this makes side-by-side reviews difficult without a >>> wide monitor. I realize not everyone shares this view, but they're >>> probably not working on a laptop screen regularly.) >> >> I have wrapped the lines to contain them inside the 80 column margin. > > I and my scrubber/slider thank you. :) > > Two minor nits? SeedGenerator.java: Lines 507/518 Done that too. > >>> Do you need to close the InputStream when last holder is GC'd, or do >>> we just let the FileInputStream's finalizer take care of that? >> >> WeakReference is enqueued when it is cleared, so >> at that time we have no access to the referent (UncloseableInputStream) >> any more. We could, in addition, "strongly" reference the underlying >> FileInputStream in the WeakReference subclass itself, but that would >> just prolong the life of FileInputStream (possibly forever if no further >> calls to FileInputStreamPool are made that expunge the references from >> the queue). So yes, we rely on FileInputStream's finalizer, but I don't >> see any other way that would be better than that. > > Makes sense, thanks. > >> NativePRNG and >> URLSeedGenerator don't have a means of closing underlying resources >> either, so this is not making things any worse. > > Yes. > >>> Both of these current calls are contained within a >>> AccessContrller.doPriviledged, the checkRead() seems redundant. >> >> That's right, but from encapsulation, uniformity, security and future >> maintainability standpoint, I would keep this logic in. It doesn't hurt. >> Another possibility is to move doPriviliged call to FileInputStreamPool >> itself and declare it's API exposing security capability (of reading any >> file). > > I see this was addressed later via Alan's review. > >>> In your test case, if assertions are not enabled, the tests at >>> 46/50/51 are noops, e.g. when run by hand. Generally should directly >>> throw Exceptions. >> >> I modified the test to use jdk.testlibrary.Asserts class. Is this ok >> from "run by hand" perspective or should the test be self-contained? > > I've not used this Asserts library yet. Is this part of TestNG, or > something new in jtreg or jprt? If Core-libs is ok with this style of > doing it, I'm ok. I'm kind of old-school and tests should be mostly > self-contained and can be tested via: > > % javac Clazz.java > % java Clazz This should work now. > > without extra classpaths needed. I understand this model doesn't work > with @library and such, so I'm not strongly tied to it. I can be > taught new tricks. > > >>> Core-libs folks? >> >> The documentation doesn't mention threads anywhere in InputStream or >> FileInputStream except in this piece of javadoc for available() method: > ...snip... > > Ok. > > A few minor nits below: > > FileInputStreamPool.java > ======================== > * This method opens an underlying {@link java.io.FileInputStream} for > -> > * This method opens an underlying {@link java.io.FileInputStream} for a > > * among multiple readers of same {@code file} and ignores > -> > * among multiple readers of the same {@code file} and ignores Done. > > FileInputStreamPoolTest.java > ============================ > Generally JTREG labels are immediately following the copyright and > before the imports. > > While what you have is allowed by the JTREG syntax, @test is usually > by itself, or followed by old SCCS or filename info. > > @summary is usually the bug description. Suggest: > > @summary SecureRandom should be more frugal with file descriptors > > 48: This is still using assert. Fixed. > > Maybe issue multiple reads to exercise in1 and in2? e.g. 2 bytes of > in1, 4 bytes of in2, then 2 bytes of in1? The 1st assert makes sure in1 == in2, so there's no point in invoking the same instance via two aliases. > > IIRC, when I ran this under NetBeans last week, the second testCaching > didn't clear the WeakReference. This should not happen any more now that the test is helping to enqueue the WeakReferences instead of waiting for ReferenceHandler to enqueue them. The test can now fail only if System.gc() does not trigger WeakReference processing in the VM. Can you give it a try on your NetBeans environment? > > Thanks, > > Brad Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.levart at gmail.com Thu Jan 1 20:57:18 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 01 Jan 2015 21:57:18 +0100 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <83431B89-27FD-4087-B643-5FDF4052D8BF@oracle.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A119FF.4060103@oracle.com> <54A122AA.3010004@gmail.com> <54A17899.4060304@oracle.com> <54A59E4C.1050603@gmail.com> <83431B89-27FD-4087-B643-5FDF4052D8BF@oracle.com> Message-ID: <54A5B4AE.6030807@gmail.com> On 01/01/2015 08:56 PM, Chris Hegarty wrote: > This looks very nice Peter. > > Just a small comment on the test; it may avoid future problems if the > test use deleteFileWithRetry, from the test library [1], rather than > file.delete(). > > -Chris. > > [1] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/test/lib/testlibrary/jdk/testlibrary/FileUtils.java > Hi Chris, Thanks for pointing me to the FileUtils. It got me thinking that the test might not be able to delete the file on Windows, since after return from 2nd call to testCaching(), it might still be open (and it very probably will be in the webrev.04 test). So I "fixed" this. I now treat the unsuccessful deletion as a test failure as it should only occur if the file is not closed at the end which it now should be. Here's the latest webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.05/ Regards, Peter > On 1 Jan 2015, at 19:21, Peter Levart > wrote: > >> >> On 12/29/2014 04:51 PM, Alan Bateman wrote: >>> On 29/12/2014 09:45, Peter Levart wrote: >>>> >>>> Thanks for looking at this, Alan. >>>> >>>> You're right about File.getCanonicalFile(). It already checks read >>>> permission for a file. The additional explicit check is >>>> superfluous. I have removed it. >>>> >>>> With explicit check I wanted the API to behave uniformly regardless >>>> of whether the returned stream is opened by getInputStream() call >>>> or an already opened stream is just returned. getCannonicalFile() >>>> already takes care of it. Here's the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/ >>>> >>> Updated patch looks good to me. >>> >>> -Alan. >> >> Thanks, Alan. >> >> Peter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Fri Jan 2 22:58:21 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 02 Jan 2015 14:58:21 -0800 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <54A5AC7C.5010806@gmail.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A20475.3040206@oracle.com> <54A5AC7C.5010806@gmail.com> Message-ID: <54A7228D.4040801@oracle.com> On 1/1/2015 12:22 PM, Peter Levart wrote: > Hi Brad, > > Here's next webrev which tries to cover all your comments: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.04/ I downloaded the webrev.05 (Chris' later followup email) and ran it through JPRT. The only error was the previously seen -Dseed which is not your problem. Again, I only ran: jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, jdk_security*, jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools. If you need anything else run, let me know. >>>> Looks like you have a committer status, will you be pushing this? >>> >>> I can, yes. As soon as we clear-out the remaining questions, right? >> >> Yes. The comments below are minor and shouldn't need another review >> cycle. > > I'm worried about the failure of the test you observed while running > from NetBeans. Perhaps a 0.5s wait is sometimes not enough for > ReferenceHandler thread to process (enqueue) a WeakReference. Since > there is already a facility in place to help ReferenceHandler thread > instead of wait for it, I used it in new version of the test. BTW, there's now an unnecessary import from java.lang.AssertionError added in webrev.04. >> TEST RESULT: Failed. Compilation failed: Compilation failed > > I changed the test to be self-contained now so one can run it without > testlib in classpath. Thanks. It's compiling fine now. >> Two minor nits? SeedGenerator.java: Lines 507/518 > > Done that too. Thanks. >> Maybe issue multiple reads to exercise in1 and in2? e.g. 2 bytes of >> in1, 4 bytes of in2, then 2 bytes of in1? > > The 1st assert makes sure in1 == in2, so there's no point in invoking > the same instance via two aliases. True. >> IIRC, when I ran this under NetBeans last week, the second testCaching >> didn't clear the WeakReference. > > This should not happen any more now that the test is helping to enqueue > the WeakReferences instead of waiting for ReferenceHandler to enqueue > them. Yes, that hit the refQueue.poll(). It's always interesting to work with core-libs folks, learn something new everyday. Mixing Lambdas/try-with. I need a time-machine for your CFV/jdk8 Committer: http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-August/002896.html I vote yes. > The test can now fail only if System.gc() does not trigger > WeakReference processing in the VM. Can you give it a try on your > NetBeans environment? One last comment. It's now 2015. ;) Brad From peter.levart at gmail.com Sun Jan 4 16:25:14 2015 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 04 Jan 2015 17:25:14 +0100 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <54A7228D.4040801@oracle.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A20475.3040206@oracle.com> <54A5AC7C.5010806@gmail.com> <54A7228D.4040801@oracle.com> Message-ID: <54A9696A.3070406@gmail.com> Hi Brad, So I created another webrev (just removed the unneeded import and left-over System.out.println from test): http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.06/ I'll leave it here to rest for a couple of days and if no one objects, I'll push it to jdk9-dev. Thanks everybody for reviews and happy new year! Regards, Peter On 01/02/2015 11:58 PM, Bradford Wetmore wrote: > > On 1/1/2015 12:22 PM, Peter Levart wrote: >> Hi Brad, >> >> Here's next webrev which tries to cover all your comments: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.04/ >> > > I downloaded the webrev.05 (Chris' later followup email) and ran it > through JPRT. The only error was the previously seen -Dseed which is > not your problem. > > Again, I only ran: > > jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, > jdk_security*, jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools. > > If you need anything else run, let me know. > >>>>> Looks like you have a committer status, will you be pushing this? >>>> >>>> I can, yes. As soon as we clear-out the remaining questions, right? >>> >>> Yes. The comments below are minor and shouldn't need another review >>> cycle. >> >> I'm worried about the failure of the test you observed while running >> from NetBeans. Perhaps a 0.5s wait is sometimes not enough for >> ReferenceHandler thread to process (enqueue) a WeakReference. Since >> there is already a facility in place to help ReferenceHandler thread >> instead of wait for it, I used it in new version of the test. > > BTW, there's now an unnecessary import from java.lang.AssertionError > added in webrev.04. > >>> TEST RESULT: Failed. Compilation failed: Compilation failed >> >> I changed the test to be self-contained now so one can run it without >> testlib in classpath. > > Thanks. It's compiling fine now. > >>> Two minor nits? SeedGenerator.java: Lines 507/518 >> >> Done that too. > > Thanks. > >>> Maybe issue multiple reads to exercise in1 and in2? e.g. 2 bytes of >>> in1, 4 bytes of in2, then 2 bytes of in1? >> >> The 1st assert makes sure in1 == in2, so there's no point in invoking >> the same instance via two aliases. > > True. > >>> IIRC, when I ran this under NetBeans last week, the second testCaching >>> didn't clear the WeakReference. >> >> This should not happen any more now that the test is helping to enqueue >> the WeakReferences instead of waiting for ReferenceHandler to enqueue >> them. > > Yes, that hit the refQueue.poll(). > > It's always interesting to work with core-libs folks, learn something > new everyday. Mixing Lambdas/try-with. > > I need a time-machine for your CFV/jdk8 Committer: > > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-August/002896.html > > I vote yes. > >> The test can now fail only if System.gc() does not trigger >> WeakReference processing in the VM. Can you give it a try on your >> NetBeans environment? > > One last comment. It's now 2015. ;) > > Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Mon Jan 5 16:00:58 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 5 Jan 2015 11:00:58 -0500 (EST) Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <4353739B-3220-4AF9-9FB5-ECA1EEE0C85C@oracle.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> <2FADB035-FA74-48BC-B923-444AED97A510@oracle.com> <1176100146.1009924.1419437362122.JavaMail.zimbra@redhat.com> <4353739B-3220-4AF9-9FB5-ECA1EEE0C85C@oracle.com> Message-ID: <475969676.2624820.1420473658297.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Can you elaborate on 'this and a couple of other patches' - is that supposed > to be all of the corresponding JEP 130? Some part of it? > > Considering that the JEP 130 has legal and docs implications that imply more > work having to be done than just back porting a couple of change sets, I > think you need to try to make a stronger case for the proposed change. > > Is there a specific issue in JBS (or some other bug tracker) this change is > trying to address? > Specifically, the full set is: 4963723: Implement SHA-224 7044060: Need to support NSA Suite B Cryptography algorithms 8006935: Need to take care of long secret keys in HMAC/PRF computation 8000897: VM crash in CompileBroker The main one is 7044060, which allows DH key sizes of 2048. Prior to this fix, the maximum key size for DH is 1024, whereas the Apache web server now defaults to a minimum of 2048. This leads to a RuntimeException "Could not generate DH keypair" from the Java side. 4963723 is a per-requisite, not so much for SHA-224 itself, as to the refactoring included in that change, which 7044060 then builds on. 8006935 and 8000897 fix bugs that arose because of the previous two fixes. We had a Red Hat bug for this, but I doubt it's fully visible externally: https://bugzilla.redhat.com/show_bug.cgi?id=1145848 > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | > Mobile:+491737185961 > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > > > On 24.12.2014, at 17:09, Andrew Hughes wrote: > > > > ----- Original Message ----- > >> Considering that the issue was a P3 RFE rather than a high priority bug > >> fix, > >> it's not clear to me why it would be necessary to backport it into 7u80, > >> at > >> the end point in the release cycle. > >> > > > > I don't have anything to do with the assignment of such priorities. > > > > From our side, as already explained, backporting this and a couple of other > > patches > > yet to come that depend on it is important for retaining the compatibility > > of OpenJDK > > web servers with Apache web servers, which have switched to requiring a > > higher DH key > > size by default. > > > > Thanks, > > -- > > Andrew :) > > > > Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From bradford.wetmore at oracle.com Tue Jan 6 19:52:10 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 06 Jan 2015 11:52:10 -0800 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <54A9696A.3070406@gmail.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A20475.3040206@oracle.com> <54A5AC7C.5010806@gmail.com> <54A7228D.4040801@oracle.com> <54A9696A.3070406@gmail.com> Message-ID: <54AC3CEA.6000702@oracle.com> I only looked at test, looks good to me. I'd rarely ask to remove extra prints in tests. It adds initial debugging data points in case something breaks down the road. Brad On 1/4/2015 8:25 AM, Peter Levart wrote: > Hi Brad, > > So I created another webrev (just removed the unneeded import and > left-over System.out.println from test): > > http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.06/ > > I'll leave it here to rest for a couple of days and if no one objects, > I'll push it to jdk9-dev. > > Thanks everybody for reviews and happy new year! > > Regards, Peter > > On 01/02/2015 11:58 PM, Bradford Wetmore wrote: >> >> On 1/1/2015 12:22 PM, Peter Levart wrote: >>> Hi Brad, >>> >>> Here's next webrev which tries to cover all your comments: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.04/ >>> >> >> I downloaded the webrev.05 (Chris' later followup email) and ran it >> through JPRT. The only error was the previously seen -Dseed which is >> not your problem. >> >> Again, I only ran: >> >> jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, >> jdk_security*, jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools. >> >> If you need anything else run, let me know. >> >>>>>> Looks like you have a committer status, will you be pushing this? >>>>> >>>>> I can, yes. As soon as we clear-out the remaining questions, right? >>>> >>>> Yes. The comments below are minor and shouldn't need another review >>>> cycle. >>> >>> I'm worried about the failure of the test you observed while running >>> from NetBeans. Perhaps a 0.5s wait is sometimes not enough for >>> ReferenceHandler thread to process (enqueue) a WeakReference. Since >>> there is already a facility in place to help ReferenceHandler thread >>> instead of wait for it, I used it in new version of the test. >> >> BTW, there's now an unnecessary import from java.lang.AssertionError >> added in webrev.04. >> >>>> TEST RESULT: Failed. Compilation failed: Compilation failed >>> >>> I changed the test to be self-contained now so one can run it without >>> testlib in classpath. >> >> Thanks. It's compiling fine now. >> >>>> Two minor nits? SeedGenerator.java: Lines 507/518 >>> >>> Done that too. >> >> Thanks. >> >>>> Maybe issue multiple reads to exercise in1 and in2? e.g. 2 bytes of >>>> in1, 4 bytes of in2, then 2 bytes of in1? >>> >>> The 1st assert makes sure in1 == in2, so there's no point in invoking >>> the same instance via two aliases. >> >> True. >> >>>> IIRC, when I ran this under NetBeans last week, the second testCaching >>>> didn't clear the WeakReference. >>> >>> This should not happen any more now that the test is helping to enqueue >>> the WeakReferences instead of waiting for ReferenceHandler to enqueue >>> them. >> >> Yes, that hit the refQueue.poll(). >> >> It's always interesting to work with core-libs folks, learn something >> new everyday. Mixing Lambdas/try-with. >> >> I need a time-machine for your CFV/jdk8 Committer: >> >> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-August/002896.html >> >> I vote yes. >> >>> The test can now fail only if System.gc() does not trigger >>> WeakReference processing in the VM. Can you give it a try on your >>> NetBeans environment? >> >> One last comment. It's now 2015. ;) >> >> Brad >> > From xuelei.fan at oracle.com Wed Jan 7 00:38:40 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 07 Jan 2015 08:38:40 +0800 Subject: [JDK-9] RFR: 8048607: Implement key generation tests In-Reply-To: <540E6A37.3070607@oracle.com> References: <53D5F8AD.2060804@oracle.com> <53DB0509.3000109@oracle.com> <53F6F9B4.6040206@oracle.com> <540E6A37.3070607@oracle.com> Message-ID: <54AC8010.2020000@oracle.com> Sorry for the delay. TestKGParity.java ----------------- Can you provide more comment on what kind of algorithms are you want to cover in this testing? Suggested to use the bug synopsis as the summary filed. You are the author of this test. You may want to remove the author line in the class comment. Otherwise, looks fine to me. Thanks, Xuelei On 9/9/2014 10:47 AM, zaiyao liu wrote: > Hi Xuelei, > > Can you help to review this test? > JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8048607 > Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048607/webrev01/ > > Thanks > > Kevin > ? 2014/8/22 16:05, zaiyao liu ??: >> May I request you to review 1 new test to be added for key generation algorithms. New test are added to address following: >> - Generate a secret key using key generator for specified algorithm, >> retrieve its value, then verify the parity of that key. >> >> JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8048607 >> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048607/webrev01/ >> >> Thanks, >> >> Kevin > From zaiyao.liu at oracle.com Wed Jan 7 02:54:12 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Wed, 07 Jan 2015 10:54:12 +0800 Subject: [JDK-9] RFR: 8048607: Implement key generation tests In-Reply-To: <54AC8010.2020000@oracle.com> References: <53D5F8AD.2060804@oracle.com> <53DB0509.3000109@oracle.com> <53F6F9B4.6040206@oracle.com> <540E6A37.3070607@oracle.com> <54AC8010.2020000@oracle.com> Message-ID: <54AC9FD4.2010608@oracle.com> Hi Xuelei, Thanks for review, please check the update: http://cr.openjdk.java.net/~zailiu/8044193/webrev.03/ Please help to push it if OK. Full comments: 8048607: Implement key generation tests Reviewed-by: xuelei Contributed-by: Zaiyao Liu Thanks and Regards. Kevin ? 2015/1/7 8:38, Xuelei Fan ??: > Sorry for the delay. > > TestKGParity.java > ----------------- > Can you provide more comment on what kind of algorithms are you want to > cover in this testing? > > Suggested to use the bug synopsis as the summary filed. > > You are the author of this test. You may want to remove the author line > in the class comment. > > Otherwise, looks fine to me. > > Thanks, > Xuelei > > > On 9/9/2014 10:47 AM, zaiyao liu wrote: >> Hi Xuelei, >> >> Can you help to review this test? >> JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8048607 >> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048607/webrev01/ >> >> Thanks >> >> Kevin >> ? 2014/8/22 16:05, zaiyao liu ??: >>> May I request you to review 1 new test to be added for key generation algorithms. New test are added to address following: >>> - Generate a secret key using key generator for specified algorithm, >>> retrieve its value, then verify the parity of that key. >>> >>> JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8048607 >>> Webrev: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048607/webrev01/ >>> >>> Thanks, >>> >>> Kevin From jamil.j.nimeh at oracle.com Wed Jan 7 02:59:47 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 06 Jan 2015 18:59:47 -0800 Subject: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary Message-ID: <54ACA123.4020009@oracle.com> Hello all, This is a quick fix to deal with a broken link for the RC5ParameterSpec javadoc. Bug: https://bugs.openjdk.java.net/browse/JDK-8058912 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8058912/webrev.01/ Thanks! --Jamil From xuelei.fan at oracle.com Wed Jan 7 03:24:02 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 07 Jan 2015 11:24:02 +0800 Subject: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary In-Reply-To: <54ACA123.4020009@oracle.com> References: <54ACA123.4020009@oracle.com> Message-ID: <54ACA6D2.4030208@oracle.com> Looks fine to me. Just curious, why update the link of "http://www.ietf.org/rfc/rfc2040.txt"? The link works. Thanks, Xuelei On 1/7/2015 10:59 AM, Jamil Nimeh wrote: > Hello all, > > This is a quick fix to deal with a broken link for the RC5ParameterSpec > javadoc. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8058912 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8058912/webrev.01/ > > Thanks! > --Jamil From jamil.j.nimeh at oracle.com Wed Jan 7 05:06:56 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 06 Jan 2015 21:06:56 -0800 Subject: =?US-ASCII?Q?Re:_RFR_[JDK-9]:_JDK-8058912_:_?= =?US-ASCII?Q?Broken_link_(access_denied_error)?= =?US-ASCII?Q?=0D_=09to_http://www.rsasecurity.com?= =?US-ASCII?Q?_in_RC5ParameterSpec_class_summary?= Message-ID: <9i4qoel89fu77hqo6ls4h8pi.1420606886616@email.android.com> I did a similar doc bug fix in the past and one of the comments suggested using the tools variant of the RFC page. ?The table of contents links and links to errata and so forth are nice. ?So I figured I'd do the same thing here as last time. ?If it's a problem I can switch back to the ASCII version. --Jamil -------- Original message -------- From: Xuelei Fan Date: 01/06/2015 7:24 PM (GMT-08:00) To: security-dev at openjdk.java.net Subject: Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary Looks fine to me. Just curious, why update the link of "http://www.ietf.org/rfc/rfc2040.txt"? The link works. Thanks, Xuelei On 1/7/2015 10:59 AM, Jamil Nimeh wrote: > Hello all, > > This is a quick fix to deal with a broken link for the RC5ParameterSpec > javadoc. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8058912 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8058912/webrev.01/ > > Thanks! > --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Wed Jan 7 06:26:24 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 7 Jan 2015 01:26:24 -0500 Subject: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary In-Reply-To: <9i4qoel89fu77hqo6ls4h8pi.1420606886616@email.android.com> References: <9i4qoel89fu77hqo6ls4h8pi.1420606886616@email.android.com> Message-ID: <36287628-B0FF-4383-AE46-F4AF8F1EC477@comcast.net> Actually, www.rfc-editor.org/rfc/rfc.txt is probably a better long term normative reference for documents in the RFC series. Mike Sent from my iPad > On Jan 7, 2015, at 00:06, Jamil Nimeh wrote: > > I did a similar doc bug fix in the past and one of the comments suggested using the tools variant of the RFC page. The table of contents links and links to errata and so forth are nice. So I figured I'd do the same thing here as last time. If it's a problem I can switch back to the ASCII version. > > --Jamil > > > -------- Original message -------- > From: Xuelei Fan > Date: 01/06/2015 7:24 PM (GMT-08:00) > To: security-dev at openjdk.java.net > Subject: Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary > > Looks fine to me. > > Just curious, why update the link of > "http://www.ietf.org/rfc/rfc2040.txt"? The link works. > > Thanks, > Xuelei > > On 1/7/2015 10:59 AM, Jamil Nimeh wrote: > > Hello all, > > > > This is a quick fix to deal with a broken link for the RC5ParameterSpec > > javadoc. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8058912 > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8058912/webrev.01/ > > > > Thanks! > > --Jamil > From xuelei.fan at oracle.com Wed Jan 7 07:03:01 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 07 Jan 2015 15:03:01 +0800 Subject: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary In-Reply-To: <9i4qoel89fu77hqo6ls4h8pi.1420606886616@email.android.com> References: <9i4qoel89fu77hqo6ls4h8pi.1420606886616@email.android.com> Message-ID: <54ACDA25.3040107@oracle.com> On 1/7/2015 1:06 PM, Jamil Nimeh wrote: > I did a similar doc bug fix in the past and one of the comments > suggested using the tools variant of the RFC page. The table of > contents links and links to errata and so forth are nice. So I figured > I'd do the same thing here as last time. If it's a problem I can switch > back to the ASCII version. > It's OK. I just want to learn more about the background history. Thanks, Xuelei > --Jamil > > > -------- Original message -------- > From: Xuelei Fan > Date: 01/06/2015 7:24 PM (GMT-08:00) > To: security-dev at openjdk.java.net > Subject: Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied > error) to http://www.rsasecurity.com in RC5ParameterSpec class summary > > Looks fine to me. > > Just curious, why update the link of > "http://www.ietf.org/rfc/rfc2040.txt"? The link works. > > Thanks, > Xuelei > > On 1/7/2015 10:59 AM, Jamil Nimeh wrote: >> Hello all, >> >> This is a quick fix to deal with a broken link for the RC5ParameterSpec >> javadoc. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8058912 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8058912/webrev.01/ >> >> Thanks! >> --Jamil > From weijun.wang at oracle.com Wed Jan 7 07:49:55 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 07 Jan 2015 15:49:55 +0800 Subject: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary In-Reply-To: <36287628-B0FF-4383-AE46-F4AF8F1EC477@comcast.net> References: <9i4qoel89fu77hqo6ls4h8pi.1420606886616@email.android.com> <36287628-B0FF-4383-AE46-F4AF8F1EC477@comcast.net> Message-ID: <54ACE523.60403@oracle.com> On 1/7/2015 14:26, Michael StJohns wrote: > Actually,www.rfc-editor.org/rfc/rfc.txt is probably a better long term normative reference for documents in the RFC series. Why? I think Jamil's tools.ietf.org/html/rfc is better. The xml2rfc tool generates this style. --Max > > Mike From xuelei.fan at oracle.com Wed Jan 7 08:01:27 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 07 Jan 2015 16:01:27 +0800 Subject: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary In-Reply-To: <54ACE523.60403@oracle.com> References: <9i4qoel89fu77hqo6ls4h8pi.1420606886616@email.android.com> <36287628-B0FF-4383-AE46-F4AF8F1EC477@comcast.net> <54ACE523.60403@oracle.com> Message-ID: <54ACE7D7.80908@oracle.com> A IETF workgroup uses the following style for its documentation: plain text: http://www.rfc-editor.org/rfc/rfc.txt pdf: http://www.rfc-editor.org/rfc/pdfrfc/rfc.txt.pdf html: http://tools.ietf.org/html/rfc For Java docs, I think the html version may be better to track the history and links. Xuelei On 1/7/2015 3:49 PM, Weijun Wang wrote: > On 1/7/2015 14:26, Michael StJohns wrote: >> Actually,www.rfc-editor.org/rfc/rfc.txt is probably a better long >> term normative reference for documents in the RFC series. > > Why? > > I think Jamil's tools.ietf.org/html/rfc is better. The xml2rfc tool > generates this style. > > --Max > >> >> Mike From sean.mullan at oracle.com Wed Jan 7 12:09:41 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 07 Jan 2015 07:09:41 -0500 Subject: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary In-Reply-To: <54ACA123.4020009@oracle.com> References: <54ACA123.4020009@oracle.com> Message-ID: <54AD2205.5030506@oracle.com> Please add a noreg-doc label to the bug. Looks fine otherwise. --Sean On 01/06/2015 09:59 PM, Jamil Nimeh wrote: > Hello all, > > This is a quick fix to deal with a broken link for the RC5ParameterSpec > javadoc. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8058912 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8058912/webrev.01/ > > Thanks! > --Jamil From valerie.peng at oracle.com Wed Jan 7 23:30:32 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 07 Jan 2015 15:30:32 -0800 Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <5419FA7F.903@oracle.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> Message-ID: <54ADC198.5040307@oracle.com> I looked through the source changes and they look fine, except that the following related fix should also be combined for completeness: 7169496: Problem with the SHA-224 support for SunMSCAPI provider webrev for 7169496: http://cr.openjdk.java.net/~valeriep/7169496/webrev.00/ As for the test changes, I am still looking at them. Will let you know once I am done. Thanks, Valerie On 12/23/2014 8:13 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Valerie Peng (original author) is probably best suited to reviewing this >> but I think she's out of the office the moment and back next week. Let's >> hope we can get an update/review then. >> > Hi, > > Any movement on this? It's been three months. > > Thanks. > >> regards, >> Sean. >> >> On 01/10/2014 16:11, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> ----- Original Message ----- >>>>> Code changes generally require two approvals: codereview, performed by a >>>>> reviewer, (in this case from security-dev) and push approval, performed >>>>> by a gatekeeper. Given your email template matches the push approval >>>>> template I understood that you intended the latter. Generally speaking >>>>> codereview requests would say "Request for review" as opposed to >>>>> "Request for approval" so a reviewer could overlook your mail if you >>>>> intended the former. >>>>> >>>>> -Rob >>>>> >>>>> On 18/09/14 00:21, Andrew Hughes wrote: >>>>>> ----- Original Message ----- >>>>>>> Hi Andrew, >>>>>>> >>>>>>> Sorry to be a pest, but given the scope of the change I'd feel more >>>>>>> comfortable with an explicit codereview for the backport. >>>>>>> >>>>>>> -Rob >>>>>>> >>>>>>> On 17/09/14 18:32, Andrew Hughes wrote: >>>>>>>> This is the first of three backports to 7u designed to retain SSL >>>>>>>> compatibility with servers implemented in other languages switching >>>>>>>> to larger key sizes (notably DH>=2048 in Apache 2.4.7 [0]). >>>>>>>> >>>>>>>> This patch is a per-requisite of the patch which brings NSA Suite B >>>>>>>> support to 7. It applies largely unchanged, bar the following: >>>>>>>> >>>>>>>> * Copyright header adjustment >>>>>>>> * Removal of change to java.security.spec.MGF1ParameterSpec to avoid >>>>>>>> introducing a new public variable. The SHA-224 variant is constructed >>>>>>>> directly in com.sun.crypto.provider.OAEPParameters instead. >>>>>>>> * A change to OAEPParameters is dropped as it was already incorporated >>>>>>>> in the backport of 7180907& 8049480 (addition of SHA-224 to >>>>>>>> convertToStandardName) >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4963723 >>>>>>>> Webrev: http://cr.openjdk.java.net/~andrew/jdk7u/4963723/webrev.01/ >>>>>>>> >>>>>>>> [0] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html >>>>>>>> >>>>>>>> Ok to push? >>>>>>>> >>>>>>>> Thanks, >>>>>> Which is what I asked for, no? >>>>>> >>>>>> If I wasn't waiting on a review first, I'd have pushed the change. >>>> This was the only applicable template on: >>>> >>>> http://openjdk.java.net/projects/jdk7u/ >>>> >>>> Anyway, now including security-dev for review. >>>> -- >>>> Andrew :) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>>> >>>> >>> Ping. Any movement on this? >> From mstjohns at comcast.net Thu Jan 8 00:10:18 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 07 Jan 2015 19:10:18 -0500 Subject: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary In-Reply-To: <54ACE7D7.80908@oracle.com> References: <9i4qoel89fu77hqo6ls4h8pi.1420606886616@email.android.com> <36287628-B0FF-4383-AE46-F4AF8F1EC477@comcast.net> <54ACE523.60403@oracle.com> <54ACE7D7.80908@oracle.com> Message-ID: What you want is the most "stable" reference rather than the prettiest reference IMHO. That's the rfc-editor.org set of links as the RFC editor is the owner of the RFC series. The IETF set of links are subject to change to meet the needs of the IETF and the tools page links *will* change again at some point - either because the IETF gets someone new to manage the tools, or because some new organizational structure of the web site works better with the IETF work flow. I expect the www.rfc-editor.org references to be stable for at least the next 20 years because that's part of the RFC editor's charter (providing a stable archive). I wouldn't care to make a bet on how long the IETF tools page references will remain as they are - it could be decades, it could be minutes. WRT the xml2rfc comment - one of the things that will probably happen this year is the replacement of text or the addition of a new normative format (pdf?) for new RFCs. Later, Mike At 03:01 AM 1/7/2015, Xuelei Fan wrote: >A IETF workgroup uses the following style for its documentation: > >plain text: > http://www.rfc-editor.org/rfc/rfc.txt >pdf: > http://www.rfc-editor.org/rfc/pdfrfc/rfc.txt.pdf >html: > http://tools.ietf.org/html/rfc > >For Java docs, I think the html version may be better to track the >history and links. > >Xuelei > >On 1/7/2015 3:49 PM, Weijun Wang wrote: >> On 1/7/2015 14:26, Michael StJohns wrote: >>> Actually,www.rfc-editor.org/rfc/rfc.txt is probably a better long >>> term normative reference for documents in the RFC series. >> >> Why? >> >> I think Jamil's tools.ietf.org/html/rfc is better. The xml2rfc tool >> generates this style. >> >> --Max >> >>> >>> Mike From Xuelei.Fan at Oracle.COM Thu Jan 8 01:27:18 2015 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Thu, 08 Jan 2015 09:27:18 +0800 Subject: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary In-Reply-To: <201501080010.t0809cOL029096@userp2050.oracle.com> References: <9i4qoel89fu77hqo6ls4h8pi.1420606886616@email.android.com> <36287628-B0FF-4383-AE46-F4AF8F1EC477@comcast.net> <54ACE523.60403@oracle.com> <54ACE7D7.80908@oracle.com> <201501080010.t0809cOL029096@userp2050.oracle.com> Message-ID: <54ADDCF6.3090903@Oracle.COM> Good point! Thanks for looking insight into the question, Mike. Jamil, what do you think if we use the plain text links as Mike suggested if we run into similar update again? Thanks, Xuelei On 1/8/2015 8:10 AM, Michael StJohns wrote: > What you want is the most "stable" reference rather than the prettiest reference IMHO. That's the rfc-editor.org set of links as the RFC editor is the owner of the RFC series. > > The IETF set of links are subject to change to meet the needs of the IETF and the tools page links *will* change again at some point - either because the IETF gets someone new to manage the tools, or because some new organizational structure of the web site works better with the IETF work flow. > > I expect the www.rfc-editor.org references to be stable for at least the next 20 years because that's part of the RFC editor's charter (providing a stable archive). I wouldn't care to make a bet on how long the IETF tools page references will remain as they are - it could be decades, it could be minutes. > > WRT the xml2rfc comment - one of the things that will probably happen this year is the replacement of text or the addition of a new normative format (pdf?) for new RFCs. > > Later, Mike > > > > > At 03:01 AM 1/7/2015, Xuelei Fan wrote: >> A IETF workgroup uses the following style for its documentation: >> >> plain text: >> http://www.rfc-editor.org/rfc/rfc.txt >> pdf: >> http://www.rfc-editor.org/rfc/pdfrfc/rfc.txt.pdf >> html: >> http://tools.ietf.org/html/rfc >> >> For Java docs, I think the html version may be better to track the >> history and links. >> >> Xuelei >> >> On 1/7/2015 3:49 PM, Weijun Wang wrote: >>> On 1/7/2015 14:26, Michael StJohns wrote: >>>> Actually,www.rfc-editor.org/rfc/rfc.txt is probably a better long >>>> term normative reference for documents in the RFC series. >>> >>> Why? >>> >>> I think Jamil's tools.ietf.org/html/rfc is better. The xml2rfc tool >>> generates this style. >>> >>> --Max >>> >>>> >>>> Mike > > From valerie.peng at oracle.com Thu Jan 8 01:54:54 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 07 Jan 2015 17:54:54 -0800 Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <54ADC198.5040307@oracle.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <5419FA7F.903@oracle.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> <54ADC198.5040307@oracle.com> Message-ID: <54ADE36E.8090202@oracle.com> Changes on Tests look fine. Regards, Valerie On 1/7/2015 3:30 PM, Valerie Peng wrote: > > I looked through the source changes and they look fine, except that > the following related fix should also be combined for completeness: > > 7169496: Problem with the SHA-224 support for SunMSCAPI provider > webrev for 7169496: > http://cr.openjdk.java.net/~valeriep/7169496/webrev.00/ > > As for the test changes, I am still looking at them. Will let you know > once I am done. > Thanks, > Valerie > > On 12/23/2014 8:13 AM, Andrew Hughes wrote: >> ----- Original Message ----- >>> Valerie Peng (original author) is probably best suited to reviewing >>> this >>> but I think she's out of the office the moment and back next week. >>> Let's >>> hope we can get an update/review then. >>> >> Hi, >> >> Any movement on this? It's been three months. >> >> Thanks. >> >>> regards, >>> Sean. >>> >>> On 01/10/2014 16:11, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> ----- Original Message ----- >>>>>> Code changes generally require two approvals: codereview, >>>>>> performed by a >>>>>> reviewer, (in this case from security-dev) and push approval, >>>>>> performed >>>>>> by a gatekeeper. Given your email template matches the push approval >>>>>> template I understood that you intended the latter. Generally >>>>>> speaking >>>>>> codereview requests would say "Request for review" as opposed to >>>>>> "Request for approval" so a reviewer could overlook your mail if you >>>>>> intended the former. >>>>>> >>>>>> -Rob >>>>>> >>>>>> On 18/09/14 00:21, Andrew Hughes wrote: >>>>>>> ----- Original Message ----- >>>>>>>> Hi Andrew, >>>>>>>> >>>>>>>> Sorry to be a pest, but given the scope of the change I'd feel >>>>>>>> more >>>>>>>> comfortable with an explicit codereview for the backport. >>>>>>>> >>>>>>>> -Rob >>>>>>>> >>>>>>>> On 17/09/14 18:32, Andrew Hughes wrote: >>>>>>>>> This is the first of three backports to 7u designed to retain SSL >>>>>>>>> compatibility with servers implemented in other languages >>>>>>>>> switching >>>>>>>>> to larger key sizes (notably DH>=2048 in Apache 2.4.7 [0]). >>>>>>>>> >>>>>>>>> This patch is a per-requisite of the patch which brings NSA >>>>>>>>> Suite B >>>>>>>>> support to 7. It applies largely unchanged, bar the following: >>>>>>>>> >>>>>>>>> * Copyright header adjustment >>>>>>>>> * Removal of change to java.security.spec.MGF1ParameterSpec to >>>>>>>>> avoid >>>>>>>>> introducing a new public variable. The SHA-224 variant is >>>>>>>>> constructed >>>>>>>>> directly in com.sun.crypto.provider.OAEPParameters instead. >>>>>>>>> * A change to OAEPParameters is dropped as it was already >>>>>>>>> incorporated >>>>>>>>> in the backport of 7180907& 8049480 (addition of SHA-224 to >>>>>>>>> convertToStandardName) >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4963723 >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~andrew/jdk7u/4963723/webrev.01/ >>>>>>>>> >>>>>>>>> [0] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html >>>>>>>>> >>>>>>>>> Ok to push? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>> Which is what I asked for, no? >>>>>>> >>>>>>> If I wasn't waiting on a review first, I'd have pushed the change. >>>>> This was the only applicable template on: >>>>> >>>>> http://openjdk.java.net/projects/jdk7u/ >>>>> >>>>> Anyway, now including security-dev for review. >>>>> -- >>>>> Andrew :) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>>>> >>>>> >>>> Ping. Any movement on this? >>> From jamil.j.nimeh at oracle.com Thu Jan 8 02:02:57 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 07 Jan 2015 18:02:57 -0800 Subject: =?US-ASCII?Q?Re:_RFR_[JDK-9]:_JDK-8058912_:_?= =?US-ASCII?Q?Broken_link_(access_denied_error)?= =?US-ASCII?Q?=0D__to_http://www.rsasecurity.com?= =?US-ASCII?Q?_in_RC5ParameterSpec_class_summary?= Message-ID: Sure. ?I did a little looking into this as well between email exchanges and I think Mike has it right. ?According to http://www.ietf.org/rfc.html the RFC Editor site is the authoritative source. ?Kind of a bummer as I prefer the xml2rfc format. ?But if RFC Editor has the best chance at long-term stability then it is probably the way to go for future things like this. There are multiple javadoc pages that reference RFCs...would it make sense to just file one bug or RFE and hit all the appropriate pages in one sweep? --Jamil -------- Original message -------- From: Xuelei Fan Date: 01/07/2015 5:27 PM (GMT-08:00) To: Michael StJohns , Weijun Wang , Jamil Nimeh Cc: security-dev at openjdk.java.net Subject: Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary Good point! Thanks for looking insight into the question, Mike. Jamil, what do you think if we use the plain text links as Mike suggested if we run into similar update again? Thanks, Xuelei On 1/8/2015 8:10 AM, Michael StJohns wrote: > What you want is the most "stable" reference rather than the prettiest reference IMHO. That's the rfc-editor.org set of links as the RFC editor is the owner of the RFC series. > > The IETF set of links are subject to change to meet the needs of the IETF and the tools page links *will* change again at some point - either because the IETF gets someone new to manage the tools, or because some new organizational structure of the web site works better with the IETF work flow. > > I expect the www.rfc-editor.org references to be stable for at least the next 20 years because that's part of the RFC editor's charter (providing a stable archive). I wouldn't care to make a bet on how long the IETF tools page references will remain as they are - it could be decades, it could be minutes. > > WRT the xml2rfc comment - one of the things that will probably happen this year is the replacement of text or the addition of a new normative format (pdf?) for new RFCs. > > Later, Mike > > > > > At 03:01 AM 1/7/2015, Xuelei Fan wrote: >> A IETF workgroup uses the following style for its documentation: >> >> plain text: >> http://www.rfc-editor.org/rfc/rfc.txt >> pdf: >> http://www.rfc-editor.org/rfc/pdfrfc/rfc.txt.pdf >> html: >> http://tools.ietf.org/html/rfc >> >> For Java docs, I think the html version may be better to track the >> history and links. >> >> Xuelei >> >> On 1/7/2015 3:49 PM, Weijun Wang wrote: >>> On 1/7/2015 14:26, Michael StJohns wrote: >>>> Actually,www.rfc-editor.org/rfc/rfc.txt is probably a better long >>>> term normative reference for documents in the RFC series. >>> >>> Why? >>> >>> I think Jamil's tools.ietf.org/html/rfc is better. The xml2rfc tool >>> generates this style. >>> >>> --Max >>> >>>> >>>> Mike > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Jan 8 11:47:05 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 08 Jan 2015 06:47:05 -0500 Subject: RFR [JDK-9]: JDK-8058912 : Broken link (access denied error) to http://www.rsasecurity.com in RC5ParameterSpec class summary In-Reply-To: References: Message-ID: <54AE6E39.5020505@oracle.com> On 01/07/2015 09:02 PM, Jamil Nimeh wrote: > Sure. I did a little looking into this as well between email exchanges > and I think Mike has it right. According to > http://www.ietf.org/rfc.html the RFC Editor site is the authoritative > source. Kind of a bummer as I prefer the xml2rfc format. But if RFC > Editor has the best chance at long-term stability then it is probably > the way to go for future things like this. > > There are multiple javadoc pages that reference RFCs...would it make > sense to just file one bug or RFE and hit all the appropriate pages in > one sweep? Yes, I think this makes the most sense. --Sean > > --Jamil > > > -------- Original message -------- > From: Xuelei Fan > Date: 01/07/2015 5:27 PM (GMT-08:00) > To: Michael StJohns , Weijun Wang > , Jamil Nimeh > Cc: security-dev at openjdk.java.net > Subject: Re: RFR [JDK-9]: JDK-8058912 : Broken link (access denied > error) to http://www.rsasecurity.com in RC5ParameterSpec class summary > > Good point! Thanks for looking insight into the question, Mike. > > Jamil, what do you think if we use the plain text links as Mike > suggested if we run into similar update again? > > Thanks, > Xuelei > > On 1/8/2015 8:10 AM, Michael StJohns wrote: > > What you want is the most "stable" reference rather than the > prettiest reference IMHO. That's the rfc-editor.org set of links as the > RFC editor is the owner of the RFC series. > > > > The IETF set of links are subject to change to meet the needs of the > IETF and the tools page links *will* change again at some point - either > because the IETF gets someone new to manage the tools, or because some > new organizational structure of the web site works better with the IETF > work flow. > > > > I expect the www.rfc-editor.org references to be stable for at least > the next 20 years because that's part of the RFC editor's charter > (providing a stable archive). I wouldn't care to make a bet on how long > the IETF tools page references will remain as they are - it could be > decades, it could be minutes. > > > > WRT the xml2rfc comment - one of the things that will probably happen > this year is the replacement of text or the addition of a new normative > format (pdf?) for new RFCs. > > > > Later, Mike > > > > > > > > > > At 03:01 AM 1/7/2015, Xuelei Fan wrote: > >> A IETF workgroup uses the following style for its documentation: > >> > >> plain text: > >> http://www.rfc-editor.org/rfc/rfc.txt > >> pdf: > >> http://www.rfc-editor.org/rfc/pdfrfc/rfc.txt.pdf > >> html: > >> http://tools.ietf.org/html/rfc > >> > >> For Java docs, I think the html version may be better to track the > >> history and links. > >> > >> Xuelei > >> > >> On 1/7/2015 3:49 PM, Weijun Wang wrote: > >>> On 1/7/2015 14:26, Michael StJohns wrote: > >>>> Actually,www.rfc-editor.org/rfc/rfc.txt is probably a better long > >>>> term normative reference for documents in the RFC series. > >>> > >>> Why? > >>> > >>> I think Jamil's tools.ietf.org/html/rfc is better. The xml2rfc > tool > >>> generates this style. > >>> > >>> --Max > >>> > >>>> > >>>> Mike > > > > > From sean.coffey at oracle.com Thu Jan 8 19:08:25 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 08 Jan 2015 19:08:25 +0000 Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <54ADE36E.8090202@oracle.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <5419FA7F.903@oracle.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> <54ADC198.5040307@oracle.com> <54ADE36E.8090202@oracle.com> Message-ID: <54AED5A9.8000301@oracle.com> Thanks for the code reviews Valerie. Andrew - looks like you need to submit new review with 7169496. Note that you still need to file for approval once code review is complete : http://openjdk.java.net/projects/jdk7u/groundrules.html I'm just being cautious on this one given the possible behavioural impact, the docs impact and the QA impact. A CCC may be required. I can help on that front - I'lll know more by next week. regards, Sean. On 08/01/2015 01:54, Valerie Peng wrote: > Changes on Tests look fine. > Regards, > Valerie > > On 1/7/2015 3:30 PM, Valerie Peng wrote: >> >> I looked through the source changes and they look fine, except that >> the following related fix should also be combined for completeness: >> >> 7169496: Problem with the SHA-224 support for SunMSCAPI provider >> webrev for 7169496: >> http://cr.openjdk.java.net/~valeriep/7169496/webrev.00/ >> >> As for the test changes, I am still looking at them. Will let you >> know once I am done. >> Thanks, >> Valerie >> >> On 12/23/2014 8:13 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Valerie Peng (original author) is probably best suited to reviewing >>>> this >>>> but I think she's out of the office the moment and back next week. >>>> Let's >>>> hope we can get an update/review then. >>>> >>> Hi, >>> >>> Any movement on this? It's been three months. >>> >>> Thanks. >>> >>>> regards, >>>> Sean. >>>> >>>> On 01/10/2014 16:11, Andrew Hughes wrote: >>>>> ----- Original Message ----- >>>>>> ----- Original Message ----- >>>>>>> Code changes generally require two approvals: codereview, >>>>>>> performed by a >>>>>>> reviewer, (in this case from security-dev) and push approval, >>>>>>> performed >>>>>>> by a gatekeeper. Given your email template matches the push >>>>>>> approval >>>>>>> template I understood that you intended the latter. Generally >>>>>>> speaking >>>>>>> codereview requests would say "Request for review" as opposed to >>>>>>> "Request for approval" so a reviewer could overlook your mail if >>>>>>> you >>>>>>> intended the former. >>>>>>> >>>>>>> -Rob >>>>>>> >>>>>>> On 18/09/14 00:21, Andrew Hughes wrote: >>>>>>>> ----- Original Message ----- >>>>>>>>> Hi Andrew, >>>>>>>>> >>>>>>>>> Sorry to be a pest, but given the scope of the change I'd feel >>>>>>>>> more >>>>>>>>> comfortable with an explicit codereview for the backport. >>>>>>>>> >>>>>>>>> -Rob >>>>>>>>> >>>>>>>>> On 17/09/14 18:32, Andrew Hughes wrote: >>>>>>>>>> This is the first of three backports to 7u designed to retain >>>>>>>>>> SSL >>>>>>>>>> compatibility with servers implemented in other languages >>>>>>>>>> switching >>>>>>>>>> to larger key sizes (notably DH>=2048 in Apache 2.4.7 [0]). >>>>>>>>>> >>>>>>>>>> This patch is a per-requisite of the patch which brings NSA >>>>>>>>>> Suite B >>>>>>>>>> support to 7. It applies largely unchanged, bar the following: >>>>>>>>>> >>>>>>>>>> * Copyright header adjustment >>>>>>>>>> * Removal of change to java.security.spec.MGF1ParameterSpec >>>>>>>>>> to avoid >>>>>>>>>> introducing a new public variable. The SHA-224 variant is >>>>>>>>>> constructed >>>>>>>>>> directly in com.sun.crypto.provider.OAEPParameters instead. >>>>>>>>>> * A change to OAEPParameters is dropped as it was already >>>>>>>>>> incorporated >>>>>>>>>> in the backport of 7180907& 8049480 (addition of SHA-224 to >>>>>>>>>> convertToStandardName) >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4963723 >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~andrew/jdk7u/4963723/webrev.01/ >>>>>>>>>> >>>>>>>>>> [0] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html >>>>>>>>>> >>>>>>>>>> Ok to push? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>> Which is what I asked for, no? >>>>>>>> >>>>>>>> If I wasn't waiting on a review first, I'd have pushed the change. >>>>>> This was the only applicable template on: >>>>>> >>>>>> http://openjdk.java.net/projects/jdk7u/ >>>>>> >>>>>> Anyway, now including security-dev for review. >>>>>> -- >>>>>> Andrew :) >>>>>> >>>>>> Free Java Software Engineer >>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>> >>>>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>>>>> >>>>>> >>>>> Ping. Any movement on this? >>>> From mmaass at andrew.cmu.edu Thu Jan 8 21:29:28 2015 From: mmaass at andrew.cmu.edu (Michael Maass) Date: Thu, 08 Jan 2015 16:29:28 -0500 Subject: Further Defenses for the Security Manager In-Reply-To: <5D4ABD71-AAA1-4EFE-A154-A5B0EC9B8FA9@oracle.com> References: <5450ED3A.6050801@andrew.cmu.edu> <5D4ABD71-AAA1-4EFE-A154-A5B0EC9B8FA9@oracle.com> Message-ID: <54AEF6B8.6040401@andrew.cmu.edu> Hello Jeff, Sorry for the delayed response. Regarding privilege escalation and class loading, our observation was that many Java exploits have an exploit class and a separate payload class. The exploit class typically attacks a vulnerability with the outcome that the payload class is loaded with elevated privileges (e.g. use a vulnerability to create a privileged ClassLoader, then use the privileged loader to load the payload). The exploit class then typically executes the payload as a PrivilegedAction. The payload at this point is running with AllPermissions. This privileged position is typically leveraged to disable the sandbox before moving on to different stages that will download and install more advanced malware. However, there is no obligation at this point to disable the sandbox in the payload, the payload class could simply perform the malicious operations straight-away as the class is effectively not sandboxed anyway (i.e. it's not sufficient to simply stop applets from setting the SecurityManager to null). Our thought was to catch cases where a payload class, which should have the same privileges as the rest of the applet's classes, is loaded with a superset of those privileges. Given this goal, I am not entirely sure these points apply as potential issues. For example, if the exploit class were preloaded by the JRE, wouldn't it be preloaded with the same privileges as the rest of the applet, thus not granting it the ability to perform its malicious operations? If I understand correctly, the same would be true for cases 1-4. Our specific and perhaps naive idea was that the JVM could inspect the stack frames when a class is being loaded to ensure that the privileges of the loaded class are a subset of the privileges for each class in the stack frames. We did not believe this needed to account for doPrivileged because it is our understanding that a class that can use a ClassLoader to load another class with more privileges and directly access the loaded, privileged class will always break the Java security model. Does this paint a reasonable picture? My understanding of JVM internals is unfortunately not very advanced. Thanks, Michael On 12/19/2014 07:47 PM, Jeff Nisewanger wrote: > Thank you for contacting us and sharing the initial results of your research. > > You raised two basic topics. > > First, you discussed the possibility of adding additional restrictions on the ability to change the system Security Manager multiple times during application execution. This is normally already subject to a security check but there might be malicious exploits that bypass the existing check. > > It turns out that we are already independently investigating this topic. We agree that such a restriction likely requires additional assistance from the JVM implementation for several reasons. > > As you mentioned, an important aspect to such a change is to minimize backwards compatibility problems. Your research on the use of security managers by existing Java applications is interesting and useful. > > You also suggested the general idea that whenever a new class is loaded we should check the granted permissions of the classes containing the methods on the thread call stack. > > You propose to ensure that each such class on the call stack has already itself been granted a superset of the permissions that would be granted to the newly loaded class. However, you would not enforce this general rule for common cases such as classes loaded by the bootstrap loader or classes within the list of restricted package names. > > Does your proposal take into account any calls to AccessController.doPrivileged() on the thread call stack? Could a thread shortcut this proposed check by causing it's action to take place on another thread (create a new thread to initiate the class loading)? > > The Java Virtual Machine specification allows for class loading to be initiated in a flexible manner that may have only a tangential relationship to the members of a thread's call stack. Examples include: > > 1. When a class is being loaded the JVM resolves the names of the superclass or super interfaces > > 2. Constant pool resolution during the execution of a bytecode instruction in a class that refers symbolically to a named class type. > > 3. Bytecode verification of another class which is in the process of being loaded. To ensure type-safety, the verifier may sometimes load other classes recursively that are symbolically referenced by a bytecode instruction (before any of the code in the class being verified is ever executed normally). > > 4. Direct calls to Class.forName(), ClassLoader.loadClass() or perhaps somehow maliciously to ClassLoader.defineClass(). > > Also, according to the specification, the JVM is free to spontaneously "pre-load" classes whenever it feels like it even if those classes have no apparent relationship with the thread chosen to load them. > > For this reason, Java class loading is generally independent of thread context except for the immediate class in which a constant pool resolution is being performed which is subject, for example, to the language-level access controls (public, protected, etc.) of the class it is referencing. > > Thanks, > Jeff > > >> On Oct 29, 2014, at 6:35 AM, Michael Maass wrote: >> >> Hello All, >> >> I've spent the last 6 months working with some colleagues on a project that aimed to stop an exploitation avenue that has been popular with recent Java exploits: disabling the security manager. We think that what ended up with may be worthy of a JEP and/or a prototype implementation in the JVM; we're looking for feedback from the experts, you folks. >> >> We initially set out to determine how benign applications interact with the security manager and to determine how those interactions differ from malicious ones. The idea was that an investigation aimed at making these determinations could show us ways to constrain operations on the manager that are backwards compatible with benign applications while blocking exploits. >> >> After investigating the open source Java landscape we learned to distinguish between (1) "self-protecting" and "defenseless" security managers and (2) the operations that may be performed in the presence of each. A defenseless manager enforces a policy that uses at least one permission in a set of permissions we identified that allow anyone to change the manager itself or the policy it enforces (a self-protecting manager is the opposite of a defenseless manager). Given this definition, we found that enforcing the following rules stopped known exploits without impeding (aside from overhead) the execution of benign applications: >> >> 1. If a self-protecting manager is set, a class may not load or cause the loading of a class more privileged than itself unless the loaded class is in a protected package (listed in the package.access property in java.security.Security). >> >> 2. If a self-protecting manager is set, an application may not change the security manager or the enforced policy in any way. >> >> We built a JVMTI agent to enforce these rules (available here: https://github.com/SecurityManagerCodeBase/JavaSandboxFortifier). Unfortunately, to use the JVMTI events that allow us to enforce rule 2, the JIT must be off, which drastically slows down the execution of applets in the presence of our agent. Rule 1 adds about 1-2% overhead. We believe overhead would drop enough for adoption if the JVM were to natively enforce these rules instead of using an agent, but we do not have the resources or the expertise to try this ourselves. >> >> Any thoughts on whether or not this type of change is worth pursing in the form of a JEP and/or prototype in the JVM? If so, is anyone willing and able to help? >> >> Thanks, >> >> Michael Maass, PhD Candidate >> Software Engineering >> Institute for Software Research >> School of Computer Science >> Carnegie Mellon University From jason.uh at oracle.com Fri Jan 9 02:46:00 2015 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 08 Jan 2015 18:46:00 -0800 Subject: [9] Request for Review: 8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled In-Reply-To: <5492EC6B.10000@oracle.com> References: <54908BAD.3010700@oracle.com> <5492EC6B.10000@oracle.com> Message-ID: <54AF40E8.5090202@oracle.com> Thanks, Sean. Here is an updated webrev with your suggested changes. I've also added tests here, and will no longer be adding tests for this changeset to the closed repo. http://cr.openjdk.java.net/~juh/8046724/01/ Thanks, Jason On 12/18/2014 07:02 AM, Sean Mullan wrote: > Just a few comments: > > - some of the methods (encodePoint, trimZeroes, ...) can be made private > static. > > 451: if getCurveOid returns null, you should throw MarshalException > instead of outputting a null Oid > > 486: if getECParameterSpec returns null, you should throw > MarshalException (otherwise an NPE would be thrown on line 498) > > 520,524: these methods should be private > > --Sean > > On 12/16/2014 02:44 PM, Jason Uh wrote: >> Please review this fix, which allows XML Signature ECKeyValue elements >> to be marshalled and unmarshalled. >> >> Dependence on internal sun.security.* classes has been removed, so that >> the (un)marshalling can happen without reflection. >> >> webrev: http://cr.openjdk.java.net/~juh/8046724/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8046724 >> >> A corresponding test will be added to the closed repository. >> >> Thanks, >> Jason From sean.mullan at oracle.com Fri Jan 9 18:50:26 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 09 Jan 2015 13:50:26 -0500 Subject: [9] Request for Review: 8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled In-Reply-To: <54AF40E8.5090202@oracle.com> References: <54908BAD.3010700@oracle.com> <5492EC6B.10000@oracle.com> <54AF40E8.5090202@oracle.com> Message-ID: <54B022F2.5070707@oracle.com> On 01/08/2015 09:46 PM, Jason Uh wrote: > Thanks, Sean. > > Here is an updated webrev with your suggested changes. I've also added > tests here, and will no longer be adding tests for this changeset to the > closed repo. > http://cr.openjdk.java.net/~juh/8046724/01/ Looks good, just one minor comment. Can you remove the comment on line 169 of KeySelectors.java? It is no longer true now that all 3 key types are supported. Thanks, Sean > > Thanks, > Jason > > On 12/18/2014 07:02 AM, Sean Mullan wrote: >> Just a few comments: >> >> - some of the methods (encodePoint, trimZeroes, ...) can be made private >> static. >> >> 451: if getCurveOid returns null, you should throw MarshalException >> instead of outputting a null Oid >> >> 486: if getECParameterSpec returns null, you should throw >> MarshalException (otherwise an NPE would be thrown on line 498) >> >> 520,524: these methods should be private >> >> --Sean >> >> On 12/16/2014 02:44 PM, Jason Uh wrote: >>> Please review this fix, which allows XML Signature ECKeyValue elements >>> to be marshalled and unmarshalled. >>> >>> Dependence on internal sun.security.* classes has been removed, so that >>> the (un)marshalling can happen without reflection. >>> >>> webrev: http://cr.openjdk.java.net/~juh/8046724/00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8046724 >>> >>> A corresponding test will be added to the closed repository. >>> >>> Thanks, >>> Jason From jason.uh at oracle.com Fri Jan 9 19:24:02 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 09 Jan 2015 11:24:02 -0800 Subject: [9] Request for Review: 8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled In-Reply-To: <54B022F2.5070707@oracle.com> References: <54908BAD.3010700@oracle.com> <5492EC6B.10000@oracle.com> <54AF40E8.5090202@oracle.com> <54B022F2.5070707@oracle.com> Message-ID: <54B02AD2.3070109@oracle.com> Thanks, I'll push after I remove that comment. Jason On 01/09/2015 10:50 AM, Sean Mullan wrote: > On 01/08/2015 09:46 PM, Jason Uh wrote: >> Thanks, Sean. >> >> Here is an updated webrev with your suggested changes. I've also added >> tests here, and will no longer be adding tests for this changeset to the >> closed repo. >> http://cr.openjdk.java.net/~juh/8046724/01/ > > Looks good, just one minor comment. Can you remove the comment on line > 169 of KeySelectors.java? It is no longer true now that all 3 key types > are supported. > > Thanks, > Sean > >> >> Thanks, >> Jason >> >> On 12/18/2014 07:02 AM, Sean Mullan wrote: >>> Just a few comments: >>> >>> - some of the methods (encodePoint, trimZeroes, ...) can be made private >>> static. >>> >>> 451: if getCurveOid returns null, you should throw MarshalException >>> instead of outputting a null Oid >>> >>> 486: if getECParameterSpec returns null, you should throw >>> MarshalException (otherwise an NPE would be thrown on line 498) >>> >>> 520,524: these methods should be private >>> >>> --Sean >>> >>> On 12/16/2014 02:44 PM, Jason Uh wrote: >>>> Please review this fix, which allows XML Signature ECKeyValue elements >>>> to be marshalled and unmarshalled. >>>> >>>> Dependence on internal sun.security.* classes has been removed, so that >>>> the (un)marshalling can happen without reflection. >>>> >>>> webrev: http://cr.openjdk.java.net/~juh/8046724/00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046724 >>>> >>>> A corresponding test will be added to the closed repository. >>>> >>>> Thanks, >>>> Jason From valerie.peng at oracle.com Mon Jan 12 21:07:08 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 12 Jan 2015 13:07:08 -0800 Subject: Review request for CR 8044193 Need to add known answer tests for AES cipher In-Reply-To: <54AC7238.2040005@oracle.com> References: <54978BEA.1050702@oracle.com> <54AC7238.2040005@oracle.com> Message-ID: <54B4377C.4060506@oracle.com> Hi, Kevin, Somehow I missed your Dec email, sorry for the late reply... I should probably clarify my earlier comments about test policies. 1) are u sure the testAESWithDefaultProvider.policy is necessary? I didn't find any add/remove provider calls in TestAESWithDefaultProviders.java? 2)The RuntimePermission fo "loadLibrary.sunec" in the testAESWithRemoveAddProvider.policy should not be needed. It could be due to an earlier bug which has been fixed. Can you please re-run the test without this permission and see if it's still necessary to have this granted? 3) The 3 test policies even though for different tests, if they have the same content, perhaps we can consolidate them into just 1. Thanks, Valerie On 1/6/2015 3:39 PM, Rajan Halade wrote: > Subject: Re: Review request for CR 8044193 Need to add known answer > tests for AES cipher > Date: Mon, 22 Dec 2014 11:11:38 +0800 > From: zaiyao liu > Organization: Oracle Corporation > To: security-dev at openjdk.java.net > > > > Hi Valeries, > > Thanks for review, please check the update: > http://cr.openjdk.java.net/~rhalade/8044193/webrev.02/ > > Regards. > > Kevin > ? 2014/8/6 3:00, Valerie Peng ??: > > > > The tests look fine. > > However, can you please update the test policy files with fine-grained > > permissions for SunJCE provider? > > Please refer to the current/lib/security/java.policy. > > > > Thanks, > > Valerie > > > > On 7/28/2014 9:36 PM, zaiyao liu wrote: > >> Hello, > >> Please help to review the tests for AES cipher. > >> This tests test AES ciphers with different modes and padding > >> schemes when provider change,are part of tests for bug 8044193(Open > >> part) > >> Bug -https://bugs.openjdk.java.net/browse/JDK-8044193 > >> webrev-http://cr.openjdk.java.net/~rhalade/8044193/webrev.00/ > >> > >> Thanks > >> > >> Kevin Liu > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.uh at oracle.com Mon Jan 12 23:56:00 2015 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 12 Jan 2015 15:56:00 -0800 Subject: [9] RFR: 8059916: Change default criticality of policy mappings and policy constraints certificate extensions Message-ID: <54B45F10.2000201@oracle.com> Please review this change, which changes the default criticality of the policy mappings and policy constraints certificate extensions. This change makes both extensions critical by default, per RFC 5280. webrev: http://cr.openjdk.java.net/~juh/8059916/01/webrev bug: https://bugs.openjdk.java.net/browse/JDK-8059916 Thanks, Jason From zaiyao.liu at oracle.com Tue Jan 13 01:37:15 2015 From: zaiyao.liu at oracle.com (zaiyao liu) Date: Tue, 13 Jan 2015 09:37:15 +0800 Subject: Review request for CR 8044193 Need to add known answer tests for AES cipher In-Reply-To: <54B4377C.4060506@oracle.com> References: <54978BEA.1050702@oracle.com> <54AC7238.2040005@oracle.com> <54B4377C.4060506@oracle.com> Message-ID: <54B476CB.4020208@oracle.com> Thanks Valerie for review. Please check the update: http://cr.openjdk.java.net/~zailiu/8044193/webrev.04/ Kevin ? 2015/1/13 5:07, Valerie Peng ??: > Hi, Kevin, > > Somehow I missed your Dec email, sorry for the late reply... > > I should probably clarify my earlier comments about test policies. > 1) are u sure the testAESWithDefaultProvider.policy is necessary? I > didn't find any add/remove provider calls in > TestAESWithDefaultProviders.java? > 2) The RuntimePermission fo "loadLibrary.sunec" in the > testAESWithRemoveAddProvider.policy should not be needed. It could be > due to an earlier bug which has been fixed. Can you please re-run the > test without this permission and see if it's still necessary to have > this granted? > 3) The 3 test policies even though for different tests, if they have > the same content, perhaps we can consolidate them into just 1. > > Thanks, > Valerie > > On 1/6/2015 3:39 PM, Rajan Halade wrote: >> Subject: Re: Review request for CR 8044193 Need to add known answer >> tests for AES cipher >> Date: Mon, 22 Dec 2014 11:11:38 +0800 >> From: zaiyao liu >> Organization: Oracle Corporation >> To: security-dev at openjdk.java.net >> >> >> >> Hi Valeries, >> >> Thanks for review, please check the update: >> http://cr.openjdk.java.net/~rhalade/8044193/webrev.02/ >> >> Regards. >> >> Kevin >> ? 2014/8/6 3:00, Valerie Peng ??: >> > >> > The tests look fine. >> > However, can you please update the test policy files with fine-grained >> > permissions for SunJCE provider? >> > Please refer to the current /lib/security/java.policy. >> > >> > Thanks, >> > Valerie >> > >> > On 7/28/2014 9:36 PM, zaiyao liu wrote: >> >> Hello, >> >> Please help to review the tests for AES cipher. >> >> This tests test AES ciphers with different modes and padding >> >> schemes when provider change,are part of tests for bug 8044193(Open >> >> part) >> >> Bug -https://bugs.openjdk.java.net/browse/JDK-8044193 >> >> webrev-http://cr.openjdk.java.net/~rhalade/8044193/webrev.00/ >> >> >> >> Thanks >> >> >> >> Kevin Liu >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Tue Jan 13 11:08:33 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 13 Jan 2015 11:08:33 +0000 Subject: [9] request for review 8059009: LDAPCertStore fails to retrieve CRL after LDAP server closes idle connection In-Reply-To: <547CAF2E.6000408@oracle.com> References: <547CAF2E.6000408@oracle.com> Message-ID: <12C72236-3F8A-4DCE-9A2C-17601BAEADED@oracle.com> Your fix looks good. Thanks. On 1 Dec 2014, at 18:10, Artem Smotrakov wrote: > Please review this fix for 9. > > It corrects the following issues: > - InitialLdapContext and LDAPCertStore does not recover connection if it was closed, for example, by server, or due to some network issue > - A cache of CertStore instances in LDAPCertStore does not work if LDAPCertStoreParameters is used > > Changes: > - updated LdapCtx to make re-connect possible > - updated LDAPCertStore to use InitialLdapContext that supports re-connect > - updated LDAPCertStore to use only SunLDAPCertStoreParameters objects for cache of CertStore instances > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059009 > Webrev: http://cr.openjdk.java.net/~asmotrak/8059009/webrev.01/ > > Artem From sean.mullan at oracle.com Tue Jan 13 12:55:22 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 13 Jan 2015 07:55:22 -0500 Subject: [9] RFR: 8059916: Change default criticality of policy mappings and policy constraints certificate extensions In-Reply-To: <54B45F10.2000201@oracle.com> References: <54B45F10.2000201@oracle.com> Message-ID: <54B515BA.1030805@oracle.com> Looks good to me. --Sean On 01/12/2015 06:56 PM, Jason Uh wrote: > Please review this change, which changes the default criticality of the > policy mappings and policy constraints certificate extensions. This > change makes both extensions critical by default, per RFC 5280. > > webrev: http://cr.openjdk.java.net/~juh/8059916/01/webrev > bug: https://bugs.openjdk.java.net/browse/JDK-8059916 > > Thanks, > Jason From jason.uh at oracle.com Tue Jan 13 18:48:35 2015 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 13 Jan 2015 10:48:35 -0800 Subject: [9] RFR: 8059916: Change default criticality of policy mappings and policy constraints certificate extensions In-Reply-To: <54B515BA.1030805@oracle.com> References: <54B45F10.2000201@oracle.com> <54B515BA.1030805@oracle.com> Message-ID: <54B56883.2070302@oracle.com> Thanks, Sean. Could you also look at one more change I've added? http://cr.openjdk.java.net/~juh/8059916/02/ Line 103 of PolicyMappingsExtension.java: - extensionId = PKIXExtensions.KeyUsage_Id; - critical = false; + extensionId = PKIXExtensions.PolicyMappings_Id; + critical = true; (Good catch, Jamil.) Jason On 1/13/15 4:55 AM, Sean Mullan wrote: > Looks good to me. > > --Sean > > On 01/12/2015 06:56 PM, Jason Uh wrote: >> Please review this change, which changes the default criticality of the >> policy mappings and policy constraints certificate extensions. This >> change makes both extensions critical by default, per RFC 5280. >> >> webrev: http://cr.openjdk.java.net/~juh/8059916/01/webrev >> bug: https://bugs.openjdk.java.net/browse/JDK-8059916 >> >> Thanks, >> Jason From sean.mullan at oracle.com Tue Jan 13 22:06:32 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 13 Jan 2015 17:06:32 -0500 Subject: [9] RFR: 8059916: Change default criticality of policy mappings and policy constraints certificate extensions In-Reply-To: <54B56883.2070302@oracle.com> References: <54B45F10.2000201@oracle.com> <54B515BA.1030805@oracle.com> <54B56883.2070302@oracle.com> Message-ID: <54B596E8.50805@oracle.com> Looks good. --Sean On 01/13/2015 01:48 PM, Jason Uh wrote: > Thanks, Sean. Could you also look at one more change I've added? > > http://cr.openjdk.java.net/~juh/8059916/02/ > > Line 103 of PolicyMappingsExtension.java: > - extensionId = PKIXExtensions.KeyUsage_Id; > - critical = false; > + extensionId = PKIXExtensions.PolicyMappings_Id; > + critical = true; > > (Good catch, Jamil.) > > Jason > > On 1/13/15 4:55 AM, Sean Mullan wrote: >> Looks good to me. >> >> --Sean >> >> On 01/12/2015 06:56 PM, Jason Uh wrote: >>> Please review this change, which changes the default criticality of the >>> policy mappings and policy constraints certificate extensions. This >>> change makes both extensions critical by default, per RFC 5280. >>> >>> webrev: http://cr.openjdk.java.net/~juh/8059916/01/webrev >>> bug: https://bugs.openjdk.java.net/browse/JDK-8059916 >>> >>> Thanks, >>> Jason > From valerie.peng at oracle.com Tue Jan 13 23:17:57 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 13 Jan 2015 15:17:57 -0800 Subject: Review request for CR 8044193 Need to add known answer tests for AES cipher In-Reply-To: <54B476CB.4020208@oracle.com> References: <54978BEA.1050702@oracle.com> <54AC7238.2040005@oracle.com> <54B4377C.4060506@oracle.com> <54B476CB.4020208@oracle.com> Message-ID: <54B5A7A5.6030108@oracle.com> Updated changes look good. Thanks, Valerie On 1/12/2015 5:37 PM, zaiyao liu wrote: > Thanks Valerie for review. Please check the update: > http://cr.openjdk.java.net/~zailiu/8044193/webrev.04/ > > Kevin > ? 2015/1/13 5:07, Valerie Peng ??: >> Hi, Kevin, >> >> Somehow I missed your Dec email, sorry for the late reply... >> >> I should probably clarify my earlier comments about test policies. >> 1) are u sure the testAESWithDefaultProvider.policy is necessary? I >> didn't find any add/remove provider calls in >> TestAESWithDefaultProviders.java? >> 2) The RuntimePermission fo "loadLibrary.sunec" in the >> testAESWithRemoveAddProvider.policy should not be needed. It could be >> due to an earlier bug which has been fixed. Can you please re-run the >> test without this permission and see if it's still necessary to have >> this granted? >> 3) The 3 test policies even though for different tests, if they have >> the same content, perhaps we can consolidate them into just 1. >> >> Thanks, >> Valerie >> >> On 1/6/2015 3:39 PM, Rajan Halade wrote: >>> Subject: Re: Review request for CR 8044193 Need to add known answer >>> tests for AES cipher >>> Date: Mon, 22 Dec 2014 11:11:38 +0800 >>> From: zaiyao liu >>> Organization: Oracle Corporation >>> To: security-dev at openjdk.java.net >>> >>> >>> >>> Hi Valeries, >>> >>> Thanks for review, please check the update: >>> http://cr.openjdk.java.net/~rhalade/8044193/webrev.02/ >>> >>> Regards. >>> >>> Kevin >>> ? 2014/8/6 3:00, Valerie Peng ??: >>> > >>> > The tests look fine. >>> > However, can you please update the test policy files with fine-grained >>> > permissions for SunJCE provider? >>> > Please refer to the current/lib/security/java.policy. >>> > >>> > Thanks, >>> > Valerie >>> > >>> > On 7/28/2014 9:36 PM, zaiyao liu wrote: >>> >> Hello, >>> >> Please help to review the tests for AES cipher. >>> >> This tests test AES ciphers with different modes and padding >>> >> schemes when provider change,are part of tests for bug 8044193(Open >>> >> part) >>> >> Bug -https://bugs.openjdk.java.net/browse/JDK-8044193 >>> >> webrev-http://cr.openjdk.java.net/~rhalade/8044193/webrev.00/ >>> >> >>> >> Thanks >>> >> >>> >> Kevin Liu >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Jan 14 18:10:36 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 14 Jan 2015 18:10:36 +0000 Subject: PING 2: [7u80] Request for review for CR 4963723: Implement SHA-224 In-Reply-To: <54AED5A9.8000301@oracle.com> References: <155489540.24500766.1410975144648.JavaMail.zimbra@redhat.com> <5419FA7F.903@oracle.com> <965519084.24587907.1410996112530.JavaMail.zimbra@redhat.com> <541A19D1.40606@oracle.com> <43988642.26705122.1411395941534.JavaMail.zimbra@redhat.com> <386426516.2373337.1412176298444.JavaMail.zimbra@redhat.com> <542D1374.8030608@oracle.com> <277967304.797105.1419351204764.JavaMail.zimbra@redhat.com> <54ADC198.5040307@oracle.com> <54ADE36E.8090202@oracle.com> <54AED5A9.8000301@oracle.com> Message-ID: <54B6B11C.4030307@oracle.com> Andrew, Can I ask what the status of the 7044060 patch is like for jdk7u ? Is it also ready for review ? 7044060: Need to support NSA Suite B Cryptography algorithms Some argue that the benefits of the 4963723/SHA-224 fix are minor without the above bug fix also being ready. I presume there are settings on the Apache webserver that allow it to still accept DH keys of less than 2048 bits. Is that the case ? regards, Sean. On 08/01/15 19:08, Se?n Coffey wrote: > Thanks for the code reviews Valerie. > > Andrew - looks like you need to submit new review with 7169496. Note > that you still need to file for approval once code review is complete > : http://openjdk.java.net/projects/jdk7u/groundrules.html > > I'm just being cautious on this one given the possible behavioural > impact, the docs impact and the QA impact. A CCC may be required. I > can help on that front - I'lll know more by next week. > > regards, > Sean. > > On 08/01/2015 01:54, Valerie Peng wrote: >> Changes on Tests look fine. >> Regards, >> Valerie >> >> On 1/7/2015 3:30 PM, Valerie Peng wrote: >>> >>> I looked through the source changes and they look fine, except that >>> the following related fix should also be combined for completeness: >>> >>> 7169496: Problem with the SHA-224 support for SunMSCAPI provider >>> webrev for 7169496: >>> http://cr.openjdk.java.net/~valeriep/7169496/webrev.00/ >>> >>> As for the test changes, I am still looking at them. Will let you >>> know once I am done. >>> Thanks, >>> Valerie >>> >>> On 12/23/2014 8:13 AM, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> Valerie Peng (original author) is probably best suited to >>>>> reviewing this >>>>> but I think she's out of the office the moment and back next week. >>>>> Let's >>>>> hope we can get an update/review then. >>>>> >>>> Hi, >>>> >>>> Any movement on this? It's been three months. >>>> >>>> Thanks. >>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> On 01/10/2014 16:11, Andrew Hughes wrote: >>>>>> ----- Original Message ----- >>>>>>> ----- Original Message ----- >>>>>>>> Code changes generally require two approvals: codereview, >>>>>>>> performed by a >>>>>>>> reviewer, (in this case from security-dev) and push approval, >>>>>>>> performed >>>>>>>> by a gatekeeper. Given your email template matches the push >>>>>>>> approval >>>>>>>> template I understood that you intended the latter. Generally >>>>>>>> speaking >>>>>>>> codereview requests would say "Request for review" as opposed to >>>>>>>> "Request for approval" so a reviewer could overlook your mail >>>>>>>> if you >>>>>>>> intended the former. >>>>>>>> >>>>>>>> -Rob >>>>>>>> >>>>>>>> On 18/09/14 00:21, Andrew Hughes wrote: >>>>>>>>> ----- Original Message ----- >>>>>>>>>> Hi Andrew, >>>>>>>>>> >>>>>>>>>> Sorry to be a pest, but given the scope of the change I'd >>>>>>>>>> feel more >>>>>>>>>> comfortable with an explicit codereview for the backport. >>>>>>>>>> >>>>>>>>>> -Rob >>>>>>>>>> >>>>>>>>>> On 17/09/14 18:32, Andrew Hughes wrote: >>>>>>>>>>> This is the first of three backports to 7u designed to >>>>>>>>>>> retain SSL >>>>>>>>>>> compatibility with servers implemented in other languages >>>>>>>>>>> switching >>>>>>>>>>> to larger key sizes (notably DH>=2048 in Apache 2.4.7 [0]). >>>>>>>>>>> >>>>>>>>>>> This patch is a per-requisite of the patch which brings NSA >>>>>>>>>>> Suite B >>>>>>>>>>> support to 7. It applies largely unchanged, bar the following: >>>>>>>>>>> >>>>>>>>>>> * Copyright header adjustment >>>>>>>>>>> * Removal of change to java.security.spec.MGF1ParameterSpec >>>>>>>>>>> to avoid >>>>>>>>>>> introducing a new public variable. The SHA-224 variant is >>>>>>>>>>> constructed >>>>>>>>>>> directly in com.sun.crypto.provider.OAEPParameters instead. >>>>>>>>>>> * A change to OAEPParameters is dropped as it was already >>>>>>>>>>> incorporated >>>>>>>>>>> in the backport of 7180907& 8049480 (addition of SHA-224 to >>>>>>>>>>> convertToStandardName) >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4963723 >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~andrew/jdk7u/4963723/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> [0] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html >>>>>>>>>>> >>>>>>>>>>> Ok to push? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>> Which is what I asked for, no? >>>>>>>>> >>>>>>>>> If I wasn't waiting on a review first, I'd have pushed the >>>>>>>>> change. >>>>>>> This was the only applicable template on: >>>>>>> >>>>>>> http://openjdk.java.net/projects/jdk7u/ >>>>>>> >>>>>>> Anyway, now including security-dev for review. >>>>>>> -- >>>>>>> Andrew :) >>>>>>> >>>>>>> Free Java Software Engineer >>>>>>> Red Hat, Inc. (http://www.redhat.com) >>>>>>> >>>>>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>>>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>>>>>> >>>>>>> >>>>>> Ping. Any movement on this? >>>>> > From weijun.wang at oracle.com Thu Jan 15 04:10:17 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 15 Jan 2015 12:10:17 +0800 Subject: RFR 8022582: Relax response flags checking in sun.security.krb5.KrbKdcRep.check. Message-ID: <5FA2E532-5E0C-4647-8659-89ACF6119B0D@oracle.com> Hi All Please review the code changes at http://cr.openjdk.java.net/~weijun/8022582/webrev.00 Sometimes a forwardable ticket request is sent but KDC returns a non-forwardable one. For example, in Windows, an account can be set as "sensitive and cannot be delegated". While it's possible to remove the "forwardable=true" line in krb5.conf to avoid the check failure, the file is global and maybe another account wants to be delegated. Therefore we just to relax the forwardable check. KrbTgsReq is also modified so that one can get a service ticket when TGT is not forwardable. One special case is S4U2self request, both the existing ticket and the expected ticket must be forwardable, and we fail early if one is not. A new test simulates the "sensitive account" concept in Windows. Thanks Max From sean.coffey at oracle.com Thu Jan 15 10:28:46 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 15 Jan 2015 10:28:46 +0000 Subject: DSA with keylength > 1024 no longer accepted In-Reply-To: <54B79223.4060805@certitrade.net> References: <54B79223.4060805@certitrade.net> Message-ID: <54B7965E.8010109@oracle.com> Hi Peter, security-dev is best mailing list to discuss this issue, I'm cc'ing that list and bcc'ing off jdk7u-dev. Are you hitting this issue with JDK 8 and later ? (I'll assume so) - You've hit https://bugs.openjdk.java.net/browse/JDK-8039921 To aid compatibility, it's been decided to relax that restriction from 8u60 and later. See comments in bug report around use of SHA1 and SHA2 and the length of keys that should be used in each operation. Hope that helps. regards, Sean. On 15/01/2015 10:10, Peter Haraldson wrote: > Hi > First, I'm not quite sure if this is the correct list for this issue, > please excuse & correct me if it's not. > > Our problem is that in latest openjdk a check is added that makes our > certificates with DSA & Keylength 2048 unusable. In file > "sun.security.provider.DSA" line 484-489: > protected void checkKey(DSAParams params) throws > InvalidKeyException { > int valueL = params.getP().bitLength(); > if (valueL > 1024) { > throw new InvalidKeyException("Key is too long for > this algorithm"); > } > } > This is new, these certificates worked fine before. I don't know the > reason for not accepting longer keys than 1024, not allowing too short > keys would make sense to me but not allowing long keys? > > We need to find a permanent solution, as for now we can't update our > production servers because of this. We have several certificates > issued by MasterCard, it is a very tedious job to change them all. > Is there a way we could bypass this, could this check be abandoned in > next update? > > Our system: > java version "1.7.0_65" (not affected) > OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17) > OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) > OS: RedHat 6.6 > > Regards Peter From erik.joelsson at oracle.com Thu Jan 15 11:05:34 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Jan 2015 12:05:34 +0100 Subject: RFR: JDK-8068748: missing US_export_policy.jar in jdk9-b44 is causing compilation errors building jdk9 source code Message-ID: <54B79EFE.7050202@oracle.com> Hello, Please review the open part of this patch, which changes the building of policy jars to happen even if BUILD_CRYPTO is false. Previously these weren't built as there were signed versions of these jars, but since we no longer sign them, there is no need to not build them. Bug: https://bugs.openjdk.java.net/browse/JDK-8068748 Webrev: http://cr.openjdk.java.net/~erikj/8068748/webrev.jdk.01/ The webrev diffs look a bit weird. The only thing I did was to remove the "ifneq ($(BUILD_CRYPTO), no)" and adjust the indentation. /Erik From fweimer at redhat.com Thu Jan 15 11:10:37 2015 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 15 Jan 2015 12:10:37 +0100 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: <53F1F272.3030705@redhat.com> References: <53F1F272.3030705@redhat.com> Message-ID: <54B7A02D.7010305@redhat.com> On 08/18/2014 02:32 PM, Florian Weimer wrote: > This change addresses a severe performance regression, first introduced > in JDK 8, triggered by the negotiation of a GCM cipher suite in the TLS > implementation. This regression is a result of the poor performance of > the implementation of the GHASH function. > > I first tried to eliminate just the allocations in blockMult while still > retaining the byte arrays. This did not substantially increase > performance in my micro-benchmark. I then replaced the 16-byte arrays > with longs, replaced the inner loops with direct bit fiddling on the > longs, eliminated data-dependent conditionals (which are generally > frowned upon in cryptographic algorithms due to the risk of timing > attacks), and split the main loop in two, one for each half of the hash > state. This is the result: > > Updated webrev: Anthony, could you file a bug so that I can include its number? Thanks. -- Florian Weimer / Red Hat Product Security From anthony.scarpino at oracle.com Thu Jan 15 16:24:58 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 15 Jan 2015 08:24:58 -0800 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: <54B7A02D.7010305@redhat.com> References: <53F1F272.3030705@redhat.com> <54B7A02D.7010305@redhat.com> Message-ID: <54B7E9DA.1070404@oracle.com> On 01/15/2015 03:10 AM, Florian Weimer wrote: > On 08/18/2014 02:32 PM, Florian Weimer wrote: >> This change addresses a severe performance regression, first introduced >> in JDK 8, triggered by the negotiation of a GCM cipher suite in the TLS >> implementation. This regression is a result of the poor performance of >> the implementation of the GHASH function. >> >> I first tried to eliminate just the allocations in blockMult while still >> retaining the byte arrays. This did not substantially increase >> performance in my micro-benchmark. I then replaced the 16-byte arrays >> with longs, replaced the inner loops with direct bit fiddling on the >> longs, eliminated data-dependent conditionals (which are generally >> frowned upon in cryptographic algorithms due to the risk of timing >> attacks), and split the main loop in two, one for each half of the hash >> state. This is the result: >> >> > > Updated webrev: > > Anthony, could you file a bug so that I can include its number? Thanks. > Here it is: https://bugs.openjdk.java.net/browse/JDK-8069072 Tony From mmaass at andrew.cmu.edu Thu Jan 15 16:39:17 2015 From: mmaass at andrew.cmu.edu (Michael Maass) Date: Thu, 15 Jan 2015 11:39:17 -0500 Subject: Further Defenses for the Security Manager In-Reply-To: <5D4ABD71-AAA1-4EFE-A154-A5B0EC9B8FA9@oracle.com> References: <5450ED3A.6050801@andrew.cmu.edu> <5D4ABD71-AAA1-4EFE-A154-A5B0EC9B8FA9@oracle.com> Message-ID: <54B7ED35.7090609@andrew.cmu.edu> Is there a standard corpus of applets that Oracle would use to test this kind of feature? I am need of an applet corpus and I am wondering if there is something out there already that you folks use. Michael On 12/19/2014 07:47 PM, Jeff Nisewanger wrote: > Thank you for contacting us and sharing the initial results of your research. > > You raised two basic topics. > > First, you discussed the possibility of adding additional restrictions on the ability to change the system Security Manager multiple times during application execution. This is normally already subject to a security check but there might be malicious exploits that bypass the existing check. > > It turns out that we are already independently investigating this topic. We agree that such a restriction likely requires additional assistance from the JVM implementation for several reasons. > > As you mentioned, an important aspect to such a change is to minimize backwards compatibility problems. Your research on the use of security managers by existing Java applications is interesting and useful. > > You also suggested the general idea that whenever a new class is loaded we should check the granted permissions of the classes containing the methods on the thread call stack. > > You propose to ensure that each such class on the call stack has already itself been granted a superset of the permissions that would be granted to the newly loaded class. However, you would not enforce this general rule for common cases such as classes loaded by the bootstrap loader or classes within the list of restricted package names. > > Does your proposal take into account any calls to AccessController.doPrivileged() on the thread call stack? Could a thread shortcut this proposed check by causing it's action to take place on another thread (create a new thread to initiate the class loading)? > > The Java Virtual Machine specification allows for class loading to be initiated in a flexible manner that may have only a tangential relationship to the members of a thread's call stack. Examples include: > > 1. When a class is being loaded the JVM resolves the names of the superclass or super interfaces > > 2. Constant pool resolution during the execution of a bytecode instruction in a class that refers symbolically to a named class type. > > 3. Bytecode verification of another class which is in the process of being loaded. To ensure type-safety, the verifier may sometimes load other classes recursively that are symbolically referenced by a bytecode instruction (before any of the code in the class being verified is ever executed normally). > > 4. Direct calls to Class.forName(), ClassLoader.loadClass() or perhaps somehow maliciously to ClassLoader.defineClass(). > > Also, according to the specification, the JVM is free to spontaneously "pre-load" classes whenever it feels like it even if those classes have no apparent relationship with the thread chosen to load them. > > For this reason, Java class loading is generally independent of thread context except for the immediate class in which a constant pool resolution is being performed which is subject, for example, to the language-level access controls (public, protected, etc.) of the class it is referencing. > > Thanks, > Jeff > > >> On Oct 29, 2014, at 6:35 AM, Michael Maass wrote: >> >> Hello All, >> >> I've spent the last 6 months working with some colleagues on a project that aimed to stop an exploitation avenue that has been popular with recent Java exploits: disabling the security manager. We think that what ended up with may be worthy of a JEP and/or a prototype implementation in the JVM; we're looking for feedback from the experts, you folks. >> >> We initially set out to determine how benign applications interact with the security manager and to determine how those interactions differ from malicious ones. The idea was that an investigation aimed at making these determinations could show us ways to constrain operations on the manager that are backwards compatible with benign applications while blocking exploits. >> >> After investigating the open source Java landscape we learned to distinguish between (1) "self-protecting" and "defenseless" security managers and (2) the operations that may be performed in the presence of each. A defenseless manager enforces a policy that uses at least one permission in a set of permissions we identified that allow anyone to change the manager itself or the policy it enforces (a self-protecting manager is the opposite of a defenseless manager). Given this definition, we found that enforcing the following rules stopped known exploits without impeding (aside from overhead) the execution of benign applications: >> >> 1. If a self-protecting manager is set, a class may not load or cause the loading of a class more privileged than itself unless the loaded class is in a protected package (listed in the package.access property in java.security.Security). >> >> 2. If a self-protecting manager is set, an application may not change the security manager or the enforced policy in any way. >> >> We built a JVMTI agent to enforce these rules (available here: https://github.com/SecurityManagerCodeBase/JavaSandboxFortifier). Unfortunately, to use the JVMTI events that allow us to enforce rule 2, the JIT must be off, which drastically slows down the execution of applets in the presence of our agent. Rule 1 adds about 1-2% overhead. We believe overhead would drop enough for adoption if the JVM were to natively enforce these rules instead of using an agent, but we do not have the resources or the expertise to try this ourselves. >> >> Any thoughts on whether or not this type of change is worth pursing in the form of a JEP and/or prototype in the JVM? If so, is anyone willing and able to help? >> >> Thanks, >> >> Michael Maass, PhD Candidate >> Software Engineering >> Institute for Software Research >> School of Computer Science >> Carnegie Mellon University From mstjohns at comcast.net Thu Jan 15 19:31:37 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 15 Jan 2015 14:31:37 -0500 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: <54B7A02D.7010305@redhat.com> References: <53F1F272.3030705@redhat.com> <54B7A02D.7010305@redhat.com> Message-ID: Just for curiosity, what was the improvement in performance? I'm wondering if it might be worthwhile to see if its possible to add a plugin to use the hardware instructions: http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/communications-ia-galois-counter-mode-paper.pdf Mike At 06:10 AM 1/15/2015, Florian Weimer wrote: >On 08/18/2014 02:32 PM, Florian Weimer wrote: >>This change addresses a severe performance regression, first introduced >>in JDK 8, triggered by the negotiation of a GCM cipher suite in the TLS >>implementation. This regression is a result of the poor performance of >>the implementation of the GHASH function. >> >>I first tried to eliminate just the allocations in blockMult while still >>retaining the byte arrays. This did not substantially increase >>performance in my micro-benchmark. I then replaced the 16-byte arrays >>with longs, replaced the inner loops with direct bit fiddling on the >>longs, eliminated data-dependent conditionals (which are generally >>frowned upon in cryptographic algorithms due to the risk of timing >>attacks), and split the main loop in two, one for each half of the hash >>state. This is the result: >> >> > >Updated webrev: > >Anthony, could you file a bug so that I can include its number? Thanks. > >-- >Florian Weimer / Red Hat Product Security From anthony.scarpino at oracle.com Thu Jan 15 20:14:03 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 15 Jan 2015 12:14:03 -0800 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: <201501151931.t0FJVeJl026559@userp2030.oracle.com> References: <53F1F272.3030705@redhat.com> <54B7A02D.7010305@redhat.com> <201501151931.t0FJVeJl026559@userp2030.oracle.com> Message-ID: Florian had posted months back about it giving 10x improvement. Hardware acceleration is an separate project as it is mostly changes to hotspot. Tony > On Jan 15, 2015, at 11:31 AM, Michael StJohns wrote: > > Just for curiosity, what was the improvement in performance? > > I'm wondering if it might be worthwhile to see if its possible to add a plugin to use the hardware instructions: > > http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/communications-ia-galois-counter-mode-paper.pdf > > Mike > > At 06:10 AM 1/15/2015, Florian Weimer wrote: >>> On 08/18/2014 02:32 PM, Florian Weimer wrote: >>> This change addresses a severe performance regression, first introduced >>> in JDK 8, triggered by the negotiation of a GCM cipher suite in the TLS >>> implementation. This regression is a result of the poor performance of >>> the implementation of the GHASH function. >>> >>> I first tried to eliminate just the allocations in blockMult while still >>> retaining the byte arrays. This did not substantially increase >>> performance in my micro-benchmark. I then replaced the 16-byte arrays >>> with longs, replaced the inner loops with direct bit fiddling on the >>> longs, eliminated data-dependent conditionals (which are generally >>> frowned upon in cryptographic algorithms due to the risk of timing >>> attacks), and split the main loop in two, one for each half of the hash >>> state. This is the result: >>> >>> >> >> Updated webrev: >> >> Anthony, could you file a bug so that I can include its number? Thanks. >> >> -- >> Florian Weimer / Red Hat Product Security > > From fweimer at redhat.com Thu Jan 15 20:26:38 2015 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 15 Jan 2015 21:26:38 +0100 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: <201501151945.t0FJj2FF029891@mx1.redhat.com> References: <53F1F272.3030705@redhat.com> <54B7A02D.7010305@redhat.com> <201501151945.t0FJj2FF029891@mx1.redhat.com> Message-ID: <54B8227E.2070404@redhat.com> On 01/15/2015 08:31 PM, Michael StJohns wrote: > Just for curiosity, what was the improvement in performance? Tim Whittington posted independent benchmark numbers here: He could reproduce the 10x improvement quoted in the bug and the original submission. > I'm wondering if it might be worthwhile to see if its possible to add a plugin to use the hardware instructions: > > http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/communications-ia-galois-counter-mode-paper.pdf Yes, they are going to help quite a bit as well. The other thing we need to fix for TLS is that AES-GCM is a garbage collector stress test. Last time I looked, for each transferred byte, there were four bytes allocated on the heap. -- Florian Weimer / Red Hat Product Security From joe.darcy at oracle.com Fri Jan 16 00:39:26 2015 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 15 Jan 2015 16:39:26 -0800 Subject: JDK 9 RFR of JDK-8069127: Suppress deprecation warnings in jdk.deploy.osx module Message-ID: <54B85DBE.6030209@oracle.com> Hello, Please review these simple changes to address a few stray deprecation warnings in the jdk.deploy.osx module: JDK-8069127: Suppress deprecation warnings in jdk.deploy.osx module http://cr.openjdk.java.net/~darcy/8069127.0/ The patch is --- old/src/jdk.deploy.osx/macosx/classes/apple/security/KeychainStore.java 2015-01-15 16:36:49.547707664 -0800 +++ new/src/jdk.deploy.osx/macosx/classes/apple/security/KeychainStore.java 2015-01-15 16:36:49.359707672 -0800 @@ -911,6 +911,7 @@ return true; } + @SuppressWarnings("deprecation") private byte[] fetchPrivateKeyFromBag(byte[] privateKeyInfo) throws IOException, NoSuchAlgorithmException, CertificateException { byte[] returnValue = null; @@ -971,6 +972,7 @@ return returnValue; } + @SuppressWarnings("deprecation") private byte[] extractKeyData(DerInputStream stream) throws IOException, NoSuchAlgorithmException, CertificateException { Thanks, -Joe From bradford.wetmore at oracle.com Fri Jan 16 00:42:54 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 15 Jan 2015 16:42:54 -0800 Subject: JDK 9 RFR of JDK-8069127: Suppress deprecation warnings in jdk.deploy.osx module In-Reply-To: <54B85DBE.6030209@oracle.com> References: <54B85DBE.6030209@oracle.com> Message-ID: <54B85E8E.7020507@oracle.com> Looks good. Thanks. Brad On 1/15/2015 4:39 PM, joe darcy wrote: > Hello, > > Please review these simple changes to address a few stray deprecation > warnings in the jdk.deploy.osx module: > > JDK-8069127: Suppress deprecation warnings in jdk.deploy.osx module > http://cr.openjdk.java.net/~darcy/8069127.0/ > > The patch is > > --- > old/src/jdk.deploy.osx/macosx/classes/apple/security/KeychainStore.java > 2015-01-15 16:36:49.547707664 -0800 > +++ > new/src/jdk.deploy.osx/macosx/classes/apple/security/KeychainStore.java > 2015-01-15 16:36:49.359707672 -0800 > @@ -911,6 +911,7 @@ > return true; > } > > + @SuppressWarnings("deprecation") > private byte[] fetchPrivateKeyFromBag(byte[] privateKeyInfo) > throws IOException, NoSuchAlgorithmException, CertificateException > { > byte[] returnValue = null; > @@ -971,6 +972,7 @@ > return returnValue; > } > > + @SuppressWarnings("deprecation") > private byte[] extractKeyData(DerInputStream stream) > throws IOException, NoSuchAlgorithmException, > CertificateException > { > > Thanks, > > -Joe From bradford.wetmore at oracle.com Fri Jan 16 01:56:48 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 15 Jan 2015 17:56:48 -0800 Subject: RFR: JDK-8068748: missing US_export_policy.jar in jdk9-b44 is causing compilation errors building jdk9 source code In-Reply-To: <54B79EFE.7050202@oracle.com> References: <54B79EFE.7050202@oracle.com> Message-ID: <54B86FE0.3000908@oracle.com> Looks good, thanks for fixing this! Brad On 1/15/2015 3:05 AM, Erik Joelsson wrote: > Hello, > > Please review the open part of this patch, which changes the building of > policy jars to happen even if BUILD_CRYPTO is false. Previously these > weren't built as there were signed versions of these jars, but since we > no longer sign them, there is no need to not build them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068748 > Webrev: http://cr.openjdk.java.net/~erikj/8068748/webrev.jdk.01/ > > The webrev diffs look a bit weird. The only thing I did was to remove > the "ifneq ($(BUILD_CRYPTO), no)" and adjust the indentation. > > /Erik From anthony.scarpino at oracle.com Fri Jan 16 08:18:35 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 16 Jan 2015 00:18:35 -0800 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: <54B8227E.2070404@redhat.com> References: <53F1F272.3030705@redhat.com> <54B7A02D.7010305@redhat.com> <201501151945.t0FJj2FF029891@mx1.redhat.com> <54B8227E.2070404@redhat.com> Message-ID: > On Jan 15, 2015, at 12:26 PM, Florian Weimer wrote: > > Yes, they are going to help quite a bit as well. The other thing we need to fix for TLS is that AES-GCM is a garbage collector stress test. Last time I looked, for each transferred byte, there were four bytes allocated on the heap. What exactly are you referring to here? Is there a problem in TLS where it is using too much memory for AES-GCM specifically or AES-GCM itself is using too much memory? What test did you do to see this heap allocation or is this code inspection? thanks Tony From jdk-security-dev at whittington.net.nz Fri Jan 16 08:38:36 2015 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Fri, 16 Jan 2015 21:38:36 +1300 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: References: <53F1F272.3030705@redhat.com> <54B7A02D.7010305@redhat.com> <201501151945.t0FJj2FF029891@mx1.redhat.com> <54B8227E.2070404@redhat.com> Message-ID: <85BE90A3-AC63-4401-BAF6-9102B70EB56A@whittington.net.nz> On 16/01/2015, at 9:18 pm, Anthony Scarpino wrote: >> On Jan 15, 2015, at 12:26 PM, Florian Weimer wrote: >> >> Yes, they are going to help quite a bit as well. The other thing we need to fix for TLS is that AES-GCM is a garbage collector stress test. Last time I looked, for each transferred byte, there were four bytes allocated on the heap. > > What exactly are you referring to here? Is there a problem in TLS where it is using too much memory for AES-GCM specifically or AES-GCM itself is using too much memory? What test did you do to see this heap allocation or is this code inspection? > The GCM implementation (jdk/src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java) does a lot of unnecessary data copying/allocation: - AAD is buffered in a ByteArrayOutputStream and accessed with toByteArray() = unnecessary copy of all AAD to buffer and to new array - on decrypt, all ciphertext is buffered in a ByteArrayOutputStream, accessed with toByteArray() = unnecessary copying of all ciphertext data to new array (twice if you don?t buy that it should buffer ciphertext) - all of the block pad/length block operations allocate new arrays (they could all use a preallocated per-cipher buffer) - there are a bunch of other byte[] allocations that could probably be eliminated ByteArrayOutputStream buffer can be trivially accessed to avoid copy, and the AAD buffer can probably be avoided entirely. I haven?t checked to see if JSSE is using the in[], out[] variants of update/doFinal to avoid copying there. cheers tim > thanks > > Tony > From ivan.gerasimov at oracle.com Fri Jan 16 12:32:07 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 16 Jan 2015 15:32:07 +0300 Subject: Request for review : 8032573 - CertificateFactory.getInstance("X.509").generateCertificates(InputStream) does not throw CertificateException for invalid input In-Reply-To: <549B117F.9050504@oracle.com> References: <54997943.6020706@oracle.com> <549B117F.9050504@oracle.com> Message-ID: <54B904C7.2060906@oracle.com> Hi everyone! I'm taking over this backport by Mala. Can I consider it reviewed, given the comment is corrected? Sincerely yours, Ivan On 24.12.2014 22:18, Jamil Nimeh wrote: > Hi Mala, the backport looks good to me. Only one nit: I think the > comment "no crls provided" in X509Factory.java:461 should be removed > since you have the corrected comment in there. > > For what it's worth I'm not an approved reviewer on the census yet so > you might need someone else to give the official OK. > > Cheers! > --Jamil > > On 12/23/2014 6:16 AM, mala bankal wrote: >> HI Jamil, All, >> >> Request your review for backport of bug# 8032573 to 7u-dev. >> >> https://bugs.openjdk.java.net/browse/JDK-8032573 >> >> webrev: >> http://cr.openjdk.java.net/~mbankal/8032573/webrev.00/ >> >> rgds >> mala > > > From sean.mullan at oracle.com Fri Jan 16 12:41:36 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Jan 2015 07:41:36 -0500 Subject: Request for review : 8032573 - CertificateFactory.getInstance("X.509").generateCertificates(InputStream) does not throw CertificateException for invalid input In-Reply-To: <54B904C7.2060906@oracle.com> References: <54997943.6020706@oracle.com> <549B117F.9050504@oracle.com> <54B904C7.2060906@oracle.com> Message-ID: <54B90700.4020902@oracle.com> On 01/16/2015 07:32 AM, Ivan Gerasimov wrote: > Hi everyone! > > I'm taking over this backport by Mala. > Can I consider it reviewed, given the comment is corrected? Yes, you can add me as the reviewer. --Sean > > Sincerely yours, > Ivan > > On 24.12.2014 22:18, Jamil Nimeh wrote: >> Hi Mala, the backport looks good to me. Only one nit: I think the >> comment "no crls provided" in X509Factory.java:461 should be removed >> since you have the corrected comment in there. >> >> For what it's worth I'm not an approved reviewer on the census yet so >> you might need someone else to give the official OK. >> >> Cheers! >> --Jamil >> >> On 12/23/2014 6:16 AM, mala bankal wrote: >>> HI Jamil, All, >>> >>> Request your review for backport of bug# 8032573 to 7u-dev. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032573 >>> >>> webrev: >>> http://cr.openjdk.java.net/~mbankal/8032573/webrev.00/ >>> >>> rgds >>> mala >> >> >> > From ivan.gerasimov at oracle.com Fri Jan 16 12:49:53 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 16 Jan 2015 15:49:53 +0300 Subject: Request for review : 8032573 - CertificateFactory.getInstance("X.509").generateCertificates(InputStream) does not throw CertificateException for invalid input In-Reply-To: <54B90700.4020902@oracle.com> References: <54997943.6020706@oracle.com> <549B117F.9050504@oracle.com> <54B904C7.2060906@oracle.com> <54B90700.4020902@oracle.com> Message-ID: <54B908F1.6030405@oracle.com> Thanks! On 16.01.2015 15:41, Sean Mullan wrote: > On 01/16/2015 07:32 AM, Ivan Gerasimov wrote: >> Hi everyone! >> >> I'm taking over this backport by Mala. >> Can I consider it reviewed, given the comment is corrected? > > Yes, you can add me as the reviewer. > > --Sean > >> >> Sincerely yours, >> Ivan >> >> On 24.12.2014 22:18, Jamil Nimeh wrote: >>> Hi Mala, the backport looks good to me. Only one nit: I think the >>> comment "no crls provided" in X509Factory.java:461 should be removed >>> since you have the corrected comment in there. >>> >>> For what it's worth I'm not an approved reviewer on the census yet so >>> you might need someone else to give the official OK. >>> >>> Cheers! >>> --Jamil >>> >>> On 12/23/2014 6:16 AM, mala bankal wrote: >>>> HI Jamil, All, >>>> >>>> Request your review for backport of bug# 8032573 to 7u-dev. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032573 >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~mbankal/8032573/webrev.00/ >>>> >>>> rgds >>>> mala >>> >>> >>> >> > > From jaroslav.bachorik at oracle.com Fri Jan 16 19:09:38 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 16 Jan 2015 20:09:38 +0100 Subject: RFR 8064331: JavaSecurityAccess.doIntersectionPrivilege() drops the information about the domain combiner of the stack ACC Message-ID: <54B961F2.9000603@oracle.com> Please, review the following change. Issue : https://bugs.openjdk.java.net/browse/JDK-8064331 Webrev: http://cr.openjdk.java.net/~jbachorik/8064331/webrev.00 When using JavaSecurity.doIntersectionPrivilege() to invoke a privileged operation in ACC that is a result of combining a saved ACC and the stack ACC the DomainCombiner assigned to the stack ACC gets lost. The solution is to explicitly add the stack ACC's DomainCombiner to the ACC instance used to execute the privileged operation. Thanks, -JB- From magnus.ihse.bursie at oracle.com Fri Jan 16 19:35:32 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 16 Jan 2015 20:35:32 +0100 Subject: RFR: JDK-8068748: missing US_export_policy.jar in jdk9-b44 is causing compilation errors building jdk9 source code In-Reply-To: <54B79EFE.7050202@oracle.com> References: <54B79EFE.7050202@oracle.com> Message-ID: <54B96804.1030101@oracle.com> On 2015-01-15 12:05, Erik Joelsson wrote: > Hello, > > Please review the open part of this patch, which changes the building > of policy jars to happen even if BUILD_CRYPTO is false. Previously > these weren't built as there were signed versions of these jars, but > since we no longer sign them, there is no need to not build them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068748 > Webrev: http://cr.openjdk.java.net/~erikj/8068748/webrev.jdk.01/ > > The webrev diffs look a bit weird. The only thing I did was to remove > the "ifneq ($(BUILD_CRYPTO), no)" and adjust the indentation. > Looks good to me. /Magnus From sean.coffey at oracle.com Mon Jan 19 15:50:13 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Mon, 19 Jan 2015 15:50:13 +0000 Subject: DSA with keylength > 1024 no longer accepted (jdk7u-dev Digest, Vol 43, Issue 8) In-Reply-To: <54BD2106.3040301@certitrade.net> References: <54BD2106.3040301@certitrade.net> Message-ID: <54BD27B5.4030906@oracle.com> Peter, the issue you reference isn't a problem in jdk7u. - for the Oracle JDK at least. The code snippet your refer to is from jdk8 source code. The key length restriction was initially introduced as a side effect of this fix in JDK 8 https://bugs.openjdk.java.net/browse/JDK-7044060 That said, the version string you pasted makes it look like you're running IcedTea from Redhat. My earlier assumptions were that you were running OpenJDK binary based on the jdk7u sources (http://hg.openjdk.java.net/jdk7u/jdk7u/jdk) - If IcedTea has ported JDK-7044060 to their code base, you might have to contact them. Best to follow up on distro-pkg-dev at openjdk.java.net regards, Sean. On 19/01/15 15:21, Peter Haraldson wrote: > > > Thanks, I have now subscribed to security-dev as well. To keep the > thread intact I still reply here. > > Our java version would be JDK 7 I suppose - reported java version > "1.7.0_65". > > I checked your link, and I can see this issue will be resolved in JDK > 8 & 9, but I could not find anything about this issue with JDK 7. > If it's not to be fixed in JDK 7 then we will need to upgrade. > > Kind regards > Peter > > >> >> Message: 3 >> Date: Thu, 15 Jan 2015 10:28:46 +0000 >> From: Se?n Coffey >> To: Peter Haraldson >> Cc: Security OpenJDK >> Subject: Re: DSA with keylength > 1024 no longer accepted >> Message-ID: <54B7965E.8010109 at oracle.com> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> Hi Peter, >> >> security-dev is best mailing list to discuss this issue, I'm cc'ing that >> list and bcc'ing off jdk7u-dev. >> >> Are you hitting this issue with JDK 8 and later ? (I'll assume so) - >> You've hit https://bugs.openjdk.java.net/browse/JDK-8039921 >> To aid compatibility, it's been decided to relax that restriction from >> 8u60 and later. See comments in bug report around use of SHA1 and SHA2 >> and the length of keys that should be used in each operation. >> >> Hope that helps. >> regards, >> Sean. >> >> On 15/01/2015 10:10, Peter Haraldson wrote: >>> Hi >>> First, I'm not quite sure if this is the correct list for this issue, >>> please excuse & correct me if it's not. >>> >>> Our problem is that in latest openjdk a check is added that makes our >>> certificates with DSA & Keylength 2048 unusable. In file >>> "sun.security.provider.DSA" line 484-489: >>> protected void checkKey(DSAParams params) throws >>> InvalidKeyException { >>> int valueL = params.getP().bitLength(); >>> if (valueL > 1024) { >>> throw new InvalidKeyException("Key is too long for >>> this algorithm"); >>> } >>> } >>> This is new, these certificates worked fine before. I don't know the >>> reason for not accepting longer keys than 1024, not allowing too short >>> keys would make sense to me but not allowing long keys? >>> >>> We need to find a permanent solution, as for now we can't update our >>> production servers because of this. We have several certificates >>> issued by MasterCard, it is a very tedious job to change them all. >>> Is there a way we could bypass this, could this check be abandoned in >>> next update? >>> >>> Our system: >>> java version "1.7.0_65" (not affected) >>> OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17) >>> OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) >>> OS: RedHat 6.6 >>> >>> Regards Peter >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Thu, 15 Jan 2015 11:02:48 +0000 >> From: kevin.walls at oracle.com >> To: jdk7u-dev at openjdk.java.net >> Subject: hg: jdk7u/jdk7u-dev/hotspot: 8042235: redefining method used >> by multiple MethodHandles crashes VM >> Message-ID: <201501151102.t0FB2mNa002494 at aojmv0008> >> >> Changeset: e99b6986875c >> Author: kevinw >> Date: 2015-01-15 09:12 +0000 >> URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e99b6986875c >> >> 8042235: redefining method used by multiple MethodHandles crashes VM >> Reviewed-by: coleenp, sspitsyn >> >> ! src/share/vm/classfile/javaClasses.cpp >> ! src/share/vm/classfile/javaClasses.hpp >> ! src/share/vm/oops/cpCacheOop.cpp >> ! src/share/vm/oops/instanceKlass.cpp >> ! src/share/vm/oops/instanceKlass.hpp >> ! src/share/vm/prims/jvm.cpp >> ! src/share/vm/prims/methodHandles.cpp >> ! src/share/vm/prims/methodHandles.hpp >> + >> test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandlesNoASM.java >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Thu, 15 Jan 2015 12:09:30 +0000 >> From: Se?n Coffey >> To: "Valery Kopylov (Akvelon)" , "Martin >> Sawicki (MS OPEN TECH)" , >> "jdk7u-dev at openjdk.java.net" >> Cc: "Kirk Shoop \(MS OPEN TECH\)" >> Subject: Re: Backporting the TCP loopback fast path (Windows) >> improvement to OpenJDK v7 >> Message-ID: <54B7ADFA.4030906 at oracle.com> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> Valeriy, >> >> I used the jdk7u patch that was attached to the mail request. It applied >> cleanly. I've posted webrev here for reference (patch there also): >> http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u/webrev/ >> >> The new WSAIoctl call would appear to be failing with WSAEINVAL. The >> NET_EnableFastTcpLoopback call already tests for WSAEOPNOTSUPP - maybe >> we should test for WSAEINVAL also and perhaps return silently if windows >> don't support the option. Or maybe - we state this as desired behaviour >> - i.e this option is suitable for modern windows kernels - your note >> below would contradict what I'm seeing though. >> >> The test passes for me on Windows 7 and fails on Windows XP. >> >> regards, >> Sean. >> >> On 15/01/2015 11:15, Valery Kopylov (Akvelon) wrote: >>> Hi Sean, >>> >>> Our TCP loopback implementation should process the option correctly >>> on older windows kernels. I tried to reproduce the issue, but it >>> works fine on my side. So I have an assumption that part of the code >>> present on jdk9 patch has been lost and this causes such errors. >>> Did you use the patch for jdk7 sent by Martin or perform the >>> backporting from jdk8 or 9 by yourself? >>> Could you please send me output of "hg diff" command in jdk folder? >>> >>> >>> Best regards, >>> Valeriy Kopylov >>> >>> -----Original Message----- >>> From: Se?n Coffey [mailto:sean.coffey at oracle.com] >>> Sent: Tuesday, January 13, 2015 22:31 >>> To: Martin Sawicki (MS OPEN TECH); jdk7u-dev at openjdk.java.net >>> Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH); Alan Bateman >>> Subject: Re: Backporting the TCP loopback fast path (Windows) >>> improvement to OpenJDK v7 >>> >>> Hi Martin, >>> >>> I've run into a problem in backporting this to JDK 7u. The test >>> fails on our build/test systems. (windows XP) - >>>> reason: User specified action: run main/othervm >>>> -Djdk.net.useFastTcpLoopback StressLoopback elapsed time (seconds): >>>> 0.64 >>>> STDOUT: >>>> STDERR: >>>> java.net.SocketException: Invalid argument: fastLoopback >>>> at sun.nio.ch.Net.socket0(Native Method) >>>> at sun.nio.ch.Net.serverSocket(Net.java:445) >>>> at >>>> sun.nio.ch.AsynchronousServerSocketChannelImpl.(AsynchronousServerSocketChannelImpl.java:71) >>>> at >>>> sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl.(WindowsAsynchronousServerSocketChannelImpl.java:69) >>>> at >>>> sun.nio.ch.WindowsAsynchronousChannelProvider.openAsynchronousServerSocketChannel(WindowsAsynchronousChannelProvider.java:83) >>>> at >>>> java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:140) >>>> at >>>> java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:161) >>>> at StressLoopback.main(StressLoopback.java:42) >>> This seems to be from the fact that the new SIO_LOOPBACK_FAST_PATH >>> IOCTL code is only supported on more modern windows systems. I'm >>> wondering if we should change the src code to not attempt to use >>> this option on older windows kernels or if I should just modify the >>> testcase to not run the test on older windows systems ? >>> >>> regards, >>> Sean. >>> >>> >>> >>> On 09/01/2015 16:25, Martin Sawicki (MS OPEN TECH) wrote: >>>> Sean, thank you for the update and your assistance. Looking forward. >>>> >>>> -----Original Message----- >>>> From: Se?n Coffey [mailto:sean.coffey at oracle.com] >>>> Sent: Friday, January 09, 2015 8:24 AM >>>> To: Martin Sawicki (MS OPEN TECH); jdk7u-dev at openjdk.java.net >>>> Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH) >>>> Subject: Re: Backporting the TCP loopback fast path (Windows) >>>> improvement to OpenJDK v7 >>>> >>>> Hey Martin, >>>> >>>> I can help in getting this enhancement ported to jdk7u-dev. I'm >>>> just waiting on approval for use of new system property in jdk7u >>>> release. >>>> Once I have that, I can get this in. >>>> >>>> regards, >>>> Sean. >>>> >>>> On 08/01/15 20:01, Martin Sawicki (MS OPEN TECH) wrote: >>>>> Hello again, >>>>> We'd like to propose to back-port our TCP loopback fast path >>>>> performance improvement for Windows that was recently accepted >>>>> into OpenJDK v9 and v8 into v7. >>>>> Just for reference, the original OpenJDK v9 fix just for reference >>>>> can be found here: >>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8. >>>>> >>>>> Our suggested webrev patch file for OpenJDK *v7* is attached to >>>>> this message, based on our understanding of the back-porting steps. >>>>> >>>>> Your review and acceptance of this contribution would be appreciated. >>>>> >>>>> Best regards, >>>>> Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open >>>>> Technologies, Inc. >>>>> A subsidiary of Microsoft Corp. >>>>> >> >> >> >> ------------------------------ >> >> Message: 6 >> Date: Thu, 15 Jan 2015 11:25:25 -0600 >> From: Paul Nauman >> To: jdk7u-dev at openjdk.java.net >> Subject: [7u-dev] Request for approval: 8020829: NMT tests fail on >> platforms if NMT detail is not supported >> Message-ID: <54B7F805.1090802 at oracle.com> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Would like to push this trivial backport to correct test failures. >> >> Bug: 8020829 (Confidential) - NMT tests fail on platforms if NMT detail >> is not supported. >> hs25 changeset: >> http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5fd8e2fbafd4 >> Reviewed by: chris.plummer at oracle.com >> >> - Paul >> >> >> >> ------------------------------ >> >> Message: 7 >> Date: Thu, 15 Jan 2015 19:33:19 +0100 >> From: dalibor topic >> To: "jdk7u-dev at openjdk.java.net" >> Subject: [7u communication] RDP2 milestone for 7u80 approaching >> Message-ID: <54B807EF.8000809 at oracle.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> As per earlier communication [1], RDP2 for jdk7u80 is approaching. It >> looks like 7u80 b05 (planned for the week of January 21st) will be the >> last 7u80 promotion built from the jdk7u repo. >> >> After January 21st, RDP2 will start. >> >> cheers, >> dalibor topic >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-December/010126.html >> >> > From fweimer at redhat.com Tue Jan 20 09:33:33 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 20 Jan 2015 10:33:33 +0100 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: <54B7E9DA.1070404@oracle.com> References: <53F1F272.3030705@redhat.com> <54B7A02D.7010305@redhat.com> <54B7E9DA.1070404@oracle.com> Message-ID: <54BE20ED.5080109@redhat.com> On 01/15/2015 05:24 PM, Anthony Scarpino wrote: >> Anthony, could you file a bug so that I can include its number? Thanks. >> > > Here it is: https://bugs.openjdk.java.net/browse/JDK-8069072 Thanks. Updated webrev: -- Florian Weimer / Red Hat Product Security From fweimer at redhat.com Tue Jan 20 09:37:59 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 20 Jan 2015 10:37:59 +0100 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: References: <53F1F272.3030705@redhat.com> <54B7A02D.7010305@redhat.com> <201501151945.t0FJj2FF029891@mx1.redhat.com> <54B8227E.2070404@redhat.com> Message-ID: <54BE21F7.4010507@redhat.com> On 01/16/2015 09:18 AM, Anthony Scarpino wrote: >> On Jan 15, 2015, at 12:26 PM, Florian Weimer wrote: >> >> Yes, they are going to help quite a bit as well. The other thing we need to fix for TLS is that AES-GCM is a garbage collector stress test. Last time I looked, for each transferred byte, there were four bytes allocated on the heap. > > What exactly are you referring to here? Is there a problem in TLS where it is using too much memory for AES-GCM specifically or AES-GCM itself is using too much memory? What test did you do to see this heap allocation or is this code inspection? I ran several large HTTPS downloads (of varying sizes), using AES-GCM at the TLS layer, and noticed that the allocation profile shown by hprof has several allocation sites where the amount scales with download size. The cause is a bit difficult to discern. One aspect is that the AES-GCM implementation creates a temporary buffer if the input and output buffer is identical. -- Florian Weimer / Red Hat Product Security From vincent.x.ryan at oracle.com Tue Jan 20 11:56:51 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 20 Jan 2015 11:56:51 +0000 Subject: [JDK-9] RFR: 8041787: Need new regressions tests for buffer handling for PBE algorithms In-Reply-To: <53D5F8AD.2060804@oracle.com> References: <53D5F8AD.2060804@oracle.com> Message-ID: <62717805-3FCD-4415-8737-835B5E5BCA2A@oracle.com> The new tests look fine. Thanks. On 28 Jul 2014, at 08:15, Rajan Halade wrote: > May I request you to review these 4 new tests to be added for PBE keys. New tests are added to address following: > > - same buffer can be used for encrypt and decrypt with PBE > - Mac update works correctly with different size of ByteBuffer > - doFinal and update operation result in same PBMac > - for PBEWithMD5AndDES cipher, only CBC mode and PKCS#5Padding is allowed > > JDK Issue: https://bugs.openjdk.java.net/browse/JDK-8041787 > Webrev: http://cr.openjdk.java.net/~rhalade/8041787/webrev.00/ > > Thanks, > Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Wed Jan 21 06:35:43 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 21 Jan 2015 09:35:43 +0300 Subject: [9] request for review: 8049171: Additional tests for jarsigner's warnings Message-ID: <54BF48BF.9090505@oracle.com> Hello, Please review a couple of new tests for jarsigner's warnings. Basically tests run jarsigner and check warning/error messages and exit codes according to [1]. https://bugs.openjdk.java.net/browse/JDK-8049171 http://cr.openjdk.java.net/~asmotrak/8049171/webrev.00 [1] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html Artem From weijun.wang at oracle.com Wed Jan 21 08:29:25 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 21 Jan 2015 16:29:25 +0800 Subject: [9] request for review: 8049171: Additional tests for jarsigner's warnings In-Reply-To: <54BF48BF.9090505@oracle.com> References: <54BF48BF.9090505@oracle.com> Message-ID: Thanks for adding so many tests. Some suggestions: - JarUtils.java You can use the new InputStream.transferTo() method. I am not sure if I understand updateJar correctly. It looks like srcJarFile is opened multiple times so its entries are duplicated a lot in the destination. Or is there a secret break? - Utils.java The mixed using of File and Files is strange, but you are free to keep it. - TimestampCheck.java You can make Handler Autocloseable to use try-with-resources in tests. - Various tests I am not a fan of calling Utils.cleanup() in final block. Unless you have created huge garbages, those files are precious when the test fails (given you provide -retain in jtreg, which I always do). Thanks Max > On Jan 21, 2015, at 14:35, Artem Smotrakov wrote: > > Hello, > > Please review a couple of new tests for jarsigner's warnings. Basically tests run jarsigner and check warning/error messages and exit codes according to [1]. > > https://bugs.openjdk.java.net/browse/JDK-8049171 > http://cr.openjdk.java.net/~asmotrak/8049171/webrev.00 > > [1] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html > > Artem > > From peter.levart at gmail.com Wed Jan 21 11:52:36 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 21 Jan 2015 12:52:36 +0100 Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors In-Reply-To: <54AC3CEA.6000702@oracle.com> References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com> <549AA573.2060801@gmail.com> <54A20475.3040206@oracle.com> <54A5AC7C.5010806@gmail.com> <54A7228D.4040801@oracle.com> <54A9696A.3070406@gmail.com> <54AC3CEA.6000702@oracle.com> Message-ID: <54BF9304.10906@gmail.com> Hi, I have pushed this change. Thanks Brad, Alan and Chris for reviews. Regards, Peter On 01/06/2015 08:52 PM, Bradford Wetmore wrote: > I only looked at test, looks good to me. > > I'd rarely ask to remove extra prints in tests. It adds initial > debugging data points in case something breaks down the road. > > Brad > > > On 1/4/2015 8:25 AM, Peter Levart wrote: >> Hi Brad, >> >> So I created another webrev (just removed the unneeded import and >> left-over System.out.println from test): >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.06/ >> >> >> I'll leave it here to rest for a couple of days and if no one objects, >> I'll push it to jdk9-dev. >> >> Thanks everybody for reviews and happy new year! >> >> Regards, Peter >> >> On 01/02/2015 11:58 PM, Bradford Wetmore wrote: >>> >>> On 1/1/2015 12:22 PM, Peter Levart wrote: >>>> Hi Brad, >>>> >>>> Here's next webrev which tries to cover all your comments: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.04/ >>>> >>>> >>> >>> I downloaded the webrev.05 (Chris' later followup email) and ran it >>> through JPRT. The only error was the previously seen -Dseed which is >>> not your problem. >>> >>> Again, I only ran: >>> >>> jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, >>> jdk_security*, jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools. >>> >>> If you need anything else run, let me know. >>> >>>>>>> Looks like you have a committer status, will you be pushing this? >>>>>> >>>>>> I can, yes. As soon as we clear-out the remaining questions, right? >>>>> >>>>> Yes. The comments below are minor and shouldn't need another review >>>>> cycle. >>>> >>>> I'm worried about the failure of the test you observed while running >>>> from NetBeans. Perhaps a 0.5s wait is sometimes not enough for >>>> ReferenceHandler thread to process (enqueue) a WeakReference. Since >>>> there is already a facility in place to help ReferenceHandler thread >>>> instead of wait for it, I used it in new version of the test. >>> >>> BTW, there's now an unnecessary import from java.lang.AssertionError >>> added in webrev.04. >>> >>>>> TEST RESULT: Failed. Compilation failed: Compilation failed >>>> >>>> I changed the test to be self-contained now so one can run it without >>>> testlib in classpath. >>> >>> Thanks. It's compiling fine now. >>> >>>>> Two minor nits? SeedGenerator.java: Lines 507/518 >>>> >>>> Done that too. >>> >>> Thanks. >>> >>>>> Maybe issue multiple reads to exercise in1 and in2? e.g. 2 bytes of >>>>> in1, 4 bytes of in2, then 2 bytes of in1? >>>> >>>> The 1st assert makes sure in1 == in2, so there's no point in invoking >>>> the same instance via two aliases. >>> >>> True. >>> >>>>> IIRC, when I ran this under NetBeans last week, the second >>>>> testCaching >>>>> didn't clear the WeakReference. >>>> >>>> This should not happen any more now that the test is helping to >>>> enqueue >>>> the WeakReferences instead of waiting for ReferenceHandler to enqueue >>>> them. >>> >>> Yes, that hit the refQueue.poll(). >>> >>> It's always interesting to work with core-libs folks, learn something >>> new everyday. Mixing Lambdas/try-with. >>> >>> I need a time-machine for your CFV/jdk8 Committer: >>> >>> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-August/002896.html >>> >>> I vote yes. >>> >>>> The test can now fail only if System.gc() does not trigger >>>> WeakReference processing in the VM. Can you give it a try on your >>>> NetBeans environment? >>> >>> One last comment. It's now 2015. ;) >>> >>> Brad >>> >> From weijun.wang at oracle.com Thu Jan 22 10:46:06 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 22 Jan 2015 18:46:06 +0800 Subject: RFR 8071313: krb5.conf not read if SCDynamicStore krb5 config is empty Message-ID: <7FCE4119-D6AA-4380-891C-C9350523AA30@oracle.com> Hi All Please review the fix at http://cr.openjdk.java.net/~weijun/8071313/webrev.00 On a Mac OS X, when Open Directory is installed but disabled, Java should be able to use other Kerberos settings. Noreg-hard but I added a comment [1] to describe how to test the change. Thanks Max [1] https://bugs.openjdk.java.net/browse/JDK-8071313 From artem.smotrakov at oracle.com Thu Jan 22 11:40:19 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 22 Jan 2015 14:40:19 +0300 Subject: [9] request for review: 8049171: Additional tests for jarsigner's warnings In-Reply-To: References: <54BF48BF.9090505@oracle.com> Message-ID: <54C0E1A3.8070600@oracle.com> Thanks, Max. Please see inline. On 01/21/2015 11:29 AM, Wang Weijun wrote: > Thanks for adding so many tests. Some suggestions: > > - JarUtils.java > > You can use the new InputStream.transferTo() method. Sure, I didn't know about that, thanks. > > I am not sure if I understand updateJar correctly. It looks like srcJarFile is opened multiple times so its entries are duplicated a lot in the destination. Or is there a secret break? There is no any secret, just a bug. It is not necessary to open srcJarFile multiple times. I have updated the webrev, updateJar() method does the following: - creates a new jar file (destJarFilename) - puts files which are specified in files parameter to destJarFilename - copies files from srcJarFilename to destJarFilename if they are no files with the same names in destJarFilename > > - Utils.java > > The mixed using of File and Files is strange, but you are free to keep it. Agree. I removed this method since tests don't need it anymore after I removed cleanup() methods (please see below). > > - TimestampCheck.java > > You can make Handler Autocloseable to use try-with-resources in tests. Good idea. > > - Various tests > > I am not a fan of calling Utils.cleanup() in final block. Unless you have created huge garbages, those files are precious when the test fails (given you provide -retain in jtreg, which I always do). Agree, those files may be helpful, they are not huge. I have removed a cleanup() methods. Here is an updated webrev with your suggested changes and a couple of others: - added @ignore tag for BadKeyUsageTest since it fails due to a bug in JDK - updated MultipleWarningsTest test to check ExtendedKeyUsage case instead of KeyUsage http://cr.openjdk.java.net/~asmotrak/8049171/webrev.01/ Artem > Thanks > Max > >> On Jan 21, 2015, at 14:35, Artem Smotrakov wrote: >> >> Hello, >> >> Please review a couple of new tests for jarsigner's warnings. Basically tests run jarsigner and check warning/error messages and exit codes according to [1]. >> >> https://bugs.openjdk.java.net/browse/JDK-8049171 >> http://cr.openjdk.java.net/~asmotrak/8049171/webrev.00 >> >> [1] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html >> >> Artem >> >> From vincent.x.ryan at oracle.com Thu Jan 22 11:42:53 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 22 Jan 2015 11:42:53 +0000 Subject: [9] review request 8069155: The value of 'KeyStore Type' isn't 'jks' Message-ID: Please review this trivial fix to a broken manual test. The test assumed that the default keystore type is JKS. Since JDK 9 Build 45 the default is PKCS12. The fix simply sets the required keystore type when first creating the keystore used by the testcase. Bug: https://bugs.openjdk.java.net/browse/JDK-8069155 Webrev: http://cr.openjdk.java.net/~vinnie/8069155/webrev.00/ Thanks. From xuelei.fan at oracle.com Thu Jan 22 12:27:52 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 22 Jan 2015 20:27:52 +0800 Subject: [9] review request 8069155: The value of 'KeyStore Type' isn't 'jks' In-Reply-To: References: Message-ID: <54C0ECC8.6080602@oracle.com> Looks fine to me. Xuelei On 1/22/2015 7:42 PM, Vincent Ryan wrote: > Please review this trivial fix to a broken manual test. > > The test assumed that the default keystore type is JKS. Since JDK 9 Build 45 the default is PKCS12. > The fix simply sets the required keystore type when first creating the keystore used by the testcase. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8069155 > Webrev: http://cr.openjdk.java.net/~vinnie/8069155/webrev.00/ > > Thanks. > From sean.mullan at oracle.com Thu Jan 22 14:22:15 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 22 Jan 2015 09:22:15 -0500 Subject: RFR 8071313: krb5.conf not read if SCDynamicStore krb5 config is empty In-Reply-To: <7FCE4119-D6AA-4380-891C-C9350523AA30@oracle.com> References: <7FCE4119-D6AA-4380-891C-C9350523AA30@oracle.com> Message-ID: <54C10797.3090604@oracle.com> Looks ok to me. --Sean On 01/22/2015 05:46 AM, Wang Weijun wrote: > Hi All > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8071313/webrev.00 > > On a Mac OS X, when Open Directory is installed but disabled, Java should be able to use other Kerberos settings. > > Noreg-hard but I added a comment [1] to describe how to test the change. > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8071313 > From weijun.wang at oracle.com Thu Jan 22 14:33:12 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 22 Jan 2015 22:33:12 +0800 Subject: RFR 8055045: StringIndexOutOfBoundsException while reading krb5.conf Message-ID: Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8055045/webrev.00/ The old code has an error is the value is a single " or '. Thanks Max From sean.coffey at oracle.com Thu Jan 22 15:21:56 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 22 Jan 2015 15:21:56 +0000 Subject: RFR: 8065994: HTTP Tunnel connection to NTLM proxy reauthenticates instead of using keep-alive Message-ID: <54C11594.7050402@oracle.com> Looking for a review around this issue that came in as a reported performance regression in NTLM proxy authentication. It turned out that HttpsClients were being discarded after Proxy SocketAddress equality tests failed. Lack of caching is expensive in terms for performance for TLS and needless handshakes. The 2nd round of NTLM authentication was passing in a Proxy which had a resolved SocketAddress. The previous Proxy creation for the same connection (via DefaultProxySelector) constructs Proxy using unresolved socketAddress. Proposed fix is to compare like with like and have Proxy construct with unresolved Address. I captured more details in bug report. I'm also using this opportunity to adding some extra logging to the HttpsClient class and to correct a bad null versus NO_PROXY test that existed (line 339) bug report : https://bugs.openjdk.java.net/browse/JDK-8065994 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8065994/webrev/ regards, Sean. From jamil.j.nimeh at oracle.com Thu Jan 22 18:35:37 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 22 Jan 2015 10:35:37 -0800 Subject: RFR 8044860: Vectors and fixed length fields should be verified for allowed sizes In-Reply-To: References: Message-ID: <54C142F9.3030508@oracle.com> Hi all, This review is to provide length checks on the session ID for SSL/TLS connections. It appears to be the only vector/array that needs additional length-checks to make sure it's not exceeding 32 bytes. Bug: https://bugs.openjdk.java.net/browse/JDK-8044860 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.01 Thanks, --Jamil From xuelei.fan at oracle.com Fri Jan 23 00:26:38 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 23 Jan 2015 08:26:38 +0800 Subject: RFR 8044860: Vectors and fixed length fields should be verified for allowed sizes In-Reply-To: <54C142F9.3030508@oracle.com> References: <54C142F9.3030508@oracle.com> Message-ID: <54C1953E.3030500@oracle.com> I may use SSLProtocolException if the size of session ID is bigger than 32. Otherwise, looks fine to me. Xuelei On 1/23/2015 2:35 AM, Jamil Nimeh wrote: > Hi all, > > This review is to provide length checks on the session ID for SSL/TLS > connections. It appears to be the only vector/array that needs > additional length-checks to make sure it's not exceeding 32 bytes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044860 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.01 > > Thanks, > --Jamil From jamil.j.nimeh at oracle.com Fri Jan 23 01:12:20 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 22 Jan 2015 17:12:20 -0800 Subject: =?US-ASCII?Q?Re:_RFR_8044860:_Vectors_and_fixed_length_?= =?US-ASCII?Q?fields_should_be_verified=0D_=09for_allowed_sizes?= Message-ID: Thanks for the review, Xuelei. ?I'll make that change and run it through the tests. --Jamil -------- Original message -------- From: Xuelei Fan Date: 01/22/2015 4:26 PM (GMT-08:00) To: security-dev at openjdk.java.net Subject: Re: RFR 8044860: Vectors and fixed length fields should be verified for allowed sizes I may use SSLProtocolException if the size of session ID is bigger than 32. Otherwise, looks fine to me. Xuelei On 1/23/2015 2:35 AM, Jamil Nimeh wrote: > Hi all, > > This review is to provide length checks on the session ID for SSL/TLS > connections. It appears to be the only vector/array that needs > additional length-checks to make sure it's not exceeding 32 bytes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044860 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.01 > > Thanks, > --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Jan 23 02:18:35 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 23 Jan 2015 10:18:35 +0800 Subject: [9] request for review: 8049171: Additional tests for jarsigner's warnings In-Reply-To: <54C0E1A3.8070600@oracle.com> References: <54BF48BF.9090505@oracle.com> <54C0E1A3.8070600@oracle.com> Message-ID: > On Jan 22, 2015, at 19:40, Artem Smotrakov wrote: > >> I am not sure if I understand updateJar correctly. It looks like srcJarFile is opened multiple times so its entries are duplicated a lot in the destination. Or is there a secret break? > There is no any secret, just a bug. It is not necessary to open srcJarFile multiple times. > > I have updated the webrev, updateJar() method does the following: > - creates a new jar file (destJarFilename) > - puts files which are specified in files parameter to destJarFilename > - copies files from srcJarFilename to destJarFilename if they are no files with the same names in destJarFilename The process above means the new files are added at the beginning. While jarsigner is able to verify such a file (it uses JarFile) the output is actually invalid because the MANIFEST and the signature files must be at the beginning (otherwise a JarInputStream cannot verify it). The "jar u" way is to copy each old entry into destination unless the entry name is in the updated list where the new file will be read. Finally the untouched files in the updated list are appended. > > Here is an updated webrev with your suggested changes and a couple of others: > - added @ignore tag for BadKeyUsageTest since it fails due to a bug in JDK > - updated MultipleWarningsTest test to check ExtendedKeyUsage case instead of KeyUsage Great. Thanks Max > > http://cr.openjdk.java.net/~asmotrak/8049171/webrev.01/ > From jamil.j.nimeh at oracle.com Fri Jan 23 02:24:09 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 22 Jan 2015 18:24:09 -0800 Subject: RFR 8044860: Vectors and fixed length fields should be verified for allowed sizes In-Reply-To: <54C1953E.3030500@oracle.com> References: <54C142F9.3030508@oracle.com> <54C1953E.3030500@oracle.com> Message-ID: <54C1B0C9.5090503@oracle.com> Hi Xuelei, et al.: Updated webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.02 Thanks, --Jamil On 01/22/2015 04:26 PM, Xuelei Fan wrote: > I may use SSLProtocolException if the size of session ID is bigger than > 32. Otherwise, looks fine to me. > > Xuelei > > On 1/23/2015 2:35 AM, Jamil Nimeh wrote: >> Hi all, >> >> This review is to provide length checks on the session ID for SSL/TLS >> connections. It appears to be the only vector/array that needs >> additional length-checks to make sure it's not exceeding 32 bytes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8044860 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.01 >> >> Thanks, >> --Jamil From xuelei.fan at oracle.com Fri Jan 23 02:27:43 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 23 Jan 2015 10:27:43 +0800 Subject: RFR 8044860: Vectors and fixed length fields should be verified for allowed sizes In-Reply-To: <54C1B0C9.5090503@oracle.com> References: <54C142F9.3030508@oracle.com> <54C1953E.3030500@oracle.com> <54C1B0C9.5090503@oracle.com> Message-ID: <54C1B19F.9010109@oracle.com> Looks fine to me. Thanks! Xuelei On 1/23/2015 10:24 AM, Jamil Nimeh wrote: > Hi Xuelei, et al.: > > Updated webrev: > http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.02 > > Thanks, > --Jamil > > On 01/22/2015 04:26 PM, Xuelei Fan wrote: >> I may use SSLProtocolException if the size of session ID is bigger than >> 32. Otherwise, looks fine to me. >> >> Xuelei >> >> On 1/23/2015 2:35 AM, Jamil Nimeh wrote: >>> Hi all, >>> >>> This review is to provide length checks on the session ID for SSL/TLS >>> connections. It appears to be the only vector/array that needs >>> additional length-checks to make sure it's not exceeding 32 bytes. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044860 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.01 >>> >>> Thanks, >>> --Jamil > From jason.uh at oracle.com Fri Jan 23 02:46:11 2015 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 22 Jan 2015 18:46:11 -0800 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes Message-ID: <54C1B5F3.1010000@oracle.com> Please review this change, which enables DSA and ECDSA signatures in the IEEE P1363 format (the concatenation of r and s). This is accomplished through an implementation of AlgorithmParameterSpec, SignatureFormatParameterSpec, which can be passed to the existing Signature.setParameter() method before signing or verifying a signature to indicate the desired signature format. webrev: http://cr.openjdk.java.net/~juh/8042967/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8042967 Thanks, Jason From bradford.wetmore at oracle.com Fri Jan 23 05:57:59 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 22 Jan 2015 21:57:59 -0800 Subject: RFR 8044860: Vectors and fixed length fields should be verified for allowed sizes In-Reply-To: <54C1B19F.9010109@oracle.com> References: <54C142F9.3030508@oracle.com> <54C1953E.3030500@oracle.com> <54C1B0C9.5090503@oracle.com> <54C1B19F.9010109@oracle.com> Message-ID: <54C1E2E7.4090609@oracle.com> Jamil, MAX_LENGTH probably could have been private, but not a big deal. Nice that it was only SessionID. I did a spot check on the TLS Extensions and TLS1.0-1.2, do you check on other related TLS RFCs? Brad On 1/22/2015 6:27 PM, Xuelei Fan wrote: > Looks fine to me. Thanks! > > Xuelei > > On 1/23/2015 10:24 AM, Jamil Nimeh wrote: >> Hi Xuelei, et al.: >> >> Updated webrev: >> http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.02 >> >> Thanks, >> --Jamil >> >> On 01/22/2015 04:26 PM, Xuelei Fan wrote: >>> I may use SSLProtocolException if the size of session ID is bigger than >>> 32. Otherwise, looks fine to me. >>> >>> Xuelei >>> >>> On 1/23/2015 2:35 AM, Jamil Nimeh wrote: >>>> Hi all, >>>> >>>> This review is to provide length checks on the session ID for SSL/TLS >>>> connections. It appears to be the only vector/array that needs >>>> additional length-checks to make sure it's not exceeding 32 bytes. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044860 >>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.01 >>>> >>>> Thanks, >>>> --Jamil >> > From jamil.j.nimeh at oracle.com Fri Jan 23 06:17:19 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 22 Jan 2015 22:17:19 -0800 Subject: RFR 8044860: Vectors and fixed length fields should be verified for allowed sizes In-Reply-To: <54C1E2E7.4090609@oracle.com> References: <54C142F9.3030508@oracle.com> <54C1953E.3030500@oracle.com> <54C1B0C9.5090503@oracle.com> <54C1B19F.9010109@oracle.com> <54C1E2E7.4090609@oracle.com> Message-ID: <54C1E76F.6070101@oracle.com> I did check some of the other TLS RFCs, particularly 6066, 6961, 4492, 5288 and a few others. There are so many that I'm not 100% certain I caught them all, but not all apply to JSSE either. In all the RFCs I looked at, those vectors had upper bounds that matched the maximum value for its length field. --Jamil On 01/22/2015 09:57 PM, Bradford Wetmore wrote: > Jamil, > > MAX_LENGTH probably could have been private, but not a big deal. > > Nice that it was only SessionID. I did a spot check on the TLS > Extensions and TLS1.0-1.2, do you check on other related TLS RFCs? > > Brad > > > > On 1/22/2015 6:27 PM, Xuelei Fan wrote: >> Looks fine to me. Thanks! >> >> Xuelei >> >> On 1/23/2015 10:24 AM, Jamil Nimeh wrote: >>> Hi Xuelei, et al.: >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.02 >>> >>> Thanks, >>> --Jamil >>> >>> On 01/22/2015 04:26 PM, Xuelei Fan wrote: >>>> I may use SSLProtocolException if the size of session ID is bigger >>>> than >>>> 32. Otherwise, looks fine to me. >>>> >>>> Xuelei >>>> >>>> On 1/23/2015 2:35 AM, Jamil Nimeh wrote: >>>>> Hi all, >>>>> >>>>> This review is to provide length checks on the session ID for SSL/TLS >>>>> connections. It appears to be the only vector/array that needs >>>>> additional length-checks to make sure it's not exceeding 32 bytes. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044860 >>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.01 >>>>> >>>>> Thanks, >>>>> --Jamil >>> >> From bradford.wetmore at oracle.com Fri Jan 23 06:27:03 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 22 Jan 2015 22:27:03 -0800 Subject: RFR 8044860: Vectors and fixed length fields should be verified for allowed sizes In-Reply-To: <54C1E76F.6070101@oracle.com> References: <54C142F9.3030508@oracle.com> <54C1953E.3030500@oracle.com> <54C1B0C9.5090503@oracle.com> <54C1B19F.9010109@oracle.com> <54C1E2E7.4090609@oracle.com> <54C1E76F.6070101@oracle.com> Message-ID: <54C1E9B7.7050903@oracle.com> Thanks for checking and for getting this bug knocked out. I find http://datatracker.ietf.org/wg/tls/documents/ to be a useful cross checking tool in situations like this. As long as you hit the major ones that we support, I'm happy. Thanks, Brad On 1/22/2015 10:17 PM, Jamil Nimeh wrote: > I did check some of the other TLS RFCs, particularly 6066, 6961, 4492, > 5288 and a few others. There are so many that I'm not 100% certain I > caught them all, but not all apply to JSSE either. In all the RFCs I > looked at, those vectors had upper bounds that matched the maximum value > for its length field. > > --Jamil > > > On 01/22/2015 09:57 PM, Bradford Wetmore wrote: >> Jamil, >> >> MAX_LENGTH probably could have been private, but not a big deal. >> >> Nice that it was only SessionID. I did a spot check on the TLS >> Extensions and TLS1.0-1.2, do you check on other related TLS RFCs? >> >> Brad >> >> >> >> On 1/22/2015 6:27 PM, Xuelei Fan wrote: >>> Looks fine to me. Thanks! >>> >>> Xuelei >>> >>> On 1/23/2015 10:24 AM, Jamil Nimeh wrote: >>>> Hi Xuelei, et al.: >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.02 >>>> >>>> Thanks, >>>> --Jamil >>>> >>>> On 01/22/2015 04:26 PM, Xuelei Fan wrote: >>>>> I may use SSLProtocolException if the size of session ID is bigger >>>>> than >>>>> 32. Otherwise, looks fine to me. >>>>> >>>>> Xuelei >>>>> >>>>> On 1/23/2015 2:35 AM, Jamil Nimeh wrote: >>>>>> Hi all, >>>>>> >>>>>> This review is to provide length checks on the session ID for SSL/TLS >>>>>> connections. It appears to be the only vector/array that needs >>>>>> additional length-checks to make sure it's not exceeding 32 bytes. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044860 >>>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8044860/webrev.01 >>>>>> >>>>>> Thanks, >>>>>> --Jamil >>>> >>> > From artem.smotrakov at oracle.com Fri Jan 23 08:12:54 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 23 Jan 2015 11:12:54 +0300 Subject: [9] request for review: 8049171: Additional tests for jarsigner's warnings In-Reply-To: References: <54BF48BF.9090505@oracle.com> <54C0E1A3.8070600@oracle.com> Message-ID: <54C20286.1060106@oracle.com> Hi Max, Please see inline. On 01/23/2015 05:18 AM, Wang Weijun wrote: >> I have updated the webrev, updateJar() method does the following: >> >- creates a new jar file (destJarFilename) >> >- puts files which are specified in files parameter to destJarFilename >> >- copies files from srcJarFilename to destJarFilename if they are no files with the same names in destJarFilename > The process above means the new files are added at the beginning. Yes, "jar -tvf" shows the following for an original signed jar (before updateJar() is called) jar -tvf JTwork/scratch/0/signed.jar 83 Fri Jan 23 10:06:16 MSK 2015 META-INF/MANIFEST.MF 327 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.SF 1091 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.RSA 0 Fri Jan 23 10:06:10 MSK 2015 first.txt After pdateJar() is called, "jar -tvf" shows the following for modified jar jar -tvf JTwork/scratch/0/updated_signed.jar 0 Fri Jan 23 10:06:16 MSK 2015 second.txt 83 Fri Jan 23 10:06:16 MSK 2015 META-INF/MANIFEST.MF 327 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.SF 1091 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.RSA 0 Fri Jan 23 10:06:10 MSK 2015 first.txt > While jarsigner is able to verify such a file (it uses JarFile) the output is actually invalid because the MANIFEST and the signature files must be at the beginning (otherwise a JarInputStream cannot verify it). jarsigner successfully verifies a jar file that was modified by updateJar() method, please see a piece of log for sun/security/tools/jarsigner/warnings/HasUnsignedEntryTest.java test Copy signed.jar to updated_signed.jar, and add second.txt.class, so it contains unsigned entry Updating updated_signed.jar with second.txt Copying META-INF/MANIFEST.MF to updated_signed.jar Copying META-INF/ALIAS.SF to updated_signed.jar Copying META-INF/ALIAS.RSA to updated_signed.jar Copying first.txt to updated_signed.jar Command line: [/home/artem/ws/jdk/jdk9_dev/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jarsigner -verify -verbose -keystore keystore.jks -storepass password -keypass password updated_signed.jar] 0 Fri Jan 23 10:06:16 MSK 2015 second.txt s k 83 Fri Jan 23 10:06:16 MSK 2015 META-INF/MANIFEST.MF 327 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.SF 1091 Fri Jan 23 10:06:16 MSK 2015 META-INF/ALIAS.RSA smk 0 Fri Jan 23 10:06:10 MSK 2015 first.txt s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore i = at least one certificate was found in identity scope jar verified. Warning: This jar contains unsigned entries which have not been integrity-checked. This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2016-01-23) or after any future revocation date. Re-run with the -verbose and -certs options for more details. If the MANIFEST and the signature files must be at the beginning, should it be considered as a bug in jarsigner? Should it reject such files? > > The "jar u" way is to copy each old entry into destination unless the entry name is in the updated list where the new file will be read. Finally the untouched files in the updated list are appended. Since tests were not originally for checking some unusual ways for updating jars, I think they need to be updated to use the "jar u" way for adding unsigned entry. Artem > From chris.hegarty at oracle.com Fri Jan 23 15:00:45 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 23 Jan 2015 15:00:45 +0000 Subject: RFR: 8065994: HTTP Tunnel connection to NTLM proxy reauthenticates instead of using keep-alive In-Reply-To: <54C11594.7050402@oracle.com> References: <54C11594.7050402@oracle.com> Message-ID: <54C2621D.9050603@oracle.com> Looks good to me Sean. Good to see additional logging in this area. -Chris. On 22/01/15 15:21, Se?n Coffey wrote: > Looking for a review around this issue that came in as a reported > performance regression in NTLM proxy authentication. It turned out that > HttpsClients were being discarded after Proxy SocketAddress equality > tests failed. Lack of caching is expensive in terms for performance for > TLS and needless handshakes. The 2nd round of NTLM authentication was > passing in a Proxy which had a resolved SocketAddress. The previous > Proxy creation for the same connection (via DefaultProxySelector) > constructs Proxy using unresolved socketAddress. Proposed fix is to > compare like with like and have Proxy construct with unresolved Address. > > I captured more details in bug report. I'm also using this opportunity > to adding some extra logging to the HttpsClient class and to correct a > bad null versus NO_PROXY test that existed (line 339) > > bug report : https://bugs.openjdk.java.net/browse/JDK-8065994 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8065994/webrev/ > > regards, > Sean. From sean.mullan at oracle.com Fri Jan 23 18:21:33 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 23 Jan 2015 13:21:33 -0500 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes In-Reply-To: <54C1B5F3.1010000@oracle.com> References: <54C1B5F3.1010000@oracle.com> Message-ID: <54C2912D.6060304@oracle.com> Hi Jason, Just a few comments: * DOMSignatureMethod - If setParameter throws an exception, I think we should fallback and try the old code. This will allow 3rd party JCE providers to continue to work until they update their implementations to support the new ParameterSpec. * DSA, ECDSASignature, P11Signature - engineSetParameter should throw InvalidParameterException if the enum is neither ASN1 nor P1363 * SignatureFormatParameterSpec - can you add a sentence describing what each format is, ex: for ASN.1: "An ASN.1 sequence of two INTEGER values: r and s, in that order: SEQUENCE ::= { r INTEGER, s INTEGER }". For P1363, "an octet-encoding of r and s, in that order." * TestECDSA, TestDSA2 - can you add an @bug 8042967 to each of these tests, since you are extending them to test this new format. - can you also add a test which uses the SignatureFormatParameterSpec.ASN1 enum (by passing it to setParameter)? --Sean On 01/22/2015 09:46 PM, Jason Uh wrote: > Please review this change, which enables DSA and ECDSA signatures in the > IEEE P1363 format (the concatenation of r and s). > > This is accomplished through an implementation of > AlgorithmParameterSpec, SignatureFormatParameterSpec, which can be > passed to the existing Signature.setParameter() method before signing or > verifying a signature to indicate the desired signature format. > > webrev: http://cr.openjdk.java.net/~juh/8042967/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8042967 > > Thanks, > Jason From bradford.wetmore at oracle.com Fri Jan 23 18:28:18 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 23 Jan 2015 10:28:18 -0800 Subject: RFR: 8069038: javax/net/ssl/TLS/TLSClientPropertyTest.java needs to be updated for JDK-8061210 In-Reply-To: <54C1E11C.8040501@oracle.com> References: <54C1E11C.8040501@oracle.com> Message-ID: <54C292C2.8010100@oracle.com> This is a P2 test bug impacting continuous integration: http://cr.openjdk.java.net/~wetmore/8069038/webrev.00 A recent change missed updating one of the tests. Pretty straight forward, also corrected one typo. I don't see this test in the JDK 8 workspace, it's apparently only a 9 thing. Brad From bradford.wetmore at oracle.com Fri Jan 23 18:30:30 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 23 Jan 2015 10:30:30 -0800 Subject: RFR: 8069038: javax/net/ssl/TLS/TLSClientPropertyTest.java needs to be updated for JDK-8061210 In-Reply-To: <54C292C2.8010100@oracle.com> References: <54C1E11C.8040501@oracle.com> <54C292C2.8010100@oracle.com> Message-ID: <54C29346.8000107@oracle.com> Xuelei/Sean looked at this already (below). Brad On 1/23/2015 5:04 AM, Sean Mullan wrote: > On 01/23/2015 02:21 AM, Bradford Wetmore wrote: >> JPRT passed. Off to bed. > > The fix looks fine to me. > > --Sean On 1/22/2015 10:02 PM, Xuelei Fan wrote: > Looks fine to me. > > Thanks, > Xuelei On 1/23/2015 10:28 AM, Bradford Wetmore wrote: > > This is a P2 test bug impacting continuous integration: > > http://cr.openjdk.java.net/~wetmore/8069038/webrev.00 > > A recent change missed updating one of the tests. > > Pretty straight forward, also corrected one typo. > > I don't see this test in the JDK 8 workspace, it's apparently only a 9 > thing. > > Brad > From sean.mullan at oracle.com Fri Jan 23 18:46:18 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 23 Jan 2015 13:46:18 -0500 Subject: RFR 8055045: StringIndexOutOfBoundsException while reading krb5.conf In-Reply-To: References: Message-ID: <54C296FA.8050404@oracle.com> Looks good to me. --Sean On 01/22/2015 09:33 AM, Wang Weijun wrote: > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8055045/webrev.00/ > > The old code has an error is the value is a single " or '. > > Thanks > Max > From jason.uh at oracle.com Fri Jan 23 21:12:33 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 23 Jan 2015 13:12:33 -0800 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes In-Reply-To: <54C2912D.6060304@oracle.com> References: <54C1B5F3.1010000@oracle.com> <54C2912D.6060304@oracle.com> Message-ID: <54C2B941.5070800@oracle.com> Hi Sean, Here is a new webrev with changes addressing all of your comments: http://cr.openjdk.java.net/~juh/8042967/01/ Thanks, Jason On 01/23/2015 10:21 AM, Sean Mullan wrote: > Hi Jason, > > Just a few comments: > > * DOMSignatureMethod > > - If setParameter throws an exception, I think we should fallback and > try the old code. This will allow 3rd party JCE providers to continue to > work until they update their implementations to support the new > ParameterSpec. > > * DSA, ECDSASignature, P11Signature > > - engineSetParameter should throw InvalidParameterException if the enum > is neither ASN1 nor P1363 > > * SignatureFormatParameterSpec > > - can you add a sentence describing what each format is, ex: for ASN.1: > "An ASN.1 sequence of two INTEGER values: r and s, in that order: > SEQUENCE ::= { r INTEGER, s INTEGER }". For P1363, "an octet-encoding of > r and s, in that order." > > * TestECDSA, TestDSA2 > > - can you add an @bug 8042967 to each of these tests, since you are > extending them to test this new format. > > - can you also add a test which uses the > SignatureFormatParameterSpec.ASN1 enum (by passing it to setParameter)? > > --Sean > > On 01/22/2015 09:46 PM, Jason Uh wrote: >> Please review this change, which enables DSA and ECDSA signatures in the >> IEEE P1363 format (the concatenation of r and s). >> >> This is accomplished through an implementation of >> AlgorithmParameterSpec, SignatureFormatParameterSpec, which can be >> passed to the existing Signature.setParameter() method before signing or >> verifying a signature to indicate the desired signature format. >> >> webrev: http://cr.openjdk.java.net/~juh/8042967/00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8042967 >> >> Thanks, >> Jason From weijun.wang at oracle.com Mon Jan 26 02:03:33 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 26 Jan 2015 10:03:33 +0800 Subject: [9] request for review: 8049171: Additional tests for jarsigner's warnings In-Reply-To: <54C20286.1060106@oracle.com> References: <54BF48BF.9090505@oracle.com> <54C0E1A3.8070600@oracle.com> <54C20286.1060106@oracle.com> Message-ID: <54C5A075.4060304@oracle.com> On 1/23/2015 16:12, Artem Smotrakov wrote: > If the MANIFEST and the signature files must be at the beginning, should > it be considered as a bug in jarsigner? Should it reject such files? I think so. Will file a bug. >> >> The "jar u" way is to copy each old entry into destination unless the >> entry name is in the updated list where the new file will be read. >> Finally the untouched files in the updated list are appended. > Since tests were not originally for checking some unusual ways for > updating jars, I think they need to be updated to use the "jar u" way > for adding unsigned entry. Good. Thanks Max > > Artem >> > > > From mstjohns at comcast.net Mon Jan 26 04:15:31 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Sun, 25 Jan 2015 23:15:31 -0500 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes In-Reply-To: <54C1B5F3.1010000@oracle.com> References: <54C1B5F3.1010000@oracle.com> Message-ID: Sorry - I missed this the first time around.... I think this may not be the right approach... I'm concerned with trying to overload ECDSA and DSA which have always had relationships with very specific specifications and trying to make them also cover P1363. A better approach may be to create two new Signature plugins (with new registered names): ECDSA-P1363 and DSA-P1363 which do those specific signature formats rather than overloading the current meanings. (I mention this, because its possible that ECDSA-Curve25519 is on the way and it has yet a different set of things going on). If you don't want to do that, then I have to ask whether this the right place to implement the fix? Why wouldn't you implement this at the java.security.Signature code? My reasoning is that you've fixed it for the packaged provider, but not for other providers. If you did the signature reformatting in Signature, you would be able to "fix" the other providers as well. Mike At 09:46 PM 1/22/2015, Jason Uh wrote: >Please review this change, which enables DSA and ECDSA signatures in the IEEE P1363 format (the concatenation of r and s). > >This is accomplished through an implementation of AlgorithmParameterSpec, SignatureFormatParameterSpec, which can be passed to the existing Signature.setParameter() method before signing or verifying a signature to indicate the desired signature format. > >webrev: http://cr.openjdk.java.net/~juh/8042967/00/ >bug: https://bugs.openjdk.java.net/browse/JDK-8042967 > >Thanks, >Jason From artem.smotrakov at oracle.com Mon Jan 26 07:55:59 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 26 Jan 2015 10:55:59 +0300 Subject: [9] request for review: 8049171: Additional tests for jarsigner's warnings In-Reply-To: <54C5A075.4060304@oracle.com> References: <54BF48BF.9090505@oracle.com> <54C0E1A3.8070600@oracle.com> <54C20286.1060106@oracle.com> <54C5A075.4060304@oracle.com> Message-ID: <54C5F30F.7070207@oracle.com> Hi Max, Here is an updated webrev, please take a look. http://cr.openjdk.java.net/~asmotrak/8049171/webrev.02/ Artem On 01/26/2015 05:03 AM, Weijun Wang wrote: > > > On 1/23/2015 16:12, Artem Smotrakov wrote: >> If the MANIFEST and the signature files must be at the beginning, should >> it be considered as a bug in jarsigner? Should it reject such files? > > I think so. Will file a bug. > >>> >>> The "jar u" way is to copy each old entry into destination unless the >>> entry name is in the updated list where the new file will be read. >>> Finally the untouched files in the updated list are appended. >> Since tests were not originally for checking some unusual ways for >> updating jars, I think they need to be updated to use the "jar u" way >> for adding unsigned entry. > > Good. > > Thanks > Max > >> >> Artem >>> >> >> >> From weijun.wang at oracle.com Mon Jan 26 08:11:50 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 26 Jan 2015 16:11:50 +0800 Subject: [9] request for review: 8049171: Additional tests for jarsigner's warnings In-Reply-To: <54C5F30F.7070207@oracle.com> References: <54BF48BF.9090505@oracle.com> <54C0E1A3.8070600@oracle.com> <54C20286.1060106@oracle.com> <54C5A075.4060304@oracle.com> <54C5F30F.7070207@oracle.com> Message-ID: <3A738B71-A464-46D7-BACC-16108A5311C8@oracle.com> JarUtils: You can break after line 83. Otherwise very good. Thanks Max > On Jan 26, 2015, at 15:55, Artem Smotrakov wrote: > > Hi Max, > > Here is an updated webrev, please take a look. > > http://cr.openjdk.java.net/~asmotrak/8049171/webrev.02/ > > Artem > > On 01/26/2015 05:03 AM, Weijun Wang wrote: >> >> >> On 1/23/2015 16:12, Artem Smotrakov wrote: >>> If the MANIFEST and the signature files must be at the beginning, should >>> it be considered as a bug in jarsigner? Should it reject such files? >> >> I think so. Will file a bug. >> >>>> >>>> The "jar u" way is to copy each old entry into destination unless the >>>> entry name is in the updated list where the new file will be read. >>>> Finally the untouched files in the updated list are appended. >>> Since tests were not originally for checking some unusual ways for >>> updating jars, I think they need to be updated to use the "jar u" way >>> for adding unsigned entry. >> >> Good. >> >> Thanks >> Max >> >>> >>> Artem >>>> >>> >>> >>> > From artem.smotrakov at oracle.com Mon Jan 26 08:24:31 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 26 Jan 2015 11:24:31 +0300 Subject: [9] request for review: 8049171: Additional tests for jarsigner's warnings In-Reply-To: <3A738B71-A464-46D7-BACC-16108A5311C8@oracle.com> References: <54BF48BF.9090505@oracle.com> <54C0E1A3.8070600@oracle.com> <54C20286.1060106@oracle.com> <54C5A075.4060304@oracle.com> <54C5F30F.7070207@oracle.com> <3A738B71-A464-46D7-BACC-16108A5311C8@oracle.com> Message-ID: <54C5F9BF.3080903@oracle.com> On 01/26/2015 11:11 AM, Wang Weijun wrote: > JarUtils: > > You can break after line 83. Sure, I have updated the webrev http://cr.openjdk.java.net/~asmotrak/8049171/webrev.03/ > > Otherwise very good. Thanks for reviewing this. > > Thanks > Max > >> On Jan 26, 2015, at 15:55, Artem Smotrakov wrote: >> >> Hi Max, >> >> Here is an updated webrev, please take a look. >> >> http://cr.openjdk.java.net/~asmotrak/8049171/webrev.02/ >> >> Artem >> >> On 01/26/2015 05:03 AM, Weijun Wang wrote: >>> >>> On 1/23/2015 16:12, Artem Smotrakov wrote: >>>> If the MANIFEST and the signature files must be at the beginning, should >>>> it be considered as a bug in jarsigner? Should it reject such files? >>> I think so. Will file a bug. >>> >>>>> The "jar u" way is to copy each old entry into destination unless the >>>>> entry name is in the updated list where the new file will be read. >>>>> Finally the untouched files in the updated list are appended. >>>> Since tests were not originally for checking some unusual ways for >>>> updating jars, I think they need to be updated to use the "jar u" way >>>> for adding unsigned entry. >>> Good. >>> >>> Thanks >>> Max >>> >>>> Artem >>>> >>>> From fweimer at redhat.com Mon Jan 26 10:04:30 2015 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 26 Jan 2015 11:04:30 +0100 Subject: RFR: 8061798: Add support for TLS_FALLBACK_SCSV Message-ID: <54C6112E.7030806@redhat.com> I have rebased the TLS_FALLBACK_SCSV implementation I submitted in October 2014 to the current jdk9-dev tree: The test uses an expired X.509 certificate (which was already part of the test suite), but this is harmless. TLS_FALLBACK_SCSV is a bit of a wart, but it seems necessary for feature parity with other TLS server implementations. -- Florian Weimer / Red Hat Product Security From weijun.wang at oracle.com Mon Jan 26 13:45:34 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 26 Jan 2015 21:45:34 +0800 Subject: RFR 8071562: TimestampCheck.java change removes a whitespace between command and args In-Reply-To: <54C63249.9020801@oracle.com> References: <201501261014.t0QAEPno014340@aojmv0008> <54C63249.9020801@oracle.com> Message-ID: <54C644FE.7020803@oracle.com> Ah yes, a whitespace was mistakenly removed. Please review my fix at http://cr.openjdk.java.net/~weijun/8071562/webrev.00/ It's simply cmd = System.getProperty("java.home") + "/bin/jarsigner"; } - cmd += System.getProperty("test.tool.vm.opts") + cmd += " " + System.getProperty("test.tool.vm.opts") + " -J-Djava.security.egd=file:/dev/./urandom" Thanks Max On 1/26/2015 20:25, Alan Bateman wrote: > > Don't know if this is related but one of the jarsigner tests has started > to fail, same thing on mach5. > > http://.../sun/security/tools/jarsigner/ts.jtr > > > On 26/01/2015 10:14, weijun.wang at oracle.com wrote: >> Changeset: 5c61ccd9c162 >> Author: asmotrak >> Date: 2015-01-26 18:13 +0800 >> URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5c61ccd9c162 >> >> 8049171: Additional tests for jarsigner's warnings >> Reviewed-by: weijun >> From Alan.Bateman at oracle.com Mon Jan 26 13:50:43 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Jan 2015 13:50:43 +0000 Subject: RFR 8071562: TimestampCheck.java change removes a whitespace between command and args In-Reply-To: <54C644FE.7020803@oracle.com> References: <201501261014.t0QAEPno014340@aojmv0008> <54C63249.9020801@oracle.com> <54C644FE.7020803@oracle.com> Message-ID: <54C64633.3000108@oracle.com> On 26/01/2015 13:45, Weijun Wang wrote: > Ah yes, a whitespace was mistakenly removed. Please review my fix at > > http://cr.openjdk.java.net/~weijun/8071562/webrev.00/ > > It's simply > > cmd = System.getProperty("java.home") + "/bin/jarsigner"; > } > - cmd += System.getProperty("test.tool.vm.opts") > + cmd += " " + System.getProperty("test.tool.vm.opts") > + " -J-Djava.security.egd=file:/dev/./urandom" Looks okay to me. -Alan From sean.mullan at oracle.com Mon Jan 26 15:33:11 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 26 Jan 2015 10:33:11 -0500 Subject: RFR 8022582: Relax response flags checking in sun.security.krb5.KrbKdcRep.check. In-Reply-To: <5FA2E532-5E0C-4647-8659-89ACF6119B0D@oracle.com> References: <5FA2E532-5E0C-4647-8659-89ACF6119B0D@oracle.com> Message-ID: <54C65E37.1060508@oracle.com> Typo on line 941 of KDC.java: s/senstives/sensitives Also the OS component of the bug is set to "solaris_10", which doesn't seem right. Looks ok otherwise. --Sean On 01/14/2015 11:10 PM, Wang Weijun wrote: > Hi All > > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8022582/webrev.00 > > Sometimes a forwardable ticket request is sent but KDC returns a non-forwardable one. For example, in Windows, an account can be set as "sensitive and cannot be delegated". While it's possible to remove the "forwardable=true" line in krb5.conf to avoid the check failure, the file is global and maybe another account wants to be delegated. Therefore we just to relax the forwardable check. > > KrbTgsReq is also modified so that one can get a service ticket when TGT is not forwardable. > > One special case is S4U2self request, both the existing ticket and the expected ticket must be forwardable, and we fail early if one is not. > > A new test simulates the "sensitive account" concept in Windows. > > Thanks > Max > From otaviojava at java.net Mon Jan 26 19:10:43 2015 From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Mon, 26 Jan 2015 17:10:43 -0200 Subject: IndexOf with Char instead of String In-Reply-To: <54C58A97.7090908@oracle.com> References: <54C58A97.7090908@oracle.com> Message-ID: The same code, but using the new standard: http://cr.openjdk.java.net/~chegar/docs/portingScript.html How is the new standard I thought that I should create new thread. Sorry. On Sun, Jan 25, 2015 at 10:30 PM, Claes Redestad wrote: > Wait a minute. Is this the latest? Why start a new thread? > > Updating your benchmark to the latest JMH and running them against the > latest JDK9 I get contradictory > results (repeatable on two different machines): > > Benchmark (param) Mode Cnt Score Error Units > > .indexOfChar 10000 thrpt 50 3875.096 ? 12.365 ops/s > .indexOfString 10000 thrpt 50 4523.693 ? 9.835 ops/s > > JMH 1.5 version: > > import org.openjdk.jmh.annotations.*; > import org.openjdk.jmh.infra.Blackhole; > ... > private static final String WORDS = "I love java Language 8 because > has Lambda, Stream and MetaSpace"; > > @Param("10000") > private int param; > > @Benchmark > public void indexOfString(Blackhole bh) { > for (int i = 0; i <= param; i++) { > int index = WORDS.indexOf(","); > bh.consume(index); > } > } > > @Benchmark > public void indexOfChar(Blackhole bh) { > for (int i = 0; i <= param; i++) { > int index = WORDS.indexOf(','); > bh.consume(index); > } > } > > Turning WORDS into public String words actually narrows the gap (doesn't > really make sense to > benchmark indexOf with a literal char/String on a literal String, IMHO): > > Char: 5.158 ? 0.052 ops/ms > String: 5.314 ? 0.052 ops/ms > > Writing the benchmark like this: > > public String words = "I love java Language 8 because has Lambda, > Stream and MetaSpace"; > > @Benchmark > public int indexOfString() { > return words.indexOf(","); > } > > @Benchmark > public int indexOfChar() { > return words.indexOf(','); > } > > shows some possible benefit: > > Char 50.962 ? 0.529 ops/us > String 44.765 ? 0.078 ops/us > > Comparing with results from older JDKs, it seems something must've subtly > changed - perhaps > a regression somewhere. Turning off > > The fact that there's no indexOf(char) but rather an indexOf(int), while > this area is a > minefield of intrinsics makes all of this very hard to evaluate from a > performance point of view. > > Also, I think everyone would appreciate if you could split the patch into > one patch per module. > That'd be a natural split and will simplify getting reviews from each > appropriate team. > > /Claes > > On 2015-01-12 23:23, Ot?vio Gon?alves de Santana wrote: > >> These String literals may be replaced by equivalent character literals[1], >> gaining some performance enhancement. >> >> Webrev: >> https://dl.dropboxusercontent.com/u/16109193/open_jdk/jdk/ >> index_of_character/index.html >> >> >> [1] >> @State(Scope.Thread) >> @OutputTimeUnit(TimeUnit.SECONDS) >> public class IndexOfBenchmark { >> >> private static final String WORDS = "I love java Language 8 because >> has >> Lambda, Stream and MetaSpace"; >> >> @Param("10000") >> private int param; >> >> @GenerateMicroBenchmark >> public void indexOfString(BlackHole bh) { >> >> for (int i = 0; i <= param; i++) { >> int index = WORDS.indexOf(","); >> bh.consume(index); >> } >> } >> >> @GenerateMicroBenchmark >> public void indexOfChar(BlackHole bh) { >> >> for (int i = 0; i <= param; i++) { >> int index = WORDS.indexOf(','); >> bh.consume(index); >> } >> } >> } >> >> Benchmark (param) Mode Samples Mean >> Mean error Units >> m.IndexOfBenchmark.indexOfChar 10000 thrpt 10 5579.120 >> 114.179 ops/s >> m.IndexOfBenchmark.indexOfString 10000 thrpt 10 4562.178 >> 46.751 ops/s >> >> > -- Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * 55 (11) 98255-3513 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Jan 26 22:42:41 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 26 Jan 2015 17:42:41 -0500 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes In-Reply-To: <20150126041521.0EF23D03BA@aojmv0009> References: <54C1B5F3.1010000@oracle.com> <20150126041521.0EF23D03BA@aojmv0009> Message-ID: <54C6C2E1.1080407@oracle.com> On 01/25/2015 11:15 PM, Michael StJohns wrote: > Sorry - I missed this the first time around.... I think this may not > be the right approach... > > I'm concerned with trying to overload ECDSA and DSA which have always > had relationships with very specific specifications and trying to > make them also cover P1363. Are you more concerned with existing implementations? I'm curious because FIPS 186-3 does not (AFAICT) require that the signature bytes be formatted using ASN.1 DER. Also, some other standards require the P1363 format (like XML Signature) and other prominent crypto libraries (I think at least MSCrypto and JSS) encode in P1363. > A better approach may be to create two new Signature plugins (with > new registered names): ECDSA-P1363 and DSA-P1363 which do those > specific signature formats rather than overloading the current > meanings. (I mention this, because its possible that ECDSA-Curve25519 > is on the way and it has yet a different set of things going on). We had originally considered that as an alternative solution. There were some concerns (communicated internally) that this was not a good solution because the encoding format would not be as apparent, and it was a bit ugly to stuff this into an algorithm name String (you have many variants, so you would need to do something like "WithAndFormat", and thus you end up with a multitude of algorithms Strings that need to be supported in your providers to cover all the variants. I think we are open to revisiting that solution but I would like to hear a bit more about your concerns. > If you don't want to do that, then I have to ask whether this the > right place to implement the fix? Why wouldn't you implement this at > the java.security.Signature code? My reasoning is that you've fixed > it for the packaged provider, but not for other providers. If you > did the signature reformatting in Signature, you would be able to > "fix" the other providers as well. That doesn't solve the problem nicely, because then you would have to strip the ASN.1 DER encoding to convert to P1363 format (and vice-versa), which is basically what toolkits/libraries are forced to do today. This solution allows the provider to return the formatted bytes in the requested form without any need or overhead for additional re-formatting. --Sean > > Mike > > > > > > > > > > > At 09:46 PM 1/22/2015, Jason Uh wrote: >> Please review this change, which enables DSA and ECDSA signatures >> in the IEEE P1363 format (the concatenation of r and s). >> >> This is accomplished through an implementation of >> AlgorithmParameterSpec, SignatureFormatParameterSpec, which can be >> passed to the existing Signature.setParameter() method before >> signing or verifying a signature to indicate the desired signature >> format. >> >> webrev: http://cr.openjdk.java.net/~juh/8042967/00/ bug: >> https://bugs.openjdk.java.net/browse/JDK-8042967 >> >> Thanks, Jason > > From sean.mullan at oracle.com Tue Jan 27 16:24:40 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 27 Jan 2015 11:24:40 -0500 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes In-Reply-To: <54C6C2E1.1080407@oracle.com> References: <54C1B5F3.1010000@oracle.com> <20150126041521.0EF23D03BA@aojmv0009> <54C6C2E1.1080407@oracle.com> Message-ID: <54C7BBC8.9070105@oracle.com> I thought a bit more about this and I think you have a good point. If other new Signature algorithms are added that require parameters, then this design won't work, because setParameter is only supposed to be called once. For example, I can't do this: sig.setParameter(SignatureFormatParameterSpec.P1363); sig.setParameter(curve2519Params); We shall rethink this and see if we can come up with a better design. Thanks for reviewing this. --Sean On 01/26/2015 05:42 PM, Sean Mullan wrote: > On 01/25/2015 11:15 PM, Michael StJohns wrote: >> Sorry - I missed this the first time around.... I think this may not >> be the right approach... >> >> I'm concerned with trying to overload ECDSA and DSA which have always >> had relationships with very specific specifications and trying to >> make them also cover P1363. > > Are you more concerned with existing implementations? I'm curious > because FIPS 186-3 does not (AFAICT) require that the signature bytes be > formatted using ASN.1 DER. Also, some other standards require the P1363 > format (like XML Signature) and other prominent crypto libraries (I > think at least MSCrypto and JSS) encode in P1363. > >> A better approach may be to create two new Signature plugins (with >> new registered names): ECDSA-P1363 and DSA-P1363 which do those >> specific signature formats rather than overloading the current >> meanings. (I mention this, because its possible that ECDSA-Curve25519 >> is on the way and it has yet a different set of things going on). > > We had originally considered that as an alternative solution. There were > some concerns (communicated internally) that this was not a good > solution because the encoding format would not be as apparent, and it > was a bit ugly to stuff this into an algorithm name String (you have > many variants, so you would need to do something like > "WithAndFormat", and thus you end up with a > multitude of algorithms Strings that need to be supported in your > providers to cover all the variants. I think we are open to revisiting > that solution but I would like to hear a bit more about your concerns. > >> If you don't want to do that, then I have to ask whether this the >> right place to implement the fix? Why wouldn't you implement this at >> the java.security.Signature code? My reasoning is that you've fixed >> it for the packaged provider, but not for other providers. If you >> did the signature reformatting in Signature, you would be able to >> "fix" the other providers as well. > > That doesn't solve the problem nicely, because then you would have to > strip the ASN.1 DER encoding to convert to P1363 format (and > vice-versa), which is basically what toolkits/libraries are forced to do > today. This solution allows the provider to return the formatted bytes > in the requested form without any need or overhead for additional > re-formatting. > > --Sean > >> >> Mike >> >> >> >> >> >> >> >> >> >> >> At 09:46 PM 1/22/2015, Jason Uh wrote: >>> Please review this change, which enables DSA and ECDSA signatures >>> in the IEEE P1363 format (the concatenation of r and s). >>> >>> This is accomplished through an implementation of >>> AlgorithmParameterSpec, SignatureFormatParameterSpec, which can be >>> passed to the existing Signature.setParameter() method before >>> signing or verifying a signature to indicate the desired signature >>> format. >>> >>> webrev: http://cr.openjdk.java.net/~juh/8042967/00/ bug: >>> https://bugs.openjdk.java.net/browse/JDK-8042967 >>> >>> Thanks, Jason >> >> From ecki at zusammenkunft.net Tue Jan 27 17:50:24 2015 From: ecki at zusammenkunft.net (Bernd) Date: Tue, 27 Jan 2015 18:50:24 +0100 Subject: disabled SSL3 not reflected in "supported protocols" Message-ID: Hello, with the Java 7u76 update the default security setting is, that SSL3 is banned. At first I thought, this would reflect in enabled and supported protocols, however the list of supported protocols still contain SSL3 and I can also enable SSL3 and this is reflected on the getEnabledProtocols(): 1.7.0_76 Oracle Corporation jdk.tls.disabledAlgorithms=SSLv3 Default Protocols, enabled: [TLSv1] supported: [SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2] Set SSL3+TLSv1, enabled: [SSLv3, TLSv1] Set SSL3, enabled: [SSLv3] Now handshaking... Exception in thread "main" javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate) Only at handshake time it looks, like the disabled check is done. I wonder would it be cleaner to remove it from the supported set and not keep it in the enabled set (but accept the setEnabled for backward compatibility). Gruss Bernd PS: testcode: //Security.setProperty("jdk.tls.disabledAlgorithms", ""); System.out.printf("%s %s jdk.tls.disabledAlgorithms=%s%n", System.getProperty("java.version", "?"), System.getProperty("java.vendor", "?"), Security.getProperty("jdk.tls.disabledAlgorithms")); SSLSocket s = (SSLSocket)SSLSocketFactory.getDefault().createSocket("www.google.com", 443); System.out.printf("Default Protocols, enabled: %s supported: %s%n", Arrays.toString(s.getEnabledProtocols()), Arrays.toString(s.getSupportedProtocols())); s.setEnabledProtocols(new String[]{ "SSLv3", "TLSv1"}); System.out.printf("Set SSL3+TLSv1, enabled: %s%n", Arrays.toString(s.getEnabledProtocols())); s.setEnabledProtocols(new String[]{ "SSLv3"}); System.out.printf("Set SSL3, enabled: %s%nNow handshaking...%n", Arrays.toString(s.getEnabledProtocols())); s.startHandshake(); System.out.println("Ciper " + s.getSession().getCipherSuite() + " (" + s.getSession().getProtocol() + ")"); -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Tue Jan 27 22:40:21 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 27 Jan 2015 17:40:21 -0500 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes In-Reply-To: <54C6C2E1.1080407@oracle.com> References: <54C1B5F3.1010000@oracle.com> <20150126041521.0EF23D03BA@aojmv0009> <54C6C2E1.1080407@oracle.com> Message-ID: At 05:42 PM 1/26/2015, Sean Mullan wrote: >On 01/25/2015 11:15 PM, Michael StJohns wrote: >>Sorry - I missed this the first time around.... I think this may not >>be the right approach... >> >>I'm concerned with trying to overload ECDSA and DSA which have always >>had relationships with very specific specifications and trying to >>make them also cover P1363. > >Are you more concerned with existing implementations? I'm curious because FIPS 186-3 does not (AFAICT) require that the signature bytes be formatted using ASN.1 DER. Also, some other standards require the P1363 format (like XML Signature) and other prominent crypto libraries (I think at least MSCrypto and JSS) encode in P1363. Mostly, the default for the Signature contract is to output things that can immediately be put into the BIT STRING of an ASN1 Signed construct (e.g. to-be-signed body/signature algorithm/signature). One of the things I've nagged (I think it was) Bret about is how the documentation with respect to the registered algorithm names needs to be tied back to specific standards. I still think that needs to be done. X9.62 DOES actually have an ASN1 format (see appendix E). That format is also specified for the SECG equivalent and in the various ECDSA related RFCs. FIPS 186-4 just describes the math - it leaves most of the plumbing/formatting to other standards. Note that it just specifies that the signature is r and s, without giving a concrete representation. So what I'm concerned with is surprise. I'm also concerned with "default signature formats" from new providers. Right now, I know if I ask for ECDSA, the output of Signature will be in a very specific format, and the math will match what's in FIPS 186-4, X9.62 and SECG. I'm really uncomfortable about changing that. I think the algorithm name should map to one specific suite of math and input/output formats. >>A better approach may be to create two new Signature plugins (with >>new registered names): ECDSA-P1363 and DSA-P1363 which do those >>specific signature formats rather than overloading the current >>meanings. (I mention this, because its possible that ECDSA-Curve25519 >>is on the way and it has yet a different set of things going on). > >We had originally considered that as an alternative solution. There were some concerns (communicated internally) that this was not a good solution because the encoding format would not be as apparent, and it was a bit ugly to stuff this into an algorithm name String (you have many variants, so you would need to do something like "WithAndFormat", and thus you end up with a multitude of algorithms Strings that need to be supported in your providers to cover all the variants. I think we are open to revisiting that solution but I would like to hear a bit more about your concerns. For the current problem - it only seems to occur for ECDSA/DSA and I don't think you're going to end up with a lot of the "ECDSAWithP1363Format" stuff. I also don't like that you're twiddling the model in a way that not all providers will do. E.g. I have to explicitly ask for "ECDSA" from the sun provider to ensure that I get an implementation that supports P1363 signature formats. THAT more than anything else seems to violate the plugin contract. >>If you don't want to do that, then I have to ask whether this the >>right place to implement the fix? Why wouldn't you implement this at >>the java.security.Signature code? My reasoning is that you've fixed >>it for the packaged provider, but not for other providers. If you >>did the signature reformatting in Signature, you would be able to >>"fix" the other providers as well. > >That doesn't solve the problem nicely, because then you would have to strip the ASN.1 DER encoding to convert to P1363 format (and vice-versa), which is basically what toolkits/libraries are forced to do today. This solution allows the provider to return the formatted bytes in the requested form without any need or overhead for additional re-formatting. Fair point. But not really on point here. If I ask for an ECDSA signature implementation, it should have specific characteristics. And those characteristics should be pretty much identical regardless of which provider. I'd rather ask for an ECDSA-p1363 implementation and be told no, rather than having to search through the providers to and ECDSA implementation that also does P1363. I can always work from the output signature format of ALL current providers and get to P1363 format signatures - yes, additional work, but no surprises and no special coding necessary to get to the right provider. Mike >--Sean > >> >>Mike >> >> >> >> >> >> >> >> >> >> >>At 09:46 PM 1/22/2015, Jason Uh wrote: >>>Please review this change, which enables DSA and ECDSA signatures >>>in the IEEE P1363 format (the concatenation of r and s). >>> >>>This is accomplished through an implementation of >>>AlgorithmParameterSpec, SignatureFormatParameterSpec, which can be >>>passed to the existing Signature.setParameter() method before >>>signing or verifying a signature to indicate the desired signature >>>format. >>> >>>webrev: http://cr.openjdk.java.net/~juh/8042967/00/ bug: >>>https://bugs.openjdk.java.net/browse/JDK-8042967 >>> >>>Thanks, Jason >> From rob.mckenna at oracle.com Wed Jan 28 16:10:14 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 28 Jan 2015 16:10:14 +0000 Subject: RFR: 8065553: Failed Java web start via IPv6 (Java7u71 or later) Message-ID: <54C909E6.8080206@oracle.com> Hi folks, There is a problem in sun/security/util/HostnameChecker.java matchIP method. When comparing an ipv6 address with its abbreviated counterpart the comparison will fail. I'm open to a more efficient way of comparing these addresses (perhaps a utility method to abbreviate an ipv6 string) but this seems to do the job. http://cr.openjdk.java.net/~robm/8065553/webrev.01/ (btw, though this is a security component, it does seem to have a strong networking slant, so feel free to redirect me to net-dev) -Rob From mstjohns at comcast.net Wed Jan 28 20:03:44 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 28 Jan 2015 15:03:44 -0500 Subject: BigInteger magnitude (Related to RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes) Message-ID: In the code for dealing with R and S in the ECDSA engine is the same construct I've seen several times and programmed in several different ways mostly inside the security code. To wit: Given a positive BigInteger, return a byte array of the magnitude of a specific length, right adjusted and left zero padded. E.g. if "r" is a BigInteger with a positive value of 5, then "r.getMagnitude(4)" would return a byte[] of length 4 consisting of { 0, 0, 0, 5 }. That construct occurs in the R/S encoding for ECDSA signatures and in the encoding of the derived shared secret from a DH or ECDH. It probably occurs elsewhere as this is a pretty common sub function for crypto. Would it make sense to add to BigInteger some or all of the following methods: (In BigInteger) byte[] getMagnitude(int magLengthInBytes) void getMagnitude (byte[] magnitude) void getMagnitude (byte[] magnitude, int magOffset, int magLengthInBytes) ByteBuffer getMagnitude(ByteBuffer buffer, intMagLengthInBytes) - or - (in ByteBuffer) ByteBuffer putBigIntegerMagnitude(BigInteger bigint, int magLengthInBytes) (If we add the last two, then perhaps add the equivalent constructors or duals: BigInteger (int signum, byte[] magnitude, int magOffset, int magLengthInBytes) BigInteger (int signum, ByteBuffer magnitude, int magLengthInBytes) - or - (in ByteBuffer) BigInteger getBigIntegerByMagnitude (int signum, int magLengthInBytes); ) And then ideally go back and clean up the code tree to use these as the common constructs. Throws a NumberFormatException if the magnitude won't fit in the number of bytes (e.g. 100000 in a magnitude of 2 array) These are probably public API changes. Mike From ivan.gerasimov at oracle.com Wed Jan 28 21:04:00 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 29 Jan 2015 00:04:00 +0300 Subject: RFR 8068720: ArrayIndexOutOfBoundsException in JSSE with NetscapeCertType "SSL client" Message-ID: <54C94EC0.3040806@oracle.com> Hello! Behavior of sun.security.x509.NetscapeCertTypeExtension turns out to be inconsistent. It greatly depends on the order in which the entries are set/retrieved. The inconsistency is illustrated in the regression test: While these two lines work fine, 38 ext1.set(SSL_SERVER, true); 39 ext1.get(SSL_CLIENT); next two lines result in AIOOBEx: 43 ext2.set(SSL_CLIENT, true); 44 ext2.get(SSL_SERVER); The fix is trivial. Would you please help review it? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068720 WEBREV: http://cr.openjdk.java.net/~igerasim/8068720/0/webrev/ Sincerely yours, Ivan From mstjohns at comcast.net Wed Jan 28 21:24:01 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 28 Jan 2015 16:24:01 -0500 Subject: RFR 8068720: ArrayIndexOutOfBoundsException in JSSE with NetscapeCertType "SSL client" In-Reply-To: <54C94EC0.3040806@oracle.com> References: <54C94EC0.3040806@oracle.com> Message-ID: Not critical and more work, but maybe just update this to use java.util.BitSet? Mike At 04:04 PM 1/28/2015, Ivan Gerasimov wrote: >Hello! > >Behavior of sun.security.x509.NetscapeCertTypeExtension turns out to be inconsistent. >It greatly depends on the order in which the entries are set/retrieved. > >The inconsistency is illustrated in the regression test: > >While these two lines work fine, > > 38 ext1.set(SSL_SERVER, true); > 39 ext1.get(SSL_CLIENT); > >next two lines result in AIOOBEx: > > 43 ext2.set(SSL_CLIENT, true); > 44 ext2.get(SSL_SERVER); > > > >The fix is trivial. >Would you please help review it? > >BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068720 >WEBREV: http://cr.openjdk.java.net/~igerasim/8068720/0/webrev/ > > >Sincerely yours, >Ivan From jdk-security-dev at whittington.net.nz Thu Jan 29 01:32:21 2015 From: jdk-security-dev at whittington.net.nz (Tim Whittington) Date: Thu, 29 Jan 2015 14:32:21 +1300 Subject: Over-restrictive EC certificate checks in JSSE TLS 1.2 Message-ID: Hi all I noticed looking at the JSSE cipher suite selection that EC certificates are unnecessarily restricted when TLS 1.2 is used. Specifically sun.security.ssl.ServerHandshaker.trySetCipherSuite(CipherSuite) requires ?EC_EC? certs (an EC key, signed with an EC issuer key) for *_ECDSA suites, and requires ?EC_RSA? for ECDH_RSA suites. The restrictions on signing key for EC certs were specified in RFC 4492 (which introduced EC cipher-suites for TLS 1.0 and 1.1), but were explicitly removed in TLS 1.2 by RFC 5246 [2] (see Appendix A.7 and sections 7.4.2 and 7.4.6) (as an aside this effectively this makes ECDH_RSA an alias for ECDH_ECDSA). i.e. for TLS 1.2, an ?EC? only restriction is appropriate for ECDH_RSA and *_ECDSA suites. I?ve successfully tested JSSE negotiating TLS 1.2 + ECDHE_ECDSA with an EC cert signed by an RSA issuer (in this case using Tomcat, which hard-codes the key alias to use, ignoring the keyType provided to the key store selection APIs) so this restriction can probably be quite simply removed. cheers tim [1] https://tools.ietf.org/html/rfc4492 [2] https://tools.ietf.org/html/rfc5246#appendix-A.7 From bradford.wetmore at oracle.com Thu Jan 29 01:44:09 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 28 Jan 2015 17:44:09 -0800 Subject: disabled SSL3 not reflected in "supported protocols" In-Reply-To: References: Message-ID: <54C99069.5090901@oracle.com> On 1/27/2015 9:50 AM, Bernd wrote: > with the Java 7u76 update the default security setting is, that SSL3 is > banned. As you saw (and for those that haven't yet), SSLv3 has been disabled (deactivated) by default, but it can be reenabled by removing "SSLv3" from the list of disabled algorithms in the Security Property "jdk.tls.disabledAlgorithms". (See /lib/security/java.security) jdk.tls.disabledAlgorithms=SSLv3 SSLv3 is still available, but you have to really jump through hoops to get it back. > At first I thought, this would reflect in enabled and supported > protocols, however the list of supported protocols still contain SSL3 > and I can also enable SSL3 and this is reflected on the > getEnabledProtocols(): > > 1.7.0_76 Oracle Corporation jdk.tls.disabledAlgorithms=SSLv3 > Default Protocols, enabled: [TLSv1] supported: [SSLv2Hello, SSLv3, > TLSv1, TLSv1.1, TLSv1.2] > Set SSL3+TLSv1, enabled: [SSLv3, TLSv1] > Set SSL3, enabled: [SSLv3] > Now handshaking... > Exception in thread "main" javax.net.ssl.SSLHandshakeException: No > appropriate protocol (protocol is disabled or cipher suites are > inappropriate) > > Only at handshake time it looks, like the disabled check is done. Correct. It uses the new AlgorithmConstraints class internally, and there's a lookup of the Security Property for older releases. > I wonder would it be cleaner to remove it from the supported set and not > keep it in the enabled set (but accept the setEnabled for backward > compatibility). We went back and forth on this trying to balance the complete removal of the SSLv3 code vs. your suggestion to something in between, and it had to be something that a System Admin could configure. We decided for those applications that had hard-coded SSLv3, we should not introduce an unexpected IllegalArgumentException Runtime exception on set(). We also had to balance in JCK assumptions that a set() followed by a get() were expected to return the same values. (e.g. no new JCK failures.) All of the SSLContexts leave SSLv3 out of the default protocol list (including the "SSLv3" SSLContext which leaves only "TLSv1" enabled), so the only people who would be potentially impacted are those who are intentionally trying to set SSLv3, and they should be asking themselves different questions. This approach is a little confusing/surprising, but gave us the best compromise between the competing goals. Brad From xuelei.fan at oracle.com Thu Jan 29 03:39:28 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 29 Jan 2015 11:39:28 +0800 Subject: RFR: 8061798: Add support for TLS_FALLBACK_SCSV In-Reply-To: <54C6112E.7030806@redhat.com> References: <54C6112E.7030806@redhat.com> Message-ID: <54C9AB70.6070802@oracle.com> Hi Florian, Thanks for contribute this patch to OpenJDK. The draft of TLS_FALLBACK_SCSV is moving pretty fast. Would you mind wait for the integration until it becomes an official RFC in order to mitigate the potential compatibility impact? I looked back the approach we used to support TLS_EMPTY_RENEGOTIATION_INFO_SCSV (RFC 5746). TLS_EMPTY_RENEGOTIATION_INFO_SCSV is treated as a cipher suite. Application can configure to enabled or disable this special cipher suite as normal: SSLSocket.setEnabledCipherSuites(String[] suites) SSSEngine.setEnabledCipherSuites(String[] suites) What do you think if we use TLS_FALLBACK_SCSV as a cipher suite? If the enabled cipher suite list contains this cipher suites, client would send this cipher suite in ClientHello request. If it is OK, may not need to define new public APIs any more. As make it possible if this implementation is needed to backport to previous releases (In general, no APIs changes are allowed in JDK update releases). Thanks, Xuelei On 1/26/2015 6:04 PM, Florian Weimer wrote: > I have rebased the TLS_FALLBACK_SCSV implementation I submitted in > October 2014 to the current jdk9-dev tree: > > > > The test uses an expired X.509 certificate (which was already part of > the test suite), but this is harmless. > > TLS_FALLBACK_SCSV is a bit of a wart, but it seems necessary for feature > parity with other TLS server implementations. > From xuelei.fan at oracle.com Thu Jan 29 04:17:49 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 29 Jan 2015 12:17:49 +0800 Subject: Over-restrictive EC certificate checks in JSSE TLS 1.2 In-Reply-To: References: Message-ID: <54C9B46D.9080401@oracle.com> Hi Tim, Thanks for the find of the restriction in OpenJDK. The bug is tracked as JDK-8071858: https://bugs.openjdk.java.net/browse/JDK-8071858 (I just filed a bug, may need a few time to see it in public.) Thanks & Regards, Xuelei On 1/29/2015 9:32 AM, Tim Whittington wrote: > Hi all > > I noticed looking at the JSSE cipher suite selection that EC certificates are unnecessarily restricted when TLS 1.2 is used. > Specifically sun.security.ssl.ServerHandshaker.trySetCipherSuite(CipherSuite) requires ?EC_EC? certs (an EC key, signed with an EC issuer key) for *_ECDSA suites, and requires ?EC_RSA? for ECDH_RSA suites. > > The restrictions on signing key for EC certs were specified in RFC 4492 (which introduced EC cipher-suites for TLS 1.0 and 1.1), but were explicitly removed in TLS 1.2 by RFC 5246 [2] (see Appendix A.7 and sections 7.4.2 and 7.4.6) (as an aside this effectively this makes ECDH_RSA an alias for ECDH_ECDSA). > > i.e. for TLS 1.2, an ?EC? only restriction is appropriate for ECDH_RSA and *_ECDSA suites. > > I?ve successfully tested JSSE negotiating TLS 1.2 + ECDHE_ECDSA with an EC cert signed by an RSA issuer (in this case using Tomcat, which hard-codes the key alias to use, ignoring the keyType provided to the key store selection APIs) so this restriction can probably be quite simply removed. > > cheers > tim > > [1] https://tools.ietf.org/html/rfc4492 > [2] https://tools.ietf.org/html/rfc5246#appendix-A.7 > From ivan.gerasimov at oracle.com Thu Jan 29 06:45:44 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 29 Jan 2015 09:45:44 +0300 Subject: RFR 8068720: ArrayIndexOutOfBoundsException in JSSE with NetscapeCertType "SSL client" In-Reply-To: <201501282124.t0SLNtG5035805@aserp2020.oracle.com> References: <54C94EC0.3040806@oracle.com> <201501282124.t0SLNtG5035805@aserp2020.oracle.com> Message-ID: <54C9D718.5040503@oracle.com> On 29.01.2015 0:24, Michael StJohns wrote: > Not critical and more work, but maybe just update this to use java.util.BitSet? I'd prefer not to invest much effort in refactoring of this class. Let's limit scope of the fix by only getting rid of AIOOB exception for positive indices! Sincerely yours, Ivan > Mike > > > At 04:04 PM 1/28/2015, Ivan Gerasimov wrote: >> Hello! >> >> Behavior of sun.security.x509.NetscapeCertTypeExtension turns out to be inconsistent. >> It greatly depends on the order in which the entries are set/retrieved. >> >> The inconsistency is illustrated in the regression test: >> >> While these two lines work fine, >> >> 38 ext1.set(SSL_SERVER, true); >> 39 ext1.get(SSL_CLIENT); >> >> next two lines result in AIOOBEx: >> >> 43 ext2.set(SSL_CLIENT, true); >> 44 ext2.get(SSL_SERVER); >> >> >> >> The fix is trivial. >> Would you please help review it? >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068720 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8068720/0/webrev/ >> >> >> Sincerely yours, >> Ivan > > > From fweimer at redhat.com Thu Jan 29 09:59:39 2015 From: fweimer at redhat.com (Florian Weimer) Date: Thu, 29 Jan 2015 10:59:39 +0100 Subject: RFR: 8061798: Add support for TLS_FALLBACK_SCSV In-Reply-To: <54C9AB70.6070802@oracle.com> References: <54C6112E.7030806@redhat.com> <54C9AB70.6070802@oracle.com> Message-ID: <54CA048B.7040409@redhat.com> On 01/29/2015 04:39 AM, Xuelei Fan wrote: > Hi Florian, > > Thanks for contribute this patch to OpenJDK. > > The draft of TLS_FALLBACK_SCSV is moving pretty fast. Would you mind > wait for the integration until it becomes an official RFC in order to > mitigate the potential compatibility impact? The RFC is basically set in stone because code implementing it has already been shipped. I don't like the specification, and I don't like how it happened. But practically speaking, it's a done deal, even if the IETF end up not publishing the RFC (which is extremely unlikely because an RFC is the only way to get the SCSV code point reservation). > I looked back the approach we used to support > TLS_EMPTY_RENEGOTIATION_INFO_SCSV (RFC 5746). > TLS_EMPTY_RENEGOTIATION_INFO_SCSV is treated as a cipher suite. > Application can configure to enabled or disable this special cipher > suite as normal: > SSLSocket.setEnabledCipherSuites(String[] suites) > SSSEngine.setEnabledCipherSuites(String[] suites) > > What do you think if we use TLS_FALLBACK_SCSV as a cipher suite? If the > enabled cipher suite list contains this cipher suites, client would send > this cipher suite in ClientHello request. We absolutely have to prevent that application developers set this SCSV by accident. Developers feel tempted to set TLS_FALLBACK_SCSV to increase security, but this is very wrong. Things will appear to work just fine right now, but if the server side ever upgrades to TLS 1.3, the handshake will fail to work (I called this a ?time bomb? in the IETF TLS WG discussion, because that's what it is). Questions on the OpenSSL mailing list (and misleading advice in response) show that this is a real problem. My hope is that with a new API, the risk that developers enable this accidentally is reduced. It makes it also more transparent to code reviews. > If it is OK, may not need to define new public APIs any more. As make > it possible if this implementation is needed to backport to previous > releases (In general, no APIs changes are allowed in JDK update releases). I plan to backport only the server part, the client part is mostly there for testing purposes. -- Florian Weimer / Red Hat Product Security From sean.mullan at oracle.com Thu Jan 29 15:27:16 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 29 Jan 2015 10:27:16 -0500 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes In-Reply-To: <201501272240.t0RMe45G005679@userp2020.oracle.com> References: <54C1B5F3.1010000@oracle.com> <20150126041521.0EF23D03BA@aojmv0009> <54C6C2E1.1080407@oracle.com> <201501272240.t0RMe45G005679@userp2020.oracle.com> Message-ID: <54CA5154.6040302@oracle.com> On 01/27/2015 05:40 PM, Michael StJohns wrote: > So what I'm concerned with is surprise. I'm also concerned with > "default signature formats" from new providers. Right now, I know if > I ask for ECDSA, the output of Signature will be in a very specific > format, and the math will match what's in FIPS 186-4, X9.62 and SECG. > I'm really uncomfortable about changing that. I think the algorithm > name should map to one specific suite of math and input/output > formats. Yes, your argument makes sense, and we will change the fix to use new algorithm Strings that specify the P1363 format. Jason will be following up with more details on that. Thanks for weighing in on this issue and spending the time to explain your concerns. --Sean From jason.uh at oracle.com Thu Jan 29 20:41:44 2015 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 29 Jan 2015 12:41:44 -0800 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes In-Reply-To: <54CA5154.6040302@oracle.com> References: <54C1B5F3.1010000@oracle.com> <20150126041521.0EF23D03BA@aojmv0009> <54C6C2E1.1080407@oracle.com> <201501272240.t0RMe45G005679@userp2020.oracle.com> <54CA5154.6040302@oracle.com> Message-ID: <54CA9B08.4050403@oracle.com> Mike, Thanks for your feedback. I'll be changing this fix to introduce new algorithm Strings to specify the P1363 format. These strings will be of the form: withinFormat For example: SHA1withDSAinP1363Format SHA1withECDSAinP1363Format The intent is to reduce potential confusion with the extended algorithm Strings specifying MGF functions (withand) by using the word "in" for conjunction and to append "Format" to the format name. Would you be ok with this solution? Thanks, Jason On 1/29/15 7:27 AM, Sean Mullan wrote: > On 01/27/2015 05:40 PM, Michael StJohns wrote: >> So what I'm concerned with is surprise. I'm also concerned with >> "default signature formats" from new providers. Right now, I know if >> I ask for ECDSA, the output of Signature will be in a very specific >> format, and the math will match what's in FIPS 186-4, X9.62 and SECG. >> I'm really uncomfortable about changing that. I think the algorithm >> name should map to one specific suite of math and input/output >> formats. > > Yes, your argument makes sense, and we will change the fix to use new > algorithm Strings that specify the P1363 format. Jason will be following > up with more details on that. > > Thanks for weighing in on this issue and spending the time to explain > your concerns. > > --Sean From mandy.chung at oracle.com Thu Jan 29 20:58:09 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 29 Jan 2015 12:58:09 -0800 Subject: Review request 8069551: Move java.security.acl from compact3 to java.base Message-ID: <54CA9EE1.2010800@oracle.com> Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00 java.security.acl is superceded by java.security package since 1.2. This patch proposes to move java.security.acl package to java.base module rather than complicating the module graph with a close-to-useless dedicated module. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.mckenna at oracle.com Thu Jan 29 21:18:00 2015 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 29 Jan 2015 21:18:00 +0000 Subject: RFR: 8065553: Failed Java web start via IPv6 (Java7u71 or later) In-Reply-To: <54C909E6.8080206@oracle.com> References: <54C909E6.8080206@oracle.com> Message-ID: <54CAA388.3070906@oracle.com> Ping? -Rob On 28/01/15 16:10, Rob McKenna wrote: > Hi folks, > > There is a problem in sun/security/util/HostnameChecker.java matchIP > method. When comparing an ipv6 address with its abbreviated > counterpart the comparison will fail. I'm open to a more efficient way > of comparing these addresses (perhaps a utility method to abbreviate > an ipv6 string) but this seems to do the job. > > http://cr.openjdk.java.net/~robm/8065553/webrev.01/ > > (btw, though this is a security component, it does seem to have a > strong networking slant, so feel free to redirect me to net-dev) > > -Rob > > > From sean.mullan at oracle.com Thu Jan 29 22:19:38 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 29 Jan 2015 17:19:38 -0500 Subject: Review request 8069551: Move java.security.acl from compact3 to java.base In-Reply-To: <54CA9EE1.2010800@oracle.com> References: <54CA9EE1.2010800@oracle.com> Message-ID: <54CAB1FA.8020100@oracle.com> Looks fine to me. --Sean On 01/29/2015 03:58 PM, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00 > > java.security.acl is superceded by java.security package since 1.2. > > This patch proposes to move java.security.acl package to java.base > module rather than complicating the module graph with a close-to-useless > dedicated module. > > Mandy From mstjohns at comcast.net Thu Jan 29 23:56:59 2015 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 29 Jan 2015 18:56:59 -0500 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes In-Reply-To: <54CA9B08.4050403@oracle.com> References: <54C1B5F3.1010000@oracle.com> <20150126041521.0EF23D03BA@aojmv0009> <54C6C2E1.1080407@oracle.com> <201501272240.t0RMe45G005679@userp2020.oracle.com> <54CA5154.6040302@oracle.com> <54CA9B08.4050403@oracle.com> Message-ID: At 03:41 PM 1/29/2015, Jason Uh wrote: >Mike, > >Thanks for your feedback. > >I'll be changing this fix to introduce new algorithm Strings to specify the P1363 format. These strings will be of the form: > > withinFormat > >For example: > > SHA1withDSAinP1363Format > SHA1withECDSAinP1363Format Hmm... hadn't gotten that far. I think that would work, but its not quite right as in this case its about format, but might be about some other twiddle ( say endianess) for other specifications. If would be nice if the convention applied to more than ECDSA and DSA. I'm not opposed to the proposal though. My counter proposal would be for [/] as the naming convention. With the general contract that all implementations of share the same general math at least for KeyAgreement and Signature but may not share the same concrete representations or encodings (e.g. there's difference in the encoding of the shared secret output from DH for TLS vs pretty much everything else - has to do with the integer to octet string conversion). Again, not opposed to the naming convention you suggested, just trying to think in meta terms. Mike >The intent is to reduce potential confusion with the extended algorithm Strings specifying MGF functions (withand) by using the word "in" for conjunction and to append "Format" to the format name. > >Would you be ok with this solution? > >Thanks, >Jason > >On 1/29/15 7:27 AM, Sean Mullan wrote: >>On 01/27/2015 05:40 PM, Michael StJohns wrote: >>>So what I'm concerned with is surprise. I'm also concerned with >>>"default signature formats" from new providers. Right now, I know if >>>I ask for ECDSA, the output of Signature will be in a very specific >>>format, and the math will match what's in FIPS 186-4, X9.62 and SECG. >>>I'm really uncomfortable about changing that. I think the algorithm >>>name should map to one specific suite of math and input/output >>>formats. >> >>Yes, your argument makes sense, and we will change the fix to use new >>algorithm Strings that specify the P1363 format. Jason will be following >>up with more details on that. >> >>Thanks for weighing in on this issue and spending the time to explain >>your concerns. >> >>--Sean From Alan.Bateman at oracle.com Fri Jan 30 08:50:41 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Jan 2015 08:50:41 +0000 Subject: Review request 8069551: Move java.security.acl from compact3 to java.base In-Reply-To: <54CA9EE1.2010800@oracle.com> References: <54CA9EE1.2010800@oracle.com> Message-ID: <54CB45E1.9070300@oracle.com> On 29/01/2015 20:58, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00 > > java.security.acl is superceded by java.security package since 1.2. > > This patch proposes to move java.security.acl package to java.base > module rather than complicating the module graph with a > close-to-useless dedicated module. This looks okay. One small suggestion is to move the lines in unshuffle_list.txt up to where the other java.base paths are. -Alan From mandy.chung at oracle.com Fri Jan 30 17:10:33 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Jan 2015 09:10:33 -0800 Subject: Review request 8069551: Move java.security.acl from compact3 to java.base In-Reply-To: <54CB45E1.9070300@oracle.com> References: <54CA9EE1.2010800@oracle.com> <54CB45E1.9070300@oracle.com> Message-ID: <54CBBB09.9000000@oracle.com> On 1/30/15 12:50 AM, Alan Bateman wrote: > On 29/01/2015 20:58, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00 >> >> java.security.acl is superceded by java.security package since 1.2. >> >> This patch proposes to move java.security.acl package to java.base >> module rather than complicating the module graph with a >> close-to-useless dedicated module. > This looks okay. One small suggestion is to move the lines in > unshuffle_list.txt up to where the other java.base paths are. Yes that's better. Fixed. thanks. Mandy From jason.uh at oracle.com Fri Jan 30 22:18:56 2015 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 30 Jan 2015 14:18:56 -0800 Subject: [9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes In-Reply-To: <201501292356.t0TNugUq021123@userp2020.oracle.com> References: <54C1B5F3.1010000@oracle.com> <20150126041521.0EF23D03BA@aojmv0009> <54C6C2E1.1080407@oracle.com> <201501272240.t0RMe45G005679@userp2020.oracle.com> <54CA5154.6040302@oracle.com> <54CA9B08.4050403@oracle.com> <201501292356.t0TNugUq021123@userp2020.oracle.com> Message-ID: <54CC0350.8000407@oracle.com> Mike, Thanks again for weighing in. As you're not opposed to the proposal, I will go ahead and move forward with this plan. I will put out an updated webrev with the new approach once it is ready. Thanks, Jason On 1/29/15 3:56 PM, Michael StJohns wrote: > At 03:41 PM 1/29/2015, Jason Uh wrote: >> Mike, >> >> Thanks for your feedback. >> >> I'll be changing this fix to introduce new algorithm Strings to specify the P1363 format. These strings will be of the form: >> >> withinFormat >> >> For example: >> >> SHA1withDSAinP1363Format >> SHA1withECDSAinP1363Format > > Hmm... hadn't gotten that far. > > I think that would work, but its not quite right as in this case its about format, but might be about some other twiddle ( say endianess) for other specifications. If would be nice if the convention applied to more than ECDSA and DSA. I'm not opposed to the proposal though. > > My counter proposal would be for [/] as the naming convention. With the general contract that all implementations of share the same general math at least for KeyAgreement and Signature but may not share the same concrete representations or encodings (e.g. there's difference in the encoding of the shared secret output from DH for TLS vs pretty much everything else - has to do with the integer to octet string conversion). Again, not opposed to the naming convention you suggested, just trying to think in meta terms. > > Mike > > > > > >> The intent is to reduce potential confusion with the extended algorithm Strings specifying MGF functions (withand) by using the word "in" for conjunction and to append "Format" to the format name. >> >> Would you be ok with this solution? >> >> Thanks, >> Jason >> >> On 1/29/15 7:27 AM, Sean Mullan wrote: >>> On 01/27/2015 05:40 PM, Michael StJohns wrote: >>>> So what I'm concerned with is surprise. I'm also concerned with >>>> "default signature formats" from new providers. Right now, I know if >>>> I ask for ECDSA, the output of Signature will be in a very specific >>>> format, and the math will match what's in FIPS 186-4, X9.62 and SECG. >>>> I'm really uncomfortable about changing that. I think the algorithm >>>> name should map to one specific suite of math and input/output >>>> formats. >>> >>> Yes, your argument makes sense, and we will change the fix to use new >>> algorithm Strings that specify the P1363 format. Jason will be following >>> up with more details on that. >>> >>> Thanks for weighing in on this issue and spending the time to explain >>> your concerns. >>> >>> --Sean > > From anthony.scarpino at oracle.com Fri Jan 30 22:28:00 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 30 Jan 2015 14:28:00 -0800 Subject: com.sun.crypto.provider.GHASH performance fix In-Reply-To: <54BE20ED.5080109@redhat.com> References: <53F1F272.3030705@redhat.com> <54B7A02D.7010305@redhat.com> <54B7E9DA.1070404@oracle.com> <54BE20ED.5080109@redhat.com> Message-ID: <54CC0570.1010600@oracle.com> On 01/20/2015 01:33 AM, Florian Weimer wrote: > On 01/15/2015 05:24 PM, Anthony Scarpino wrote: >>> Anthony, could you file a bug so that I can include its number? Thanks. >>> >> >> Here it is: https://bugs.openjdk.java.net/browse/JDK-8069072 > > Thanks. Updated webrev: > > > I'm happy with the code changes. One change is to fix the copyright date on the GHASH.java file so it says "2013, 2015". The only other thing I'm not sure about is how the copyright should be on the test. You have Red Hat at the top. I'm not sure if it is suppose to be like GHASH with Oracle on top and IBM listed farther down. Anyone else have any input on that? Tony From bradford.wetmore at oracle.com Fri Jan 30 23:21:37 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 30 Jan 2015 15:21:37 -0800 Subject: Review request 8069551: Move java.security.acl from compact3 to java.base In-Reply-To: <54CBBB09.9000000@oracle.com> References: <54CA9EE1.2010800@oracle.com> <54CB45E1.9070300@oracle.com> <54CBBB09.9000000@oracle.com> Message-ID: <54CC1201.1030103@oracle.com> Looks ok to me too. Brad On 1/30/2015 9:10 AM, Mandy Chung wrote: > On 1/30/15 12:50 AM, Alan Bateman wrote: >> On 29/01/2015 20:58, Mandy Chung wrote: >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00 >>> >>> java.security.acl is superceded by java.security package since 1.2. >>> >>> This patch proposes to move java.security.acl package to java.base >>> module rather than complicating the module graph with a >>> close-to-useless dedicated module. >> This looks okay. One small suggestion is to move the lines in >> unshuffle_list.txt up to where the other java.base paths are. > > Yes that's better. Fixed. > > thanks. > Mandy >