From tristan.yan at oracle.com Mon Aug 3 17:27:40 2015 From: tristan.yan at oracle.com (Tristan Yan) Date: Mon, 3 Aug 2015 10:27:40 -0700 Subject: RFR 8044199: tests for RSA keys and key specifications Message-ID: Pinging Hi Please review new tests for RSA keys and key specifications Bug: https://bugs.openjdk.java.net/browse/JDK-8044199 Webrev: http://cr.openjdk.java.net/~tyan/8044199/webrev.01/ > Thanks Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Tue Aug 4 18:06:56 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 4 Aug 2015 20:06:56 +0200 Subject: Should SSLEngine throw SSLHandhakeException? Message-ID: <55C0FF40.9050208@redhat.com> If the SSLEngine client receives a fatal alert, an exception for Alerts.alert_unexpected_message is generated, which is an SSLException, not for the alert received, which would be an SSLHandhsakeException. Is this intentional? If not, the attached patch fixes that. I see this when the client receives an inappropriate_fallback alert with my TLS_FALLBACK_SCSV patch, but I can't see a reason why the behavior for other alerts would be different. -- Florian Weimer / Red Hat Product Security -------------- next part -------------- A non-text attachment was scrubbed... Name: engine.patch Type: text/x-patch Size: 714 bytes Desc: not available URL: From joe.darcy at oracle.com Tue Aug 4 19:16:19 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 4 Aug 2015 12:16:19 -0700 Subject: JDK 9 RFR of JDK-8132855: Adjust tier 1 and 2 definitions for security-related intrinsics Message-ID: <55C10F83.6030501@oracle.com> Hello, As a complement to JDK-8132854: Adjust tier 1 and 2 definitions for nio-related intrinsics, with the fix for JDK-8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics the sources for the libraries clearly indicate which methods might have intrinsic support in HotSpot, that is, which methods might have their Java source implementation replaced by some other code sequence maintained in HotSpot, such as a special-purpose processor-specific instruction. To ease testing, it would be helpful if all the intrinsified methods were included in the tier 1 test group. Most of the intrinics are in java.lang, java.math, and java.util, packages whose tests are already in tier 1. Several security libraries are marked with @HotSpotIntrinsicCandidate including: ./java.base/share/classes/com/sun/crypto/provider/GHASH.java # internal processBlocks method to ghash ./java.base/share/classes/com/sun/crypto/provider/AESCrypt.java # implEncryptBlock, implDecryptBlock ./java.base/share/classes/com/sun/crypto/provider/CipherBlockChaining.java # implEncrypt, implDecrypt The tests for those libraries seem to be included in the security2 test group which is part of tier 2. I propose to move the tests for that functionality to tier 1: diff -r 9bce83952890 test/TEST.groups --- a/test/TEST.groups Tue Aug 04 11:26:51 2015 -0700 +++ b/test/TEST.groups Tue Aug 04 12:09:59 2015 -0700 @@ -30,6 +30,7 @@ :jdk_util \ sun/nio/cs/ISO8859x.java \ java/nio/Buffer \ + com/sun/crypto/provider/Cipher \ :jdk_math tier2 = \ @@ -40,6 +41,7 @@ :jdk_net \ :jdk_time \ :jdk_security \ + -com/sun/crypto/provider/Cipher \ :jdk_text \ :core_tools \ :jdk_other \ There are several others security libs intrinsics too: ./java.base/share/classes/sun/security/provider/SHA5.java # implCompress0 ./java.base/share/classes/sun/security/provider/DigestBase.java # implCompressMultiBlock0 ./java.base/share/classes/sun/security/provider/SHA.java # implCompress0 ./java.base/share/classes/sun/security/provider/SHA2.java # implCompress0 However, it was not immediately clear to me where the tests for that functionality reside. Assuming they can be identified, I would like to move those tests to tier 1 as well. Thanks, -Joe From artem.smotrakov at oracle.com Wed Aug 5 11:01:03 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 05 Aug 2015 14:01:03 +0300 Subject: [9] RFR: 8075299: Additional tests for 6857795 Message-ID: <55C1ECEF.5000204@oracle.com> Hello, Please review a couple of new tests which checks if krb5 settings are read correctly from conf file and system properties. Bug: https://bugs.openjdk.java.net/browse/JDK-8075299 Webrev: http://cr.openjdk.java.net/~asmotrak/8075299/webrev.00/ Artem From weijun.wang at oracle.com Wed Aug 5 14:40:54 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 05 Aug 2015 22:40:54 +0800 Subject: [9] RFR: 8075299: Additional tests for 6857795 In-Reply-To: <55C1ECEF.5000204@oracle.com> References: <55C1ECEF.5000204@oracle.com> Message-ID: <55C22076.8090602@oracle.com> Hi Artem First, you shouldn't need any @modules here, the sun/security/krb5/auto already contains a TEST.properties file covering everything. For the same reason, you should place KinitConfPlusProps.java somewhere inside auto. If you think a subdir is better, put it into auto/tools. Back to the tests themselves: I don't see how KrbTicket.java is related to the bug description. There is no system properties mentioned. KinitConfPlusProps.java does not seems to prove that both conf file and system properties are used. Why should the 1st kinit call fail? Doesn't the principal name also contain the realm here? The conf file only contains realm and kdc and nothing else. If both conf file and system properties are provided, how do you prove the conf file is also read and not ignored? Thanks Max On 08/05/2015 07:01 PM, Artem Smotrakov wrote: > Hello, > > Please review a couple of new tests which checks if krb5 settings are > read correctly from conf file and system properties. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075299 > Webrev: http://cr.openjdk.java.net/~asmotrak/8075299/webrev.00/ > > Artem From sergey.kuksenko at oracle.com Wed Aug 5 12:09:15 2015 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Wed, 05 Aug 2015 15:09:15 +0300 Subject: RFR: 8132330: Ineffective SecureRandom usage in RSA encoding with PKCS1Padding Message-ID: <55C1FCEB.2000100@oracle.com> Hi All, Please review changes to the following performance improvement: https://bugs.openjdk.java.net/browse/JDK-8132330 Webrev: http://cr.openjdk.java.net/~skuksenko/crypto/8132330/webrev.02/ Sponsorship is required. ------ Currently sun.security.rsa.RSAPadding::padV15 uses fixed size (64 bytes) buffer for obtaining random bytes from SecureRandom. Here we got two sources of inefficiency: - when length of required padding is greater than 64 -> several calls of SecureRandom.nextBytes are required that increases contention blocking on SecureRandom - when length of required padding is less than 64 it causes unnecessary overhead (e.g. nextBytes for 16 bytes is 4x times faster than for 64 bytes) Suggested performance improvement shows RSA encoding (public key) speedup: - 10%-18% when NativePRNG SecureRandom is used, - 5%-7% when SHA1PRNG is used. -- Best regards, Sergey Kuksenko From fweimer at redhat.com Wed Aug 5 20:45:52 2015 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 5 Aug 2015 22:45:52 +0200 Subject: [9] RFC: 8061798: Add support for TLS_FALLBACK_SCSV (RFC 7507) In-Reply-To: <557F9CCE.5030504@oracle.com> References: <55491200.6010308@redhat.com> <55495555.2040004@oracle.com> <554A1A63.8070809@redhat.com> <554AA643.4050101@oracle.com> <554AFFB2.6070500@redhat.com> <556E5ECC.4080404@oracle.com> <557EA1B2.1070603@redhat.com> <557F9CCE.5030504@oracle.com> Message-ID: <55C27600.10107@redhat.com> On 06/16/2015 05:49 AM, Xuelei Fan wrote: > On 6/15/2015 5:58 PM, Florian Weimer wrote: >> On 06/03/2015 03:56 AM, Xuelei Fan wrote: >> >>> I can sponsor you for the specification update approval and changeset >>> integration if needed. >> >> I'd really appreciate that. Still applies, thanks. >>> I still have a few comments about this fix: >>> >>> 1. TLS_FALLBACK_SCSV may still be miss-used as it is defined as a >>> default enabled cipher suites. >> >> Are you sure about that? The test case looks for the string "FALLBACK" >> among the supported and enabled cipher suites, and it's not there. >> > Ah, I see your point. > > You defined K_FALLBACK_SCSV as not allowed KeyExchange (line 343), and > the cipher suite TLS_FALLBACK_SCSV as not allowed cipher suites (line > 1097-1098) although it is in the block of the default enabled cipher > suites code. > > I would like to remove the two updates above as they are not actually > allowed to be used. If I do that, the code which actually reacts to TLS_FALLBACK_SCSV never sees the SCSV because it has been filtered out before. So I had to leave this change in. >> Do you have a pointer to similar code in OpenJDK? > See the templates: > jdk/test/javax/net/ssl/templates/SSLEngineTemplate.java > jdk/test/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java With a lot of trial and error, I managed to write the EngineWrapper class. I want to call particular attention to this bit: dummy.position(dummy.limit()); networkOutput.clear(); SSLHandshakeException deferred = null; try { wrapToScratch(dummy); } catch (SSLHandshakeException e) { // During handshakes, we may receive a deferred // exception from a task, but the engine still has // data to send. deferred = e; networkOutput.clear(); try { wrapToScratch(dummy); } catch (Exception e1) { // Rethrow original exception because it is // likely more informative. throw deferred; } } networkOutput.flip(); writeFully(networkOutput); if (deferred != null) throw deferred; This happens because the handshake runs exclusively on a task (not just the bits that need blocking), and the way exceptions from tasks are handled, they overtake the data being sent. Without the above, the handshake alert is never sent because the deferred exception from the task hides the queued alert message. Quite frankly, this smells of an SSLEngine bug. (This is a separate issue from the wrong exception class for handshake exceptions.) >> The slightly awkward name is due to the fact that it's just a >> flag send to the server, and it does not cause the TLS implementation to >> perform the fallback on its own. What about this? >> >> public void setProtocolFallbackInProgress(boolean inProgress) {?} >> public boolean isProtocolFallbackInProgress() {?} >> > Sounds much better to me, except that the name is really long. I would still prefer the long name because is it is quite explicit. Its length should not matter applications should not use this interface. :) I've prepared a new webrev under: The main addition is client support in SSLEngine. -- Florian Weimer / Red Hat Product Security From artem.smotrakov at oracle.com Thu Aug 6 13:42:15 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 06 Aug 2015 16:42:15 +0300 Subject: [9] RFR: 8075299: Additional tests for 6857795 In-Reply-To: <55C22076.8090602@oracle.com> References: <55C1ECEF.5000204@oracle.com> <55C22076.8090602@oracle.com> Message-ID: <55C36437.6040605@oracle.com> Hi Max, On 08/05/2015 05:40 PM, Weijun Wang wrote: > Hi Artem > > First, you shouldn't need any @modules here, the > sun/security/krb5/auto already contains a TEST.properties file > covering everything. For the same reason, you should place > KinitConfPlusProps.java somewhere inside auto. If you think a subdir > is better, put it into auto/tools. I moved the tests to sun/security/krb5/auto > > Back to the tests themselves: > > I don't see how KrbTicket.java is related to the bug description. > There is no system properties mentioned. Right, this test doesn't use any krb5-related system properties. It only uses krb5 config file, and check if a krb ticket has appropriate state. I didn't find any test that checks it (at least, explicitly). The bug subject/description is confusing a little bit, I updated it. > > KinitConfPlusProps.java does not seems to prove that both conf file > and system properties are used. Why should the 1st kinit call fail? The test starts a local KDC instance on a random free port. Next, hostname and port number are written to krb5 config file. "java.security.krb5.kdc" specifies only a host without port. Since the property is preferable, kinit tries to connect to a local KDC on default port, and connection fails. By the way, as far as I know, currently it is not possible to specify a port number in "java.security.krb5.kdc". http://hg.openjdk.java.net/jdk9/dev/jdk/file/66e2bdad38a8/src/java.security.jgss/share/classes/sun/security/krb5/Config.java It may be better to make it possible. I am not sure that ":" symbol can be used here because of compatibility risks. Currently it is used to separate hostnames: String tmp = getProperty("java.security.krb5.kdc"); if (tmp != null) { // The user can specify a list of kdc hosts separated by ":" defaultKDC = tmp.replace(':', ' '); } else { defaultKDC = null; } What do you think? > Doesn't the principal name also contain the realm here? Yes, it does. I think it would be better to use a principal name without realm here since krb config contain it. I updated the test. > The conf file only contains realm and kdc and nothing else. If both > conf file and system properties are provided, how do you prove the > conf file is also read and not ignored? The test doesn't check it. I see the following ways to check it: - Corrupt krb5 conf, and run kinit with it. I suppose it should fail. - Add some extra parameters to krb5, run kinit, and then try to use obtained data, and check that those extra parameters were used (I am not sure about details right now, need to do some experiments) What do you think? Thanks for review. Please take a look at updated webrev http://cr.openjdk.java.net/~asmotrak/8075299/webrev.01/ Artem > > Thanks > Max > > On 08/05/2015 07:01 PM, Artem Smotrakov wrote: >> Hello, >> >> Please review a couple of new tests which checks if krb5 settings are >> read correctly from conf file and system properties. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8075299 >> Webrev: http://cr.openjdk.java.net/~asmotrak/8075299/webrev.00/ >> >> Artem From volker.simonis at gmail.com Thu Aug 6 14:53:50 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 6 Aug 2015 16:53:50 +0200 Subject: RFR(XS): 8132551: Initialize local variables before returning them in p11_convert.c Message-ID: Hi, can somebody please review these trivial change which initializes local variables before they are returned as return values: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132551 https://bugs.openjdk.java.net/browse/JDK-8132551 Funny enough, this was objected by the Visual Studio compiler in the slowdebug build only but not in the product or debug builds. Thank you and best regards, Volker From sean.mullan at oracle.com Thu Aug 6 16:41:38 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 06 Aug 2015 12:41:38 -0400 Subject: JDK 9 RFR of JDK-8132855: Adjust tier 1 and 2 definitions for security-related intrinsics In-Reply-To: <55C10F83.6030501@oracle.com> References: <55C10F83.6030501@oracle.com> Message-ID: <55C38E42.7090201@oracle.com> On 08/04/2015 03:16 PM, joe darcy wrote: > Hello, > > As a complement to JDK-8132854: Adjust tier 1 and 2 definitions for > nio-related intrinsics, with the fix for > > JDK-8076112: Add @HotSpotIntrinsicCandidate annotation to > indicate methods for which Java Runtime has intrinsics > > the sources for the libraries clearly indicate which methods might have > intrinsic support in HotSpot, that is, which methods might have their > Java source implementation replaced by some other code sequence > maintained in HotSpot, such as a special-purpose processor-specific > instruction. To ease testing, it would be helpful if all the > intrinsified methods were included in the tier 1 test group. Most of the > intrinics are in java.lang, java.math, and java.util, packages whose > tests are already in tier 1. > > Several security libraries are marked with @HotSpotIntrinsicCandidate > including: > > ./java.base/share/classes/com/sun/crypto/provider/GHASH.java # internal > processBlocks method to ghash > ./java.base/share/classes/com/sun/crypto/provider/AESCrypt.java # > implEncryptBlock, implDecryptBlock > ./java.base/share/classes/com/sun/crypto/provider/CipherBlockChaining.java > # implEncrypt, implDecrypt > > The tests for those libraries seem to be included in the security2 test > group which is part of tier 2. I propose to move the tests for that > functionality to tier 1: > > diff -r 9bce83952890 test/TEST.groups > --- a/test/TEST.groups Tue Aug 04 11:26:51 2015 -0700 > +++ b/test/TEST.groups Tue Aug 04 12:09:59 2015 -0700 > @@ -30,6 +30,7 @@ > :jdk_util \ > sun/nio/cs/ISO8859x.java \ > java/nio/Buffer \ > + com/sun/crypto/provider/Cipher \ > :jdk_math > > tier2 = \ > @@ -40,6 +41,7 @@ > :jdk_net \ > :jdk_time \ > :jdk_security \ > + -com/sun/crypto/provider/Cipher \ > :jdk_text \ > :core_tools \ > :jdk_other \ Looks good to me. > > There are several others security libs intrinsics too: > > ./java.base/share/classes/sun/security/provider/SHA5.java # implCompress0 > ./java.base/share/classes/sun/security/provider/DigestBase.java # > implCompressMultiBlock0 > ./java.base/share/classes/sun/security/provider/SHA.java # implCompress0 > ./java.base/share/classes/sun/security/provider/SHA2.java # implCompress0 > > However, it was not immediately clear to me where the tests for that > functionality reside. Assuming they can be identified, I would like to > move those tests to tier 1 as well. These intrinsics were implemented in JEP 207. Looking at the associated changesets, it looks like the tests were put in the hotspot repo: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/edf93f2ccf99/test/compiler/intrinsics/sha/TestSHA.java --Sean From sean.mullan at oracle.com Thu Aug 6 20:06:20 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 06 Aug 2015 16:06:20 -0400 Subject: RFR: JDK-8077055 : Allow other named SecurityPermissions, RuntimePermissions, and AuthPermissions to be used Message-ID: <55C3BE3C.6060103@oracle.com> Please review this small specification change to allow implementations to define additional implementation-specific target names for SecurityPermission, RuntimePermission, and AuthPermission: webrev: http://cr.openjdk.java.net/~mullan/webrevs/8077055/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8077055 Thanks, Sean From bradford.wetmore at oracle.com Thu Aug 6 23:42:44 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 6 Aug 2015 16:42:44 -0700 Subject: RFR(XS): 8132551: Initialize local variables before returning them in p11_convert.c In-Reply-To: References: Message-ID: <55C3F0F4.5020706@oracle.com> Looks good. Thanks. Brad On 8/6/2015 7:53 AM, Volker Simonis wrote: > Hi, > > can somebody please review these trivial change which initializes > local variables before they are returned as return values: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8132551 > https://bugs.openjdk.java.net/browse/JDK-8132551 > > Funny enough, this was objected by the Visual Studio compiler in the > slowdebug build only but not in the product or debug builds. > > Thank you and best regards, > Volker > From schlosna at gmail.com Fri Aug 7 10:41:31 2015 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 7 Aug 2015 06:41:31 -0400 Subject: RFR: 8132330: Ineffective SecureRandom usage in RSA encoding with PKCS1Padding In-Reply-To: <55C1FCEB.2000100@oracle.com> References: <55C1FCEB.2000100@oracle.com> Message-ID: What happens in the case Where there are not enough non-zero random bytes in the new version? On Wednesday, August 5, 2015, Sergey Kuksenko wrote: > Hi All, > > Please review changes to the following performance improvement: > > https://bugs.openjdk.java.net/browse/JDK-8132330 > > Webrev: http://cr.openjdk.java.net/~skuksenko/crypto/8132330/webrev.02/ > > Sponsorship is required. > > ------ > Currently sun.security.rsa.RSAPadding::padV15 uses fixed size (64 bytes) > buffer for obtaining random bytes from SecureRandom. > Here we got two sources of inefficiency: > - when length of required padding is greater than 64 -> several calls of > SecureRandom.nextBytes are required that increases contention blocking on > SecureRandom > - when length of required padding is less than 64 it causes unnecessary > overhead (e.g. nextBytes for 16 bytes is 4x times faster than for 64 bytes) > > Suggested performance improvement shows RSA encoding (public key) speedup: > - 10%-18% when NativePRNG SecureRandom is used, > - 5%-7% when SHA1PRNG is used. > > > -- > Best regards, > Sergey Kuksenko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlosna at gmail.com Fri Aug 7 11:40:31 2015 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 7 Aug 2015 07:40:31 -0400 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: <4F0F677B.4090406@oracle.com> References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> <4F0E31B9.8040609@oracle.com> <4F0F677B.4090406@oracle.com> Message-ID: // reviving this ghost Hi Valerie, Sean, and sec-dev, I am curious if there has been any movement on incorporating a fix for https://bugs.openjdk.java.net/browse/JDK-7092821? I have encountered several systems where this is a significant contention and scale bottleneck. While there are some workarounds such as pooling and reusing Provider instances, that seems like a band-aid, and fixing the JDK is a better path. If I were to put a webrev together, would someone be kind enough to sponsor it for me? Are there any existing open source load tests to verify these changes? Is there a good mechanism in OpenJDK now to run JMH across all of the supported platforms (I only have access to a small subset of the permutation of platforms). Thanks! - Dave On Thursday, January 12, 2012, Valerie (Yu-Ching) Peng < valerie.peng at oracle.com> wrote: > Dave, > Thanks for the comments. > Let me think about it some more and see how to better address this kind of > racing issue. > > If you have concerns on fixes for 7033170 and 7092825, please let me know. > > Sean, > Can you please ignore the review request for 7092821 for now. I'll send > out an updated version later. > If you can still review the remaining two, that'd be great. > > Thanks, > Valerie > > On 01/11/12 21:48, David Schlosnagle wrote: > >> On Wed, Jan 11, 2012 at 8:04 PM, Valerie (Yu-Ching) Peng >> wrote: >> >>> 7092821: java.security.Provider.getService() is synchronized and became >>> scalability bottleneck. >>> jdk7u Webrev: http://cr.openjdk.java.net/~valeriep/7092821_7u/ >>> jdk8 Webrev: http://cr.openjdk.java.net/~valeriep/7092821/ >>> >> Valerie, >> >> You might already be aware of this, but there is a data race on lines >> 685 - 686 of the Provider's getService(String, String) method. If >> there are concurrent callers to getService while lookupCache == null, >> the lookupCache may be overwritten by a new ConcurrentHashMap after >> another thread has just instantiated and populated an entry in the >> cache leading to thrashing on lookupCache. It might be worthwhile to >> either use a double checked lock to avoid the race at the expense of >> an additional lock and volatile read in the case lookupCache == null >> or add a comment indicating that this is an accepted data race. >> >> There is also now the possibility that if one thread is executing >> getService while another thread invokes one of the methods that sets >> lookupCache = null, there could then be a NullPointerException on line >> 703 as the volatile read would now see a null and fail. You could >> prevent that by either moving the putIfAbsent under the lock (not >> ideal for performance if you're already seeing contention), or just >> maintain a local reference to the cache map and use it throughout the >> getService method. This would mean that if the lookupCache reference >> was concurrently mutated, the putIfAbsent would basically be a write >> to the local map reference which is now garbage, but shouldn't really >> hurt anything. >> >> I'd propose something along the lines of the following to address this: >> >> public Service getService(String type, String algorithm) { >> ServiceKey key = new ServiceKey(type, algorithm); >> ConcurrentMap localLookupCache = >> getLookupCache(); >> Service result = localLookupCache.get(key); >> if (result != null) { >> return (result == NULL_MARK? null : result); >> } >> synchronized (this) { >> checkInitialized(); >> if (serviceMap != null) { >> result = serviceMap.get(key); >> } >> if (result == null) { >> ensureLegacyParsed(); >> result = (legacyMap != null) ? legacyMap.get(key) : null; >> } >> } >> // under concurrent mutation of lookupCache, this will write >> to map that is no >> // longer the active cache >> localLookupCache.putIfAbsent(key, (result == null? NULL_MARK : >> result)); >> return result; >> } >> >> private ConcurrentMap getLookupCache() { >> if (lookupCache == null) { >> synchronized (this) { >> // must fall back on double checked lock >> if (lookupCache == null) { >> lookupCache = new ConcurrentHashMap<>(); >> } >> } >> } >> return lookupCache; >> } >> >> >> - Dave >> >> >> For reference, here were the original changes: >> 429 // Cache for service lookups. Discard whenever services are >> changed. >> 430 private transient volatile ConcurrentMap >> lookupCache; >> ...snip... >> 682 public Service getService(String type, String algorithm) { >> 683 ServiceKey key = new ServiceKey(type, algorithm); >> 684 Service result = null; >> 685 if (lookupCache == null) { >> 686 lookupCache = new ConcurrentHashMap<>(); >> 687 } else { >> 688 result = lookupCache.get(key); >> 689 if (result != null) { >> 690 return (result == NULL_MARK? null : result); >> 691 } >> 692 } >> 693 synchronized (this) { >> 694 checkInitialized(); >> 695 if (serviceMap != null) { >> 696 result = serviceMap.get(key); >> 697 } >> 698 if (result == null) { >> 699 ensureLegacyParsed(); >> 700 result = (legacyMap != null) ? legacyMap.get(key) : >> null; >> 701 } >> 702 } >> 703 lookupCache.putIfAbsent(key, (result == null? NULL_MARK : >> result)); >> 704 return result; >> 705 } >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlosna at gmail.com Fri Aug 7 12:44:50 2015 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 7 Aug 2015 08:44:50 -0400 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> <4F0E31B9.8040609@oracle.com> <4F0F677B.4090406@oracle.com> Message-ID: I forgot to mention one other workaround for this bug, as used in Guava is cloning the instance if clone() is supported, see https://github.com/google/guava/issues/1197 On Friday, August 7, 2015, David Schlosnagle wrote: > // reviving this ghost > > Hi Valerie, Sean, and sec-dev, > > I am curious if there has been any movement on incorporating a fix for > https://bugs.openjdk.java.net/browse/JDK-7092821? I have encountered > several systems where this is a significant contention and > scale bottleneck. While there are some workarounds such as pooling and > reusing Provider instances, that seems like a band-aid, and fixing the JDK > is a better path. > > If I were to put a webrev together, would someone be kind enough to sponsor > it for me? Are there any existing open source load tests to verify these > changes? Is there a good mechanism in OpenJDK now to run JMH across all of > the supported platforms (I only have access to a small subset of the > permutation of platforms). > > Thanks! > > - Dave > > On Thursday, January 12, 2012, Valerie (Yu-Ching) Peng < > valerie.peng at oracle.com > > wrote: > >> Dave, >> Thanks for the comments. >> Let me think about it some more and see how to better address this kind >> of racing issue. >> >> If you have concerns on fixes for 7033170 and 7092825, please let me know. >> >> Sean, >> Can you please ignore the review request for 7092821 for now. I'll send >> out an updated version later. >> If you can still review the remaining two, that'd be great. >> >> Thanks, >> Valerie >> >> On 01/11/12 21:48, David Schlosnagle wrote: >> >>> On Wed, Jan 11, 2012 at 8:04 PM, Valerie (Yu-Ching) Peng >>> wrote: >>> >>>> 7092821: java.security.Provider.getService() is synchronized and became >>>> scalability bottleneck. >>>> jdk7u Webrev: http://cr.openjdk.java.net/~valeriep/7092821_7u/ >>>> jdk8 Webrev: http://cr.openjdk.java.net/~valeriep/7092821/ >>>> >>> Valerie, >>> >>> You might already be aware of this, but there is a data race on lines >>> 685 - 686 of the Provider's getService(String, String) method. If >>> there are concurrent callers to getService while lookupCache == null, >>> the lookupCache may be overwritten by a new ConcurrentHashMap after >>> another thread has just instantiated and populated an entry in the >>> cache leading to thrashing on lookupCache. It might be worthwhile to >>> either use a double checked lock to avoid the race at the expense of >>> an additional lock and volatile read in the case lookupCache == null >>> or add a comment indicating that this is an accepted data race. >>> >>> There is also now the possibility that if one thread is executing >>> getService while another thread invokes one of the methods that sets >>> lookupCache = null, there could then be a NullPointerException on line >>> 703 as the volatile read would now see a null and fail. You could >>> prevent that by either moving the putIfAbsent under the lock (not >>> ideal for performance if you're already seeing contention), or just >>> maintain a local reference to the cache map and use it throughout the >>> getService method. This would mean that if the lookupCache reference >>> was concurrently mutated, the putIfAbsent would basically be a write >>> to the local map reference which is now garbage, but shouldn't really >>> hurt anything. >>> >>> I'd propose something along the lines of the following to address this: >>> >>> public Service getService(String type, String algorithm) { >>> ServiceKey key = new ServiceKey(type, algorithm); >>> ConcurrentMap localLookupCache = >>> getLookupCache(); >>> Service result = localLookupCache.get(key); >>> if (result != null) { >>> return (result == NULL_MARK? null : result); >>> } >>> synchronized (this) { >>> checkInitialized(); >>> if (serviceMap != null) { >>> result = serviceMap.get(key); >>> } >>> if (result == null) { >>> ensureLegacyParsed(); >>> result = (legacyMap != null) ? legacyMap.get(key) : >>> null; >>> } >>> } >>> // under concurrent mutation of lookupCache, this will write >>> to map that is no >>> // longer the active cache >>> localLookupCache.putIfAbsent(key, (result == null? NULL_MARK : >>> result)); >>> return result; >>> } >>> >>> private ConcurrentMap getLookupCache() { >>> if (lookupCache == null) { >>> synchronized (this) { >>> // must fall back on double checked lock >>> if (lookupCache == null) { >>> lookupCache = new ConcurrentHashMap<>(); >>> } >>> } >>> } >>> return lookupCache; >>> } >>> >>> >>> - Dave >>> >>> >>> For reference, here were the original changes: >>> 429 // Cache for service lookups. Discard whenever services are >>> changed. >>> 430 private transient volatile ConcurrentMap >>> lookupCache; >>> ...snip... >>> 682 public Service getService(String type, String algorithm) { >>> 683 ServiceKey key = new ServiceKey(type, algorithm); >>> 684 Service result = null; >>> 685 if (lookupCache == null) { >>> 686 lookupCache = new ConcurrentHashMap<>(); >>> 687 } else { >>> 688 result = lookupCache.get(key); >>> 689 if (result != null) { >>> 690 return (result == NULL_MARK? null : result); >>> 691 } >>> 692 } >>> 693 synchronized (this) { >>> 694 checkInitialized(); >>> 695 if (serviceMap != null) { >>> 696 result = serviceMap.get(key); >>> 697 } >>> 698 if (result == null) { >>> 699 ensureLegacyParsed(); >>> 700 result = (legacyMap != null) ? legacyMap.get(key) >>> : null; >>> 701 } >>> 702 } >>> 703 lookupCache.putIfAbsent(key, (result == null? NULL_MARK : >>> result)); >>> 704 return result; >>> 705 } >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Aug 7 13:16:20 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 07 Aug 2015 09:16:20 -0400 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> <4F0E31B9.8040609@oracle.com> <4F0F677B.4090406@oracle.com> Message-ID: <55C4AFA4.6000300@oracle.com> Hi David, On 08/07/2015 08:44 AM, David Schlosnagle wrote: > I forgot to mention one other workaround for this bug, as used in Guava > is cloning the instance if clone() is supported, see > https://github.com/google/guava/issues/1197 > > On Friday, August 7, 2015, David Schlosnagle > wrote: > > // reviving this ghost > > Hi Valerie, Sean, and sec-dev, > > I am curious if there has been any movement on incorporating a fix > for https://bugs.openjdk.java.net/browse/JDK-7092821? I have > encountered several systems where this is a significant contention > and scale bottleneck. While there are some workarounds such as > pooling and reusing Provider instances, that seems like a band-aid, > and fixing the JDK is a better path. I don't know if Valerie has made any progress on this issue, so I'll let her add any details. > > If I were to put a webrev together, would someone be kind enough > to sponsor it for me? Yes, I think we could do that and I see you have already signed the OCA. > Are there any existing open source load tests > to verify these changes? Not that I know of. It would be great if you could implement a JMH microbenchmark as part of your fix. > Is there a good mechanism in OpenJDK now to > run JMH across all of the supported platforms (I only have access to > a small subset of the permutation of platforms). That's being worked on for JDK 9 but AFAIK it isn't ready yet. See http://openjdk.java.net/jeps/230 Thanks for your help! --Sean > > Thanks! > > - Dave > > On Thursday, January 12, 2012, Valerie (Yu-Ching) Peng > > wrote: > > Dave, > Thanks for the comments. > Let me think about it some more and see how to better address > this kind of racing issue. > > If you have concerns on fixes for 7033170 and 7092825, please > let me know. > > Sean, > Can you please ignore the review request for 7092821 for now. > I'll send out an updated version later. > If you can still review the remaining two, that'd be great. > > Thanks, > Valerie > > On 01/11/12 21:48, David Schlosnagle wrote: > > On Wed, Jan 11, 2012 at 8:04 PM, Valerie (Yu-Ching) Peng > wrote: > > 7092821: java.security.Provider.getService() is > synchronized and became scalability bottleneck. > jdk7u Webrev: > http://cr.openjdk.java.net/~valeriep/7092821_7u/ > jdk8 Webrev: http://cr.openjdk.java.net/~valeriep/7092821/ > > Valerie, > > You might already be aware of this, but there is a data race > on lines > 685 - 686 of the Provider's getService(String, String) > method. If > there are concurrent callers to getService while lookupCache > == null, > the lookupCache may be overwritten by a new > ConcurrentHashMap after > another thread has just instantiated and populated an entry > in the > cache leading to thrashing on lookupCache. It might be > worthwhile to > either use a double checked lock to avoid the race at the > expense of > an additional lock and volatile read in the case lookupCache > == null > or add a comment indicating that this is an accepted data race. > > There is also now the possibility that if one thread is > executing > getService while another thread invokes one of the methods > that sets > lookupCache = null, there could then be a > NullPointerException on line > 703 as the volatile read would now see a null and fail. You > could > prevent that by either moving the putIfAbsent under the lock > (not > ideal for performance if you're already seeing contention), > or just > maintain a local reference to the cache map and use it > throughout the > getService method. This would mean that if the lookupCache > reference > was concurrently mutated, the putIfAbsent would basically be > a write > to the local map reference which is now garbage, but > shouldn't really > hurt anything. > > I'd propose something along the lines of the following to > address this: > > public Service getService(String type, String algorithm) { > ServiceKey key = new ServiceKey(type, algorithm); > ConcurrentMap > localLookupCache = getLookupCache(); > Service result = localLookupCache.get(key); > if (result != null) { > return (result == NULL_MARK? null : result); > } > synchronized (this) { > checkInitialized(); > if (serviceMap != null) { > result = serviceMap.get(key); > } > if (result == null) { > ensureLegacyParsed(); > result = (legacyMap != null) ? > legacyMap.get(key) : null; > } > } > // under concurrent mutation of lookupCache, this > will write > to map that is no > // longer the active cache > localLookupCache.putIfAbsent(key, (result == null? > NULL_MARK : result)); > return result; > } > > private ConcurrentMap > getLookupCache() { > if (lookupCache == null) { > synchronized (this) { > // must fall back on double checked lock > if (lookupCache == null) { > lookupCache = new ConcurrentHashMap<>(); > } > } > } > return lookupCache; > } > > > - Dave > > > For reference, here were the original changes: > 429 // Cache for service lookups. Discard whenever > services are changed. > 430 private transient volatile > ConcurrentMap > lookupCache; > ...snip... > 682 public Service getService(String type, String > algorithm) { > 683 ServiceKey key = new ServiceKey(type, algorithm); > 684 Service result = null; > 685 if (lookupCache == null) { > 686 lookupCache = new ConcurrentHashMap<>(); > 687 } else { > 688 result = lookupCache.get(key); > 689 if (result != null) { > 690 return (result == NULL_MARK? null : > result); > 691 } > 692 } > 693 synchronized (this) { > 694 checkInitialized(); > 695 if (serviceMap != null) { > 696 result = serviceMap.get(key); > 697 } > 698 if (result == null) { > 699 ensureLegacyParsed(); > 700 result = (legacyMap != null) ? > legacyMap.get(key) : null; > 701 } > 702 } > 703 lookupCache.putIfAbsent(key, (result == null? > NULL_MARK : result)); > 704 return result; > 705 } > > From sergey.kuksenko at oracle.com Fri Aug 7 13:58:46 2015 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Fri, 07 Aug 2015 16:58:46 +0300 Subject: RFR: 8132330: Ineffective SecureRandom usage in RSA encoding with PKCS1Padding In-Reply-To: References: <55C1FCEB.2000100@oracle.com> Message-ID: <55C4B996.7020508@oracle.com> The same as before. We will request a new portion of random bytes. On 08/07/2015 01:41 PM, David Schlosnagle wrote: > What happens in the case Where there are not enough non-zero random > bytes in the new version? > > On Wednesday, August 5, 2015, Sergey Kuksenko > > wrote: > > Hi All, > > Please review changes to the following performance improvement: > > https://bugs.openjdk.java.net/browse/JDK-8132330 > > Webrev: http://cr.openjdk.java.net/~skuksenko/crypto/8132330/webrev.02/ > > Sponsorship is required. > > ------ > Currently sun.security.rsa.RSAPadding::padV15 uses fixed size (64 > bytes) buffer for obtaining random bytes from SecureRandom. > Here we got two sources of inefficiency: > - when length of required padding is greater than 64 -> several > calls of SecureRandom.nextBytes are required that increases > contention blocking on SecureRandom > - when length of required padding is less than 64 it causes > unnecessary overhead (e.g. nextBytes for 16 bytes is 4x times faster > than for 64 bytes) > > Suggested performance improvement shows RSA encoding (public key) > speedup: > - 10%-18% when NativePRNG SecureRandom is used, > - 5%-7% when SHA1PRNG is used. > > > -- > Best regards, > Sergey Kuksenko > -- Best regards, Sergey Kuksenko From valerie.peng at oracle.com Fri Aug 7 23:25:27 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 07 Aug 2015 16:25:27 -0700 Subject: [9] RFR 8130665 "java/lang/SecurityManager/CheckSecurityProvider.java failing in jake on OS X" Message-ID: <55C53E67.1020705@oracle.com> Hi, Sean and build experts, Can you please review the fix for 8130665 "java/lang/SecurityManager/CheckSecurityProvider.java failing in jake on OS X"? The Apple provider fails to be instantiated in Jake due to the missing permission grants. However, it currently only fails in Jake workspace and fix is verified by running JPRT against Jake. Given that Apple provider only presents for Mac OSX, its policy file is under the macosx directory and I have to make minor modifications to pick up that file for MacOSX build. Here is the webrev: http://cr.openjdk.java.net/~valeriep/8130665/webrev.00/ Thanks, Valerie From weijun.wang at oracle.com Sat Aug 8 13:56:57 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 08 Aug 2015 21:56:57 +0800 Subject: RFC: OpenJDK JarSigner API Message-ID: <55C60AA9.4020709@oracle.com> Hi All JDK 9 is more restricted on calling sun.* public methods but we know there are users calling sun.security.tools.jarsigner.Main to sign jar files. A new API is proposed for this very purpose in OpenJDK. Please note it is defined in a jdk.* package therefore not a Java SE API. We are also thinking of an API to cover keytool functions. Stay tuned. The new API does not cover every option of the existing jarsigner tool, for example, -altsign, -tsapolicyid, -tsadigestalg, -internalsf, -sectionsonly, etc, but we hope it is enough in most use cases. All suggestions are welcome. Thanks Max package jdk.security.jarsigner; /** * An immutable utility class to sign a jar file. *

* A caller creates a {@code JarSigner.Builder} object, (optionally) sets some * parameters, and then calls the {@link JarSigner.Builder#build build} method * to create a {@code JarSigner} object. This {@code JarSigner} object can then * be used to sign a jar file. *

* Unless otherwise stated, calling a method of {@code JarSigner} or * {@code JarSigner.Builder} with a null argument will throw * a {@link NullPointerException}. *

* Example: * 

  * JarSigner signer = new JarSigner.Builder(key, certPath)
  *         .digestAlg("SHA-1")
  *         .sigAlg("SHA1withDSA")
  *         .build();
  * try (ZipFile in = new ZipFile(inputFile);
  *         FileOutputStream out = new FileOutputStream(outFile)) {
  *     signer.sign(in, out);
  * }
  *
* * @since 1.9 */ @jdk.Exported public final class JarSigner { /** * A mutable builder class that can create an immutable {@code JarSigner} * from various signing-related parameters. * * @since 1.9 */ @jdk.Exported public static class Builder { /** * Creates a {@code JarSigner.Builder} object with * a {@link KeyStore.PrivateKeyEntry} object. * * @param entry the {@link KeyStore.PrivateKeyEntry} of the signer. */ public Builder(KeyStore.PrivateKeyEntry entry); /** * Creates a {@code JarSigner.Builder} object with a private key and * a certification path. * * @param privateKey the private key of the signer. * @param certPath the certification path of the signer. * @throws IllegalArgumentException if {@code certPath} is empty, or * the {@code privateKey} algorithm does not match the algorithm * of the {@code PublicKey} in the end entity certificate * (the first certificate in {@code certPath}). */ public Builder(PrivateKey privateKey, CertPath certPath); /** * Sets the digest algorithm. If no digest algorithm is specified, * the default algorithm returned by {@link #getDefaultDigestAlg} * will be used. * * @param algorithm the standard name of the algorithm. See * the MessageDigest section in the * Java Cryptography Architecture Standard Algorithm Name * Documentation for information about standard algorithm names. * @return the {@code JarSigner.Builder} itself. * @throws NoSuchAlgorithmException if {@code algorithm} is not available. */ public Builder digestAlg(String algorithm) throws NoSuchAlgorithmException; /** * Sets the digest algorithm from the specified provider. * If no digest algorithm is specified, the default algorithm * returned by {@link #getDefaultDigestAlg} will be used. * * @param algorithm the standard name of the algorithm. See * the MessageDigest section in the * Java Cryptography Architecture Standard Algorithm Name * Documentation for information about standard algorithm names. * @param provider the provider. * @return the {@code JarSigner.Builder} itself. * @throws NoSuchAlgorithmException if {@code algorithm} is not available * in the specified provider. */ public Builder digestAlg(String algorithm, Provider provider) throws NoSuchAlgorithmException; /** * Sets the signature algorithm. If no signature algorithm * is specified, the default signature algorithm returned by * {@link #getDefaultSigAlg} for the private key algorithm will be used. * * @param algorithm the standard name of the algorithm. See * the Signature section in the * Java Cryptography Architecture Standard Algorithm Name * Documentation for information about standard algorithm names. * @return the {@code JarSigner.Builder} itself. * @throws NoSuchAlgorithmException if {@code algorithm} is not available. * @throws IllegalArgumentException if {@code algorithm} is not compatible * with the algorithm of the signer's private key. */ public Builder sigAlg(String algorithm) throws NoSuchAlgorithmException; /** * Sets the signature algorithm from the specified provider. * If no signature algorithm is specified, the default signature algorithm * returned by {@link #getDefaultSigAlg} for the private key algorithm * will be used. * * @param algorithm the standard name of the algorithm. See * the Signature section in the * Java Cryptography Architecture Standard Algorithm Name * Documentation for information about standard algorithm names. * @param provider the provider. * @return the {@code JarSigner.Builder} itself. * @throws NoSuchAlgorithmException if {@code algorithm} is not available * in the specified provider. * @throws IllegalArgumentException if {@code algorithm} is not compatible * with the algorithm of the signer's private key. */ public Builder sigAlg(String algorithm, Provider provider) throws NoSuchAlgorithmException; /** * Sets the URI of the Time Stamping Authority (TSA). * * @param uri the URI. * @return the {@code JarSigner.Builder} itself. */ public Builder tsa(URI uri); /** * Sets the signer name. The name will be used as the base name for * the signature files. All lowercase characters will be converted to * uppercase for signature file names. If a signer name is not * specified, the string "SIGNER" will be used. * * @param name the signer name. * @return the {@code JarSigner.Builder} itself. * @throws IllegalArgumentException if {@code name} is empty or has a size * bigger than 8, or it contains characters not from the set * "a-zA-Z0-9_-". */ public Builder signerName(String name); /** * Gets the default digest algorithm. * * @implNote This implementation returns "SHA-256". The value may * change in the future. * * @return the default digest algorithm. */ public static String getDefaultDigestAlg(); /** * Gets the default signature algorithm for a private key algorithm. * For example, SHA256withRSA for RSA, and SHA256withDSA for DSA. * * @implNote This implementation returns "SHA256withDSA" for the "DSA" * key algorithm, "SHA256withRSA" for "RSA", "SHA256withECDSA" for "EC", * and {@code null} otherwise. The value(s) may change in the future. * * @param keyAlg the key algorithm. * @return the default signature algorithm. Returns null if a default * signature algorithm cannot be found. In this case, {@link #sigAlg} * must be called to specify a signature algorithm. Otherwise, * the {@link #build} method will throw an {@link IllegalArgumentException}. * @throws IllegalArgumentException if {@code keyAlg} is empty. */ public static String getDefaultSigAlg(String keyAlg); /** * Builds a {@code JarSigner} object from the parameters set by the * setter methods. *

* This method does not modify internal state of this {@code Builder} * object and can be called multiple times to generate multiple * {@code JarSigner} objects. After a {@code JarSigner} object is * built, calling any setter method on this {@code Builder} will have * no effect on it. * * @return the {@code JarSigner} object. * @throws IllegalArgumentException if a signature algorithm is not * set and cannot be derived from the private key using the * {@link #getDefaultSigAlg} method. */ public JarSigner build(); } /** * Signs a file into an {@link OutputStream}. This method will not close * {@code file} or {@code os}. * * @param file the file to sign. * @param os the output stream. * @throws JarSignerException if the signing fails. */ public void sign(ZipFile file, OutputStream os); /** * Returns the digest algorithm for this {@code JarSigner}. * @return the digest algorithm. The return value is never null. */ public String getDigestAlg(); /** * Returns the signature algorithm for this {@code JarSigner}. * @return the signature algorithm. The return value is never null. */ public String getSigAlg(); /** * Returns the URI of the Time Stamping Authority (TSA). * @return the URI of the TSA. */ public URI getTsa(); /** * Returns the signer name of this {@code JarSigner}. * @return the signer name. The return value is never null. */ public String getSignerName(); } /** * This exception is thrown when {@link JarSigner#sign} fails. * * @since 1.9 */ @jdk.Exported public class JarSignerException extends RuntimeException { private static final long serialVersionUID = -4732217075689309530L; /** * Constructs a new {@code JarSignerException} with the specified detail * message and cause.

Note that the detail message associated with * {@code cause} is not automatically incorporated in * this {@code JarSignerException}'s detail message. * * @param message the detail message (which is saved for later retrieval * by the {@link #getMessage()} method). * @param cause the cause (which is saved for later retrieval by the * {@link #getCause()} method). (A null value is * permitted, and indicates that the cause is nonexistent or * unknown.) */ public JarSignerException(String message, Throwable cause); } From erik.joelsson at oracle.com Mon Aug 10 10:49:46 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Aug 2015 12:49:46 +0200 Subject: [9] RFR 8130665 "java/lang/SecurityManager/CheckSecurityProvider.java failing in jake on OS X" In-Reply-To: <55C53E67.1020705@oracle.com> References: <55C53E67.1020705@oracle.com> Message-ID: <55C881CA.9030701@oracle.com> Hello Valerie, To reduce duplication, I think something like this would be preferable. Remove the windows and macosx checks and just always run this line: POLICY_SRC_LIST += \ $(wildcard $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/conf/security/java.policy) That way, I platform specific file is always picked up if found. /Erik On 2015-08-08 01:25, Valerie Peng wrote: > Hi, Sean and build experts, > > Can you please review the fix for 8130665 > "java/lang/SecurityManager/CheckSecurityProvider.java failing in jake > on OS X"? > The Apple provider fails to be instantiated in Jake due to the missing > permission grants. > However, it currently only fails in Jake workspace and fix is verified > by running JPRT against Jake. > > Given that Apple provider only presents for Mac OSX, its policy file > is under the macosx directory and I have to make minor modifications > to pick up that file for MacOSX build. > > Here is the webrev: > http://cr.openjdk.java.net/~valeriep/8130665/webrev.00/ > > Thanks, > Valerie From svetlana.nikandrova at oracle.com Mon Aug 10 12:57:21 2015 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Mon, 10 Aug 2015 15:57:21 +0300 Subject: [9] review request for JDK-8050460: JAAS login/logout tests with LoginContext Message-ID: <55C89FB1.9050007@oracle.com> Hello, Please review tests for login/logout with LoginContex. Webrev: http://cr.openjdk.java.net/~asmotrak/sweta/8050460/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8050460 Thanks, Svetlana From rajan.halade at oracle.com Mon Aug 10 20:44:37 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Mon, 10 Aug 2015 13:44:37 -0700 Subject: [9] RFR: 8048624: Tests for SealedObject In-Reply-To: <55B15AAD.6040108@oracle.com> References: <55A98E0F.7040409@oracle.com> <55B15AAD.6040108@oracle.com> Message-ID: <55C90D35.8090603@oracle.com> Hi Valerie, I have updated the webrev after your comment and our discussion to only retain TestSealedObjectNull test. http://cr.openjdk.java.net/~rhalade/8048624/webrev.01/ Thanks, Rajan On 7/23/15 2:20 PM, Valerie Peng wrote: > > > - I think it's more universal to call getParameters() instead of > getIV(). Otherwise, if the test is enhanced with GCM mode, it will not > work. > - Certain combination of mode and padding require certain input > length. With SealedObject, the input to the Cipher object is the > "serialized" bytes. Otherwise, IllegalBlockSizeException will be > thrown. If the test coverage is about SealedObject code, we don't need > these many different combinations. What is the aim for coverage here? > - DES, DESede and Blowfish and no AES? Note that AES block size is 16 > bytes, so the current input will need to be adjusted. Currently, the > serialized form is 24 bytes. You need to bump it up to at least 32 > bytes to avoid IllegalBlockSizeException. > > > - This is not really testing NullCipher. If you replace NullCipher > with any other cipher, this test would still pass. > - Well, in reality, no one will ever use SealedObject with NullCipher, > I can't think of a reason to. I wonder if anyone actually uses > NullCipher. What is the purpose of this test? > > Thanks, > Valerie > > On 7/17/2015 4:21 PM, Rajan Halade wrote: >> May I request you to review two new tests added to check SealedObject >> with different ciphers. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048624 >> Webrev: http://cr.openjdk.java.net/~rhalade/8048624/webrev/ >> >> Thanks, >> Rajan From valerie.peng at oracle.com Mon Aug 10 22:47:15 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 10 Aug 2015 15:47:15 -0700 Subject: RFR 8044199: tests for RSA keys and key specifications In-Reply-To: References: Message-ID: <55C929F3.8070801@oracle.com> Tristan, - Given that the tests are against SunRsaSign provider, I think sun/security/rsa subdirectory is a better choice than java/security/rsa. - Put @test and @bug on separate lines - Elaborate more on what is tested and what is the expected result in the bug record. The current content isn't very clear. - Can u have more unique names for these tests? Currently, they are too similarly named and it's somewhat confusing. The directory already contains RSA, I don't feel that u need to have RSA again in the names of the test especially when SunRsaSign provider doesn't support non-RSA algorithms. For KeyTest.java 1) typo on line 69, rsaPrivateKey2 should be rsaPrivateKey 2) This test is based on the provider specific behavior that CRT key is generated by default for RSA. It'd be much clearer if you can add an instanceof check on the generated RSA private key objects before the KeyFactory + RSAPrivateKeySpec code. In addition, add additional code to check for equality with the matching KeySpec (e.g. RSAPrivateCrtKeySpec for RSAPrivateCrtKey) is used. 3) line 58, add a space between '//" and text. For RSAKeySizeTest.java 1) specify provider "SunRSASign" for all getInstance() calls. 2) line 55 can be moved up to before the for-loop. 3) instead of using toString(int), probably bitLength() would be a better choice. 4) sizeTest() doesn't really check size but rather it compares the modulus values being equal. This check can be moved to RSAKeySizeTest.java. For RSATest.java 1) specify provider "SunRSASign" for all getInstance() calls. Thanks, Valerie On 8/3/2015 10:27 AM, Tristan Yan wrote: > Hi > > Please review new tests for RSA keys and key specifications > > Bug:https://bugs.openjdk.java.net/browse/JDK-8044199 > Webrev:http://cr.openjdk.java.net/~tyan/8044199/webrev.01/ > > > Thanks > Tristan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Aug 10 23:27:13 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 10 Aug 2015 16:27:13 -0700 Subject: 7u Code review request for 7033170, 7092821, 7092825 In-Reply-To: <55C4AFA4.6000300@oracle.com> References: <4EF1157C.7030506@oracle.com> <4EF23034.8030208@oracle.com> <4EF248F6.3080000@oracle.com> <4F0E31B9.8040609@oracle.com> <4F0F677B.4090406@oracle.com> <55C4AFA4.6000300@oracle.com> Message-ID: <55C93351.1040307@oracle.com> Well, I used to have a workspace containing a prototype fix, but I didn't get to run the benchmark against the prototype. Then, I went to work on other bug fixes and enhancement and this has been put on the back burners. Valerie On 8/7/2015 6:16 AM, Sean Mullan wrote: > Hi David, > > On 08/07/2015 08:44 AM, David Schlosnagle wrote: >> I forgot to mention one other workaround for this bug, as used in Guava >> is cloning the instance if clone() is supported, see >> https://github.com/google/guava/issues/1197 >> >> On Friday, August 7, 2015, David Schlosnagle > > wrote: >> >> // reviving this ghost >> >> Hi Valerie, Sean, and sec-dev, >> >> I am curious if there has been any movement on incorporating a fix >> for https://bugs.openjdk.java.net/browse/JDK-7092821? I have >> encountered several systems where this is a significant contention >> and scale bottleneck. While there are some workarounds such as >> pooling and reusing Provider instances, that seems like a band-aid, >> and fixing the JDK is a better path. > > I don't know if Valerie has made any progress on this issue, so I'll > let her add any details. > >> >> If I were to put a webrev together, would someone be kind enough >> to sponsor it for me? > > Yes, I think we could do that and I see you have already signed the OCA. > >> Are there any existing open source load tests >> to verify these changes? > > Not that I know of. It would be great if you could implement a JMH > microbenchmark as part of your fix. > >> Is there a good mechanism in OpenJDK now to >> run JMH across all of the supported platforms (I only have access to >> a small subset of the permutation of platforms). > > That's being worked on for JDK 9 but AFAIK it isn't ready yet. See > http://openjdk.java.net/jeps/230 > > Thanks for your help! > > --Sean > >> >> Thanks! >> >> - Dave >> >> On Thursday, January 12, 2012, Valerie (Yu-Ching) Peng >> > > wrote: >> >> Dave, >> Thanks for the comments. >> Let me think about it some more and see how to better address >> this kind of racing issue. >> >> If you have concerns on fixes for 7033170 and 7092825, please >> let me know. >> >> Sean, >> Can you please ignore the review request for 7092821 for now. >> I'll send out an updated version later. >> If you can still review the remaining two, that'd be great. >> >> Thanks, >> Valerie >> >> On 01/11/12 21:48, David Schlosnagle wrote: >> >> On Wed, Jan 11, 2012 at 8:04 PM, Valerie (Yu-Ching) Peng >> wrote: >> >> 7092821: java.security.Provider.getService() is >> synchronized and became scalability bottleneck. >> jdk7u Webrev: >> http://cr.openjdk.java.net/~valeriep/7092821_7u/ >> jdk8 Webrev: >> http://cr.openjdk.java.net/~valeriep/7092821/ >> >> Valerie, >> >> You might already be aware of this, but there is a data race >> on lines >> 685 - 686 of the Provider's getService(String, String) >> method. If >> there are concurrent callers to getService while lookupCache >> == null, >> the lookupCache may be overwritten by a new >> ConcurrentHashMap after >> another thread has just instantiated and populated an entry >> in the >> cache leading to thrashing on lookupCache. It might be >> worthwhile to >> either use a double checked lock to avoid the race at the >> expense of >> an additional lock and volatile read in the case lookupCache >> == null >> or add a comment indicating that this is an accepted data >> race. >> >> There is also now the possibility that if one thread is >> executing >> getService while another thread invokes one of the methods >> that sets >> lookupCache = null, there could then be a >> NullPointerException on line >> 703 as the volatile read would now see a null and fail. You >> could >> prevent that by either moving the putIfAbsent under the lock >> (not >> ideal for performance if you're already seeing contention), >> or just >> maintain a local reference to the cache map and use it >> throughout the >> getService method. This would mean that if the lookupCache >> reference >> was concurrently mutated, the putIfAbsent would basically be >> a write >> to the local map reference which is now garbage, but >> shouldn't really >> hurt anything. >> >> I'd propose something along the lines of the following to >> address this: >> >> public Service getService(String type, String >> algorithm) { >> ServiceKey key = new ServiceKey(type, algorithm); >> ConcurrentMap >> localLookupCache = getLookupCache(); >> Service result = localLookupCache.get(key); >> if (result != null) { >> return (result == NULL_MARK? null : result); >> } >> synchronized (this) { >> checkInitialized(); >> if (serviceMap != null) { >> result = serviceMap.get(key); >> } >> if (result == null) { >> ensureLegacyParsed(); >> result = (legacyMap != null) ? >> legacyMap.get(key) : null; >> } >> } >> // under concurrent mutation of lookupCache, this >> will write >> to map that is no >> // longer the active cache >> localLookupCache.putIfAbsent(key, (result == null? >> NULL_MARK : result)); >> return result; >> } >> >> private ConcurrentMap >> getLookupCache() { >> if (lookupCache == null) { >> synchronized (this) { >> // must fall back on double checked lock >> if (lookupCache == null) { >> lookupCache = new >> ConcurrentHashMap<>(); >> } >> } >> } >> return lookupCache; >> } >> >> >> - Dave >> >> >> For reference, here were the original changes: >> 429 // Cache for service lookups. Discard whenever >> services are changed. >> 430 private transient volatile >> ConcurrentMap >> lookupCache; >> ...snip... >> 682 public Service getService(String type, String >> algorithm) { >> 683 ServiceKey key = new ServiceKey(type, >> algorithm); >> 684 Service result = null; >> 685 if (lookupCache == null) { >> 686 lookupCache = new ConcurrentHashMap<>(); >> 687 } else { >> 688 result = lookupCache.get(key); >> 689 if (result != null) { >> 690 return (result == NULL_MARK? null : >> result); >> 691 } >> 692 } >> 693 synchronized (this) { >> 694 checkInitialized(); >> 695 if (serviceMap != null) { >> 696 result = serviceMap.get(key); >> 697 } >> 698 if (result == null) { >> 699 ensureLegacyParsed(); >> 700 result = (legacyMap != null) ? >> legacyMap.get(key) : null; >> 701 } >> 702 } >> 703 lookupCache.putIfAbsent(key, (result == null? >> NULL_MARK : result)); >> 704 return result; >> 705 } >> >> From weijun.wang at oracle.com Tue Aug 11 02:47:14 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Aug 2015 10:47:14 +0800 Subject: RFR: JDK-8077055 : Allow other named SecurityPermissions, RuntimePermissions, and AuthPermissions to be used In-Reply-To: <55C3BE3C.6060103@oracle.com> References: <55C3BE3C.6060103@oracle.com> Message-ID: <55C96232.2030306@oracle.com> Everything is fine. One thing in AuthPermission.java: + * {@link javax.security.auth.login.LoginContext}, and + * {@link javax.security.auth.login.Configuration} objects. I remember you can add an additional label in {@link}, otherwise, the text is too long. Thanks Max On 08/07/2015 04:06 AM, Sean Mullan wrote: > Please review this small specification change to allow implementations > to define additional implementation-specific target names for > SecurityPermission, RuntimePermission, and AuthPermission: > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8077055/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8077055 > > Thanks, > Sean From vincent.x.ryan at oracle.com Tue Aug 11 11:34:13 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 11 Aug 2015 12:34:13 +0100 Subject: [9] review request for 8133318: Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and earlier Message-ID: Please review this change to omit several PKCS11 tests from test runs on Solaris SPARC 11.1 and earlier. The tests had been failing intermittently. Webrev: http://cr.openjdk.java.net/~vinnie/8133318/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8133318 Thanks. From sean.mullan at oracle.com Tue Aug 11 11:47:06 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Aug 2015 07:47:06 -0400 Subject: RFR: JDK-8077055 : Allow other named SecurityPermissions, RuntimePermissions, and AuthPermissions to be used In-Reply-To: <55C96232.2030306@oracle.com> References: <55C3BE3C.6060103@oracle.com> <55C96232.2030306@oracle.com> Message-ID: <55C9E0BA.9090605@oracle.com> On 08/10/2015 10:47 PM, Weijun Wang wrote: > Everything is fine. > > One thing in AuthPermission.java: > + * {@link javax.security.auth.login.LoginContext}, and > + * {@link javax.security.auth.login.Configuration} objects. > > I remember you can add an additional label in {@link}, otherwise, the > text is too long. It's not a problem in this case. By default, the link uses the name of the class for the link so it appears as "LoginContext and Configuration objects.". --Sean > > Thanks > Max > > On 08/07/2015 04:06 AM, Sean Mullan wrote: >> Please review this small specification change to allow implementations >> to define additional implementation-specific target names for >> SecurityPermission, RuntimePermission, and AuthPermission: >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8077055/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8077055 >> >> Thanks, >> Sean From sean.mullan at oracle.com Tue Aug 11 12:28:46 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Aug 2015 08:28:46 -0400 Subject: [9] review request for 8133318: Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and earlier In-Reply-To: References: Message-ID: <55C9EA7E.2030003@oracle.com> There are bunch of methods for determining os.version, etc in jdk/testlibrary/Platform that might be better to reuse. Did you consider caching the value of "uname -v" so it can be reused by other tests? It seems expensive to exec a process just to get that value every time one of these tests is run. --Sean On 08/11/2015 07:34 AM, Vincent Ryan wrote: > Please review this change to omit several PKCS11 tests from test runs on Solaris SPARC 11.1 and earlier. > The tests had been failing intermittently. > > Webrev: http://cr.openjdk.java.net/~vinnie/8133318/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8133318 > > Thanks. > From weijun.wang at oracle.com Tue Aug 11 12:44:22 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Aug 2015 20:44:22 +0800 Subject: RFR: JDK-8077055 : Allow other named SecurityPermissions, RuntimePermissions, and AuthPermissions to be used In-Reply-To: <55C9E0BA.9090605@oracle.com> References: <55C3BE3C.6060103@oracle.com> <55C96232.2030306@oracle.com> <55C9E0BA.9090605@oracle.com> Message-ID: <55C9EE26.2090904@oracle.com> On 08/11/2015 07:47 PM, Sean Mullan wrote: > On 08/10/2015 10:47 PM, Weijun Wang wrote: >> Everything is fine. >> >> One thing in AuthPermission.java: >> + * {@link javax.security.auth.login.LoginContext}, and >> + * {@link javax.security.auth.login.Configuration} objects. >> >> I remember you can add an additional label in {@link}, otherwise, the >> text is too long. > > It's not a problem in this case. By default, the link uses the name of > the class for the link so it appears as "LoginContext and Configuration > objects.". That would be good. I am looking at IntelliJ IDEA's Quick Documentation and it shows the full name. --Max From vincent.x.ryan at oracle.com Tue Aug 11 13:14:40 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 11 Aug 2015 14:14:40 +0100 Subject: [9] review request for 8133318: Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and earlier In-Reply-To: <55C9EA7E.2030003@oracle.com> References: <55C9EA7E.2030003@oracle.com> Message-ID: <98F433B0-FCB1-403E-B543-52AC20C52F73@oracle.com> The process exec for uname is only made when the test is run on Solaris SPARC earlier than 11.2 but I take your point. I?ll look at caching its value and re-using the util methods. > On 11 Aug 2015, at 13:28, Sean Mullan wrote: > > There are bunch of methods for determining os.version, etc in jdk/testlibrary/Platform that might be better to reuse. > > Did you consider caching the value of "uname -v" so it can be reused by other tests? It seems expensive to exec a process just to get that value every time one of these tests is run. > > --Sean > > On 08/11/2015 07:34 AM, Vincent Ryan wrote: >> Please review this change to omit several PKCS11 tests from test runs on Solaris SPARC 11.1 and earlier. >> The tests had been failing intermittently. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8133318/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8133318 >> >> Thanks. >> From sean.mullan at oracle.com Tue Aug 11 16:01:16 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 11 Aug 2015 12:01:16 -0400 Subject: [9] review request for 8133318: Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and earlier In-Reply-To: <98F433B0-FCB1-403E-B543-52AC20C52F73@oracle.com> References: <55C9EA7E.2030003@oracle.com> <98F433B0-FCB1-403E-B543-52AC20C52F73@oracle.com> Message-ID: <55CA1C4C.7030205@oracle.com> On 08/11/2015 09:14 AM, Vincent Ryan wrote: > The process exec for uname is only made when the test is run on Solaris SPARC earlier than 11.2 but I take your point. > I?ll look at caching its value and re-using the util methods. Actually thinking more about this, and I don't know for sure, but agentvm mode may reuse VMs for different update versions of Solaris, so a cached value could return the wrong value and cause unexpected results. So this is probably not feasible. --Sean > > > >> On 11 Aug 2015, at 13:28, Sean Mullan wrote: >> >> There are bunch of methods for determining os.version, etc in jdk/testlibrary/Platform that might be better to reuse. >> >> Did you consider caching the value of "uname -v" so it can be reused by other tests? It seems expensive to exec a process just to get that value every time one of these tests is run. >> >> --Sean >> >> On 08/11/2015 07:34 AM, Vincent Ryan wrote: >>> Please review this change to omit several PKCS11 tests from test runs on Solaris SPARC 11.1 and earlier. >>> The tests had been failing intermittently. >>> >>> Webrev: http://cr.openjdk.java.net/~vinnie/8133318/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133318 >>> >>> Thanks. >>> > From weijun.wang at oracle.com Wed Aug 12 00:38:31 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 12 Aug 2015 08:38:31 +0800 Subject: RFR: 8132330: Ineffective SecureRandom usage in RSA encoding with PKCS1Padding In-Reply-To: <55C1FCEB.2000100@oracle.com> References: <55C1FCEB.2000100@oracle.com> Message-ID: <55CA9587.1020205@oracle.com> Hi Sergey Sorry for the late reply. The change looks fine. If you want me to push it, please show me the changeset block you like, including contributed-by or your openjdk id if you already had an author role. Thanks Max On 08/05/2015 08:09 PM, Sergey Kuksenko wrote: > Hi All, > > Please review changes to the following performance improvement: > > https://bugs.openjdk.java.net/browse/JDK-8132330 > > Webrev: http://cr.openjdk.java.net/~skuksenko/crypto/8132330/webrev.02/ > > Sponsorship is required. > > ------ > Currently sun.security.rsa.RSAPadding::padV15 uses fixed size (64 bytes) > buffer for obtaining random bytes from SecureRandom. > Here we got two sources of inefficiency: > - when length of required padding is greater than 64 -> several calls of > SecureRandom.nextBytes are required that increases contention blocking > on SecureRandom > - when length of required padding is less than 64 it causes unnecessary > overhead (e.g. nextBytes for 16 bytes is 4x times faster than for 64 bytes) > > Suggested performance improvement shows RSA encoding (public key) speedup: > - 10%-18% when NativePRNG SecureRandom is used, > - 5%-7% when SHA1PRNG is used. > > From vincent.x.ryan at oracle.com Wed Aug 12 09:45:14 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 12 Aug 2015 10:45:14 +0100 Subject: [9] review request for 8133318: Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and earlier In-Reply-To: <55CA1C4C.7030205@oracle.com> References: <55C9EA7E.2030003@oracle.com> <98F433B0-FCB1-403E-B543-52AC20C52F73@oracle.com> <55CA1C4C.7030205@oracle.com> Message-ID: <7588C116-7E66-481A-B424-4552782CFD32@oracle.com> > On 11 Aug 2015, at 17:01, Sean Mullan wrote: > > On 08/11/2015 09:14 AM, Vincent Ryan wrote: >> The process exec for uname is only made when the test is run on Solaris SPARC earlier than 11.2 but I take your point. >> I?ll look at caching its value and re-using the util methods. > > Actually thinking more about this, and I don't know for sure, but agentvm mode may reuse VMs for different update versions of Solaris, so a cached value could return the wrong value and cause unexpected results. So this is probably not feasible. OK I?ll leave the current code unchanged as there?s no significant benefit to using the utility methods in jdk.testlibrary.Platform class either since System.getProperty effectively caches the property values it reads. > > --Sean > >> >> >> >>> On 11 Aug 2015, at 13:28, Sean Mullan wrote: >>> >>> There are bunch of methods for determining os.version, etc in jdk/testlibrary/Platform that might be better to reuse. >>> >>> Did you consider caching the value of "uname -v" so it can be reused by other tests? It seems expensive to exec a process just to get that value every time one of these tests is run. >>> >>> --Sean >>> >>> On 08/11/2015 07:34 AM, Vincent Ryan wrote: >>>> Please review this change to omit several PKCS11 tests from test runs on Solaris SPARC 11.1 and earlier. >>>> The tests had been failing intermittently. >>>> >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8133318/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133318 >>>> >>>> Thanks. >>>> >> From sean.mullan at oracle.com Wed Aug 12 13:26:56 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 12 Aug 2015 09:26:56 -0400 Subject: [9] review request for 8133318: Exclude intermittent failing PKCS11 tests on Solaris SPARC 11.1 and earlier In-Reply-To: <7588C116-7E66-481A-B424-4552782CFD32@oracle.com> References: <55C9EA7E.2030003@oracle.com> <98F433B0-FCB1-403E-B543-52AC20C52F73@oracle.com> <55CA1C4C.7030205@oracle.com> <7588C116-7E66-481A-B424-4552782CFD32@oracle.com> Message-ID: <55CB49A0.3070104@oracle.com> On 08/12/2015 05:45 AM, Vincent Ryan wrote: > >> On 11 Aug 2015, at 17:01, Sean Mullan wrote: >> >> On 08/11/2015 09:14 AM, Vincent Ryan wrote: >>> The process exec for uname is only made when the test is run on Solaris SPARC earlier than 11.2 but I take your point. >>> I?ll look at caching its value and re-using the util methods. >> >> Actually thinking more about this, and I don't know for sure, but agentvm mode may reuse VMs for different update versions of Solaris, so a cached value could return the wrong value and cause unexpected results. So this is probably not feasible. > > OK I?ll leave the current code unchanged as there?s no significant benefit to using the utility methods in jdk.testlibrary.Platform class either > since System.getProperty effectively caches the property values it reads. Ok. --Sean > > >> >> --Sean >> >>> >>> >>> >>>> On 11 Aug 2015, at 13:28, Sean Mullan wrote: >>>> >>>> There are bunch of methods for determining os.version, etc in jdk/testlibrary/Platform that might be better to reuse. >>>> >>>> Did you consider caching the value of "uname -v" so it can be reused by other tests? It seems expensive to exec a process just to get that value every time one of these tests is run. >>>> >>>> --Sean >>>> >>>> On 08/11/2015 07:34 AM, Vincent Ryan wrote: >>>>> Please review this change to omit several PKCS11 tests from test runs on Solaris SPARC 11.1 and earlier. >>>>> The tests had been failing intermittently. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8133318/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133318 >>>>> >>>>> Thanks. >>>>> >>> > From tristan.yan at oracle.com Wed Aug 12 23:06:59 2015 From: tristan.yan at oracle.com (Tristan Yan) Date: Wed, 12 Aug 2015 16:06:59 -0700 Subject: RFR for JDK-8048604 : Tests for strong crypto ciphers Message-ID: <55CBD193.5020504@oracle.com> Please be free review these new tests for strong crypto ciphers. webrev : http://cr.openjdk.java.net/~tyan/8048604/webrev.01/ bug : https://bugs.openjdk.java.net/browse/JDK-8048604 Thank you very much Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.brunet at oracle.com Thu Aug 13 17:29:31 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 13 Aug 2015 12:29:31 -0500 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55A85EE6.5010705@oracle.com> References: <55A43D08.7030106@oracle.com> <55A4DDC9.7070704@oracle.com> <55A6D3C1.4080601@oracle.com> <55A85EE6.5010705@oracle.com> Message-ID: <55CCD3FB.9060502@oracle.com> One final update from Mandy: - change test path to remove jdk.accessibility; only use package name for path - add @modules java.desktop jdk.accessibility http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.03/ Pete On 7/16/15 8:48 PM, Pete Brunet wrote: > From Mandy: > - remove unused imports > - add @run main/othervm > > http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.02/ > > On 7/15/15 4:42 PM, Pete Brunet wrote: >> An update is available and mostly changes only the test case, >> Bug8151626.java. The other change is to remove jtreg.security.policy. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.01/ >> >> Changes: >> >> From Sean >> - The jtreg @run statement was removed; don't specify security manager >> or security policy. >> - Remove jtreg.security.policy >> - Add System.setSecurityManager(new SecurityManager()); to the beginning >> of the code. >> >> From Sergey >> - Wrap test in invokeAndWait >> - Add frame.dispose in finally >> - Remove System.exit >> >> I also removed the Thread.sleep. It doesn't appear to be needed. >> >> Pete >> >> On 7/14/15 5:00 AM, Sergey Bylokhov wrote: >>> Hi, Pete. >>> The fix looks fine, but you should tweak the test a little bit. >>> - You access the swing components on non-EDT thread. >>> - You should not use System.exit in the test. >>> - The JFrame should be disposed before the end of the test. >>> >>> On 14.07.15 1:34, Pete Brunet wrote: >>>> Please review the webrev for >>>> https://bugs.openjdk.java.net/browse/JDK-8051626 >>>> >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >>>> >>>> This is so the the Java Accessibility Utilities package, >>>> com.sun.java.accessibility.util, can be run with the security manager >>>> active but the non-public accessibility packages won't, i.e. >>>> com.sun.java.accessibility.internal and >>>> com.sun.java.accessibility.util.internal. >>>> >>>> Running the regression test proves that there will be a security >>>> exception when using a method of com.sun.java.accessibility.util before >>>> the fix but not after. >>>> >>>> Pete From mandy.chung at oracle.com Thu Aug 13 18:16:17 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 13 Aug 2015 11:16:17 -0700 Subject: RfR JDK-8051626 Rework security restrictions of Java Access Bridge and related Utilities In-Reply-To: <55CCD3FB.9060502@oracle.com> References: <55A43D08.7030106@oracle.com> <55A4DDC9.7070704@oracle.com> <55A6D3C1.4080601@oracle.com> <55A85EE6.5010705@oracle.com> <55CCD3FB.9060502@oracle.com> Message-ID: <55CCDEF1.5000903@oracle.com> Looks fine. Mandy On 08/13/2015 10:29 AM, Pete Brunet wrote: > One final update from Mandy: > - change test path to remove jdk.accessibility; only use package name > for path > - add @modules java.desktop jdk.accessibility > > http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.03/ > > Pete > > On 7/16/15 8:48 PM, Pete Brunet wrote: >> From Mandy: >> - remove unused imports >> - add @run main/othervm >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.02/ >> >> On 7/15/15 4:42 PM, Pete Brunet wrote: >>> An update is available and mostly changes only the test case, >>> Bug8151626.java. The other change is to remove jtreg.security.policy. >>> >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.01/ >>> >>> Changes: >>> >>> From Sean >>> - The jtreg @run statement was removed; don't specify security manager >>> or security policy. >>> - Remove jtreg.security.policy >>> - Add System.setSecurityManager(new SecurityManager()); to the beginning >>> of the code. >>> >>> From Sergey >>> - Wrap test in invokeAndWait >>> - Add frame.dispose in finally >>> - Remove System.exit >>> >>> I also removed the Thread.sleep. It doesn't appear to be needed. >>> >>> Pete >>> >>> On 7/14/15 5:00 AM, Sergey Bylokhov wrote: >>>> Hi, Pete. >>>> The fix looks fine, but you should tweak the test a little bit. >>>> - You access the swing components on non-EDT thread. >>>> - You should not use System.exit in the test. >>>> - The JFrame should be disposed before the end of the test. >>>> >>>> On 14.07.15 1:34, Pete Brunet wrote: >>>>> Please review the webrev for >>>>> https://bugs.openjdk.java.net/browse/JDK-8051626 >>>>> >>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8051626/webrev.00/ >>>>> >>>>> This is so the the Java Accessibility Utilities package, >>>>> com.sun.java.accessibility.util, can be run with the security manager >>>>> active but the non-public accessibility packages won't, i.e. >>>>> com.sun.java.accessibility.internal and >>>>> com.sun.java.accessibility.util.internal. >>>>> >>>>> Running the regression test proves that there will be a security >>>>> exception when using a method of com.sun.java.accessibility.util before >>>>> the fix but not after. >>>>> >>>>> Pete From valerie.peng at oracle.com Fri Aug 14 02:31:12 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 13 Aug 2015 19:31:12 -0700 Subject: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module Message-ID: <55CD52F0.2000205@oracle.com> Can someone please help reviewing this change? This is to move Apple provider from jdk.deploy.osx module to java.base module. The native library for Apple provider is separated out from the "osx" one generated in jdk.deploy.osx module and named "osxapple" (sort of following the convention of SunMSCAPI provider whose native library is named "sunmscapi"). webrev: http://cr.openjdk.java.net/~valeriep/8086002/webrev.00/ Thanks, Valerie From erik.joelsson at oracle.com Fri Aug 14 07:01:27 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Aug 2015 09:01:27 +0200 Subject: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module In-Reply-To: <55CD52F0.2000205@oracle.com> References: <55CD52F0.2000205@oracle.com> Message-ID: <55CD9247.2090602@oracle.com> Build changes look good. /Erik On 2015-08-14 04:31, Valerie Peng wrote: > > Can someone please help reviewing this change? > This is to move Apple provider from jdk.deploy.osx module to java.base > module. > The native library for Apple provider is separated out from the "osx" > one generated in jdk.deploy.osx module and named "osxapple" (sort of > following the convention of SunMSCAPI provider whose native library is > named "sunmscapi"). > > webrev: http://cr.openjdk.java.net/~valeriep/8086002/webrev.00/ > > Thanks, > Valerie From sean.mullan at oracle.com Fri Aug 14 13:30:24 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Aug 2015 09:30:24 -0400 Subject: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module In-Reply-To: <55CD52F0.2000205@oracle.com> References: <55CD52F0.2000205@oracle.com> Message-ID: <55CDED70.4080701@oracle.com> Couple of minor comments on ProviderConfig.java 183: you can use the diamond operator for anonymous classes now (PrivilegedAction<>). You could also use a lambda expression here but I'll leave that up to you. 193: the braces around "if (debug != null)" are not indented properly Looks fine otherwise. --Sean On 08/13/2015 10:31 PM, Valerie Peng wrote: > > Can someone please help reviewing this change? > This is to move Apple provider from jdk.deploy.osx module to java.base > module. > The native library for Apple provider is separated out from the "osx" > one generated in jdk.deploy.osx module and named "osxapple" (sort of > following the convention of SunMSCAPI provider whose native library is > named "sunmscapi"). > > webrev: http://cr.openjdk.java.net/~valeriep/8086002/webrev.00/ > > Thanks, > Valerie From mandy.chung at oracle.com Fri Aug 14 17:17:49 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 14 Aug 2015 10:17:49 -0700 Subject: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module In-Reply-To: <55CD52F0.2000205@oracle.com> References: <55CD52F0.2000205@oracle.com> Message-ID: > On Aug 13, 2015, at 7:31 PM, Valerie Peng wrote: > > > Can someone please help reviewing this change? > This is to move Apple provider from jdk.deploy.osx module to java.base module. > The native library for Apple provider is separated out from the "osx" one generated in jdk.deploy.osx module and named "osxapple" (sort of following the convention of SunMSCAPI provider whose native library is named "sunmscapi"). > > webrev: http://cr.openjdk.java.net/~valeriep/8086002/webrev.00/ Thanks for doing this. jdk.deploy.osx is temporary home for Apple security provider and a couple of MacOSX specific stuff. The change looks good in general. Identation in line 193-200 in ProviderConfig.java needs fixing, as Sean pointed out. As we discussed offline, we should rename the library name to reflect what it?s. A couple of suggestions: libosxkeychain, libosxcrypto, or libosxsec etc. We could go with libosxkeychain for now and rename it in the future for new feature, if any. Mandy From sean.mullan at oracle.com Fri Aug 14 20:06:39 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 14 Aug 2015 16:06:39 -0400 Subject: RFC: OpenJDK JarSigner API In-Reply-To: <55C60AA9.4020709@oracle.com> References: <55C60AA9.4020709@oracle.com> Message-ID: <55CE4A4F.5090602@oracle.com> This looks good to me. --Sean On 08/08/2015 09:56 AM, Weijun Wang wrote: > Hi All > > JDK 9 is more restricted on calling sun.* public methods but we know > there are users calling sun.security.tools.jarsigner.Main to sign jar > files. A new API is proposed for this very purpose in OpenJDK. Please > note it is defined in a jdk.* package therefore not a Java SE API. We > are also thinking of an API to cover keytool functions. Stay tuned. > > The new API does not cover every option of the existing jarsigner tool, > for example, -altsign, -tsapolicyid, -tsadigestalg, -internalsf, > -sectionsonly, etc, but we hope it is enough in most use cases. > > All suggestions are welcome. > > Thanks > Max > > package jdk.security.jarsigner; > > /** > * An immutable utility class to sign a jar file. > *

> * A caller creates a {@code JarSigner.Builder} object, (optionally) > sets some > * parameters, and then calls the {@link JarSigner.Builder#build build} > method > * to create a {@code JarSigner} object. This {@code JarSigner} object > can then > * be used to sign a jar file. > *

> * Unless otherwise stated, calling a method of {@code JarSigner} or > * {@code JarSigner.Builder} with a null argument will throw > * a {@link NullPointerException}. > *

> * Example: > * 

>   * JarSigner signer = new JarSigner.Builder(key, certPath)
>   *         .digestAlg("SHA-1")
>   *         .sigAlg("SHA1withDSA")
>   *         .build();
>   * try (ZipFile in = new ZipFile(inputFile);
>   *         FileOutputStream out = new FileOutputStream(outFile)) {
>   *     signer.sign(in, out);
>   * }
>   *
> * > * @since 1.9 > */ > @jdk.Exported > public final class JarSigner { > > /** > * A mutable builder class that can create an immutable {@code > JarSigner} > * from various signing-related parameters. > * > * @since 1.9 > */ > @jdk.Exported > public static class Builder { > > /** > * Creates a {@code JarSigner.Builder} object with > * a {@link KeyStore.PrivateKeyEntry} object. > * > * @param entry the {@link KeyStore.PrivateKeyEntry} of the > signer. > */ > public Builder(KeyStore.PrivateKeyEntry entry); > > /** > * Creates a {@code JarSigner.Builder} object with a private > key and > * a certification path. > * > * @param privateKey the private key of the signer. > * @param certPath the certification path of the signer. > * @throws IllegalArgumentException if {@code certPath} is > empty, or > * the {@code privateKey} algorithm does not match the > algorithm > * of the {@code PublicKey} in the end entity certificate > * (the first certificate in {@code certPath}). > */ > public Builder(PrivateKey privateKey, CertPath certPath); > > /** > * Sets the digest algorithm. If no digest algorithm is specified, > * the default algorithm returned by {@link #getDefaultDigestAlg} > * will be used. > * > * @param algorithm the standard name of the algorithm. See > * the MessageDigest section in the * > "{@docRoot}/../technotes/guides/security/StandardNames.html#MessageDigest"> > * Java Cryptography Architecture Standard Algorithm Name > * Documentation for information about standard > algorithm names. > * @return the {@code JarSigner.Builder} itself. > * @throws NoSuchAlgorithmException if {@code algorithm} is not > available. > */ > public Builder digestAlg(String algorithm) throws > NoSuchAlgorithmException; > > /** > * Sets the digest algorithm from the specified provider. > * If no digest algorithm is specified, the default algorithm > * returned by {@link #getDefaultDigestAlg} will be used. > * > * @param algorithm the standard name of the algorithm. See > * the MessageDigest section in the * > "{@docRoot}/../technotes/guides/security/StandardNames.html#MessageDigest"> > * Java Cryptography Architecture Standard Algorithm Name > * Documentation for information about standard > algorithm names. > * @param provider the provider. > * @return the {@code JarSigner.Builder} itself. > * @throws NoSuchAlgorithmException if {@code algorithm} is not > available > * in the specified provider. > */ > public Builder digestAlg(String algorithm, Provider provider) > throws NoSuchAlgorithmException; > > /** > * Sets the signature algorithm. If no signature algorithm > * is specified, the default signature algorithm returned by > * {@link #getDefaultSigAlg} for the private key algorithm will > be used. > * > * @param algorithm the standard name of the algorithm. See > * the Signature section in the * > "{@docRoot}/../technotes/guides/security/StandardNames.html#Signature"> > * Java Cryptography Architecture Standard Algorithm Name > * Documentation for information about standard > algorithm names. > * @return the {@code JarSigner.Builder} itself. > * @throws NoSuchAlgorithmException if {@code algorithm} is not > available. > * @throws IllegalArgumentException if {@code algorithm} is not > compatible > * with the algorithm of the signer's private key. > */ > public Builder sigAlg(String algorithm) throws > NoSuchAlgorithmException; > > /** > * Sets the signature algorithm from the specified provider. > * If no signature algorithm is specified, the default > signature algorithm > * returned by {@link #getDefaultSigAlg} for the private key > algorithm > * will be used. > * > * @param algorithm the standard name of the algorithm. See > * the Signature section in the * > "{@docRoot}/../technotes/guides/security/StandardNames.html#Signature"> > * Java Cryptography Architecture Standard Algorithm Name > * Documentation for information about standard > algorithm names. > * @param provider the provider. > * @return the {@code JarSigner.Builder} itself. > * @throws NoSuchAlgorithmException if {@code algorithm} is not > available > * in the specified provider. > * @throws IllegalArgumentException if {@code algorithm} is not > compatible > * with the algorithm of the signer's private key. > */ > public Builder sigAlg(String algorithm, Provider provider) > throws NoSuchAlgorithmException; > > /** > * Sets the URI of the Time Stamping Authority (TSA). > * > * @param uri the URI. > * @return the {@code JarSigner.Builder} itself. > */ > public Builder tsa(URI uri); > > /** > * Sets the signer name. The name will be used as the base name > for > * the signature files. All lowercase characters will be > converted to > * uppercase for signature file names. If a signer name is not > * specified, the string "SIGNER" will be used. > * > * @param name the signer name. > * @return the {@code JarSigner.Builder} itself. > * @throws IllegalArgumentException if {@code name} is empty or > has a size > * bigger than 8, or it contains characters not from the set > * "a-zA-Z0-9_-". > */ > public Builder signerName(String name); > > /** > * Gets the default digest algorithm. > * > * @implNote This implementation returns "SHA-256". The value may > * change in the future. > * > * @return the default digest algorithm. > */ > public static String getDefaultDigestAlg(); > > /** > * Gets the default signature algorithm for a private key > algorithm. > * For example, SHA256withRSA for RSA, and SHA256withDSA for DSA. > * > * @implNote This implementation returns "SHA256withDSA" for > the "DSA" > * key algorithm, "SHA256withRSA" for "RSA", "SHA256withECDSA" > for "EC", > * and {@code null} otherwise. The value(s) may change in the > future. > * > * @param keyAlg the key algorithm. > * @return the default signature algorithm. Returns null if a > default > * signature algorithm cannot be found. In this case, {@link > #sigAlg} > * must be called to specify a signature algorithm. Otherwise, > * the {@link #build} method will throw an {@link > IllegalArgumentException}. > * @throws IllegalArgumentException if {@code keyAlg} is empty. > */ > public static String getDefaultSigAlg(String keyAlg); > > /** > * Builds a {@code JarSigner} object from the parameters set by > the > * setter methods. > *

> * This method does not modify internal state of this {@code > Builder} > * object and can be called multiple times to generate multiple > * {@code JarSigner} objects. After a {@code JarSigner} object is > * built, calling any setter method on this {@code Builder} > will have > * no effect on it. > * > * @return the {@code JarSigner} object. > * @throws IllegalArgumentException if a signature algorithm is > not > * set and cannot be derived from the private key using the > * {@link #getDefaultSigAlg} method. > */ > public JarSigner build(); > } > > /** > * Signs a file into an {@link OutputStream}. This method will not > close > * {@code file} or {@code os}. > * > * @param file the file to sign. > * @param os the output stream. > * @throws JarSignerException if the signing fails. > */ > public void sign(ZipFile file, OutputStream os); > > /** > * Returns the digest algorithm for this {@code JarSigner}. > * @return the digest algorithm. The return value is never null. > */ > public String getDigestAlg(); > > /** > * Returns the signature algorithm for this {@code JarSigner}. > * @return the signature algorithm. The return value is never null. > */ > public String getSigAlg(); > > /** > * Returns the URI of the Time Stamping Authority (TSA). > * @return the URI of the TSA. > */ > public URI getTsa(); > > /** > * Returns the signer name of this {@code JarSigner}. > * @return the signer name. The return value is never null. > */ > public String getSignerName(); > } > > /** > * This exception is thrown when {@link JarSigner#sign} fails. > * > * @since 1.9 > */ > @jdk.Exported > public class JarSignerException extends RuntimeException { > > private static final long serialVersionUID = -4732217075689309530L; > > /** > * Constructs a new {@code JarSignerException} with the specified > detail > * message and cause.

Note that the detail message associated with > * {@code cause} is not automatically incorporated in > * this {@code JarSignerException}'s detail message. > * > * @param message the detail message (which is saved for later > retrieval > * by the {@link #getMessage()} method). > * @param cause the cause (which is saved for later retrieval by the > * {@link #getCause()} method). (A null value is > * permitted, and indicates that the cause is nonexistent or > * unknown.) > */ > public JarSignerException(String message, Throwable cause); > } From mandy.chung at oracle.com Fri Aug 14 21:37:16 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 14 Aug 2015 14:37:16 -0700 Subject: RFC: OpenJDK JarSigner API In-Reply-To: <55C60AA9.4020709@oracle.com> References: <55C60AA9.4020709@oracle.com> Message-ID: Looks good in general. Have you considered using ?Algorithm? instead of ?Alg? the abbreviation in the method names digesting, sigAlg etc The Builder::build method: After a {@code JarSigner} object is built, calling any setter method on this {@code Builder} will have no effect on it. Will the setter methods throw IllegalStateException if the build method has already been called? Mandy > On Aug 8, 2015, at 6:56 AM, Weijun Wang wrote: > > Hi All > > JDK 9 is more restricted on calling sun.* public methods but we know there are users calling sun.security.tools.jarsigner.Main to sign jar files. A new API is proposed for this very purpose in OpenJDK. Please note it is defined in a jdk.* package therefore not a Java SE API. We are also thinking of an API to cover keytool functions. Stay tuned. > > The new API does not cover every option of the existing jarsigner tool, for example, -altsign, -tsapolicyid, -tsadigestalg, -internalsf, -sectionsonly, etc, but we hope it is enough in most use cases. > > All suggestions are welcome. > > Thanks > Max > > package jdk.security.jarsigner; > > /** > * An immutable utility class to sign a jar file. > *

> * A caller creates a {@code JarSigner.Builder} object, (optionally) sets some > * parameters, and then calls the {@link JarSigner.Builder#build build} method > * to create a {@code JarSigner} object. This {@code JarSigner} object can then > * be used to sign a jar file. > *

> * Unless otherwise stated, calling a method of {@code JarSigner} or > * {@code JarSigner.Builder} with a null argument will throw > * a {@link NullPointerException}. > *

> * Example: > * 

> * JarSigner signer = new JarSigner.Builder(key, certPath)
> *         .digestAlg("SHA-1")
> *         .sigAlg("SHA1withDSA")
> *         .build();
> * try (ZipFile in = new ZipFile(inputFile);
> *         FileOutputStream out = new FileOutputStream(outFile)) {
> *     signer.sign(in, out);
> * }
> *
> * > * @since 1.9 > */ > @jdk.Exported > public final class JarSigner { > > /** > * A mutable builder class that can create an immutable {@code JarSigner} > * from various signing-related parameters. > * > * @since 1.9 > */ > @jdk.Exported > public static class Builder { > > /** > * Creates a {@code JarSigner.Builder} object with > * a {@link KeyStore.PrivateKeyEntry} object. > * > * @param entry the {@link KeyStore.PrivateKeyEntry} of the signer. > */ > public Builder(KeyStore.PrivateKeyEntry entry); > > /** > * Creates a {@code JarSigner.Builder} object with a private key and > * a certification path. > * > * @param privateKey the private key of the signer. > * @param certPath the certification path of the signer. > * @throws IllegalArgumentException if {@code certPath} is empty, or > * the {@code privateKey} algorithm does not match the algorithm > * of the {@code PublicKey} in the end entity certificate > * (the first certificate in {@code certPath}). > */ > public Builder(PrivateKey privateKey, CertPath certPath); > > /** > * Sets the digest algorithm. If no digest algorithm is specified, > * the default algorithm returned by {@link #getDefaultDigestAlg} > * will be used. > * > * @param algorithm the standard name of the algorithm. See > * the MessageDigest section in the * "{@docRoot}/../technotes/guides/security/StandardNames.html#MessageDigest"> > * Java Cryptography Architecture Standard Algorithm Name > * Documentation for information about standard algorithm names. > * @return the {@code JarSigner.Builder} itself. > * @throws NoSuchAlgorithmException if {@code algorithm} is not available. > */ > public Builder digestAlg(String algorithm) throws NoSuchAlgorithmException; > > /** > * Sets the digest algorithm from the specified provider. > * If no digest algorithm is specified, the default algorithm > * returned by {@link #getDefaultDigestAlg} will be used. > * > * @param algorithm the standard name of the algorithm. See > * the MessageDigest section in the * "{@docRoot}/../technotes/guides/security/StandardNames.html#MessageDigest"> > * Java Cryptography Architecture Standard Algorithm Name > * Documentation for information about standard algorithm names. > * @param provider the provider. > * @return the {@code JarSigner.Builder} itself. > * @throws NoSuchAlgorithmException if {@code algorithm} is not available > * in the specified provider. > */ > public Builder digestAlg(String algorithm, Provider provider) > throws NoSuchAlgorithmException; > > /** > * Sets the signature algorithm. If no signature algorithm > * is specified, the default signature algorithm returned by > * {@link #getDefaultSigAlg} for the private key algorithm will be used. > * > * @param algorithm the standard name of the algorithm. See > * the Signature section in the * "{@docRoot}/../technotes/guides/security/StandardNames.html#Signature"> > * Java Cryptography Architecture Standard Algorithm Name > * Documentation for information about standard algorithm names. > * @return the {@code JarSigner.Builder} itself. > * @throws NoSuchAlgorithmException if {@code algorithm} is not available. > * @throws IllegalArgumentException if {@code algorithm} is not compatible > * with the algorithm of the signer's private key. > */ > public Builder sigAlg(String algorithm) throws NoSuchAlgorithmException; > > /** > * Sets the signature algorithm from the specified provider. > * If no signature algorithm is specified, the default signature algorithm > * returned by {@link #getDefaultSigAlg} for the private key algorithm > * will be used. > * > * @param algorithm the standard name of the algorithm. See > * the Signature section in the * "{@docRoot}/../technotes/guides/security/StandardNames.html#Signature"> > * Java Cryptography Architecture Standard Algorithm Name > * Documentation for information about standard algorithm names. > * @param provider the provider. > * @return the {@code JarSigner.Builder} itself. > * @throws NoSuchAlgorithmException if {@code algorithm} is not available > * in the specified provider. > * @throws IllegalArgumentException if {@code algorithm} is not compatible > * with the algorithm of the signer's private key. > */ > public Builder sigAlg(String algorithm, Provider provider) > throws NoSuchAlgorithmException; > > /** > * Sets the URI of the Time Stamping Authority (TSA). > * > * @param uri the URI. > * @return the {@code JarSigner.Builder} itself. > */ > public Builder tsa(URI uri); > > /** > * Sets the signer name. The name will be used as the base name for > * the signature files. All lowercase characters will be converted to > * uppercase for signature file names. If a signer name is not > * specified, the string "SIGNER" will be used. > * > * @param name the signer name. > * @return the {@code JarSigner.Builder} itself. > * @throws IllegalArgumentException if {@code name} is empty or has a size > * bigger than 8, or it contains characters not from the set > * "a-zA-Z0-9_-". > */ > public Builder signerName(String name); > > /** > * Gets the default digest algorithm. > * > * @implNote This implementation returns "SHA-256". The value may > * change in the future. > * > * @return the default digest algorithm. > */ > public static String getDefaultDigestAlg(); > > /** > * Gets the default signature algorithm for a private key algorithm. > * For example, SHA256withRSA for RSA, and SHA256withDSA for DSA. > * > * @implNote This implementation returns "SHA256withDSA" for the "DSA" > * key algorithm, "SHA256withRSA" for "RSA", "SHA256withECDSA" for "EC", > * and {@code null} otherwise. The value(s) may change in the future. > * > * @param keyAlg the key algorithm. > * @return the default signature algorithm. Returns null if a default > * signature algorithm cannot be found. In this case, {@link #sigAlg} > * must be called to specify a signature algorithm. Otherwise, > * the {@link #build} method will throw an {@link IllegalArgumentException}. > * @throws IllegalArgumentException if {@code keyAlg} is empty. > */ > public static String getDefaultSigAlg(String keyAlg); > > /** > * Builds a {@code JarSigner} object from the parameters set by the > * setter methods. > *

> * This method does not modify internal state of this {@code Builder} > * object and can be called multiple times to generate multiple > * {@code JarSigner} objects. After a {@code JarSigner} object is > * built, calling any setter method on this {@code Builder} will have > * no effect on it. > * > * @return the {@code JarSigner} object. > * @throws IllegalArgumentException if a signature algorithm is not > * set and cannot be derived from the private key using the > * {@link #getDefaultSigAlg} method. > */ > public JarSigner build(); > } > > /** > * Signs a file into an {@link OutputStream}. This method will not close > * {@code file} or {@code os}. > * > * @param file the file to sign. > * @param os the output stream. > * @throws JarSignerException if the signing fails. > */ > public void sign(ZipFile file, OutputStream os); > > /** > * Returns the digest algorithm for this {@code JarSigner}. > * @return the digest algorithm. The return value is never null. > */ > public String getDigestAlg(); > > /** > * Returns the signature algorithm for this {@code JarSigner}. > * @return the signature algorithm. The return value is never null. > */ > public String getSigAlg(); > > /** > * Returns the URI of the Time Stamping Authority (TSA). > * @return the URI of the TSA. > */ > public URI getTsa(); > > /** > * Returns the signer name of this {@code JarSigner}. > * @return the signer name. The return value is never null. > */ > public String getSignerName(); > } > > /** > * This exception is thrown when {@link JarSigner#sign} fails. > * > * @since 1.9 > */ > @jdk.Exported > public class JarSignerException extends RuntimeException { > > private static final long serialVersionUID = -4732217075689309530L; > > /** > * Constructs a new {@code JarSignerException} with the specified detail > * message and cause.

Note that the detail message associated with > * {@code cause} is not automatically incorporated in > * this {@code JarSignerException}'s detail message. > * > * @param message the detail message (which is saved for later retrieval > * by the {@link #getMessage()} method). > * @param cause the cause (which is saved for later retrieval by the > * {@link #getCause()} method). (A null value is > * permitted, and indicates that the cause is nonexistent or > * unknown.) > */ > public JarSignerException(String message, Throwable cause); > } From valerie.peng at oracle.com Fri Aug 14 23:30:12 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 14 Aug 2015 16:30:12 -0700 Subject: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module In-Reply-To: <55CD52F0.2000205@oracle.com> References: <55CD52F0.2000205@oracle.com> Message-ID: <55CE7A04.8080709@oracle.com> Updated the webrev in place to use "osxsecurity" given peer feedbacks. Thanks, Valerie On 8/13/2015 7:31 PM, Valerie Peng wrote: > > Can someone please help reviewing this change? > This is to move Apple provider from jdk.deploy.osx module to java.base > module. > The native library for Apple provider is separated out from the "osx" > one generated in jdk.deploy.osx module and named "osxapple" (sort of > following the convention of SunMSCAPI provider whose native library is > named "sunmscapi"). > > webrev: http://cr.openjdk.java.net/~valeriep/8086002/webrev.00/ > > Thanks, > Valerie From mandy.chung at oracle.com Fri Aug 14 23:58:21 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 14 Aug 2015 16:58:21 -0700 Subject: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module In-Reply-To: <55CE7A04.8080709@oracle.com> References: <55CD52F0.2000205@oracle.com> <55CE7A04.8080709@oracle.com> Message-ID: Looks good. Mandy > On Aug 14, 2015, at 4:30 PM, Valerie Peng wrote: > > > Updated the webrev in place to use "osxsecurity" given peer feedbacks. > Thanks, > Valerie > > On 8/13/2015 7:31 PM, Valerie Peng wrote: >> >> Can someone please help reviewing this change? >> This is to move Apple provider from jdk.deploy.osx module to java.base module. >> The native library for Apple provider is separated out from the "osx" one generated in jdk.deploy.osx module and named "osxapple" (sort of following the convention of SunMSCAPI provider whose native library is named "sunmscapi"). >> >> webrev: http://cr.openjdk.java.net/~valeriep/8086002/webrev.00/ >> >> Thanks, >> Valerie From weijun.wang at oracle.com Sat Aug 15 02:18:39 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 15 Aug 2015 10:18:39 +0800 Subject: RFC: OpenJDK JarSigner API In-Reply-To: References: <55C60AA9.4020709@oracle.com> Message-ID: <55CEA17F.20704@oracle.com> On 8/15/2015 5:37 AM, Mandy Chung wrote: > Looks good in general. > > Have you considered using ?Algorithm? instead of ?Alg? the abbreviation in the method names digesting, sigAlg etc > I reuse the jarsigner option names (-sigalg, -digestalg, -tsa), hoping people are already familiar with them. > The Builder::build method: > After a {@code JarSigner} object is built, calling any setter method on this {@code Builder} will have no effect on it. > > Will the setter methods throw IllegalStateException if the build method has already been called? No. Otherwise calling build() again is useless. A user can modify a setting and create another JarSigner. --Max > > Mandy > >> On Aug 8, 2015, at 6:56 AM, Weijun Wang wrote: >> >> Hi All >> >> JDK 9 is more restricted on calling sun.* public methods but we know there are users calling sun.security.tools.jarsigner.Main to sign jar files. A new API is proposed for this very purpose in OpenJDK. Please note it is defined in a jdk.* package therefore not a Java SE API. We are also thinking of an API to cover keytool functions. Stay tuned. >> >> The new API does not cover every option of the existing jarsigner tool, for example, -altsign, -tsapolicyid, -tsadigestalg, -internalsf, -sectionsonly, etc, but we hope it is enough in most use cases. >> >> All suggestions are welcome. >> >> Thanks >> Max >> >> package jdk.security.jarsigner; >> >> /** >> * An immutable utility class to sign a jar file. >> *

>> * A caller creates a {@code JarSigner.Builder} object, (optionally) sets some >> * parameters, and then calls the {@link JarSigner.Builder#build build} method >> * to create a {@code JarSigner} object. This {@code JarSigner} object can then >> * be used to sign a jar file. >> *

>> * Unless otherwise stated, calling a method of {@code JarSigner} or >> * {@code JarSigner.Builder} with a null argument will throw >> * a {@link NullPointerException}. >> *

>> * Example: >> * 

>> * JarSigner signer = new JarSigner.Builder(key, certPath)
>> *         .digestAlg("SHA-1")
>> *         .sigAlg("SHA1withDSA")
>> *         .build();
>> * try (ZipFile in = new ZipFile(inputFile);
>> *         FileOutputStream out = new FileOutputStream(outFile)) {
>> *     signer.sign(in, out);
>> * }
>> *
>> * >> * @since 1.9 >> */ >> @jdk.Exported >> public final class JarSigner { >> >> /** >> * A mutable builder class that can create an immutable {@code JarSigner} >> * from various signing-related parameters. >> * >> * @since 1.9 >> */ >> @jdk.Exported >> public static class Builder { >> >> /** >> * Creates a {@code JarSigner.Builder} object with >> * a {@link KeyStore.PrivateKeyEntry} object. >> * >> * @param entry the {@link KeyStore.PrivateKeyEntry} of the signer. >> */ >> public Builder(KeyStore.PrivateKeyEntry entry); >> >> /** >> * Creates a {@code JarSigner.Builder} object with a private key and >> * a certification path. >> * >> * @param privateKey the private key of the signer. >> * @param certPath the certification path of the signer. >> * @throws IllegalArgumentException if {@code certPath} is empty, or >> * the {@code privateKey} algorithm does not match the algorithm >> * of the {@code PublicKey} in the end entity certificate >> * (the first certificate in {@code certPath}). >> */ >> public Builder(PrivateKey privateKey, CertPath certPath); >> >> /** >> * Sets the digest algorithm. If no digest algorithm is specified, >> * the default algorithm returned by {@link #getDefaultDigestAlg} >> * will be used. >> * >> * @param algorithm the standard name of the algorithm. See >> * the MessageDigest section in the > * "{@docRoot}/../technotes/guides/security/StandardNames.html#MessageDigest"> >> * Java Cryptography Architecture Standard Algorithm Name >> * Documentation for information about standard algorithm names. >> * @return the {@code JarSigner.Builder} itself. >> * @throws NoSuchAlgorithmException if {@code algorithm} is not available. >> */ >> public Builder digestAlg(String algorithm) throws NoSuchAlgorithmException; >> >> /** >> * Sets the digest algorithm from the specified provider. >> * If no digest algorithm is specified, the default algorithm >> * returned by {@link #getDefaultDigestAlg} will be used. >> * >> * @param algorithm the standard name of the algorithm. See >> * the MessageDigest section in the > * "{@docRoot}/../technotes/guides/security/StandardNames.html#MessageDigest"> >> * Java Cryptography Architecture Standard Algorithm Name >> * Documentation for information about standard algorithm names. >> * @param provider the provider. >> * @return the {@code JarSigner.Builder} itself. >> * @throws NoSuchAlgorithmException if {@code algorithm} is not available >> * in the specified provider. >> */ >> public Builder digestAlg(String algorithm, Provider provider) >> throws NoSuchAlgorithmException; >> >> /** >> * Sets the signature algorithm. If no signature algorithm >> * is specified, the default signature algorithm returned by >> * {@link #getDefaultSigAlg} for the private key algorithm will be used. >> * >> * @param algorithm the standard name of the algorithm. See >> * the Signature section in the > * "{@docRoot}/../technotes/guides/security/StandardNames.html#Signature"> >> * Java Cryptography Architecture Standard Algorithm Name >> * Documentation for information about standard algorithm names. >> * @return the {@code JarSigner.Builder} itself. >> * @throws NoSuchAlgorithmException if {@code algorithm} is not available. >> * @throws IllegalArgumentException if {@code algorithm} is not compatible >> * with the algorithm of the signer's private key. >> */ >> public Builder sigAlg(String algorithm) throws NoSuchAlgorithmException; >> >> /** >> * Sets the signature algorithm from the specified provider. >> * If no signature algorithm is specified, the default signature algorithm >> * returned by {@link #getDefaultSigAlg} for the private key algorithm >> * will be used. >> * >> * @param algorithm the standard name of the algorithm. See >> * the Signature section in the > * "{@docRoot}/../technotes/guides/security/StandardNames.html#Signature"> >> * Java Cryptography Architecture Standard Algorithm Name >> * Documentation for information about standard algorithm names. >> * @param provider the provider. >> * @return the {@code JarSigner.Builder} itself. >> * @throws NoSuchAlgorithmException if {@code algorithm} is not available >> * in the specified provider. >> * @throws IllegalArgumentException if {@code algorithm} is not compatible >> * with the algorithm of the signer's private key. >> */ >> public Builder sigAlg(String algorithm, Provider provider) >> throws NoSuchAlgorithmException; >> >> /** >> * Sets the URI of the Time Stamping Authority (TSA). >> * >> * @param uri the URI. >> * @return the {@code JarSigner.Builder} itself. >> */ >> public Builder tsa(URI uri); >> >> /** >> * Sets the signer name. The name will be used as the base name for >> * the signature files. All lowercase characters will be converted to >> * uppercase for signature file names. If a signer name is not >> * specified, the string "SIGNER" will be used. >> * >> * @param name the signer name. >> * @return the {@code JarSigner.Builder} itself. >> * @throws IllegalArgumentException if {@code name} is empty or has a size >> * bigger than 8, or it contains characters not from the set >> * "a-zA-Z0-9_-". >> */ >> public Builder signerName(String name); >> >> /** >> * Gets the default digest algorithm. >> * >> * @implNote This implementation returns "SHA-256". The value may >> * change in the future. >> * >> * @return the default digest algorithm. >> */ >> public static String getDefaultDigestAlg(); >> >> /** >> * Gets the default signature algorithm for a private key algorithm. >> * For example, SHA256withRSA for RSA, and SHA256withDSA for DSA. >> * >> * @implNote This implementation returns "SHA256withDSA" for the "DSA" >> * key algorithm, "SHA256withRSA" for "RSA", "SHA256withECDSA" for "EC", >> * and {@code null} otherwise. The value(s) may change in the future. >> * >> * @param keyAlg the key algorithm. >> * @return the default signature algorithm. Returns null if a default >> * signature algorithm cannot be found. In this case, {@link #sigAlg} >> * must be called to specify a signature algorithm. Otherwise, >> * the {@link #build} method will throw an {@link IllegalArgumentException}. >> * @throws IllegalArgumentException if {@code keyAlg} is empty. >> */ >> public static String getDefaultSigAlg(String keyAlg); >> >> /** >> * Builds a {@code JarSigner} object from the parameters set by the >> * setter methods. >> *

>> * This method does not modify internal state of this {@code Builder} >> * object and can be called multiple times to generate multiple >> * {@code JarSigner} objects. After a {@code JarSigner} object is >> * built, calling any setter method on this {@code Builder} will have >> * no effect on it. >> * >> * @return the {@code JarSigner} object. >> * @throws IllegalArgumentException if a signature algorithm is not >> * set and cannot be derived from the private key using the >> * {@link #getDefaultSigAlg} method. >> */ >> public JarSigner build(); >> } >> >> /** >> * Signs a file into an {@link OutputStream}. This method will not close >> * {@code file} or {@code os}. >> * >> * @param file the file to sign. >> * @param os the output stream. >> * @throws JarSignerException if the signing fails. >> */ >> public void sign(ZipFile file, OutputStream os); >> >> /** >> * Returns the digest algorithm for this {@code JarSigner}. >> * @return the digest algorithm. The return value is never null. >> */ >> public String getDigestAlg(); >> >> /** >> * Returns the signature algorithm for this {@code JarSigner}. >> * @return the signature algorithm. The return value is never null. >> */ >> public String getSigAlg(); >> >> /** >> * Returns the URI of the Time Stamping Authority (TSA). >> * @return the URI of the TSA. >> */ >> public URI getTsa(); >> >> /** >> * Returns the signer name of this {@code JarSigner}. >> * @return the signer name. The return value is never null. >> */ >> public String getSignerName(); >> } >> >> /** >> * This exception is thrown when {@link JarSigner#sign} fails. >> * >> * @since 1.9 >> */ >> @jdk.Exported >> public class JarSignerException extends RuntimeException { >> >> private static final long serialVersionUID = -4732217075689309530L; >> >> /** >> * Constructs a new {@code JarSignerException} with the specified detail >> * message and cause.

Note that the detail message associated with >> * {@code cause} is not automatically incorporated in >> * this {@code JarSignerException}'s detail message. >> * >> * @param message the detail message (which is saved for later retrieval >> * by the {@link #getMessage()} method). >> * @param cause the cause (which is saved for later retrieval by the >> * {@link #getCause()} method). (A null value is >> * permitted, and indicates that the cause is nonexistent or >> * unknown.) >> */ >> public JarSignerException(String message, Throwable cause); >> } > From mandy.chung at oracle.com Sat Aug 15 06:39:54 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 14 Aug 2015 23:39:54 -0700 Subject: RFC: OpenJDK JarSigner API In-Reply-To: <55CEA17F.20704@oracle.com> References: <55C60AA9.4020709@oracle.com> <55CEA17F.20704@oracle.com> Message-ID: <09A1A5C1-CE39-47CD-89BB-A2E5FDB792CB@oracle.com> > On Aug 14, 2015, at 7:18 PM, Weijun Wang wrote: > > > > On 8/15/2015 5:37 AM, Mandy Chung wrote: >> Looks good in general. >> >> Have you considered using ?Algorithm? instead of ?Alg? the abbreviation in the method names digesting, sigAlg etc >> > > I reuse the jarsigner option names (-sigalg, -digestalg, -tsa), hoping people are already familiar with them. IMO the digestAlgorithm method name isn?t too long and is clearer than the abbreviation. > >> The Builder::build method: >> After a {@code JarSigner} object is built, calling any setter method on this {@code Builder} will have no effect on it. >> >> Will the setter methods throw IllegalStateException if the build method has already been called? > > No. Otherwise calling build() again is useless. A user can modify a setting and create another JarSigner. Ah.. I see. You meant no effect on the built JarSigner instance. Mandy > > --Max > >> >> Mandy >> >>> On Aug 8, 2015, at 6:56 AM, Weijun Wang wrote: >>> >>> Hi All >>> >>> JDK 9 is more restricted on calling sun.* public methods but we know there are users calling sun.security.tools.jarsigner.Main to sign jar files. A new API is proposed for this very purpose in OpenJDK. Please note it is defined in a jdk.* package therefore not a Java SE API. We are also thinking of an API to cover keytool functions. Stay tuned. >>> >>> The new API does not cover every option of the existing jarsigner tool, for example, -altsign, -tsapolicyid, -tsadigestalg, -internalsf, -sectionsonly, etc, but we hope it is enough in most use cases. >>> >>> All suggestions are welcome. >>> >>> Thanks >>> Max >>> >>> package jdk.security.jarsigner; >>> >>> /** >>> * An immutable utility class to sign a jar file. >>> *

>>> * A caller creates a {@code JarSigner.Builder} object, (optionally) sets some >>> * parameters, and then calls the {@link JarSigner.Builder#build build} method >>> * to create a {@code JarSigner} object. This {@code JarSigner} object can then >>> * be used to sign a jar file. >>> *

>>> * Unless otherwise stated, calling a method of {@code JarSigner} or >>> * {@code JarSigner.Builder} with a null argument will throw >>> * a {@link NullPointerException}. >>> *

>>> * Example: >>> * 

>>> * JarSigner signer = new JarSigner.Builder(key, certPath)
>>> *         .digestAlg("SHA-1")
>>> *         .sigAlg("SHA1withDSA")
>>> *         .build();
>>> * try (ZipFile in = new ZipFile(inputFile);
>>> *         FileOutputStream out = new FileOutputStream(outFile)) {
>>> *     signer.sign(in, out);
>>> * }
>>> *
>>> * >>> * @since 1.9 >>> */ >>> @jdk.Exported >>> public final class JarSigner { >>> >>> /** >>> * A mutable builder class that can create an immutable {@code JarSigner} >>> * from various signing-related parameters. >>> * >>> * @since 1.9 >>> */ >>> @jdk.Exported >>> public static class Builder { >>> >>> /** >>> * Creates a {@code JarSigner.Builder} object with >>> * a {@link KeyStore.PrivateKeyEntry} object. >>> * >>> * @param entry the {@link KeyStore.PrivateKeyEntry} of the signer. >>> */ >>> public Builder(KeyStore.PrivateKeyEntry entry); >>> >>> /** >>> * Creates a {@code JarSigner.Builder} object with a private key and >>> * a certification path. >>> * >>> * @param privateKey the private key of the signer. >>> * @param certPath the certification path of the signer. >>> * @throws IllegalArgumentException if {@code certPath} is empty, or >>> * the {@code privateKey} algorithm does not match the algorithm >>> * of the {@code PublicKey} in the end entity certificate >>> * (the first certificate in {@code certPath}). >>> */ >>> public Builder(PrivateKey privateKey, CertPath certPath); >>> >>> /** >>> * Sets the digest algorithm. If no digest algorithm is specified, >>> * the default algorithm returned by {@link #getDefaultDigestAlg} >>> * will be used. >>> * >>> * @param algorithm the standard name of the algorithm. See >>> * the MessageDigest section in the >> * "{@docRoot}/../technotes/guides/security/StandardNames.html#MessageDigest"> >>> * Java Cryptography Architecture Standard Algorithm Name >>> * Documentation for information about standard algorithm names. >>> * @return the {@code JarSigner.Builder} itself. >>> * @throws NoSuchAlgorithmException if {@code algorithm} is not available. >>> */ >>> public Builder digestAlg(String algorithm) throws NoSuchAlgorithmException; >>> >>> /** >>> * Sets the digest algorithm from the specified provider. >>> * If no digest algorithm is specified, the default algorithm >>> * returned by {@link #getDefaultDigestAlg} will be used. >>> * >>> * @param algorithm the standard name of the algorithm. See >>> * the MessageDigest section in the >> * "{@docRoot}/../technotes/guides/security/StandardNames.html#MessageDigest"> >>> * Java Cryptography Architecture Standard Algorithm Name >>> * Documentation for information about standard algorithm names. >>> * @param provider the provider. >>> * @return the {@code JarSigner.Builder} itself. >>> * @throws NoSuchAlgorithmException if {@code algorithm} is not available >>> * in the specified provider. >>> */ >>> public Builder digestAlg(String algorithm, Provider provider) >>> throws NoSuchAlgorithmException; >>> >>> /** >>> * Sets the signature algorithm. If no signature algorithm >>> * is specified, the default signature algorithm returned by >>> * {@link #getDefaultSigAlg} for the private key algorithm will be used. >>> * >>> * @param algorithm the standard name of the algorithm. See >>> * the Signature section in the >> * "{@docRoot}/../technotes/guides/security/StandardNames.html#Signature"> >>> * Java Cryptography Architecture Standard Algorithm Name >>> * Documentation for information about standard algorithm names. >>> * @return the {@code JarSigner.Builder} itself. >>> * @throws NoSuchAlgorithmException if {@code algorithm} is not available. >>> * @throws IllegalArgumentException if {@code algorithm} is not compatible >>> * with the algorithm of the signer's private key. >>> */ >>> public Builder sigAlg(String algorithm) throws NoSuchAlgorithmException; >>> >>> /** >>> * Sets the signature algorithm from the specified provider. >>> * If no signature algorithm is specified, the default signature algorithm >>> * returned by {@link #getDefaultSigAlg} for the private key algorithm >>> * will be used. >>> * >>> * @param algorithm the standard name of the algorithm. See >>> * the Signature section in the >> * "{@docRoot}/../technotes/guides/security/StandardNames.html#Signature"> >>> * Java Cryptography Architecture Standard Algorithm Name >>> * Documentation for information about standard algorithm names. >>> * @param provider the provider. >>> * @return the {@code JarSigner.Builder} itself. >>> * @throws NoSuchAlgorithmException if {@code algorithm} is not available >>> * in the specified provider. >>> * @throws IllegalArgumentException if {@code algorithm} is not compatible >>> * with the algorithm of the signer's private key. >>> */ >>> public Builder sigAlg(String algorithm, Provider provider) >>> throws NoSuchAlgorithmException; >>> >>> /** >>> * Sets the URI of the Time Stamping Authority (TSA). >>> * >>> * @param uri the URI. >>> * @return the {@code JarSigner.Builder} itself. >>> */ >>> public Builder tsa(URI uri); >>> >>> /** >>> * Sets the signer name. The name will be used as the base name for >>> * the signature files. All lowercase characters will be converted to >>> * uppercase for signature file names. If a signer name is not >>> * specified, the string "SIGNER" will be used. >>> * >>> * @param name the signer name. >>> * @return the {@code JarSigner.Builder} itself. >>> * @throws IllegalArgumentException if {@code name} is empty or has a size >>> * bigger than 8, or it contains characters not from the set >>> * "a-zA-Z0-9_-". >>> */ >>> public Builder signerName(String name); >>> >>> /** >>> * Gets the default digest algorithm. >>> * >>> * @implNote This implementation returns "SHA-256". The value may >>> * change in the future. >>> * >>> * @return the default digest algorithm. >>> */ >>> public static String getDefaultDigestAlg(); >>> >>> /** >>> * Gets the default signature algorithm for a private key algorithm. >>> * For example, SHA256withRSA for RSA, and SHA256withDSA for DSA. >>> * >>> * @implNote This implementation returns "SHA256withDSA" for the "DSA" >>> * key algorithm, "SHA256withRSA" for "RSA", "SHA256withECDSA" for "EC", >>> * and {@code null} otherwise. The value(s) may change in the future. >>> * >>> * @param keyAlg the key algorithm. >>> * @return the default signature algorithm. Returns null if a default >>> * signature algorithm cannot be found. In this case, {@link #sigAlg} >>> * must be called to specify a signature algorithm. Otherwise, >>> * the {@link #build} method will throw an {@link IllegalArgumentException}. >>> * @throws IllegalArgumentException if {@code keyAlg} is empty. >>> */ >>> public static String getDefaultSigAlg(String keyAlg); >>> >>> /** >>> * Builds a {@code JarSigner} object from the parameters set by the >>> * setter methods. >>> *

>>> * This method does not modify internal state of this {@code Builder} >>> * object and can be called multiple times to generate multiple >>> * {@code JarSigner} objects. After a {@code JarSigner} object is >>> * built, calling any setter method on this {@code Builder} will have >>> * no effect on it. >>> * >>> * @return the {@code JarSigner} object. >>> * @throws IllegalArgumentException if a signature algorithm is not >>> * set and cannot be derived from the private key using the >>> * {@link #getDefaultSigAlg} method. >>> */ >>> public JarSigner build(); >>> } >>> >>> /** >>> * Signs a file into an {@link OutputStream}. This method will not close >>> * {@code file} or {@code os}. >>> * >>> * @param file the file to sign. >>> * @param os the output stream. >>> * @throws JarSignerException if the signing fails. >>> */ >>> public void sign(ZipFile file, OutputStream os); >>> >>> /** >>> * Returns the digest algorithm for this {@code JarSigner}. >>> * @return the digest algorithm. The return value is never null. >>> */ >>> public String getDigestAlg(); >>> >>> /** >>> * Returns the signature algorithm for this {@code JarSigner}. >>> * @return the signature algorithm. The return value is never null. >>> */ >>> public String getSigAlg(); >>> >>> /** >>> * Returns the URI of the Time Stamping Authority (TSA). >>> * @return the URI of the TSA. >>> */ >>> public URI getTsa(); >>> >>> /** >>> * Returns the signer name of this {@code JarSigner}. >>> * @return the signer name. The return value is never null. >>> */ >>> public String getSignerName(); >>> } >>> >>> /** >>> * This exception is thrown when {@link JarSigner#sign} fails. >>> * >>> * @since 1.9 >>> */ >>> @jdk.Exported >>> public class JarSignerException extends RuntimeException { >>> >>> private static final long serialVersionUID = -4732217075689309530L; >>> >>> /** >>> * Constructs a new {@code JarSignerException} with the specified detail >>> * message and cause.

Note that the detail message associated with >>> * {@code cause} is not automatically incorporated in >>> * this {@code JarSignerException}'s detail message. >>> * >>> * @param message the detail message (which is saved for later retrieval >>> * by the {@link #getMessage()} method). >>> * @param cause the cause (which is saved for later retrieval by the >>> * {@link #getCause()} method). (A null value is >>> * permitted, and indicates that the cause is nonexistent or >>> * unknown.) >>> */ >>> public JarSignerException(String message, Throwable cause); >>> } >> From amanda.jiang at oracle.com Mon Aug 17 05:39:19 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Sun, 16 Aug 2015 22:39:19 -0700 Subject: RFR 8050427 LoginContext tests to cover JDK-4703361 Message-ID: <55D17387.7030201@oracle.com> Hi All, Please be free to review these new tests for Dynamic configuration of authentication modules. Bug: https://bugs.openjdk.java.net/browse/JDK-8050427 webrev:http://cr.openjdk.java.net/~amjiang/8050427/webrev.01/ Thanks, Amanda From weijun.wang at oracle.com Mon Aug 17 07:29:30 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 17 Aug 2015 15:29:30 +0800 Subject: RFR 8050427 LoginContext tests to cover JDK-4703361 In-Reply-To: <55D17387.7030201@oracle.com> References: <55D17387.7030201@oracle.com> Message-ID: <55D18D5A.7020207@oracle.com> There are something I don't understand. MyConfiguration.java: - optionOrder: Is it possible to make this an argument of the constructor? - getConfiguration/setConfiguration: If these are useless, why adding these methods? SmartLoginModule.java: - initialize: Why don't you use the callbackHandler argument? - shouldSucceed: It is always very confusing to make a field accessible from outside a class. DynamicConfigurationTest.java: - test: why the if checks are based on both isNegative and success? Why not only on isNegative? If you want to test 2 stages (initialize and login), you can provide 2 isNegative flags. Thanks Max On 08/17/2015 01:39 PM, Amanda Jiang wrote: > Hi All, > > Please be free to review these new tests for Dynamic configuration of > authentication modules. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8050427 > webrev:http://cr.openjdk.java.net/~amjiang/8050427/webrev.01/ > > > Thanks, > Amanda > > From weijun.wang at oracle.com Mon Aug 17 08:21:57 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 17 Aug 2015 16:21:57 +0800 Subject: RFC JEP: NIST SP 800-90A SecureRandom implementations Message-ID: <55D199A5.4060609@oracle.com> Hi All Please take a look at the draft JEP at https://bugs.openjdk.java.net/browse/JDK-8051408 With this JEP, we'd like to add new pure-Java SecureRandom implementations to OpenJDK, which are based on DRBG mechanisms in NIST SP 800-90Ar1 [1]. According to 800-90C [3], RBG (SecureRandom in Java) consists of a DRBG and its Source of Entropy Input, most likely an Entropy Source [2] which is able to return fresh full entropy. This JEP introduced an EntropyInput interface but has not provided many methods (you might want getAvailability(), getRate(), setTimeOut(), etc). It will be enhanced in another JEP (possibly not in JDK 9). All suggestions are welcome. Thanks Max [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf [2] http://csrc.nist.gov/publications/drafts/800-90/draft-sp800-90c.pdf [3] http://csrc.nist.gov/publications/drafts/800-90/draft-sp800-90b.pdf From erik.joelsson at oracle.com Mon Aug 17 10:09:40 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 17 Aug 2015 12:09:40 +0200 Subject: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module In-Reply-To: <55CE7A04.8080709@oracle.com> References: <55CD52F0.2000205@oracle.com> <55CE7A04.8080709@oracle.com> Message-ID: <55D1B2E4.2070402@oracle.com> Build changes still look good. /Erik On 2015-08-15 01:30, Valerie Peng wrote: > > Updated the webrev in place to use "osxsecurity" given peer feedbacks. > Thanks, > Valerie > > On 8/13/2015 7:31 PM, Valerie Peng wrote: >> >> Can someone please help reviewing this change? >> This is to move Apple provider from jdk.deploy.osx module to >> java.base module. >> The native library for Apple provider is separated out from the "osx" >> one generated in jdk.deploy.osx module and named "osxapple" (sort of >> following the convention of SunMSCAPI provider whose native library >> is named "sunmscapi"). >> >> webrev: http://cr.openjdk.java.net/~valeriep/8086002/webrev.00/ >> >> Thanks, >> Valerie From valerie.peng at oracle.com Tue Aug 18 00:21:38 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 17 Aug 2015 17:21:38 -0700 Subject: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module In-Reply-To: References: <55CD52F0.2000205@oracle.com> <55CE7A04.8080709@oracle.com> Message-ID: <55D27A92.5080105@oracle.com> Thanks for the review. Is one more reviewer from build team needed? Valerie On 8/14/2015 4:58 PM, Mandy Chung wrote: > Looks good. > Mandy > >> On Aug 14, 2015, at 4:30 PM, Valerie Peng wrote: >> >> >> Updated the webrev in place to use "osxsecurity" given peer feedbacks. >> Thanks, >> Valerie >> >> On 8/13/2015 7:31 PM, Valerie Peng wrote: >>> Can someone please help reviewing this change? >>> This is to move Apple provider from jdk.deploy.osx module to java.base module. >>> The native library for Apple provider is separated out from the "osx" one generated in jdk.deploy.osx module and named "osxapple" (sort of following the convention of SunMSCAPI provider whose native library is named "sunmscapi"). >>> >>> webrev: http://cr.openjdk.java.net/~valeriep/8086002/webrev.00/ >>> >>> Thanks, >>> Valerie From erik.joelsson at oracle.com Tue Aug 18 07:34:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 18 Aug 2015 09:34:06 +0200 Subject: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module In-Reply-To: <55D27A92.5080105@oracle.com> References: <55CD52F0.2000205@oracle.com> <55CE7A04.8080709@oracle.com> <55D27A92.5080105@oracle.com> Message-ID: <55D2DFEE.4090401@oracle.com> One is enough. /Erik On 2015-08-18 02:21, Valerie Peng wrote: > Thanks for the review. > Is one more reviewer from build team needed? > Valerie > > On 8/14/2015 4:58 PM, Mandy Chung wrote: >> Looks good. >> Mandy >> >>> On Aug 14, 2015, at 4:30 PM, Valerie Peng >>> wrote: >>> >>> >>> Updated the webrev in place to use "osxsecurity" given peer feedbacks. >>> Thanks, >>> Valerie >>> >>> On 8/13/2015 7:31 PM, Valerie Peng wrote: >>>> Can someone please help reviewing this change? >>>> This is to move Apple provider from jdk.deploy.osx module to >>>> java.base module. >>>> The native library for Apple provider is separated out from the >>>> "osx" one generated in jdk.deploy.osx module and named "osxapple" >>>> (sort of following the convention of SunMSCAPI provider whose >>>> native library is named "sunmscapi"). >>>> >>>> webrev: http://cr.openjdk.java.net/~valeriep/8086002/webrev.00/ >>>> >>>> Thanks, >>>> Valerie From alexander.v.stepanov at oracle.com Tue Aug 18 10:56:07 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Tue, 18 Aug 2015 13:56:07 +0300 Subject: RFR [9] 8133802: replace some tags (obsolete in html5) in security-libs docs Message-ID: <55D30F47.7030304@oracle.com> Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8133802/webrev.00 for https://bugs.openjdk.java.net/browse/JDK-8133802 Just another portion of deprecated tags replaced with {@code } (some

tags were replaced as well). Thanks, Alexander From vincent.x.ryan at oracle.com Tue Aug 18 11:23:03 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 18 Aug 2015 12:23:03 +0100 Subject: [9] code review request for 8130799: KeyStoreSpi.engineProbe does not throw the expected NullPointerException Message-ID: <B3B6B422-05E1-42BF-974C-B1659046F80A@oracle.com> Please review this trivial change to the KeyStoreSpi.engineProbe method so that it matches its specification wrt NPE. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8130799 <https://bugs.openjdk.java.net/browse/JDK-8130799> Webrev: http://cr.openjdk.java.net/~vinnie/8130799/webrev.00/ <http://cr.openjdk.java.net/~vinnie/8130799/webrev.00/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150818/657bad5b/attachment.html> From valerie.peng at oracle.com Tue Aug 18 20:53:44 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 18 Aug 2015 13:53:44 -0700 Subject: [9] RFR 8086002: Move apple.security.AppleProvider to a proper module In-Reply-To: <55D2DFEE.4090401@oracle.com> References: <55CD52F0.2000205@oracle.com> <55CE7A04.8080709@oracle.com> <A16694D9-7088-4833-96E9-C8C3FA10D336@oracle.com> <55D27A92.5080105@oracle.com> <55D2DFEE.4090401@oracle.com> Message-ID: <55D39B58.2020904@oracle.com> Ok, thanks! Valerie On 8/18/2015 12:34 AM, Erik Joelsson wrote: > One is enough. > > /Erik > > On 2015-08-18 02:21, Valerie Peng wrote: >> Thanks for the review. >> Is one more reviewer from build team needed? >> Valerie >> >> On 8/14/2015 4:58 PM, Mandy Chung wrote: >>> Looks good. >>> Mandy >>> >>>> On Aug 14, 2015, at 4:30 PM, Valerie Peng<valerie.peng at oracle.com> >>>> wrote: >>>> >>>> >>>> Updated the webrev in place to use "osxsecurity" given peer feedbacks. >>>> Thanks, >>>> Valerie >>>> >>>> On 8/13/2015 7:31 PM, Valerie Peng wrote: >>>>> Can someone please help reviewing this change? >>>>> This is to move Apple provider from jdk.deploy.osx module to >>>>> java.base module. >>>>> The native library for Apple provider is separated out from the >>>>> "osx" one generated in jdk.deploy.osx module and named "osxapple" >>>>> (sort of following the convention of SunMSCAPI provider whose >>>>> native library is named "sunmscapi"). >>>>> >>>>> webrev: http://cr.openjdk.java.net/~valeriep/8086002/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie > From xuelei.fan at oracle.com Wed Aug 19 00:54:57 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 19 Aug 2015 08:54:57 +0800 Subject: [9] review request for JDK-8050460: JAAS login/logout tests with LoginContext In-Reply-To: <55C89FB1.9050007@oracle.com> References: <55C89FB1.9050007@oracle.com> Message-ID: <55D3D3E1.2000203@oracle.com> Looks fine to me. Xuelei On 8/10/2015 8:57 PM, Svetlana Nikandrova wrote: > Hello, > > Please review tests for login/logout with LoginContex. > > Webrev: http://cr.openjdk.java.net/~asmotrak/sweta/8050460/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8050460 > > Thanks, > Svetlana > > From xuelei.fan at oracle.com Wed Aug 19 01:01:59 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 19 Aug 2015 09:01:59 +0800 Subject: [9] RFR: 8049237: Need new tests for X509V3 certificates In-Reply-To: <55A5B948.5030400@oracle.com> References: <55A5B948.5030400@oracle.com> Message-ID: <55D3D587.9070603@oracle.com> Hi Rajan, Sorry for the delay. The code looks fine to me. I was just wondering, what's the purpose for the V1toV3Cert.java test? Is it practice behavior? Thanks, Xuelei On 7/15/2015 9:37 AM, Rajan Halade wrote: > May I request you to review two new tests added. V1toV3Cert tries to > covert a existing V1 certificate to V3 and V3Certificate test tries to > generate V3 certificate with different extensions. > > Webrev: http://cr.openjdk.java.net/~rhalade/8049237/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8049237 > > Thanks, > Rajan From xuelei.fan at oracle.com Wed Aug 19 07:46:53 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 19 Aug 2015 15:46:53 +0800 Subject: [9] RFR: 8048601: Tests for JCE crypto ciphers In-Reply-To: <55A57096.10700@oracle.com> References: <55A57096.10700@oracle.com> Message-ID: <55D4346D.2090907@oracle.com> Looks fine to me. Xuelei On 7/15/2015 4:27 AM, Rajan Halade wrote: > May I request you to review new tests added to check Cipher operations > with different algorithms and modes. > > Webrev: http://cr.openjdk.java.net/~rhalade/8048601/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8048601 > > Thanks, > Rajan From xuelei.fan at oracle.com Wed Aug 19 15:56:31 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 19 Aug 2015 23:56:31 +0800 Subject: [9] code review request for 8130799: KeyStoreSpi.engineProbe does not throw the expected NullPointerException In-Reply-To: <B3B6B422-05E1-42BF-974C-B1659046F80A@oracle.com> References: <B3B6B422-05E1-42BF-974C-B1659046F80A@oracle.com> Message-ID: <55D4A72F.2090108@oracle.com> Looks fine to me. Don't you want to add a exception message to indicate the input stream is null? Xuelei On 8/18/2015 7:23 PM, Vincent Ryan wrote: > Please review this trivial change to the KeyStoreSpi.engineProbe method > so that it matches its specification wrt NPE. > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130799 > Webrev: http://cr.openjdk.java.net/~vinnie/8130799/webrev.00/ From vincent.x.ryan at oracle.com Wed Aug 19 16:01:11 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 19 Aug 2015 17:01:11 +0100 Subject: [9] code review request for 8130799: KeyStoreSpi.engineProbe does not throw the expected NullPointerException In-Reply-To: <55D4A72F.2090108@oracle.com> References: <B3B6B422-05E1-42BF-974C-B1659046F80A@oracle.com> <55D4A72F.2090108@oracle.com> Message-ID: <82255D8D-0A21-40C2-A9BB-05EA4AA4F14F@oracle.com> Thanks Xuelei, I?ll add that message. > On 19 Aug 2015, at 16:56, Xuelei Fan <xuelei.fan at oracle.com> wrote: > > Looks fine to me. Don't you want to add a exception message to indicate > the input stream is null? > > Xuelei > > On 8/18/2015 7:23 PM, Vincent Ryan wrote: >> Please review this trivial change to the KeyStoreSpi.engineProbe method >> so that it matches its specification wrt NPE. >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8130799 >> Webrev: http://cr.openjdk.java.net/~vinnie/8130799/webrev.00/ > From vincent.x.ryan at oracle.com Wed Aug 19 16:59:05 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 19 Aug 2015 17:59:05 +0100 Subject: [9] review request for 8132786: java/security/cert/CertPathValidator/OCSP/AIACheck.java fails intermittently Message-ID: <DFBF2333-5326-4766-994C-2C1BF8F4F8F7@oracle.com> Please review this fix for an intermittently failing test. It now expects a SocketException or a SocketTimeoutException. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8132786 Webrev: http://cr.openjdk.java.net/~vinnie/8132786/webrev.00/ From valerie.peng at oracle.com Wed Aug 19 17:18:26 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 19 Aug 2015 10:18:26 -0700 Subject: [9] RFR: 8048601: Tests for JCE crypto ciphers In-Reply-To: <55D4346D.2090907@oracle.com> References: <55A57096.10700@oracle.com> <55D4346D.2090907@oracle.com> Message-ID: <55D4BA62.5040407@oracle.com> Rajan, I have some comments and will send u later today. Please hold off the integration of this for a little bit. Thanks, Valerie On 8/19/2015 12:46 AM, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 7/15/2015 4:27 AM, Rajan Halade wrote: >> May I request you to review new tests added to check Cipher operations >> with different algorithms and modes. >> >> Webrev: http://cr.openjdk.java.net/~rhalade/8048601/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048601 >> >> Thanks, >> Rajan From valerie.peng at oracle.com Wed Aug 19 22:38:56 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 19 Aug 2015 15:38:56 -0700 Subject: [9] RFR: 8048601: Tests for JCE crypto ciphers In-Reply-To: <55A57096.10700@oracle.com> References: <55A57096.10700@oracle.com> Message-ID: <55D50580.8090402@oracle.com> Rajan, TestCipher.java 1) this class is used as the base for many algorithm, modes, and paddings. But then it hardcodes some values or parameter types which may not work against some algorithms, e.g. IvParameterSpec with 8-byte value, padding length being 8 bytes. PAD_LEN=8 vs PAD_BYTES=16, is this difference intentional? Seems to me that this TestCipher class only works against Ciphers w/ 8-byte blocks and uses iv. I think it's clearer to have a constant named BLKSIZE instead of just 8. 2) Also, u don't need to repeatedly generate random bytes for input data, IV, etc. The input data can be generated once outside of loop. As for the parameters, either u can just let the cipher object generates it or grab the IV values from whatever data that u have already, e.g. certain part of the input data. 2) input length is always 800. Would be nice to have a comment stating the requirement, e.g. multiple of blocks in order to work against ciphers w/ NoPadding 3) line 54, Would be nice to clarify that the range of tested key size is from MINIMUM_KEY_SIZE to what returned by Cipher.getMaxAllowedKeyLength(ALGORITHM) with the increment of KEYCUTTER. 4) line 66, keyStrength is better phrased as variousKeySize in my opinion. 5) MINIMUM_KEY_SIZE and KEYCUTTER should be algorithm specific. It'd be clearer to explicitly list out the algorithms which works against the the hardcoded values for the sake of maintenance. 6) It looks to me that String[] modes and String[] paddings could be moved to runAll(). This seems more consistent with the signature of runTest() where mode and padding are again specified here. Will send u comments regarding the TestLength ones in a separate email. Thanks, Valerie On 7/14/2015 1:27 PM, Rajan Halade wrote: > May I request you to review new tests added to check Cipher operations > with different algorithms and modes. > > Webrev: http://cr.openjdk.java.net/~rhalade/8048601/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8048601 > > Thanks, > Rajan From tristan.yan at oracle.com Thu Aug 20 16:31:37 2015 From: tristan.yan at oracle.com (Tristan Yan) Date: Thu, 20 Aug 2015 09:31:37 -0700 Subject: RFR 8044199: tests for RSA keys and key specifications Message-ID: <55D600E9.4040003@oracle.com> Thanks Valerie Please review the fixed version. http://cr.openjdk.java.net/~tyan/8044199/webrev.02/ Tristan > Tristan, > > - Given that the tests are against SunRsaSign provider, I think > sun/security/rsa subdirectory is a better choice than java/security/rsa. > - Put @test and @bug on separate lines > - Elaborate more on what is tested and what is the expected result in > the bug record. The current content isn't very clear. > - Can u have more unique names for these tests? Currently, they are too > similarly named and it's somewhat confusing. The directory already > contains RSA, I don't feel that u need to have RSA again in the names of > the test especially when SunRsaSign provider doesn't support non-RSA > algorithms. > > For KeyTest.java > 1) typo on line 69, rsaPrivateKey2 should be rsaPrivateKey > 2) This test is based on the> provider specific behavior that CRT key is > generated by default for RSA. It'd be much clearer if you can add an > instanceof check on the generated RSA private key objects before the > KeyFactory + RSAPrivateKeySpec code. In addition, add additional code to > check for equality with the matching KeySpec (e.g. RSAPrivateCrtKeySpec > for RSAPrivateCrtKey) is used. > 3) line 58, add a space between '//" and text. > > For RSAKeySizeTest.java > 1) specify provider "SunRSASign" for all getInstance() calls. > 2) line 55 can be moved up to before the for-loop. > 3) instead of using toString(int), probably bitLength() would be a > better choice. > 4) sizeTest() doesn't really check size but rather it compares the > modulus values being equal. This check can be moved to RSAKeySizeTest.java. > > For RSATest.java > 1) specify provider "SunRSASign" for all getInstance() calls. > > Thanks, > Valerie > > On 8/3/2015 10:27 AM, Tristan Yan wrote: >>/ Hi />>/ />>/ Please review new tests for RSA keys and key specifications />>/ />>/ Bug:https://bugs.openjdk.java.net/browse/JDK-8044199 />>/ Webrev:http://cr.openjdk.java.net/~tyan/8044199/webrev.01/ <http://cr.openjdk.java.net/%7Etyan/8044199/webrev.01/> <http://cr.openjdk.java.net/%7Etyan/8044199/webrev.01/> <http://cr.openjdk.java.net/~tyan/8044199/webrev.01/ <http://cr.openjdk.java.net/%7Etyan/8044199/webrev.01/> <http://cr.openjdk.java.net/%7Etyan/8044199/webrev.01/>> />>/ />>/ Thanks />>/ Tristan />> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150820/73e9f022/attachment.html> From amanda.jiang at oracle.com Thu Aug 20 21:47:05 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 20 Aug 2015 14:47:05 -0700 Subject: RFR 8075020: Additional interop tests for Java as HTTPS client Message-ID: <55D64AD9.4090807@oracle.com> Hi All, Please help to review following changeset which add some interoperability testing for Https Client Bug: https://bugs.openjdk.java.net/browse/JDK-8075020 webrev: http://cr.openjdk.java.net/~amjiang/8075020/webrev.01/ Thanks, Amanda From amanda.jiang at oracle.com Thu Aug 20 21:57:13 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 20 Aug 2015 14:57:13 -0700 Subject: RFR 8075020: Additional interop tests for Java as HTTPS client In-Reply-To: <55D64AD9.4090807@oracle.com> References: <55D64AD9.4090807@oracle.com> Message-ID: <55D64D39.3080909@oracle.com> Please ignore the request. Thanks, Amanda On 8/20/15, 2:47 PM, Amanda Jiang wrote: > Hi All, > > Please help to review following changeset which add some > interoperability testing for Https Client > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075020 > webrev: http://cr.openjdk.java.net/~amjiang/8075020/webrev.01/ > > Thanks, > Amanda > From amanda.jiang at oracle.com Thu Aug 20 23:11:32 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 20 Aug 2015 16:11:32 -0700 Subject: RFR 8048357: PKCS basic tests Message-ID: <55D65EA4.60905@oracle.com> Hi All, Please be free to review new tests for conformance testing of PKCS. bug: https://bugs.openjdk.java.net/browse/JDK-8048357 webrev: http://cr.openjdk.java.net/~amjiang/8048357/webrev.01/ Thanks, Amanda -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150820/b3b2df37/attachment.html> From valerie.peng at oracle.com Thu Aug 20 23:19:49 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 20 Aug 2015 16:19:49 -0700 Subject: [9] RFR: 8048601: Tests for JCE crypto ciphers In-Reply-To: <55D50580.8090402@oracle.com> References: <55A57096.10700@oracle.com> <55D50580.8090402@oracle.com> Message-ID: <55D66095.4090309@oracle.com> Rajan, Here are some comments for the other half of the webrev: TestCipherTextLength.java 1) line 82 and 85, why TEXT_LEN is needed? I don't find any usage of it inside runAll(..) method? 2) the names here are a bit too similar, e.g. PBEWrapper, PBECipherWrapper, AESPBEWrapper. The individual subclasses aren't that big, why not make them inner static classes of the parent class? No need to repeat the Wrapper and PBE in the subclass names. To match your other wrapper class DESCipherWrapper, perhaps you can rename the PBE counterpart to something like: PBECipherWrapper (parent) with subclasses (defined statically inside PBECipherWrapper) named PBKDF2, AES, and Legacy (these are PKCS#5 v1.5 defined algorithms). PBKDF2Wrapper.java 1) typo on line 43 and 52 - should be T_R_ANSFORMATION 2) Instead of "PKDF2_DEFAULT_KEY_LEN" (typo? I think u meant PBKDF2), it should really be CIPHER_KEY_SIZE since the purpose here is to generate keys for the Cipher object. 3) the key that you generated on line 57 can be viewed as an intermediate key. You could have moved the processing in initCipher(...) method into the constructor and store the resulting cipher key into 'key'. For example: SecretKey derivedKey = keyFactory.generateSecret(pbeKeySpec); key = new SecretKeySpec(derivedKey.getEncoded(), KEY_ALGORITHM); Thanks, Valerie On 8/19/2015 3:38 PM, Valerie Peng wrote: > Rajan, > > TestCipher.java > 1) this class is used as the base for many algorithm, modes, and > paddings. But then it hardcodes some values or parameter types which > may not work against some algorithms, e.g. IvParameterSpec with 8-byte > value, padding length being 8 bytes. PAD_LEN=8 vs PAD_BYTES=16, is > this difference intentional? > Seems to me that this TestCipher class only works against Ciphers w/ > 8-byte blocks and uses iv. I think it's clearer to have a constant > named BLKSIZE instead of just 8. > 2) Also, u don't need to repeatedly generate random bytes for input > data, IV, etc. The input data can be generated once outside of loop. > As for the parameters, either u can just let the cipher object > generates it or grab the IV values from whatever data that u have > already, e.g. certain part of the input data. > 2) input length is always 800. Would be nice to have a comment stating > the requirement, e.g. multiple of blocks in order to work against > ciphers w/ NoPadding > 3) line 54, Would be nice to clarify that the range of tested key size > is from MINIMUM_KEY_SIZE to what returned by > Cipher.getMaxAllowedKeyLength(ALGORITHM) with the increment of KEYCUTTER. > 4) line 66, keyStrength is better phrased as variousKeySize in my > opinion. > 5) MINIMUM_KEY_SIZE and KEYCUTTER should be algorithm specific. It'd > be clearer to explicitly list out the algorithms which works against > the the hardcoded values for the sake of maintenance. > 6) It looks to me that String[] modes and String[] paddings could be > moved to runAll(). This seems more consistent with the signature of > runTest() where mode and padding are again specified here. > > Will send u comments regarding the TestLength ones in a separate email. > Thanks, > Valerie > > On 7/14/2015 1:27 PM, Rajan Halade wrote: >> May I request you to review new tests added to check Cipher >> operations with different algorithms and modes. >> >> Webrev: http://cr.openjdk.java.net/~rhalade/8048601/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048601 >> >> Thanks, >> Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150820/0befd827/attachment-0001.html> From ecki at zusammenkunft.net Fri Aug 21 00:32:05 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 21 Aug 2015 02:32:05 +0200 Subject: RFR 8048357: PKCS basic tests In-Reply-To: <55D65EA4.60905@oracle.com> References: <55D65EA4.60905@oracle.com> Message-ID: <20150821023205.00006309.ecki@zusammenkunft.net> Hello Amanda, out of curiosity I was looking at the tests, and have a few comments: PKCS7VerifyTest.java 63 byte[] base64Bytes = new byte[pkcs7In.available()]; 64 if (pkcs7In.read(base64Bytes) < base64Bytes.length) { There are two pet peeves of mine. available() to get the file length and reading without a loop. Both (and more code) could be avoided with Files.readAllBytes() SignOrder.java (not sure what the DER contains. comment? but generally speaking): 94 AlgorithmId[] algIds = {new AlgorithmId(AlgorithmId.MD5_oid), 95 new AlgorithmId(AlgorithmId.SHA_oid)}; ... 192 keyGen.initialize(512); Would it be better to test with more modern algorithms (SHA2) and larger (1024) key sizes. Especially since this will reduce problems when weak 512bit keys some times in the future get blocked. Gruss Bernd Am Thu, 20 Aug 2015 16:11:32 -0700 schrieb Amanda Jiang <amanda.jiang at oracle.com>: > Hi All, > > Please be free to review new tests for conformance testing of PKCS. > > bug: https://bugs.openjdk.java.net/browse/JDK-8048357 > webrev: http://cr.openjdk.java.net/~amjiang/8048357/webrev.01/ > > Thanks, > Amanda > From weijun.wang at oracle.com Fri Aug 21 07:13:11 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 21 Aug 2015 15:13:11 +0800 Subject: RFR 8048357: PKCS basic tests In-Reply-To: <55D65EA4.60905@oracle.com> References: <55D65EA4.60905@oracle.com> Message-ID: <55D6CF87.807@oracle.com> PKCS10AttrOrder.java: - Why not inline revAttributes(), prov() and constructMap()? They are only used once. Putting the content into the main method is more clear. - You can create separate method for the while look checks. The 2 look identical. PKCS10AttributeReader.java: - Is it OK to indent the data in the comment to multiple levels? - Again, initMap() not necessary. PKCS7VerifyTest.java: - Not sure what this is for. The 1st and 2nd argument of the @run line are the same? SignerOrder.java: - Comment on what derString1 and derString1 are. - What do you expect verifs1.length and verifs2.length to be? Will you also check it? PKCS8Test.java: - Typo: s/recieved/received/g Thanks Max On 08/21/2015 07:11 AM, Amanda Jiang wrote: > Hi All, > > Please be free to review new tests for conformance testing of PKCS. > > bug: https://bugs.openjdk.java.net/browse/JDK-8048357 > webrev: http://cr.openjdk.java.net/~amjiang/8048357/webrev.01/ > > Thanks, > Amanda > From artem.smotrakov at oracle.com Fri Aug 21 20:34:09 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 21 Aug 2015 13:34:09 -0700 Subject: [9] RFR: 8048622: Enhance tests for PKCS11 keystores with NSS Message-ID: <55D78B41.3050003@oracle.com> Hello, Please review a couple of changes for PKCS11 tests: - Added a new test which checks that a keystore can't be loaded with incorrect password, found https://bugs.openjdk.java.net/browse/JDK-8134232 - Added a check that a trusted entry can be removedfrom keystore - Updated existing tests not to use random data - Updated existing tests to use try-with-resources for I/O operationswith files - Small cosmetic updates Bug: https://bugs.openjdk.java.net/browse/JDK-8048622 Webrev: http://cr.openjdk.java.net/~asmotrak/8048622/webrev.00/ Artem From alexander.v.stepanov at oracle.com Mon Aug 24 09:46:38 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Mon, 24 Aug 2015 12:46:38 +0300 Subject: RFR [9] 8133802: replace some <tt> tags (obsolete in html5) in security-libs docs In-Reply-To: <55D30F47.7030304@oracle.com> References: <55D30F47.7030304@oracle.com> Message-ID: <55DAE7FE.2080703@oracle.com> Sorry, just a reminder. Thanks, Alexander On 8/18/2015 1:56 PM, Alexander Stepanov wrote: > Hello, > > Could you please review the following fix: > http://cr.openjdk.java.net/~avstepan/8133802/webrev.00 > for > https://bugs.openjdk.java.net/browse/JDK-8133802 > > Just another portion of deprecated <tt> tags replaced with {@code } > (some <xmp> tags were replaced as well). > > Thanks, > Alexander From sean.coffey at oracle.com Mon Aug 24 12:54:25 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 24 Aug 2015 13:54:25 +0100 Subject: RFR : 8133535: Better exception messaging in Ucrypto code Message-ID: <55DB1401.70207@oracle.com> Hoping to improve some of the exception messaging that is thrown from Ucrypto code. I'm hoping to tackle other components in the security libraries on a case by case basis. Aim is to improve exception messages and capture detail for end user where possible. bug report : https://bugs.openjdk.java.net/browse/JDK-8133535 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8133535.jdk9/webrev/ -- Regards, Sean. From weijun.wang at oracle.com Mon Aug 24 13:56:57 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 24 Aug 2015 21:56:57 +0800 Subject: RFR 8056174: New APIs for jar signing Message-ID: <55DB22A9.40704@oracle.com> Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8056174/webrev.02/ A new JarSigner public API is introduced to OpenJDK. The code change chooses a two-layer implementation style, with public JarSigner/Builder in jdk.security and private JarSignerX/BuilderX in sun.security. The private side contains some unpopular options which I hope can be used to implement the jarsigner tool itself in another changeset. Some spec clarification is made since my last mail [1], including Builder#sign, JarSigner#getDigestAlg, and JarSigner#getSigAlg. In Builder, I am still using should method names (sigAlg, digestAlg, and tsa) since I think the jarsigner option names are already widely accepted. Otherwise, a name like setDigestAlgorithm seems a little unfamiliar. Thanks Max [1] http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012636.html From sean.mullan at oracle.com Mon Aug 24 14:25:10 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 24 Aug 2015 10:25:10 -0400 Subject: [9] review request for 8132786: java/security/cert/CertPathValidator/OCSP/AIACheck.java fails intermittently In-Reply-To: <DFBF2333-5326-4766-994C-2C1BF8F4F8F7@oracle.com> References: <DFBF2333-5326-4766-994C-2C1BF8F4F8F7@oracle.com> Message-ID: <55DB2946.3050505@oracle.com> Looks fine to me. --Sean On 08/19/2015 12:59 PM, Vincent Ryan wrote: > Please review this fix for an intermittently failing test. It now expects a SocketException or a SocketTimeoutException. > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8132786 > Webrev: http://cr.openjdk.java.net/~vinnie/8132786/webrev.00/ > From weijun.wang at oracle.com Mon Aug 24 14:53:07 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 24 Aug 2015 22:53:07 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <55DB22A9.40704@oracle.com> References: <55DB22A9.40704@oracle.com> Message-ID: <55DB2FD3.6030901@oracle.com> Typo, short method names. (Strange, I was typing in Linux and no auto-correct is on). --Max On 08/24/2015 09:56 PM, Weijun Wang wrote: > I am still using should method names From sean.mullan at oracle.com Mon Aug 24 19:00:19 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 24 Aug 2015 15:00:19 -0400 Subject: RFR [9] 8133802: replace some <tt> tags (obsolete in html5) in security-libs docs In-Reply-To: <55DAE7FE.2080703@oracle.com> References: <55D30F47.7030304@oracle.com> <55DAE7FE.2080703@oracle.com> Message-ID: <55DB69C3.2000306@oracle.com> On line 105 of RC5ParameterSpec, can you move the closing brace at the start of the line to the end of the previous line? Otherwise, everything else looks fine. --Sean On 08/24/2015 05:46 AM, Alexander Stepanov wrote: > Sorry, just a reminder. > > Thanks, > Alexander > > On 8/18/2015 1:56 PM, Alexander Stepanov wrote: >> Hello, >> >> Could you please review the following fix: >> http://cr.openjdk.java.net/~avstepan/8133802/webrev.00 >> for >> https://bugs.openjdk.java.net/browse/JDK-8133802 >> >> Just another portion of deprecated <tt> tags replaced with {@code } >> (some <xmp> tags were replaced as well). >> >> Thanks, >> Alexander > From jamil.j.nimeh at oracle.com Tue Aug 25 04:55:20 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 24 Aug 2015 21:55:20 -0700 Subject: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension Message-ID: <55DBF538.7070000@oracle.com> Hi all, This is a quick fix to the OCSPNonceExtension class to add a couple defensive copies to public get/set methods. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.00 Thanks, --Jamil From xuelei.fan at oracle.com Tue Aug 25 08:14:22 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 25 Aug 2015 16:14:22 +0800 Subject: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension In-Reply-To: <55DBF538.7070000@oracle.com> References: <55DBF538.7070000@oracle.com> Message-ID: <55DC23DE.1080806@oracle.com> OCSPNonceExtension.java ======================= - nonceData = (byte[])obj; + nonceData = ((byte[])obj).clone(); Do you want to check null obj? - return nonceData; + return (nonceData != null ? nonceData.clone() : null); I think you may want to enclose the "!=" operator as: + return (nonceData != null) ? nonceData.clone() : null; Xuelei On 8/25/2015 12:55 PM, Jamil Nimeh wrote: > Hi all, > > This is a quick fix to the OCSPNonceExtension class to add a couple > defensive copies to public get/set methods. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.00 > > Thanks, > --Jamil From alexander.v.stepanov at oracle.com Tue Aug 25 09:47:43 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Tue, 25 Aug 2015 12:47:43 +0300 Subject: RFR [9] 8133802: replace some <tt> tags (obsolete in html5) in security-libs docs In-Reply-To: <55DB69C3.2000306@oracle.com> References: <55D30F47.7030304@oracle.com> <55DAE7FE.2080703@oracle.com> <55DB69C3.2000306@oracle.com> Message-ID: <55DC39BF.1040800@oracle.com> Hello Sean, Thanks! Will move the brace before commit. Regards, Alexander On 8/24/2015 10:00 PM, Sean Mullan wrote: > On line 105 of RC5ParameterSpec, can you move the closing brace at the > start of the line to the end of the previous line? Otherwise, > everything else looks fine. > > --Sean > > On 08/24/2015 05:46 AM, Alexander Stepanov wrote: >> Sorry, just a reminder. >> >> Thanks, >> Alexander >> >> On 8/18/2015 1:56 PM, Alexander Stepanov wrote: >>> Hello, >>> >>> Could you please review the following fix: >>> http://cr.openjdk.java.net/~avstepan/8133802/webrev.00 >>> for >>> https://bugs.openjdk.java.net/browse/JDK-8133802 >>> >>> Just another portion of deprecated <tt> tags replaced with {@code } >>> (some <xmp> tags were replaced as well). >>> >>> Thanks, >>> Alexander >> From sean.mullan at oracle.com Tue Aug 25 13:40:41 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 25 Aug 2015 09:40:41 -0400 Subject: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension In-Reply-To: <55DC23DE.1080806@oracle.com> References: <55DBF538.7070000@oracle.com> <55DC23DE.1080806@oracle.com> Message-ID: <55DC7059.2090706@oracle.com> Is it necessary for the class to implement CertAttrSet? I realize all of the internal X.509 extensions implement that, but that was done a long time ago and not something we really want to carry forward if not needed. I think it would be cleaner not to do that as it would more easily allow you to make the class immutable, and would allow you to remove the set method. Thanks, Sean On 08/25/2015 04:14 AM, Xuelei Fan wrote: > OCSPNonceExtension.java > ======================= > - nonceData = (byte[])obj; > + nonceData = ((byte[])obj).clone(); > > Do you want to check null obj? > > - return nonceData; > + return (nonceData != null ? nonceData.clone() : null); > > I think you may want to enclose the "!=" operator as: > > + return (nonceData != null) ? nonceData.clone() : null; > > > Xuelei > > On 8/25/2015 12:55 PM, Jamil Nimeh wrote: >> Hi all, >> >> This is a quick fix to the OCSPNonceExtension class to add a couple >> defensive copies to public get/set methods. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.00 >> >> Thanks, >> --Jamil > From jamil.j.nimeh at oracle.com Tue Aug 25 15:11:25 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 25 Aug 2015 08:11:25 -0700 Subject: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension In-Reply-To: <55DC7059.2090706@oracle.com> References: <55DBF538.7070000@oracle.com> <55DC23DE.1080806@oracle.com> <55DC7059.2090706@oracle.com> Message-ID: <55DC859D.2090704@oracle.com> Hi Sean, Yes, I was just following Extension convention in terms of implementing CertAttrSet. Within sun.security.x509, X509CertInfo uses the set methods from other objects implementing CertAttrSet. But OCSPNonceExtension really isn't a certificate attribute so it probably doesn't need to bring this interface in. I'll refactor this and alter the tests to match. --Jamil On 08/25/2015 06:40 AM, Sean Mullan wrote: > Is it necessary for the class to implement CertAttrSet? I realize all > of the internal X.509 extensions implement that, but that was done a > long time ago and not something we really want to carry forward if not > needed. I think it would be cleaner not to do that as it would more > easily allow you to make the class immutable, and would allow you to > remove the set method. > > Thanks, > Sean > > On 08/25/2015 04:14 AM, Xuelei Fan wrote: >> OCSPNonceExtension.java >> ======================= >> - nonceData = (byte[])obj; >> + nonceData = ((byte[])obj).clone(); >> >> Do you want to check null obj? >> >> - return nonceData; >> + return (nonceData != null ? nonceData.clone() : null); >> >> I think you may want to enclose the "!=" operator as: >> >> + return (nonceData != null) ? nonceData.clone() : null; >> >> >> Xuelei >> >> On 8/25/2015 12:55 PM, Jamil Nimeh wrote: >>> Hi all, >>> >>> This is a quick fix to the OCSPNonceExtension class to add a couple >>> defensive copies to public get/set methods. >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.00 >>> >>> Thanks, >>> --Jamil >> From sean.mullan at oracle.com Tue Aug 25 17:09:10 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 25 Aug 2015 13:09:10 -0400 Subject: [9] RFR: 8049237: Need new tests for X509V3 certificates In-Reply-To: <55D3D587.9070603@oracle.com> References: <55A5B948.5030400@oracle.com> <55D3D587.9070603@oracle.com> Message-ID: <55DCA136.30007@oracle.com> On 08/18/2015 09:01 PM, Xuelei Fan wrote: > Hi Rajan, > > Sorry for the delay. The code looks fine to me. I was just wondering, > what's the purpose for the V1toV3Cert.java test? Is it practice behavior? I had the same question. I would remove this test as it seems like a obscure case not supported by any of our tools/APIs. --Sean > Thanks, > Xuelei > > On 7/15/2015 9:37 AM, Rajan Halade wrote: >> May I request you to review two new tests added. V1toV3Cert tries to >> covert a existing V1 certificate to V3 and V3Certificate test tries to >> generate V3 certificate with different extensions. >> >> Webrev: http://cr.openjdk.java.net/~rhalade/8049237/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8049237 >> >> Thanks, >> Rajan > From rajan.halade at oracle.com Tue Aug 25 18:30:37 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 25 Aug 2015 11:30:37 -0700 Subject: [9] RFR: 8049237: Need new tests for X509V3 certificates In-Reply-To: <55DCA136.30007@oracle.com> References: <55A5B948.5030400@oracle.com> <55D3D587.9070603@oracle.com> <55DCA136.30007@oracle.com> Message-ID: <55DCB44D.6000204@oracle.com> On 8/25/15 10:09 AM, Sean Mullan wrote: > On 08/18/2015 09:01 PM, Xuelei Fan wrote: >> Hi Rajan, >> >> Sorry for the delay. The code looks fine to me. I was just wondering, >> what's the purpose for the V1toV3Cert.java test? Is it practice >> behavior? > > I had the same question. I would remove this test as it seems like a > obscure case not supported by any of our tools/APIs. This test tries to convert V1 to V3 certificate. Ok, I removed this test case. http://cr.openjdk.java.net/~rhalade/8049237/webrev.01/ Thanks, Rajan > > --Sean > >> Thanks, >> Xuelei >> >> On 7/15/2015 9:37 AM, Rajan Halade wrote: >>> May I request you to review two new tests added. V1toV3Cert tries to >>> covert a existing V1 certificate to V3 and V3Certificate test tries to >>> generate V3 certificate with different extensions. >>> >>> Webrev: http://cr.openjdk.java.net/~rhalade/8049237/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049237 >>> >>> Thanks, >>> Rajan >> From rajan.halade at oracle.com Tue Aug 25 20:10:17 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 25 Aug 2015 13:10:17 -0700 Subject: [9] RFR: 8048601: Tests for JCE crypto ciphers In-Reply-To: <55D66095.4090309@oracle.com> References: <55A57096.10700@oracle.com> <55D50580.8090402@oracle.com> <55D66095.4090309@oracle.com> Message-ID: <55DCCBA9.2090105@oracle.com> Hi Valerie, Thanks for comments! I have fixed all of them. http://cr.openjdk.java.net/~rhalade/8048601/webrev.01/ - Rajan On 8/20/15 4:19 PM, Valerie Peng wrote: > Rajan, > > Here are some comments for the other half of the webrev: > TestCipherTextLength.java > 1) line 82 and 85, why TEXT_LEN is needed? I don't find any usage of > it inside runAll(..) method? removed. > 2) the names here are a bit too similar, e.g. PBEWrapper, > PBECipherWrapper, AESPBEWrapper. The individual subclasses aren't that > big, why not make them inner static classes of the parent class? No > need to repeat the Wrapper and PBE in the subclass names. To match > your other wrapper class DESCipherWrapper, perhaps you can rename the > PBE counterpart to something like: > > PBECipherWrapper (parent) with subclasses (defined statically > inside PBECipherWrapper) named PBKDF2, AES, and Legacy (these are > PKCS#5 v1.5 defined algorithms). fixed, thanks! > > PBKDF2Wrapper.java > 1) typo on line 43 and 52 - should be T_R_ANSFORMATION fixed > 2) Instead of "PKDF2_DEFAULT_KEY_LEN" (typo? I think u meant PBKDF2), > it should really be CIPHER_KEY_SIZE since the purpose here is to > generate keys for the Cipher object. renamed the variable. > 3) the key that you generated on line 57 can be viewed as an > intermediate key. You could have moved the processing in > initCipher(...) method into the constructor and store the resulting > cipher key into 'key'. For example: > SecretKey derivedKey = keyFactory.generateSecret(pbeKeySpec); > key = new SecretKeySpec(derivedKey.getEncoded(), KEY_ALGORITHM); key is generated in consturctor. > > Thanks, > Valerie > > On 8/19/2015 3:38 PM, Valerie Peng wrote: >> Rajan, >> >> TestCipher.java >> 1) this class is used as the base for many algorithm, modes, and >> paddings. But then it hardcodes some values or parameter types which >> may not work against some algorithms, e.g. IvParameterSpec with >> 8-byte value, padding length being 8 bytes. PAD_LEN=8 vs >> PAD_BYTES=16, is this difference intentional? >> Seems to me that this TestCipher class only works against Ciphers w/ >> 8-byte blocks and uses iv. I think it's clearer to have a constant >> named BLKSIZE instead of just 8. Yes. I have changed iv to be final variable now initialized in constructor. >> 2) Also, u don't need to repeatedly generate random bytes for input >> data, IV, etc. The input data can be generated once outside of loop. >> As for the parameters, either u can just let the cipher object >> generates it or grab the IV values from whatever data that u have >> already, e.g. certain part of the input data. fixed, no need for random anymore. >> 2) input length is always 800. Would be nice to have a comment >> stating the requirement, e.g. multiple of blocks in order to work >> against ciphers w/ NoPadding >> 3) line 54, Would be nice to clarify that the range of tested key >> size is from MINIMUM_KEY_SIZE to what returned by >> Cipher.getMaxAllowedKeyLength(ALGORITHM) with the increment of >> KEYCUTTER. added comments. >> 4) line 66, keyStrength is better phrased as variousKeySize in my >> opinion. renamed to variousKeySize. >> 5) MINIMUM_KEY_SIZE and KEYCUTTER should be algorithm specific. It'd >> be clearer to explicitly list out the algorithms which works against >> the the hardcoded values for the sake of maintenance. added comments. >> 6) It looks to me that String[] modes and String[] paddings could be >> moved to runAll(). This seems more consistent with the signature of >> runTest() where mode and padding are again specified here. I left it as is and changed runTest to private method. Either is ok with me. Thanks, Rajan >> >> Will send u comments regarding the TestLength ones in a separate email. >> Thanks, >> Valerie >> >> On 7/14/2015 1:27 PM, Rajan Halade wrote: >>> May I request you to review new tests added to check Cipher >>> operations with different algorithms and modes. >>> >>> Webrev: http://cr.openjdk.java.net/~rhalade/8048601/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048601 >>> >>> Thanks, >>> Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150825/3bfbe7fc/attachment-0001.html> From weijun.wang at oracle.com Wed Aug 26 07:57:49 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 26 Aug 2015 15:57:49 +0800 Subject: RFR 8077670: sun/security/krb5/auto/MaxRetries.java may fail with BindException Message-ID: <55DD717D.3080302@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/8077670/webrev.00/ The test now tries to find an available port in a loop. Thanks Max From chris.hegarty at oracle.com Wed Aug 26 08:05:38 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 26 Aug 2015 09:05:38 +0100 Subject: RFR 8077670: sun/security/krb5/auto/MaxRetries.java may fail with BindException In-Reply-To: <55DD717D.3080302@oracle.com> References: <55DD717D.3080302@oracle.com> Message-ID: <55DD7352.1030604@oracle.com> Hi Max, I don't know the specifics of this test, but can it use the ephemeral port pattern, ds = new DatagramSocket(); ds.getLocalPort()? Rather than looping. -Chris. On 26/08/15 08:57, Weijun Wang wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/8077670/webrev.00/ > > The test now tries to find an available port in a loop. > > Thanks > Max From weijun.wang at oracle.com Wed Aug 26 14:11:58 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 26 Aug 2015 22:11:58 +0800 Subject: RFR 8077670: sun/security/krb5/auto/MaxRetries.java may fail with BindException In-Reply-To: <55DD7352.1030604@oracle.com> References: <55DD717D.3080302@oracle.com> <55DD7352.1030604@oracle.com> Message-ID: <55DDC92E.6020209@oracle.com> Hi Chris I don't know about that method. Will try. This test is trying to start a UDP server that does nothing so that its client receives neither a PortUnreachableException nor a valid reply and can only timeout. Thanks Max On 08/26/2015 04:05 PM, Chris Hegarty wrote: > Hi Max, > > I don't know the specifics of this test, but can it use the ephemeral > port pattern, ds = new DatagramSocket(); ds.getLocalPort()? Rather than > looping. > > -Chris. > > On 26/08/15 08:57, Weijun Wang wrote: >> Please take a look at >> >> http://cr.openjdk.java.net/~weijun/8077670/webrev.00/ >> >> The test now tries to find an available port in a loop. >> >> Thanks >> Max From christoph.langer at sap.com Wed Aug 26 14:22:34 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Aug 2015 14:22:34 +0000 Subject: Check for potential buffer overflow in ecdecode.c ?? Message-ID: <0DFD2E72402C9243A8630A7759B27E4338EF5377@DEWDFEMB12B.global.corp.sap> Hi, when running coverity checks on src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c we had a finding that potentially the buffer "genenc" in function "gf_populate_params" could be exceeded as the length of input strings for the strcat operations is not checked. A check to satisfy coverity could look like: http://cr.openjdk.java.net/~goetz/webrevs/ecdecode-strlen/webrev.01/ However, I'm not sure if that is really valuable. The data used for the strcat operations is defined rather statically in ecl-curve.h and as of now the buffer would not be exceeded in any case. Any opinions about this check? Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150826/391fe59f/attachment.html> From sean.mullan at oracle.com Wed Aug 26 15:39:44 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 26 Aug 2015 11:39:44 -0400 Subject: [9] RFR: 8049237: Need new tests for X509V3 certificates In-Reply-To: <55DCB44D.6000204@oracle.com> References: <55A5B948.5030400@oracle.com> <55D3D587.9070603@oracle.com> <55DCA136.30007@oracle.com> <55DCB44D.6000204@oracle.com> Message-ID: <55DDDDC0.5070409@oracle.com> This looks ok now, although I would probably eliminate the tests for SHA-1 and bump up the keysize to 2048, so that this test won't have to be updated when those algorithms/keysizes are constrained in the future. --Sean On 08/25/2015 02:30 PM, Rajan Halade wrote: > > > On 8/25/15 10:09 AM, Sean Mullan wrote: >> On 08/18/2015 09:01 PM, Xuelei Fan wrote: >>> Hi Rajan, >>> >>> Sorry for the delay. The code looks fine to me. I was just wondering, >>> what's the purpose for the V1toV3Cert.java test? Is it practice >>> behavior? >> >> I had the same question. I would remove this test as it seems like a >> obscure case not supported by any of our tools/APIs. > This test tries to convert V1 to V3 certificate. Ok, I removed this test > case. > > http://cr.openjdk.java.net/~rhalade/8049237/webrev.01/ > > Thanks, > Rajan >> >> --Sean >> >>> Thanks, >>> Xuelei >>> >>> On 7/15/2015 9:37 AM, Rajan Halade wrote: >>>> May I request you to review two new tests added. V1toV3Cert tries to >>>> covert a existing V1 certificate to V3 and V3Certificate test tries to >>>> generate V3 certificate with different extensions. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rhalade/8049237/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049237 >>>> >>>> Thanks, >>>> Rajan >>> > From weijun.wang at oracle.com Wed Aug 26 15:56:42 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 26 Aug 2015 23:56:42 +0800 Subject: RFR 8077670: sun/security/krb5/auto/MaxRetries.java may fail with BindException In-Reply-To: <55DDC92E.6020209@oracle.com> References: <55DD717D.3080302@oracle.com> <55DD7352.1030604@oracle.com> <55DDC92E.6020209@oracle.com> Message-ID: <55DDE1BA.7040401@oracle.com> Great it works for me. Webrev updated at http://cr.openjdk.java.net/~weijun/8077670/webrev.01/. Thanks Max On 08/26/2015 10:11 PM, Weijun Wang wrote: > Hi Chris > > I don't know about that method. Will try. > > This test is trying to start a UDP server that does nothing so that its > client receives neither a PortUnreachableException nor a valid reply and > can only timeout. > > Thanks > Max > > On 08/26/2015 04:05 PM, Chris Hegarty wrote: >> Hi Max, >> >> I don't know the specifics of this test, but can it use the ephemeral >> port pattern, ds = new DatagramSocket(); ds.getLocalPort()? Rather than >> looping. >> >> -Chris. >> >> On 26/08/15 08:57, Weijun Wang wrote: >>> Please take a look at >>> >>> http://cr.openjdk.java.net/~weijun/8077670/webrev.00/ >>> >>> The test now tries to find an available port in a loop. >>> >>> Thanks >>> Max From vincent.x.ryan at oracle.com Wed Aug 26 16:34:53 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 26 Aug 2015 17:34:53 +0100 Subject: [9] Request for review 8134112: api/java_security/KeyStore/index.html#GetInstance2Tests[getInstanceIOE2, getInstanceIOE3] still fail after JDK-8130850 is fixed in b77 Message-ID: <1A477FDB-65A7-4571-BE7D-2E3C497DA7AA@oracle.com> Please review this change to the KeyStore.getInstance(File,LoadStoreParameter) method to correctly handle its LoadStoreParameter argument. It now extracts the embedded password before calling the KeyStore.load(InputStream,char[]) method. This fix corrects a JCK test that had been failing. Thanks. Webrev: http://cr.openjdk.java.net/~vinnie/8134112/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8134112 From chris.hegarty at oracle.com Wed Aug 26 20:03:44 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 26 Aug 2015 21:03:44 +0100 Subject: RFR 8077670: sun/security/krb5/auto/MaxRetries.java may fail with BindException In-Reply-To: <55DDE1BA.7040401@oracle.com> References: <55DD717D.3080302@oracle.com> <55DD7352.1030604@oracle.com> <55DDC92E.6020209@oracle.com> <55DDE1BA.7040401@oracle.com> Message-ID: <7A0867BE-33BD-42FB-9B6A-A7748931E20E@oracle.com> > On 26 Aug 2015, at 16:56, Weijun Wang <weijun.wang at oracle.com> wrote: > > Great it works for me. > > Webrev updated at http://cr.openjdk.java.net/~weijun/8077670/webrev.01/. Looks good to me Max. -Chris. > Thanks > Max > > On 08/26/2015 10:11 PM, Weijun Wang wrote: >> Hi Chris >> >> I don't know about that method. Will try. >> >> This test is trying to start a UDP server that does nothing so that its >> client receives neither a PortUnreachableException nor a valid reply and >> can only timeout. >> >> Thanks >> Max >> >> On 08/26/2015 04:05 PM, Chris Hegarty wrote: >>> Hi Max, >>> >>> I don't know the specifics of this test, but can it use the ephemeral >>> port pattern, ds = new DatagramSocket(); ds.getLocalPort()? Rather than >>> looping. >>> >>> -Chris. >>> >>> On 26/08/15 08:57, Weijun Wang wrote: >>>> Please take a look at >>>> >>>> http://cr.openjdk.java.net/~weijun/8077670/webrev.00/ >>>> >>>> The test now tries to find an available port in a loop. >>>> >>>> Thanks >>>> Max From rajan.halade at oracle.com Wed Aug 26 23:16:23 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 26 Aug 2015 16:16:23 -0700 Subject: [9] RFR: 8049237: Need new tests for X509V3 certificates In-Reply-To: <55DDDDC0.5070409@oracle.com> References: <55A5B948.5030400@oracle.com> <55D3D587.9070603@oracle.com> <55DCA136.30007@oracle.com> <55DCB44D.6000204@oracle.com> <55DDDDC0.5070409@oracle.com> Message-ID: <55DE48C7.20008@oracle.com> Hi Sean, On 8/26/15 8:39 AM, Sean Mullan wrote: > This looks ok now, although I would probably eliminate the tests for > SHA-1 and bump up the keysize to 2048, so that this test won't have to > be updated when those algorithms/keysizes are constrained in the future. I would take up other enhancements later. For now, I have updated test to reset jdk.tls.disabledAlgorithms to remove constraints. http://cr.openjdk.java.net/~rhalade/8049237/webrev.02 Thanks, Rajan > > --Sean > > On 08/25/2015 02:30 PM, Rajan Halade wrote: >> >> >> On 8/25/15 10:09 AM, Sean Mullan wrote: >>> On 08/18/2015 09:01 PM, Xuelei Fan wrote: >>>> Hi Rajan, >>>> >>>> Sorry for the delay. The code looks fine to me. I was just >>>> wondering, >>>> what's the purpose for the V1toV3Cert.java test? Is it practice >>>> behavior? >>> >>> I had the same question. I would remove this test as it seems like a >>> obscure case not supported by any of our tools/APIs. >> This test tries to convert V1 to V3 certificate. Ok, I removed this test >> case. >> >> http://cr.openjdk.java.net/~rhalade/8049237/webrev.01/ >> >> Thanks, >> Rajan >>> >>> --Sean >>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 7/15/2015 9:37 AM, Rajan Halade wrote: >>>>> May I request you to review two new tests added. V1toV3Cert tries to >>>>> covert a existing V1 certificate to V3 and V3Certificate test >>>>> tries to >>>>> generate V3 certificate with different extensions. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rhalade/8049237/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049237 >>>>> >>>>> Thanks, >>>>> Rajan >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150826/b3df472e/attachment.html> From weijun.wang at oracle.com Thu Aug 27 00:29:41 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 27 Aug 2015 08:29:41 +0800 Subject: RFR 8134555: The InquireSecContextPermissionCheck.java test was mistakenly removed Message-ID: <55DE59F5.4090000@oracle.com> Please review http://cr.openjdk.java.net/~weijun/8134555/webrev.00/ The test was mistakenly removed in a previous changeset. Restored now. Thanks Max From sean.mullan at oracle.com Thu Aug 27 11:43:51 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Aug 2015 07:43:51 -0400 Subject: [9] RFR: 8049237: Need new tests for X509V3 certificates In-Reply-To: <55DE48C7.20008@oracle.com> References: <55A5B948.5030400@oracle.com> <55D3D587.9070603@oracle.com> <55DCA136.30007@oracle.com> <55DCB44D.6000204@oracle.com> <55DDDDC0.5070409@oracle.com> <55DE48C7.20008@oracle.com> Message-ID: <55DEF7F7.5030203@oracle.com> On 08/26/2015 07:16 PM, Rajan Halade wrote: > Hi Sean, > > On 8/26/15 8:39 AM, Sean Mullan wrote: >> This looks ok now, although I would probably eliminate the tests for >> SHA-1 and bump up the keysize to 2048, so that this test won't have to >> be updated when those algorithms/keysizes are constrained in the future. > I would take up other enhancements later. For now, I have updated test > to reset jdk.tls.disabledAlgorithms to remove constraints. > > http://cr.openjdk.java.net/~rhalade/8049237/webrev.02 I don't think the different signature variants buy you much, since what you are mainly testing here is the ability to parse the created certificate without errors. I would simplify the test by just having a single test for each key type. --Sean > > Thanks, > Rajan >> >> --Sean >> >> On 08/25/2015 02:30 PM, Rajan Halade wrote: >>> >>> >>> On 8/25/15 10:09 AM, Sean Mullan wrote: >>>> On 08/18/2015 09:01 PM, Xuelei Fan wrote: >>>>> Hi Rajan, >>>>> >>>>> Sorry for the delay. The code looks fine to me. I was just >>>>> wondering, >>>>> what's the purpose for the V1toV3Cert.java test? Is it practice >>>>> behavior? >>>> >>>> I had the same question. I would remove this test as it seems like a >>>> obscure case not supported by any of our tools/APIs. >>> This test tries to convert V1 to V3 certificate. Ok, I removed this test >>> case. >>> >>> http://cr.openjdk.java.net/~rhalade/8049237/webrev.01/ >>> >>> Thanks, >>> Rajan >>>> >>>> --Sean >>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 7/15/2015 9:37 AM, Rajan Halade wrote: >>>>>> May I request you to review two new tests added. V1toV3Cert tries to >>>>>> covert a existing V1 certificate to V3 and V3Certificate test >>>>>> tries to >>>>>> generate V3 certificate with different extensions. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rhalade/8049237/webrev.00/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049237 >>>>>> >>>>>> Thanks, >>>>>> Rajan >>>>> >>> > From aph at redhat.com Thu Aug 27 15:51:45 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 27 Aug 2015 16:51:45 +0100 Subject: GCM performance and Unsafe byte array accesses Message-ID: <55DF3211.3060206@redhat.com> I've been looking at the performance of AES/GCM. The profile is quite surprising: samples cum. samples % cum. % symbol name 476009 476009 36.7033 36.7033 aescrypt_encryptBlock 297239 773248 22.9190 59.6224 ghash_processBlocks 195334 968582 15.0615 74.6839 int com.sun.crypto.provider.GCTR.doFinal(byte[], int, int, byte[], int) I would have expected aescrypt_encryptBlock and ghash_processBlocks to be very high, but that GCTR.doFinal is so high is rather surprising: all it has to do is increment a counter, call aescrypt_encryptBlock, and xor the result with the plaintext. The problem seems to be due to byte accesses in GCTR.doFinal() and GaloisCounterMode.update(). Earlier this year I wrote a bunch of new Unsafe.get/put-XX-Unaligned methods, and these are ideal for bulk accesses to byte arrays. So, as an experiment I wrote some methods to do array accesses and used them to speed up GCM, with this result: 492274 492274 40.8856 40.8856 13256.jo aescrypt_encryptBlock 298185 790459 24.7656 65.6512 13256.jo ghash_processBlocks 86325 876784 7.1697 72.8209 13256.jo int com.sun.crypto.provider.GCTR.update(byte[], int, int, byte[], int) GCTR.update() is twice as fast as it was, and overall the performance of AES/GCM is 10% better. The changes to the GCM code are quite minor: diff -r 6940407d544a src/java.base/share/classes/com/sun/crypto/provider/GCTR.java --- a/src/java.base/share/classes/com/sun/crypto/provider/GCTR.java Thu Aug 20 07:36:37 2015 -0700 +++ b/src/java.base/share/classes/com/sun/crypto/provider/GCTR.java Thu Aug 27 16:17:25 2015 +0100 @@ -94,11 +97,12 @@ int numOfCompleteBlocks = inLen / AES_BLOCK_SIZE; for (int i = 0; i < numOfCompleteBlocks; i++) { aes.encryptBlock(counter, 0, encryptedCntr, 0); - for (int n = 0; n < AES_BLOCK_SIZE; n++) { - int index = (i * AES_BLOCK_SIZE + n); - out[outOfs + index] = - (byte) ((in[inOfs + index] ^ encryptedCntr[n])); - } + int index = i * AES_BLOCK_SIZE; + ByteArrays.putLongs(out, outOfs + index, + (ByteArrays.getLong(in, inOfs + index + 0) ^ + ByteArrays.getLong(encryptedCntr, 0)), + (ByteArrays.getLong(in, inOfs + index + 8) ^ + ByteArrays.getLong(encryptedCntr, 8))); GaloisCounterMode.increment32(counter); } return inLen; diff -r 6940407d544a src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java --- a/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java Thu Aug 20 07:36:37 2015 -0700 +++ b/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java Thu Aug 27 16:17:25 2015 +0100 @@ -82,11 +82,8 @@ // should never happen throw new ProviderException("Illegal counter block length"); } - // start from last byte and only go over 4 bytes, i.e. total 32 bits - int n = value.length - 1; - while ((n >= value.length - 4) && (++value[n] == 0)) { - n--; - } + int counter = ByteArrays.getInt(value, value.length - 4, true); + ByteArrays.putInt(value, value.length - 4, counter + 1, true); } // ivLen in bits I've attached the full diff. So, here's my question: there are many places over the crypto code base where we could take advantage of this. Do you think it makes sense to make changes like this? I can't see any major disadvantages, and it's a considerable performance improvement. Andrew. -------------- next part -------------- diff -r 6940407d544a src/java.base/share/classes/com/sun/crypto/provider/ByteArrays.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/java.base/share/classes/com/sun/crypto/provider/ByteArrays.java Thu Aug 27 16:47:27 2015 +0100 @@ -0,0 +1,110 @@ +/* + * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +package com.sun.crypto.provider; + +import sun.misc.Unsafe; + +final class ByteArrays { + + private static final Unsafe UNSAFE = Unsafe.getUnsafe(); + + static final private int LONG_SIZE = 8; + static final private int INT_SIZE = 4; + static final private int SHORT_SIZE = 2; + + static final private long BASE_OFFSET = Unsafe.ARRAY_BYTE_BASE_OFFSET; + + static final private void checkIndex(int i, int nb, int limit) { + if ((i < 0) || (nb > limit - i)) + throw new ArrayIndexOutOfBoundsException(i); + } + + static long getLong(byte[] a, int index) { + checkIndex(index, LONG_SIZE, a.length); + return UNSAFE.getLongUnaligned(a, BASE_OFFSET + index); + } + + static int getInt(byte[] a, int index) { + checkIndex(index, INT_SIZE, a.length); + return UNSAFE.getIntUnaligned(a, BASE_OFFSET + index); + } + + static short getShort(byte[] a, int index) { + checkIndex(index, SHORT_SIZE, a.length); + return UNSAFE.getShortUnaligned(a, BASE_OFFSET + index); + } + + static void putLong(byte[] a, int index, long value) { + checkIndex(index, LONG_SIZE, a.length); + UNSAFE.putLongUnaligned(a, BASE_OFFSET + index, value); + } + + static void putLongs(byte[] a, int index, long value0, long value1) { + checkIndex(index, LONG_SIZE * 2, a.length); + UNSAFE.putLongUnaligned(a, BASE_OFFSET + index, value0); + UNSAFE.putLongUnaligned(a, BASE_OFFSET + index + LONG_SIZE, value1); + } + + static void putInt(byte[] a, int index, int value) { + checkIndex(index, INT_SIZE, a.length); + UNSAFE.putIntUnaligned(a, BASE_OFFSET + index, value); + } + + static void putShort(byte[] a, int index, short value) { + checkIndex(index, SHORT_SIZE, a.length); + UNSAFE.putShortUnaligned(a, BASE_OFFSET + index, value); + } + + static long getLong(byte[] a, int index, boolean bigEndian) { + checkIndex(index, LONG_SIZE, a.length); + return UNSAFE.getLongUnaligned(a, BASE_OFFSET + index, bigEndian); + } + + static int getInt(byte[] a, int index, boolean bigEndian) { + checkIndex(index, INT_SIZE, a.length); + return UNSAFE.getIntUnaligned(a, BASE_OFFSET + index, bigEndian); + } + + static short getShort(byte[] a, int index, boolean bigEndian) { + checkIndex(index, SHORT_SIZE, a.length); + return UNSAFE.getShortUnaligned(a, BASE_OFFSET + index, bigEndian); + } + + static void putLong(byte[] a, int index, long value, boolean bigEndian) { + checkIndex(index, LONG_SIZE, a.length); + UNSAFE.putLongUnaligned(a, BASE_OFFSET + index, value, bigEndian); + } + + static void putInt(byte[] a, int index, int value, boolean bigEndian) { + checkIndex(index, INT_SIZE, a.length); + UNSAFE.putIntUnaligned(a, BASE_OFFSET + index, value, bigEndian); + } + + static void putShort(byte[] a, int index, short value, boolean bigEndian) { + checkIndex(index, SHORT_SIZE, a.length); + UNSAFE.putShortUnaligned(a, BASE_OFFSET + index, value, bigEndian); + } +} \ No newline at end of file diff -r 6940407d544a src/java.base/share/classes/com/sun/crypto/provider/GCTR.java --- a/src/java.base/share/classes/com/sun/crypto/provider/GCTR.java Thu Aug 20 07:36:37 2015 -0700 +++ b/src/java.base/share/classes/com/sun/crypto/provider/GCTR.java Thu Aug 27 16:47:27 2015 +0100 @@ -32,6 +32,7 @@ import java.security.*; import javax.crypto.*; import static com.sun.crypto.provider.AESConstants.AES_BLOCK_SIZE; +import sun.misc.Unsafe; /** * This class represents the GCTR function defined in NIST 800-38D @@ -66,6 +67,8 @@ // needed for save/restore calls private byte[] counterSave = null; + private static final Unsafe UNSAFE = Unsafe.getUnsafe(); + // NOTE: cipher should already be initialized GCTR(SymmetricCipher cipher, byte[] initialCounterBlk) { this.aes = cipher; @@ -94,11 +97,12 @@ int numOfCompleteBlocks = inLen / AES_BLOCK_SIZE; for (int i = 0; i < numOfCompleteBlocks; i++) { aes.encryptBlock(counter, 0, encryptedCntr, 0); - for (int n = 0; n < AES_BLOCK_SIZE; n++) { - int index = (i * AES_BLOCK_SIZE + n); - out[outOfs + index] = - (byte) ((in[inOfs + index] ^ encryptedCntr[n])); - } + int index = i * AES_BLOCK_SIZE; + ByteArrays.putLongs(out, outOfs + index, + (ByteArrays.getLong(in, inOfs + index + 0) ^ + ByteArrays.getLong(encryptedCntr, 0)), + (ByteArrays.getLong(in, inOfs + index + 8) ^ + ByteArrays.getLong(encryptedCntr, 8))); GaloisCounterMode.increment32(counter); } return inLen; diff -r 6940407d544a src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java --- a/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java Thu Aug 20 07:36:37 2015 -0700 +++ b/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java Thu Aug 27 16:47:27 2015 +0100 @@ -82,11 +82,8 @@ // should never happen throw new ProviderException("Illegal counter block length"); } - // start from last byte and only go over 4 bytes, i.e. total 32 bits - int n = value.length - 1; - while ((n >= value.length - 4) && (++value[n] == 0)) { - n--; - } + int counter = ByteArrays.getInt(value, value.length - 4, true); + ByteArrays.putInt(value, value.length - 4, counter + 1, true); } // ivLen in bits From peter.brunet at oracle.com Thu Aug 27 21:02:20 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 27 Aug 2015 16:02:20 -0500 Subject: RfR JDK-8134456 java/lang/SecurityManager/CheckPackageAccess.java failing on several platforms Message-ID: <55DF7ADC.7090808@oracle.com> Please review a patch for a test change which is needed to fix an issue caused by JDK-8051626. Tier 1 tests are being impacted. http://cr.openjdk.java.net/~ptbrunet/JDK-8134456/webrev.00/ Pete From sean.mullan at oracle.com Thu Aug 27 21:50:01 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Aug 2015 17:50:01 -0400 Subject: RfR JDK-8134456 java/lang/SecurityManager/CheckPackageAccess.java failing on several platforms In-Reply-To: <55DF7ADC.7090808@oracle.com> References: <55DF7ADC.7090808@oracle.com> Message-ID: <55DF8609.9020307@oracle.com> This looks good to me, if the JPRT results are good. However, does this also fix the failure in CheckPackageMatching? I would have expected you needed an additional fix - see my subsequent comment: https://bugs.openjdk.java.net/browse/JDK-8134456?focusedCommentId=13837407&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837407 Thanks, Sean On 08/27/2015 05:02 PM, Pete Brunet wrote: > Please review a patch for a test change which is needed to fix an issue > caused by JDK-8051626. Tier 1 tests are being impacted. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8134456/webrev.00/ > > Pete > From peter.brunet at oracle.com Thu Aug 27 21:59:58 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 27 Aug 2015 16:59:58 -0500 Subject: RfR JDK-8134456 java/lang/SecurityManager/CheckPackageAccess.java failing on several platforms In-Reply-To: <55DF8609.9020307@oracle.com> References: <55DF7ADC.7090808@oracle.com> <55DF8609.9020307@oracle.com> Message-ID: <55DF885E.5080108@oracle.com> Hi Sean, I might need to make a change but this is the JTREG output from my local run jtreg -jdk:./build/windows-x86_64-normal-server-release/images/jdk ./jdk/test/java/lang/SecurityManager/ Execution successful java/lang/SecurityManager/CheckPackageAccess.java: Make sure all restricted packages listed in the package.access property in the java.security file are blocked java/lang/SecurityManager/CheckPackageMatching.java: Check the matching implemented by SecurityManager.checkPackageAccess java/lang/SecurityManager/CheckSecurityProvider.java: Consolidate java.security files into one file with modifications java/lang/SecurityManager/NoAWT.java: Sanity check that SecurityManager methods that used to check AWTPermission now check for AllPermission so it looks like there are no problems. What do you think? I'll report back once my JPRT run finishes. Pete On 8/27/15 4:50 PM, Sean Mullan wrote: > This looks good to me, if the JPRT results are good. However, does > this also fix the failure in CheckPackageMatching? I would have > expected you needed an additional fix - see my subsequent comment: > > https://bugs.openjdk.java.net/browse/JDK-8134456?focusedCommentId=13837407&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837407 > > > Thanks, > Sean > > On 08/27/2015 05:02 PM, Pete Brunet wrote: >> Please review a patch for a test change which is needed to fix an issue >> caused by JDK-8051626. Tier 1 tests are being impacted. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8134456/webrev.00/ >> >> Pete >> From peter.brunet at oracle.com Thu Aug 27 23:49:57 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 27 Aug 2015 18:49:57 -0500 Subject: RfR JDK-8134456 java/lang/SecurityManager/CheckPackageAccess.java failing on several platforms In-Reply-To: <55DF885E.5080108@oracle.com> References: <55DF7ADC.7090808@oracle.com> <55DF8609.9020307@oracle.com> <55DF885E.5080108@oracle.com> Message-ID: <55DFA225.2090900@oracle.com> JPRT jdk_lang tests ran clean, 7 builds passed, 8 tests passed. http://scaaa637.us.oracle.com//archive/2015/08/2015-08-27-204226.pbrunet.dev command line: jprt submit -stree . -email peter.brunet at oracle.com -c JDK-8134456 -buildenv SKIP_BOOT_CYCLE=false -noqa -ot '.*product.*' -onlytests '.*jdk_lang' Pete On 8/27/15 4:59 PM, Pete Brunet wrote: > Hi Sean, I might need to make a change but this is the JTREG output from > my local run > jtreg -jdk:./build/windows-x86_64-normal-server-release/images/jdk > ./jdk/test/java/lang/SecurityManager/ > > Execution successful > > java/lang/SecurityManager/CheckPackageAccess.java: Make sure all > restricted packages listed in the package.access property in the > java.security file are blocked > java/lang/SecurityManager/CheckPackageMatching.java: Check the matching > implemented by SecurityManager.checkPackageAccess > java/lang/SecurityManager/CheckSecurityProvider.java: Consolidate > java.security files into one file with modifications > java/lang/SecurityManager/NoAWT.java: Sanity check that SecurityManager > methods that used to check AWTPermission now check for AllPermission > > so it looks like there are no problems. What do you think? > > I'll report back once my JPRT run finishes. > > Pete > > On 8/27/15 4:50 PM, Sean Mullan wrote: >> This looks good to me, if the JPRT results are good. However, does >> this also fix the failure in CheckPackageMatching? I would have >> expected you needed an additional fix - see my subsequent comment: >> >> https://bugs.openjdk.java.net/browse/JDK-8134456?focusedCommentId=13837407&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837407 >> >> >> Thanks, >> Sean >> >> On 08/27/2015 05:02 PM, Pete Brunet wrote: >>> Please review a patch for a test change which is needed to fix an issue >>> caused by JDK-8051626. Tier 1 tests are being impacted. >>> >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134456/webrev.00/ >>> >>> Pete >>> From rajan.halade at oracle.com Thu Aug 27 23:52:02 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 27 Aug 2015 16:52:02 -0700 Subject: [9] RFR: 8049237: Need new tests for X509V3 certificates In-Reply-To: <55DEF7F7.5030203@oracle.com> References: <55A5B948.5030400@oracle.com> <55D3D587.9070603@oracle.com> <55DCA136.30007@oracle.com> <55DCB44D.6000204@oracle.com> <55DDDDC0.5070409@oracle.com> <55DE48C7.20008@oracle.com> <55DEF7F7.5030203@oracle.com> Message-ID: <55DFA2A2.7010309@oracle.com> On 8/27/15 4:43 AM, Sean Mullan wrote: > I don't think the different signature variants buy you much, since > what you are mainly testing here is the ability to parse the created > certificate without errors. I would simplify the test by just having a > single test for each key type. > > --Sean Test updated, see http://cr.openjdk.java.net/~rhalade/8049237/webrev.03/ Thanks, Rajan From sean.mullan at oracle.com Fri Aug 28 01:37:51 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 27 Aug 2015 21:37:51 -0400 Subject: RfR JDK-8134456 java/lang/SecurityManager/CheckPackageAccess.java failing on several platforms In-Reply-To: <55DFA225.2090900@oracle.com> References: <55DF7ADC.7090808@oracle.com> <55DF8609.9020307@oracle.com> <55DF885E.5080108@oracle.com> <55DFA225.2090900@oracle.com> Message-ID: <55DFBB6F.9080205@oracle.com> Great, go ahead and push the fix. --Sean On 8/27/15 7:49 PM, Pete Brunet wrote: > JPRT jdk_lang tests ran clean, 7 builds passed, 8 tests passed. > http://scaaa637.us.oracle.com//archive/2015/08/2015-08-27-204226.pbrunet.dev > > command line: > jprt submit -stree . -email peter.brunet at oracle.com -c JDK-8134456 > -buildenv SKIP_BOOT_CYCLE=false -noqa -ot '.*product.*' -onlytests > '.*jdk_lang' > > Pete > > On 8/27/15 4:59 PM, Pete Brunet wrote: >> Hi Sean, I might need to make a change but this is the JTREG output from >> my local run >> jtreg -jdk:./build/windows-x86_64-normal-server-release/images/jdk >> ./jdk/test/java/lang/SecurityManager/ >> >> Execution successful >> >> java/lang/SecurityManager/CheckPackageAccess.java: Make sure all >> restricted packages listed in the package.access property in the >> java.security file are blocked >> java/lang/SecurityManager/CheckPackageMatching.java: Check the matching >> implemented by SecurityManager.checkPackageAccess >> java/lang/SecurityManager/CheckSecurityProvider.java: Consolidate >> java.security files into one file with modifications >> java/lang/SecurityManager/NoAWT.java: Sanity check that SecurityManager >> methods that used to check AWTPermission now check for AllPermission >> >> so it looks like there are no problems. What do you think? >> >> I'll report back once my JPRT run finishes. >> >> Pete >> >> On 8/27/15 4:50 PM, Sean Mullan wrote: >>> This looks good to me, if the JPRT results are good. However, does >>> this also fix the failure in CheckPackageMatching? I would have >>> expected you needed an additional fix - see my subsequent comment: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8134456?focusedCommentId=13837407&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837407 >>> >>> >>> Thanks, >>> Sean >>> >>> On 08/27/2015 05:02 PM, Pete Brunet wrote: >>>> Please review a patch for a test change which is needed to fix an issue >>>> caused by JDK-8051626. Tier 1 tests are being impacted. >>>> >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134456/webrev.00/ >>>> >>>> Pete >>>> > From peter.brunet at oracle.com Fri Aug 28 02:12:19 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Thu, 27 Aug 2015 21:12:19 -0500 Subject: RfR JDK-8134456 java/lang/SecurityManager/CheckPackageAccess.java failing on several platforms In-Reply-To: <55DFBB6F.9080205@oracle.com> References: <55DF7ADC.7090808@oracle.com> <55DF8609.9020307@oracle.com> <55DF885E.5080108@oracle.com> <55DFA225.2090900@oracle.com> <55DFBB6F.9080205@oracle.com> Message-ID: <55DFC383.2070908@oracle.com> On 8/27/15 8:37 PM, Sean Mullan wrote: > Great, go ahead and push the fix. Is one review (yours) enough? > > --Sean > > On 8/27/15 7:49 PM, Pete Brunet wrote: >> JPRT jdk_lang tests ran clean, 7 builds passed, 8 tests passed. >> http://scaaa637.us.oracle.com//archive/2015/08/2015-08-27-204226.pbrunet.dev >> >> >> command line: >> jprt submit -stree . -email peter.brunet at oracle.com -c JDK-8134456 >> -buildenv SKIP_BOOT_CYCLE=false -noqa -ot '.*product.*' -onlytests >> '.*jdk_lang' >> >> Pete >> >> On 8/27/15 4:59 PM, Pete Brunet wrote: >>> Hi Sean, I might need to make a change but this is the JTREG output >>> from >>> my local run >>> jtreg -jdk:./build/windows-x86_64-normal-server-release/images/jdk >>> ./jdk/test/java/lang/SecurityManager/ >>> >>> Execution successful >>> >>> java/lang/SecurityManager/CheckPackageAccess.java: Make sure all >>> restricted packages listed in the package.access property in the >>> java.security file are blocked >>> java/lang/SecurityManager/CheckPackageMatching.java: Check the matching >>> implemented by SecurityManager.checkPackageAccess >>> java/lang/SecurityManager/CheckSecurityProvider.java: Consolidate >>> java.security files into one file with modifications >>> java/lang/SecurityManager/NoAWT.java: Sanity check that SecurityManager >>> methods that used to check AWTPermission now check for AllPermission >>> >>> so it looks like there are no problems. What do you think? >>> >>> I'll report back once my JPRT run finishes. >>> >>> Pete >>> >>> On 8/27/15 4:50 PM, Sean Mullan wrote: >>>> This looks good to me, if the JPRT results are good. However, does >>>> this also fix the failure in CheckPackageMatching? I would have >>>> expected you needed an additional fix - see my subsequent comment: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8134456?focusedCommentId=13837407&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837407 >>>> >>>> >>>> >>>> Thanks, >>>> Sean >>>> >>>> On 08/27/2015 05:02 PM, Pete Brunet wrote: >>>>> Please review a patch for a test change which is needed to fix an >>>>> issue >>>>> caused by JDK-8051626. Tier 1 tests are being impacted. >>>>> >>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134456/webrev.00/ >>>>> >>>>> Pete >>>>> >> From mandy.chung at oracle.com Fri Aug 28 03:04:53 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 27 Aug 2015 20:04:53 -0700 Subject: RfR JDK-8134456 java/lang/SecurityManager/CheckPackageAccess.java failing on several platforms In-Reply-To: <55DFC383.2070908@oracle.com> References: <55DF7ADC.7090808@oracle.com> <55DF8609.9020307@oracle.com> <55DF885E.5080108@oracle.com> <55DFA225.2090900@oracle.com> <55DFBB6F.9080205@oracle.com> <55DFC383.2070908@oracle.com> Message-ID: <4AD7E81F-35AD-40F7-B109-3155F4CCDA84@oracle.com> Yes one review is enough to push to jdk9/dev (until later in the development cycle). Your change looks fine to me. What about the question Sean asked about CheckPackageMatching? I think that test is passing. Mandy > On Aug 27, 2015, at 7:12 PM, Pete Brunet <peter.brunet at oracle.com> wrote: > > > > On 8/27/15 8:37 PM, Sean Mullan wrote: >> Great, go ahead and push the fix. > Is one review (yours) enough? >> >> --Sean >> >> On 8/27/15 7:49 PM, Pete Brunet wrote: >>> JPRT jdk_lang tests ran clean, 7 builds passed, 8 tests passed. >>> http://scaaa637.us.oracle.com//archive/2015/08/2015-08-27-204226.pbrunet.dev >>> >>> >>> command line: >>> jprt submit -stree . -email peter.brunet at oracle.com -c JDK-8134456 >>> -buildenv SKIP_BOOT_CYCLE=false -noqa -ot '.*product.*' -onlytests >>> '.*jdk_lang' >>> >>> Pete >>> >>> On 8/27/15 4:59 PM, Pete Brunet wrote: >>>> Hi Sean, I might need to make a change but this is the JTREG output >>>> from >>>> my local run >>>> jtreg -jdk:./build/windows-x86_64-normal-server-release/images/jdk >>>> ./jdk/test/java/lang/SecurityManager/ >>>> >>>> Execution successful >>>> >>>> java/lang/SecurityManager/CheckPackageAccess.java: Make sure all >>>> restricted packages listed in the package.access property in the >>>> java.security file are blocked >>>> java/lang/SecurityManager/CheckPackageMatching.java: Check the matching >>>> implemented by SecurityManager.checkPackageAccess >>>> java/lang/SecurityManager/CheckSecurityProvider.java: Consolidate >>>> java.security files into one file with modifications >>>> java/lang/SecurityManager/NoAWT.java: Sanity check that SecurityManager >>>> methods that used to check AWTPermission now check for AllPermission >>>> >>>> so it looks like there are no problems. What do you think? >>>> >>>> I'll report back once my JPRT run finishes. >>>> >>>> Pete >>>> >>>> On 8/27/15 4:50 PM, Sean Mullan wrote: >>>>> This looks good to me, if the JPRT results are good. However, does >>>>> this also fix the failure in CheckPackageMatching? I would have >>>>> expected you needed an additional fix - see my subsequent comment: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8134456?focusedCommentId=13837407&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837407 >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Sean >>>>> >>>>> On 08/27/2015 05:02 PM, Pete Brunet wrote: >>>>>> Please review a patch for a test change which is needed to fix an >>>>>> issue >>>>>> caused by JDK-8051626. Tier 1 tests are being impacted. >>>>>> >>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134456/webrev.00/ >>>>>> >>>>>> Pete >>>>>> >>> > From peter.brunet at oracle.com Fri Aug 28 14:53:51 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 28 Aug 2015 09:53:51 -0500 Subject: RfR JDK-8134456 java/lang/SecurityManager/CheckPackageAccess.java failing on several platforms In-Reply-To: <4AD7E81F-35AD-40F7-B109-3155F4CCDA84@oracle.com> References: <55DF7ADC.7090808@oracle.com> <55DF8609.9020307@oracle.com> <55DF885E.5080108@oracle.com> <55DFA225.2090900@oracle.com> <55DFBB6F.9080205@oracle.com> <55DFC383.2070908@oracle.com> <4AD7E81F-35AD-40F7-B109-3155F4CCDA84@oracle.com> Message-ID: <55E075FF.40505@oracle.com> On 8/27/15 10:04 PM, Mandy Chung wrote: > Yes one review is enough to push to jdk9/dev (until later in the development cycle). > > Your change looks fine to me. What about the question Sean asked about CheckPackageMatching? I think that test is passing. Sean/Mandy, Is there someone who would understand CheckPackageMatching better than I? I have a P2 to work on and would appreciated it if someone else could look into this. Pete > > Mandy > >> On Aug 27, 2015, at 7:12 PM, Pete Brunet <peter.brunet at oracle.com> wrote: >> >> >> >> On 8/27/15 8:37 PM, Sean Mullan wrote: >>> Great, go ahead and push the fix. >> Is one review (yours) enough? >>> --Sean >>> >>> On 8/27/15 7:49 PM, Pete Brunet wrote: >>>> JPRT jdk_lang tests ran clean, 7 builds passed, 8 tests passed. >>>> http://scaaa637.us.oracle.com//archive/2015/08/2015-08-27-204226.pbrunet.dev >>>> >>>> >>>> command line: >>>> jprt submit -stree . -email peter.brunet at oracle.com -c JDK-8134456 >>>> -buildenv SKIP_BOOT_CYCLE=false -noqa -ot '.*product.*' -onlytests >>>> '.*jdk_lang' >>>> >>>> Pete >>>> >>>> On 8/27/15 4:59 PM, Pete Brunet wrote: >>>>> Hi Sean, I might need to make a change but this is the JTREG output >>>>> from >>>>> my local run >>>>> jtreg -jdk:./build/windows-x86_64-normal-server-release/images/jdk >>>>> ./jdk/test/java/lang/SecurityManager/ >>>>> >>>>> Execution successful >>>>> >>>>> java/lang/SecurityManager/CheckPackageAccess.java: Make sure all >>>>> restricted packages listed in the package.access property in the >>>>> java.security file are blocked >>>>> java/lang/SecurityManager/CheckPackageMatching.java: Check the matching >>>>> implemented by SecurityManager.checkPackageAccess >>>>> java/lang/SecurityManager/CheckSecurityProvider.java: Consolidate >>>>> java.security files into one file with modifications >>>>> java/lang/SecurityManager/NoAWT.java: Sanity check that SecurityManager >>>>> methods that used to check AWTPermission now check for AllPermission >>>>> >>>>> so it looks like there are no problems. What do you think? >>>>> >>>>> I'll report back once my JPRT run finishes. >>>>> >>>>> Pete >>>>> >>>>> On 8/27/15 4:50 PM, Sean Mullan wrote: >>>>>> This looks good to me, if the JPRT results are good. However, does >>>>>> this also fix the failure in CheckPackageMatching? I would have >>>>>> expected you needed an additional fix - see my subsequent comment: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8134456?focusedCommentId=13837407&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837407 >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Sean >>>>>> >>>>>> On 08/27/2015 05:02 PM, Pete Brunet wrote: >>>>>>> Please review a patch for a test change which is needed to fix an >>>>>>> issue >>>>>>> caused by JDK-8051626. Tier 1 tests are being impacted. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8134456/webrev.00/ >>>>>>> >>>>>>> Pete >>>>>>> From sean.mullan at oracle.com Fri Aug 28 15:00:41 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 28 Aug 2015 11:00:41 -0400 Subject: RfR JDK-8134456 java/lang/SecurityManager/CheckPackageAccess.java failing on several platforms In-Reply-To: <55E075FF.40505@oracle.com> References: <55DF7ADC.7090808@oracle.com> <55DF8609.9020307@oracle.com> <55DF885E.5080108@oracle.com> <55DFA225.2090900@oracle.com> <55DFBB6F.9080205@oracle.com> <55DFC383.2070908@oracle.com> <4AD7E81F-35AD-40F7-B109-3155F4CCDA84@oracle.com> <55E075FF.40505@oracle.com> Message-ID: <55E07799.2060301@oracle.com> On 08/28/2015 10:53 AM, Pete Brunet wrote: > > On 8/27/15 10:04 PM, Mandy Chung wrote: >> >Yes one review is enough to push to jdk9/dev (until later in the development cycle). >> > >> >Your change looks fine to me. What about the question Sean asked about CheckPackageMatching? I think that test is passing. > Sean/Mandy, Is there someone who would understand CheckPackageMatching > better than I? I have a P2 to work on and would appreciated it if > someone else could look into this. I'll take a look at it and get back to you, it's on the ProblemList now so we have more time to look at it. --Sean From valerie.peng at oracle.com Fri Aug 28 21:03:59 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 28 Aug 2015 14:03:59 -0700 Subject: RFR 8044199: tests for RSA keys and key specifications In-Reply-To: <55D600E9.4040003@oracle.com> References: <55D600E9.4040003@oracle.com> Message-ID: <55E0CCBF.7070405@oracle.com> Hi Tristan, Mostly fine, just 2 more nits: 1) KeySizeTest: the @test and @bug are still on the same line. 2) SpecTest.java: the @run command from line 40 - 45 still have the old name, e.g. KeyModulusTest? I think u need to match them. Thanks, Valerie On 8/20/2015 9:31 AM, Tristan Yan wrote: > Thanks Valerie > > Please review the fixed version. > > http://cr.openjdk.java.net/~tyan/8044199/webrev.02/ > > Tristan > > > > Tristan, > > > > - Given that the tests are against SunRsaSign provider, I think > > sun/security/rsa subdirectory is a better choice than java/security/rsa. > > - Put @test and @bug on separate lines > > - Elaborate more on what is tested and what is the expected result in > > the bug record. The current content isn't very clear. > > - Can u have more unique names for these tests? Currently, they are too > > similarly named and it's somewhat confusing. The directory already > > contains RSA, I don't feel that u need to have RSA again in the names of > > the test especially when SunRsaSign provider doesn't support non-RSA > > algorithms. > > > > For KeyTest.java > > 1) typo on line 69, rsaPrivateKey2 should be rsaPrivateKey > > 2) This test is based on the> > provider specific behavior that CRT key is > > generated by default for RSA. It'd be much clearer if you can add an > > instanceof check on the generated RSA private key objects before the > > KeyFactory + RSAPrivateKeySpec code. In addition, add additional code to > > check for equality with the matching KeySpec (e.g. RSAPrivateCrtKeySpec > > for RSAPrivateCrtKey) is used. > > 3) line 58, add a space between '//" and text. > > > > For RSAKeySizeTest.java > > 1) specify provider "SunRSASign" for all getInstance() calls. > > 2) line 55 can be moved up to before the for-loop. > > 3) instead of using toString(int), probably bitLength() would be a > > better choice. > > 4) sizeTest() doesn't really check size but rather it compares the > > modulus values being equal. This check can be moved to RSAKeySizeTest.java. > > > > For RSATest.java > > 1) specify provider "SunRSASign" for all getInstance() calls. > > > > Thanks, > > Valerie > > > > On 8/3/2015 10:27 AM, Tristan Yan wrote: > >>/ Hi > />>/ > />>/ Please review new tests for RSA keys and key specifications > />>/ > />>/ Bug:https://bugs.openjdk.java.net/browse/JDK-8044199 > />>/ Webrev:http://cr.openjdk.java.net/~tyan/8044199/webrev.01/ <http://cr.openjdk.java.net/%7Etyan/8044199/webrev.01/> <http://cr.openjdk.java.net/%7Etyan/8044199/webrev.01/> <http://cr.openjdk.java.net/~tyan/8044199/webrev.01/ <http://cr.openjdk.java.net/%7Etyan/8044199/webrev.01/> <http://cr.openjdk.java.net/%7Etyan/8044199/webrev.01/>> > />>/ > />>/ Thanks > />>/ Tristan > />> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150828/dd21fcb2/attachment.html> From valerie.peng at oracle.com Fri Aug 28 21:26:49 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 28 Aug 2015 14:26:49 -0700 Subject: [9] RFR: 8048601: Tests for JCE crypto ciphers In-Reply-To: <55DCCBA9.2090105@oracle.com> References: <55A57096.10700@oracle.com> <55D50580.8090402@oracle.com> <55D66095.4090309@oracle.com> <55DCCBA9.2090105@oracle.com> Message-ID: <55E0D219.5050502@oracle.com> Ok, looks good. Thanks, Valerie On 8/25/2015 1:10 PM, Rajan Halade wrote: > Hi Valerie, > > Thanks for comments! I have fixed all of them. > > http://cr.openjdk.java.net/~rhalade/8048601/webrev.01/ > > - Rajan > > On 8/20/15 4:19 PM, Valerie Peng wrote: >> Rajan, >> >> Here are some comments for the other half of the webrev: >> TestCipherTextLength.java >> 1) line 82 and 85, why TEXT_LEN is needed? I don't find any usage of >> it inside runAll(..) method? > removed. >> 2) the names here are a bit too similar, e.g. PBEWrapper, >> PBECipherWrapper, AESPBEWrapper. The individual subclasses aren't >> that big, why not make them inner static classes of the parent class? >> No need to repeat the Wrapper and PBE in the subclass names. To match >> your other wrapper class DESCipherWrapper, perhaps you can rename the >> PBE counterpart to something like: >> >> PBECipherWrapper (parent) with subclasses (defined statically >> inside PBECipherWrapper) named PBKDF2, AES, and Legacy (these are >> PKCS#5 v1.5 defined algorithms). > fixed, thanks! >> >> PBKDF2Wrapper.java >> 1) typo on line 43 and 52 - should be T_R_ANSFORMATION > fixed >> 2) Instead of "PKDF2_DEFAULT_KEY_LEN" (typo? I think u meant PBKDF2), >> it should really be CIPHER_KEY_SIZE since the purpose here is to >> generate keys for the Cipher object. > renamed the variable. >> 3) the key that you generated on line 57 can be viewed as an >> intermediate key. You could have moved the processing in >> initCipher(...) method into the constructor and store the resulting >> cipher key into 'key'. For example: >> SecretKey derivedKey = keyFactory.generateSecret(pbeKeySpec); >> key = new SecretKeySpec(derivedKey.getEncoded(), KEY_ALGORITHM); > key is generated in consturctor. >> >> Thanks, >> Valerie >> >> On 8/19/2015 3:38 PM, Valerie Peng wrote: >>> Rajan, >>> >>> TestCipher.java >>> 1) this class is used as the base for many algorithm, modes, and >>> paddings. But then it hardcodes some values or parameter types which >>> may not work against some algorithms, e.g. IvParameterSpec with >>> 8-byte value, padding length being 8 bytes. PAD_LEN=8 vs >>> PAD_BYTES=16, is this difference intentional? >>> Seems to me that this TestCipher class only works against Ciphers w/ >>> 8-byte blocks and uses iv. I think it's clearer to have a constant >>> named BLKSIZE instead of just 8. > Yes. I have changed iv to be final variable now initialized in > constructor. >>> 2) Also, u don't need to repeatedly generate random bytes for input >>> data, IV, etc. The input data can be generated once outside of loop. >>> As for the parameters, either u can just let the cipher object >>> generates it or grab the IV values from whatever data that u have >>> already, e.g. certain part of the input data. > fixed, no need for random anymore. >>> 2) input length is always 800. Would be nice to have a comment >>> stating the requirement, e.g. multiple of blocks in order to work >>> against ciphers w/ NoPadding >>> 3) line 54, Would be nice to clarify that the range of tested key >>> size is from MINIMUM_KEY_SIZE to what returned by >>> Cipher.getMaxAllowedKeyLength(ALGORITHM) with the increment of >>> KEYCUTTER. > added comments. >>> 4) line 66, keyStrength is better phrased as variousKeySize in my >>> opinion. > renamed to variousKeySize. >>> 5) MINIMUM_KEY_SIZE and KEYCUTTER should be algorithm specific. It'd >>> be clearer to explicitly list out the algorithms which works against >>> the the hardcoded values for the sake of maintenance. > added comments. >>> 6) It looks to me that String[] modes and String[] paddings could be >>> moved to runAll(). This seems more consistent with the signature of >>> runTest() where mode and padding are again specified here. > I left it as is and changed runTest to private method. Either is ok > with me. > > Thanks, > Rajan >>> >>> Will send u comments regarding the TestLength ones in a separate email. >>> Thanks, >>> Valerie >>> >>> On 7/14/2015 1:27 PM, Rajan Halade wrote: >>>> May I request you to review new tests added to check Cipher >>>> operations with different algorithms and modes. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rhalade/8048601/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048601 >>>> >>>> Thanks, >>>> Rajan > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150828/1d219ca3/attachment-0001.html> From jamil.j.nimeh at oracle.com Sat Aug 29 01:25:13 2015 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 28 Aug 2015 18:25:13 -0700 Subject: RFR JDK-8134364: Add defensive copies to get/set methods for OCSPNonceExtension In-Reply-To: <55DC859D.2090704@oracle.com> References: <55DBF538.7070000@oracle.com> <55DC23DE.1080806@oracle.com> <55DC7059.2090706@oracle.com> <55DC859D.2090704@oracle.com> Message-ID: <55E109F9.1030701@oracle.com> Hello all, I've removed the CertAttrSet interface from OCSPNonceExtension and trimmed away a few unneeded methods. As a result the class is immutable now. JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.01 Thanks, --Jamil On 08/25/2015 08:11 AM, Jamil Nimeh wrote: > Hi Sean, > > Yes, I was just following Extension convention in terms of > implementing CertAttrSet. Within sun.security.x509, X509CertInfo uses > the set methods from other objects implementing CertAttrSet. But > OCSPNonceExtension really isn't a certificate attribute so it probably > doesn't need to bring this interface in. > > I'll refactor this and alter the tests to match. > > --Jamil > > On 08/25/2015 06:40 AM, Sean Mullan wrote: >> Is it necessary for the class to implement CertAttrSet? I realize all >> of the internal X.509 extensions implement that, but that was done a >> long time ago and not something we really want to carry forward if >> not needed. I think it would be cleaner not to do that as it would >> more easily allow you to make the class immutable, and would allow >> you to remove the set method. >> >> Thanks, >> Sean >> >> On 08/25/2015 04:14 AM, Xuelei Fan wrote: >>> OCSPNonceExtension.java >>> ======================= >>> - nonceData = (byte[])obj; >>> + nonceData = ((byte[])obj).clone(); >>> >>> Do you want to check null obj? >>> >>> - return nonceData; >>> + return (nonceData != null ? nonceData.clone() : null); >>> >>> I think you may want to enclose the "!=" operator as: >>> >>> + return (nonceData != null) ? nonceData.clone() : null; >>> >>> >>> Xuelei >>> >>> On 8/25/2015 12:55 PM, Jamil Nimeh wrote: >>>> Hi all, >>>> >>>> This is a quick fix to the OCSPNonceExtension class to add a couple >>>> defensive copies to public get/set methods. >>>> >>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8134364 >>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8134364/webrev.00 >>>> >>>> Thanks, >>>> --Jamil >>> > From vincent.x.ryan at oracle.com Mon Aug 31 08:58:07 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 31 Aug 2015 09:58:07 +0100 Subject: 8130800: KeyStore.getInstance(File, char[]) does not throw IOE for null password Message-ID: <1340AC02-316A-46FA-8B76-D5C90C7F5836@oracle.com> Please review this spec change in java.security.KeyStore to clarify that a keystore integrity check is not performed when a null password is supplied. Thanks. Webrev: http://cr.openjdk.java.net/~vinnie/8130800/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8130800 From weijun.wang at oracle.com Mon Aug 31 09:02:06 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 31 Aug 2015 17:02:06 +0800 Subject: 8130800: KeyStore.getInstance(File, char[]) does not throw IOE for null password In-Reply-To: <1340AC02-316A-46FA-8B76-D5C90C7F5836@oracle.com> References: <1340AC02-316A-46FA-8B76-D5C90C7F5836@oracle.com> Message-ID: <55E4180E.1040300@oracle.com> This looks good. Thanks Max On 08/31/2015 04:58 PM, Vincent Ryan wrote: > Please review this spec change in java.security.KeyStore to clarify that a keystore integrity check is not performed when a null password is supplied. > Thanks. > > Webrev: http://cr.openjdk.java.net/~vinnie/8130800/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8130800 > From vincent.x.ryan at oracle.com Mon Aug 31 09:04:21 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 31 Aug 2015 10:04:21 +0100 Subject: 8130800: KeyStore.getInstance(File, char[]) does not throw IOE for null password In-Reply-To: <55E4180E.1040300@oracle.com> References: <1340AC02-316A-46FA-8B76-D5C90C7F5836@oracle.com> <55E4180E.1040300@oracle.com> Message-ID: <FC00F868-8111-4D03-8AE6-42322FFD5B26@oracle.com> Thanks Max. > On 31 Aug 2015, at 10:02, Weijun Wang <weijun.wang at oracle.com> wrote: > > This looks good. > > Thanks > Max > > On 08/31/2015 04:58 PM, Vincent Ryan wrote: >> Please review this spec change in java.security.KeyStore to clarify that a keystore integrity check is not performed when a null password is supplied. >> Thanks. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8130800/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8130800 >> From sean.mullan at oracle.com Mon Aug 31 15:33:56 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 31 Aug 2015 11:33:56 -0400 Subject: [9] RFR: 8049237: Need new tests for X509V3 certificates In-Reply-To: <55DFA2A2.7010309@oracle.com> References: <55A5B948.5030400@oracle.com> <55D3D587.9070603@oracle.com> <55DCA136.30007@oracle.com> <55DCB44D.6000204@oracle.com> <55DDDDC0.5070409@oracle.com> <55DE48C7.20008@oracle.com> <55DEF7F7.5030203@oracle.com> <55DFA2A2.7010309@oracle.com> Message-ID: <55E473E4.3090105@oracle.com> On 08/27/2015 07:52 PM, Rajan Halade wrote: > On 8/27/15 4:43 AM, Sean Mullan wrote: >> I don't think the different signature variants buy you much, since >> what you are mainly testing here is the ability to parse the created >> certificate without errors. I would simplify the test by just having a >> single test for each key type. >> >> --Sean > Test updated, see http://cr.openjdk.java.net/~rhalade/8049237/webrev.03/ Lines 73-74 should be removed. The jdk.tls.disabledAlgorithms property has no effect on this code since it does not use TLS. --Sean From valerie.peng at oracle.com Mon Aug 31 23:49:12 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 31 Aug 2015 16:49:12 -0700 Subject: [9] RFR 8133801: sun/security/pkcs11/Provider/ConfigShortPath.java failed in jigsaw nightly at Windows Message-ID: <55E4E7F8.5070608@oracle.com> Hi, Can someone please help reviewing this regression test update? http://cr.openjdk.java.net/~valeriep/8133801/webrev.00/ Both tests are updated to not using private SunPKCS11 constructors. The test Absolute.java has been updated in Jigsaw workspace, so I just matched the copy in JDK workspace to it. As for the test ConfigShortPath.java, the configuration files are OS-specific, so a bit more OS-specific handling is needed. I have run JPRT against both JDK and Jigsaw workspace with the changed files and results look fine. Thanks, Valerie From frank.yuan at oracle.com Thu Aug 13 07:27:26 2015 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 13 Aug 2015 07:27:26 -0000 Subject: RFR JDK-8074931: Additional tests for CertPath API Message-ID: <026b01d0d599$7f0e98c0$7d2bca40$@oracle.com> Hi Security developers I have a security test co-location bug https://bugs.openjdk.java.net/browse/JDK-8074931, which is to add more coverage for CertPath and X509CertSelector in jdk repo. Would you like to review this patch http://cr.openjdk.java.net/~fyuan/8074931/webrev.00/? Your comment will be appreciated. Best Regards Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150813/01cdb248/attachment.html> From sha.jiang at oracle.com Thu Aug 13 08:43:35 2015 From: sha.jiang at oracle.com (Sha Jiang) Date: Thu, 13 Aug 2015 08:43:35 -0000 Subject: RFR JDK-8075286: Additional tests for signature algorithm OIDs and transformation string Message-ID: <55CC58AF.7080608@oracle.com> Hi Security developers, I have a security test bug https://bugs.openjdk.java.net/browse/JDK-8075286, which adds more cases for NSA Suite B algorithms in jdk repo. Please review this patch at http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.00/ Every comment is appreciated. Best Regards, John Jiang From staryjir at protonmail.ch Wed Aug 19 21:48:39 2015 From: staryjir at protonmail.ch (Jiri Stary) Date: Wed, 19 Aug 2015 21:48:39 -0000 Subject: Brainpool curves Message-ID: <84b37f14179b57a34c10d0596b6f7dc0@protonmail.ch> Hello, do you plan to support brainpool curves for TLS in Java 9 (RFC 7027) ? Regards Jiri Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20150819/bde8cfe4/attachment.html>