From sean.coffey at oracle.com Mon Oct 1 13:11:12 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 1 Oct 2018 14:11:12 +0100 Subject: RFR: 8209862:CipherCore performance improvement Message-ID: <778f299c-c2b0-be47-59a9-3690ed3f9b40@oracle.com> JDK-8207775 introduced some performance regressions in the ciphercore area. Sergey Kuksenko has been looking at this and has contributed the following patch: http://cr.openjdk.java.net/~skuksenko/crypto/8209862/ bug report : https://bugs.openjdk.java.net/browse/JDK-8209862 I've been reviewing it and ran functionality and TCK testing. Didn't see any issues. Sergey has also confirmed that the patch helps to alleviate the performance issues introduced. More details regards approach for fix are in the bug description. Thanks Sergey! I'm looking for another review from security team. -- Regards, Sean. From adam.petcher at oracle.com Mon Oct 1 14:32:28 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 1 Oct 2018 10:32:28 -0400 Subject: RFR: 8209862:CipherCore performance improvement In-Reply-To: <778f299c-c2b0-be47-59a9-3690ed3f9b40@oracle.com> References: <778f299c-c2b0-be47-59a9-3690ed3f9b40@oracle.com> Message-ID: <4f202b2f-9d83-c043-1f29-a53e174aa07c@oracle.com> Looks like a nice improvement, but is it possible to do this without duplicating code? For example, code almost identical to this also appears starting on line 860: 971 } else { // encrypting 972 try { 973 outLen = finalNoPadding(finalBuf, finalOffset, output, 974 outputOffset, finalBufLen); 975 } finally { 976 // reset after doFinal() for GCM encryption 977 requireReinit = (cipherMode == GCM_MODE); 978 if (finalBuf != input) { 979 // done with internal finalBuf array. Copied to output 980 Arrays.fill(finalBuf, (byte) 0x00); 981 } 982 } 983 } It may be possible to factor out the entire if/else statement and some of the code around it into a separate method and do the short buffer check and save/restore around it. Ideally, each doFinal method would have only a small amount of code to either allocate the array or check array lengths, and then they would call the same private method to do most of the work. I would suggest a noreg-sqe label on the ticket to document that existing regression tests are used to ensure correctness of the modified code. Minor code style comments: check for long lines (e.g. line 856) and missing spaces after commas in actual parameter lists (also e.g. line 856). Also, line 1076 is missing space around the '?' and ':' characters. I can check the code again and give you the complete list after we sort out the code duplication. On 10/1/2018 9:11 AM, Se?n Coffey wrote: > JDK-8207775 introduced some performance regressions in the ciphercore > area. Sergey Kuksenko has been looking at this and has contributed the > following patch: > > http://cr.openjdk.java.net/~skuksenko/crypto/8209862/ > bug report : https://bugs.openjdk.java.net/browse/JDK-8209862 > > I've been reviewing it and ran functionality and TCK testing. Didn't > see any issues. Sergey has also confirmed that the patch helps to > alleviate the performance issues introduced. More details regards > approach for fix are in the bug description. > > Thanks Sergey! I'm looking for another review from security team. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Oct 1 18:49:08 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 1 Oct 2018 14:49:08 -0400 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> Message-ID: <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> Looks good. After you update the CSR with these changes, I can review it. --Sean On 9/28/18 9:36 AM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ > > Major changes: > > 1. Comment out key=value lines in java.security > 2. Fix a bug in PBES2Parameters.java > 3. Test no longer depends on openssl. Instead, use openssl to generate some pkcs12 files and included in the test. > 4. A new test KeyProtAlgCompat.java to ensure compatibility on pkcs12/PKCS12 names > > I haven't made any change to KeyStore.java yet. CSR is also not updated. > > Thanks > Max > >> On Sep 28, 2018, at 7:26 AM, Weijun Wang wrote: >> >> I think commenting out the key=value lines in java.security will ensure compatibility. >> >> Also, I think it's a tiny bug between >> >> 1. KeyStore.java uses "keystore.PKCS12.keyProtectionAlgorithm" >> 2. PKCS12KeyStore searches for "keystore.pkcs12.keyProtectionAlgorithm" first and "keystore.PKCS12.keyProtectionAlgorithm" next. >> >> I would like to update KeyStore.java to use "keystore.pkcs12.keyProtectionAlgorithm". We will keep supporting the PKCS12 name for this old property but everything else is clean. >> >> How do you think? >> >> Thanks >> Max >> >>> On Sep 28, 2018, at 12:22 AM, Sean Mullan wrote: >>> >>> The keystore.pkcs12.keyProtectionAlgorithm property was introduced in JDK 8. I don't think there are many apps using it. >>> >>> Thus, I would make a decision on what you think the best solution is long-term and then make sure you document any compatibility issues in the CSR and release note. >>> >>> My main advice is not to carry over the existing PKCS12 or pkcs12 flexibility into the new properties. >>> >>> --Sean >>> >>> On 9/27/18 11:27 AM, Weijun Wang wrote: >>>> Thinking about this more and there is a small problem. >>>> Suppose a user is already using PKCS12. Since it was a security property, there are 2 ways to use it: >>>> 1. Set it in java.security. Now the user is using JDK 12 and in java.security there is an existing keystore.pkcs12.keyProtectionAlgorithm. If the user noticed it, he would realize this is the formal name and modify it. If he hasn't noticed it he would add a new line using PKCS12. But then since both exist, the "pkcs12" one will be read first. >>>> 2. Set it with Security::setProperty. This is similar to the "hasn't noticed it" case above, and his value will be ignored. >>>> So, the user-provided PKCS12 one will only be used if the user is using an old java.security file. Do we really want to support that? >>>> Since PKCS12 is already written into KeyStore.java, it seems the correct way is to use "PKCS12" as the formal name and use "pkcs12" as an alias. But in JDK 11, the search order is first "pkcs12" and then "PKCS12". >>>> Or, shall we comment out the lines in java.security? They are indeed useless because default values are already hardcoded in source files. >>>> --Max >>>>> On Sep 27, 2018, at 10:29 PM, Sean Mullan wrote: >>>>> >>>>> It seems odd to support both. Once we put that into the code it?s very hard to take out in case someone is depending on it. So for the new properties I would just support one variant. >> > From ivan.gerasimov at oracle.com Mon Oct 1 23:37:51 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 1 Oct 2018 16:37:51 -0700 Subject: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike Message-ID: Hello! A handful of a few similar typos across core-libs/security-libs areas. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381 WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/ Would you please help review the fix? -- With kind regards, Ivan Gerasimov From anthony.scarpino at oracle.com Mon Oct 1 23:41:27 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 1 Oct 2018 16:41:27 -0700 Subject: RFR: 8209862:CipherCore performance improvement In-Reply-To: <778f299c-c2b0-be47-59a9-3690ed3f9b40@oracle.com> References: <778f299c-c2b0-be47-59a9-3690ed3f9b40@oracle.com> Message-ID: <32675e58-64a0-2f27-fb28-231b8b71b314@oracle.com> On 10/01/2018 06:11 AM, Se?n Coffey wrote: > JDK-8207775 introduced some performance regressions in the ciphercore > area. Sergey Kuksenko has been looking at this and has contributed the > following patch: > > http://cr.openjdk.java.net/~skuksenko/crypto/8209862/ > bug report : https://bugs.openjdk.java.net/browse/JDK-8209862 > > I've been reviewing it and ran functionality and TCK testing. Didn't see > any issues. Sergey has also confirmed that the patch helps to alleviate > the performance issues introduced. More details regards approach for fix > are in the bug description. > > Thanks Sergey! I'm looking for another review from security team. > A minor change maybe to move the declaration of finalBuf on line 1040 into the if() below, then return the finalBuf in the if. Then remove the else and return 'input' --- if ( ... byte[] finalBuf; ... return finalBuf; } return input; } --- I don't think this should hurt performance at all, maybe just a few less instructions Tony From lance.andersen at oracle.com Mon Oct 1 23:43:35 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 1 Oct 2018 19:43:35 -0400 Subject: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike In-Reply-To: References: Message-ID: <77361AB4-670F-4284-A32E-E5A106BACDAC@oracle.com> The changes look reasonable Ivan > On Oct 1, 2018, at 7:37 PM, Ivan Gerasimov wrote: > > Hello! > > A handful of a few similar typos across core-libs/security-libs areas. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381 > WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/ > > Would you please help review the fix? > > -- > With kind regards, > Ivan Gerasimov > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From bradford.wetmore at oracle.com Mon Oct 1 23:58:55 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 1 Oct 2018 16:58:55 -0700 Subject: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike In-Reply-To: References: Message-ID: <2032e61f-4a63-3a51-80a6-eb8e77791b7c@oracle.com> I checked the last 6 only (SSLEngine+). Looks good. Brad On 10/1/2018 4:37 PM, Ivan Gerasimov wrote: > Hello! > > A handful of a few similar typos across core-libs/security-libs areas. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381 > WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/ > > Would you please help review the fix? > From weijun.wang at oracle.com Tue Oct 2 00:02:10 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Oct 2018 08:02:10 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> Message-ID: <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> > On Oct 2, 2018, at 2:49 AM, Sean Mullan wrote: > > Looks good. After you update the CSR with these changes, I can review it. Sure. How do you think of the following change? Shall I also add it? diff --git a/src/java.base/share/classes/java/security/KeyStore.java b/src/java.base/share/classes/java/security/KeyStore.java --- a/src/java.base/share/classes/java/security/KeyStore.java +++ b/src/java.base/share/classes/java/security/KeyStore.java @@ -318,7 +318,7 @@ * for a given keystore type is set using the * {@code 'keystore..keyProtectionAlgorithm'} security property. * For example, the - * {@code keystore.PKCS12.keyProtectionAlgorithm} property stores the + * {@code keystore.pkcs12.keyProtectionAlgorithm} property stores the * name of the default key protection algorithm used for PKCS12 * keystores. If the security property is not set, an * implementation-specific algorithm will be used. Shall I add some word to this method saying we should use lowercase or are we going to live with this lower+UPPER for every keystore type forever? If yes, there will also be some text for its compatibility risk. Thanks Max > > --Sean > > On 9/28/18 9:36 AM, Weijun Wang wrote: >> Webrev updated at >> http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ >> Major changes: >> 1. Comment out key=value lines in java.security >> 2. Fix a bug in PBES2Parameters.java >> 3. Test no longer depends on openssl. Instead, use openssl to generate some pkcs12 files and included in the test. >> 4. A new test KeyProtAlgCompat.java to ensure compatibility on pkcs12/PKCS12 names >> I haven't made any change to KeyStore.java yet. CSR is also not updated. >> Thanks >> Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Oct 2 01:41:35 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 1 Oct 2018 18:41:35 -0700 Subject: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike In-Reply-To: <77361AB4-670F-4284-A32E-E5A106BACDAC@oracle.com> References: <77361AB4-670F-4284-A32E-E5A106BACDAC@oracle.com> Message-ID: <8fefa7f9-e6c1-fc4b-3c78-56ecfe787090@oracle.com> Changes look fine; thanks, -Joe On 10/1/2018 4:43 PM, Lance Andersen wrote: > The changes look reasonable Ivan > >> On Oct 1, 2018, at 7:37 PM, Ivan Gerasimov wrote: >> >> Hello! >> >> A handful of a few similar typos across core-libs/security-libs areas. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/ >> >> Would you please help review the fix? >> >> -- >> With kind regards, >> Ivan Gerasimov >> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From valerie.peng at oracle.com Tue Oct 2 01:48:00 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 1 Oct 2018 18:48:00 -0700 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> Message-ID: Hi Martin, For the KeyStore case, they are mostly token objects which the extract key info approach does not apply? For your changes in p11_keymgmt.c, I ran into compiler error and SIGBUS errors on two OS (mac and solaris sparc), I ended up changing variable initializations as well as memset(...). With the updated native changes, I adapted and re-tested my prototype changes. For reference, you can find the updated prototype changes at: http://cr.openjdk.java.net/~valeriep/6913047Exp/webrev.01/ Besides making changes in the keymgmet.c for getting rid of platform-specific compilation error and SIGBUS error, I noticed that you hardcoded the key wrapping mechanism in native code for both getNativeKeyInfo(...)/createNativeKey() methods, it seems better to storing the mechanism object at java side, i.e. P11Key and its associated classes, and then pass the object to JNI code (please also see my webrev.01) In addition, I switched the reference counting to your model, i.e. increase in init() and decrease in reset(), instead of the try-n-finally model in prototype webrev.00. My earlier comment on P11Cipher class which you should not replace the initialize() call with ensureInitialized() call applies to all other PKCS11 classes as well. With this approach, the KeyID field of P11Key should not be freely accessible and directly referenced outside of P11Key class. Also, the increase and decrease of reference counting must be paired up. Supposedly, the reference count should not go negative, right? If the reference counting isn't correct, the key may be freed pre-maturely? Lastly, the reference counting is an implementation detail and I think it's better to keep it inside the P11Key class/file and not exposing it, i.e. through method names. I have spent time verifying my updated prototype changes and trace the reference counting. All look fine, except there is one regression test failure (sun/security/tools/keytool/NssTest.java) on linux-x64 which I am still troubleshooting. However, I will be on vacation from 10/4 to 10/21, so I want to update you on what I have so you can continue during my vacation. Thanks, Valerie On 9/18/2018 4:48 PM, Valerie Peng wrote: > > Hi Martin, > > I am ok with your conservation choice of only applying this when using > NSS. If we are only applying this for NSS, we should really refactor > the code to minimize the impact on callers and P11Key class. My > prototype code may be on the extreme end of minimizing changes. But > the current webrev can use some refactoring also. With your > explanation, I now understand your model better. How about the > refactoring in P11Key class? Is there a reason for not doing this? I > did test my prototype code against existing regression tests (except > the KeyStore ones as more API changes are needed for persistent keys > which I have not covered in prototype) but I ran into some strange > errors in some native p11 calls which I did not touch so I commented > them out and just checked the part of reference count, etc. > > I will take a closer look at the KeyStore case and let you know. > Thanks, > Valerie > > On 9/18/2018 7:29 AM, Martin Balao wrote: >> Hi Valerie, >> >> Thanks for your comments. >> >> Here it is Webrev.11: >> >> ?* >> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.11/ >> >> ?* >> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.11.zip >> >> >> >> L397: That's right. I was trying to simplify the code but missed >> this. Thanks. >> L471: The key reference counter has to be decremented under any >> exception (P11Key.decNativeKeyRef method call). But, yes, no >> exception different than PKCS11Exception should be thrown. Reverted >> this change. >> >> >> L99: Comment changed. It should be better now. >> L148-L149: In fact, I'd enforce this and disable the feature for all >> token keys. Token keys are permanent and extracting them is risky. >> This criteria was already applied when dealing with key stores >> (P11Keystore class). >> >> Yes, this feature is enabled for NSS only because it's the only >> backend we currently know that is affected by this memory "leak" >> issue. If there were any other software-token backend affected, we >> can try this feature there too. HSMs shouldn't have any problem. I >> prefer to take a more conservative approach and enable the feature >> only in those cases in which it's really necessary. All other cases, >> default to the previous mechanism for freeing memory. >> >> This does not replace the PhantomReference approach; both work >> together and are complementary. In cases where temporary keys feature >> is disabled or when a temporary key client is not behaving correctly >> (i.e.: leaking stateful operations like "cipher" or "signature" in an >> intermediate state with the native key initialized), PhantomReference >> approach will be the last chance to free memory. The native key >> object can be destroyed (C_DestroyObject call) either from the >> PhantomReference mechanism or from the temporary keys mechanism. >> There shouldn't be any conflict between them. If it's destroyed >> through temporary keys mechanism, then we know that the P11Key object >> is alive (refereced) and thus PhantomReference destruction won't be >> taking place at the same time. Once the key is deleted, keyID is set >> to 0 and session to null. Thus, PhantomReference destruction won't >> have any effect when executed later. If we think of the other case >> (when the key is freed by PhantomReference), we have a P11Key object >> with a native key initialized but with no references to it. Thus, >> destroyNativeKey method won't be called and >> SessionKeyRef.disposeNative is the only method that will delete the key. >> >> L157: that's right, synchronization has to be at class level. Fixed. >> >> L1343: It's not the same session: this.session was assigned a new >> value (this.session = session;) before calling addObject. >> >> L1363: removeObject is called for the session, inside >> setKeyIDAndSession: "this.session.removeObject();". Null is set to >> this.session instance variable after this call. >> >> In regards to the refactorings you proposed, the problem I see with >> moving key reference incrementing/decrementing to PKCS11.java is that >> some operations are stateful. I.e.: encryption. When we initialize >> the operation with C_EncryptInit, the key id is the 3rd parameter. >> Destroying the key id and then doing C_EncryptUpdate sounds incorrect >> to me. Have you tried the regression testing suite after this >> refactoring? (I see some parts commented). In regards to removing the >> tmpNativeKey parameter (used to explicitly disable the feature for >> new P11Key objects), how do you handle the P11KeyStore case? We don't >> want temporary keys there. >> >> Kind regards, >> Martin.- >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue Oct 2 05:26:17 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 1 Oct 2018 22:26:17 -0700 Subject: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike In-Reply-To: <2032e61f-4a63-3a51-80a6-eb8e77791b7c@oracle.com> References: <2032e61f-4a63-3a51-80a6-eb8e77791b7c@oracle.com> Message-ID: <6a3136a7-0e0d-df1d-0410-cc26e8f371a4@oracle.com> Thank you for reviewing! I just realized that the sentence about SKIP_ARRAY in the javadoc for SSLSocketImpl.skip() is not relevant, as the temporary array is not static anymore, so I just removed it. The updated webrev with this only change, comparing to the previous one, is here: http://cr.openjdk.java.net/~igerasim/8200381/01/webrev/ With kind regards, Ivan On 10/1/18 4:58 PM, Bradford Wetmore wrote: > I checked the last 6 only (SSLEngine+). Looks good. > > Brad > > > On 10/1/2018 4:37 PM, Ivan Gerasimov wrote: >> Hello! >> >> A handful of a few similar typos across core-libs/security-libs areas. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/ >> >> Would you please help review the fix? >> > -- With kind regards, Ivan Gerasimov From sean.mullan at oracle.com Tue Oct 2 15:34:09 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 2 Oct 2018 11:34:09 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: Hello, Thanks for all the comments so far, and the interesting discussions about the future of the SecurityManager. We will definitely return to those discussions in the near future, but for now I have a second webrev ready for review for this enhancement: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ The main changes since the initial revision are: 1. System.setSecurityManager is no longer deprecated. This type of change clearly needs more discussion and is not an essential part of this RFE. 2. After further thought, I took Bernd's suggestion [1] and instead of adding a new property to disallow the setting of a SecurityManager at runtime, have added new tokens to the existing "java.security.manager" system property, named "=disallow", and "=allow" to toggle this behavior. The "=" is to avoid any potential clashes with custom SM classes with those names. I think this is a cleaner approach. There are a couple of new paragraphs in the SecurityManager class description describing the "java.security.manager" property and how the new tokens work. 3. I also added a comment that Bernd had requested [2] on why System.setSecurityManager calls checkPackageAccess("java.lang"). Also, the CSR has been updated: https://bugs.openjdk.java.net/browse/JDK-8203316 Thanks, Sean [1] http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html [2] http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html On 9/13/18 4:02 PM, Sean Mullan wrote: > This is a SecurityManager related change which warrants some additional > details for its motivation. > > The current System.setSecurityManager() API allows a SecurityManager to > be set at run-time. However, because of this mutability, it incurs a > performance overhead even for applications that never call it and do not > enable a SecurityManager dynamically, which is probably the majority of > applications. > > For example, there are lots of "SecurityManager sm = > System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If > it was known that a SecurityManager could never be set at run-time, > these checks could be optimized using constant-folding. > > There are essentially two main parts to this change: > > 1. Deprecation of System.securityManager() > > Going forward, we want to discourage applications from calling > System.setSecurityManager(). Instead they should enable a > SecurityManager using the java.security.manager system property on the > command-line. > > 2. A new JDK-specific system property to disallow the setting of the > security manager at run-time: jdk.allowSecurityManager > > If set to false, it allows the run-time to optimize the code and improve > performance when it is known that an application will never run with a > SecurityManager. To support this behavior, the > System.setSecurityManager() API has been updated such that it can throw > an UnsupportedOperationException if it does not allow a security manager > to be set dynamically. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 > JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 > > (I will likely also send this to core-libs for additional review later) > > --Sean From bradford.wetmore at oracle.com Tue Oct 2 16:34:36 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 2 Oct 2018 09:34:36 -0700 Subject: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike In-Reply-To: <6a3136a7-0e0d-df1d-0410-cc26e8f371a4@oracle.com> References: <2032e61f-4a63-3a51-80a6-eb8e77791b7c@oracle.com> <6a3136a7-0e0d-df1d-0410-cc26e8f371a4@oracle.com> Message-ID: <12af4d5b-db90-b1aa-81da-fb9ee97b4773@oracle.com> Fine. Brad On 10/1/2018 10:26 PM, Ivan Gerasimov wrote: > Thank you for reviewing! > > I just realized that the sentence about SKIP_ARRAY in the javadoc for > SSLSocketImpl.skip() is not relevant, as the temporary array is not > static anymore, so I just removed it. > > The updated webrev with this only change, comparing to the previous one, > is here: > > http://cr.openjdk.java.net/~igerasim/8200381/01/webrev/ > > With kind regards, > > Ivan > > > On 10/1/18 4:58 PM, Bradford Wetmore wrote: >> I checked the last 6 only (SSLEngine+).? Looks good. >> >> Brad >> >> >> On 10/1/2018 4:37 PM, Ivan Gerasimov wrote: >>> Hello! >>> >>> A handful of a few similar typos across core-libs/security-libs areas. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/ >>> >>> Would you please help review the fix? >>> >> > From sean.mullan at oracle.com Tue Oct 2 16:51:50 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 2 Oct 2018 12:51:50 -0400 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> Message-ID: <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> On 10/1/18 8:02 PM, Weijun Wang wrote: > > >> On Oct 2, 2018, at 2:49 AM, Sean Mullan > > wrote: >> >> Looks good. After you update the CSR with these changes, I can review it. > > Sure. > > How do you think of the following change? Shall I also add it? Yes. > > *diff --git a/src/java.base/share/classes/java/security/KeyStore.java > b/src/java.base/share/classes/java/security/KeyStore.java* > *--- a/src/java.base/share/classes/java/security/KeyStore.java* > *+++ b/src/java.base/share/classes/java/security/KeyStore.java* > @@ -318,7 +318,7 @@ > ? ? ? ? ? * for a given keystore type is set using the > ? ? ? ? ? * {@code 'keystore..keyProtectionAlgorithm'} security > property. > ? ? ? ? ? * For example, the > - ? ? ? ? * {@code keystore.PKCS12.keyProtectionAlgorithm} property > stores the > + ? ? ? ? * {@code keystore.pkcs12.keyProtectionAlgorithm} property > stores the > ? ? ? ? ? * name of the default key protection algorithm used for PKCS12 > ? ? ? ? ? * keystores. If the security property is not set, an > ? ? ? ? ? * implementation-specific algorithm will be used. > > Shall I add some word to this method saying we should use lowercase or > are we going to live with this lower+UPPER for every keystore type > forever? No. Let's just continue to check in the code for both variants of the above property, but remove all references to the upper-case variant from the javadocs and java.security file. --Sean > > If yes, there will also be some text for its compatibility risk. > > Thanks > Max > >> >> --Sean >> >> On 9/28/18 9:36 AM, Weijun Wang wrote: >>> Webrev updated at >>> http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ >>> >>> Major changes: >>> 1. Comment out key=value lines in java.security >>> 2. Fix a bug in PBES2Parameters.java >>> 3. Test no longer depends on openssl. Instead, use openssl to >>> generate some pkcs12 files and included in the test. >>> 4. A new test KeyProtAlgCompat.java to ensure compatibility on >>> pkcs12/PKCS12 names >>> I haven't made any change to KeyStore.java yet. CSR is also not updated. >>> Thanks >>> Max > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Oct 2 17:05:51 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Oct 2018 10:05:51 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <7f11d2db-5f82-fed6-b4d1-c6f685ea88fa@oracle.com> On 10/2/18 8:34 AM, Sean Mullan wrote: > Hello, > > Thanks for all the comments so far, and the interesting discussions > about the future of the SecurityManager. We will definitely return to > those discussions in the near future, but for now I have a second > webrev ready for review for this enhancement: > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ > > : > > 2. After further thought, I took Bernd's suggestion [1] and instead of > adding a new property to disallow the setting of a SecurityManager at > runtime, have added new tokens to the existing "java.security.manager" > system property, named "=disallow", and "=allow" to toggle this > behavior. The "=" is to avoid any potential clashes with custom SM > classes with those names. I think this is a cleaner approach. There > are a couple of new paragraphs in the SecurityManager class > description describing the "java.security.manager" property and how > the new tokens work. I'm not a fan of using double == which is not obvious to catch the typo.? I think the `==` syntax may not be commonly known either (I suspect it's seldom for a user to override java.security.policy rather than augmenting it). Have you considered using simple token `disallow` and `allow` (or all-caps)?? The possibility of a custom security manager class named `disallow` and `allow` should be low. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Oct 2 17:14:23 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 2 Oct 2018 13:14:23 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <7f11d2db-5f82-fed6-b4d1-c6f685ea88fa@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <7f11d2db-5f82-fed6-b4d1-c6f685ea88fa@oracle.com> Message-ID: <815c63e4-d2cf-c837-eeee-a5eefbbf210e@oracle.com> On 10/2/18 1:05 PM, Mandy Chung wrote: > I'm not a fan of using double == which is not obvious to catch the > typo.? I think the `==` syntax may not be commonly known either (I > suspect it's seldom for a user to override java.security.policy rather > than augmenting it). > > Have you considered using simple token `disallow` and `allow` (or > all-caps)? I am fine with that as well. >? The possibility of a custom security manager class named > `disallow` and `allow` should be low. I agree. I could imagine there might be a custom SM class named "Disallow" but that should still work, right? --Sean From sean.coffey at oracle.com Tue Oct 2 17:51:23 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 2 Oct 2018 18:51:23 +0100 Subject: RFR: 8209862:CipherCore performance improvement In-Reply-To: <4f202b2f-9d83-c043-1f29-a53e174aa07c@oracle.com> References: <778f299c-c2b0-be47-59a9-3690ed3f9b40@oracle.com> <4f202b2f-9d83-c043-1f29-a53e174aa07c@oracle.com> Message-ID: Good points from Adam and Tony. I've taken them both on board. Sergey has already eliminated a lot of duplicate code but there was further optimizing possible in the two doFinal(..) methods. I've introduced a new 'fillOutputBuffer' method to help. Please review : https://cr.openjdk.java.net/~coffeys/webrev.8209862.v2/webrev/ regards, Sean. On 01/10/2018 15:32, Adam Petcher wrote: > Looks like a nice improvement, but is it possible to do this without > duplicating code? For example, code almost identical to this also > appears starting on line 860: > > 971 } else { // encrypting > 972 try { > 973 outLen = finalNoPadding(finalBuf, finalOffset, output, > 974 outputOffset, finalBufLen); > 975 } finally { > 976 // reset after doFinal() for GCM encryption > 977 requireReinit = (cipherMode == GCM_MODE); > 978 if (finalBuf != input) { > 979 // done with internal finalBuf array. Copied to output > 980 Arrays.fill(finalBuf, (byte) 0x00); > 981 } > 982 } > 983 } > It may be possible to factor out the entire if/else statement and some > of the code around it into a separate method and do the short buffer > check and save/restore around it. Ideally, each doFinal method would > have only a small amount of code to either allocate the array or check > array lengths, and then they would call the same private method to do > most of the work. > > I would suggest a noreg-sqe label on the ticket to document that > existing regression tests are used to ensure correctness of the > modified code. > > Minor code style comments: check for long lines (e.g. line 856) and > missing spaces after commas in actual parameter lists (also e.g. line > 856). Also, line 1076 is missing space around the '?' and ':' > characters. I can check the code again and give you the complete list > after we sort out the code duplication. > > > On 10/1/2018 9:11 AM, Se?n Coffey wrote: >> JDK-8207775 introduced some performance regressions in the ciphercore >> area. Sergey Kuksenko has been looking at this and has contributed >> the following patch: >> >> http://cr.openjdk.java.net/~skuksenko/crypto/8209862/ >> bug report : https://bugs.openjdk.java.net/browse/JDK-8209862 >> >> I've been reviewing it and ran functionality and TCK testing. Didn't >> see any issues. Sergey has also confirmed that the patch helps to >> alleviate the performance issues introduced. More details regards >> approach for fix are in the bug description. >> >> Thanks Sergey! I'm looking for another review from security team. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Oct 2 18:15:57 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Oct 2018 11:15:57 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <815c63e4-d2cf-c837-eeee-a5eefbbf210e@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <7f11d2db-5f82-fed6-b4d1-c6f685ea88fa@oracle.com> <815c63e4-d2cf-c837-eeee-a5eefbbf210e@oracle.com> Message-ID: <55a75188-533a-d95e-b7b1-d3e06dfcf2d5@oracle.com> On 10/2/18 10:14 AM, Sean Mullan wrote: > On 10/2/18 1:05 PM, Mandy Chung wrote: >> I'm not a fan of using double == which is not obvious to catch the >> typo.? I think the `==` syntax may not be commonly known either (I >> suspect it's seldom for a user to override java.security.policy >> rather than augmenting it). >> >> Have you considered using simple token `disallow` and `allow` (or >> all-caps)? > > I am fine with that as well. > >> ? The possibility of a custom security manager class named `disallow` >> and `allow` should be low. > > I agree. I could imagine there might be a custom SM class named > "Disallow" but that should still work, right? Yes since the property value is case-sensitive. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Oct 2 18:47:58 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Oct 2018 19:47:58 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: On 02/10/2018 16:34, Sean Mullan wrote: > Hello, > > Thanks for all the comments so far, and the interesting discussions > about the future of the SecurityManager. We will definitely return to > those discussions in the near future, but for now I have a second > webrev ready for review for this enhancement: > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ I see the mails between you and Mandy about not using the double equals and using "allow" and "disallow". That makes sense as it is consistent with "default" and the chances of someone of having a SM class named "allow" or "disallow" isn't wroth worrying about. In System.java L85 it has "utilize" and might be clearer to stick with "set". L88 has "installed at startup" where it might be more consistent to use "set" there too. Otherwise looks good to me. -Alan From sean.mullan at oracle.com Tue Oct 2 19:31:27 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 2 Oct 2018 15:31:27 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <8d541aa2-7701-534b-f6f7-51813e6de7a1@oracle.com> On 10/2/18 2:47 PM, Alan Bateman wrote: > On 02/10/2018 16:34, Sean Mullan wrote: >> Hello, >> >> Thanks for all the comments so far, and the interesting discussions >> about the future of the SecurityManager. We will definitely return to >> those discussions in the near future, but for now I have a second >> webrev ready for review for this enhancement: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ > I see the mails between you and Mandy about not using the double equals > and using "allow" and "disallow". That makes sense as it is consistent > with "default" and the chances of someone of having a SM class named > "allow" or "disallow" isn't wroth worrying about. > > In System.java L85 it has "utilize" and might be clearer to stick with > "set". That sentence already has "setting" in it, so I think it would sound confusing to also have "set". I changed it to "use". I think this is fine since the previous sentence talks about setting the security manager at startup, and this sentence explains how you do that. > L88 has "installed at startup" where it might be more consistent > to use "set" there too. Ok. --Sean From Nico.Williams at twosigma.com Tue Oct 2 23:04:33 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Tue, 2 Oct 2018 23:04:33 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) Message-ID: <20181002230433.GU703@twosigma.com> Hello, We at Two Sigma Open Source, LLC, would like to make a contribution, to the OpenJDK, of various enhancements to the the OpenJDK's JGSS stack, specifically for better interoperability with native C GSS-API implementations. As I understand it, Two Sigma Open Source, LLC, has signed the OCA already. You can find our git clone of the OpenJDK, based on the AdoptOpenJDK github clone of the OpenJDK, at: https://github.com/twosigma/OpenJDK The relevant branches are: - ts-jgss-jdk12 -> our patches based on the JDK 12 master branch - ts-jgss-jdk11 -> our patches based on the JDK 11 master branch Summary of our changes: 1) Make GSSName extend Principal This is necessary in order for JGSS applications to be able to use JAAS when also using the native C GSS-API JNI wrapper. A GSS-API name object really is a principal name, therefore it is natural that GSSName must extend Principal. 2) Add a GssLoginModule to go with Krb5LoginModule. Krb5LoginModule is for when using the native Java implementation of Kerberos V5. GssLoginModule is for when using JGSS with the native C GSS-API JNI wrapper. In principle we could have just one module for both, but we have not done this work yet. In practice both modules can be used in any given JAAS configuration by, e.g., specifying both as optional. 3) Add JGSS functionality required to have GssLoginModule on par with Krb5LoginModule. This means adding methods for acquiring a GSSCredentialElement with a password. 4) Bug fixes. We have fixes for a number of bugs, including ones where not disposing early of JNI resources meant accumulating heap pressure that the JVM / GC is not aware of. GSS-API native objects ("security context", "credential handles", "names") can be sizeable, but as far as the JVM is concerned they are icebergs: the JVM sees only the tiny amount floating above the surface, but underneath is a much larger object. 5) Commentary, including suggestions for how to generalize ServicePermission to be applicable to non-Kerberos principals, such as by either mapping names from ServicePermission grants to non-Kerberos principal names, or by extending ServicePermission grant syntax to allow other name forms than Kerberos. We'd like to know how to proceed to get this contribution adopted upstream. I am aware of http://cr.openjdk.java.net/~chegar/docs/sandbox.html and will be moving to create a sandbox and webrev for our contribution soon. Thanks, Nico -- From Alan.Bateman at oracle.com Wed Oct 3 06:54:15 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Oct 2018 07:54:15 +0100 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20181002230433.GU703@twosigma.com> References: <20181002230433.GU703@twosigma.com> Message-ID: On 03/10/2018 00:04, Nico Williams wrote: > Hello, > > We at Two Sigma Open Source, LLC, would like to make a contribution, to > the OpenJDK, of various enhancements to the the OpenJDK's JGSS stack, > specifically for better interoperability with native C GSS-API > implementations. As I understand it, Two Sigma Open Source, LLC, has > signed the OCA already. > The "How to contribute" [1] is the best place to start. I see you are listed on the OCA signatories so that gets you through step 0. For the patches then I think you'll need to start a discussion here on the specific issues and changes that are you looking to contribute. This project requires all contributions to be sent on the mailing list or hosted on locations such as cr.openjdk.java.net. From your mail then it sounds like you have a lot of changes so it's probably best to start small, say with small fixes, until you've gain some experience with the process of contributing and sponsors/reviewers build up confidence in the changes. I suspect you will have the experience of doing significantly better than showing up with large patch that add features and changes large areas of JGSS. Starting small is really important for sponsors and reviewers as the review and testing effort for many contributions can be significant. -Alan [1] http://openjdk.java.net/contribute/ From adam.petcher at oracle.com Wed Oct 3 14:04:00 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 3 Oct 2018 10:04:00 -0400 Subject: Conceptual feedback on new ECC JEP In-Reply-To: <12a5b48d-9d6e-51a1-1f5b-9cbf32de910d@oracle.com> References: <952bd988-0c9d-422b-f14b-591ed92a397d@oracle.com> <12a5b48d-9d6e-51a1-1f5b-9cbf32de910d@oracle.com> Message-ID: <37bc701a-68d2-5086-4134-ed0edd48c7d5@oracle.com> I received quite a bit of feedback that questions the value of the new provider, and the "branchless mode" in general. At the same time, nobody has told me that this mode would be useful to them. So I am removing it from the JEP. In short, I will only be doing the second bullet point from my last email below---SunEC will be modified to include modern implementations of these three curves. I want to stress that no change to the spec/description of SunEC will be made. In particular, the "EC" algorithms in SunEC will make no guarantees related to security against side-channel attacks. Because this is now an implementation-only change, and there is no new feature to document, there is no longer any need to make this change under a JEP. My plan is to continue this work under JDK-8208698[1] and withdraw the JEP. There is no API or behavior change, so there will be no CSR for this change. [1] https://bugs.openjdk.java.net/browse/JDK-8208698 On 9/25/2018 10:40 AM, Adam Petcher wrote: > Thanks, everyone for your feedback on this JEP. I have incorporated > this feedback (received on this mailing list and elsewhere) into the > draft JEP[1]. Here is a summary of the current JEP and plan: > > *) A new provider (name TBD) will be developed to hold the new ECC > implementation for the three curves. This provider will feature the > interoperability-limiting restrictions on its API that were discussed > at length on this mailing list. The new provider will be at the end of > the list, so it won't be used by default. > *) The operations of the new implementation will also be added to > SunEC for the three curves. This means that the new implementation > will be used by default, in a completely compatible way (without any > restrictions on its API). Using the new implementation through SunEC > will not provide the same level of security against side-channel > attacks as using it through the new provider. > *) We will add some tests that make sure that TLS still work when the > new provider is used instead of SunEC. We may need to make some small > changes to the TLS implementation in order to get these tests to pass. > *) A couple of people asked me about whether we could modernize the > implementation of more curves in the future. I added a section at the > end of the JEP to discuss this. > > Of course, none of this is set in stone, and we still have some API > details to work out in the CSR. I'll be doing the CSR next, and I'm > happy to accept feedback at any time. > > [1] https://bugs.openjdk.java.net/browse/JDK-8204574 > > > On 8/23/2018 1:50 PM, Adam Petcher wrote: >> I'm starting work on yet another ECC JEP[1], this time with the goal >> of developing improved implementations of existing algorithms, rather >> than implementing new ones. The JEP will re-implement ECDH and ECDSA >> for the 256-, 384-, and 521-bit NIST prime curves. The new >> implementation will be all Java, and will resist side-channel attacks >> by not branching on secrets. It will go in a new provider which is >> not in the provider list in the java.security file by default. So it >> will need to be manually enabled by changing the configuration or >> putting the new provider name in the code. It will only support a >> subset of the API that is supported by the implementation in SunEC. >> In particular, it will reject any private keys with scalar values >> specified using BigInteger (as in ECPrivateKeySpec), and its private >> keys will not return scalar values as BigInteger (as in >> ECPrivateKey.getS()). >> >> Please take a look and send me any feedback you have. I'm especially >> looking for suggestions on how this new implementation should fit >> into the API. I would prefer to have it enabled by default, but I >> can't think of a way to do that without either branching on secrets >> in some cases (converting a BigInteger private key to an array) or >> breaking compatibility (throwing an exception when it gets a >> BigInteger private key). >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8204574 >> > From sean.mullan at oracle.com Wed Oct 3 19:43:09 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 3 Oct 2018 15:43:09 -0400 Subject: RFR 8210395: Add doc to SecurityTools.java In-Reply-To: References: <22AF6964-E1CD-491A-BC9C-0318965FE171@oracle.com> Message-ID: <6c533c7c-55e4-38fb-14b5-95db0f4acdec@oracle.com> Looks fine to me. --Sean On 9/24/18 11:59 PM, Weijun Wang wrote: > Ping again. > >> On Sep 5, 2018, at 12:17 PM, Weijun Wang wrote: >> >> I ran javadoc on test/lib so I can learn the useful helper classes, and find out SecurityTools.java has no javadoc at all. >> >> Please review this change >> >> http://cr.openjdk.java.net/~weijun/8210395/webrev.00/ >> >> Thanks >> Max >> > From sean.mullan at oracle.com Wed Oct 3 20:12:39 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 3 Oct 2018 16:12:39 -0400 Subject: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: Message-ID: <1b22437e-69ff-54a3-81b9-ccd6a0782629@oracle.com> For those of you that are not also subscribed to security-dev, this is mostly FYI, as the review is winding down, but if you have any comments, let me know. This change will add new token options ("allow" and "disallow") to the java.security.manager system property. The "disallow" option is intended to provide a potential performance boost for applications that don't enable a SecurityManager, as there is a cost associated with allowing a SecurityManager to enabled at runtime, even if it is never enabled. The CSR provides a good summary of the issue and spec changes: https://bugs.openjdk.java.net/browse/JDK-8203316 Thanks, Sean -------- Forwarded Message -------- Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable Date: Tue, 2 Oct 2018 11:34:09 -0400 From: Sean Mullan Organization: Oracle Corporation To: security Dev OpenJDK Hello, Thanks for all the comments so far, and the interesting discussions about the future of the SecurityManager. We will definitely return to those discussions in the near future, but for now I have a second webrev ready for review for this enhancement: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ The main changes since the initial revision are: 1. System.setSecurityManager is no longer deprecated. This type of change clearly needs more discussion and is not an essential part of this RFE. 2. After further thought, I took Bernd's suggestion [1] and instead of adding a new property to disallow the setting of a SecurityManager at runtime, have added new tokens to the existing "java.security.manager" system property, named "=disallow", and "=allow" to toggle this behavior. The "=" is to avoid any potential clashes with custom SM classes with those names. I think this is a cleaner approach. There are a couple of new paragraphs in the SecurityManager class description describing the "java.security.manager" property and how the new tokens work. 3. I also added a comment that Bernd had requested [2] on why System.setSecurityManager calls checkPackageAccess("java.lang"). Also, the CSR has been updated: https://bugs.openjdk.java.net/browse/JDK-8203316 Thanks, Sean [1] http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html [2] http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html On 9/13/18 4:02 PM, Sean Mullan wrote: > This is a SecurityManager related change which warrants some additional > details for its motivation. > > The current System.setSecurityManager() API allows a SecurityManager to > be set at run-time. However, because of this mutability, it incurs a > performance overhead even for applications that never call it and do not > enable a SecurityManager dynamically, which is probably the majority of > applications. > > For example, there are lots of "SecurityManager sm = > System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If > it was known that a SecurityManager could never be set at run-time, > these checks could be optimized using constant-folding. > > There are essentially two main parts to this change: > > 1. Deprecation of System.securityManager() > > Going forward, we want to discourage applications from calling > System.setSecurityManager(). Instead they should enable a > SecurityManager using the java.security.manager system property on the > command-line. > > 2. A new JDK-specific system property to disallow the setting of the > security manager at run-time: jdk.allowSecurityManager > > If set to false, it allows the run-time to optimize the code and improve > performance when it is known that an application will never run with a > SecurityManager. To support this behavior, the > System.setSecurityManager() API has been updated such that it can throw > an UnsupportedOperationException if it does not allow a security manager > to be set dynamically. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 > JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 > > (I will likely also send this to core-libs for additional review later) > > --Sean From valerie.peng at oracle.com Wed Oct 3 20:36:37 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 3 Oct 2018 13:36:37 -0700 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> Message-ID: <566016d0-00ba-e938-693f-56948b9013da@oracle.com> Hi Martin, I found the problem causing the one regression test failure and fixed it. Now Mach5 run is clean. http://cr.openjdk.java.net/~valeriep/6913047Exp/webrev.02 I also made various changes hoping to improve things. You can compare the files in above webrev with yours for differences. General principal is to minimize the changes as all new code may introduce regressions especially with changes of this scale. One key difference is that in your code, you destroy the native key handle after extracting native key info in the key constructor, and then re-creating the key handle when increase the reference count. I use a different approach, I keep the key handle in the key constructor which will then be destroyed when the reference count goes down to 0. From the regression test output that I observed, most keys are created and used once. Keeping the keyID in constructor seems more efficient. Besides, I also disable native key info extraction for all token keys. One thing that I am debating is whether we should add some property to disable this. I am aware that this will only be enabled if the key info extraction succeeds. However, would there be cases where the extraction succeeds but the re-creation fails? P11 Key objects are quite widely used, if something goes wrong, the impact may be significant. Thanks, Valerie On 10/1/2018 6:48 PM, Valerie Peng wrote: > > Hi Martin, > > For the KeyStore case, they are mostly token objects which the extract > key info approach does not apply? > > For your changes in p11_keymgmt.c, I ran into compiler error and > SIGBUS errors on two OS (mac and solaris sparc), I ended up changing > variable initializations as well as memset(...). With the updated > native changes, I adapted and re-tested my prototype changes. For > reference, you can find the updated prototype changes at: > http://cr.openjdk.java.net/~valeriep/6913047Exp/webrev.01/ > > Besides making changes in the keymgmet.c for getting rid of > platform-specific compilation error and SIGBUS error, I noticed that > you hardcoded the key wrapping mechanism in native code for both > getNativeKeyInfo(...)/createNativeKey() methods, it seems better to > storing the mechanism object at java side, i.e. P11Key and its > associated classes, and then pass the object to JNI code (please also > see my webrev.01) > > In addition, I switched the reference counting to your model, i.e. > increase in init() and decrease in reset(), instead of the > try-n-finally model in prototype webrev.00. My earlier comment on > P11Cipher class which you should not replace the initialize() call > with ensureInitialized() call applies to all other PKCS11 classes as well. > > With this approach, the KeyID field of P11Key should not be freely > accessible and directly referenced outside of P11Key class. Also, the > increase and decrease of reference counting must be paired up. > Supposedly, the reference count should not go negative, right? If the > reference counting isn't correct, the key may be freed pre-maturely? > Lastly, the reference counting is an implementation detail and I think > it's better to keep it inside the P11Key class/file and not exposing > it, i.e. through method names. > > I have spent time verifying my updated prototype changes and trace the > reference counting. All look fine, except there is one regression test > failure (sun/security/tools/keytool/NssTest.java) on linux-x64 which I > am still troubleshooting. However, I will be on vacation from 10/4 to > 10/21, so I want to update you on what I have so you can continue > during my vacation. > > Thanks, > > Valerie > > > > On 9/18/2018 4:48 PM, Valerie Peng wrote: >> >> Hi Martin, >> >> I am ok with your conservation choice of only applying this when >> using NSS. If we are only applying this for NSS, we should really >> refactor the code to minimize the impact on callers and P11Key class. >> My prototype code may be on the extreme end of minimizing changes. >> But the current webrev can use some refactoring also. With your >> explanation, I now understand your model better. How about the >> refactoring in P11Key class? Is there a reason for not doing this? I >> did test my prototype code against existing regression tests (except >> the KeyStore ones as more API changes are needed for persistent keys >> which I have not covered in prototype) but I ran into some strange >> errors in some native p11 calls which I did not touch so I commented >> them out and just checked the part of reference count, etc. >> >> I will take a closer look at the KeyStore case and let you know. >> Thanks, >> Valerie >> >> On 9/18/2018 7:29 AM, Martin Balao wrote: >>> Hi Valerie, >>> >>> Thanks for your comments. >>> >>> Here it is Webrev.11: >>> >>> ?* >>> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.11/ >>> >>> ?* >>> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.11.zip >>> >>> >>> >>> L397: That's right. I was trying to simplify the code but missed >>> this. Thanks. >>> L471: The key reference counter has to be decremented under any >>> exception (P11Key.decNativeKeyRef method call). But, yes, no >>> exception different than PKCS11Exception should be thrown. Reverted >>> this change. >>> >>> >>> L99: Comment changed. It should be better now. >>> L148-L149: In fact, I'd enforce this and disable the feature for all >>> token keys. Token keys are permanent and extracting them is risky. >>> This criteria was already applied when dealing with key stores >>> (P11Keystore class). >>> >>> Yes, this feature is enabled for NSS only because it's the only >>> backend we currently know that is affected by this memory "leak" >>> issue. If there were any other software-token backend affected, we >>> can try this feature there too. HSMs shouldn't have any problem. I >>> prefer to take a more conservative approach and enable the feature >>> only in those cases in which it's really necessary. All other cases, >>> default to the previous mechanism for freeing memory. >>> >>> This does not replace the PhantomReference approach; both work >>> together and are complementary. In cases where temporary keys >>> feature is disabled or when a temporary key client is not behaving >>> correctly (i.e.: leaking stateful operations like "cipher" or >>> "signature" in an intermediate state with the native key >>> initialized), PhantomReference approach will be the last chance to >>> free memory. The native key object can be destroyed (C_DestroyObject >>> call) either from the PhantomReference mechanism or from the >>> temporary keys mechanism. There shouldn't be any conflict between >>> them. If it's destroyed through temporary keys mechanism, then we >>> know that the P11Key object is alive (refereced) and thus >>> PhantomReference destruction won't be taking place at the same time. >>> Once the key is deleted, keyID is set to 0 and session to null. >>> Thus, PhantomReference destruction won't have any effect when >>> executed later. If we think of the other case (when the key is freed >>> by PhantomReference), we have a P11Key object with a native key >>> initialized but with no references to it. Thus, destroyNativeKey >>> method won't be called and SessionKeyRef.disposeNative is the only >>> method that will delete the key. >>> >>> L157: that's right, synchronization has to be at class level. Fixed. >>> >>> L1343: It's not the same session: this.session was assigned a new >>> value (this.session = session;) before calling addObject. >>> >>> L1363: removeObject is called for the session, inside >>> setKeyIDAndSession: "this.session.removeObject();". Null is set to >>> this.session instance variable after this call. >>> >>> In regards to the refactorings you proposed, the problem I see with >>> moving key reference incrementing/decrementing to PKCS11.java is >>> that some operations are stateful. I.e.: encryption. When we >>> initialize the operation with C_EncryptInit, the key id is the 3rd >>> parameter. Destroying the key id and then doing C_EncryptUpdate >>> sounds incorrect to me. Have you tried the regression testing suite >>> after this refactoring? (I see some parts commented). In regards to >>> removing the tmpNativeKey parameter (used to explicitly disable the >>> feature for new P11Key objects), how do you handle the P11KeyStore >>> case? We don't want temporary keys there. >>> >>> Kind regards, >>> Martin.- >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nico.Williams at twosigma.com Wed Oct 3 20:49:28 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 3 Oct 2018 20:49:28 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: References: <20181002230433.GU703@twosigma.com> Message-ID: <20181003204928.GA26310@twosigma.com> On Wed, Oct 03, 2018 at 07:54:15AM +0100, Alan Bateman wrote: > The "How to contribute" [1] is the best place to start. I see you > are listed on the OCA signatories so that gets you through step 0. Indeed. Figuring out how to deal with the OCA is a large reason we took so long to begin this contribution, as our legal department had some objections for some time which were eventually resolved by having our open source entity sign the OCA and our contributions done under that entity. > For the patches then I think you'll need to start a discussion here > on the specific issues and changes that are you looking to > contribute. This project requires all contributions to be sent on Yes, I'm hoping that my post begins that discussion. > the mailing list or hosted on locations such as cr.openjdk.java.net. I'll attempt to attach all 25 commits now. I hope the list will accept them. I will post them (and webrev) to cr.openjdk.java.net. > From your mail then it sounds like you have a lot of changes so it's > probably best to start small, say with small fixes, until you've > gain some experience with the process of contributing and Our changes are broken up reasonably well -- they are not squashed into one big commit. Thus it is already possible to review small ones first. A lot of these changes are interrelated. Reviewing them in order of size might require rebasing our stack of commits, and may not be entirely possible. We're extremely familiar with this code as we have been patching the JGSS stack this way for years (we have developed these patches for JDKs 7, 8, 9, 10, 11, and the current 12 master), and we have been running this in production (with JDKs 7, 8, and 9, and soon 11) on Linux and Windows (our patches for earlier versions add native GSS support on Windows much as Weijun did for JDK 11, which we then use with the SAP GSS->SSPI bridge, our fork of which is here: https://github.com/twosigma/gsskrb5). FWIW, regarding credentials, Viktor and I are part of the Heimdal team, and we contribute to MIT Kerberos, and I have authored Internet RFCs in the GSS-API space, thus we're extremely familiar with the GSS-API in general and several implementation in particular. Also, I am familiar with the JGSS team as I used to work in Solaris security engineering 2002-2008 (and continued in Solaris engineering, just not security, for another two years), and I know the engineers working on JGSS well enough from back then (e.g., Weijun Wang, Valerie Peng), and I've stayed in touch with Weijun Wang since leaving Oracle. We're also maintainers or contributors to a number of GSS-API applications, including the SSHv2 GSS keyex implementation in PuTTY, similar patches for OpenSSH, and so on. Lastly, Viktor is a member of the OpenSSL core team, contributed DANE support, and is a co-maintainer of Postfix among other things. > sponsors/reviewers build up confidence in the changes. I suspect you We're hoping Weijun or Valerie can sponsor this. > will have the experience of doing significantly better than showing > up with large patch that add features and changes large areas of > JGSS. Starting small is really important for sponsors and reviewers > as the review and testing effort for many contributions can be > significant. There was no way to avoid showing up with a large set of patches. The problems we're fixing run deep and are interrelated, and indeed, we're not entirely done fixing problems that run deep, but we are done fixing all the problems that we care about, thus our commentary-only commits. In particular, we're not addressing the lack of generality in ServicePermission. See, GSS-API is supposed to be a pluggable security mechanism abstraction, and each security mechanism can have different ways of naming entities, but ServicePermission is entirely Kerberos-specific, and there are a number of places where ServicePermissions are checked if and only if Kerberos was used but not if something else was used. It is clearly not correct to skip these permission checks just because ServicePermission does not support non-Kerberos mechanisms, but ServicePermission could have been designed to -and could be updated to- to support them. Now, we could have shown up quite a while back, but for a variety of reasons that are not germane here, we ended up not being able to do so until now. I'd like to start by reviewing the important changes at an abstract level: - making GSSName extend Principal I don't think this should be controversial in the least, but probably will require discussion. This is one way in which JGSS problems run deep: by not making GSSName extend Principal, it is not possible to use native GSS with JAAS. - adding GssLoginModule This is the other way in which the problems we're fixing run deep: GSS-API is supposed to be pluggable as to security mechanisms, but the JGSS / Krb5 stack is very Kerberos-specific. It should always have been GssLoginModule, not Krb5lOginModule, not least because the Krb5 non-GSS interfaces are mostly not exposed. Similar lack of generality exists in ServicePermission, about which more below. Nico -- From Nico.Williams at twosigma.com Wed Oct 3 21:30:57 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 3 Oct 2018 21:30:57 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20181003204928.GA26310@twosigma.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> Message-ID: <20181003213057.GB26310@twosigma.com> On Wed, Oct 03, 2018 at 08:49:28PM +0000, Nico Williams wrote: > I'll attempt to attach all 25 commits now. I hope the list will accept > them. I will post them (and webrev) to cr.openjdk.java.net. And... I forgot to attach them. Let's try again. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-missing-dbgsysGetLastErrorString.patch Type: text/x-diff Size: 1890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-JGSS-Fix-cut-paste-error-in-NativeUtil.c.patch Type: text/x-diff Size: 968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Fix-error-handling-in-GSSLibStub.patch Type: text/x-diff Size: 23762 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Implement-String-to-gss_buffer_t-import.patch Type: text/x-diff Size: 5380 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Revert-initGSSBuffer-to-JDK7-non-copy-behaviour.patch Type: text/x-diff Size: 13403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Fix-loss-of-GSS_S_FAILURE-major-status-in-importCont.patch Type: text/x-diff Size: 1054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Add-actual-mechanism-to-native-GSSNameElement-state.patch Type: text/x-diff Size: 10862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Add-getLocalName-GSSName-method.patch Type: text/x-diff Size: 13926 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Add-createCredential-with-password.patch Type: text/x-diff Size: 39219 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-JGSS-Don-t-dispose-of-creds-too-eagerly.patch Type: text/x-diff Size: 4369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-Fix-SpNego-multi-round-trip-bug.patch Type: text/x-diff Size: 6126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-JGSS-Add-comment-about-unnec.-perm-check.patch Type: text/x-diff Size: 1307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0013-ServicePermission-empty-realm-support.patch Type: text/x-diff Size: 3015 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0014-Add-isDefaultCredential-method-to-GSSCredentialSpi.patch Type: text/x-diff Size: 10063 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0015-JGSS-Prefer-default-cred-handles-if-possible.patch Type: text/x-diff Size: 4473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0016-Make-GSSName-implement-Principal-add-getName.patch Type: text/x-diff Size: 5244 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0017-Add-GssLoginModule.patch Type: text/x-diff Size: 25473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018-Engage-GssLoginModule-only-when-native-true.patch Type: text/x-diff Size: 10619 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0019-Krb5LoginModule-cleanup.patch Type: text/x-diff Size: 26717 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0020-fixup-SEAM-bug-uncomments.patch Type: text/x-diff Size: 2146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0021-Fix-leak-in-exception-cases-in-getJavaOID.patch Type: text/x-diff Size: 1563 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0022-FIXME-commentary.patch Type: text/x-diff Size: 3914 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0023-Add-commentary-about-permissions-checks.patch Type: text/x-diff Size: 2380 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0024-JGSS-Simplify-context-permissions-checks.patch Type: text/x-diff Size: 7126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0025-Dispose-of-delegated-cred-handles-early.patch Type: text/x-diff Size: 2377 bytes Desc: not available URL: From valerie.peng at oracle.com Wed Oct 3 22:13:55 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 3 Oct 2018 15:13:55 -0700 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20181003213057.GB26310@twosigma.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181003213057.GB26310@twosigma.com> Message-ID: <5a013549-0d7a-c23a-f345-d7fa51354193@oracle.com> Hi Nico, Thanks for submitting the patches, Max is off on Chinese holidays til 7th and I am going to be on vacation til 19th. I suppose no bugs have been filed for these issues? Max and I will take a look upon our return. Regards, Valerie On 10/3/2018 2:30 PM, Nico Williams wrote: > On Wed, Oct 03, 2018 at 08:49:28PM +0000, Nico Williams wrote: >> I'll attempt to attach all 25 commits now. I hope the list will accept >> them. I will post them (and webrev) to cr.openjdk.java.net. > And... I forgot to attach them. Let's try again. From weijun.wang at oracle.com Wed Oct 3 22:20:14 2018 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 4 Oct 2018 06:20:14 +0800 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <5a013549-0d7a-c23a-f345-d7fa51354193@oracle.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181003213057.GB26310@twosigma.com> <5a013549-0d7a-c23a-f345-d7fa51354193@oracle.com> Message-ID: Yes, I am on vacation now. When I?m back, I?ll post your changes to cr.openjdk.java.net first. Thanks Max > ? 2018?10?4??06:13?Valerie Peng ??? > > Hi Nico, > > Thanks for submitting the patches, Max is off on Chinese holidays til 7th and I am going to be on vacation til 19th. > > I suppose no bugs have been filed for these issues? Max and I will take a look upon our return. > > Regards, > > Valerie > > >> On 10/3/2018 2:30 PM, Nico Williams wrote: >>> On Wed, Oct 03, 2018 at 08:49:28PM +0000, Nico Williams wrote: >>> I'll attempt to attach all 25 commits now. I hope the list will accept >>> them. I will post them (and webrev) to cr.openjdk.java.net. >> And... I forgot to attach them. Let's try again. > From Nico.Williams at twosigma.com Wed Oct 3 22:45:02 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 3 Oct 2018 22:45:02 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <5a013549-0d7a-c23a-f345-d7fa51354193@oracle.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181003213057.GB26310@twosigma.com> <5a013549-0d7a-c23a-f345-d7fa51354193@oracle.com> Message-ID: <20181003224502.GD26310@twosigma.com> On Wed, Oct 03, 2018 at 03:13:55PM -0700, Valerie Peng wrote: > Thanks for submitting the patches, Max is off on Chinese holidays > til 7th and I am going to be on vacation til 19th. > > I suppose no bugs have been filed for these issues? Max and I will > take a look upon our return. Great! And I saw Weijun's reply as well. Thanks! Enjoy your vacation, Nico -- From stuart.marks at oracle.com Wed Oct 3 23:11:33 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 3 Oct 2018 16:11:33 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> Message-ID: <53d9515a-f74b-ef6e-a30c-8b28d3b18169@oracle.com> Hi Sean, The new arrangement of using special tokens for java.security.manager makes a lot more sense than having a separate property. Overall, the proposed semantics seem reasonable to me. I have some suggestions to clarify the proposed specification. (But also see below.) From webrev.01: 81 * Environments using a security manager will typically set the security 82 * manager at startup. In the JDK implementation, this is done by setting 83 * the system property "{@code java.security.manager}" on the command line to 84 * the class name of the security manager, or to the empty String ("") 85 * or "{@code default}" to utilize the default security manager. 86 * If the "{@code java.security.manager}" system property is not set, the 87 * default value is {@code null}, which means a security manager will not be 88 * installed at startup. I'd suggest using the term "special token" to describe the string "default" here, to make it clear that this string is interpreted specially and is not interpreted as a security manager class name. (The FilePermission docs use the term "special token" to describe "<>".) Similarly, I'd suggest "special token" be used to describe "allow" and "disallow" below. 93 * In the JDK implementation, if the Java virtual machine is started with 94 * the "{@code java.security.manager}" system property set to 95 * "{@code =disallow}" then the 96 * {@link System#setSecurityManager(SecurityManager) setSecurityManager} 97 * method cannot be used to set a security manager and will throw an 98 * {@code UnsupportedOperationException}. The ability to dynamically set the (I assume this will be changed from "=disallow" to "disallow" and similar for "allow" below.) This should clarify that if "disallow" is used then no security manager will be installed, in addition to preventing one from being installed in the future. 98 * The ability to dynamically set the 99 * security manager in a running system is an impediment to some performance 100 * optimizations, even if the method is never called. While I think this is true, it's a bit of rationale stuck into the middle of the specification for the values of the system property, and as such it sticks out. It kind of begs for more explanation. I'd suggest removing it. 100 * If a security manager is 101 * set at startup, or if the property is set to "{@code =allow}", then a 102 * security manager can be set dynamically. I'd split this into two (or multiple) sentences, because there's actually a lot going on here. If the property is set to the special token "allow", no security manager is installed at startup, but one can be set dynamically using the setSecurityManager method. (Right?) I think there are more cases that need to be covered than just "allow". If the property is set to "allow", the class name of a security manager, the empty string "", or the special token "default", then the setSecurityManager() method can be used to attempt to set the security manager dynamically. However, an already-installed security manager may refuse this request. (Right?) ** Whew, this is kind of a lot. The reason is that there are several different values that the property can be set to, and they have an effect on the initial SM that's set AND an effect on the behavior of calls to setSecurityManager() at runtime. To get this straight, I wrote down a table: Prop Value SM installed initially setSecurityManager() works ------------------------------------------------------------------------------ null none yes empty string java.lang.SecurityManager maybe "default" java.lang.SecurityManager maybe "disallow" none no "allow" none yes a class name the named class maybe Note: "maybe" means that setSecurityManager() will attempt to set the SM, in that it won't throw UOE; however, the current SM might disallow it depending upon its policies and the privilege of the caller. From this table one can see that setting the property to the empty string and to "default" have identical effects. Also, not setting the property (i.e., its value is null) and setting it to "allow" have the same effects. Did I get this right? Anyway, you can describe all of this in prose, but it has to be worded very carefully in order to get all the details right. Or, you could put a table directly into the spec. Or both! Up to you how you want to proceed. ** An aside, possibly off topic. If the j.s.m property names a class that's to be used as the security manager, presumably it must be a j.l.SecurityManager or a subclass. Are there other requirements, such as having a public no-arg constructor? Does the class need to be public, and does it need to be in exported package or anything? Is the classpath or the module path searched, and if the alternative SM is in a named module, is there a syntax for naming it? Sorry for all the impertinent questions; I can't find where this is documented. Feel free to redirect. s'marks On 10/2/18 8:34 AM, Sean Mullan wrote: > Thanks for all the comments so far, and the interesting discussions about the > future of the SecurityManager. We will definitely return to those discussions in > the near future, but for now I have a second webrev ready for review for this > enhancement: > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ > > The main changes since the initial revision are: > > 1. System.setSecurityManager is no longer deprecated. This type of change > clearly needs more discussion and is not an essential part of this RFE. > > 2. After further thought, I took Bernd's suggestion [1] and instead of adding a > new property to disallow the setting of a SecurityManager at runtime, have added > new tokens to the existing "java.security.manager" system property, named > "=disallow", and "=allow" to toggle this behavior. The "=" is to avoid any > potential clashes with custom SM classes with those names. I think this is a > cleaner approach. There are a couple of new paragraphs in the SecurityManager > class description describing the "java.security.manager" property and how the > new tokens work. > > 3. I also added a comment that Bernd had requested [2] on why > System.setSecurityManager calls checkPackageAccess("java.lang"). > > Also, the CSR has been updated: https://bugs.openjdk.java.net/browse/JDK-8203316 > > Thanks, > Sean > > [1] http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html > [2] http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html > > On 9/13/18 4:02 PM, Sean Mullan wrote: >> This is a SecurityManager related change which warrants some additional >> details for its motivation. >> >> The current System.setSecurityManager() API allows a SecurityManager to be set >> at run-time. However, because of this mutability, it incurs a performance >> overhead even for applications that never call it and do not enable a >> SecurityManager dynamically, which is probably the majority of applications. >> >> For example, there are lots of "SecurityManager sm = >> System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If it was >> known that a SecurityManager could never be set at run-time, these checks >> could be optimized using constant-folding. >> >> There are essentially two main parts to this change: >> >> 1. Deprecation of System.securityManager() >> >> Going forward, we want to discourage applications from calling >> System.setSecurityManager(). Instead they should enable a SecurityManager >> using the java.security.manager system property on the command-line. >> >> 2. A new JDK-specific system property to disallow the setting of the security >> manager at run-time: jdk.allowSecurityManager >> >> If set to false, it allows the run-time to optimize the code and improve >> performance when it is known that an application will never run with a >> SecurityManager. To support this behavior, the System.setSecurityManager() API >> has been updated such that it can throw an UnsupportedOperationException if it >> does not allow a security manager to be set dynamically. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 >> >> (I will likely also send this to core-libs for additional review later) >> >> --Sean From Sergey.Bylokhov at oracle.com Thu Oct 4 00:52:16 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 3 Oct 2018 17:52:16 -0700 Subject: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <1b22437e-69ff-54a3-81b9-ccd6a0782629@oracle.com> References: <1b22437e-69ff-54a3-81b9-ccd6a0782629@oracle.com> Message-ID: <189f3e88-44e8-f297-1b73-02dd73a79fad@oracle.com> Hi, Sean. One question related to SecurityManager and performance, is it possible to provide a special version of AccessController.doPrivileged which will be noop if SecurityManager is not present? On 03/10/2018 13:12, Sean Mullan wrote: > For those of you that are not also subscribed to security-dev, this is > mostly FYI, as the review is winding down, but if you have any comments, > let me know. > > This change will add new token options ("allow" and "disallow") to the > java.security.manager system property. The "disallow" option is intended > to provide a potential performance boost for applications that don't > enable a SecurityManager, as there is a cost associated with allowing a > SecurityManager to enabled at runtime, even if it is never enabled. The > CSR provides a good summary of the issue and spec changes: > https://bugs.openjdk.java.net/browse/JDK-8203316 > > Thanks, > Sean > > -------- Forwarded Message -------- > Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's > security manager immutable > Date: Tue, 2 Oct 2018 11:34:09 -0400 > From: Sean Mullan > Organization: Oracle Corporation > To: security Dev OpenJDK > > Hello, > > Thanks for all the comments so far, and the interesting discussions > about the future of the SecurityManager. We will definitely return to > those discussions in the near future, but for now I have a second webrev > ready for review for this enhancement: > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ > > The main changes since the initial revision are: > > 1. System.setSecurityManager is no longer deprecated. This type of > change clearly needs more discussion and is not an essential part of > this RFE. > > 2. After further thought, I took Bernd's suggestion [1] and instead of > adding a new property to disallow the setting of a SecurityManager at > runtime, have added new tokens to the existing "java.security.manager" > system property, named "=disallow", and "=allow" to toggle this > behavior. The "=" is to avoid any potential clashes with custom SM > classes with those names. I think this is a cleaner approach. There are > a couple of new paragraphs in the SecurityManager class description > describing the "java.security.manager" property and how the new tokens > work. > > 3. I also added a comment that Bernd had requested [2] on why > System.setSecurityManager calls checkPackageAccess("java.lang"). > > Also, the CSR has been updated: > https://bugs.openjdk.java.net/browse/JDK-8203316 > > Thanks, > Sean > > [1] > http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html > > > On 9/13/18 4:02 PM, Sean Mullan wrote: >> This is a SecurityManager related change which warrants some >> additional details for its motivation. >> >> The current System.setSecurityManager() API allows a SecurityManager >> to be set at run-time. However, because of this mutability, it incurs >> a performance overhead even for applications that never call it and do >> not enable a SecurityManager dynamically, which is probably the >> majority of applications. >> >> For example, there are lots of "SecurityManager sm = >> System.getSecurityManager(); if (sm != null) ..." checks in the JDK. >> If it was known that a SecurityManager could never be set at run-time, >> these checks could be optimized using constant-folding. >> >> There are essentially two main parts to this change: >> >> 1. Deprecation of System.securityManager() >> >> Going forward, we want to discourage applications from calling >> System.setSecurityManager(). Instead they should enable a >> SecurityManager using the java.security.manager system property on the >> command-line. >> >> 2. A new JDK-specific system property to disallow the setting of the >> security manager at run-time: jdk.allowSecurityManager >> >> If set to false, it allows the run-time to optimize the code and >> improve performance when it is known that an application will never >> run with a SecurityManager. To support this behavior, the >> System.setSecurityManager() API has been updated such that it can >> throw an UnsupportedOperationException if it does not allow a security >> manager to be set dynamically. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 >> >> (I will likely also send this to core-libs for additional review later) >> >> --Sean -- Best regards, Sergey. From Alan.Bateman at oracle.com Thu Oct 4 10:19:06 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Oct 2018 11:19:06 +0100 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20181003204928.GA26310@twosigma.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> Message-ID: On 03/10/2018 21:49, Nico Williams wrote: > : > A lot of these changes are interrelated. Reviewing them in order of > size might require rebasing our stack of commits, and may not be > entirely possible. > > We're extremely familiar with this code as we have been patching the > JGSS stack this way for years (we have developed these patches for JDKs > 7, 8, 9, 10, 11, and the current 12 master), and we have been running > this in production (with JDKs 7, 8, and 9, and soon 11) Just a few high-level points on the patches that you attached: 1. It's important to take sponsor/Reviewer effort into account. I skimmed through some of the 25 patches and they lack a detailed description on what the issue is about. JGSS gurus might recognize some of these issues from the diffs but I suspect you (or Victor) will need to match the patches to existing issues in JIRA or else get bugs submitted so that there is a description for each issue in the bug database. 2. I skimmed the patches and didn't see any tests or changes to existing tests. This may come up in the discussion of each change as the default position is for all bug fixes should have tests where feasible. 3. I see the patches include at least some API changes so the sponsor will need to submit a CSR for approval. API changes are only allowed in feature releases. -Alan From sean.mullan at oracle.com Thu Oct 4 12:50:14 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 4 Oct 2018 08:50:14 -0400 Subject: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <189f3e88-44e8-f297-1b73-02dd73a79fad@oracle.com> References: <1b22437e-69ff-54a3-81b9-ccd6a0782629@oracle.com> <189f3e88-44e8-f297-1b73-02dd73a79fad@oracle.com> Message-ID: <0a8fa2f0-07de-ada6-8331-ea9d3c054365@oracle.com> On 10/3/18 8:52 PM, Sergey Bylokhov wrote: > Hi, Sean. > One question related to SecurityManager and performance, is it possible > to provide a special version of AccessController.doPrivileged which will > be noop if SecurityManager is not present? Yes, it may be possible, and we have prototyped it. But I didn't want to mix it up with this one as it has some different specification challenges -- for example, the AccessController APIs can be used independently of the SecurityManager. I plan to get back to this one soon and hope to have something that can be reviewed a bit later. Thanks, Sean > > On 03/10/2018 13:12, Sean Mullan wrote: >> For those of you that are not also subscribed to security-dev, this is >> mostly FYI, as the review is winding down, but if you have any >> comments, let me know. >> >> This change will add new token options ("allow" and "disallow") to the >> java.security.manager system property. The "disallow" option is >> intended to provide a potential performance boost for applications >> that don't enable a SecurityManager, as there is a cost associated >> with allowing a SecurityManager to enabled at runtime, even if it is >> never enabled. The CSR provides a good summary of the issue and spec >> changes: https://bugs.openjdk.java.net/browse/JDK-8203316 >> >> Thanks, >> Sean >> >> -------- Forwarded Message -------- >> Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's >> security manager immutable >> Date: Tue, 2 Oct 2018 11:34:09 -0400 >> From: Sean Mullan >> Organization: Oracle Corporation >> To: security Dev OpenJDK >> >> Hello, >> >> Thanks for all the comments so far, and the interesting discussions >> about the future of the SecurityManager. We will definitely return to >> those discussions in the near future, but for now I have a second >> webrev ready for review for this enhancement: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ >> >> The main changes since the initial revision are: >> >> 1. System.setSecurityManager is no longer deprecated. This type of >> change clearly needs more discussion and is not an essential part of >> this RFE. >> >> 2. After further thought, I took Bernd's suggestion [1] and instead of >> adding a new property to disallow the setting of a SecurityManager at >> runtime, have added new tokens to the existing "java.security.manager" >> system property, named "=disallow", and "=allow" to toggle this >> behavior. The "=" is to avoid any potential clashes with custom SM >> classes with those names. I think this is a cleaner approach. There >> are a couple of new paragraphs in the SecurityManager class >> description describing the "java.security.manager" property and how >> the new tokens work. >> >> 3. I also added a comment that Bernd had requested [2] on why >> System.setSecurityManager calls checkPackageAccess("java.lang"). >> >> Also, the CSR has been updated: >> https://bugs.openjdk.java.net/browse/JDK-8203316 >> >> Thanks, >> Sean >> >> [1] >> http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html >> >> >> On 9/13/18 4:02 PM, Sean Mullan wrote: >>> This is a SecurityManager related change which warrants some >>> additional details for its motivation. >>> >>> The current System.setSecurityManager() API allows a SecurityManager >>> to be set at run-time. However, because of this mutability, it incurs >>> a performance overhead even for applications that never call it and >>> do not enable a SecurityManager dynamically, which is probably the >>> majority of applications. >>> >>> For example, there are lots of "SecurityManager sm = >>> System.getSecurityManager(); if (sm != null) ..." checks in the JDK. >>> If it was known that a SecurityManager could never be set at >>> run-time, these checks could be optimized using constant-folding. >>> >>> There are essentially two main parts to this change: >>> >>> 1. Deprecation of System.securityManager() >>> >>> Going forward, we want to discourage applications from calling >>> System.setSecurityManager(). Instead they should enable a >>> SecurityManager using the java.security.manager system property on >>> the command-line. >>> >>> 2. A new JDK-specific system property to disallow the setting of the >>> security manager at run-time: jdk.allowSecurityManager >>> >>> If set to false, it allows the run-time to optimize the code and >>> improve performance when it is known that an application will never >>> run with a SecurityManager. To support this behavior, the >>> System.setSecurityManager() API has been updated such that it can >>> throw an UnsupportedOperationException if it does not allow a >>> security manager to be set dynamically. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 >>> >>> (I will likely also send this to core-libs for additional review later) >>> >>> --Sean > > From david.lloyd at redhat.com Thu Oct 4 14:17:49 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 4 Oct 2018 09:17:49 -0500 Subject: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <189f3e88-44e8-f297-1b73-02dd73a79fad@oracle.com> References: <1b22437e-69ff-54a3-81b9-ccd6a0782629@oracle.com> <189f3e88-44e8-f297-1b73-02dd73a79fad@oracle.com> Message-ID: On Wed, Oct 3, 2018 at 7:53 PM Sergey Bylokhov wrote: > Hi, Sean. > One question related to SecurityManager and performance, is it possible > to provide a special version of AccessController.doPrivileged which will > be noop if SecurityManager is not present? TBH that method (at least, the no-arg variant) should *always* have been a no-op. All it really accomplishes, in practice, is to place a mark on the stack where the stack crawl to build the access control context should stop (plus one frame), and this effect is something that is already a natural consequence of a method being called in the JVM. The doPrivileged variant that accepts an ACC parameter should likewise always have been no-op other than stashing the nested ACC into some sort of thread-local (or better, a field on Thread) which can be referred to by the aforementioned stack crawl. The pure-java AccessController I prototyped late last year relies on these ideas, among other things. -- - DML From Nico.Williams at twosigma.com Thu Oct 4 17:15:47 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Thu, 4 Oct 2018 17:15:47 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> Message-ID: <20181004171547.GE26310@twosigma.com> On Thu, Oct 04, 2018 at 11:19:06AM +0100, Alan Bateman wrote: > On 03/10/2018 21:49, Nico Williams wrote: > >: > >A lot of these changes are interrelated. Reviewing them in order of > >size might require rebasing our stack of commits, and may not be > >entirely possible. > > > >We're extremely familiar with this code as we have been patching the > >JGSS stack this way for years (we have developed these patches for JDKs > >7, 8, 9, 10, 11, and the current 12 master), and we have been running > >this in production (with JDKs 7, 8, and 9, and soon 11) > Just a few high-level points on the patches that you attached: > > 1. It's important to take sponsor/Reviewer effort into account. I > skimmed through some of the 25 patches and they lack a detailed > description on what the issue is about. JGSS gurus might recognize > some of these issues from the diffs but I suspect you (or Victor) > will need to match the patches to existing issues in JIRA or else > get bugs submitted so that there is a description for each issue in > the bug database. We've pointed out that we need bugs filed. We'll work with Weijun to get them filed when he's back from vacation. > 2. I skimmed the patches and didn't see any tests or changes to > existing tests. This may come up in the discussion of each change as > the default position is for all bug fixes should have tests where > feasible. That's an existing problem in the codebase. The tests are very limited as it is, and testing GSS/Kerberos requires mocking up a KDC, which requires more complex test infrastructure. > 3. I see the patches include at least some API changes so the > sponsor will need to submit a CSR for approval. API changes are only > allowed in feature releases. That's fine. Nico -- From sean.mullan at oracle.com Thu Oct 4 21:04:16 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 4 Oct 2018 17:04:16 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <53d9515a-f74b-ef6e-a30c-8b28d3b18169@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <53d9515a-f74b-ef6e-a30c-8b28d3b18169@oracle.com> Message-ID: Excellent comments, Stuart. Thanks for taking the time to review this. I have posted another review that should address most of your comments, but also responded inline with replies below. http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/ I also posted the javadoc so you can see what it looks like, esp. the table: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/docs/api/java.base/java/lang/SecurityManager.html http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/docs/api/java.base/java/lang/System.html On 10/3/18 7:11 PM, Stuart Marks wrote: > Hi Sean, > > The new arrangement of using special tokens for java.security.manager > makes a lot more sense than having a separate property. Overall, the > proposed semantics seem reasonable to me. > > > I have some suggestions to clarify the proposed specification. (But also > see below.) From webrev.01: > > ? 81? * Environments using a security manager will typically set the > security > ? 82? * manager at startup. In the JDK implementation, this is done by > setting > ? 83? * the system property "{@code java.security.manager}" on the > command line to > ? 84? * the class name of the security manager, or to the empty String > ("") > ? 85? * or "{@code default}" to utilize the default security manager. > ? 86? * If the "{@code java.security.manager}" system property is not > set, the > ? 87? * default value is {@code null}, which means a security manager > will not be > ? 88? * installed at startup. > > I'd suggest using the term "special token" to describe the string > "default" here, to make it clear that this string is interpreted > specially and is not interpreted as a security manager class name. (The > FilePermission docs use the term "special token" to describe "< FILES>>".) > > Similarly, I'd suggest "special token" be used to describe "allow" and > "disallow" below. Good suggestion, I added "special token" to those places as well as to the reference to "disallow" in System.setSecurityManager. I also broke up the first sentence above on lines 81-85 in two sentences to make it easier to read. > ? 93? * In the JDK implementation, if the Java virtual machine is > started with > ? 94? * the "{@code java.security.manager}" system property set to > ? 95? * "{@code =disallow}" then the > ? 96? * {@link System#setSecurityManager(SecurityManager) > setSecurityManager} > ? 97? * method cannot be used to set a security manager and will throw an > ? 98? * {@code UnsupportedOperationException}. The ability to > dynamically set the > > (I assume this will be changed from "=disallow" to "disallow" and > similar for "allow" below.) Oops. Yes. I had fixed that but forgot to upload it in the webrev. Fixed now. > This should clarify that if "disallow" is used then no security manager > will be installed, in addition to preventing one from being installed in > the future. Yes, fixed. > ? 98? *??????????????????????????????????????? The ability to > dynamically set the > ? 99? * security manager in a running system is an impediment to some > performance > ?100? * optimizations, even if the method is never called. > > While I think this is true, it's a bit of rationale stuck into the > middle of the specification for the values of the system property, and > as such it sticks out. It kind of begs for more explanation. I'd suggest > removing it. I was on the fence about including that as well. I have removed it (and also from the implNote in System.setSecurityManager). I think the JBS issue is the best place to keep this type of information for now. > ?100? *???????????????????????????????????????????????? If a security > manager is > ?101? * set at startup, or if the property is set to "{@code =allow}", > then a > ?102? * security manager can be set dynamically. > > I'd split this into two (or multiple) sentences, because there's > actually a lot going on here. > > If the property is set to the special token "allow", no security manager > is installed at startup, but one can be set dynamically using the > setSecurityManager method. (Right?) Correct. > I think there are more cases that need to be covered than just "allow". > If the property is set to "allow", the class name of a security manager, > the empty string "", or the special token "default", then the > setSecurityManager() method can be used to attempt to set the security > manager dynamically. However, an already-installed security manager may > refuse this request. (Right?) Correct. Initially I was a bit reluctant to document the behavior of System.setSecurityManager for all the different property values. It also depends on whether you are calling it for the first time or not. The only real difference in behavior is if "disallow" is set. Otherwise, it works exactly as the API is specified. But I can see how it can cause confusion since there are many different options for java.security.manager now. > ** > > Whew, this is kind of a lot. The reason is that there are several > different values that the property can be set to, and they have an > effect on the initial SM that's set AND an effect on the behavior of > calls to setSecurityManager() at runtime. To get this straight, I wrote > down a table: > > > Prop Value????????? SM installed initially????????? setSecurityManager() > works > ------------------------------------------------------------------------------ > > null??????????????? none??????????????????????????? yes > empty string??????? java.lang.SecurityManager?????? maybe > "default"?????????? java.lang.SecurityManager?????? maybe > "disallow"????????? none??????????????????????????? no > "allow"???????????? none??????????????????????????? yes > a class name??????? the named class???????????????? maybe > > > Note: "maybe" means that setSecurityManager() will attempt to set the > SM, in that it won't throw UOE; however, the current SM might disallow > it depending upon its policies and the privilege of the caller. > > From this table one can see that setting the property to the empty > string and to "default" have identical effects. Also, not setting the > property (i.e., its value is null) and setting it to "allow" have the > same effects. Did I get this right? Yes, more or less. For the "yes" boxes, it is only if you assume it is the first time it is called and null is not the value of SM. > Anyway, you can describe all of this in prose, but it has to be worded > very carefully in order to get all the details right. Or, you could put > a table directly into the spec. Or both! Up to you how you want to proceed. I did both! For the table, my main issue was how to document the last column, and whether to assume setSecurityManager was being called for the first time or not. I assumed it was not, because this is really about static vs dynamic and not about how many times an SM can be set. > ** > > An aside, possibly off topic. If the j.s.m property names a class that's > to be used as the security manager, presumably it must be a > j.l.SecurityManager or a subclass. Are there other requirements, such as > having a public no-arg constructor? Does the class need to be public, > and does it need to be in exported package or anything? Is the classpath > or the module path searched, and if the alternative SM is in a named > module, is there a syntax for naming it? I don't think the package needs to be exported - it looks like the code tries to work around that by using reflection. It can be in a named or unnamed module. I have kept it simple and added these 2 sentences: "If a class name is specified, it must be java.lang.SecurityManager or a public subclass and have a public no-arg constructor. The class is loaded by the system class loader." We could revisit this later if it should be more precise. --Sean > > Sorry for all the impertinent questions; I can't find where this is > documented. Feel free to redirect. > > s'marks > > > > > > > > > > On 10/2/18 8:34 AM, Sean Mullan wrote: >> Thanks for all the comments so far, and the interesting discussions >> about the future of the SecurityManager. We will definitely return to >> those discussions in the near future, but for now I have a second >> webrev ready for review for this enhancement: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ >> >> The main changes since the initial revision are: >> >> 1. System.setSecurityManager is no longer deprecated. This type of >> change clearly needs more discussion and is not an essential part of >> this RFE. >> >> 2. After further thought, I took Bernd's suggestion [1] and instead of >> adding a new property to disallow the setting of a SecurityManager at >> runtime, have added new tokens to the existing "java.security.manager" >> system property, named "=disallow", and "=allow" to toggle this >> behavior. The "=" is to avoid any potential clashes with custom SM >> classes with those names. I think this is a cleaner approach. There >> are a couple of new paragraphs in the SecurityManager class >> description describing the "java.security.manager" property and how >> the new tokens work. >> >> 3. I also added a comment that Bernd had requested [2] on why >> System.setSecurityManager calls checkPackageAccess("java.lang"). >> >> Also, the CSR has been updated: >> https://bugs.openjdk.java.net/browse/JDK-8203316 >> >> Thanks, >> Sean >> >> [1] >> http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html >> >> >> On 9/13/18 4:02 PM, Sean Mullan wrote: >>> This is a SecurityManager related change which warrants some >>> additional details for its motivation. >>> >>> The current System.setSecurityManager() API allows a SecurityManager >>> to be set at run-time. However, because of this mutability, it incurs >>> a performance overhead even for applications that never call it and >>> do not enable a SecurityManager dynamically, which is probably the >>> majority of applications. >>> >>> For example, there are lots of "SecurityManager sm = >>> System.getSecurityManager(); if (sm != null) ..." checks in the JDK. >>> If it was known that a SecurityManager could never be set at >>> run-time, these checks could be optimized using constant-folding. >>> >>> There are essentially two main parts to this change: >>> >>> 1. Deprecation of System.securityManager() >>> >>> Going forward, we want to discourage applications from calling >>> System.setSecurityManager(). Instead they should enable a >>> SecurityManager using the java.security.manager system property on >>> the command-line. >>> >>> 2. A new JDK-specific system property to disallow the setting of the >>> security manager at run-time: jdk.allowSecurityManager >>> >>> If set to false, it allows the run-time to optimize the code and >>> improve performance when it is known that an application will never >>> run with a SecurityManager. To support this behavior, the >>> System.setSecurityManager() API has been updated such that it can >>> throw an UnsupportedOperationException if it does not allow a >>> security manager to be set dynamically. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 >>> >>> (I will likely also send this to core-libs for additional review later) >>> >>> --Sean From stuart.marks at oracle.com Thu Oct 4 21:56:00 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 4 Oct 2018 14:56:00 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <53d9515a-f74b-ef6e-a30c-8b28d3b18169@oracle.com> Message-ID: Hi Sean, Thanks for the updates. Looks like the details are all there now. One minor point: 87 * If a class name is specified, it must be {@code java.lang.SecurityManager} 88 * or a public subclass and have a public no-arg constructor. The class is 89 * loaded by the {@linkplain ClassLoader#getSystemClassLoader() 90 * system class loader}. The class is loaded by the system class loader, only if the class name is something other than "java.lang.SecurityManager". Editorial: 83 * the system property "{@code java.security.manager}" on the command line to Here and in several places, I don't think it's necessary to have the property name both in code font and in quotation marks. I think the code font is sufficient. Thanks, s'marks On 10/4/18 2:04 PM, Sean Mullan wrote: > Excellent comments, Stuart. Thanks for taking the time to review this. > > I have posted another review that should address most of your comments, but also > responded inline with replies below. > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/ > > I also posted the javadoc so you can see what it looks like, esp. the table: > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/docs/api/java.base/java/lang/SecurityManager.html > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/docs/api/java.base/java/lang/System.html > > > > On 10/3/18 7:11 PM, Stuart Marks wrote: >> Hi Sean, >> >> The new arrangement of using special tokens for java.security.manager makes a >> lot more sense than having a separate property. Overall, the proposed >> semantics seem reasonable to me. >> >> >> I have some suggestions to clarify the proposed specification. (But also see >> below.) From webrev.01: >> >> ?? 81? * Environments using a security manager will typically set the security >> ?? 82? * manager at startup. In the JDK implementation, this is done by setting >> ?? 83? * the system property "{@code java.security.manager}" on the command >> line to >> ?? 84? * the class name of the security manager, or to the empty String ("") >> ?? 85? * or "{@code default}" to utilize the default security manager. >> ?? 86? * If the "{@code java.security.manager}" system property is not set, the >> ?? 87? * default value is {@code null}, which means a security manager will >> not be >> ?? 88? * installed at startup. >> >> I'd suggest using the term "special token" to describe the string "default" >> here, to make it clear that this string is interpreted specially and is not >> interpreted as a security manager class name. (The FilePermission docs use the >> term "special token" to describe "<>".) >> >> Similarly, I'd suggest "special token" be used to describe "allow" and >> "disallow" below. > > Good suggestion, I added "special token" to those places as well as to the > reference to "disallow" in System.setSecurityManager. I also broke up the first > sentence above on lines 81-85 in two sentences to make it easier to read. > >> ?? 93? * In the JDK implementation, if the Java virtual machine is started with >> ?? 94? * the "{@code java.security.manager}" system property set to >> ?? 95? * "{@code =disallow}" then the >> ?? 96? * {@link System#setSecurityManager(SecurityManager) setSecurityManager} >> ?? 97? * method cannot be used to set a security manager and will throw an >> ?? 98? * {@code UnsupportedOperationException}. The ability to dynamically set >> the >> >> (I assume this will be changed from "=disallow" to "disallow" and similar for >> "allow" below.) > > Oops. Yes. I had fixed that but forgot to upload it in the webrev. Fixed now. > >> This should clarify that if "disallow" is used then no security manager will >> be installed, in addition to preventing one from being installed in the future. > > Yes, fixed. > >> ?? 98? *??????????????????????????????????????? The ability to dynamically set >> the >> ?? 99? * security manager in a running system is an impediment to some >> performance >> ??100? * optimizations, even if the method is never called. >> >> While I think this is true, it's a bit of rationale stuck into the middle of >> the specification for the values of the system property, and as such it sticks >> out. It kind of begs for more explanation. I'd suggest removing it. > > I was on the fence about including that as well. I have removed it (and also > from the implNote in System.setSecurityManager). I think the JBS issue is the > best place to keep this type of information for now. > >> ??100? *???????????????????????????????????????????????? If a security manager is >> ??101? * set at startup, or if the property is set to "{@code =allow}", then a >> ??102? * security manager can be set dynamically. >> >> I'd split this into two (or multiple) sentences, because there's actually a >> lot going on here. >> >> If the property is set to the special token "allow", no security manager is >> installed at startup, but one can be set dynamically using the >> setSecurityManager method. (Right?) > > Correct. > >> I think there are more cases that need to be covered than just "allow". If the >> property is set to "allow", the class name of a security manager, the empty >> string "", or the special token "default", then the setSecurityManager() >> method can be used to attempt to set the security manager dynamically. >> However, an already-installed security manager may refuse this request. (Right?) > > Correct. Initially I was a bit reluctant to document the behavior of > System.setSecurityManager for all the different property values. It also depends > on whether you are calling it for the first time or not. The only real > difference in behavior is if "disallow" is set. Otherwise, it works exactly as > the API is specified. But I can see how it can cause confusion since there are > many different options for java.security.manager now. > >> ** >> >> Whew, this is kind of a lot. The reason is that there are several different >> values that the property can be set to, and they have an effect on the initial >> SM that's set AND an effect on the behavior of calls to setSecurityManager() >> at runtime. To get this straight, I wrote down a table: >> >> >> Prop Value????????? SM installed initially????????? setSecurityManager() works >> ------------------------------------------------------------------------------ >> null??????????????? none??????????????????????????? yes >> empty string??????? java.lang.SecurityManager?????? maybe >> "default"?????????? java.lang.SecurityManager?????? maybe >> "disallow"????????? none??????????????????????????? no >> "allow"???????????? none??????????????????????????? yes >> a class name??????? the named class???????????????? maybe >> >> >> Note: "maybe" means that setSecurityManager() will attempt to set the SM, in >> that it won't throw UOE; however, the current SM might disallow it depending >> upon its policies and the privilege of the caller. >> >> ?From this table one can see that setting the property to the empty string and >> to "default" have identical effects. Also, not setting the property (i.e., its >> value is null) and setting it to "allow" have the same effects. Did I get this >> right? > > Yes, more or less. For the "yes" boxes, it is only if you assume it is the first > time it is called and null is not the value of SM. > >> Anyway, you can describe all of this in prose, but it has to be worded very >> carefully in order to get all the details right. Or, you could put a table >> directly into the spec. Or both! Up to you how you want to proceed. > > I did both! For the table, my main issue was how to document the last column, > and whether to assume setSecurityManager was being called for the first time or > not. I assumed it was not, because this is really about static vs dynamic and > not about how many times an SM can be set. >> ** >> >> An aside, possibly off topic. If the j.s.m property names a class that's to be >> used as the security manager, presumably it must be a j.l.SecurityManager or a >> subclass. Are there other requirements, such as having a public no-arg >> constructor? Does the class need to be public, and does it need to be in >> exported package or anything? Is the classpath or the module path searched, >> and if the alternative SM is in a named module, is there a syntax for naming it? > > I don't think the package needs to be exported - it looks like the code tries to > work around that by using reflection. It can be in a named or unnamed module. > > I have kept it simple and added these 2 sentences: "If a class name is > specified, it must be java.lang.SecurityManager or a public subclass and have a > public no-arg constructor. The class is loaded by the system class loader." We > could revisit this later if it should be more precise. > > --Sean > >> >> Sorry for all the impertinent questions; I can't find where this is >> documented. Feel free to redirect. >> >> s'marks >> >> >> >> >> >> >> >> >> >> On 10/2/18 8:34 AM, Sean Mullan wrote: >>> Thanks for all the comments so far, and the interesting discussions about the >>> future of the SecurityManager. We will definitely return to those discussions >>> in the near future, but for now I have a second webrev ready for review for >>> this enhancement: >>> >>> http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ >>> >>> The main changes since the initial revision are: >>> >>> 1. System.setSecurityManager is no longer deprecated. This type of change >>> clearly needs more discussion and is not an essential part of this RFE. >>> >>> 2. After further thought, I took Bernd's suggestion [1] and instead of adding >>> a new property to disallow the setting of a SecurityManager at runtime, have >>> added new tokens to the existing "java.security.manager" system property, >>> named "=disallow", and "=allow" to toggle this behavior. The "=" is to avoid >>> any potential clashes with custom SM classes with those names. I think this >>> is a cleaner approach. There are a couple of new paragraphs in the >>> SecurityManager class description describing the "java.security.manager" >>> property and how the new tokens work. >>> >>> 3. I also added a comment that Bernd had requested [2] on why >>> System.setSecurityManager calls checkPackageAccess("java.lang"). >>> >>> Also, the CSR has been updated: https://bugs.openjdk.java.net/browse/JDK-8203316 >>> >>> Thanks, >>> Sean >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html >>> [2] >>> http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html >>> >>> On 9/13/18 4:02 PM, Sean Mullan wrote: >>>> This is a SecurityManager related change which warrants some additional >>>> details for its motivation. >>>> >>>> The current System.setSecurityManager() API allows a SecurityManager to be >>>> set at run-time. However, because of this mutability, it incurs a >>>> performance overhead even for applications that never call it and do not >>>> enable a SecurityManager dynamically, which is probably the majority of >>>> applications. >>>> >>>> For example, there are lots of "SecurityManager sm = >>>> System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If it >>>> was known that a SecurityManager could never be set at run-time, these >>>> checks could be optimized using constant-folding. >>>> >>>> There are essentially two main parts to this change: >>>> >>>> 1. Deprecation of System.securityManager() >>>> >>>> Going forward, we want to discourage applications from calling >>>> System.setSecurityManager(). Instead they should enable a SecurityManager >>>> using the java.security.manager system property on the command-line. >>>> >>>> 2. A new JDK-specific system property to disallow the setting of the >>>> security manager at run-time: jdk.allowSecurityManager >>>> >>>> If set to false, it allows the run-time to optimize the code and improve >>>> performance when it is known that an application will never run with a >>>> SecurityManager. To support this behavior, the System.setSecurityManager() >>>> API has been updated such that it can throw an UnsupportedOperationException >>>> if it does not allow a security manager to be set dynamically. >>>> >>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 >>>> >>>> (I will likely also send this to core-libs for additional review later) >>>> >>>> --Sean From Alan.Bateman at oracle.com Fri Oct 5 10:40:13 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 Oct 2018 11:40:13 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <53d9515a-f74b-ef6e-a30c-8b28d3b18169@oracle.com> Message-ID: On 04/10/2018 22:04, Sean Mullan wrote: > Excellent comments, Stuart. Thanks for taking the time to review this. > > I have posted another review that should address most of your > comments, but also responded inline with replies below. > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/ > > I also posted the javadoc so you can see what it looks like, esp. the > table: > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/docs/api/java.base/java/lang/SecurityManager.html > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.02/docs/api/java.base/java/lang/System.html > The update to the javadoc, to describe how the security manager is located etc., goes beyond the original scope of the change but it's a welcome update as this is something that was always missing from the docs. Overall I think it looks good. The only issue I see is the statement "The class is loaded by the system class loader ..." as it's actually the built-in application class loader. This is necessary to avoid some tricky bootstrapping issues, also to ensure the security manager is set before the custom system class loader executes. I agree with Stuart's comment that the quotes around java.security.manager are a bit of a distraction. A minor nit with the webrev is that the lines with the table descriptions are way too long. You can put line breaks in those and it will not impact the generated javadoc. -Alan. From sean.mullan at oracle.com Fri Oct 5 12:59:12 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 5 Oct 2018 08:59:12 -0400 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <53d9515a-f74b-ef6e-a30c-8b28d3b18169@oracle.com> Message-ID: <67aaac3e-1386-acff-76ca-0d6d64243c47@oracle.com> On 10/5/18 6:40 AM, Alan Bateman wrote: > The only issue I see is the statement "The class is loaded by the system > class loader ..." as it's actually the built-in application class loader. Is the "built-in application class loader" something that is specified somewhere else? I'd like to link to a definition. --Sean From Alan.Bateman at oracle.com Fri Oct 5 13:34:04 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 Oct 2018 14:34:04 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <67aaac3e-1386-acff-76ca-0d6d64243c47@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <53d9515a-f74b-ef6e-a30c-8b28d3b18169@oracle.com> <67aaac3e-1386-acff-76ca-0d6d64243c47@oracle.com> Message-ID: On 05/10/2018 13:59, Sean Mullan wrote: > On 10/5/18 6:40 AM, Alan Bateman wrote: >> The only issue I see is the statement "The class is loaded by the >> system class loader ..." as it's actually the built-in application >> class loader. > > Is the "built-in application class loader" something that is specified > somewhere else? I'd like to link to a definition. > There is a section in the ClassLoader class description that you can link to. -Alan From dean.long at oracle.com Fri Oct 5 17:52:02 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 5 Oct 2018 10:52:02 -0700 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <53d9515a-f74b-ef6e-a30c-8b28d3b18169@oracle.com> <67aaac3e-1386-acff-76ca-0d6d64243c47@oracle.com> Message-ID: <55eb573d-e5ea-be86-8578-0a1fde24d4bd@oracle.com> On 10/5/18 6:34 AM, Alan Bateman wrote: > > > On 05/10/2018 13:59, Sean Mullan wrote: >> On 10/5/18 6:40 AM, Alan Bateman wrote: >>> The only issue I see is the statement "The class is loaded by the >>> system class loader ..." as it's actually the built-in application >>> class loader. >> >> Is the "built-in application class loader" something that is >> specified somewhere else? I'd like to link to a definition. >> > There is a section in the ClassLoader class description that you can > link to. > Isn't this an implementation detail that could change?? Could it say instead "system class loader or one of its ancestors" or something equally flexible? dl > -Alan > From Alan.Bateman at oracle.com Fri Oct 5 18:14:12 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 Oct 2018 19:14:12 +0100 Subject: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <55eb573d-e5ea-be86-8578-0a1fde24d4bd@oracle.com> References: <4c0ddbab-facb-0a57-b5b9-56490ebb4882@oracle.com> <53d9515a-f74b-ef6e-a30c-8b28d3b18169@oracle.com> <67aaac3e-1386-acff-76ca-0d6d64243c47@oracle.com> <55eb573d-e5ea-be86-8578-0a1fde24d4bd@oracle.com> Message-ID: On 05/10/2018 18:52, dean.long at oracle.com wrote: > > Isn't this an implementation detail that could change?? Could it say > instead "system class loader or one of its ancestors" or something > equally flexible? > I don't think there is much flexibility here. If the custom security manager class is visible to the custom system class loader but not visible to the default system class loader then it cannot be loaded. So I think it has to say that the security manager class is visible to the default system class loader ("built-in application class loader" in the discussion here). A link to the section in ClassLoader spec where it defines the 3 built-in class loaders, and the ClassLoader::getSystemClassLoader method, should be enough. -Alan From swpalmer at gmail.com Fri Oct 5 16:00:10 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 5 Oct 2018 12:00:10 -0400 Subject: Jar's CodeSigner null on Java 10, non-null on Java 8 Message-ID: <0CAF593B-8FEC-4ED9-ABC6-A4A89423D838@gmail.com> Excuse me if this isn?t the right place to ask this. I?ve been trying to debug something related to verifying that a class was signed with a particular certificate. The certificate is self-signed and long expired, if that makes a difference. I have the following code to check the signature: private static boolean signedByMe(Class c) { ProtectionDomain protectionDomain = c.getProtectionDomain(); if ( protectionDomain == null ) return false; CodeSource codeSource = protectionDomain.getCodeSource(); if ( codeSource == null ) return false; CodeSigner[] codeSigners = codeSource.getCodeSigners(); if (codeSigners != null) { for (CodeSigner cs : codeSigners) { for (Certificate cp : cs.getSignerCertPath().getCertificates()) { byte[] sigKey = cp.getPublicKey().getEncoded(); if (Arrays.equals(sigKey, ourKey)) { return true; } } } } return false; } (ourKey is the byte[] of the public key of the certificate used to sign the jar) On Java 8 this works fine. On Java 10.0.2 codeSigners is null. If I run with -Djava.security.debug=jar the output indicates that the classes are signed in both cases. Is this a bug or a specific change to how the expired certificate is handled? Regards, Scott (please include me in replies, I?m not subscribed to the list) From sean.mullan at oracle.com Fri Oct 5 19:52:45 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 5 Oct 2018 15:52:45 -0400 Subject: Jar's CodeSigner null on Java 10, non-null on Java 8 In-Reply-To: <0CAF593B-8FEC-4ED9-ABC6-A4A89423D838@gmail.com> References: <0CAF593B-8FEC-4ED9-ABC6-A4A89423D838@gmail.com> Message-ID: <7fe61fa8-5396-8f3b-e672-161ff429306a@oracle.com> On what version of Java 8 does it work? I am not sure what the problem is without additional information. Also, have you tried running with -Djava.security.debug=all? Did anything unusual (exceptions, etc) get logged? I would also suggest filing a bug with a reproducible test case, if possible: https://bugreport.java.com/bugreport/ --Sean On 10/5/18 12:00 PM, Scott Palmer wrote: > Excuse me if this isn?t the right place to ask this. > > I?ve been trying to debug something related to verifying that a class was signed with a particular certificate. The certificate is self-signed and long expired, if that makes a difference. > > I have the following code to check the signature: > > private static boolean signedByMe(Class c) { > ProtectionDomain protectionDomain = c.getProtectionDomain(); > if ( protectionDomain == null ) return false; > CodeSource codeSource = protectionDomain.getCodeSource(); > if ( codeSource == null ) return false; > CodeSigner[] codeSigners = codeSource.getCodeSigners(); > if (codeSigners != null) { > for (CodeSigner cs : codeSigners) { > for (Certificate cp : cs.getSignerCertPath().getCertificates()) { > byte[] sigKey = cp.getPublicKey().getEncoded(); > if (Arrays.equals(sigKey, ourKey)) { > return true; > } > } > } > } > return false; > } > > (ourKey is the byte[] of the public key of the certificate used to sign the jar) > > On Java 8 this works fine. > > On Java 10.0.2 codeSigners is null. > > If I run with -Djava.security.debug=jar the output indicates that the classes are signed in both cases. > > Is this a bug or a specific change to how the expired certificate is handled? > > Regards, > > Scott > (please include me in replies, I?m not subscribed to the list) > From ecki at zusammenkunft.net Fri Oct 5 21:56:39 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 5 Oct 2018 21:56:39 +0000 Subject: Jar's CodeSigner null on Java 10, non-null on Java 8 In-Reply-To: <0CAF593B-8FEC-4ED9-ABC6-A4A89423D838@gmail.com> References: <0CAF593B-8FEC-4ED9-ABC6-A4A89423D838@gmail.com> Message-ID: What are the Hashes, signatures algorithms and key Sizes? Maybe one of the newer security properties turning those off? Does it have a timestamp? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: -2123340816m Auftrag von Gesendet: Freitag, Oktober 5, 2018 10:13 PM An: security-dev at openjdk.java.net Betreff: Jar's CodeSigner null on Java 10, non-null on Java 8 Excuse me if this isn?t the right place to ask this. I?ve been trying to debug something related to verifying that a class was signed with a particular certificate. The certificate is self-signed and long expired, if that makes a difference. I have the following code to check the signature: private static boolean signedByMe(Class c) { ProtectionDomain protectionDomain = c.getProtectionDomain(); if ( protectionDomain == null ) return false; CodeSource codeSource = protectionDomain.getCodeSource(); if ( codeSource == null ) return false; CodeSigner[] codeSigners = codeSource.getCodeSigners(); if (codeSigners != null) { for (CodeSigner cs : codeSigners) { for (Certificate cp : cs.getSignerCertPath().getCertificates()) { byte[] sigKey = cp.getPublicKey().getEncoded(); if (Arrays.equals(sigKey, ourKey)) { return true; } } } } return false; } (ourKey is the byte[] of the public key of the certificate used to sign the jar) On Java 8 this works fine. On Java 10.0.2 codeSigners is null. If I run with -Djava.security.debug=jar the output indicates that the classes are signed in both cases. Is this a bug or a specific change to how the expired certificate is handled? Regards, Scott (please include me in replies, I?m not subscribed to the list) -------------- next part -------------- An HTML attachment was scrubbed... URL: From swpalmer at gmail.com Sat Oct 6 04:24:45 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 6 Oct 2018 00:24:45 -0400 Subject: Jar's CodeSigner null on Java 10, non-null on Java 8 Message-ID: <7BB0D8C1-924F-409A-84CA-D271F8E53603@gmail.com> Sean asked: > On what version of Java 8 does it work? > Up to 8u181 at least. > > I am not sure what the problem is without additional information. > > What do you need? I will try to sign something trivial with the same cert and create a test case for a bug report. > > Also, have you tried running with -Djava.security.debug=all? Did > anything unusual (exceptions, etc) get logged? No. All I notice is that on Java 10.0.2 it shows this (names sanitized for public consumption): scl: getPermissions ProtectionDomain (file:/full/path/to/my/signed.jar ) jdk.internal.loader.ClassLoaders$AppClassLoader at 57536d79 java.security.Permissions at ba2f4ec ( ("java.io.FilePermission? "/full/path/to/my/signed.jar" "read") ("java.lang.RuntimePermission" "exitVM") ) and on Java 8u181 it shows this: scl: getPermissions ProtectionDomain (file:/full/path/to/my/signed.jar (Signer: [ [ Version: V3 Subject: CN=My Company Corp., OU=Development, O=My Company Corp., L=Markham, ST=Ontario, C=CA Signature Algorithm: SHA1withDSA, OID = 1.2.840.10040.4.3 Key: Sun DSA Public Key Parameters:DSA p: fd7f5381 1d751229 52df4a9c 2eece4e7 f611b752 3cef4400 c31e3f80 b6512669 455d4022 51fb593d 8d58fabf c5f5ba30 f6cb9b55 6cd7813b 801d346f f26660b7 6b9950a5 a49f9fe8 047b1022 c24fbba9 d7feb7c6 1bf83b57 e7c6a8a6 150f04fb 83f6d3c5 1ec30235 54135a16 9132f675 f3ae2b61 d72aeff2 2203199d d14801c7 q: 9760508f 15230bcc b292b982 a2eb840b f0581cf5 g: f7e1a085 d69b3dde cbbcab5c 36b857b9 7994afbb fa3aea82 f9574c0b 3d078267 5159578e bad4594f e6710710 8180b449 167123e8 4c281613 b7cf0932 8cc8a6e1 3c167a8b 547c8d28 e0a3ae1e 2bb3a675 916ea37f 0bfa2135 62f1fb62 7a01243b cca4f1be a8519089 a883dfe1 5ae59f06 928b665e 807b5525 64014c3b fecf492a y: 4d96a9d5 2b20f1f7 f12decd1 4b5ba0e8 4a98d40a 7d745661 b12f661f 84eae997 071d3619 308961f8 6879f76a 0feba11f e08a63fe b044441a fbd33b3c 30ba3e96 e1ac938b bb19ec59 89422123 6b15ad53 ed33e791 a616a61e c6fda1d5 bf95657e 399bb7a1 2ae77ce1 d1806666 5d68c61a 80f967db 525e36c5 a011594a 382ca7aa Validity: [From: Thu May 31 16:16:20 EDT 2012, To: Wed Aug 29 16:16:20 EDT 2012] Issuer: CN=My Company Corp., OU=Development, O=My Company Corp., L=Markham, ST=Ontario, C=CA SerialNumber: [ 4daa8ba0] Certificate Extensions: 1 [1]: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 89 81 49 B9 64 68 72 52 18 39 CE 77 97 7A E9 C9 ..I.dhrR.9.w.z.. 0010: 0C C1 C0 5D ...] ] ] ] Algorithm: [SHA1withDSA] Signature: 0000: 30 2C 02 14 3A FE E1 48 12 0A 02 86 D2 C2 17 56 0,..:..H.......V 0010: 98 88 76 B6 E7 10 C6 0B 02 14 7C 59 CC AF F6 8E ..v........Y.... 0020: BF ED 27 59 42 E1 78 6E 5C 5E E6 E4 A7 53 ..'YB.xn\^...S ])) sun.misc.Launcher$AppClassLoader at 3d4eac69 java.security.Permissions at 5cb0d902 ( ("java.io.FilePermission" "/full/path/to/my/signed.jar" "read") ("java.lang.RuntimePermission" "exitVM") ) > > I would also suggest filing a bug with a reproducible test case, if > possible: https://bugreport.java.com/bugreport/ I?ll try to put something together. Bernd asked: > What are the Hashes, signatures algorithms and key Sizes? Maybe one of the newer security properties turning those off? Does it have a timestamp? SHA1withDSA 1024 bit. There is no timestamp. I checked the $JAVA_HOME/conf/security/java.security file and the key size and algorithm appear to allowed. But there is a lot in there and I?m not 100% sure - What property are you thinking of? I did comment out two of the restrictions that I thought could be related even though they looked okay (jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms) and it had no effect *please include me in replies, I?m not subscribed to the list* Regards, Scott Excuse me if this isn?t the right place to ask this. I have the following code to check the signature: private static boolean signedByMe(Class c) { ProtectionDomain protectionDomain = c.getProtectionDomain(); if ( codeSource == null ) return false; if (codeSigners != null) { byte[] sigKey = cp.getPublicKey().getEncoded(); return true; } } } } return false; On Java 8 this works fine. On Java 10.0.2 codeSigners is null. Is this a bug or a specific change to how the expired certificate is handled? Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From swpalmer at gmail.com Sat Oct 6 05:21:40 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 6 Oct 2018 01:21:40 -0400 Subject: Jar's CodeSigner null on Java 10, non-null on Java 8 In-Reply-To: <7BB0D8C1-924F-409A-84CA-D271F8E53603@gmail.com> References: <7BB0D8C1-924F-409A-84CA-D271F8E53603@gmail.com> Message-ID: <50CBD019-87C8-4DB0-9CCA-D2732E74FDFA@gmail.com> As is too often the case I discovered the difference while trying to isolate a test case. With Java 10 I had extra JVM args to deal with module path and that appeared to cause the problem. I?m not 100% sure what?s happening in my app, but the test case is working so there likely isn?t any issue to bother you guys about. Sorry. Scott > On Oct 6, 2018, at 12:24 AM, Scott Palmer wrote: > > Sean asked: >> On what version of Java 8 does it work? >> > > Up to 8u181 at least. >> I am not sure what the problem is without additional information. >> >> What do you need? I will try to sign something trivial with the same cert and create a test case for a bug report. >> >> Also, have you tried running with -Djava.security.debug=all? Did >> anything unusual (exceptions, etc) get logged? > No. All I notice is that on Java 10.0.2 it shows this (names sanitized for public consumption): > scl: getPermissions ProtectionDomain (file:/full/path/to/my/signed.jar ) > jdk.internal.loader.ClassLoaders$AppClassLoader at 57536d79 > > java.security.Permissions at ba2f4ec ( > ("java.io.FilePermission? "/full/path/to/my/signed.jar" "read") > ("java.lang.RuntimePermission" "exitVM") > ) > > and on Java 8u181 it shows this: > scl: getPermissions ProtectionDomain (file:/full/path/to/my/signed.jar (Signer: [ > [ > Version: V3 > Subject: CN=My Company Corp., OU=Development, O=My Company Corp., L=Markham, ST=Ontario, C=CA > Signature Algorithm: SHA1withDSA, OID = 1.2.840.10040.4.3 > > Key: Sun DSA Public Key > Parameters:DSA > p: fd7f5381 1d751229 52df4a9c 2eece4e7 f611b752 3cef4400 c31e3f80 b6512669 > 455d4022 51fb593d 8d58fabf c5f5ba30 f6cb9b55 6cd7813b 801d346f f26660b7 > 6b9950a5 a49f9fe8 047b1022 c24fbba9 d7feb7c6 1bf83b57 e7c6a8a6 150f04fb > 83f6d3c5 1ec30235 54135a16 9132f675 f3ae2b61 d72aeff2 2203199d d14801c7 > q: 9760508f 15230bcc b292b982 a2eb840b f0581cf5 > g: f7e1a085 d69b3dde cbbcab5c 36b857b9 7994afbb fa3aea82 f9574c0b 3d078267 > 5159578e bad4594f e6710710 8180b449 167123e8 4c281613 b7cf0932 8cc8a6e1 > 3c167a8b 547c8d28 e0a3ae1e 2bb3a675 916ea37f 0bfa2135 62f1fb62 7a01243b > cca4f1be a8519089 a883dfe1 5ae59f06 928b665e 807b5525 64014c3b fecf492a > > y: > 4d96a9d5 2b20f1f7 f12decd1 4b5ba0e8 4a98d40a 7d745661 b12f661f 84eae997 > 071d3619 308961f8 6879f76a 0feba11f e08a63fe b044441a fbd33b3c 30ba3e96 > e1ac938b bb19ec59 89422123 6b15ad53 ed33e791 a616a61e c6fda1d5 bf95657e > 399bb7a1 2ae77ce1 d1806666 5d68c61a 80f967db 525e36c5 a011594a 382ca7aa > > Validity: [From: Thu May 31 16:16:20 EDT 2012, > To: Wed Aug 29 16:16:20 EDT 2012] > Issuer: CN=My Company Corp., OU=Development, O=My Company Corp., L=Markham, ST=Ontario, C=CA > SerialNumber: [ 4daa8ba0] > > Certificate Extensions: 1 > [1]: ObjectId: 2.5.29.14 Criticality=false > SubjectKeyIdentifier [ > KeyIdentifier [ > 0000: 89 81 49 B9 64 68 72 52 18 39 CE 77 97 7A E9 C9 ..I.dhrR.9.w.z.. > 0010: 0C C1 C0 5D ...] > ] > ] > > ] > Algorithm: [SHA1withDSA] > Signature: > 0000: 30 2C 02 14 3A FE E1 48 12 0A 02 86 D2 C2 17 56 0,..:..H.......V > 0010: 98 88 76 B6 E7 10 C6 0B 02 14 7C 59 CC AF F6 8E ..v........Y.... > 0020: BF ED 27 59 42 E1 78 6E 5C 5E E6 E4 A7 53 ..'YB.xn\^...S > > ])) > sun.misc.Launcher$AppClassLoader at 3d4eac69 > > java.security.Permissions at 5cb0d902 ( > ("java.io.FilePermission" "/full/path/to/my/signed.jar" "read") > ("java.lang.RuntimePermission" "exitVM") > ) > >> >> I would also suggest filing a bug with a reproducible test case, if >> possible: https://bugreport.java.com/bugreport/ > I?ll try to put something together. > Bernd asked: >> What are the Hashes, signatures algorithms and key Sizes? Maybe one of the newer security properties turning those off? Does it have a timestamp? > > SHA1withDSA 1024 bit. There is no timestamp. > > I checked the $JAVA_HOME/conf/security/java.security file and the key size and algorithm appear to allowed. But there is a lot in there and I?m not 100% sure - What property are you thinking of? I did comment out two of the restrictions that I thought could be related even though they looked okay (jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms) and it had no effect > > > *please include me in replies, I?m not subscribed to the list* > > Regards, > > Scott > > > Excuse me if this isn?t the right place to ask this. > > > I have the following code to check the signature: > > private static boolean signedByMe(Class c) { > ProtectionDomain protectionDomain = c.getProtectionDomain(); > if ( codeSource == null ) return false; > if (codeSigners != null) { > byte[] sigKey = cp.getPublicKey().getEncoded(); > return true; > } > } > } > } > return false; > > > On Java 8 this works fine. > > On Java 10.0.2 codeSigners is null. > > > Is this a bug or a specific change to how the expired certificate is handled? > > Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From swpalmer at gmail.com Sat Oct 6 20:09:39 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 6 Oct 2018 16:09:39 -0400 Subject: Jar's CodeSigner null on Java 10, non-null on Java 8 In-Reply-To: <50CBD019-87C8-4DB0-9CCA-D2732E74FDFA@gmail.com> References: <7BB0D8C1-924F-409A-84CA-D271F8E53603@gmail.com> <50CBD019-87C8-4DB0-9CCA-D2732E74FDFA@gmail.com> Message-ID: I made a simple test case that will either pass of fail depending on how I choose to launch with Java 10. On the class path it works. On the module path AND the class path it works On the module path executed with -m it fails. On the module path with another *specific but totally unrelated jar* AND the class path, run using fully-qualified class name it fails. On the module path only with fully qualified class name the class can?t be found (this is inconsistent with the previous). # Run with Java 10.0.2 #DEBUG_OPT=-Djava.security.debug=all #DEBUG_OPT=-Djava.security.debug=jar # This works: java --class-path SignTest.jar $DEBUG_OPT example.SignTest # This works: java --module-path SignTest.jar --class-path SignTest.jar $DEBUG_OPT example.SignTest # This fails: java --module-path SignTest.jar $DEBUG_OPT -m SignTest # This fails: java --module-path woodstox-core-asl-4.4.1.jar:SignTest.jar $DEBUG_OPT example.SignTest # This can't find example.SignTest (Why not, given it can for the above?) java --module-path SignTest.jar $DEBUG_OPT example.SignTest # This fails: java --module-path woodstox-core-asl-4.4.1.jar:SignTest.jar --class-path SignTest.jar $DEBUG_OPT example.SignTest (Note that no classes from woodstox-core-asl-4.4.1.jar are needed, but its presence changes the behaviour.) Here is the code. It is the only class in SignTest.jar and that jar is signed with a newly created keypair using the default algorithm, no timestamps package example; import java.security.CodeSigner; import java.security.CodeSource; import java.security.ProtectionDomain; public class SignTest { public static void main(String[] args) { if (signedByUs(SignTest.class)) { System.out.println("PASS"); } else { System.out.println("FAIL"); } } private static boolean signedByUs(Class c) { ProtectionDomain protectionDomain = c.getProtectionDomain(); if (protectionDomain == null) { return false; } CodeSource codeSource = protectionDomain.getCodeSource(); if (codeSource == null) { return false; } CodeSigner[] codeSigners = codeSource.getCodeSigners(); if (codeSigners != null) { System.out.println(c.getName() + " is signed by something."); return true; } else { System.out.println(c.getName() + " appears to be unsigned."); return false; } } } It doesn?t make sense to me, but I am still getting used to modules, so perhaps I am missing something related to modules and security? Gradle code to build and sign: apply plugin: 'java' sourceCompatibility = '1.8' [compileJava, compileTestJava]*.options*.encoding = 'UTF-8' if (!hasProperty('mainClass')) { ext.mainClass = 'example.SignTest' } task makeCert() { if (! new File("$projectDir/testKeystore").exists()) { println "Creating new test keystore..." project.exec { commandLine 'keytool', '-genkeypair', '-noprompt', '-keystore', "$projectDir/testKeystore", '-keypass', 'testing', '-storepass', 'testing', '-dname', 'CN=Test, OU=Test, O=Test, L=Test, ST=Test, C=CA', '-alias', 'test_alias' } } else { println "Using existing keystore: 'testKeystore" } } jar.dependsOn makeCert jar { manifest { attributes( 'Main-Class' : mainClass ) } doLast { println "Signing jar..." project.exec { commandLine = ['jarsigner', '-keystore', "$projectDir/testKeystore", '-storepass', 'testing', '-keypass', 'testing', jar.archivePath, 'test_alias' ] } } } Regards, Scott > On Oct 6, 2018, at 1:21 AM, Scott Palmer wrote: > > As is too often the case I discovered the difference while trying to isolate a test case. With Java 10 I had extra JVM args to deal with module path and that appeared to cause the problem. I?m not 100% sure what?s happening in my app, but the test case is working so there likely isn?t any issue to bother you guys about. Sorry. > > Scott > > On Oct 6, 2018, at 12:24 AM, Scott Palmer > wrote: > >> Sean asked: >>> On what version of Java 8 does it work? >>> >> >> Up to 8u181 at least. >>> I am not sure what the problem is without additional information. >>> >>> What do you need? I will try to sign something trivial with the same cert and create a test case for a bug report. >>> >>> Also, have you tried running with -Djava.security.debug=all? Did >>> anything unusual (exceptions, etc) get logged? >> No. All I notice is that on Java 10.0.2 it shows this (names sanitized for public consumption): >> scl: getPermissions ProtectionDomain (file:/full/path/to/my/signed.jar ) >> jdk.internal.loader.ClassLoaders$AppClassLoader at 57536d79 >> >> java.security.Permissions at ba2f4ec ( >> ("java.io.FilePermission? "/full/path/to/my/signed.jar" "read") >> ("java.lang.RuntimePermission" "exitVM") >> ) >> >> and on Java 8u181 it shows this: >> scl: getPermissions ProtectionDomain (file:/full/path/to/my/signed.jar (Signer: [ >> [ >> Version: V3 >> Subject: CN=My Company Corp., OU=Development, O=My Company Corp., L=Markham, ST=Ontario, C=CA >> Signature Algorithm: SHA1withDSA, OID = 1.2.840.10040.4.3 >> >> Key: Sun DSA Public Key >> Parameters:DSA >> p: fd7f5381 1d751229 52df4a9c 2eece4e7 f611b752 3cef4400 c31e3f80 b6512669 >> 455d4022 51fb593d 8d58fabf c5f5ba30 f6cb9b55 6cd7813b 801d346f f26660b7 >> 6b9950a5 a49f9fe8 047b1022 c24fbba9 d7feb7c6 1bf83b57 e7c6a8a6 150f04fb >> 83f6d3c5 1ec30235 54135a16 9132f675 f3ae2b61 d72aeff2 2203199d d14801c7 >> q: 9760508f 15230bcc b292b982 a2eb840b f0581cf5 >> g: f7e1a085 d69b3dde cbbcab5c 36b857b9 7994afbb fa3aea82 f9574c0b 3d078267 >> 5159578e bad4594f e6710710 8180b449 167123e8 4c281613 b7cf0932 8cc8a6e1 >> 3c167a8b 547c8d28 e0a3ae1e 2bb3a675 916ea37f 0bfa2135 62f1fb62 7a01243b >> cca4f1be a8519089 a883dfe1 5ae59f06 928b665e 807b5525 64014c3b fecf492a >> >> y: >> 4d96a9d5 2b20f1f7 f12decd1 4b5ba0e8 4a98d40a 7d745661 b12f661f 84eae997 >> 071d3619 308961f8 6879f76a 0feba11f e08a63fe b044441a fbd33b3c 30ba3e96 >> e1ac938b bb19ec59 89422123 6b15ad53 ed33e791 a616a61e c6fda1d5 bf95657e >> 399bb7a1 2ae77ce1 d1806666 5d68c61a 80f967db 525e36c5 a011594a 382ca7aa >> >> Validity: [From: Thu May 31 16:16:20 EDT 2012, >> To: Wed Aug 29 16:16:20 EDT 2012] >> Issuer: CN=My Company Corp., OU=Development, O=My Company Corp., L=Markham, ST=Ontario, C=CA >> SerialNumber: [ 4daa8ba0] >> >> Certificate Extensions: 1 >> [1]: ObjectId: 2.5.29.14 Criticality=false >> SubjectKeyIdentifier [ >> KeyIdentifier [ >> 0000: 89 81 49 B9 64 68 72 52 18 39 CE 77 97 7A E9 C9 ..I.dhrR.9.w.z.. >> 0010: 0C C1 C0 5D ...] >> ] >> ] >> >> ] >> Algorithm: [SHA1withDSA] >> Signature: >> 0000: 30 2C 02 14 3A FE E1 48 12 0A 02 86 D2 C2 17 56 0,..:..H.......V >> 0010: 98 88 76 B6 E7 10 C6 0B 02 14 7C 59 CC AF F6 8E ..v........Y.... >> 0020: BF ED 27 59 42 E1 78 6E 5C 5E E6 E4 A7 53 ..'YB.xn\^...S >> >> ])) >> sun.misc.Launcher$AppClassLoader at 3d4eac69 >> >> java.security.Permissions at 5cb0d902 ( >> ("java.io.FilePermission" "/full/path/to/my/signed.jar" "read") >> ("java.lang.RuntimePermission" "exitVM") >> ) >> >>> >>> I would also suggest filing a bug with a reproducible test case, if >>> possible: https://bugreport.java.com/bugreport/ >> I?ll try to put something together. >> Bernd asked: >>> What are the Hashes, signatures algorithms and key Sizes? Maybe one of the newer security properties turning those off? Does it have a timestamp? >> >> SHA1withDSA 1024 bit. There is no timestamp. >> >> I checked the $JAVA_HOME/conf/security/java.security file and the key size and algorithm appear to allowed. But there is a lot in there and I?m not 100% sure - What property are you thinking of? I did comment out two of the restrictions that I thought could be related even though they looked okay (jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms) and it had no effect >> >> >> *please include me in replies, I?m not subscribed to the list* >> >> Regards, >> >> Scott >> >> >> Excuse me if this isn?t the right place to ask this. >> >> >> I have the following code to check the signature: >> >> private static boolean signedByMe(Class c) { >> ProtectionDomain protectionDomain = c.getProtectionDomain(); >> if ( codeSource == null ) return false; >> if (codeSigners != null) { >> byte[] sigKey = cp.getPublicKey().getEncoded(); >> return true; >> } >> } >> } >> } >> return false; >> >> >> On Java 8 this works fine. >> >> On Java 10.0.2 codeSigners is null. >> >> >> Is this a bug or a specific change to how the expired certificate is handled? >> >> Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Oct 7 07:49:26 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 7 Oct 2018 08:49:26 +0100 Subject: Jar's CodeSigner null on Java 10, non-null on Java 8 In-Reply-To: <50CBD019-87C8-4DB0-9CCA-D2732E74FDFA@gmail.com> References: <7BB0D8C1-924F-409A-84CA-D271F8E53603@gmail.com> <50CBD019-87C8-4DB0-9CCA-D2732E74FDFA@gmail.com> Message-ID: <01d91a6e-f418-af1f-f3dc-c5002c3d6667@oracle.com> On 06/10/2018 06:21, Scott Palmer wrote: > As is too often the case I discovered the difference while trying to > isolate a test case. With Java 10 I had extra JVM args to deal with > module path and that appeared to cause the problem. There is very limited support for signing of modules and signed modular JARs. JDK-8194930 [1] tracks the issue of the protection domain not including the signing info but there are other issues, mostly at link-time where jlink will report an error if you attempt to creating a run-time image containing a signed module. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8194930 From weijun.wang at oracle.com Sun Oct 7 14:38:33 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 7 Oct 2018 22:38:33 +0800 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20181004171547.GE26310@twosigma.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> Message-ID: <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> > On Oct 5, 2018, at 1:15 AM, Nico Williams wrote: > > On Thu, Oct 04, 2018 at 11:19:06AM +0100, Alan Bateman wrote: >> On 03/10/2018 21:49, Nico Williams wrote: >>> : >>> A lot of these changes are interrelated. Reviewing them in order of >>> size might require rebasing our stack of commits, and may not be >>> entirely possible. >>> >>> We're extremely familiar with this code as we have been patching the >>> JGSS stack this way for years (we have developed these patches for JDKs >>> 7, 8, 9, 10, 11, and the current 12 master), and we have been running >>> this in production (with JDKs 7, 8, and 9, and soon 11) >> Just a few high-level points on the patches that you attached: >> >> 1. It's important to take sponsor/Reviewer effort into account. I >> skimmed through some of the 25 patches and they lack a detailed >> description on what the issue is about. JGSS gurus might recognize >> some of these issues from the diffs but I suspect you (or Victor) >> will need to match the patches to existing issues in JIRA or else >> get bugs submitted so that there is a description for each issue in >> the bug database. > > We've pointed out that we need bugs filed. We'll work with Weijun to > get them filed when he's back from vacation. I'm just back. Will start working tomorrow. > >> 2. I skimmed the patches and didn't see any tests or changes to >> existing tests. This may come up in the discussion of each change as >> the default position is for all bug fixes should have tests where >> feasible. > > That's an existing problem in the codebase. The tests are very limited > as it is, and testing GSS/Kerberos requires mocking up a KDC, which > requires more complex test infrastructure. I do have a simple one at http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/sun/security/krb5/auto/KDC.java you can read OneKDC.java, Context.java and Basic.java in the same directory. --Max > >> 3. I see the patches include at least some API changes so the >> sponsor will need to submit a CSR for approval. API changes are only >> allowed in feature releases. > > That's fine. > > Nico > -- From jamil.j.nimeh at oracle.com Sun Oct 7 16:33:49 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 7 Oct 2018 09:33:49 -0700 Subject: RFR: 8210989 TLSv1.2 not authenticating using PSS certificates Message-ID: Hello all, this fixes an issue where for TLSv1.2 connections specifically, clients will not authenticate using PSS certs even when PSS signature algorithms are asserted in the CertificateRequest message.? This brings in a method for client certificate selection similar to how we do it for TLS 1.3.? TLS 1.3, 1.1 and 1.0 client certificate selection is not affected by this fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8210989 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210989/webrev.01/ --Jamil From swpalmer at gmail.com Sun Oct 7 17:08:28 2018 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 7 Oct 2018 13:08:28 -0400 Subject: Jar's CodeSigner null on Java 10, non-null on Java 8 In-Reply-To: <01d91a6e-f418-af1f-f3dc-c5002c3d6667@oracle.com> References: <7BB0D8C1-924F-409A-84CA-D271F8E53603@gmail.com> <50CBD019-87C8-4DB0-9CCA-D2732E74FDFA@gmail.com> <01d91a6e-f418-af1f-f3dc-c5002c3d6667@oracle.com> Message-ID: Thanks Alan. I think this is exactly the issue I was hitting. Is it currently not possible to ensure modules have not been tampered with? I don?t think my application will ever be properly modularized anyway, so I will simply make sure those jars are only on the class path. But I?m a little surprised that a security issue like this would linger for so long. I guess with the removal of applet and web start support this issue wasn?t deemed as serious as it otherwise would be. Regards, Scott > On Oct 7, 2018, at 3:49 AM, Alan Bateman wrote: > > On 06/10/2018 06:21, Scott Palmer wrote: >> As is too often the case I discovered the difference while trying to isolate a test case. With Java 10 I had extra JVM args to deal with module path and that appeared to cause the problem. > There is very limited support for signing of modules and signed modular JARs. JDK-8194930 [1] tracks the issue of the protection domain not including the signing info but there are other issues, mostly at link-time where jlink will report an error if you attempt to creating a run-time image containing a signed module. > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8194930 From Alan.Bateman at oracle.com Sun Oct 7 17:26:32 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 7 Oct 2018 18:26:32 +0100 Subject: Jar's CodeSigner null on Java 10, non-null on Java 8 In-Reply-To: References: <7BB0D8C1-924F-409A-84CA-D271F8E53603@gmail.com> <50CBD019-87C8-4DB0-9CCA-D2732E74FDFA@gmail.com> <01d91a6e-f418-af1f-f3dc-c5002c3d6667@oracle.com> Message-ID: <0a286076-095b-c253-3a93-0d812f13e30c@oracle.com> On 07/10/2018 18:08, Scott Palmer wrote: > Thanks Alan. I think this is exactly the issue I was hitting. > > Is it currently not possible to ensure modules have not been tampered with? > The signature checking for signed JARs on the module path is the same as that done for signed JARs on the class path. So if your signed JARs has been tampered with you should get an exception at startup. -Alan From weijun.wang at oracle.com Mon Oct 8 04:35:33 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 8 Oct 2018 12:35:33 +0800 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> Message-ID: <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/. In order to file a bug or post a patch, you need to be an author first. Read here: http://openjdk.java.net/projects/#project-author. Let's pick 2 simple bug fixes to start with. Thanks Max From weijun.wang at oracle.com Mon Oct 8 08:11:34 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 8 Oct 2018 16:11:34 +0800 Subject: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf In-Reply-To: <3ca1245f-4c6f-91c2-3e1a-a396d6f675b1@oracle.com> References: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> <8AB1F42A-A2B5-4F87-9EC3-AB2F158DA7D2@oracle.com> <3ca1245f-4c6f-91c2-3e1a-a396d6f675b1@oracle.com> Message-ID: <4F5EE22F-B063-4BFB-8A69-379C2FD28FE5@oracle.com> And please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8211380 The text is copied below: Supports the `dns_canonicalize_hostname` setting in krb5.conf. When set to true, a short hostname in a service principal name will be canonicalized to a FQDN if available. Otherwise, no canonicalization is performed. The default value is true. This is also the behvaior before JDK 12. Thanks Max > On Sep 29, 2018, at 8:15 AM, Valerie Peng wrote: > > > Sure, I like the new simplified result. > > Changes look fine, > > Valerie > > > On 9/26/2018 7:09 PM, Weijun Wang wrote: >> Webrev updated at https://cr.openjdk.java.net/~weijun/8210821/webrev.01. >> >>> On Sep 26, 2018, at 11:57 PM, Weijun Wang wrote: >>> >>> Hi Valerie >>> >>> I've updated the CSR to remove the "always canonicalize" choice and now the default is "true", i.e. the current "smart-canonicalization" behavior. It's 12am here and I'll update the webrev tomorrow. >>> >>> Thanks >>> Max >>> >>>> On Sep 18, 2018, at 8:52 AM, Valerie Peng wrote: >>>> >>>> Look fine to me. Added myself to CSR as reviewer. >>>> >>>> Thanks, >>>> >>>> Valerie >>>> >>>> >>>> On 9/17/2018 1:17 AM, Weijun Wang wrote: >>>>> Please review the code change and CSR at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8210821/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8210822 >>>>> >>>>> Thanks >>>>> Max >>>>> > From weijun.wang at oracle.com Mon Oct 8 08:24:43 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 8 Oct 2018 16:24:43 +0800 Subject: Jar's CodeSigner null on Java 10, non-null on Java 8 In-Reply-To: <0a286076-095b-c253-3a93-0d812f13e30c@oracle.com> References: <7BB0D8C1-924F-409A-84CA-D271F8E53603@gmail.com> <50CBD019-87C8-4DB0-9CCA-D2732E74FDFA@gmail.com> <01d91a6e-f418-af1f-f3dc-c5002c3d6667@oracle.com> <0a286076-095b-c253-3a93-0d812f13e30c@oracle.com> Message-ID: > On Oct 8, 2018, at 1:26 AM, Alan Bateman wrote: > > On 07/10/2018 18:08, Scott Palmer wrote: >> Thanks Alan. I think this is exactly the issue I was hitting. >> >> Is it currently not possible to ensure modules have not been tampered with? >> > The signature checking for signed JARs on the module path is the same as that done for signed JARs on the class path. So if your signed JARs has been tampered with you should get an exception at startup. That said, if someone modifies the content of your signed JARs and then simply removes the signature-related files, the JARs will be loaded successfully. Of course, they are treated as unsigned, but as you have observed and reported, even a correctly signed JAR is treated as unsigned too. --Max > > -Alan From claes.redestad at oracle.com Mon Oct 8 15:24:36 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Oct 2018 17:24:36 +0200 Subject: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization Message-ID: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> Hi, JDK-8207768 cause a noticeable regression in a subset of our startup tests due eagerly loading security.properties for getting a property that's only used in exceptional circumstances. Ensuring Manifest doesn't eagerly read in the property value in the static initializer avoids this. Webrev: http://cr.openjdk.java.net/~redestad/8211860/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211860 Thanks! /Claes From weijun.wang at oracle.com Mon Oct 8 15:26:24 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 8 Oct 2018 23:26:24 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> Message-ID: <52708621-F7B5-4231-A925-651FE101518D@oracle.com> CSR updated. Please take a review. https://bugs.openjdk.java.net/browse/JDK-8202590 A slightly updated webrev at https://cr.openjdk.java.net/~weijun/8076190/webrev.05 Thanks Max > On Oct 3, 2018, at 12:51 AM, Sean Mullan wrote: > > On 10/1/18 8:02 PM, Weijun Wang wrote: >> >> >>> On Oct 2, 2018, at 2:49 AM, Sean Mullan wrote: >>> >>> Looks good. After you update the CSR with these changes, I can review it. >> >> Sure. >> >> How do you think of the following change? Shall I also add it? > > Yes. >> >> diff --git a/src/java.base/share/classes/java/security/KeyStore.java b/src/java.base/share/classes/java/security/KeyStore.java >> --- a/src/java.base/share/classes/java/security/KeyStore.java >> +++ b/src/java.base/share/classes/java/security/KeyStore.java >> @@ -318,7 +318,7 @@ >> * for a given keystore type is set using the >> * {@code 'keystore..keyProtectionAlgorithm'} security property. >> * For example, the >> - * {@code keystore.PKCS12.keyProtectionAlgorithm} property stores the >> + * {@code keystore.pkcs12.keyProtectionAlgorithm} property stores the >> * name of the default key protection algorithm used for PKCS12 >> * keystores. If the security property is not set, an >> * implementation-specific algorithm will be used. >> >> Shall I add some word to this method saying we should use lowercase or are we going to live with this lower+UPPER for every keystore type forever? > No. Let's just continue to check in the code for both variants of the above property, but remove all references to the upper-case variant from the javadocs and java.security file. > > --Sean >> >> If yes, there will also be some text for its compatibility risk. >> >> Thanks >> Max >> >>> >>> --Sean >>> >>> On 9/28/18 9:36 AM, Weijun Wang wrote: >>>> Webrev updated at >>>> http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ >>>> Major changes: >>>> 1. Comment out key=value lines in java.security >>>> 2. Fix a bug in PBES2Parameters.java >>>> 3. Test no longer depends on openssl. Instead, use openssl to generate some pkcs12 files and included in the test. >>>> 4. A new test KeyProtAlgCompat.java to ensure compatibility on pkcs12/PKCS12 names >>>> I haven't made any change to KeyStore.java yet. CSR is also not updated. >>>> Thanks >>>> Max >> >> From sean.mullan at oracle.com Mon Oct 8 15:47:14 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Oct 2018 11:47:14 -0400 Subject: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization In-Reply-To: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> References: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> Message-ID: <975a559b-eaf9-fad6-4b30-04bb6ada254c@oracle.com> Looks good to me. --Sean On 10/8/18 11:24 AM, Claes Redestad wrote: > Hi, > > JDK-8207768 cause a noticeable regression in a subset of our startup > tests due eagerly loading security.properties for getting a property > that's only used in exceptional circumstances. Ensuring Manifest doesn't > eagerly read in the property value in the static initializer avoids this. > > Webrev: http://cr.openjdk.java.net/~redestad/8211860/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211860 > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Oct 8 15:55:12 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Oct 2018 17:55:12 +0200 Subject: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization In-Reply-To: <975a559b-eaf9-fad6-4b30-04bb6ada254c@oracle.com> References: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> <975a559b-eaf9-fad6-4b30-04bb6ada254c@oracle.com> Message-ID: <723ef193-f144-95e2-3f2b-fc82d4418231@oracle.com> Thanks, Sean! /Claes On 2018-10-08 17:47, Sean Mullan wrote: > Looks good to me. > > --Sean > > On 10/8/18 11:24 AM, Claes Redestad wrote: >> Hi, >> >> JDK-8207768 cause a noticeable regression in a subset of our startup >> tests due eagerly loading security.properties for getting a property >> that's only used in exceptional circumstances. Ensuring Manifest >> doesn't eagerly read in the property value in the static initializer >> avoids this. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8211860/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211860 >> >> Thanks! >> >> /Claes From Alan.Bateman at oracle.com Mon Oct 8 15:51:07 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 Oct 2018 16:51:07 +0100 Subject: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization In-Reply-To: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> References: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> Message-ID: <47f79107-a3a2-1aee-596a-472d1a8110dc@oracle.com> On 08/10/2018 16:24, Claes Redestad wrote: > Hi, > > JDK-8207768 cause a noticeable regression in a subset of our startup > tests due eagerly loading security.properties for getting a property > that's only used in exceptional circumstances. Ensuring Manifest > doesn't eagerly read in the property value in the static initializer > avoids this. > > Webrev: http://cr.openjdk.java.net/~redestad/8211860/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211860 This looks okay to me although something like "JAR_NAME" might be better than "JAR". -Alan From claes.redestad at oracle.com Mon Oct 8 15:59:05 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Oct 2018 17:59:05 +0200 Subject: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization In-Reply-To: <47f79107-a3a2-1aee-596a-472d1a8110dc@oracle.com> References: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> <47f79107-a3a2-1aee-596a-472d1a8110dc@oracle.com> Message-ID: <7f07cf90-0fb3-1fba-30c3-83c0a6472089@oracle.com> On 2018-10-08 17:51, Alan Bateman wrote: > > > On 08/10/2018 16:24, Claes Redestad wrote: >> Hi, >> >> JDK-8207768 cause a noticeable regression in a subset of our startup >> tests due eagerly loading security.properties for getting a property >> that's only used in exceptional circumstances. Ensuring Manifest >> doesn't eagerly read in the property value in the static initializer >> avoids this. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8211860/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211860 > This looks okay to me although something like "JAR_NAME" might be > better than "JAR". Sure! /Claes From sean.mullan at oracle.com Mon Oct 8 17:39:05 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Oct 2018 13:39:05 -0400 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <52708621-F7B5-4231-A925-651FE101518D@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> <52708621-F7B5-4231-A925-651FE101518D@oracle.com> Message-ID: <6232fced-0698-3a69-8b1e-358328ad7922@oracle.com> On 10/8/18 11:26 AM, Weijun Wang wrote: > CSR updated. Please take a review. > > https://bugs.openjdk.java.net/browse/JDK-8202590 # ... If there # is at least one certificate in the existing keystore, the algorithm and # parameter used to encrypt the last certificate in the existing keystore will # be reused to encrypt all certificates while storing. If the last certificate # in the existing keystore is not encrypted, all certificates will be stored # unencrypted. Can you remind me why you can't store the certificates using the same encryption algorithms that were previously used? # "keystore.pkcs12.keyPbeIterationCount" values define here. Typo: defined # The algorithm used to calculated the optional MacData at the end of a PKCS12 Typo: calculate --Sean > > A slightly updated webrev at > > https://cr.openjdk.java.net/~weijun/8076190/webrev.05 > > Thanks > Max > >> On Oct 3, 2018, at 12:51 AM, Sean Mullan wrote: >> >> On 10/1/18 8:02 PM, Weijun Wang wrote: >>> >>> >>>> On Oct 2, 2018, at 2:49 AM, Sean Mullan wrote: >>>> >>>> Looks good. After you update the CSR with these changes, I can review it. >>> >>> Sure. >>> >>> How do you think of the following change? Shall I also add it? >> >> Yes. >>> >>> diff --git a/src/java.base/share/classes/java/security/KeyStore.java b/src/java.base/share/classes/java/security/KeyStore.java >>> --- a/src/java.base/share/classes/java/security/KeyStore.java >>> +++ b/src/java.base/share/classes/java/security/KeyStore.java >>> @@ -318,7 +318,7 @@ >>> * for a given keystore type is set using the >>> * {@code 'keystore..keyProtectionAlgorithm'} security property. >>> * For example, the >>> - * {@code keystore.PKCS12.keyProtectionAlgorithm} property stores the >>> + * {@code keystore.pkcs12.keyProtectionAlgorithm} property stores the >>> * name of the default key protection algorithm used for PKCS12 >>> * keystores. If the security property is not set, an >>> * implementation-specific algorithm will be used. >>> >>> Shall I add some word to this method saying we should use lowercase or are we going to live with this lower+UPPER for every keystore type forever? >> No. Let's just continue to check in the code for both variants of the above property, but remove all references to the upper-case variant from the javadocs and java.security file. >> >> --Sean >>> >>> If yes, there will also be some text for its compatibility risk. >>> >>> Thanks >>> Max >>> >>>> >>>> --Sean >>>> >>>> On 9/28/18 9:36 AM, Weijun Wang wrote: >>>>> Webrev updated at >>>>> http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ >>>>> Major changes: >>>>> 1. Comment out key=value lines in java.security >>>>> 2. Fix a bug in PBES2Parameters.java >>>>> 3. Test no longer depends on openssl. Instead, use openssl to generate some pkcs12 files and included in the test. >>>>> 4. A new test KeyProtAlgCompat.java to ensure compatibility on pkcs12/PKCS12 names >>>>> I haven't made any change to KeyStore.java yet. CSR is also not updated. >>>>> Thanks >>>>> Max >>> >>> > From adam.petcher at oracle.com Mon Oct 8 18:18:53 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 8 Oct 2018 14:18:53 -0400 Subject: RFR: 8209862:CipherCore performance improvement In-Reply-To: References: <778f299c-c2b0-be47-59a9-3690ed3f9b40@oracle.com> <4f202b2f-9d83-c043-1f29-a53e174aa07c@oracle.com> Message-ID: <08133352-029e-e2a1-b71d-ef681d8d787e@oracle.com> The organization is better now, thanks. The code looks good to me, but I would like to request another review from Tony (or someone else who is familiar with this code) before you push. There is a lot of complexity here, and it is hard for me to be sure that everything will behave the same after the change. It will be helpful to have another person examine the new code to ensure that it is correct. Minor style issues(addressing them is optional): Lines 848, 915, and 969 are longer than 80 characters Line 1075: no space before ? character On 10/2/2018 1:51 PM, Se?n Coffey wrote: > > Good points from Adam and Tony. I've taken them both on board. Sergey > has already eliminated a lot of duplicate code but there was further > optimizing possible in the two doFinal(..) methods. I've introduced a > new 'fillOutputBuffer' method to help. Please review : > > https://cr.openjdk.java.net/~coffeys/webrev.8209862.v2/webrev/ > > regards, > Sean. > > > On 01/10/2018 15:32, Adam Petcher wrote: >> Looks like a nice improvement, but is it possible to do this without >> duplicating code? For example, code almost identical to this also >> appears starting on line 860: >> >> 971 } else { // encrypting >> 972 try { >> 973 outLen = finalNoPadding(finalBuf, finalOffset, output, >> 974 outputOffset, finalBufLen); >> 975 } finally { >> 976 // reset after doFinal() for GCM encryption >> 977 requireReinit = (cipherMode == GCM_MODE); >> 978 if (finalBuf != input) { >> 979 // done with internal finalBuf array. Copied to output >> 980 Arrays.fill(finalBuf, (byte) 0x00); >> 981 } >> 982 } >> 983 } >> It may be possible to factor out the entire if/else statement and >> some of the code around it into a separate method and do the short >> buffer check and save/restore around it. Ideally, each doFinal method >> would have only a small amount of code to either allocate the array >> or check array lengths, and then they would call the same private >> method to do most of the work. >> >> I would suggest a noreg-sqe label on the ticket to document that >> existing regression tests are used to ensure correctness of the >> modified code. >> >> Minor code style comments: check for long lines (e.g. line 856) and >> missing spaces after commas in actual parameter lists (also e.g. line >> 856). Also, line 1076 is missing space around the '?' and ':' >> characters. I can check the code again and give you the complete list >> after we sort out the code duplication. >> >> >> On 10/1/2018 9:11 AM, Se?n Coffey wrote: >>> JDK-8207775 introduced some performance regressions in the >>> ciphercore area. Sergey Kuksenko has been looking at this and has >>> contributed the following patch: >>> >>> http://cr.openjdk.java.net/~skuksenko/crypto/8209862/ >>> bug report : https://bugs.openjdk.java.net/browse/JDK-8209862 >>> >>> I've been reviewing it and ran functionality and TCK testing. Didn't >>> see any issues. Sergey has also confirmed that the patch helps to >>> alleviate the performance issues introduced. More details regards >>> approach for fix are in the bug description. >>> >>> Thanks Sergey! I'm looking for another review from security team. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Mon Oct 8 18:19:37 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 8 Oct 2018 14:19:37 -0400 Subject: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf In-Reply-To: <4F5EE22F-B063-4BFB-8A69-379C2FD28FE5@oracle.com> References: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> <8AB1F42A-A2B5-4F87-9EC3-AB2F158DA7D2@oracle.com> <3ca1245f-4c6f-91c2-3e1a-a396d6f675b1@oracle.com> <4F5EE22F-B063-4BFB-8A69-379C2FD28FE5@oracle.com> Message-ID: Hi Max, The release note is fine though it would more complete if it contained a link to the krb5_conf.html where the behavior is described. The original issue https://bugs.openjdk.java.net/browse/JDK-8210821 describes the behavior if set to 'false', while the release note is written describing if it is set to 'true'.? Updating the original issue description to be from the same point (true) of view might reduce any possible confusion about the behavior. Thanks, Roger On 10/08/2018 04:11 AM, Weijun Wang wrote: > And please also review the release note at > > https://bugs.openjdk.java.net/browse/JDK-8211380 > > The text is copied below: > > Supports the `dns_canonicalize_hostname` setting in krb5.conf. When set to true, a short hostname in a service principal name will be canonicalized to a FQDN if available. Otherwise, no canonicalization is performed. The default value is true. This is also the behvaior before JDK 12. > > Thanks > Max > > >> On Sep 29, 2018, at 8:15 AM, Valerie Peng wrote: >> >> >> Sure, I like the new simplified result. >> >> Changes look fine, >> >> Valerie >> >> >> On 9/26/2018 7:09 PM, Weijun Wang wrote: >>> Webrev updated at https://cr.openjdk.java.net/~weijun/8210821/webrev.01. >>> >>>> On Sep 26, 2018, at 11:57 PM, Weijun Wang wrote: >>>> >>>> Hi Valerie >>>> >>>> I've updated the CSR to remove the "always canonicalize" choice and now the default is "true", i.e. the current "smart-canonicalization" behavior. It's 12am here and I'll update the webrev tomorrow. >>>> >>>> Thanks >>>> Max >>>> >>>>> On Sep 18, 2018, at 8:52 AM, Valerie Peng wrote: >>>>> >>>>> Look fine to me. Added myself to CSR as reviewer. >>>>> >>>>> Thanks, >>>>> >>>>> Valerie >>>>> >>>>> >>>>> On 9/17/2018 1:17 AM, Weijun Wang wrote: >>>>>> Please review the code change and CSR at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8210821/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8210822 >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> -- Thanks, Roger From sean.mullan at oracle.com Mon Oct 8 19:01:54 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Oct 2018 15:01:54 -0400 Subject: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf In-Reply-To: References: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> <8AB1F42A-A2B5-4F87-9EC3-AB2F158DA7D2@oracle.com> <3ca1245f-4c6f-91c2-3e1a-a396d6f675b1@oracle.com> <4F5EE22F-B063-4BFB-8A69-379C2FD28FE5@oracle.com> Message-ID: <39043e8e-2840-7d31-0427-4834fe1870f3@oracle.com> The first sentence is a bit terse. Suggest changing it to: "The `dns_canonicalize_hostname` flag in the krb5.conf configuration file is now supported by the JDK Kerberos implementation." Also, you should probably spell out "FQDN". --Sean On 10/8/18 2:19 PM, Roger Riggs wrote: > Hi Max, > > The release note is fine though it would more complete if it contained a > link > to the krb5_conf.html where the behavior is described. > > The original issue https://bugs.openjdk.java.net/browse/JDK-8210821 > describes the behavior if set to 'false', while the release note is > written describing if it > is set to 'true'.? Updating the original issue description to be from > the same point (true) > of view might reduce any possible confusion about the behavior. > > Thanks, Roger > > > On 10/08/2018 04:11 AM, Weijun Wang wrote: >> And please also review the release note at >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8211380 >> >> The text is copied below: >> >> Supports the `dns_canonicalize_hostname` setting in krb5.conf. When >> set to true, a short hostname in a service principal name will be >> canonicalized to a FQDN if available. Otherwise, no canonicalization >> is performed. The default value is true. This is also the behvaior >> before JDK 12. >> >> Thanks >> Max >> >> >>> On Sep 29, 2018, at 8:15 AM, Valerie Peng >>> wrote: >>> >>> >>> Sure, I like the new simplified result. >>> >>> Changes look fine, >>> >>> Valerie >>> >>> >>> On 9/26/2018 7:09 PM, Weijun Wang wrote: >>>> Webrev updated at >>>> https://cr.openjdk.java.net/~weijun/8210821/webrev.01. >>>> >>>>> On Sep 26, 2018, at 11:57 PM, Weijun Wang >>>>> wrote: >>>>> >>>>> Hi Valerie >>>>> >>>>> I've updated the CSR to remove the "always canonicalize" choice and >>>>> now the default is "true", i.e. the current >>>>> "smart-canonicalization" behavior. It's 12am here and I'll update >>>>> the webrev tomorrow. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> On Sep 18, 2018, at 8:52 AM, Valerie Peng >>>>>> wrote: >>>>>> >>>>>> Look fine to me. Added myself to CSR as reviewer. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Valerie >>>>>> >>>>>> >>>>>> On 9/17/2018 1:17 AM, Weijun Wang wrote: >>>>>>> Please review the code change and CSR at >>>>>>> >>>>>>> ?? http://cr.openjdk.java.net/~weijun/8210821/webrev.00/ >>>>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8210822 >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> > From weijun.wang at oracle.com Tue Oct 9 01:25:44 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 9 Oct 2018 09:25:44 +0800 Subject: RFR 8210821: Support dns_canonicalize_hostname in krb5.conf In-Reply-To: <39043e8e-2840-7d31-0427-4834fe1870f3@oracle.com> References: <49DF7170-4E18-431D-A733-10507625BCB9@oracle.com> <8AB1F42A-A2B5-4F87-9EC3-AB2F158DA7D2@oracle.com> <3ca1245f-4c6f-91c2-3e1a-a396d6f675b1@oracle.com> <4F5EE22F-B063-4BFB-8A69-379C2FD28FE5@oracle.com> <39043e8e-2840-7d31-0427-4834fe1870f3@oracle.com> Message-ID: > On Oct 9, 2018, at 3:01 AM, Sean Mullan wrote: > > The first sentence is a bit terse. Suggest changing it to: > > "The `dns_canonicalize_hostname` flag in the krb5.conf configuration file is now supported by the JDK Kerberos implementation." > > Also, you should probably spell out "FQDN". > > --Sean > > On 10/8/18 2:19 PM, Roger Riggs wrote: >> Hi Max, >> The release note is fine though it would more complete if it contained a link >> to the krb5_conf.html where the behavior is described. All suggestions above accepted. See http://java.us.oracle.com/cgi-bin/jdk/release/note?key=JDK-8211380. >> The original issue https://bugs.openjdk.java.net/browse/JDK-8210821 >> describes the behavior if set to 'false', while the release note is written describing if it >> is set to 'true'. Updating the original issue description to be from the same point (true) >> of view might reduce any possible confusion about the behavior. I've updated the bug description a little. It was written that way because the bug report is requesting for a chance to set it to false, but the release note should sound neutral. :-) Thanks Max >> Thanks, Roger >> On 10/08/2018 04:11 AM, Weijun Wang wrote: >>> And please also review the release note at >>> >>> https://bugs.openjdk.java.net/browse/JDK-8211380 >>> >>> The text is copied below: >>> >>> Supports the `dns_canonicalize_hostname` setting in krb5.conf. When set to true, a short hostname in a service principal name will be canonicalized to a FQDN if available. Otherwise, no canonicalization is performed. The default value is true. This is also the behvaior before JDK 12. >>> >>> Thanks >>> Max >>> >>> >>>> On Sep 29, 2018, at 8:15 AM, Valerie Peng wrote: >>>> >>>> >>>> Sure, I like the new simplified result. >>>> >>>> Changes look fine, >>>> >>>> Valerie >>>> >>>> >>>> On 9/26/2018 7:09 PM, Weijun Wang wrote: >>>>> Webrev updated at https://cr.openjdk.java.net/~weijun/8210821/webrev.01. >>>>> >>>>>> On Sep 26, 2018, at 11:57 PM, Weijun Wang wrote: >>>>>> >>>>>> Hi Valerie >>>>>> >>>>>> I've updated the CSR to remove the "always canonicalize" choice and now the default is "true", i.e. the current "smart-canonicalization" behavior. It's 12am here and I'll update the webrev tomorrow. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> On Sep 18, 2018, at 8:52 AM, Valerie Peng wrote: >>>>>>> >>>>>>> Look fine to me. Added myself to CSR as reviewer. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Valerie >>>>>>> >>>>>>> >>>>>>> On 9/17/2018 1:17 AM, Weijun Wang wrote: >>>>>>>> Please review the code change and CSR at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/8210821/webrev.00/ >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8210822 >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> From weijun.wang at oracle.com Tue Oct 9 01:55:32 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 9 Oct 2018 09:55:32 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <6232fced-0698-3a69-8b1e-358328ad7922@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> <52708621-F7B5-4231-A925-651FE101518D@oracle.com> <6232fced-0698-3a69-8b1e-358328ad7922@oracle.com> Message-ID: The PKCS12KeyStore implementation only stores the decrypted certificate, but the major reason is that we want a password-less keystore to remain password-less without any property setting, so the newly added certificate must be stored the same way as the last existing certificate, and I think it's clearer to just use the same algorithm for all entries. Also, there is only one password for all the certificates and if they are using different PBE algorithms an attacker can break the weakest one and then use the password to decrypt those encrypted with stronger ones. --Max > On Oct 9, 2018, at 1:39 AM, Sean Mullan wrote: > > On 10/8/18 11:26 AM, Weijun Wang wrote: >> CSR updated. Please take a review. >> https://bugs.openjdk.java.net/browse/JDK-8202590 > > # ... If there > # is at least one certificate in the existing keystore, the algorithm and > # parameter used to encrypt the last certificate in the existing keystore will > # be reused to encrypt all certificates while storing. If the last certificate > # in the existing keystore is not encrypted, all certificates will be stored > # unencrypted. > > Can you remind me why you can't store the certificates using the same encryption algorithms that were previously used? From matthias.baesken at sap.com Tue Oct 9 12:12:00 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Oct 2018 12:12:00 +0000 Subject: FW: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: Message-ID: Hello, Alan commented on it : * This proposal will require a security review as it leaks sensitive information into exceptions. So I forward it to security-dev as well. If needed, we might use something similar to JDK-8207768 where a category has been added for enhanced exception messages to the java.security file . Best regards, Matthias From: Baesken, Matthias Sent: Dienstag, 9. Oktober 2018 13:40 To: core-libs-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue Hello, please review the following change . It enhances a number of JNU_ThrowIOExceptionWithLastError calls with path and current working directory information. For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is added. bug and webrev : https://bugs.openjdk.java.net/browse/JDK-8211752 http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Tue Oct 9 17:07:40 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 9 Oct 2018 10:07:40 -0700 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <52708621-F7B5-4231-A925-651FE101518D@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> <52708621-F7B5-4231-A925-651FE101518D@oracle.com> Message-ID: Seems alright to this non-crypto expert. The key thing I would like to see working is: If I create a keystore for cacerts and then use it via -with-cacerts-file taking the defaults, this results in goodness (which presumably means not getting JKS keystore) Make sure keystore creators don't have to specify a storepass. On Mon, Oct 8, 2018 at 8:26 AM, Weijun Wang wrote: > CSR updated. Please take a review. > > https://bugs.openjdk.java.net/browse/JDK-8202590 > > A slightly updated webrev at > > https://cr.openjdk.java.net/~weijun/8076190/webrev.05 > > Thanks > Max > > > On Oct 3, 2018, at 12:51 AM, Sean Mullan wrote: > > > > On 10/1/18 8:02 PM, Weijun Wang wrote: > >> > >> > >>> On Oct 2, 2018, at 2:49 AM, Sean Mullan > wrote: > >>> > >>> Looks good. After you update the CSR with these changes, I can review > it. > >> > >> Sure. > >> > >> How do you think of the following change? Shall I also add it? > > > > Yes. > >> > >> diff --git a/src/java.base/share/classes/java/security/KeyStore.java > b/src/java.base/share/classes/java/security/KeyStore.java > >> --- a/src/java.base/share/classes/java/security/KeyStore.java > >> +++ b/src/java.base/share/classes/java/security/KeyStore.java > >> @@ -318,7 +318,7 @@ > >> * for a given keystore type is set using the > >> * {@code 'keystore..keyProtectionAlgorithm'} security > property. > >> * For example, the > >> - * {@code keystore.PKCS12.keyProtectionAlgorithm} property > stores the > >> + * {@code keystore.pkcs12.keyProtectionAlgorithm} property > stores the > >> * name of the default key protection algorithm used for PKCS12 > >> * keystores. If the security property is not set, an > >> * implementation-specific algorithm will be used. > >> > >> Shall I add some word to this method saying we should use lowercase or > are we going to live with this lower+UPPER for every keystore type forever? > > No. Let's just continue to check in the code for both variants of the > above property, but remove all references to the upper-case variant from > the javadocs and java.security file. > > > > --Sean > >> > >> If yes, there will also be some text for its compatibility risk. > >> > >> Thanks > >> Max > >> > >>> > >>> --Sean > >>> > >>> On 9/28/18 9:36 AM, Weijun Wang wrote: > >>>> Webrev updated at > >>>> http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ > >>>> Major changes: > >>>> 1. Comment out key=value lines in java.security > >>>> 2. Fix a bug in PBES2Parameters.java > >>>> 3. Test no longer depends on openssl. Instead, use openssl to > generate some pkcs12 files and included in the test. > >>>> 4. A new test KeyProtAlgCompat.java to ensure compatibility on > pkcs12/PKCS12 names > >>>> I haven't made any change to KeyStore.java yet. CSR is also not > updated. > >>>> Thanks > >>>> Max > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nico.Williams at twosigma.com Tue Oct 9 20:04:53 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Tue, 9 Oct 2018 20:04:53 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> Message-ID: <20181009200453.GF26310@twosigma.com> On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote: > All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/. Thanks! (The patches I sent to you before posting to the list had the wrong email address for me. FYI.) > In order to file a bug or post a patch, you need to be an author > first. Read here: http://openjdk.java.net/projects/#project-author. So it seems I need to send email to the project lead for... security? And per-the census that would be Sean Mullan. No email address is given, but I guess it must be @openjdk.java.net, yes? I'll try it. > Let's pick 2 simple bug fixes to start with. I'll pick two that apply out of order an let you know, otherwise I may need to rebase so those come first and then send you a brand new set of patches. Nico -- From sean.mullan at oracle.com Tue Oct 9 20:31:07 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 9 Oct 2018 16:31:07 -0400 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20181009200453.GF26310@twosigma.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20181009200453.GF26310@twosigma.com> Message-ID: On 10/9/18 4:04 PM, Nico Williams wrote: >> In order to file a bug or post a patch, you need to be an author >> first. Read here:http://openjdk.java.net/projects/#project-author. > So it seems I need to send email to the project lead for... security? > And per-the census that would be Sean Mullan. No email address is > given, but I guess it must be @openjdk.java.net, yes? I'll > try it. Yes, that's me, but first you need to have at least two of your contributions reviewed and pushed. Max will help you with that, and once that is done, I can grant you the Author role. --Sean From Nico.Williams at twosigma.com Tue Oct 9 20:55:41 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Tue, 9 Oct 2018 20:55:41 +0000 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20181009200453.GF26310@twosigma.com> Message-ID: <20181009205541.GH26310@twosigma.com> On Tue, Oct 09, 2018 at 04:31:07PM -0400, Sean Mullan wrote: > On 10/9/18 4:04 PM, Nico Williams wrote: > >>In order to file a bug or post a patch, you need to be an author > >>first. Read here:http://openjdk.java.net/projects/#project-author. > >So it seems I need to send email to the project lead for... security? > >And per-the census that would be Sean Mullan. No email address is > >given, but I guess it must be @openjdk.java.net, yes? I'll > >try it. > > Yes, that's me, but first you need to have at least two of your > contributions reviewed and pushed. Max will help you with that, and > once that is done, I can grant you the Author role. OK, that was not clear, neither was it how to find your email address. Nico -- From weijun.wang at oracle.com Wed Oct 10 00:21:36 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Oct 2018 08:21:36 +0800 Subject: RFR 8211969: test/jdk/lib/security/CheckBlacklistedCerts.java searching for wrong paths Message-ID: <8B41DE7E-2515-4A2B-90D3-4B5A7D53F7FC@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8211969/webrev.00/ The wrong path was never noticed because we ignore missing files. Now that we only look for the open one and it should always be there, we will not ignore it. There won't be such an error again. Thanks Max From sha.jiang at oracle.com Wed Oct 10 03:25:10 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 10 Oct 2018 11:25:10 +0800 Subject: RFR[12] JDK-8210632: Add key exchange algorithm to javax/net/ssl/TLSCommon/CipherSuite.java Message-ID: Hi, It would be better that javax/net/ssl/TLSCommon/CipherSuite.java has an attribute on key exchange algorithm. This attribute could be used on selecting appropriate certificates by some tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8210632 Webrev: http://cr.openjdk.java.net/~jjiang/8210632/webrev.00/ Best regards, John Jiang From tomas at primekey.se Wed Oct 10 05:12:03 2018 From: tomas at primekey.se (Tomas Gustavsson) Date: Wed, 10 Oct 2018 07:12:03 +0200 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: <68fff06c-c161-0930-f7bb-58a7b794a98a@comcast.net> References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <68fff06c-c161-0930-f7bb-58a7b794a98a@comcast.net> Message-ID: Hi, > Maybe its time to provide a PKCS11AttributeSpec of some sort for key > creation and for looking things up? The current model is literally > 12-15 years old AFAICT. I just though I'd second this, albeit late. We're seing the current PKCS#11 Provider model break down with some new HSMs out there. I.e. on AWS CloudHSM/Cavium, it is only possible to set CKA_ID at time of key creation, whereas the P11 Provider sets it afterwards as a setAttribute call. This effectively makes the old Sun P11 Provider not usable at all wiht CloudHSM/Cavium. With todays PKCS#11 landscape I think we need more control, or the provider will essentially be defunct. Regards, Tomas On 2018-09-05 22:49, Michael StJohns wrote: > On 9/4/2018 9:59 PM, Valerie Peng wrote: >> These sun.security.pkcs11.wrapper classes are internal and subject to >> changes without notice. > No arguments there.? But that interface has been stable since the > initial contribution and to be blunt - the PKCS11 provider only works > well if you use the keys you created through the provider.? There's a > set of idiosyncratic choices for how to map keys to certs to keys that > make keys created by non-provider calls (e.g. C code or other non-java > libs) to the token difficult to use through the provider and vice > versa.? That led to us using the wrapper classes directly.? > > Maybe its time to provide a PKCS11AttributeSpec? of some sort for key > creation and for looking things up?? The current model is literally > 12-15 years old AFAICT. > >> >> For the time being, maybe we can leave these method intact and add a >> comment about calling the new methods which use P11Key argument >> instead of the key handle argument. > > That should work.? You may want to think about deprecating those methods > and target removing them for a later release in a couple of years.? > > Thanks - Mike > > >> >> Regards, >> Valerie >> >> On 9/1/2018 11:18 AM, Michael StJohns wrote: >>> Hi Valerie - >>> >>> I may be speaking only for myself, but there are probably a number of >>> folk using sun.security.pkcs11.wrapper.* in lieu of the PKCS11 >>> provider for a number of reasons including an ability to manage the >>> key storage and wrapping efficiently.?? Looking at this I'm thinking >>> there will be a large number of things breaking because of the way >>> you refactored things. >>> >>> While I understand that none of the sun.security.* classes are >>> "public" - these were mostly taken directly from the IAIK >>> contribution way back when and the folks I worked with used them in >>> lieu of external libraries to have a consistent PKCS11 interface >>> java-to-java. >>> >>> Perhaps instead you'd consider doing something like leaving the Java >>> to Native public methods intact? >>> >>> Mike >>> >>> >>> >>> >>> On 8/31/2018 7:53 PM, Valerie Peng wrote: >>>> >>>> Hi Martin, >>>> >>>> With the new model of "creating the key handle as needed", I think >>>> we should not allow the direct access of keyID field outside of >>>> P11Key class. This field should be made private and accessed through >>>> methods. In addition, existing PKCS11.C_XXX() methods with P11 keyID >>>> arguments can be made private and we can add wrapper methods with >>>> P11Key object argument to ensure proper usage of the P11Key object >>>> and its keyID field. >>>> >>>> I have also refactored the keyID management code into a separate >>>> holder class. The prototype code can be found at: >>>> http://cr.openjdk.java.net/~valeriep/6913047Exp/webrev.00/ >>>> >>>> The main changes that I made are in P11Key.java and PKCS11.java. The >>>> other java classes are updated to call the wrapper methods in >>>> PKCS11.java. >>>> >>>> Thanks & have a great Labor day weekend, >>>> >>>> Valerie >>>> >>>> >>>> On 8/16/2018 5:28 PM, Valerie Peng wrote: >>>>> >>>>> Hi Martin, >>>>> >>>>> >>>>> Since there is no regression test for this test, you will need to >>>>> add a "noreg-xxx" label to the bug record. For this issue, it'll >>>>> probably be "noreg-hard". >>>>> >>>>> To understand the changes better, please find my questions and some >>>>> review comments below: >>>>> >>>>> >>>>> - line 397: It's incorrect to change initialize() to >>>>> ensureInitialized(). If the cipher object were to be initialized >>>>> twice with two different keys, you need to re-initialize again. >>>>> - line 471: Why do you change it to Throwable from PKCS11Exception? >>>>> >>>>> >>>>> - line 99: comment is somewhat unclear. typo: "temporal" should be >>>>> "temporary". >>>>> - line 148-149: JDK-8165996 has been fixed. This does not apply >>>>> now, does it? >>>>> - You changed the constructors of all the P11Key-related classes to >>>>> take an additional boolean argument "tmpNativeKey". However, this >>>>> boolean argument is only used when the underlying token is "NSS". >>>>> Why limiting to NSS only? It seems that all callers except for >>>>> PKCS11 KeyStore pass true for "tmpNativeKey". When "tmpNativeKey" >>>>> is true, the keyID handle first destroyed in constructor and later >>>>> created again (ref count == 1) and destroyed (when ref count drops >>>>> to 0). This replaced the PhantomReference approach in SessionKeyRef >>>>> class, right? Now both approaches seem to be used and key >>>>> destruction is taking places at different methods. I think we >>>>> should clarify the cleanup model and perhaps refactor the code so >>>>> it's easier which approach is in use. Or grouping all these >>>>> cleanup-related fields/variables into a separate class for >>>>> readability/clarity. >>>>> - line 157-175: nativeKeyWrapperKeyID is a static variable, >>>>> shouldn't it be synchronized on a class level object? >>>>> - line 1343: the impl doesn't look right. Why do you call both >>>>> removeObject() and addObject() here with the same check? >>>>> - line 1363: the change seems incorrect, you should still call >>>>> session.removeObject(). the call setKeyIDAndSession(0, null) does >>>>> not lower the session object count. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 8/7/2018 5:41 PM, Valerie Peng wrote: >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> Thanks for the update, I will resume the review on this one with >>>>>> your latest webrev. >>>>>> >>>>>> BTW, there is no webrev.07 for your other fix, i.e. JDK-8029661, >>>>>> right? Just checking. >>>>>> >>>>>> Regards, >>>>>> Valerie >>>>>> >>>>>> On 8/3/2018 2:13 PM, Martin Balao wrote: >>>>>>> Hi Valerie, >>>>>>> >>>>>>> ?* >>>>>>> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10/ >>>>>>> >>>>>>> ?* >>>>>>> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.10.zip >>>>>>> >>>>>>> >>>>>>> New in webrev 10: >>>>>>> >>>>>>> ?* Bug fix when private DSA/EC keys are sensitive >>>>>>> ? * I found this bug removing "attributes = compatibility" entry >>>>>>> in NSS configuration file so keys were CKA_SENSITIVE. >>>>>>> ? * This is really an NSS bug when unwrapping ephemeral keys >>>>>>> (NSC_UnwrapKey function), because CKA_NETSCAPE_DB attribute is >>>>>>> required but not used/needed. There was a similar bug when >>>>>>> creating objects (NSC_CreateObject function), fixed many years >>>>>>> ago [1]. >>>>>>> ? * In those cases in which the bug occurs (private keys, of >>>>>>> DSA/EC type, sensitive and without CKA_NETSCAPE_DB attribute >>>>>>> set), I store an empty CKA_NETSCAPE_DB attribute in the buffer >>>>>>> that will later be used for key unwrapping. I'm not doing a >>>>>>> C_SetAttributeValue call because keys are read-only. We can let >>>>>>> users set CKA_NETSCAPE_DB attribute in NSS configuration file [2] >>>>>>> but this would be a workaround on users side. >>>>>>> ? * Changes in: >>>>>>> ? ?* p11_keymgmt.c >>>>>>> ? ? * L175-187, L212-214 and L275-278 >>>>>>> >>>>>>> ?* Bug fix when storing sensitive RSA keys in a keystore >>>>>>> ? * CKA_NETSCAPE_DB attribute is not needed so we return it as >>>>>>> null (instead of failing with an "Invalid algorithm" message) >>>>>>> ? * Changes in: >>>>>>> ? ?* P11KeyStore.java >>>>>>> ? ? * L1909-1914 >>>>>>> >>>>>>> ?* Lines length was cut to improve code readability >>>>>>> >>>>>>> Regression tests on jdk/sun/security/pkcs11 category passed. I >>>>>>> ran my internal test suite too, that covers the following >>>>>>> services (with SunPKCS11 provider): Cipher, Signature, >>>>>>> KeyAgreement, Digest, Mac, KeyGenerator, KeyPairGenerator and >>>>>>> Keystore. >>>>>>> >>>>>>> Kind regards, >>>>>>> Martin.- >>>>>>> >>>>>>> -- >>>>>>> [1] - https://bugzilla.mozilla.org/show_bug.cgi?id=309701#c6 >>>>>>> >>>>>>> [2] - >>>>>>> https://alvinalexander.com/java/jwarehouse/openjdk-8/jdk/test/sun/security/pkcs11/fips/fips.cfg.shtml >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From weijun.wang at oracle.com Wed Oct 10 10:10:02 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Oct 2018 18:10:02 +0800 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> <52708621-F7B5-4231-A925-651FE101518D@oracle.com> Message-ID: <48590A90-26BB-43F4-860A-5707D4D67672@oracle.com> > On Oct 10, 2018, at 1:07 AM, Martin Buchholz wrote: > > Seems alright to this non-crypto expert. > > The key thing I would like to see working is: > > If I create a keystore for cacerts and then use it via -with-cacerts-file taking the defaults, this results in goodness (which presumably means not getting JKS keystore) I haven't tried this configure option before, but does it mean just copy your own file to lib/security/cacerts? Then you need to make it correct, i.e. a JKS file, or a password-less pkcs12 file, or with-password pkcs12 but you set the correct storepass (TLS system property?). > > Make sure keystore creators don't have to specify a storepass. If you want to create a password-less pkcs12 file, you will need to specify those system properties (certProtectionAlgorithm and macAlgorithm to NONE). Then I'll make sure there is no need to specify a storepass. Thanks Max > > On Mon, Oct 8, 2018 at 8:26 AM, Weijun Wang wrote: > CSR updated. Please take a review. > > https://bugs.openjdk.java.net/browse/JDK-8202590 > > A slightly updated webrev at > > https://cr.openjdk.java.net/~weijun/8076190/webrev.05 > > Thanks > Max > > > On Oct 3, 2018, at 12:51 AM, Sean Mullan wrote: > > > > On 10/1/18 8:02 PM, Weijun Wang wrote: > >> > >> > >>> On Oct 2, 2018, at 2:49 AM, Sean Mullan wrote: > >>> > >>> Looks good. After you update the CSR with these changes, I can review it. > >> > >> Sure. > >> > >> How do you think of the following change? Shall I also add it? > > > > Yes. > >> > >> diff --git a/src/java.base/share/classes/java/security/KeyStore.java b/src/java.base/share/classes/java/security/KeyStore.java > >> --- a/src/java.base/share/classes/java/security/KeyStore.java > >> +++ b/src/java.base/share/classes/java/security/KeyStore.java > >> @@ -318,7 +318,7 @@ > >> * for a given keystore type is set using the > >> * {@code 'keystore..keyProtectionAlgorithm'} security property. > >> * For example, the > >> - * {@code keystore.PKCS12.keyProtectionAlgorithm} property stores the > >> + * {@code keystore.pkcs12.keyProtectionAlgorithm} property stores the > >> * name of the default key protection algorithm used for PKCS12 > >> * keystores. If the security property is not set, an > >> * implementation-specific algorithm will be used. > >> > >> Shall I add some word to this method saying we should use lowercase or are we going to live with this lower+UPPER for every keystore type forever? > > No. Let's just continue to check in the code for both variants of the above property, but remove all references to the upper-case variant from the javadocs and java.security file. > > > > --Sean > >> > >> If yes, there will also be some text for its compatibility risk. > >> > >> Thanks > >> Max > >> > >>> > >>> --Sean > >>> > >>> On 9/28/18 9:36 AM, Weijun Wang wrote: > >>>> Webrev updated at > >>>> http://cr.openjdk.java.net/~weijun/8076190/webrev.04/ > >>>> Major changes: > >>>> 1. Comment out key=value lines in java.security > >>>> 2. Fix a bug in PBES2Parameters.java > >>>> 3. Test no longer depends on openssl. Instead, use openssl to generate some pkcs12 files and included in the test. > >>>> 4. A new test KeyProtAlgCompat.java to ensure compatibility on pkcs12/PKCS12 names > >>>> I haven't made any change to KeyStore.java yet. CSR is also not updated. > >>>> Thanks > >>>> Max > >> > >> > > From sgehwolf at redhat.com Wed Oct 10 10:23:36 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Oct 2018 12:23:36 +0200 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? Message-ID: Hi, What is the rationale of using DSA keys (2048 bit) as default for genkeypair command? http://hg.openjdk.java.net/jdk/jdk/file/c4a39588a075/src/java.base/share/classes/sun/security/tools/keytool/Main.java#l1120 It seems a bad choice given that DSA keys are disabled via Fedora's crypto policy (not just OpenJDK, but other crypto providers too). Here the explanation from Nikos Mavrogiannopoulos from a Fedora bug[1] as to why that's a bad choice: """ DSA is not used by new security protocols any more (doesn't exist as a negotiation option under TLS1.3), and was a very rarely used option under previous protocols (TLS1.2 or earlier). In fact only DSA-1024 is documented under these protocols. DSA-2048 may or may not work depending on the implementation (and even worse may not interoperate). """ Could the default choice of keyalg for genkeypair be reconsidered? If not, why not? Thanks, Severin [1] https://bugzilla.redhat.com/show_bug.cgi?id=1582253 From sean.mullan at oracle.com Wed Oct 10 11:59:55 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 Oct 2018 07:59:55 -0400 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: References: Message-ID: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> On 10/10/18 6:23 AM, Severin Gehwolf wrote: > Hi, > > What is the rationale of using DSA keys (2048 bit) as default for > genkeypair command? > http://hg.openjdk.java.net/jdk/jdk/file/c4a39588a075/src/java.base/share/classes/sun/security/tools/keytool/Main.java#l1120 There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. > It seems a bad choice given that DSA keys are disabled via Fedora's > crypto policy (not just OpenJDK, but other crypto providers too). Actually, only DSA keys < 1024-bit are disabled by default in OpenJDK. > Here the explanation from Nikos Mavrogiannopoulos from a Fedora bug[1] > as to why that's a bad choice: > > """ > DSA is not used by new security protocols any more (doesn't exist as a > negotiation option under TLS1.3), and was a very rarely used option > under previous protocols (TLS1.2 or earlier). In fact only DSA-1024 is > documented under these protocols. DSA-2048 may or may not work > depending on the implementation (and even worse may not interoperate). > """ > > Could the default choice of keyalg for genkeypair be reconsidered? Yes, I think it should be considered since DSA is rarely used anymore and not supported by newer security protocols such as TLS 1.3. I have filed: https://bugs.openjdk.java.net/browse/JDK-8212003 --Sean > If not, why not? > > Thanks, > Severin > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1582253 > From Alan.Bateman at oracle.com Wed Oct 10 12:06:13 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2018 13:06:13 +0100 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <20181009205541.GH26310@twosigma.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20181009200453.GF26310@twosigma.com> <20181009205541.GH26310@twosigma.com> Message-ID: <421181a5-a88b-cdb6-7346-200f8cb427ac@oracle.com> On 09/10/2018 21:55, Nico Williams wrote: > On Tue, Oct 09, 2018 at 04:31:07PM -0400, Sean Mullan wrote: >> On 10/9/18 4:04 PM, Nico Williams wrote: >>>> In order to file a bug or post a patch, you need to be an author >>>> first. Read here:http://openjdk.java.net/projects/#project-author. >>> So it seems I need to send email to the project lead for... security? >>> And per-the census that would be Sean Mullan. No email address is >>> given, but I guess it must be @openjdk.java.net, yes? I'll >>> try it. >> Yes, that's me, but first you need to have at least two of your >> contributions reviewed and pushed. Max will help you with that, and >> once that is done, I can grant you the Author role. > OK, that was not clear, neither was it how to find your email address. > Actually, it's Project Lead that grants Author role. Mark Reinhold is the Project Lead for the jdk project. Once you at least two sponsored contributions then I assume Sean will request it on you, esp. when there is a pipeline of patches and interest in maintaining this area. -Alan From sean.mullan at oracle.com Wed Oct 10 12:17:21 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 Oct 2018 08:17:21 -0400 Subject: JGSS Enhancements (contribution by Two Sigma Open Source) In-Reply-To: <421181a5-a88b-cdb6-7346-200f8cb427ac@oracle.com> References: <20181002230433.GU703@twosigma.com> <20181003204928.GA26310@twosigma.com> <20181004171547.GE26310@twosigma.com> <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com> <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com> <20181009200453.GF26310@twosigma.com> <20181009205541.GH26310@twosigma.com> <421181a5-a88b-cdb6-7346-200f8cb427ac@oracle.com> Message-ID: <20ca449c-912a-52fe-88dd-537e8459907c@oracle.com> On 10/10/18 8:06 AM, Alan Bateman wrote: > > > On 09/10/2018 21:55, Nico Williams wrote: >> On Tue, Oct 09, 2018 at 04:31:07PM -0400, Sean Mullan wrote: >>> On 10/9/18 4:04 PM, Nico Williams wrote: >>>>> In order to file a bug or post a patch, you need to be an author >>>>> first. Read here:http://openjdk.java.net/projects/#project-author. >>>> So it seems I need to send email to the project lead for... security? >>>> And per-the census that would be Sean Mullan.? No email address is >>>> given, but I guess it must be @openjdk.java.net, yes?? I'll >>>> try it. >>> Yes, that's me, but first you need to have at least two of your >>> contributions reviewed and pushed. Max will help you with that, and >>> once that is done, I can grant you the Author role. >> OK, that was not clear, neither was it how to find your email address. >> > Actually, it's Project Lead that grants Author role. Mark Reinhold is > the Project Lead for the jdk project. Once you at least two sponsored > contributions then I assume Sean will request it on you, esp. when there > is a pipeline of patches and interest in maintaining this area. Right, sorry about that, and thanks for the correction. I misread "Project Lead" as "Group Lead" when I was looking at your email and the guidelines yesterday. --Sean From sgehwolf at redhat.com Wed Oct 10 12:51:47 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Oct 2018 14:51:47 +0200 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> Message-ID: Hi Sean, On Wed, 2018-10-10 at 07:59 -0400, Sean Mullan wrote: > On 10/10/18 6:23 AM, Severin Gehwolf wrote: > > Hi, > > > > What is the rationale of using DSA keys (2048 bit) as default for > > genkeypair command? > > http://hg.openjdk.java.net/jdk/jdk/file/c4a39588a075/src/java.base/share/classes/sun/security/tools/keytool/Main.java#l1120 > > There is really no other reason other than DSA keys have been the > default keypairs generated by keytool for a long time, so there are some > compatibility issues we would have to think through before changing it > to another algorithm such as RSA. Weijun might have more insight into that. > > It seems a bad choice given that DSA keys are disabled via Fedora's > > crypto policy (not just OpenJDK, but other crypto providers too). > > Actually, only DSA keys < 1024-bit are disabled by default in OpenJDK. Thanks. I should have perhaps clarified. Not sure whether that was clear. In Fedora a global crypto policy is in place. The policy affects OpenSSL, GnuTLS, (patched) OpenJDK etc. It's that global policy which disables DSA unconditionally. > > Here the explanation from Nikos Mavrogiannopoulos from a Fedora bug[1] > > as to why that's a bad choice: > > > > """ > > DSA is not used by new security protocols any more (doesn't exist as a > > negotiation option under TLS1.3), and was a very rarely used option > > under previous protocols (TLS1.2 or earlier). In fact only DSA-1024 is > > documented under these protocols. DSA-2048 may or may not work > > depending on the implementation (and even worse may not interoperate). > > """ > > > > Could the default choice of keyalg for genkeypair be reconsidered? > > Yes, I think it should be considered since DSA is rarely used anymore > and not supported by newer security protocols such as TLS 1.3. I have > filed: https://bugs.openjdk.java.net/browse/JDK-8212003 Great, thanks! Cheers, Severin > --Sean > > > If not, why not? > > > > Thanks, > > Severin > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1582253 > > From sean.mullan at oracle.com Wed Oct 10 13:07:44 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 Oct 2018 09:07:44 -0400 Subject: RFR 8211969: test/jdk/lib/security/CheckBlacklistedCerts.java searching for wrong paths In-Reply-To: <8B41DE7E-2515-4A2B-90D3-4B5A7D53F7FC@oracle.com> References: <8B41DE7E-2515-4A2B-90D3-4B5A7D53F7FC@oracle.com> Message-ID: Looks good to me. --Sean On 10/9/18 8:21 PM, Weijun Wang wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8211969/webrev.00/ > > The wrong path was never noticed because we ignore missing files. Now that we only look for the open one and it should always be there, we will not ignore it. There won't be such an error again. > > Thanks > Max > From weijun.wang at oracle.com Wed Oct 10 14:42:06 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Oct 2018 22:42:06 +0800 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> Message-ID: <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> > On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: > > There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard? As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option. If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). --Max From sean.coffey at oracle.com Wed Oct 10 16:26:32 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 10 Oct 2018 17:26:32 +0100 Subject: RFR: 8209862:CipherCore performance improvement In-Reply-To: <08133352-029e-e2a1-b71d-ef681d8d787e@oracle.com> References: <778f299c-c2b0-be47-59a9-3690ed3f9b40@oracle.com> <4f202b2f-9d83-c043-1f29-a53e174aa07c@oracle.com> <08133352-029e-e2a1-b71d-ef681d8d787e@oracle.com> Message-ID: <0388c3c4-1a99-a1f6-bf52-ce74bc8ce817@oracle.com> Thanks for the review Adam. I've corrected those style issues. Now waiting on 2nd Reviewer. Regards, Sean. On 08/10/18 19:18, Adam Petcher wrote: > > The organization is better now, thanks. The code looks good to me, but > I would like to request another review from Tony (or someone else who > is familiar with this code) before you push. There is a lot of > complexity here, and it is hard for me to be sure that everything will > behave the same after the change. It will be helpful to have another > person examine the new code to ensure that it is correct. > > Minor style issues(addressing them is optional): > > Lines 848, 915, and 969 are longer than 80 characters > Line 1075: no space before ? character > > > On 10/2/2018 1:51 PM, Se?n Coffey wrote: >> >> Good points from Adam and Tony. I've taken them both on board. Sergey >> has already eliminated a lot of duplicate code but there was further >> optimizing possible in the two doFinal(..) methods. I've introduced a >> new 'fillOutputBuffer' method to help. Please review : >> >> https://cr.openjdk.java.net/~coffeys/webrev.8209862.v2/webrev/ >> >> regards, >> Sean. >> >> >> On 01/10/2018 15:32, Adam Petcher wrote: >>> Looks like a nice improvement, but is it possible to do this without >>> duplicating code? For example, code almost identical to this also >>> appears starting on line 860: >>> >>> 971 } else { // encrypting >>> 972 try { >>> 973 outLen = finalNoPadding(finalBuf, finalOffset, output, >>> 974 outputOffset, finalBufLen); >>> 975 } finally { >>> 976 // reset after doFinal() for GCM encryption >>> 977 requireReinit = (cipherMode == GCM_MODE); >>> 978 if (finalBuf != input) { >>> 979 // done with internal finalBuf array. Copied to output >>> 980 Arrays.fill(finalBuf, (byte) 0x00); >>> 981 } >>> 982 } >>> 983 } >>> It may be possible to factor out the entire if/else statement and >>> some of the code around it into a separate method and do the short >>> buffer check and save/restore around it. Ideally, each doFinal >>> method would have only a small amount of code to either allocate the >>> array or check array lengths, and then they would call the same >>> private method to do most of the work. >>> >>> I would suggest a noreg-sqe label on the ticket to document that >>> existing regression tests are used to ensure correctness of the >>> modified code. >>> >>> Minor code style comments: check for long lines (e.g. line 856) and >>> missing spaces after commas in actual parameter lists (also e.g. >>> line 856). Also, line 1076 is missing space around the '?' and ':' >>> characters. I can check the code again and give you the complete >>> list after we sort out the code duplication. >>> >>> >>> On 10/1/2018 9:11 AM, Se?n Coffey wrote: >>>> JDK-8207775 introduced some performance regressions in the >>>> ciphercore area. Sergey Kuksenko has been looking at this and has >>>> contributed the following patch: >>>> >>>> http://cr.openjdk.java.net/~skuksenko/crypto/8209862/ >>>> bug report : https://bugs.openjdk.java.net/browse/JDK-8209862 >>>> >>>> I've been reviewing it and ran functionality and TCK testing. >>>> Didn't see any issues. Sergey has also confirmed that the patch >>>> helps to alleviate the performance issues introduced. More details >>>> regards approach for fix are in the bug description. >>>> >>>> Thanks Sergey! I'm looking for another review from security team. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Oct 10 16:33:37 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 Oct 2018 12:33:37 -0400 Subject: RFR [12]: 8211878: Bad/broken links in docs/api/java.xml.crypto/javax/xml/crypto/dsig/Reference.html Message-ID: <7652f41e-1a9c-ecab-97a5-edcec9a8a76d@oracle.com> Please review this trivial fix to correct a couple of broken hyperlinks: diff --git a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java --- a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java +++ b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2018, 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 @@ -144,7 +144,7 @@ /** * Returns the dereferenced data, if - * reference caching + * reference caching * is enabled. This is the result of dereferencing the URI of this * reference during a validation or generation operation. * @@ -156,7 +156,7 @@ /** * Returns the pre-digested input stream, if - * reference caching + * reference caching * is enabled. This is the input to the digest operation during a * validation or signing operation. * Thanks, Sean From jonathan.gibbons at oracle.com Wed Oct 10 16:34:23 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 10 Oct 2018 09:34:23 -0700 Subject: RFR [12]: 8211878: Bad/broken links in docs/api/java.xml.crypto/javax/xml/crypto/dsig/Reference.html In-Reply-To: <7652f41e-1a9c-ecab-97a5-edcec9a8a76d@oracle.com> References: <7652f41e-1a9c-ecab-97a5-edcec9a8a76d@oracle.com> Message-ID: <17b4e1cd-6d32-205d-456e-9fe604d32c98@oracle.com> Looks good to me. -- Jon On 10/10/18 9:33 AM, Sean Mullan wrote: > Please review this trivial fix to correct a couple of broken hyperlinks: > > diff --git > a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java > b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java > --- > a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java > +++ > b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2005, 2018, 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 > @@ -144,7 +144,7 @@ > > ???? /** > ????? * Returns the dereferenced data, if > -???? * reference > caching > +???? * reference > caching > ????? * is enabled. This is the result of dereferencing the URI of this > ????? * reference during a validation or generation operation. > ????? * > @@ -156,7 +156,7 @@ > > ???? /** > ????? * Returns the pre-digested input stream, if > -???? * reference > caching > +???? * reference > caching > ????? * is enabled. This is the input to the digest operation during a > ????? * validation or signing operation. > ????? * > > Thanks, > Sean From martinrb at google.com Wed Oct 10 17:58:01 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Oct 2018 10:58:01 -0700 Subject: RFR 8076190: Customizing the generation of a PKCS12 keystore In-Reply-To: <48590A90-26BB-43F4-860A-5707D4D67672@oracle.com> References: <9C834C58-ACBC-448A-9784-1C225174DA94@oracle.com> <8AB12D11-3C9C-4FD6-A263-8B93A62C2C14@oracle.com> <36FED22D-1145-49C2-9365-C9A04D070C82@oracle.com> <5C5E99F0-D640-4377-B8D0-93BB04D8935F@oracle.com> <7d576d32-6b38-46b7-a32c-553b8e3d0504@oracle.com> <88EE1B23-C656-4277-8F9B-4A50129D92B0@oracle.com> <098F6F93-B3E0-4E62-9770-D9BB41228E53@oracle.com> <184c8120-536f-8f67-8a22-bad4f1a87afa@oracle.com> <90170317-F8FC-4C85-AB6E-5243829295F0@oracle.com> <6d720584-44bf-4080-ea99-545bcda292a2@oracle.com> <798EAA85-B213-49D5-9C0E-0BB78513C9CF@oracle.com> <5d4eab66-3f4a-d5e0-dd29-29c64b127402@oracle.com> <52708621-F7B5-4231-A925-651FE101518D@oracle.com> <48590A90-26BB-43F4-860A-5707D4D67672@oracle.com> Message-ID: On Wed, Oct 10, 2018 at 3:10 AM, Weijun Wang wrote: > > > > On Oct 10, 2018, at 1:07 AM, Martin Buchholz > wrote: > > > > Seems alright to this non-crypto expert. > > > > The key thing I would like to see working is: > > > > If I create a keystore for cacerts and then use it via > -with-cacerts-file taking the defaults, this results in goodness (which > presumably means not getting JKS keystore) > > I haven't tried this configure option before, but does it mean just copy > your own file to lib/security/cacerts? > My own mental model of -with-cacerts-file is that it effectively copies the file to replace java.base/share/lib/security/cacerts. Currently, to explore this file you need to know to use JKS and learn about the "well-known" password (where is this documented??) > Then you need to make it correct, i.e. a JKS file, or a password-less > pkcs12 file, or with-password pkcs12 but you set the correct storepass (TLS > system property?). > > > > > Make sure keystore creators don't have to specify a storepass. > > If you want to create a password-less pkcs12 file, you will need to > specify those system properties (certProtectionAlgorithm and macAlgorithm > to NONE). Then I'll make sure there is no need to specify a storepass. > Because we're trying to replace a data file that already comes with the JDK, we'll always prefer to use exactly the same format and password (or lack thereof). If and when openjdk comes with a password-less pkcs12 file, we will switch as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Wed Oct 10 20:52:06 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 10 Oct 2018 16:52:06 -0400 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> Message-ID: <79022b32-dae3-3140-ac29-aea1adcdeb12@comcast.net> On 10/10/2018 10:42 AM, Weijun Wang wrote: > >> On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: >> >> There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. > Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard? us government FIPS.? It still is. But mostly US gov't is doing EC these days... at least until all the quantum fear and doubt started creeping in. > > As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option. > > If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). I'm away from the source code - but isn't it possible to configure the default in java.security??? Maybe what you is add a warning of the new default unless disabled in java.security or explicitly set there? Mike > > --Max > > From anthony.scarpino at oracle.com Wed Oct 10 21:05:48 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 10 Oct 2018 14:05:48 -0700 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> Message-ID: On 10/10/2018 07:42 AM, Weijun Wang wrote: > > >> On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: >> >> There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. > > Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard? > > As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option. > > If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). > > --Max > > I would rather get rid of the default completely. I realize there maybe scripting issues with that. If we made some documentation guarantees a default algorithm then maybe we are stuck with having a default and can use a security property. A part of me thinks it would be foolish for an application to assume a default algorithm and may deserve to be broken so they can fix it. Even if we didn't remove defaults from older java version, in future releases it would be nice to eliminate defaults were possible. With regard to a replacement, I'd prefer over EC than RSA given a choice. But either is ok. Tony From ecki at zusammenkunft.net Wed Oct 10 21:35:29 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 10 Oct 2018 21:35:29 +0000 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com>, Message-ID: It might not apply to this specific default but in the past DSA was often chosen (over RSA) as a default as it was regarded as less suspicious to been understood as an encryption capable algorithm (as opposed to RSA). But of course that thinking was never correct and the justification for interpreting crypto law is also gone. Not having a default is actually a good idea Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev on behalf of Anthony Scarpino Gesendet: Mittwoch, Oktober 10, 2018 11:18 PM An: security-dev at openjdk.java.net Betreff: Re: DSA default algorithm for keytool -genkeypair. Bad choice? On 10/10/2018 07:42 AM, Weijun Wang wrote: > > >> On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: >> >> There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. > > Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard? > > As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option. > > If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). > > --Max > > I would rather get rid of the default completely. I realize there maybe scripting issues with that. If we made some documentation guarantees a default algorithm then maybe we are stuck with having a default and can use a security property. A part of me thinks it would be foolish for an application to assume a default algorithm and may deserve to be broken so they can fix it. Even if we didn't remove defaults from older java version, in future releases it would be nice to eliminate defaults were possible. With regard to a replacement, I'd prefer over EC than RSA given a choice. But either is ok. Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Oct 11 01:33:31 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 11 Oct 2018 09:33:31 +0800 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> Message-ID: <65C1683A-3604-453B-AF0F-472344E387F3@oracle.com> I don't know what benefit it brings to a user to remove the default. Except from forcing DSA users to add a -keyalg option, RSA and EC users will not gain anything. --Max > On Oct 11, 2018, at 5:05 AM, Anthony Scarpino wrote: > > On 10/10/2018 07:42 AM, Weijun Wang wrote: >>> On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: >>> >>> There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. >> Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard? >> As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option. >> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). >> --Max > > > I would rather get rid of the default completely. > > I realize there maybe scripting issues with that. If we made some documentation guarantees a default algorithm then maybe we are stuck with having a default and can use a security property. A part of me thinks it would be foolish for an application to assume a default algorithm and may deserve to be broken so they can fix it. > > Even if we didn't remove defaults from older java version, in future releases it would be nice to eliminate defaults were possible. > > With regard to a replacement, I'd prefer over EC than RSA given a choice. But either is ok. > > Tony From anthony.scarpino at oracle.com Thu Oct 11 04:22:52 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 10 Oct 2018 21:22:52 -0700 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <65C1683A-3604-453B-AF0F-472344E387F3@oracle.com> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> <65C1683A-3604-453B-AF0F-472344E387F3@oracle.com> Message-ID: <5e4421ea-bca4-8cbd-7e46-7df915aca8ec@oracle.com> For one, it makes the user specify what they want, perhaps learning about certificates and making an educated choice. Secondly, and more importantly, it would not making it our decisions what is a default secure algorithm for all of java. Tony On 10/10/2018 06:33 PM, Weijun Wang wrote: > I don't know what benefit it brings to a user to remove the default. Except from forcing DSA users to add a -keyalg option, RSA and EC users will not gain anything. > > --Max > >> On Oct 11, 2018, at 5:05 AM, Anthony Scarpino wrote: >> >> On 10/10/2018 07:42 AM, Weijun Wang wrote: >>>> On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: >>>> >>>> There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. >>> Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard? >>> As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option. >>> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). >>> --Max >> >> >> I would rather get rid of the default completely. >> >> I realize there maybe scripting issues with that. If we made some documentation guarantees a default algorithm then maybe we are stuck with having a default and can use a security property. A part of me thinks it would be foolish for an application to assume a default algorithm and may deserve to be broken so they can fix it. >> >> Even if we didn't remove defaults from older java version, in future releases it would be nice to eliminate defaults were possible. >> >> With regard to a replacement, I'd prefer over EC than RSA given a choice. But either is ok. >> >> Tony > From sean.mullan at oracle.com Thu Oct 11 11:53:48 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 11 Oct 2018 07:53:48 -0400 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <79022b32-dae3-3140-ac29-aea1adcdeb12@comcast.net> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> <79022b32-dae3-3140-ac29-aea1adcdeb12@comcast.net> Message-ID: On 10/10/18 4:52 PM, Michael StJohns wrote: >> There is really no other reason other than DSA keys have been the >> default keypairs generated by keytool for a long time, so there are >> some compatibility issues we would have to think through before >> changing it to another algorithm such as RSA. Weijun might have more >> insight into that. > Not really. It was the default before I join Sun Microsystems many many > years ago. I think it was made the default because at the time the RSA patent had not expired yet. JDK 1.1 (when keytool was introduced) release date: February 19, 1997 RSA patent expiration: September 21, 2000 --Sean From sean.mullan at oracle.com Thu Oct 11 13:20:01 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 11 Oct 2018 09:20:01 -0400 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <5e4421ea-bca4-8cbd-7e46-7df915aca8ec@oracle.com> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> <65C1683A-3604-453B-AF0F-472344E387F3@oracle.com> <5e4421ea-bca4-8cbd-7e46-7df915aca8ec@oracle.com> Message-ID: On 10/11/18 12:22 AM, Anthony Scarpino wrote: > For one, it makes the user specify what they want, perhaps learning > about certificates and making an educated choice.? Secondly, and more > importantly, it would not making it our decisions what is a default > secure algorithm for all of java. If we could start over again, I definitely agree. It might be too late to make that kind of change now though. Moving to a middle solution where the defaults are configurable seems like it might be best for compatibility. BTW, I sometimes forget about this feature, but keytool does have a -conf option which allows you specify default options in a configuration file, ex: # A pre-configured options file keytool.all = -keystore ${user.home}/ks keytool.list = -v keytool.genkeypair = -keyalg rsa keytool -conf preconfig -genkeypair -alias me This option was never documented in the keytool docs, so I'll file a bug for that. It doesn't specifically solve the issue but it can help avoid long command lines and accidentally using the wrong default. --Sean > > Tony > > On 10/10/2018 06:33 PM, Weijun Wang wrote: >> I don't know what benefit it brings to a user to remove the default. >> Except from forcing DSA users to add a -keyalg option, RSA and EC >> users will not gain anything. >> >> --Max >> >>> On Oct 11, 2018, at 5:05 AM, Anthony Scarpino >>> wrote: >>> >>> On 10/10/2018 07:42 AM, Weijun Wang wrote: >>>>> On Oct 10, 2018, at 7:59 PM, Sean Mullan >>>>> wrote: >>>>> >>>>> There is really no other reason other than DSA keys have been the >>>>> default keypairs generated by keytool for a long time, so there are >>>>> some compatibility issues we would have to think through before >>>>> changing it to another algorithm such as RSA. Weijun might have >>>>> more insight into that. >>>> Not really. It was the default before I join Sun Microsystems many >>>> many years ago. Maybe it was a NIST standard? >>>> As for compatibility, as long as someone is still using DSA then >>>> they might not be specifying the -keyalg option. >>>> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I >>>> wonder if RSASSA-PSS signature can always use legacy RSA keys) or >>>> EC? We don't have an option to specify ECCurve in keytool yet (a >>>> string -keysize). >>>> --Max >>> >>> >>> I would rather get rid of the default completely. >>> >>> I realize there maybe scripting issues with that.? If we made some >>> documentation guarantees a default algorithm then maybe we are stuck >>> with having a default and can use a security property.? A part of me >>> thinks it would be foolish for an application to assume a default >>> algorithm and may deserve to be broken so they can fix it. >>> >>> Even if we didn't remove defaults from older java version, in future >>> releases it would be nice to eliminate defaults were possible. >>> >>> With regard to a replacement, I'd prefer over EC than RSA given a >>> choice.? But either is ok. >>> >>> Tony >> > From adam.petcher at oracle.com Thu Oct 11 13:30:04 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 11 Oct 2018 09:30:04 -0400 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> Message-ID: <27f99fd3-168b-a602-bfa1-2445e6b72927@oracle.com> On 10/10/2018 5:05 PM, Anthony Scarpino wrote: > On 10/10/2018 07:42 AM, Weijun Wang wrote: >> >> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I >> wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? >> We don't have an option to specify ECCurve in keytool yet (a string >> -keysize). >> >> --Max >> >> > > > I would rather get rid of the default completely. +1 In addition to the usual problems with defaults, there is also the issue that the user doesn't specify how the key pair can be used. The current default produces a key that can only be used with signatures, but if we change the default, then the key may also be used for encryption (RSA) or key agreement (EC). I worry about the problems that can arise if we change the default in a way that increases the capability of the key pair that is produced. From sean.mullan at oracle.com Thu Oct 11 15:44:35 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 11 Oct 2018 11:44:35 -0400 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <27f99fd3-168b-a602-bfa1-2445e6b72927@oracle.com> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> <27f99fd3-168b-a602-bfa1-2445e6b72927@oracle.com> Message-ID: <1f935587-a316-f222-c742-b3e923851f46@oracle.com> I think if we all really think we are better off in the long run not having defaults, we probably want to do this over 2 releases and give an advance warning that the change is coming. In JDK 12, we could emit a warning, ex: $ keytool -genkeypair ... Warning: the default keypair alg (DSA) is a legacy algorithm and is no longer recommended. In the next release of the JDK, defaults will be removed and the -keyalg option must be specified. (that's a bit wordy, but you get the idea) --Sean On 10/11/18 9:30 AM, Adam Petcher wrote: > On 10/10/2018 5:05 PM, Anthony Scarpino wrote: > >> On 10/10/2018 07:42 AM, Weijun Wang wrote: >>> >>> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I >>> wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? >>> We don't have an option to specify ECCurve in keytool yet (a string >>> -keysize). >>> >>> --Max >>> >>> >> >> >> I would rather get rid of the default completely. > > +1 > > In addition to the usual problems with defaults, there is also the issue > that the user doesn't specify how the key pair can be used. The current > default produces a key that can only be used with signatures, but if we > change the default, then the key may also be used for encryption (RSA) > or key agreement (EC). I worry about the problems that can arise if we > change the default in a way that increases the capability of the key > pair that is produced. From mstjohns at comcast.net Thu Oct 11 16:06:00 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 11 Oct 2018 12:06:00 -0400 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <1f935587-a316-f222-c742-b3e923851f46@oracle.com> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> <27f99fd3-168b-a602-bfa1-2445e6b72927@oracle.com> <1f935587-a316-f222-c742-b3e923851f46@oracle.com> Message-ID: <879e8582-6c73-4ab8-9e80-3b98f2c37e4d@comcast.net> Any thought to just deprecating keytool as such and adding a new tool with more modern semantics???? e.g. don't mess with what people are using (except for including a deprecation message), but fork the keytool source tree and do some developments to "ktts" - Key tool - the sequel.?? A lot more freedom to rethink the syntax and semantics of key pair and key store generation. Mike On 10/11/2018 11:44 AM, Sean Mullan wrote: > I think if we all really think we are better off in the long run not > having defaults, we probably want to do this over 2 releases and give > an advance warning that the change is coming. In JDK 12, we could emit > a warning, ex: > > $ keytool -genkeypair ... > Warning: the default keypair alg (DSA) is a legacy algorithm and is no > longer recommended. In the next release of the JDK, defaults will be > removed and the -keyalg option must be specified. > > (that's a bit wordy, but you get the idea) > > --Sean > > On 10/11/18 9:30 AM, Adam Petcher wrote: >> On 10/10/2018 5:05 PM, Anthony Scarpino wrote: >> >>> On 10/10/2018 07:42 AM, Weijun Wang wrote: >>>> >>>> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I >>>> wonder if RSASSA-PSS signature can always use legacy RSA keys) or >>>> EC? We don't have an option to specify ECCurve in keytool yet (a >>>> string -keysize). >>>> >>>> --Max >>>> >>>> >>> >>> >>> I would rather get rid of the default completely. >> >> +1 >> >> In addition to the usual problems with defaults, there is also the >> issue that the user doesn't specify how the key pair can be used. The >> current default produces a key that can only be used with signatures, >> but if we change the default, then the key may also be used for >> encryption (RSA) or key agreement (EC). I worry about the problems >> that can arise if we change the default in a way that increases the >> capability of the key pair that is produced. > From jamil.j.nimeh at oracle.com Thu Oct 11 17:11:38 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 11 Oct 2018 10:11:38 -0700 Subject: RFR: JDK-8211866 TLS 1.3 CertificateRequest message sometimes offers disallowed signature algorithms Message-ID: <9015f590-8571-f1fb-c5b5-5b0dfa18e33b@oracle.com> Hello all, This fixes an issue with the TLS 1.3 CertificateRequest message. In cases where the server side can initially support multiple protocol versions by the time it issues a CertificateRequest message it collects the list of supported signature schemes for the signature_algorithms and signature_algorithms_cert extensions using all supported protocols as a filtering mechanism. This change alters the filtering process to use only the negotiated protocol, so only those sig algs allowed for that one protocol version will be asserted. Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211866/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8211866 From matthias.baesken at sap.com Fri Oct 12 08:12:36 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 12 Oct 2018 08:12:36 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: Message-ID: Ping ... any reviews / comments ? Should I add a category , for example "ioExceptionsWithPath" to the java.security - file to control the enabling/disabling of the enhanced exception ? java.security # # Enhanced exception message information ... #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath Thanks, Matthias From: Baesken, Matthias Sent: Dienstag, 9. Oktober 2018 14:12 To: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Alan Bateman (Alan.Bateman at oracle.com) Subject: FW: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue Hello, Alan commented on it : * This proposal will require a security review as it leaks sensitive information into exceptions. So I forward it to security-dev as well. If needed, we might use something similar to JDK-8207768 where a category has been added for enhanced exception messages to the java.security file . Best regards, Matthias From: Baesken, Matthias Sent: Dienstag, 9. Oktober 2018 13:40 To: core-libs-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue Hello, please review the following change . It enhances a number of JNU_ThrowIOExceptionWithLastError calls with path and current working directory information. For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is added. bug and webrev : https://bugs.openjdk.java.net/browse/JDK-8211752 http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Oct 12 09:18:17 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Oct 2018 10:18:17 +0100 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: Message-ID: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> On 12/10/2018 09:12, Baesken, Matthias wrote: > > Ping ? ?any reviews / comments ? > > Should I add? a category? , for example? ???ioExceptionsWithPath????? > to the java.security ? file? to control? the enabling/disabling of > the? enhanced exception ? > > ? java.security > > # > > # Enhanced exception message information > > ? > > #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath > > There are several issues with this proposal. The security concern is the main one and I think we should wait for comment from security-dev. The second concern is that the patch is incomplete and inconsistent in that it changes the exception throw by two methods, it ignores other file I/O methods that throw exceptions. Finally there is the concerns with the patch itself that both Roger and I commented on. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Oct 12 10:11:01 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 12 Oct 2018 10:11:01 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: Message-ID: <2bd4f1843b0d450a8d077e9691516598@sap.com> Hi, If this is required, I would choose a more generic tag so it can be reused in other places. I would just use "path". Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Baesken, Matthias > Sent: Freitag, 12. Oktober 2018 10:13 > To: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: [CAUTION] RE: RFR: 8211752: > JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions > with path causing the issue > > Ping ... any reviews / comments ? > > Should I add a category , for example "ioExceptionsWithPath" to the > java.security - file to control the enabling/disabling of the enhanced > exception ? > > java.security > > # > # Enhanced exception message information > ... > #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath > > > Thanks, Matthias > > > From: Baesken, Matthias > Sent: Dienstag, 9. Oktober 2018 14:12 > To: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Cc: Alan Bateman (Alan.Bateman at oracle.com) > Subject: FW: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - > enhance some IOExceptions with path causing the issue > > Hello, Alan commented on it : > > > * This proposal will require a security review as it leaks sensitive > information into exceptions. > > So I forward it to security-dev as well. > > If needed, we might use something similar to JDK-8207768 where a > category has been added for enhanced exception messages to the > java.security file . > > Best regards, Matthias > > From: Baesken, Matthias > Sent: Dienstag, 9. Oktober 2018 13:40 > To: core-libs-dev at openjdk.java.net dev at openjdk.java.net> > Cc: Langer, Christoph > >; > Lindenmaier, Goetz > > > Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - > enhance some IOExceptions with path causing the issue > > > Hello, please review the following change . > It enhances a number of JNU_ThrowIOExceptionWithLastError calls with > path and current working directory information. > For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is > added. > > bug and webrev : > > https://bugs.openjdk.java.net/browse/JDK-8211752 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/ > > Thanks, Matthias From weijun.wang at oracle.com Fri Oct 12 11:02:34 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 12 Oct 2018 19:02:34 +0800 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <1f935587-a316-f222-c742-b3e923851f46@oracle.com> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> <27f99fd3-168b-a602-bfa1-2445e6b72927@oracle.com> <1f935587-a316-f222-c742-b3e923851f46@oracle.com> Message-ID: Great, I file a CSR at https://bugs.openjdk.java.net/browse/JDK-8212111. Please take a review. Thanks Max > On Oct 11, 2018, at 11:44 PM, Sean Mullan wrote: > > I think if we all really think we are better off in the long run not having defaults, we probably want to do this over 2 releases and give an advance warning that the change is coming. In JDK 12, we could emit a warning, ex: > > $ keytool -genkeypair ... > Warning: the default keypair alg (DSA) is a legacy algorithm and is no longer recommended. In the next release of the JDK, defaults will be removed and the -keyalg option must be specified. > > (that's a bit wordy, but you get the idea) > > --Sean > > On 10/11/18 9:30 AM, Adam Petcher wrote: >> On 10/10/2018 5:05 PM, Anthony Scarpino wrote: >>> On 10/10/2018 07:42 AM, Weijun Wang wrote: >>>> >>>> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). >>>> >>>> --Max >>>> >>>> >>> >>> >>> I would rather get rid of the default completely. >> +1 >> In addition to the usual problems with defaults, there is also the issue that the user doesn't specify how the key pair can be used. The current default produces a key that can only be used with signatures, but if we change the default, then the key may also be used for encryption (RSA) or key agreement (EC). I worry about the problems that can arise if we change the default in a way that increases the capability of the key pair that is produced. > From weijun.wang at oracle.com Fri Oct 12 12:24:18 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 12 Oct 2018 20:24:18 +0800 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <879e8582-6c73-4ab8-9e80-3b98f2c37e4d@comcast.net> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> <27f99fd3-168b-a602-bfa1-2445e6b72927@oracle.com> <1f935587-a316-f222-c742-b3e923851f46@oracle.com> <879e8582-6c73-4ab8-9e80-3b98f2c37e4d@comcast.net> Message-ID: <9FDE88C3-C10E-43F6-94D9-DD65057FC0E8@oracle.com> At least, this single annoyance does not deserve a rewrite, the compatibility impact should be quite low. So far, I've heard these requests related to keytool: 1. Make it GNU-style, say, "keytool -list -keystore cacerts" to "keytool list --keystore=cacerts". 2. Add more functions, say, -importprivatekey. 3. Make some functions as APIs, say, -genkeypair, -certreq. but still need no rewrite. --Max > On Oct 12, 2018, at 12:06 AM, Michael StJohns wrote: > > Any thought to just deprecating keytool as such and adding a new tool with more modern semantics? e.g. don't mess with what people are using (except for including a deprecation message), but fork the keytool source tree and do some developments to "ktts" - Key tool - the sequel. A lot more freedom to rethink the syntax and semantics of key pair and key store generation. > > Mike > > On 10/11/2018 11:44 AM, Sean Mullan wrote: >> I think if we all really think we are better off in the long run not having defaults, we probably want to do this over 2 releases and give an advance warning that the change is coming. In JDK 12, we could emit a warning, ex: >> >> $ keytool -genkeypair ... >> Warning: the default keypair alg (DSA) is a legacy algorithm and is no longer recommended. In the next release of the JDK, defaults will be removed and the -keyalg option must be specified. >> >> (that's a bit wordy, but you get the idea) >> >> --Sean >> >> On 10/11/18 9:30 AM, Adam Petcher wrote: >>> On 10/10/2018 5:05 PM, Anthony Scarpino wrote: >>> >>>> On 10/10/2018 07:42 AM, Weijun Wang wrote: >>>>> >>>>> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). >>>>> >>>>> --Max >>>>> >>>>> >>>> >>>> >>>> I would rather get rid of the default completely. >>> >>> +1 >>> >>> In addition to the usual problems with defaults, there is also the issue that the user doesn't specify how the key pair can be used. The current default produces a key that can only be used with signatures, but if we change the default, then the key may also be used for encryption (RSA) or key agreement (EC). I worry about the problems that can arise if we change the default in a way that increases the capability of the key pair that is produced. >> > From matthias.baesken at sap.com Fri Oct 12 13:18:44 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 12 Oct 2018 13:18:44 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> Message-ID: Hi Alan, Goetz, >There are several issues with this proposal. The security concern is the main one and I think we should wait for comment from security-dev. ..... >If this is required, I would choose a more generic tag >so it can be reused in other places. >I would just use "path". > >Best regards, > Goetz. Thanks for the comments . Sure, I can use path for the category naming as well, but would be good to hear the opinions of the security-dev guys on this . > The second concern is that the patch is incomplete and inconsistent in that it changes the exception throw by two methods, >it ignores other file I/O methods that throw exceptions. We have these extended exceptions for quite some time in our JVM; we decided to enhance exceptions where we have a path already "at hand" , so it was easy to extend the exceptions . In case you think this can be done with some others , that's fine with me - do you have some concrete examples ? A lot of IO exceptions currently thrown that use JNU_ThrowIOExceptionWithLastError do not have a path (at least not where the exception is thrown). Best regards , Matthias From: Alan Bateman Sent: Freitag, 12. Oktober 2018 11:18 To: Baesken, Matthias ; security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue On 12/10/2018 09:12, Baesken, Matthias wrote: Ping ... any reviews / comments ? Should I add a category , for example "ioExceptionsWithPath" to the java.security - file to control the enabling/disabling of the enhanced exception ? java.security # # Enhanced exception message information ... #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath There are several issues with this proposal. The security concern is the main one and I think we should wait for comment from security-dev. The second concern is that the patch is incomplete and inconsistent in that it changes the exception throw by two methods, it ignores other file I/O methods that throw exceptions. Finally there is the concerns with the patch itself that both Roger and I commented on. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Oct 12 14:33:15 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 12 Oct 2018 14:33:15 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> Message-ID: Hi Matthias, I generally support this enhancement of IOExceptions to include path information. I also think that we should protect this with the java.security property "jdk.includeInExceptions" and agree that "path" would be a good choice since it is generic enough to be used in other places where Exceptions are thrown that might include path names. As for some comment from security-folks: Sean, what is your take on this? As for the implementation: We should definitely get rid of the upcall into Java from JNU_ThrowIOExceptionWithLastErrorAndPath and build the exception message in that function only, just using the " jstring path" argument. The reason for having the current implementation of ExceptionUtils. createExceptionTextWithPath, as you suggested in your webrev was that we were chasing a very specific customer issue where cwd and user.dir diverged (e.g. because of some 3rd party native library which changed the cwd). And this code is somehow still around. So, user.dir should definitely not be part of the exception message. And whether the current cwd should be contained should be reviewed in detail again. Maybe at some places it is interesting but on other places it isn't at all. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Baesken, Matthias > Sent: Freitag, 12. Oktober 2018 15:19 > To: Alan Bateman ; security- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: [CAUTION] RE: RFR: 8211752: > JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions > with path causing the issue > > Hi Alan, Goetz, > > >There are several issues with this proposal. The security concern is the main > one and I think we should wait for comment from security-dev. > ..... > > >If this is required, I would choose a more generic tag > > >so it can be reused in other places. > > >I would just use "path". > > > > > >Best regards, > > > Goetz. > > Thanks for the comments . Sure, I can use path for the category naming as > well, but would be good to hear the opinions of the security-dev guys on > this . > > > The second concern is that the patch is incomplete and inconsistent in that > it changes the exception throw by two methods, > >it ignores other file I/O methods that throw exceptions. > > We have these extended exceptions for quite some time in our JVM; we > decided to enhance exceptions where we have a path already "at hand" , > so it was easy to extend the exceptions . > In case you think this can be done with some others , that's fine with me - do > you have some concrete examples ? > > A lot of IO exceptions currently thrown that use > JNU_ThrowIOExceptionWithLastError do not have a path (at least not where > the exception is thrown). > > > Best regards , > Matthias > > > > From: Alan Bateman > Sent: Freitag, 12. Oktober 2018 11:18 > To: Baesken, Matthias ; security- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - > enhance some IOExceptions with path causing the issue > > On 12/10/2018 09:12, Baesken, Matthias wrote: > > Ping ... any reviews / comments ? > > Should I add a category , for example "ioExceptionsWithPath" to the > java.security - file to control the enabling/disabling of the enhanced > exception ? > > java.security > > # > # Enhanced exception message information > ... > #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath > > There are several issues with this proposal. The security concern is the main > one and I think we should wait for comment from security-dev. The second > concern is that the patch is incomplete and inconsistent in that it changes the > exception throw by two methods, it ignores other file I/O methods that > throw exceptions. Finally there is the concerns with the patch itself that both > Roger and I commented on. > > -Alan From sean.mullan at oracle.com Fri Oct 12 15:18:56 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 Oct 2018 11:18:56 -0400 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> Message-ID: <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> On 10/12/18 10:33 AM, Langer, Christoph wrote: > Sean, what is your take on this? Sorry, I haven't had time to look at this in more detail yet. But, let's take a step back first. Can you or Matthias explain in more detail why this fix is necessary? What are the use cases and motivation? The bug report doesn't go into any detail about that and there isn't anything in the initial RFR email that explains why this change is useful or necessary. As a general guideline or advice, RFEs should include this type of information so that Reviewers understand more of the context and motivation behind the change. Thanks, Sean From mstjohns at comcast.net Fri Oct 12 16:39:42 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 12 Oct 2018 12:39:42 -0400 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: <9FDE88C3-C10E-43F6-94D9-DD65057FC0E8@oracle.com> References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> <27f99fd3-168b-a602-bfa1-2445e6b72927@oracle.com> <1f935587-a316-f222-c742-b3e923851f46@oracle.com> <879e8582-6c73-4ab8-9e80-3b98f2c37e4d@comcast.net> <9FDE88C3-C10E-43F6-94D9-DD65057FC0E8@oracle.com> Message-ID: I wasn't thinking so much a re-write as just forking the code and fixing the things that need to be fixed while leaving the old version to wither on the vine.? The usage page for the "new" program would indicate that there are no defaults? anymore and that users should use the conf file approach if they want to establish some. This is more about not having to deal with the backwards compatibility issues. Later, Mike On 10/12/2018 8:24 AM, Weijun Wang wrote: > At least, this single annoyance does not deserve a rewrite, the compatibility impact should be quite low. > > So far, I've heard these requests related to keytool: > > 1. Make it GNU-style, say, "keytool -list -keystore cacerts" to "keytool list --keystore=cacerts". > > 2. Add more functions, say, -importprivatekey. > > 3. Make some functions as APIs, say, -genkeypair, -certreq. > > but still need no rewrite. > > --Max > > > >> On Oct 12, 2018, at 12:06 AM, Michael StJohns wrote: >> >> Any thought to just deprecating keytool as such and adding a new tool with more modern semantics? e.g. don't mess with what people are using (except for including a deprecation message), but fork the keytool source tree and do some developments to "ktts" - Key tool - the sequel. A lot more freedom to rethink the syntax and semantics of key pair and key store generation. >> >> Mike >> >> On 10/11/2018 11:44 AM, Sean Mullan wrote: >>> I think if we all really think we are better off in the long run not having defaults, we probably want to do this over 2 releases and give an advance warning that the change is coming. In JDK 12, we could emit a warning, ex: >>> >>> $ keytool -genkeypair ... >>> Warning: the default keypair alg (DSA) is a legacy algorithm and is no longer recommended. In the next release of the JDK, defaults will be removed and the -keyalg option must be specified. >>> >>> (that's a bit wordy, but you get the idea) >>> >>> --Sean >>> >>> On 10/11/18 9:30 AM, Adam Petcher wrote: >>>> On 10/10/2018 5:05 PM, Anthony Scarpino wrote: >>>> >>>>> On 10/10/2018 07:42 AM, Weijun Wang wrote: >>>>>> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). >>>>>> >>>>>> --Max >>>>>> >>>>>> >>>>> >>>>> I would rather get rid of the default completely. >>>> +1 >>>> >>>> In addition to the usual problems with defaults, there is also the issue that the user doesn't specify how the key pair can be used. The current default produces a key that can only be used with signatures, but if we change the default, then the key may also be used for encryption (RSA) or key agreement (EC). I worry about the problems that can arise if we change the default in a way that increases the capability of the key pair that is produced. From anthony.scarpino at oracle.com Fri Oct 12 23:38:30 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 12 Oct 2018 16:38:30 -0700 Subject: RFR: 8209862:CipherCore performance improvement In-Reply-To: <0388c3c4-1a99-a1f6-bf52-ce74bc8ce817@oracle.com> References: <778f299c-c2b0-be47-59a9-3690ed3f9b40@oracle.com> <4f202b2f-9d83-c043-1f29-a53e174aa07c@oracle.com> <08133352-029e-e2a1-b71d-ef681d8d787e@oracle.com> <0388c3c4-1a99-a1f6-bf52-ce74bc8ce817@oracle.com> Message-ID: <74abcf18-f41e-10e9-a6fa-a88930239779@oracle.com> I'm ok with the changes. Tony On 10/10/2018 09:26 AM, Se?n Coffey wrote: > Thanks for the review Adam. I've corrected those style issues. > > Now waiting on 2nd Reviewer. > > Regards, > Sean. > > On 08/10/18 19:18, Adam Petcher wrote: >> >> The organization is better now, thanks. The code looks good to me, but >> I would like to request another review from Tony (or someone else who >> is familiar with this code) before you push. There is a lot of >> complexity here, and it is hard for me to be sure that everything will >> behave the same after the change. It will be helpful to have another >> person examine the new code to ensure that it is correct. >> >> Minor style issues(addressing them is optional): >> >> Lines 848, 915, and 969 are longer than 80 characters >> Line 1075: no space before ? character >> >> >> On 10/2/2018 1:51 PM, Se?n Coffey wrote: >>> >>> Good points from Adam and Tony. I've taken them both on board. Sergey >>> has already eliminated a lot of duplicate code but there was further >>> optimizing possible in the two doFinal(..) methods. I've introduced a >>> new 'fillOutputBuffer' method to help. Please review : >>> >>> https://cr.openjdk.java.net/~coffeys/webrev.8209862.v2/webrev/ >>> >>> regards, >>> Sean. >>> >>> >>> On 01/10/2018 15:32, Adam Petcher wrote: >>>> Looks like a nice improvement, but is it possible to do this without >>>> duplicating code? For example, code almost identical to this also >>>> appears starting on line 860: >>>> >>>> 971 } else { // encrypting >>>> 972 try { >>>> 973 outLen = finalNoPadding(finalBuf, finalOffset, output, >>>> 974 outputOffset, finalBufLen); >>>> 975 } finally { >>>> 976 // reset after doFinal() for GCM encryption >>>> 977 requireReinit = (cipherMode == GCM_MODE); >>>> 978 if (finalBuf != input) { >>>> 979 // done with internal finalBuf array. Copied to output >>>> 980 Arrays.fill(finalBuf, (byte) 0x00); >>>> 981 } >>>> 982 } >>>> 983 } >>>> It may be possible to factor out the entire if/else statement and >>>> some of the code around it into a separate method and do the short >>>> buffer check and save/restore around it. Ideally, each doFinal >>>> method would have only a small amount of code to either allocate the >>>> array or check array lengths, and then they would call the same >>>> private method to do most of the work. >>>> >>>> I would suggest a noreg-sqe label on the ticket to document that >>>> existing regression tests are used to ensure correctness of the >>>> modified code. >>>> >>>> Minor code style comments: check for long lines (e.g. line 856) and >>>> missing spaces after commas in actual parameter lists (also e.g. >>>> line 856). Also, line 1076 is missing space around the '?' and ':' >>>> characters. I can check the code again and give you the complete >>>> list after we sort out the code duplication. >>>> >>>> >>>> On 10/1/2018 9:11 AM, Se?n Coffey wrote: >>>>> JDK-8207775 introduced some performance regressions in the >>>>> ciphercore area. Sergey Kuksenko has been looking at this and has >>>>> contributed the following patch: >>>>> >>>>> http://cr.openjdk.java.net/~skuksenko/crypto/8209862/ >>>>> bug report : https://bugs.openjdk.java.net/browse/JDK-8209862 >>>>> >>>>> I've been reviewing it and ran functionality and TCK testing. >>>>> Didn't see any issues. Sergey has also confirmed that the patch >>>>> helps to alleviate the performance issues introduced. More details >>>>> regards approach for fix are in the bug description. >>>>> >>>>> Thanks Sergey! I'm looking for another review from security team. >>>>> >>>> >>> >> > From weijun.wang at oracle.com Sat Oct 13 00:48:30 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 13 Oct 2018 08:48:30 +0800 Subject: DSA default algorithm for keytool -genkeypair. Bad choice? In-Reply-To: References: <285cad31-2884-20a7-caa0-fd8ed88332ef@oracle.com> <2A32F779-82AC-492B-B2A7-8C90D43C8B22@oracle.com> <27f99fd3-168b-a602-bfa1-2445e6b72927@oracle.com> <1f935587-a316-f222-c742-b3e923851f46@oracle.com> <879e8582-6c73-4ab8-9e80-3b98f2c37e4d@comcast.net> <9FDE88C3-C10E-43F6-94D9-DD65057FC0E8@oracle.com> Message-ID: I see. The conf file is not smart enough to deal with default values for -sigalg, which can be different from different -keyalg/-keysize values. Thanks Max > On Oct 13, 2018, at 12:39 AM, Michael StJohns wrote: > > I wasn't thinking so much a re-write as just forking the code and fixing the things that need to be fixed while leaving the old version to wither on the vine. The usage page for the "new" program would indicate that there are no defaults anymore and that users should use the conf file approach if they want to establish some. > > This is more about not having to deal with the backwards compatibility issues. > > Later, Mike > > > On 10/12/2018 8:24 AM, Weijun Wang wrote: >> At least, this single annoyance does not deserve a rewrite, the compatibility impact should be quite low. >> >> So far, I've heard these requests related to keytool: >> >> 1. Make it GNU-style, say, "keytool -list -keystore cacerts" to "keytool list --keystore=cacerts". >> >> 2. Add more functions, say, -importprivatekey. >> >> 3. Make some functions as APIs, say, -genkeypair, -certreq. >> >> but still need no rewrite. >> >> --Max >> >> >> >>> On Oct 12, 2018, at 12:06 AM, Michael StJohns wrote: >>> >>> Any thought to just deprecating keytool as such and adding a new tool with more modern semantics? e.g. don't mess with what people are using (except for including a deprecation message), but fork the keytool source tree and do some developments to "ktts" - Key tool - the sequel. A lot more freedom to rethink the syntax and semantics of key pair and key store generation. >>> >>> Mike >>> >>> On 10/11/2018 11:44 AM, Sean Mullan wrote: >>>> I think if we all really think we are better off in the long run not having defaults, we probably want to do this over 2 releases and give an advance warning that the change is coming. In JDK 12, we could emit a warning, ex: >>>> >>>> $ keytool -genkeypair ... >>>> Warning: the default keypair alg (DSA) is a legacy algorithm and is no longer recommended. In the next release of the JDK, defaults will be removed and the -keyalg option must be specified. >>>> >>>> (that's a bit wordy, but you get the idea) >>>> >>>> --Sean >>>> >>>> On 10/11/18 9:30 AM, Adam Petcher wrote: >>>>> On 10/10/2018 5:05 PM, Anthony Scarpino wrote: >>>>> >>>>>> On 10/10/2018 07:42 AM, Weijun Wang wrote: >>>>>>> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). >>>>>>> >>>>>>> --Max >>>>>>> >>>>>>> >>>>>> >>>>>> I would rather get rid of the default completely. >>>>> +1 >>>>> >>>>> In addition to the usual problems with defaults, there is also the issue that the user doesn't specify how the key pair can be used. The current default produces a key that can only be used with signatures, but if we change the default, then the key may also be used for encryption (RSA) or key agreement (EC). I worry about the problems that can arise if we change the default in a way that increases the capability of the key pair that is produced. > > From jamil.j.nimeh at oracle.com Sat Oct 13 04:39:22 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 12 Oct 2018 21:39:22 -0700 Subject: RFR JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume Message-ID: <422d92e9-e7fb-f0c7-2a35-27caf144359a@oracle.com> Hello all, This addresses an issue where the client hello in a resumed TLS 1.3 session lacks the server_name client hello extension.? This can cause servers who use this extension field to direct traffic to websites to present other certificate chains for other websites than the one the client actually desires (and specified in the original client hello where the extension is present). JBS: https://bugs.openjdk.java.net/browse/JDK-8211806 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211806/ Happy Friday! --Jamil From weijun.wang at oracle.com Mon Oct 15 02:32:13 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 15 Oct 2018 10:32:13 +0800 Subject: RFR 8212165: JGSS: Fix cut/paste error in NativeUtil.c Message-ID: <7BF58AB1-0200-431E-A7F5-0D0DAEDA6599@oracle.com> Hi All Please take a review on a change in DEF_JNI_OnLoad of NativeUtil.c: diff --git a/src/java.security.jgss/share/native/libj2gss/NativeUtil.c b/src/java.security.jgss/share/native/libj2gss/NativeUtil.c --- a/src/java.security.jgss/share/native/libj2gss/NativeUtil.c +++ b/src/java.security.jgss/share/native/libj2gss/NativeUtil.c @@ -145,7 +145,7 @@ return JNI_ERR; } CLS_GSSNameElement = (*env)->NewGlobalRef(env, cls); - if (CLS_GSSException == NULL) { + if (CLS_GSSNameElement == NULL) { return JNI_ERR; } cls = (*env)->FindClass(env, "sun/security/jgss/wrapper/GSSCredElement"); The bug is reported and fixed by Viktor Dukhovni . Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Oct 15 02:53:58 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 15 Oct 2018 10:53:58 +0800 Subject: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary In-Reply-To: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com> References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com> Message-ID: Hi John I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined? If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be! Thanks Max > On Oct 15, 2018, at 10:36 AM, sha.jiang at oracle.com wrote: > > Hi, > This patch moves test/jdk/lib/testlibrary/jdk/testlibrary/SimpleSSLContext.java to test/lib/jdk/test/lib/net/SimpleSSLContext.java. > > Webrev: http://cr.openjdk.java.net/~jjiang/8211978/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8211978 > > Best regards, > John Jiang > From anthony.scarpino at oracle.com Mon Oct 15 03:04:20 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Sun, 14 Oct 2018 20:04:20 -0700 Subject: RFR: 8211426: SSL handshake succeeds under JDK 9 (and earlier) but not under JDK 11 Message-ID: <6D294BF2-17A2-4866-A5B2-877D94C98228@oracle.com> I?d like a review of this fix for when DSA is the only key available. It?s debatable how realistic this situation is, but it is a regression and key tool uses dsa by default. The fix is to remove tls1.3 from the default protocols. The placement of the code change is to minimize the keymanager check to only SSLContext setup and not have a check run with every connection. http://cr.openjdk.java.net/~ascarpino/8211426/webrev.00/ This webrev does not include the test as I did not have time to modify it yet. I will include that in a future review after my vacation. Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Oct 15 06:40:13 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Oct 2018 07:40:13 +0100 Subject: RFR 8212165: JGSS: Fix cut/paste error in NativeUtil.c In-Reply-To: <7BF58AB1-0200-431E-A7F5-0D0DAEDA6599@oracle.com> References: <7BF58AB1-0200-431E-A7F5-0D0DAEDA6599@oracle.com> Message-ID: <1a1ef6d4-f89d-ffb6-0640-c62d44fb6987@oracle.com> On 15/10/2018 03:32, Weijun Wang wrote: > Hi All > > Please take a review on a change in?DEF_JNI_OnLoad of NativeUtil.c: > > *diff --git > a/src/java.security.jgss/share/native/libj2gss/NativeUtil.c > b/src/java.security.jgss/share/native/libj2gss/NativeUtil.c* > *--- a/src/java.security.jgss/share/native/libj2gss/NativeUtil.c* > *+++ b/src/java.security.jgss/share/native/libj2gss/NativeUtil.c* > @@ -145,7 +145,7 @@ > ? return JNI_ERR; > } > CLS_GSSNameElement = (*env)->NewGlobalRef(env, cls); > - if (CLS_GSSException == NULL) { > + if (CLS_GSSNameElement == NULL) { > ? return JNI_ERR; > } > cls = (*env)->FindClass(env, "sun/security/jgss/wrapper/GSSCredElement"); > This looks okay to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Mon Oct 15 09:21:40 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 15 Oct 2018 10:21:40 +0100 Subject: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary In-Reply-To: References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com> Message-ID: Hi Max, These tests are whitebox tests - the tests classes are patched into the java.net.http module, and as a consequence they can't compile against library classes which are on the classpath. This is the unfortunate reason for the presence of a SimpleSSLContext clone in there. best regards, -- daniel On 15/10/2018 03:53, Weijun Wang wrote: > Hi John > > I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined? > > If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be! > > Thanks > Max From weijun.wang at oracle.com Mon Oct 15 09:53:41 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 15 Oct 2018 17:53:41 +0800 Subject: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary In-Reply-To: References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com> Message-ID: <5671C850-A87D-4721-8246-86545988BF27@oracle.com> This is bad. Maybe we can duplicate the ASCII-fied data. I don't have a strong opinion now. --Max > On Oct 15, 2018, at 5:21 PM, Daniel Fuchs wrote: > > Hi Max, > > These tests are whitebox tests - the tests classes are patched > into the java.net.http module, and as a consequence they can't > compile against library classes which are on the classpath. > This is the unfortunate reason for the presence of a > SimpleSSLContext clone in there. > > best regards, > > -- daniel > > On 15/10/2018 03:53, Weijun Wang wrote: >> Hi John >> I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined? >> If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be! >> Thanks >> Max > From sha.jiang at oracle.com Mon Oct 15 09:55:01 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 15 Oct 2018 17:55:01 +0800 Subject: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary In-Reply-To: References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com> Message-ID: <70e70b4b-9a36-fe3e-2a3f-cccc44b6f516@oracle.com> At least, the inner SimpleSSLContext classes in AbstractSSLTubeTest.java and FlowTest.java could be combined. I'm doing it. Best regards, John Jiang On 2018/10/15 17:21, Daniel Fuchs wrote: > Hi Max, > > These tests are whitebox tests - the tests classes are patched > into the java.net.http module, and as a consequence they can't > compile against library classes which are on the classpath. > This is the unfortunate reason for the presence of a > SimpleSSLContext clone in there. > > best regards, > > -- daniel > > On 15/10/2018 03:53, Weijun Wang wrote: >> Hi John >> >> I see testkeys is directly referenced in AbstractSSLTubeTest.java and >> FlowTest.java by an inner class also named SimpleSSLContext. Is it >> very different from the one in SimpleSSLContext.java? Can they be >> combined? >> >> If so, then we have a chance to ASCII-fy the testkeys file and >> directly include it inside SimpleSSLContext.java. This way we can >> delete one more binary file and do not need to care about file >> permissions. What a marvelous gain would that be! >> >> Thanks >> Max > > From chris.hegarty at oracle.com Mon Oct 15 10:01:33 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 15 Oct 2018 11:01:33 +0100 Subject: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary In-Reply-To: <5671C850-A87D-4721-8246-86545988BF27@oracle.com> References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com> <5671C850-A87D-4721-8246-86545988BF27@oracle.com> Message-ID: <63b5102f-6d62-a188-f8de-83e1dfde5163@oracle.com> On 15/10/18 10:53, Weijun Wang wrote: > This is bad. In the absence of better test library, module-patching, and jtreg support, this is what we end up with. It's not too bad. > Maybe we can duplicate the ASCII-fied data. I don't have a strong opinion now. Duplicating the testkeys, regardless of ASCII-ification seems worse than the duplication of this small trivial implementation class. -Chris. > --Max > >> On Oct 15, 2018, at 5:21 PM, Daniel Fuchs wrote: >> >> Hi Max, >> >> These tests are whitebox tests - the tests classes are patched >> into the java.net.http module, and as a consequence they can't >> compile against library classes which are on the classpath. >> This is the unfortunate reason for the presence of a >> SimpleSSLContext clone in there. >> >> best regards, >> >> -- daniel >> >> On 15/10/2018 03:53, Weijun Wang wrote: >>> Hi John >>> I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined? >>> If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be! >>> Thanks >>> Max >> > From sha.jiang at oracle.com Mon Oct 15 10:07:17 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 15 Oct 2018 18:07:17 +0800 Subject: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary In-Reply-To: <70e70b4b-9a36-fe3e-2a3f-cccc44b6f516@oracle.com> References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com> <70e70b4b-9a36-fe3e-2a3f-cccc44b6f516@oracle.com> Message-ID: <409bf625-5d2c-0980-ea77-3de1b94fb081@oracle.com> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8211978/webrev.01/ AbstractSSLTubeTest.java and FlowTest.java now use the same internal.net.http.SimpleSSLContext.java In addition, it looks the original jdk/testlibrary/SimpleSSLContext.java could accept an alternative keystore file, so I don't change this logic and keep the binary testkeys. Best regards, John Jiang On 2018/10/15 17:55, sha.jiang at oracle.com wrote: > At least, the inner SimpleSSLContext classes in > AbstractSSLTubeTest.java and FlowTest.java could be combined. > I'm doing it. > > Best regards, > John Jiang > > On 2018/10/15 17:21, Daniel Fuchs wrote: >> Hi Max, >> >> These tests are whitebox tests - the tests classes are patched >> into the java.net.http module, and as a consequence they can't >> compile against library classes which are on the classpath. >> This is the unfortunate reason for the presence of a >> SimpleSSLContext clone in there. >> >> best regards, >> >> -- daniel >> >> On 15/10/2018 03:53, Weijun Wang wrote: >>> Hi John >>> >>> I see testkeys is directly referenced in AbstractSSLTubeTest.java >>> and FlowTest.java by an inner class also named SimpleSSLContext. Is >>> it very different from the one in SimpleSSLContext.java? Can they be >>> combined? >>> >>> If so, then we have a chance to ASCII-fy the testkeys file and >>> directly include it inside SimpleSSLContext.java. This way we can >>> delete one more binary file and do not need to care about file >>> permissions. What a marvelous gain would that be! >>> >>> Thanks >>> Max >> >> > > From weijun.wang at oracle.com Mon Oct 15 10:10:25 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 15 Oct 2018 18:10:25 +0800 Subject: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary In-Reply-To: <63b5102f-6d62-a188-f8de-83e1dfde5163@oracle.com> References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com> <5671C850-A87D-4721-8246-86545988BF27@oracle.com> <63b5102f-6d62-a188-f8de-83e1dfde5163@oracle.com> Message-ID: <114E135E-9CB9-484C-B179-158AD8093D4C@oracle.com> > On Oct 15, 2018, at 6:01 PM, Chris Hegarty wrote: > > On 15/10/18 10:53, Weijun Wang wrote: >> This is bad. > > In the absence of better test library, module-patching, > and jtreg support, this is what we end up with. It's > not too bad. I meant this is unfortunate, or this is a bad situation. No complaint to the tests themselves. > >> Maybe we can duplicate the ASCII-fied data. I don't have a strong opinion now. > > Duplicating the testkeys, regardless of ASCII-ification > seems worse than the duplication of this small trivial > implementation class. I understand the duplication of the class is inevitable anyway now. Just thought if the data should be duplicated too. On one hand it's about ASCII-ification, also, it's about test maintaining. Every time I see "../../.." I feel scared. Thanks Max > > -Chris. > >> --Max >>> On Oct 15, 2018, at 5:21 PM, Daniel Fuchs wrote: >>> >>> Hi Max, >>> >>> These tests are whitebox tests - the tests classes are patched >>> into the java.net.http module, and as a consequence they can't >>> compile against library classes which are on the classpath. >>> This is the unfortunate reason for the presence of a >>> SimpleSSLContext clone in there. >>> >>> best regards, >>> >>> -- daniel >>> >>> On 15/10/2018 03:53, Weijun Wang wrote: >>>> Hi John >>>> I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined? >>>> If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be! >>>> Thanks >>>> Max >>> From chris.hegarty at oracle.com Mon Oct 15 10:22:34 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 15 Oct 2018 11:22:34 +0100 Subject: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary In-Reply-To: <409bf625-5d2c-0980-ea77-3de1b94fb081@oracle.com> References: <9b8a10a9-0e74-d612-1fe7-18380e742209@oracle.com> <70e70b4b-9a36-fe3e-2a3f-cccc44b6f516@oracle.com> <409bf625-5d2c-0980-ea77-3de1b94fb081@oracle.com> Message-ID: <6981bc96-4e15-9a51-8054-b3a54a8fedf2@oracle.com> On 15/10/18 11:07, sha.jiang at oracle.com wrote: > Please review the updated webrev: > http://cr.openjdk.java.net/~jjiang/8211978/webrev.01/ > AbstractSSLTubeTest.java and FlowTest.java now use the same > internal.net.http.SimpleSSLContext.java This looks good to me. Thanks John. Trivially, can you please fix an existing line length issue in ManyRequests2.java and ManyRequestsLegacy.java? Where the @summary and @run lines could be split better across a few lines ( no need to regenerate the webrev ). -Chris. From bradford.wetmore at oracle.com Mon Oct 15 15:36:09 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 15 Oct 2018 08:36:09 -0700 Subject: RFR JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume In-Reply-To: <422d92e9-e7fb-f0c7-2a35-27caf144359a@oracle.com> References: <422d92e9-e7fb-f0c7-2a35-27caf144359a@oracle.com> Message-ID: <90958ba8-3186-d715-428f-41613365474f@oracle.com> Jamil, Do you have an idea for a unit test? Are there any test servers that can do virtual server in our suites? (e.g. return certs based on their server_name?) Otherwise, I'd to do a quick double check of a couple things in the code, but initially it looks ok. Brad On 10/12/2018 9:39 PM, Jamil Nimeh wrote: > Hello all, > > This addresses an issue where the client hello in a resumed TLS 1.3 > session lacks the server_name client hello extension.? This can cause > servers who use this extension field to direct traffic to websites to > present other certificate chains for other websites than the one the > client actually desires (and specified in the original client hello > where the extension is present). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211806 > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211806/ > > Happy Friday! > > --Jamil > From jamil.j.nimeh at oracle.com Mon Oct 15 15:41:33 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 15 Oct 2018 08:41:33 -0700 Subject: RFR JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume In-Reply-To: <90958ba8-3186-d715-428f-41613365474f@oracle.com> References: <422d92e9-e7fb-f0c7-2a35-27caf144359a@oracle.com> <90958ba8-3186-d715-428f-41613365474f@oracle.com> Message-ID: <080125c7-1649-2ba6-ec6d-cccffbf69d3f@oracle.com> Yes, in fact I'm building the test now.? Sorry, I got a bit trigger-happy on getting the fix in place and forgot to cook up the test for it!? So there will be a .02 version coming shortly. In terms of testing, I think I found a way without having to do virtual servers and can even bypass sockets and use engines instead.? My plan is to set up the client with a made-up server name a la SSLParameters.setServerNames.? Then on the server side set a matcher that explicitly checks for that name only.? When the session gets resumed, the extension should be missing and cause an error.? With the patch it should be there and things should pass. At least that's my working theory.? Hopefully it will pan out. --Jamil On 10/15/2018 08:36 AM, Bradford Wetmore wrote: > Jamil, > > Do you have an idea for a unit test?? Are there any test servers that > can do virtual server in our suites?? (e.g. return certs based on > their server_name?) > > Otherwise, I'd to do a quick double check of a couple things in the > code, but initially it looks ok. > > Brad > > > On 10/12/2018 9:39 PM, Jamil Nimeh wrote: >> Hello all, >> >> This addresses an issue where the client hello in a resumed TLS 1.3 >> session lacks the server_name client hello extension.? This can cause >> servers who use this extension field to direct traffic to websites to >> present other certificate chains for other websites than the one the >> client actually desires (and specified in the original client hello >> where the extension is present). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8211806 >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211806/ >> >> Happy Friday! >> >> --Jamil >> From sean.mullan at oracle.com Mon Oct 15 17:59:03 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 15 Oct 2018 13:59:03 -0400 Subject: RFR [12]: 8210448: Copy Java XML Digital Signature API Specification into java.xml.crypto javadocs Message-ID: Please review this change to copy the normative parts of the Java XML Digital Signature API Specification into the java.xml.crypto module javadocs and update relevant links in the javadocs. The Java XML Digital Signature API Specification was published as part of JSR 105 and was previously included in the JDK Security Guides but as of JDK 10 had been removed and is no longer maintained. Also as part of this change, I moved all of the package.html files in this module to the newer package-info.java format. webrev:http://cr.openjdk.java.net/~mullan/webrevs/8210448/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8212188 --Sean From will.sargent at gmail.com Mon Oct 15 18:28:31 2018 From: will.sargent at gmail.com (Will Sargent) Date: Mon, 15 Oct 2018 11:28:31 -0700 Subject: Fluent builder API for JCA/JSSE classes Message-ID: Hi all, I've released a library that adds a fluent builder API library for JCA factory and generator classes. The primary use of this package is to set up test X.509 certificates, private keys and trust stores, but it's also helpful for picking out good defaults and working on a higher level than the raw JCA classes themselves. It's available at https://github.com/tersesystems/securitybuilder Example below of building up an SSLContext from scratch: public class X509CertificateCreatorTest { @Test public void testFunctionalStyle() throws Exception { FinalStage keyPairCreator = KeyPairCreator.creator().withRSA().withKeySize(2048); RSAKeyPair rootKeyPair = keyPairCreator.create(); RSAKeyPair intermediateKeyPair = keyPairCreator.create(); RSAKeyPair eePair = keyPairCreator.create(); IssuerStage creator = X509CertificateCreator.creator().withSHA256withRSA().withDuration(Duration.ofDays(365)); String issuer = "CN=letsencrypt.derp,O=Root CA"; X509Certificate[] chain = creator .withRootCA(issuer, rootKeyPair, 2) .chain( rootKeyPair.getPrivate(), rootCreator -> rootCreator .withPublicKey(intermediateKeyPair.getPublic()) .withSubject("OU=intermediate CA") .withCertificateAuthorityExtensions(0) .chain( intermediateKeyPair.getPrivate(), intCreator -> intCreator .withPublicKey(eePair.getPublic()) .withSubject("CN=tersesystems.com") .withEndEntityExtensions() .chain())) .create(); PrivateKeyStore privateKeyStore = PrivateKeyStore.create("tersesystems.com", eePair.getPrivate(), chain); TrustStore trustStore = TrustStore.create(singletonList(chain[2]), cert -> "letsencrypt.derp"); try { final PKIXCertPathValidatorResult result = CertificateChainValidator.validator() .withAnchor(new TrustAnchor(issuer, rootKeyPair.getPublic(), null)) .withCertificates(chain) .validate(); final PublicKey subjectPublicKey = result.getPublicKey(); assertThat(subjectPublicKey).isEqualTo(eePair.getPublic()); } catch (final CertPathValidatorException cpve) { fail("Cannot test exception", cpve); } SSLContext sslContext = SSLContextBuilder.builder() .withTLS() .withKeyManager( KeyManagerBuilder.builder() .withSunX509() .withPrivateKeyStore(privateKeyStore) .build()) .withTrustManager( TrustManagerBuilder.builder() .withDefaultAlgorithm() .withTrustStore(trustStore) .build()) .build(); assertThat(sslContext).isNotNull(); } } Thanks, Will. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Oct 15 18:36:43 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 15 Oct 2018 11:36:43 -0700 Subject: RFR: 8210989 TLSv1.2 not authenticating using PSS certificates In-Reply-To: References: Message-ID: <7d2b9936-69af-8cdc-6edf-45f5d5d0d275@oracle.com> Looks nice to me. To help to remember the decision, would you mind add a comment in the T12CertificateRequestConsumer.consume() block about why we don't use the CertificateRequest.certificate_types any more. Maybe, some words like, "Note that the certificate_types field is not used here. The supported_signature_algorithms field has provide sufficient information". Thanks, Xuelei On 10/7/2018 9:33 AM, Jamil Nimeh wrote: > Hello all, this fixes an issue where for TLSv1.2 connections > specifically, clients will not authenticate using PSS certs even when > PSS signature algorithms are asserted in the CertificateRequest > message.? This brings in a method for client certificate selection > similar to how we do it for TLS 1.3.? TLS 1.3, 1.1 and 1.0 client > certificate selection is not affected by this fix. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210989 > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210989/webrev.01/ > > --Jamil > From ecki at zusammenkunft.net Mon Oct 15 20:27:01 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 15 Oct 2018 22:27:01 +0200 Subject: Fluent builder API for JCA/JSSE classes In-Reply-To: References: Message-ID: <5bc4f815.1c69fb81.daa2d.a7d2@mx.google.com> Thats very cool! Maybe this is the right thread to discuss the future of the sun.security.x509 package. Currently your implementation will only work if that package is exported. The Depth of implementation of those classes however would be a nice Addition to an (optional?) API. Gruss Bernd -- http://bernd.eckenfels.net Von: Will Sargent Gesendet: Montag, 15. Oktober 2018 22:13 An: security-dev at openjdk.java.net Betreff: Fluent builder API for JCA/JSSE classes Hi all, I've released a library that adds a fluent builder API library for?JCA factory and generator classes. The primary use of this package is to set up test X.509 certificates, private keys and trust stores, but it's also helpful for picking out good defaults and working on a higher level than the raw JCA classes themselves.? It's available at https://github.com/tersesystems/securitybuilder Example below of building up an SSLContext from scratch: public class X509CertificateCreatorTest { @Test public void testFunctionalStyle() throws Exception { FinalStage keyPairCreator = KeyPairCreator.creator().withRSA().withKeySize(2048); RSAKeyPair rootKeyPair = keyPairCreator.create(); RSAKeyPair intermediateKeyPair = keyPairCreator.create(); RSAKeyPair eePair = keyPairCreator.create(); IssuerStage creator = X509CertificateCreator.creator().withSHA256withRSA().withDuration(Duration.ofDays(365)); String issuer = "CN=letsencrypt.derp,O=Root CA"; X509Certificate[] chain = creator .withRootCA(issuer, rootKeyPair, 2) .chain( rootKeyPair.getPrivate(), rootCreator -> rootCreator .withPublicKey(intermediateKeyPair.getPublic()) .withSubject("OU=intermediate CA") .withCertificateAuthorityExtensions(0) .chain( intermediateKeyPair.getPrivate(), intCreator -> intCreator .withPublicKey(eePair.getPublic()) .withSubject("CN=tersesystems.com") .withEndEntityExtensions() .chain())) .create(); PrivateKeyStore privateKeyStore = PrivateKeyStore.create("tersesystems.com", eePair.getPrivate(), chain); TrustStore trustStore = TrustStore.create(singletonList(chain[2]), cert -> "letsencrypt.derp"); try { final PKIXCertPathValidatorResult result = CertificateChainValidator.validator() .withAnchor(new TrustAnchor(issuer, rootKeyPair.getPublic(), null)) .withCertificates(chain) .validate(); final PublicKey subjectPublicKey = result.getPublicKey(); assertThat(subjectPublicKey).isEqualTo(eePair.getPublic()); } catch (final CertPathValidatorException cpve) { fail("Cannot test exception", cpve); } SSLContext sslContext = SSLContextBuilder.builder() .withTLS() .withKeyManager( KeyManagerBuilder.builder() .withSunX509() .withPrivateKeyStore(privateKeyStore) .build()) .withTrustManager( TrustManagerBuilder.builder() .withDefaultAlgorithm() .withTrustStore(trustStore) .build()) .build(); assertThat(sslContext).isNotNull(); } } Thanks, Will. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Oct 16 01:34:34 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Oct 2018 09:34:34 +0800 Subject: RFR 8212216: JGSS: Fix leak in exception cases in getJavaOID() Message-ID: <5FDE8642-773E-4810-92EE-CDB54DAA7D6E@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8212216/webrev.00/ This bug is reported and fixed by Nico Williams . No regression test, memory leak. Thanks Max From weijun.wang at oracle.com Tue Oct 16 01:43:15 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Oct 2018 09:43:15 +0800 Subject: RFR 8212217: JGSS: Don't dispose() of creds too eagerly Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8212217/webrev.00/ This bug is reported and fixed by Nico Williams . I'll think if a regression test can be added. Thanks Max From sha.jiang at oracle.com Tue Oct 16 01:52:25 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 16 Oct 2018 09:52:25 +0800 Subject: RFR JDK-8211971: Move security/cacerts/VerifyCACerts.java and security/CheckBlacklistedCerts.java Message-ID: Hi, This fix moves tests VerifyCACerts.java and CheckBlacklistedCerts.java in lib/security to sun/security/lib. Issue: https://bugs.openjdk.java.net/browse/JDK-8211971 Webrev: http://cr.openjdk.java.net/~jjiang/8211971/webrev.00/ Best regards, John JIang From weijun.wang at oracle.com Tue Oct 16 02:04:07 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Oct 2018 10:04:07 +0800 Subject: RFR JDK-8211971: Move security/cacerts/VerifyCACerts.java and security/CheckBlacklistedCerts.java In-Reply-To: References: Message-ID: <5610FF9B-B906-41D7-B0A6-9B8631EFD42F@oracle.com> The change looks fine. Thanks Max > On Oct 16, 2018, at 9:52 AM, sha.jiang at oracle.com wrote: > > Hi, > This fix moves tests VerifyCACerts.java and CheckBlacklistedCerts.java in lib/security to sun/security/lib. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211971 > Webrev: http://cr.openjdk.java.net/~jjiang/8211971/webrev.00/ > > Best regards, > John JIang > From xuelei.fan at oracle.com Tue Oct 16 03:52:03 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 15 Oct 2018 20:52:03 -0700 Subject: RFR: JDK-8211866 TLS 1.3 CertificateRequest message sometimes offers disallowed signature algorithms In-Reply-To: <9015f590-8571-f1fb-c5b5-5b0dfa18e33b@oracle.com> References: <9015f590-8571-f1fb-c5b5-5b0dfa18e33b@oracle.com> Message-ID: Looks fine to me. Can the following two lines joined into one? Looks like the length does not exceed 80 characters. int vectorLen = SignatureScheme.sizeInRecord() * sigAlgs.size(); Thanks, Xuelei On 10/11/2018 10:11 AM, Jamil Nimeh wrote: > Hello all, > > This fixes an issue with the TLS 1.3 CertificateRequest message. In > cases where the server side can initially support multiple protocol > versions by the time it issues a CertificateRequest message it collects > the list of supported signature schemes for the signature_algorithms and > signature_algorithms_cert extensions using all supported protocols as a > filtering mechanism. > > This change alters the filtering process to use only the negotiated > protocol, so only those sig algs allowed for that one protocol version > will be asserted. > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211866/webrev.01/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211866 > From weijun.wang at oracle.com Tue Oct 16 05:37:17 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Oct 2018 13:37:17 +0800 Subject: RFR [12]: 8210448: Copy Java XML Digital Signature API Specification into java.xml.crypto javadocs In-Reply-To: References: Message-ID: <28606AC1-90FE-404E-A3BA-E2629D3ED7D4@oracle.com> The links from source to "DOM Mechanism Requirements" use "package-summary.html#dom_reqs", but the id in dsig/package-info.java is "dom_req". In the sections you copied from the JSR 105 spec, some class/method names have links to the API spec pages, some only formatted as fixed-width texts (even if first appeared). Is this intended? Otherwise looks fine. Thanks Max > On Oct 16, 2018, at 1:59 AM, Sean Mullan wrote: > > Please review this change to copy the normative parts of the Java XML Digital Signature API Specification into the java.xml.crypto module javadocs and update relevant links in the javadocs. The Java XML Digital Signature API Specification was published as part of JSR 105 and was previously included in the JDK Security Guides but as of JDK 10 had been removed and is no longer maintained. > > Also as part of this change, I moved all of the package.html files in this module to the newer package-info.java format. > > webrev:http://cr.openjdk.java.net/~mullan/webrevs/8210448/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8212188 > > --Sean > From sha.jiang at oracle.com Tue Oct 16 08:08:00 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 16 Oct 2018 16:08:00 +0800 Subject: RFR[12] JDK-8210632: Add key exchange algorithm to javax/net/ssl/TLSCommon/CipherSuite.java In-Reply-To: References: Message-ID: Ping... On 2018/10/10 11:25, sha.jiang at oracle.com wrote: > Hi, > It would be better that javax/net/ssl/TLSCommon/CipherSuite.java has > an attribute on key exchange algorithm. > This attribute could be used on selecting appropriate certificates by > some tests. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8210632 > Webrev: http://cr.openjdk.java.net/~jjiang/8210632/webrev.00/ > > Best regards, > John Jiang > > From xuelei.fan at oracle.com Tue Oct 16 15:20:15 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 16 Oct 2018 08:20:15 -0700 Subject: RFR[12] JDK-8210632: Add key exchange algorithm to javax/net/ssl/TLSCommon/CipherSuite.java In-Reply-To: References: Message-ID: <58d13d1d-4f76-205f-5e0c-f56ba72c9126@oracle.com> Looks fine to me. There is another potential improvement to divide the ECDHE_RSA, and other KeyExAlgorithms, into two parts, the key exchange algorithm (ECDHE), certificate key algorithm (EC) and the optional certificate signature algorithms (RSA). Thanks, Xuelei On 10/16/2018 1:08 AM, sha.jiang at oracle.com wrote: > Ping... > > On 2018/10/10 11:25, sha.jiang at oracle.com wrote: >> Hi, >> It would be better that javax/net/ssl/TLSCommon/CipherSuite.java has >> an attribute on key exchange algorithm. >> This attribute could be used on selecting appropriate certificates by >> some tests. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8210632 >> Webrev: http://cr.openjdk.java.net/~jjiang/8210632/webrev.00/ >> >> Best regards, >> John Jiang >> >> > From sean.mullan at oracle.com Tue Oct 16 15:53:30 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 Oct 2018 11:53:30 -0400 Subject: RFR [12]: 8210448: Copy Java XML Digital Signature API Specification into java.xml.crypto javadocs In-Reply-To: <28606AC1-90FE-404E-A3BA-E2629D3ED7D4@oracle.com> References: <28606AC1-90FE-404E-A3BA-E2629D3ED7D4@oracle.com> Message-ID: On 10/16/18 1:37 AM, Weijun Wang wrote: > The links from source to "DOM Mechanism Requirements" use "package-summary.html#dom_reqs", but the id in dsig/package-info.java is "dom_req". Good catch! > In the sections you copied from the JSR 105 spec, some class/method names have links to the API spec pages, some only formatted as fixed-width texts (even if first appeared). Is this intended? Yes. The links are not on all of the classes but just on the more significant classes. > Otherwise looks fine. Can you also review the CSR and add your name as reviewer? Thanks, Sean > > Thanks > Max > > >> On Oct 16, 2018, at 1:59 AM, Sean Mullan wrote: >> >> Please review this change to copy the normative parts of the Java XML Digital Signature API Specification into the java.xml.crypto module javadocs and update relevant links in the javadocs. The Java XML Digital Signature API Specification was published as part of JSR 105 and was previously included in the JDK Security Guides but as of JDK 10 had been removed and is no longer maintained. >> >> Also as part of this change, I moved all of the package.html files in this module to the newer package-info.java format. >> >> webrev:http://cr.openjdk.java.net/~mullan/webrevs/8210448/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8212188 >> >> --Sean >> > From will.sargent at gmail.com Tue Oct 16 16:17:40 2018 From: will.sargent at gmail.com (Will Sargent) Date: Tue, 16 Oct 2018 09:17:40 -0700 Subject: Fluent builder API for JCA/JSSE classes In-Reply-To: <5bc4f815.1c69fb81.daa2d.a7d2@mx.google.com> References: <5bc4f815.1c69fb81.daa2d.a7d2@mx.google.com> Message-ID: Hi Bernd, I'm not sure what you mean about exporting the package. I only have it working on JDK 1.8 right now, and I'm not sure about configuring it for multiple JDK versions. All of the code in X509CertificateCreator depends heavily on the x509 implementation import sun.security.x509.AlgorithmId; import sun.security.x509.BasicConstraintsExtension; import sun.security.x509.CertificateAlgorithmId; import sun.security.x509.CertificateExtensions; import sun.security.x509.CertificateSerialNumber; import sun.security.x509.CertificateValidity; import sun.security.x509.CertificateVersion; import sun.security.x509.CertificateX509Key; import sun.security.x509.KeyUsageExtension; import sun.security.x509.X500Name; import sun.security.x509.X509CertImpl; import sun.security.x509.X509CertInfo; But I don't see a way to get around that, and this package seems to be required by OpenJDK. Other than that, the only requirement on a "sun" package is a call out to JCAUtil: https://github.com/tersesystems/securitybuilder/blob/master/src/main/java/com/tersesystems/securitybuilder/EntropySource.java#L4 which can be easily removed. On Mon, Oct 15, 2018 at 1:27 PM Bernd Eckenfels wrote: > Thats very cool! > > > > Maybe this is the right thread to discuss the future of the > sun.security.x509 package. > > > > Currently your implementation will only work if that package is exported. > The Depth of implementation of those classes however would be a nice > Addition to an (optional?) API. > > > > Gruss > > Bernd > > -- > http://bernd.eckenfels.net > > > > *Von: *Will Sargent > *Gesendet: *Montag, 15. Oktober 2018 22:13 > *An: *security-dev at openjdk.java.net > *Betreff: *Fluent builder API for JCA/JSSE classes > > > > Hi all, > > > > I've released a library that adds a fluent builder API library for JCA > factory and generator classes. The primary use of this package is to set up > test X.509 certificates, private keys and trust stores, but it's also > helpful for picking out good defaults and working on a higher level than > the raw JCA classes themselves. It's available at > https://github.com/tersesystems/securitybuilder > > > > Example below of building up an SSLContext from scratch: > > > > public class X509CertificateCreatorTest { > > @Test > > public void testFunctionalStyle() throws Exception { > > FinalStage keyPairCreator = KeyPairCreator.creator().withRSA().withKeySize(2048); > > RSAKeyPair rootKeyPair = keyPairCreator.create(); > > RSAKeyPair intermediateKeyPair = keyPairCreator.create(); > > RSAKeyPair eePair = keyPairCreator.create(); > > > > IssuerStage creator = > > X509CertificateCreator.creator().withSHA256withRSA().withDuration(Duration.ofDays(365)); > > > > String issuer = "CN=letsencrypt.derp,O=Root CA"; > > X509Certificate[] chain = > > creator > > .withRootCA(issuer, rootKeyPair, 2) > > .chain( > > rootKeyPair.getPrivate(), > > rootCreator -> > > rootCreator > > .withPublicKey(intermediateKeyPair.getPublic()) > > .withSubject("OU=intermediate CA") > > .withCertificateAuthorityExtensions(0) > > .chain( > > intermediateKeyPair.getPrivate(), > > intCreator -> > > intCreator > > .withPublicKey(eePair.getPublic()) > > .withSubject("CN=tersesystems.com") > > .withEndEntityExtensions() > > .chain())) > > .create(); > > > > PrivateKeyStore privateKeyStore = > > PrivateKeyStore.create("tersesystems.com", eePair.getPrivate(), chain); > > TrustStore trustStore = TrustStore.create(singletonList(chain[2]), cert -> "letsencrypt.derp"); > > > > try { > > final PKIXCertPathValidatorResult result = CertificateChainValidator.validator() > > .withAnchor(new TrustAnchor(issuer, rootKeyPair.getPublic(), null)) > > .withCertificates(chain) > > .validate(); > > final PublicKey subjectPublicKey = result.getPublicKey(); > > assertThat(subjectPublicKey).isEqualTo(eePair.getPublic()); > > } catch (final CertPathValidatorException cpve) { > > fail("Cannot test exception", cpve); > > } > > > > SSLContext sslContext = > > SSLContextBuilder.builder() > > .withTLS() > > .withKeyManager( > > KeyManagerBuilder.builder() > > .withSunX509() > > .withPrivateKeyStore(privateKeyStore) > > .build()) > > .withTrustManager( > > TrustManagerBuilder.builder() > > .withDefaultAlgorithm() > > .withTrustStore(trustStore) > > .build()) > > .build(); > > assertThat(sslContext).isNotNull(); > > } > > } > > > > Thanks, > Will. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Tue Oct 16 16:24:23 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 16 Oct 2018 09:24:23 -0700 Subject: RFR: 8210989 TLSv1.2 not authenticating using PSS certificates In-Reply-To: <7d2b9936-69af-8cdc-6edf-45f5d5d0d275@oracle.com> References: <7d2b9936-69af-8cdc-6edf-45f5d5d0d275@oracle.com> Message-ID: Yes, that seems like a good idea to do.? I will add some comments explaining the change. --Jamil On 10/15/2018 11:36 AM, Xuelei Fan wrote: > Looks nice to me. > > To help to remember the decision, would you mind add a comment in the > T12CertificateRequestConsumer.consume() block about why we don't use > the CertificateRequest.certificate_types any more. Maybe, some words > like, "Note that the certificate_types field is not used here. The > supported_signature_algorithms field has provide sufficient information". > > Thanks, > Xuelei > > On 10/7/2018 9:33 AM, Jamil Nimeh wrote: >> Hello all, this fixes an issue where for TLSv1.2 connections >> specifically, clients will not authenticate using PSS certs even when >> PSS signature algorithms are asserted in the CertificateRequest >> message.? This brings in a method for client certificate selection >> similar to how we do it for TLS 1.3.? TLS 1.3, 1.1 and 1.0 client >> certificate selection is not affected by this fix. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8210989 >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8210989/webrev.01/ >> >> --Jamil >> From jamil.j.nimeh at oracle.com Tue Oct 16 16:29:24 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 16 Oct 2018 09:29:24 -0700 Subject: RFR: JDK-8211866 TLS 1.3 CertificateRequest message sometimes offers disallowed signature algorithms In-Reply-To: References: <9015f590-8571-f1fb-c5b5-5b0dfa18e33b@oracle.com> Message-ID: Thanks for the review.? Yes, those lines below can be brought up into one line.? I'll get that fixed up. Thanks, --Jamil On 10/15/2018 8:52 PM, Xuelei Fan wrote: > Looks fine to me. > > > Can the following two lines joined into one?? Looks like the length > does not exceed 80 characters. > > ???? int vectorLen = SignatureScheme.sizeInRecord() * > ?????????????????? sigAlgs.size(); > > Thanks, > Xuelei > > On 10/11/2018 10:11 AM, Jamil Nimeh wrote: >> Hello all, >> >> This fixes an issue with the TLS 1.3 CertificateRequest message. In >> cases where the server side can initially support multiple protocol >> versions by the time it issues a CertificateRequest message it >> collects the list of supported signature schemes for the >> signature_algorithms and signature_algorithms_cert extensions using >> all supported protocols as a filtering mechanism. >> >> This change alters the filtering process to use only the negotiated >> protocol, so only those sig algs allowed for that one protocol >> version will be asserted. >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211866/webrev.01/ >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8211866 >> From will.sargent at gmail.com Tue Oct 16 17:36:52 2018 From: will.sargent at gmail.com (Will Sargent) Date: Tue, 16 Oct 2018 10:36:52 -0700 Subject: Fluent builder API for JCA/JSSE classes In-Reply-To: References: <5bc4f815.1c69fb81.daa2d.a7d2@mx.google.com> Message-ID: Also, I wasn't able to figure out how to create CertificateRequest at all. This is kind of a pain when dealing with Vault PKI or Lemur. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Oct 17 00:45:19 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Oct 2018 08:45:19 +0800 Subject: RFR [12]: 8210448: Copy Java XML Digital Signature API Specification into java.xml.crypto javadocs In-Reply-To: References: <28606AC1-90FE-404E-A3BA-E2629D3ED7D4@oracle.com> Message-ID: <64320E07-4FB7-432A-9CEA-6AA5E9FAD232@oracle.com> > On Oct 16, 2018, at 11:53 PM, Sean Mullan wrote: > > Can you also review the CSR and add your name as reviewer? Added. Do you want to add a link to 'the normative sections of the "Java XML Digital Signature API Specification"' in the CSR? Thanks Max From sha.jiang at oracle.com Wed Oct 17 07:03:02 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 17 Oct 2018 15:03:02 +0800 Subject: RFR[12] JDK-8212562: To remove lib/security from test/jdk/TEST.groups Message-ID: Hi, test/jdk/lib/security doesn't exist, so this directory could be removed from jdk_security3 diff -r f54dcfc5a5f8 test/jdk/TEST.groups --- a/test/jdk/TEST.groups??? Fri Oct 05 15:12:37 2018 -0700 +++ b/test/jdk/TEST.groups??? Wed Oct 17 15:01:36 2018 +0800 @@ -218,8 +218,7 @@ ???? -sun/security/krb5 \ ???? -sun/security/jgss \ ???? javax/net \ -??? com/sun/net/ssl \ -??? lib/security +??? com/sun/net/ssl ?jdk_security4 = \ ???? com/sun/security/jgss \ Best regards, John Jiang From sean.coffey at oracle.com Wed Oct 17 10:25:57 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 17 Oct 2018 11:25:57 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> Message-ID: <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> I'd like to re-boot this review. I've been working with Erik off thread who's been helping with code and test design. Some of the main changes worthy of highlighting : * Separate out the tests for JFR and Logger events * Rename some events * Normalize the data view for X509ValidationEvent (old event name : CertChainEvent) * Introduce CertificateSerialNumber type to make use of the @Relational JFR annotation. * Keep calls for JFR event operations local to call site to optimize jvm compilation webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v6/webrev/ This code is dependent on the JDK-8203629 enhancement being integrated. Regards, Sean. On 10/07/18 13:50, Se?n Coffey wrote: > Erik, > > After some trial edits, I'm not so sure if moving the event & logger > commit code into the class where it's used works too well after all. > > In the code you suggested, there's an assumption that calls such as > EventHelper.certificateChain(..) are low cost. While that might be the > case here, it's something we can't always assume. It's called once for > the JFR operation and once for the Logger operation. That pattern > multiplies itself further in other Events. i.e. set up and assign the > variables for a JFR event without knowing whether they'll be needed > again for the Logger call. We could work around it by setting up some > local variables and re-using them in the Logger code but then, we're > back to where we were. The current EventHelper design eliminates this > problem and also helps to abstract the recording/logging functionality > away from the functionality of the class itself. > > It also becomes a problem where we record events in multiple different > classes (e.g. SecurityPropertyEvent). While we could leave the code in > EventHelper for this case, we then have a mixed design pattern. > > Are you ok with leaving as is for now? A future wish might be one > where JFR would handle Logger via its own framework/API in a future > JDK release. > > I've removed the variable names using underscore. Also optimized some > variable assignments in X509Impl.commitEvent(..) > > http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ > > regards, > Sean. > > On 09/07/2018 18:01, Se?n Coffey wrote: >> Erik, >> >> Thanks for reviewing. Comments inline.. >> >> On 09/07/18 17:21, Erik Gahlin wrote: >>> Thanks Sean. >>> >>> Some feedback on the code in the security libraries. >>> >>> - We should use camel case naming convention for variables (not >>> underscore). >> Sure. I see two offending variable names which I'll fix up. >>> >>> - Looking at sun/security/ssl/Finished.java, >>> >>> I wonder if it wouldn't be less code and more easy to read, if we >>> would commit the event in a local private function and then use the >>> EventHelper class for common functionality. >> I'm fine with your suggested approach. I figured that tucking the >> recording/logging logic away in a helper class also had benefits but >> I'll re-factor to your suggested style unless I hear objections. >> >> regards, >> Sean. >> > From sean.coffey at oracle.com Wed Oct 17 11:34:37 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 17 Oct 2018 12:34:37 +0100 Subject: RFR[12] JDK-8212562: To remove lib/security from test/jdk/TEST.groups In-Reply-To: References: Message-ID: <7726c0ee-cb45-6d50-3ad1-ed3db5adfd0f@oracle.com> Looks fine to me. Regards, Sean. On 17/10/18 08:03, sha.jiang at oracle.com wrote: > Hi, > test/jdk/lib/security doesn't exist, so this directory could be > removed from jdk_security3 > > diff -r f54dcfc5a5f8 test/jdk/TEST.groups > --- a/test/jdk/TEST.groups Fri Oct 05 15:12:37 2018 -0700 > +++ b/test/jdk/TEST.groups Wed Oct 17 15:01:36 2018 +0800 > @@ -218,8 +218,7 @@ > -sun/security/krb5 \ > -sun/security/jgss \ > javax/net \ > - com/sun/net/ssl \ > - lib/security > + com/sun/net/ssl > > jdk_security4 = \ > com/sun/security/jgss \ > > Best regards, > John Jiang > From weijun.wang at oracle.com Wed Oct 17 13:22:42 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Oct 2018 21:22:42 +0800 Subject: Fluent builder API for JCA/JSSE classes In-Reply-To: References: <5bc4f815.1c69fb81.daa2d.a7d2@mx.google.com> Message-ID: You can create a PKCS10 file, we have sun.security.pkcs.PKCS10. > On Oct 17, 2018, at 1:36 AM, Will Sargent wrote: > > Also, I wasn't able to figure out how to create CertificateRequest at all. This is kind of a pain when dealing with Vault PKI or Lemur. From ivan.gerasimov at oracle.com Wed Oct 17 18:03:57 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 17 Oct 2018 11:03:57 -0700 Subject: RFR 8201355 : Avoid native memory allocation in sun.security.mscapi.PRNG.generateSeed Message-ID: <1ffccc2f-17d2-0756-274b-03edd834dc17@oracle.com> Hello! In the function Java_sun_security_mscapi_PRNG_generateSeed() a native memory is allocated, and then its content is copied into a freshly allocated Java array. The native memory allocation can be avoided, which also makes the code shorter. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8201355 WEBREV: http://cr.openjdk.java.net/~igerasim/8201355/00/webrev/ -- With kind regards, Ivan Gerasimov From adam.petcher at oracle.com Wed Oct 17 20:45:34 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 17 Oct 2018 16:45:34 -0400 Subject: RFR 8205476: KeyAgreement#generateSecret is not reset for ECDH based algorithm Message-ID: <71459e08-5d94-6d25-cd7f-c20b83795acf@oracle.com> Webrev: http://cr.openjdk.java.net/~apetcher/8205476/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8205476 CSR: https://bugs.openjdk.java.net/browse/JDK-8212051 Please review the following change for a conformance bug in the ECDH service. The KeyAgreement is supposed to reset itself after the call to generateSecret, but it is not doing that. I'm also clarifying the spec, and this change has the new wording. The CSR was just submitted, and it will also need to be approved before this code change is pushed. From mstjohns at comcast.net Thu Oct 18 00:40:41 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 17 Oct 2018 20:40:41 -0400 Subject: RFR 8205476: KeyAgreement#generateSecret is not reset for ECDH based algorithm In-Reply-To: <71459e08-5d94-6d25-cd7f-c20b83795acf@oracle.com> References: <71459e08-5d94-6d25-cd7f-c20b83795acf@oracle.com> Message-ID: <98a1d6c8-7a50-65aa-3de5-2e42495e8d27@comcast.net> On 10/17/2018 4:45 PM, Adam Petcher wrote: > Webrev: http://cr.openjdk.java.net/~apetcher/8205476/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8205476 > CSR: https://bugs.openjdk.java.net/browse/JDK-8212051 > > Please review the following change for a conformance bug in the ECDH > service. The KeyAgreement is supposed to reset itself after the call > to generateSecret, but it is not doing that. I'm also clarifying the > spec, and this change has the new wording. The CSR was just submitted, > and it will also need to be approved before this code change is pushed. > In ECDHKeyAgreement.java, suggest instead using a try-catch-finally construct and place the nulling of the publicValue in the final block rather than adding the two additional steps of assigning the result to a temp array and nulling publicValue before returning the result.? AFAICT, there is no instance on which you would not erase the publicValue even on error. Mike From weijun.wang at oracle.com Thu Oct 18 01:01:28 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Oct 2018 09:01:28 +0800 Subject: RFR 8201355 : Avoid native memory allocation in sun.security.mscapi.PRNG.generateSeed In-Reply-To: <1ffccc2f-17d2-0756-274b-03edd834dc17@oracle.com> References: <1ffccc2f-17d2-0756-274b-03edd834dc17@oracle.com> Message-ID: <1233C93B-0F57-41DA-9C9A-0BBCF0CB3551@oracle.com> Looks fine to me. Thanks Max > On Oct 18, 2018, at 2:03 AM, Ivan Gerasimov wrote: > > Hello! > > In the function Java_sun_security_mscapi_PRNG_generateSeed() a native memory is allocated, and then its content is copied into a freshly allocated Java array. The native memory allocation can be avoided, which also makes the code shorter. > > Would you please help review the fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8201355 > WEBREV: http://cr.openjdk.java.net/~igerasim/8201355/00/webrev/ > > -- > With kind regards, > Ivan Gerasimov > From weijun.wang at oracle.com Thu Oct 18 02:34:21 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Oct 2018 10:34:21 +0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option Message-ID: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> Please review the code change and CSR for JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 at webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. A Mach5 job on tier1 and tier2 running now. Thanks Max From weijun.wang at oracle.com Thu Oct 18 04:34:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Oct 2018 12:34:40 +0800 Subject: RFR 8212003: Obsoleting the default keytool -keyalg option In-Reply-To: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> References: <3948C5B9-D707-48A4-A715-312067C063C8@oracle.com> Message-ID: > On Oct 18, 2018, at 10:34 AM, Weijun Wang wrote: > > Please review the code change and CSR for > > JBS: https://bugs.openjdk.java.net/browse/JDK-8212003 > > at > > webrev: http://cr.openjdk.java.net/~weijun/8212003/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8212111 > > When -keyalg is not provided for -genkeypair or -genseckey, keytool will print out a warning. We plan to make this an error in a future release. > > A new regression test ObsoleteKeyalg.java added. "-keyalg DSA" or "-keyalg DES" added to other tests. > > A Mach5 job on tier1 and tier2 running now. Test complete. Only one test failed but it's unrelated and a known failure. BTW, I also run a Mach5 job without the test change. Two related tests failed (WeakAlg.java and KeyToolTest.java), both because seeing unexpected "Warning" text in the output. Maybe the tests should have checked a more precise "Warning: XYZ". Thanks Max > > Thanks > Max > From sean.mullan at oracle.com Thu Oct 18 15:04:13 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 18 Oct 2018 11:04:13 -0400 Subject: RFR [12]: 8195793: Remove GTE CyberTrust Global Root Message-ID: <36e606f4-912e-d09c-e5d6-8e87f276760f@oracle.com> Please review this change to remove the GTE CyberTrust Global Root from the cacerts keystore. This root is expired and all certificates that chain back to this root have expired. Note that retaining roots past their expiration date may make sense in some cases. For example, if we removed a root it could break signed code that had been previously timestamped. It may make sense to allow for a transition period for those apps to be signed and re-deployed using new certificates. However, this is much less of a risk going forward. Applets have been deprecated since JDK 9 and WebStart apps are not supported as of (Oracle) JDK 11. These were the primary use cases for signed and timestamped code that I am aware of. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8195793/webrev.00/ Thanks, Sean From mbalao at redhat.com Thu Oct 18 16:26:24 2018 From: mbalao at redhat.com (Martin Balao) Date: Thu, 18 Oct 2018 18:26:24 +0200 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: <566016d0-00ba-e938-693f-56948b9013da@oracle.com> References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> <566016d0-00ba-e938-693f-56948b9013da@oracle.com> Message-ID: Hi Valerie, Thanks for your feedback. I suggest to keep only one hierarchy of webrevs, so I'll continue in Webrev.12 using your Webrev.02 as a base. In general, I'm happy with your P11Key refactorings and with keeping the previous reference inc/dec scheme on P11key clients side. I'll go file-by-file reviewing changes between your Webrev.02 and my Webrev.11: * P11Cipher.java * Ok * I used to set "initialized" variable to false in all "initialize" function error flows but it's not necessary as it shouldn't be true when entering. * P11DHKeyFactory.java * Copyright updated * P11DSAKeyFactory.java * Ok * P11Digest.java * Ok * P11ECDHKeyAgreement.java * Copyright updated * P11ECKeyFactory.java * Copyright updated * P11Key.java * Why is P11Key now public? * I have some concerns regarding how you calculate "extractKeyInfo" value: * Why is !sensitive a requirement? * We can extract them wrapped, and the code already handles that. * !tokenObject should be a requirement * I know it's checked in NativeKeyHolder constructor but it could be part of extractKeyInfo too for clarity * Why is !type.equals(SECRET) a requirement? * It's correct that we can not destroy the key after creation (under the assumption that will be used soon), and that this should be a performance benefit for most cases. My approach here was more memory conservative, but it should be fine anyways. I'm okay with this change. * In case of createNativeKey failure, I think we should decrement the previously-incremented reference counter * Why do we need refCount to be of AtomicInteger type? All the modifications to this instance variable are done inside instance synchronized methods (getKeyID and releaseKeyID) * The benefit of the previous incNativeKeyRef/decNativeKeyRef methods is that they don't pay a sync cost for all cases in which the feature is disabled. I believe we can keep that performance improvement here too. * nativeKeyInfo variable is written at creation time and all other usages are read-only, so we can have multiple readers at the same time and synchronize on it if not null (instead of synchronizing the whole method). What do you think? * P11KeyAgreement.java * Ok * P11KeyGenerator.java * Ok * P11KeyPairGenerator.java * Ok * P11KeyStore.java * Copyright updated * The reason why a call to "makeNativeKeyPersistent" was made in P11KeyStore.updateP11Pkey method was because "P11Key key" could have been extracted and the change not persisted in the keystore. This call was disabling the feature for such keys. However, we now decided -for a good reason- that keys from keystores (token objects) will not be extracted. Thus, this call is no longer needed. I'm okay with this change. * "long newKeyID" variable not used. Fixed on some other files too. * P11Mac.java * Copyright updated * Split ensureInitialized and initialize functions again for the reasons we've previously discussed. * P11RSACipher.java * Ok * P11RSAKeyFactory.java * Ok * P11SecretKeyFactory.java * Copyright updated * The inc/dec pattern was broken in case of "token.p11.C_CopyObject" failure. Fixed. * P11Signature.java * Ok * P11TlsKeyMaterialGenerator.java * Removed dead & debug code * P11TlsMasterSecretGenerator.java * Ok * P11TlsPrfGenerator.java * Removed dead & debug code * P11TlsRsaPremasterSecretGenerator.java * Ok * PKCS11.java * Copyright updated * p11_keymgmt.c * Removed dead code * I've seen that you replaced some variable assignments with memcpy and memset calls because of compiler errors. I wonder what these errors are, as we should be able to cast and do assignments. * pkcs11t.h * Ok * pkcs11wrapper.h * Ok In addition, I removed trimming white spaces in several files. I agree with having a property to completely disable this feature. I've not seen, so far, unfixed cases in which extraction succeeds but re-creation fails. Webrev.12 is based on your Webrev.02, with modifications previously described: * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.12/ * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.12.zip NOTE: Webrev.12 does not address neither the P11Key.java issues above nor the property to completely disable this feature. Those 2 things are the only pending on my side for now. Kind regards, Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From xxinliu at amazon.com Thu Oct 18 22:34:14 2018 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 18 Oct 2018 22:34:14 +0000 Subject: Upgrade to RSAKeyGenParameterSpec.F4 for RSA Keypair generation test? Message-ID: <208E302C-C247-40EC-B18D-4FC0168B82A0@amazon.com> Hi, Security developers, We can?t pass the following test on our platform for OpenJDK8. Test: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4a782529d712/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java#l106 Error Message: Generating 512 bit keypair... STDERR: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ARGUMENTS_BAD at sun.security.pkcs11.P11KeyPairGenerator.generateKeyPair(P11KeyPairGenerator.java:424) at java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:697) at TestKeyPairGenerator.main(TestKeyPairGenerator.java:119) at PKCS11Test.premain(PKCS11Test.java:88) at PKCS11Test.testNSS(PKCS11Test.java:403) at PKCS11Test.main(PKCS11Test.java:98) at TestKeyPairGenerator.main(TestKeyPairGenerator.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.lang.Thread.run(Thread.java:748) Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ARGUMENTS_BAD at sun.security.pkcs11.wrapper.PKCS11.C_GenerateKeyPair(Native Method) at sun.security.pkcs11.P11KeyPairGenerator.generateKeyPair(P11KeyPairGenerator.java:416) ... 12 more We believe the problem is caused by the NSS standard[1]. There?s a bug related to Solaris[2]. Our platform also rejects this test for the same reason. Is it okay backport this patch to jdk8u? I think it?s backward-compatible. Here is difference between FIPS 186-2 and FIPS 186-4 RSA: restrict n size to 1024 2048 3072, restrict e to 2^16+1 to 2^256?1, and specify RSA private key generation in detail with several options. This prohibits one traditionally popular e namely 3; F4 (65537) is allowed and IME more popular anyway.[1] References: 1. https://crypto.stackexchange.com/questions/35388/what-is-the-major-difference-between-fips-186-2-and-fips-186-4 2. https://bugs.openjdk.java.net/browse/JDK-8129560 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Thu Oct 18 23:36:21 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 18 Oct 2018 16:36:21 -0700 Subject: RFR [12]: 8195793: Remove GTE CyberTrust Global Root In-Reply-To: <36e606f4-912e-d09c-e5d6-8e87f276760f@oracle.com> References: <36e606f4-912e-d09c-e5d6-8e87f276760f@oracle.com> Message-ID: <2fed4e3f-b7d2-5b88-8b41-3fb713c20990@oracle.com> Looks good to me! Thanks, Rajan On 10/18/18 8:04 AM, Sean Mullan wrote: > Please review this change to remove the GTE CyberTrust Global Root > from the cacerts keystore. This root is expired and all certificates > that chain back to this root have expired. > > Note that retaining roots past their expiration date may make sense in > some cases. For example, if we removed a root it could break signed > code that had been previously timestamped. It may make sense to allow > for a transition period for those apps to be signed and re-deployed > using new certificates. > > However, this is much less of a risk going forward. Applets have been > deprecated since JDK 9 and WebStart apps are not supported as of > (Oracle) JDK 11. These were the primary use cases for signed and > timestamped code that I am aware of. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8195793/webrev.00/ > > Thanks, > Sean From sean.coffey at oracle.com Fri Oct 19 15:51:39 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 19 Oct 2018 16:51:39 +0100 Subject: Upgrade to RSAKeyGenParameterSpec.F4 for RSA Keypair generation test? In-Reply-To: <208E302C-C247-40EC-B18D-4FC0168B82A0@amazon.com> References: <208E302C-C247-40EC-B18D-4FC0168B82A0@amazon.com> Message-ID: Hi Xin, looks like a reasonable backport candidate for jdk8u. I guess the changeset will apply cleanly once you correct the paths. You should have no problem with a push request on jdk8u-dev : http://openjdk.java.net/projects/jdk8u/approval-template.html Regards, Sean. On 18/10/18 23:34, Liu, Xin wrote: > > Hi, Security developers, > > We can?t pass the following test on our platform for OpenJDK8. > > Test:http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/4a782529d712/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java#l106 > > Error Message: > > Generating 512 bit keypair... > > STDERR: > > java.security.ProviderException: > sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ARGUMENTS_BAD > > at > sun.security.pkcs11.P11KeyPairGenerator.generateKeyPair(P11KeyPairGenerator.java:424) > > at > java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:697) > > at TestKeyPairGenerator.main(TestKeyPairGenerator.java:119) > > at PKCS11Test.premain(PKCS11Test.java:88) > > at PKCS11Test.testNSS(PKCS11Test.java:403) > > at PKCS11Test.main(PKCS11Test.java:98) > > at TestKeyPairGenerator.main(TestKeyPairGenerator.java:97) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:498) > > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > > at java.lang.Thread.run(Thread.java:748) > > Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ARGUMENTS_BAD > > at sun.security.pkcs11.wrapper.PKCS11.C_GenerateKeyPair(Native Method) > > at > sun.security.pkcs11.P11KeyPairGenerator.generateKeyPair(P11KeyPairGenerator.java:416) > > ... 12 more > > We believe the problem is caused by the NSS standard[1]. > > There?s a bug related to Solaris[2]. Our platform also rejects this > test for the same reason. Is it okay backport this patch to jdk8u? > I think it?s backward-compatible. > > > Here is difference between FIPS 186-2 and FIPS 186-4 > > RSA: restrict n size to 1024 2048 3072, restrict e to 2^16+1 to > 2^256?1, and specify RSA private key generation in detail with several > options. *This prohibits one traditionally popular e namely 3;* F4 > (65537) is allowed and IME more popular anyway.[1] > > References: > > 1.https://crypto.stackexchange.com/questions/35388/what-is-the-major-difference-between-fips-186-2-and-fips-186-4 > > 2. https://bugs.openjdk.java.net/browse/JDK-8129560 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Fri Oct 19 15:55:48 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 19 Oct 2018 16:55:48 +0100 Subject: RFR [12]: 8195793: Remove GTE CyberTrust Global Root In-Reply-To: <36e606f4-912e-d09c-e5d6-8e87f276760f@oracle.com> References: <36e606f4-912e-d09c-e5d6-8e87f276760f@oracle.com> Message-ID: <65adba55-dd53-605d-af38-e2290e8331bc@oracle.com> Looks fine. Regards, Sean. On 18/10/18 16:04, Sean Mullan wrote: > Please review this change to remove the GTE CyberTrust Global Root > from the cacerts keystore. This root is expired and all certificates > that chain back to this root have expired. > > Note that retaining roots past their expiration date may make sense in > some cases. For example, if we removed a root it could break signed > code that had been previously timestamped. It may make sense to allow > for a transition period for those apps to be signed and re-deployed > using new certificates. > > However, this is much less of a risk going forward. Applets have been > deprecated since JDK 9 and WebStart apps are not supported as of > (Oracle) JDK 11. These were the primary use cases for signed and > timestamped code that I am aware of. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8195793/webrev.00/ > > Thanks, > Sean From jamil.j.nimeh at oracle.com Fri Oct 19 18:04:28 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 19 Oct 2018 11:04:28 -0700 Subject: Update: RFR JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume In-Reply-To: <422d92e9-e7fb-f0c7-2a35-27caf144359a@oracle.com> References: <422d92e9-e7fb-f0c7-2a35-27caf144359a@oracle.com> Message-ID: Hello everyone, I've added a test to go along with the bugfix.? No changes to the actual fix itself. Updated webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211806/webrev.02/ Thanks, --Jamil On 10/12/18 9:39 PM, Jamil Nimeh wrote: > Hello all, > > This addresses an issue where the client hello in a resumed TLS 1.3 > session lacks the server_name client hello extension.? This can cause > servers who use this extension field to direct traffic to websites to > present other certificate chains for other websites than the one the > client actually desires (and specified in the original client hello > where the extension is present). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211806 > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211806/ > > Happy Friday! > > --Jamil > From xuelei.fan at oracle.com Fri Oct 19 18:18:56 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 19 Oct 2018 11:18:56 -0700 Subject: Update: RFR JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume In-Reply-To: References: <422d92e9-e7fb-f0c7-2a35-27caf144359a@oracle.com> Message-ID: Looks fine to me. Thanks, Xuelei On 10/19/2018 11:04 AM, Jamil Nimeh wrote: > Hello everyone, > > I've added a test to go along with the bugfix.? No changes to the actual > fix itself. > > Updated webrev: > http://cr.openjdk.java.net/~jnimeh/reviews/8211806/webrev.02/ > > Thanks, > > --Jamil > > On 10/12/18 9:39 PM, Jamil Nimeh wrote: >> Hello all, >> >> This addresses an issue where the client hello in a resumed TLS 1.3 >> session lacks the server_name client hello extension.? This can cause >> servers who use this extension field to direct traffic to websites to >> present other certificate chains for other websites than the one the >> client actually desires (and specified in the original client hello >> where the extension is present). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8211806 >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211806/ >> >> Happy Friday! >> >> --Jamil >> From sean.mullan at oracle.com Fri Oct 19 19:23:49 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 19 Oct 2018 15:23:49 -0400 Subject: RFR 8205476: KeyAgreement#generateSecret is not reset for ECDH based algorithm In-Reply-To: <71459e08-5d94-6d25-cd7f-c20b83795acf@oracle.com> References: <71459e08-5d94-6d25-cd7f-c20b83795acf@oracle.com> Message-ID: <7978cd44-4900-02ae-5ff3-122552d42bb6@oracle.com> The copyrights should be updated. Otherwise, looks good. --Sean On 10/17/18 4:45 PM, Adam Petcher wrote: > Webrev: http://cr.openjdk.java.net/~apetcher/8205476/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8205476 > CSR: https://bugs.openjdk.java.net/browse/JDK-8212051 > > Please review the following change for a conformance bug in the ECDH > service. The KeyAgreement is supposed to reset itself after the call to > generateSecret, but it is not doing that. I'm also clarifying the spec, > and this change has the new wording. The CSR was just submitted, and it > will also need to be approved before this code change is pushed. > From bradford.wetmore at oracle.com Sat Oct 20 00:57:04 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 19 Oct 2018 17:57:04 -0700 Subject: Update: RFR JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume In-Reply-To: References: <422d92e9-e7fb-f0c7-2a35-27caf144359a@oracle.com> Message-ID: Test: 79: arf.yak.foo? Are you sure you don't want to use the new TLD .wtf here? :) 97: You could request TLSv1.3 here, but what you have is fine since you're hardcoding just the TLSv1.3 protocol later. In other words, no real comments. Brad On 10/19/2018 11:18 AM, Xuelei Fan wrote: > Looks fine to me. > > Thanks, > Xuelei > > On 10/19/2018 11:04 AM, Jamil Nimeh wrote: >> Hello everyone, >> >> I've added a test to go along with the bugfix.? No changes to the >> actual fix itself. >> >> Updated webrev: >> http://cr.openjdk.java.net/~jnimeh/reviews/8211806/webrev.02/ >> >> Thanks, >> >> --Jamil >> >> On 10/12/18 9:39 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This addresses an issue where the client hello in a resumed TLS 1.3 >>> session lacks the server_name client hello extension.? This can cause >>> servers who use this extension field to direct traffic to websites to >>> present other certificate chains for other websites than the one the >>> client actually desires (and specified in the original client hello >>> where the extension is present). >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8211806 >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8211806/ >>> >>> Happy Friday! >>> >>> --Jamil >>> From olegk at apache.org Sun Oct 21 20:31:39 2018 From: olegk at apache.org (Oleg Kalnichevski) Date: Sun, 21 Oct 2018 22:31:39 +0200 Subject: SSLSession#getPeerCertificates and resumed TLSv1.3 sessions Message-ID: <25e58e01f8d522bc5863e1cab69b821688408bfc.camel@apache.org> Good time of the day OpenJDK 11 TLS v1.3 implementation at present breaks hostname verification code in all versions of Apache HttpClient and I am trying to figure the best way to remedy the situation. Resumed TLS v1.3 sessions do not appear to carry a server certificate chain, which, is as far as I understand, is to be expected. In case of resumed TLSv1.3 sessions an attempt to get the servers certificates with SSLSession#getPeerCertificates causes "peer not authenticated" SSLPeerUnverifiedException. The trouble is that I fail to see any way to find out whether or not an TLS v1.3 session has been negotiated using the complete TLS handshake or resumed. The only solution I was able to have found so far is to catch SSLPeerUnverifiedException, see if the TLS protocol is v1.3 and presume this is because the session has been resumed [1]. This naturally looks and feels very dodgy. Please advise how one should tell if TLS v1.3 session has been resumed using SSLSession interface or what would be the right way to perform hostname verification or any custom certificate validity checks with TLS v1.3. Thank you in advance Oleg Kalnichevski [1] https://github.com/ok2c/httpclient/commit/6ca28be047a7a461c7814ee7e0f3e083158ee349 From jai.forums2013 at gmail.com Mon Oct 22 05:46:04 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 22 Oct 2018 11:16:04 +0530 Subject: [PATCH] Typo in SSL log message related to inactive/disabled signature scheme Message-ID: <3431d5ef-62c7-19ad-2498-53871db13623@gmail.com> I noticed a typo in one of the SSL log messages, while looking into a log file generated during a SSL handshake. Here's a trivial patch which fixes the typo. I'm not a committer so will need help from someone to sponsor this patch. -Jaikiran -------------- next part -------------- # HG changeset patch # User Jaikiran Pai # Date 1540186879 -19800 # Mon Oct 22 11:11:19 2018 +0530 # Node ID 80370ecda2a514d2ce985263e800445bda4bcfb4 # Parent cf3fafc740bb6df3f7f044e4ccc4976499cd24b3 Fix typo in SSL log message for disabled/inactive signature schemes diff --git a/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java b/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java --- a/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java +++ b/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java @@ -356,12 +356,12 @@ } else if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake,verbose")) { SSLLogger.finest( - "Ignore disabled signature sheme: " + ss.name); + "Ignore disabled signature scheme: " + ss.name); } } else if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake,verbose")) { SSLLogger.finest( - "Ignore inactive signature sheme: " + ss.name); + "Ignore inactive signature scheme: " + ss.name); } } From sean.coffey at oracle.com Mon Oct 22 09:31:35 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 22 Oct 2018 10:31:35 +0100 Subject: [PATCH] Typo in SSL log message related to inactive/disabled signature scheme In-Reply-To: <3431d5ef-62c7-19ad-2498-53871db13623@gmail.com> References: <3431d5ef-62c7-19ad-2498-53871db13623@gmail.com> Message-ID: Looks fine. I'll push this for you. Regards, Sean. On 22/10/18 06:46, Jaikiran Pai wrote: > I noticed a typo in one of the SSL log messages, while looking into a > log file generated during a SSL handshake. Here's a trivial patch which > fixes the typo. I'm not a committer so will need help from someone to > sponsor this patch. > > -Jaikiran > From jai.forums2013 at gmail.com Mon Oct 22 12:47:11 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 22 Oct 2018 18:17:11 +0530 Subject: [PATCH] Typo in SSL log message related to inactive/disabled signature scheme In-Reply-To: References: <3431d5ef-62c7-19ad-2498-53871db13623@gmail.com> Message-ID: Thank you Sean. -Jaikiran On 22/10/18 3:01 PM, Se?n Coffey wrote: > Looks fine. I'll push this for you. > > Regards, > Sean. > > On 22/10/18 06:46, Jaikiran Pai wrote: >> I noticed a typo in one of the SSL log messages, while looking into a >> log file generated during a SSL handshake. Here's a trivial patch which >> fixes the typo. I'm not a committer so will need help from someone to >> sponsor this patch. >> >> -Jaikiran >> > From sean.mullan at oracle.com Mon Oct 22 15:30:05 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 22 Oct 2018 11:30:05 -0400 Subject: RFR 8212216: JGSS: Fix leak in exception cases in getJavaOID() In-Reply-To: <5FDE8642-773E-4810-92EE-CDB54DAA7D6E@oracle.com> References: <5FDE8642-773E-4810-92EE-CDB54DAA7D6E@oracle.com> Message-ID: <59071588-06eb-099d-5167-bc8ac9f1e5e5@oracle.com> Looks fine to me. It is unusual to have two noreg labels on a bug. Is that acceptable? I would probably choose one or the other. noreg-hard seems more appropriate to me. --Sean On 10/15/18 9:34 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8212216/webrev.00/ > > This bug is reported and fixed by Nico Williams . > > No regression test, memory leak. > > Thanks > Max > From weijun.wang at oracle.com Tue Oct 23 04:28:19 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 23 Oct 2018 12:28:19 +0800 Subject: RFR 8212216: JGSS: Fix leak in exception cases in getJavaOID() In-Reply-To: <59071588-06eb-099d-5167-bc8ac9f1e5e5@oracle.com> References: <5FDE8642-773E-4810-92EE-CDB54DAA7D6E@oracle.com> <59071588-06eb-099d-5167-bc8ac9f1e5e5@oracle.com> Message-ID: <51A4ACE9-3F58-4B53-9790-A47ED4C66E0A@oracle.com> Maybe noreg-trivial is for lazy people. I'll remove it and add a comment. Thanks Max > On Oct 22, 2018, at 11:30 PM, Sean Mullan wrote: > > Looks fine to me. It is unusual to have two noreg labels on a bug. Is that acceptable? I would probably choose one or the other. noreg-hard seems more appropriate to me. > > --Sean > > On 10/15/18 9:34 PM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8212216/webrev.00/ >> This bug is reported and fixed by Nico Williams . >> No regression test, memory leak. >> Thanks >> Max From lj.slo at hotmail.com Tue Oct 23 17:50:44 2018 From: lj.slo at hotmail.com (John Newman) Date: Tue, 23 Oct 2018 17:50:44 +0000 Subject: Hashing in Java and Java Cryptography Architecture (JCA) design Message-ID: This seems to me overly complicated for a simple task of instantiating a MessageDigest object: MessageDigest md = null; try { md = MessageDigest.getInstance("SHA-1"); } catch (NoSuchAlgorithmException nsae) {} Couldn't MessageDigest simply be an *interface* and the SHA funcionality a special *implementation*, like so: MessageDigest md = new ShaMessageDigest(); ? But instead we have these factory methods (accross all of the JCA core classes) which throw exceptions, polluting the code. Is the Provider abstraction really needed? The only real benefit I see is neater class names. In fact - couldn't we get rid of the entire Java Cryptography Architecture (JCA) as it is and redesign it to be more object oriented? For example, couldn't this: byte [][] args = //... MessageDigest md = //.. md.update(args[0]) md.update(args[1]); md.digest(); become this: byte [][] args = //... MessageDigest md = //.. md.update(args[0]).update(args[1]).digest(); or maybe even this: MessageDigest md = //.. byte [][] args = //... new IntermediateDigest( md, args[0], args[1] ).bytes() where IntermediateDigest itself could be an argument to MessageDigest's update() method, making things like H(H(x), y) look much more compact and readable? --Janez From openjdk at suche.org Tue Oct 23 18:24:33 2018 From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Tue, 23 Oct 2018 20:24:33 +0200 Subject: Hashing in Java and Java Cryptography Architecture (JCA) design In-Reply-To: References: Message-ID: <7c1a719c-522e-47c1-6ee4-7149fbf1c5af@suche.org> Hi, even if it looks complicated for you the idea is that your code is not hard wired to MD5 or SHA1 but in ideal case it is configured. Than you do not know in advance if the selected digest is available. On the other hand no one say that you can create your own helper/tools class. The idea is that you are not fixed to one algo but what if you say "MD4" or "POLY1305" only some algorithm where available at coding time thy can be removed later (maybe even via policy) or newly been added. For this there is the NoSuchAlgorithmException to show the developer there can be some error. RuntimeException would be ignored and may crash the whole program or task. Gru? Thomas class DIGEST { static byte[] SHA1(byte[]... args) { ... } } then you can simply call DIGEST.SHA1(a,b,c) On 23.10.2018 19:50:44, John Newman wrote: > This seems to me overly complicated for a simple task of > instantiating a MessageDigest object: > > MessageDigest md = null; > try { > md = MessageDigest.getInstance("SHA-1"); > } catch (NoSuchAlgorithmException nsae) {} > > Couldn't MessageDigest simply be an *interface* and > the SHA funcionality a special *implementation*, like so: > > MessageDigest md = new ShaMessageDigest(); > > ? > > But instead we have these factory methods (accross all of the JCA > core classes) which throw exceptions, polluting the code. Is the > Provider abstraction really needed? The only real benefit I see is > neater class names. > > In fact - couldn't we get rid of the entire Java Cryptography Architecture (JCA) > as it is and redesign it to be more object oriented? For example, couldn't this: > > byte [][] args = //... > MessageDigest md = //.. > md.update(args[0]) > md.update(args[1]); > md.digest(); > > become this: > > byte [][] args = //... > MessageDigest md = //.. > md.update(args[0]).update(args[1]).digest(); > > or maybe even this: > > MessageDigest md = //.. > byte [][] args = //... > new IntermediateDigest( > md, > args[0], > args[1] > ).bytes() > > where IntermediateDigest itself could be an argument to MessageDigest's update() > method, making things like H(H(x), y) look much more compact and readable? > > > --Janez From sean.mullan at oracle.com Tue Oct 23 19:38:29 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 23 Oct 2018 15:38:29 -0400 Subject: RFR [12]: 8211883: Disable anon and NULL cipher suites Message-ID: Please review this change to add the TLS anonymous and NULL cipher suites to the "jdk.tls.disabledAlgorithms" security property. These suites are used rarely and have security weaknesses. Anonymous suites are vulnerable to man-in-the-middle attacks. NULL suites do not provide confidentiality. RFC 7525 [1] says: "Implementations MUST NOT negotiate the cipher suites with NULL encryption." Also, TLS 1.3 has removed them. These suites are not enabled by default, so an application has to explicitly enable them using an API or the "jdk.tls.client.cipherSuites" or "jdk.tls.server.cipherSuites" system properties. However, adding them to the "jdk.tls.disabledAlgorithms" security property adds an extra level of protection and additional configuration change in order to use them. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8211883/webrev.00/ --Sean [1] https://tools.ietf.org/html/rfc7525 From jamil.j.nimeh at oracle.com Tue Oct 23 20:15:20 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 23 Oct 2018 13:15:20 -0700 Subject: RFR [12]: 8211883: Disable anon and NULL cipher suites In-Reply-To: References: Message-ID: <1bcb3761-7ef8-87cf-6a86-c854d8b39feb@oracle.com> Looks good to me. --Jamil On 10/23/18 12:38 PM, Sean Mullan wrote: > Please review this change to add the TLS anonymous and NULL cipher > suites to the "jdk.tls.disabledAlgorithms" security property. > > These suites are used rarely and have security weaknesses. Anonymous > suites are vulnerable to man-in-the-middle attacks. NULL suites do not > provide confidentiality. RFC 7525 [1] says: "Implementations MUST NOT > negotiate the cipher suites with NULL encryption." Also, TLS 1.3 has > removed them. > > These suites are not enabled by default, so an application has to > explicitly enable them using an API or the > "jdk.tls.client.cipherSuites" or "jdk.tls.server.cipherSuites" system > properties. However, adding them to the "jdk.tls.disabledAlgorithms" > security property adds an extra level of protection and additional > configuration change in order to use them. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8211883/webrev.00/ > > --Sean > > [1] https://tools.ietf.org/html/rfc7525 From jamil.j.nimeh at oracle.com Wed Oct 24 00:09:33 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 23 Oct 2018 17:09:33 -0700 Subject: SSLSession#getPeerCertificates and resumed TLSv1.3 sessions In-Reply-To: <25e58e01f8d522bc5863e1cab69b821688408bfc.camel@apache.org> References: <25e58e01f8d522bc5863e1cab69b821688408bfc.camel@apache.org> Message-ID: <703d341f-ce96-8044-0f1c-84df431f5fc9@oracle.com> Hello Oleg, Thanks for bringing this to our attention.? I've filed JDK-8212885 to track this issue.? I haven't played around with my test code to look for alternative ways to get at the peer cert chain, but I can try a few things.? I have one idea but it is completely a shot from the hip since I haven't had time to try it.? I'll throw it out there anyway while I experiment with it. For SSLSocket based connections there's a HandshakeCompletedListener that can be registered with the socket.? That listener object takes a HandshakeCompletedEvent which in turn has access to the socket and the session.? Perhaps at the completion of the initial handshake those peer certificates could be pulled from the HandshakeCompletedEvent.? That class has its own getPeerCertificates() method and can also give you the session object and a few other pieces of data that are found in the SSLSession object like the cipher suite, etc.? If your listener can do something with the HandshakeCompletedEvent that you'd (hopefully) get at the end of the initial handshake then perhaps you can obtain the cert chain that way. Like I said, I'm not sure this will work having not tried it yet (but I will).? I'll let you know if I can come up with a concrete workaround while we're getting the issue fixed. --Jamil P.S. JBS: https://bugs.openjdk.java.net/browse/JDK-8212885 On 10/21/18 1:31 PM, Oleg Kalnichevski wrote: > Good time of the day > > OpenJDK 11 TLS v1.3 implementation at present breaks hostname > verification code in all versions of Apache HttpClient and I am trying > to figure the best way to remedy the situation. > > Resumed TLS v1.3 sessions do not appear to carry a server certificate > chain, which, is as far as I understand, is to be expected. In case > of resumed TLSv1.3 sessions an attempt to get the servers certificates > with SSLSession#getPeerCertificates causes "peer not authenticated" > SSLPeerUnverifiedException. The trouble is that I fail to see any way > to find out whether or not an TLS v1.3 session has been negotiated > using the complete TLS handshake or resumed. > > The only solution I was able to have found so far is to catch > SSLPeerUnverifiedException, see if the TLS protocol is v1.3 and presume > this is because the session has been resumed [1]. This naturally looks > and feels very dodgy. > > Please advise how one should tell if TLS v1.3 session has been resumed > using SSLSession interface or what would be the right way to perform > hostname verification or any custom certificate validity checks with > TLS v1.3. > > Thank you in advance > > Oleg Kalnichevski > > [1] https://github.com/ok2c/httpclient/commit/6ca28be047a7a461c7814ee7e0f3e083158ee349 > From valerie.peng at oracle.com Wed Oct 24 00:55:14 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 23 Oct 2018 17:55:14 -0700 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> <566016d0-00ba-e938-693f-56948b9013da@oracle.com> Message-ID: Hi Martin, Please find my reply below: On 10/18/2018 9:26 AM, Martin Balao wrote: > Hi Valerie, > > Thanks for your feedback. > > I suggest to keep only one hierarchy of webrevs, so I'll continue in > Webrev.12 using your Webrev.02 as a base. Sure, I agree and prefer to use your hierarchy for the sake of complete history. > In general, I'm happy with your P11Key refactorings and with keeping > the previous reference inc/dec scheme on P11key clients side. > > I'll go file-by-file reviewing changes between your Webrev.02 and my > Webrev.11: > > ?* P11Key.java > ? * Why is P11Key now public? Hmm, this change may not be intentional. Please discard it. > ? * I have some concerns regarding how you calculate "extractKeyInfo" > value: > ? ?* Why is !sensitive a requirement? > ? ? * We can extract them wrapped, and the code already handles that. > ? ?* !tokenObject should be a requirement > ? ? * I know it's checked in NativeKeyHolder constructor but it could > be part of extractKeyInfo too for clarity > ? ?* Why is !type.equals(SECRET) a requirement? We can change the setting of extractKeyInfo to include !tokenObject and remove the !senstive and !type.equals(SECRET) I suppose. I used a stricter setting in my webrev.02 to avoid triggering the key wrapping functionality for ease of observation and verification. I didn't get to testing the prototype with key wrapping functionality before leaving for vacation, so I leave the stricter setting of extractKeyInfo in webrev.02 in place. > ? * In case of createNativeKey failure, I think we should decrement > the previously-incremented reference counter True, but since an exception is thrown, it may not matter much. > ? * Why do we need refCount to be of AtomicInteger type? All the > modifications to this instance variable are done inside instance > synchronized methods (getKeyID and releaseKeyID) This is done before I changed those methods to be synchronized. We don't need to use AtomicInteger now. > ? * The benefit of the previous incNativeKeyRef/decNativeKeyRef > methods is that they don't pay a sync cost for all cases in which the > feature is disabled. I believe we can keep that performance > improvement here too. Sure, it's good to not pay sync cost when feature is disabled. I didn't get to polish my webrev.02 due to the time crunch. Just want to show you the model that I have in mind. > ? ?* nativeKeyInfo variable is written at creation time and all other > usages are read-only, so we can have multiple readers at the same time > and synchronize on it if not null (instead of synchronizing the whole > method). What do you think? Sure, sounds good. > ?* P11KeyStore.java > ? * Copyright updated > ? * The reason why a call to "makeNativeKeyPersistent" was made in > P11KeyStore.updateP11Pkey method was because "P11Key key" could have > been extracted and the change not persisted in the keystore. This call > was disabling the feature for such keys. However, we now decided -for > a good reason- that keys from keystores (token objects) will not be > extracted. Thus, this call is no longer needed. I'm okay with this change. > ? * "long newKeyID" variable not used. Fixed on some other files too. Ok. > ?* P11Mac.java > ? * Copyright updated > ? * Split ensureInitialized and initialize functions again for the > reasons we've previously discussed. Line 195: For engineInit(...) calls, we should always call initialize() instead of ensureInitialized(). Although ensureInitialized() here will always call initialize() due to the reset(true) call on line 192, but conceptually, it should be initialize(). > ?* P11SecretKeyFactory.java > ? * Copyright updated > ? * The inc/dec pattern was broken in case of "token.p11.C_CopyObject" > failure. Fixed. Good. > ?* P11TlsKeyMaterialGenerator.java > ? * Removed dead & debug code Sure. > > ?* P11TlsPrfGenerator.java > ? * Removed dead & debug code Sure. > > ?* p11_keymgmt.c > ? * Removed dead code > ? * I've seen that you replaced some variable assignments with memcpy > and memset calls because of compiler errors. I wonder what these > errors are, as we should be able to cast and do assignments. Some are due to compiler errors, some are due to SIGBUS errors when testing with your changes. Casting also makes long lines which may hinder readability. This may due to my machine being solaris sparc. > I agree with having a property to completely disable this feature. > I've not seen, so far, unfixed cases in which extraction succeeds but > re-creation fails. Right, I think the chance of extraction succeeds but re-creation fails may be slim. The worse problem is that the re-creation succeeds but the re-created key is different from the original one. As this change does depend on the list of attributes, I wonder if the current list of attributes defined in the hardcoded template may become incomplete in the future (as newer algorithms are added or due to some other enhancements) and whether this may lead to the re-created keys being different. There could be other possible problems which we have not thought of now. Having a property to disable this may come into handy if these were to happen and helps troubleshoot if a problem is related to this or not. Thanks, Valerie > Webrev.12 is based on your Webrev.02, with modifications previously > described: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.12/ > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.12.zip > > > NOTE: Webrev.12 does not address neither the P11Key.java issues above > nor the property to completely disable this feature. Those 2 things > are the only pending on my side for now. > > Kind regards, > Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Oct 24 02:18:49 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 24 Oct 2018 10:18:49 +0800 Subject: RFR 8212867: Link to DRBG test vectors is redirected to a broken link Message-ID: Please take a review at the fix below: diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java --- a/src/java.base/share/classes/java/security/DrbgParameters.java +++ b/src/java.base/share/classes/java/security/DrbgParameters.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2018, 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 @@ -226,9 +226,9 @@ * Calling {@link SecureRandom#generateSeed(int)} will directly read * from this system default entropy source. *

- * This implementation has passed all tests included in the 20151104 version of - * - * The DRBG Test Vectors. + * This implementation has passed the test vectors (published on 2015-11-04) in + * + * Cryptographic Algorithm Validation Program. * * @since 9 */ Note that the link does not point to a zip file now. It might be a little rude to link to a 13MB zip file, and a description page is better. The page is quite concise and has a section named "Test Vectors" containing the link to the zip file. The zip file has actually no version info but the content shows the data was generated on 2015-11-04. I'd like to keep the date info in case the test vectors are updated some day. BTW, the zip file itself is exactly the same as before so there is no need to re-test. Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Oct 24 02:27:05 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 24 Oct 2018 10:27:05 +0800 Subject: RFR 8212867: Link to DRBG test vectors is redirected to a broken link In-Reply-To: References: Message-ID: <54C869FD-ED25-4213-85D2-64B717C5CD65@oracle.com> I'd like to refine the patch a little to diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java --- a/src/java.base/share/classes/java/security/DrbgParameters.java +++ b/src/java.base/share/classes/java/security/DrbgParameters.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2018, 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 @@ -226,9 +226,9 @@ * Calling {@link SecureRandom#generateSeed(int)} will directly read * from this system default entropy source. *

- * This implementation has passed all tests included in the 20151104 version of - * - * The DRBG Test Vectors. + * This implementation has passed the DRBG Test Vectors (published on 2015-11-04) in + * + * CAVP Testing: Random Number Generators. * * @since 9 */ While "Cryptographic Algorithm Validation Program" is the main title shown on the page, it looks like the secondary header "CAVP Testing: Random Number Generators" is more precise and matches the URL. I also change the test vectors name to "DRBG Test Vectors" because the section could contain more links to other RNG test vectors. Sorry for the quick update. Thanks Max > On Oct 24, 2018, at 10:18 AM, Weijun Wang wrote: > > Please take a review at the fix below: > > diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java > --- a/src/java.base/share/classes/java/security/DrbgParameters.java > +++ b/src/java.base/share/classes/java/security/DrbgParameters.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2016, 2018, 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 > @@ -226,9 +226,9 @@ > * Calling {@link SecureRandom#generateSeed(int)} will directly read > * from this system default entropy source. > *

> - * This implementation has passed all tests included in the 20151104 version of > - * > - * The DRBG Test Vectors. > + * This implementation has passed the test vectors (published on 2015-11-04) in > + * > + * Cryptographic Algorithm Validation Program. > * > * @since 9 > */ > > Note that the link does not point to a zip file now. It might be a little rude to link to a 13MB zip file, and a description page is better. The page is quite concise and has a section named "Test Vectors" containing the link to the zip file. The zip file has actually no version info but the content shows the data was generated on 2015-11-04. I'd like to keep the date info in case the test vectors are updated some day. > > BTW, the zip file itself is exactly the same as before so there is no need to re-test. > > Thanks > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olegk at apache.org Wed Oct 24 08:26:59 2018 From: olegk at apache.org (Oleg Kalnichevski) Date: Wed, 24 Oct 2018 10:26:59 +0200 Subject: SSLSession#getPeerCertificates and resumed TLSv1.3 sessions In-Reply-To: <703d341f-ce96-8044-0f1c-84df431f5fc9@oracle.com> References: <25e58e01f8d522bc5863e1cab69b821688408bfc.camel@apache.org> <703d341f-ce96-8044-0f1c-84df431f5fc9@oracle.com> Message-ID: On Tue, 2018-10-23 at 17:09 -0700, Jamil Nimeh wrote: > Hello Oleg, > > Thanks for bringing this to our attention. I've filed JDK-8212885 > to > track this issue. I haven't played around with my test code to look > for > alternative ways to get at the peer cert chain, but I can try a few > things. I have one idea but it is completely a shot from the hip > since > I haven't had time to try it. I'll throw it out there anyway while > I > experiment with it. For SSLSocket based connections there's a > HandshakeCompletedListener that can be registered with the socket. > That > listener object takes a HandshakeCompletedEvent which in turn has > access > to the socket and the session. Perhaps at the completion of the > initial > handshake those peer certificates could be pulled from the > HandshakeCompletedEvent. That class has its own > getPeerCertificates() > method and can also give you the session object and a few other > pieces > of data that are found in the SSLSession object like the cipher > suite, > etc. If your listener can do something with the > HandshakeCompletedEvent > that you'd (hopefully) get at the end of the initial handshake then > perhaps you can obtain the cert chain that way. > > Like I said, I'm not sure this will work having not tried it yet (but > I > will). I'll let you know if I can come up with a concrete > workaround > while we're getting the issue fixed. > Hi Jamil Unfortunately we need a way to deal with SSLEngine based connections as well. Would it not be possible to pull the server certificate chain from the session cache? While debugging HttpClient code I could see the original TLS session with the complete certificate chain stuck in the TLS session cache but I could not find a way to correlate the resumed session with the original one in the cache using the public SSLSession API or even to tell if the session has been resumed for that matter. This however looks plausible from inside SSLSessionImpl class. Cheers Oleg > --Jamil > > P.S. JBS: https://bugs.openjdk.java.net/browse/JDK-8212885 > > > On 10/21/18 1:31 PM, Oleg Kalnichevski wrote: > > Good time of the day > > > > OpenJDK 11 TLS v1.3 implementation at present breaks hostname > > verification code in all versions of Apache HttpClient and I am > > trying > > to figure the best way to remedy the situation. > > > > Resumed TLS v1.3 sessions do not appear to carry a server > > certificate > > chain, which, is as far as I understand, is to be expected. In case > > of resumed TLSv1.3 sessions an attempt to get the servers > > certificates > > with SSLSession#getPeerCertificates causes "peer not authenticated" > > SSLPeerUnverifiedException. The trouble is that I fail to see any > > way > > to find out whether or not an TLS v1.3 session has been negotiated > > using the complete TLS handshake or resumed. > > > > The only solution I was able to have found so far is to catch > > SSLPeerUnverifiedException, see if the TLS protocol is v1.3 and > > presume > > this is because the session has been resumed [1]. This naturally > > looks > > and feels very dodgy. > > > > Please advise how one should tell if TLS v1.3 session has been > > resumed > > using SSLSession interface or what would be the right way to > > perform > > hostname verification or any custom certificate validity checks > > with > > TLS v1.3. > > > > Thank you in advance > > > > Oleg Kalnichevski > > > > [1] > > https://github.com/ok2c/httpclient/commit/6ca28be047a7a461c7814ee7e0f3e083158ee349 > > From matthias.baesken at sap.com Wed Oct 24 14:20:47 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 24 Oct 2018 14:20:47 +0000 Subject: security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java fails in jdk In-Reply-To: <6a50692c-7fa8-081e-e72e-05fd52b80104@oracle.com> References: <1ce14de946914cf89ec60b5837e1129f@sap.com> <41263153-e2e1-f9e6-ab2d-010688b74d57@oracle.com> <6a50692c-7fa8-081e-e72e-05fd52b80104@oracle.com> Message-ID: Hi Rajan , I suggest we put the test security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java on the ProblemList.txt until the certificate issue is resolved. What do you think ? Best regards, Matthias > -----Original Message----- > From: Rajan Halade > Sent: Dienstag, 18. September 2018 19:05 > To: Lindenmaier, Goetz ; Baesken, Matthias > > Cc: security-dev at openjdk.java.net > Subject: Re: > security/infra/java/security/cert/CertPathValidator/certification/QuoVadisC > A.java fails in jdk > > We found an issue with revocation of intermedicate CA issued by QuoVadis > which is fixed by CA now. I am waiting to get new test certificates to > fix this bug. > > Thanks, > Rajan > > On 9/18/18 3:06 AM, Lindenmaier, Goetz wrote: > > Hi Rajan, > > > > are you working on this issue? We have this test disabled, I would like to > run it again. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: security-dev On Behalf > Of > >> Rajan Halade > >> Sent: Mittwoch, 11. Juli 2018 17:42 > >> To: Baesken, Matthias ; security- > >> dev at openjdk.java.net > >> Subject: Re: > >> > security/infra/java/security/cert/CertPathValidator/certification/QuoVadisC > >> A.java fails in jdk > >> > >> Thanks for the report, I have filed JDK-8207059. Yes, the test certificate > used > >> here need to be updated. > >> > >> - Rajan > >> > >> > >> On 7/11/18 7:43 AM, Baesken, Matthias wrote: > >> > >> > >> > >> > >> ... and in stdout there is a better message that seems to show the > >> reason , a certificate is expected to be "GOOD" but it has been > revoked > >> Fri Jan 19 15:39:57 CET 2018 . > >> > >> Should the test be updated with more recent certs (seems they > >> are hardwired in the test java source) ? > >> From sean.mullan at oracle.com Wed Oct 24 17:54:17 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 24 Oct 2018 13:54:17 -0400 Subject: RFR 8212867: Link to DRBG test vectors is redirected to a broken link In-Reply-To: <54C869FD-ED25-4213-85D2-64B717C5CD65@oracle.com> References: <54C869FD-ED25-4213-85D2-64B717C5CD65@oracle.com> Message-ID: <2629ce91-baa6-6179-b651-b4bc4af03b01@oracle.com> IMHO, this is kind of an odd thing to include in the javadocs, the fact that it passed a bunch of tests. I'd be more inclined to simply remove this sentence and (maybe) instead include it in the JDK Providers Guide, but even then I am not sure it is really necessary. --Sean On 10/23/18 10:27 PM, Weijun Wang wrote: > I'd like to refine the patch a little to > > *diff --git > a/src/java.base/share/classes/java/security/DrbgParameters.java > b/src/java.base/share/classes/java/security/DrbgParameters.java* > *--- a/src/java.base/share/classes/java/security/DrbgParameters.java* > *+++ b/src/java.base/share/classes/java/security/DrbgParameters.java* > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2016, 2018, 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 > @@ -226,9 +226,9 @@ > ? * Calling {@link SecureRandom#generateSeed(int)} will directly read > ? * from this system default entropy source. > ? *

> - * This implementation has passed all tests included in the 20151104 > version of > - * href="http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip"> > - * The DRBG Test Vectors. > + * This implementation has passed the DRBG Test Vectors (published on > 2015-11-04) in > + * href="https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/Random-Number-Generators"> > + * CAVP Testing: Random Number Generators. > ? * > ? * @since 9 > ? */ > > While "Cryptographic Algorithm Validation Program" is the main title > shown on the page, it looks like the secondary header "CAVP Testing: > Random Number Generators" is more precise and matches the URL. I also > change the test vectors name to "DRBG Test Vectors" because the section > could contain more links to other RNG test vectors. > > Sorry for the quick update. > > Thanks > Max > >> On Oct 24, 2018, at 10:18 AM, Weijun Wang > > wrote: >> >> Please take a review at the fix below: >> >> diff --git >> a/src/java.base/share/classes/java/security/DrbgParameters.java?b/src/java.base/share/classes/java/security/DrbgParameters.java >> --- a/src/java.base/share/classes/java/security/DrbgParameters.java >> +++ b/src/java.base/share/classes/java/security/DrbgParameters.java >> @@ -1,5 +1,5 @@ >> ?/* >> - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2016, 2018, 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 >> @@ -226,9 +226,9 @@ >> ? * Calling {@link SecureRandom#generateSeed(int)} will directly read >> ? * from this system default entropy source. >> ? *

>> - * This implementation has passed all tests included in the 20151104 >> version of >> - * > href="http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip"> >> - * The DRBG Test Vectors. >> + * This implementation has passed the test vectors (published on >> 2015-11-04) in >> + * > href="https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/Random-Number-Generators"> >> + * Cryptographic Algorithm Validation Program. >> ? * >> ? * @since 9 >> ? */ >> >> Note that the link does not point to a zip file now. It might be a >> little rude to link to a 13MB zip file, and a description?page is >> better. The page is quite concise and has a section named "Test >> Vectors" containing the link to the zip file. The zip?file has >> actually no version info but the content shows the data was generated >> on 2015-11-04. I'd like to keep the date info in?case the test vectors >> are updated some day. >> >> BTW, the zip file itself is exactly the same as before so there is no >> need to re-test. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Thu Oct 25 01:55:58 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Oct 2018 09:55:58 +0800 Subject: RFR 8212867: Link to DRBG test vectors is redirected to a broken link In-Reply-To: <2629ce91-baa6-6179-b651-b4bc4af03b01@oracle.com> References: <54C869FD-ED25-4213-85D2-64B717C5CD65@oracle.com> <2629ce91-baa6-6179-b651-b4bc4af03b01@oracle.com> Message-ID: It's a part of @implNote, and I added it there to show this implementation is compliant. I'm OK with removing it. Just like this: diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java --- a/src/java.base/share/classes/java/security/DrbgParameters.java +++ b/src/java.base/share/classes/java/security/DrbgParameters.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2018, 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 @@ -225,10 +225,6 @@ *

* Calling {@link SecureRandom#generateSeed(int)} will directly read * from this system default entropy source. - *

- * This implementation has passed all tests included in the 20151104 version of - * - * The DRBG Test Vectors. * * @since 9 */ Thanks Max > On Oct 25, 2018, at 1:54 AM, Sean Mullan wrote: > > IMHO, this is kind of an odd thing to include in the javadocs, the fact that it passed a bunch of tests. I'd be more inclined to simply remove this sentence and (maybe) instead include it in the JDK Providers Guide, but even then I am not sure it is really necessary. > > --Sean > > On 10/23/18 10:27 PM, Weijun Wang wrote: >> I'd like to refine the patch a little to >> *diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java* >> *--- a/src/java.base/share/classes/java/security/DrbgParameters.java* >> *+++ b/src/java.base/share/classes/java/security/DrbgParameters.java* >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2016, 2018, 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 >> @@ -226,9 +226,9 @@ >> * Calling {@link SecureRandom#generateSeed(int)} will directly read >> * from this system default entropy source. >> *

>> - * This implementation has passed all tests included in the 20151104 version of >> - * >> - * The DRBG Test Vectors. >> + * This implementation has passed the DRBG Test Vectors (published on 2015-11-04) in >> + * >> + * CAVP Testing: Random Number Generators. >> * >> * @since 9 >> */ >> While "Cryptographic Algorithm Validation Program" is the main title shown on the page, it looks like the secondary header "CAVP Testing: Random Number Generators" is more precise and matches the URL. I also change the test vectors name to "DRBG Test Vectors" because the section could contain more links to other RNG test vectors. >> Sorry for the quick update. >> Thanks >> Max >>> On Oct 24, 2018, at 10:18 AM, Weijun Wang > wrote: >>> >>> Please take a review at the fix below: >>> >>> diff --git a/src/java.base/share/classes/java/security/DrbgParameters.java b/src/java.base/share/classes/java/security/DrbgParameters.java >>> --- a/src/java.base/share/classes/java/security/DrbgParameters.java >>> +++ b/src/java.base/share/classes/java/security/DrbgParameters.java >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2016, 2018, 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 >>> @@ -226,9 +226,9 @@ >>> * Calling {@link SecureRandom#generateSeed(int)} will directly read >>> * from this system default entropy source. >>> *

>>> - * This implementation has passed all tests included in the 20151104 version of >>> - * >>> - * The DRBG Test Vectors. >>> + * This implementation has passed the test vectors (published on 2015-11-04) in >>> + * >>> + * Cryptographic Algorithm Validation Program. >>> * >>> * @since 9 >>> */ >>> >>> Note that the link does not point to a zip file now. It might be a little rude to link to a 13MB zip file, and a description page is better. The page is quite concise and has a section named "Test Vectors" containing the link to the zip file. The zip file has actually no version info but the content shows the data was generated on 2015-11-04. I'd like to keep the date info in case the test vectors are updated some day. >>> >>> BTW, the zip file itself is exactly the same as before so there is no need to re-test. >>> >>> Thanks >>> Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Oct 25 08:38:27 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Oct 2018 16:38:27 +0800 Subject: RFR 8026953: Add support for MS Cryptography next generation (CNG) (step 1) Message-ID: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> Please review the change at https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ (I will use a sub-task id for this change but currently JBS is down). The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. - Child class named "RSA" of CKeyPairGenerator. - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. Noreg-cleanup. Thanks Max [1] https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier From sean.mullan at oracle.com Thu Oct 25 17:10:09 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 25 Oct 2018 13:10:09 -0400 Subject: RFR 8212867: Link to DRBG test vectors is redirected to a broken link In-Reply-To: References: <54C869FD-ED25-4213-85D2-64B717C5CD65@oracle.com> <2629ce91-baa6-6179-b651-b4bc4af03b01@oracle.com> Message-ID: <96da45a0-5c7b-4de3-dfdb-cb06a8646381@oracle.com> On 10/24/18 9:55 PM, Weijun Wang wrote: > It's a part of @implNote, and I added it there to show this > implementation is compliant. I'm OK with removing it. Just like this: Fine by me. --Sean > > *diff --git > a/src/java.base/share/classes/java/security/DrbgParameters.java > b/src/java.base/share/classes/java/security/DrbgParameters.java* > *--- a/src/java.base/share/classes/java/security/DrbgParameters.java* > *+++ b/src/java.base/share/classes/java/security/DrbgParameters.java* > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2016, 2018, 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 > @@ -225,10 +225,6 @@ > ? *

> ? * Calling {@link SecureRandom#generateSeed(int)} will directly read > ? * from this system default entropy source. > - *

> - * This implementation has passed all tests included in the 20151104 > version of > - * href="http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip"> > - * The DRBG Test Vectors. > ? * > ? * @since 9 > ? */ > > Thanks > Max > >> On Oct 25, 2018, at 1:54 AM, Sean Mullan > > wrote: >> >> IMHO, this is kind of an odd thing to include in the javadocs, the >> fact that it passed a bunch of tests. I'd be more inclined?to simply >> remove this sentence and (maybe) instead include it in the JDK >> Providers Guide, but even then I am not sure it is?really necessary. >> >> --Sean >> >> On 10/23/18 10:27 PM, Weijun Wang wrote: >>> I'd like to refine the patch a little to >>> *diff --git >>> a/src/java.base/share/classes/java/security/DrbgParameters.java?b/src/java.base/share/classes/java/security/DrbgParameters.java* >>> *--- a/src/java.base/share/classes/java/security/DrbgParameters.java* >>> *+++ b/src/java.base/share/classes/java/security/DrbgParameters.java* >>> @@ -1,5 +1,5 @@ >>> ?/* >>> - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2016, 2018, 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 >>> @@ -226,9 +226,9 @@ >>> ??* Calling {@link SecureRandom#generateSeed(int)} will directly read >>> ??* from this system default entropy source. >>> ??*

>>> - * This implementation has passed all tests included in the 20151104 >>> version of >>> - * >> href="http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip"> >>> - * The DRBG Test Vectors. >>> + * This implementation has passed the DRBG Test Vectors (published >>> on 2015-11-04) in >>> + * >> href="https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/Random-Number-Generators"> >>> + * CAVP Testing: Random Number Generators. >>> ??* >>> ??* @since 9 >>> ??*/ >>> While "Cryptographic Algorithm Validation Program" is the main title >>> shown on the page, it looks like the secondary header?"CAVP Testing: >>> Random Number Generators" is more precise and matches the URL. I also >>> change the test vectors name to "DRBG?Test Vectors" because the >>> section could contain more links to other RNG test vectors. >>> Sorry for the quick update. >>> Thanks >>> Max >>>> On Oct 24, 2018, at 10:18 AM, Weijun Wang >>> ?> wrote: >>>> >>>> Please take a review at the fix below: >>>> >>>> diff --git >>>> a/src/java.base/share/classes/java/security/DrbgParameters.java?b/src/java.base/share/classes/java/security/DrbgParameters.java >>>> --- a/src/java.base/share/classes/java/security/DrbgParameters.java >>>> +++ b/src/java.base/share/classes/java/security/DrbgParameters.java >>>> @@ -1,5 +1,5 @@ >>>> ?/* >>>> - * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 2016, 2018, 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 >>>> @@ -226,9 +226,9 @@ >>>> ??* Calling {@link SecureRandom#generateSeed(int)} will directly read >>>> ??* from this system default entropy source. >>>> ??*

>>>> - * This implementation has passed all tests included in the >>>> 20151104 version of >>>> - * >>> href="http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip"> >>>> - * The DRBG Test Vectors. >>>> + * This implementation has passed the test vectors (published on >>>> 2015-11-04) in >>>> + * >>> href="https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/Random-Number-Generators"> >>>> + * Cryptographic Algorithm Validation Program. >>>> ??* >>>> ??* @since 9 >>>> ??*/ >>>> >>>> Note that the link does not point to a zip file now. It might be a >>>> little rude to link to a 13MB zip file, and a description?page is >>>> better. The page is quite concise and has a section named "Test >>>> Vectors" containing the link to the zip file. The?zip file has >>>> actually no version info but the content shows the data was >>>> generated on 2015-11-04. I'd like to keep the date?info in case the >>>> test vectors are updated some day. >>>> >>>> BTW, the zip file itself is exactly the same as before so there is >>>> no need to re-test. >>>> >>>> Thanks >>>> Max > From mstjohns at comcast.net Thu Oct 25 17:25:30 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 25 Oct 2018 13:25:30 -0400 Subject: RFR 8026953: Add support for MS Cryptography next generation (CNG) (step 1) In-Reply-To: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> Message-ID: <135316bf-6810-d572-b6a5-feee584d596a@comcast.net> Hi Max - For the same reason I was pushing back on Adam's EC provider I think I need to push back here.? You're recasting an RSAPublicKey to just a PublicKey and making it difficult to move key material in and out of the MSCAPI proivider.?? Same thing with the private key. For example, in the CPublicKey class you still have "getModulus()" and "getPublicExponent()", but to get at them you'd have to use CPublicKey rather than PublicKey. And looking forward, I'm not sure how you actually implement the EC classes here using this model. I'd suggest not making the change this way and overloading the existing classes, but instead adding the appropriate provider classes for new key types as you implement support for them.? E.g. Keep CRSAKey, CRSAPublicKey and CRSAPrivateKey as distinct classes, add CECKey, CECPublicKey and CECPrivateKey when you get there. Are you missing a KeyFactory class as well? Lastly, you may want to change the subclass/methods for CSignature (and probably other classes) to reflect the type of Signature you're returning: > if (algo.equals("NONEwithRSA")) { > - return new RSASignature.Raw(); > + return new CSignature.Raw(); Instead:?? "return new CSignature.RSARaw()" And this definitely isn't going to work if you have even one other Cipher you'll be returning: > if (algo.equals("RSA") || > algo.equals("RSA/ECB/PKCS1Padding")) { > - return new RSACipher(); > + return new CCipher(); > } Later, Mike On 10/25/2018 4:38 AM, Weijun Wang wrote: > Please review the change at > > https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ > > (I will use a sub-task id for this change but currently JBS is down). > > The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. > > Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: > > - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. > > - Child class named "RSA" of CKeyPairGenerator. > > - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. > > - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. > > Noreg-cleanup. > > Thanks > Max > > [1] https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Oct 26 03:09:19 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Oct 2018 11:09:19 +0800 Subject: RFR 8026953: Add support for MS Cryptography next generation (CNG) (step 1) In-Reply-To: <135316bf-6810-d572-b6a5-feee584d596a@comcast.net> References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <135316bf-6810-d572-b6a5-feee584d596a@comcast.net> Message-ID: <07189124-90E7-4A36-8FCA-14B912AB928E@oracle.com> Hi Mike Thanks for the feedback. I understand the current SunMSCAPI implementation recognizes RSA keys only and it's certainly incorrect to put something like getModulus() and getPublicExponent() in a general CKey class. They will be fixed later. When I have more sub class names, I'll definitely use them. You can see I've moved some CSignature methods into CSignature$RSA. I just haven't done it everywhere. We'll still need a base CKey for a CNG key, no matter what the underlying algorithm is. Since CNG uses the same NCRYPT_KEY_HANDLE type for different types of keys, we will do something similar on the Java side. Since the current CPublicKey and CPrivateKey are very light, it will be easy to move the content into algorithm-specific classes. The main reason I want to take this first step is that after some study on CNG I make some progress and also see some blockers. For example, I am able to expose a EC CNG key stored in Windows-MY now and use it to sign/verify. However, I still don't know how to import external keys inside there (certmgr.exe can so it's possible). Until now, the most requested function is to use existing keys in signatures and I want to start working on it. The first thing I noticed then is that the current class names are unsuitable and I think a refactoring will make them look better. Once I start working on the next step, I'll need to have different sub classes in CKey and CSignature. I even have an alternative plan to ditch CPublicKey and use the PublicKey classes in SunEC and SunRsaSign. This was actually already used in the RSASSA-PSS signature handling in SunMSCAPI we added into JDK 11 in the last minute. As for KeyFactory, we do not have an urgent requirement to use external keys in a CNG Signature object or store them into Windows-MY. Also, we can use the one in SunRsaSign. Thanks again. --Max > On Oct 26, 2018, at 1:25 AM, Michael StJohns wrote: > > Hi Max - > > For the same reason I was pushing back on Adam's EC provider I think I need to push back here. You're recasting an RSAPublicKey to just a PublicKey and making it difficult to move key material in and out of the MSCAPI proivider. Same thing with the private key. > > For example, in the CPublicKey class you still have "getModulus()" and "getPublicExponent()", but to get at them you'd have to use CPublicKey rather than PublicKey. > > And looking forward, I'm not sure how you actually implement the EC classes here using this model. > > I'd suggest not making the change this way and overloading the existing classes, but instead adding the appropriate provider classes for new key types as you implement support for them. E.g. Keep CRSAKey, CRSAPublicKey and CRSAPrivateKey as distinct classes, add CECKey, CECPublicKey and CECPrivateKey when you get there. > > Are you missing a KeyFactory class as well? > > Lastly, you may want to change the subclass/methods for CSignature (and probably other classes) to reflect the type of Signature you're returning: > >> if (algo.equals("NONEwithRSA")) { >> >> - return new RSASignature.Raw(); >> + return new CSignature.Raw(); > > Instead: "return new CSignature.RSARaw()" > > And this definitely isn't going to work if you have even one other Cipher you'll be returning: >> if (algo.equals("RSA") || >> algo.equals("RSA/ECB/PKCS1Padding")) { >> >> - return new RSACipher(); >> + return new CCipher(); >> >> } >> > > > Later, Mike > > > > > > On 10/25/2018 4:38 AM, Weijun Wang wrote: >> Please review the change at >> >> >> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >> >> >> (I will use a sub-task id for this change but currently JBS is down). >> >> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >> >> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >> >> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >> >> - Child class named "RSA" of CKeyPairGenerator. >> >> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >> >> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >> >> Noreg-cleanup. >> >> Thanks >> Max >> >> [1] >> https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier > From weijun.wang at oracle.com Fri Oct 26 03:22:51 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Oct 2018 11:22:51 +0800 Subject: RFR 8213007: Update the link in test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java Message-ID: <3385307A-A9BA-4C04-A9A6-6816F1928696@oracle.com> Oops, I should have updated the link in the actual CAVP test whiling fixing JDK-8212867. Here is it: diff --git a/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java b/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java --- a/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java +++ b/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2018, 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 @@ -46,8 +46,9 @@ import static java.security.DrbgParameters.Capability.*; /** - * The Known-output DRBG test. The test vector can be obtained from - * http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip. + * The Known-output DRBG test. The test vector can be downloaded from + * https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/drbg/drbgtestvectors.zip. + * The test is described on https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/Random-Number-Generators. * * Manually run this test with * Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Oct 26 12:17:31 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Oct 2018 08:17:31 -0400 Subject: RFR 8213007: Update the link in test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java In-Reply-To: <3385307A-A9BA-4C04-A9A6-6816F1928696@oracle.com> References: <3385307A-A9BA-4C04-A9A6-6816F1928696@oracle.com> Message-ID: <44a5594c-0dd2-a9bc-d1b7-89992fbea326@oracle.com> I get a "Page Not Found" error for https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/documents/drbg/drbgtestvectors.zip This works: https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/drbg/drbgtestvectors.zip --Sean On 10/25/18 11:22 PM, Weijun Wang wrote: > Oops, I should have updated the link in the actual CAVP test whiling > fixing?JDK-8212867. Here is it: > > *diff --git a/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java > b/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java* > *--- a/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java* > *+++ b/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java* > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2016, 2018, 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 > @@ -46,8 +46,9 @@ > ?import static java.security.DrbgParameters.Capability.*; > > > ?/** > - * The Known-output DRBG test. The test vector can be obtained from > - * http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip. > + * The Known-output DRBG test. The test vector can be downloaded from > + * > https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/drbg/drbgtestvectors.zip. > + * The test is described on > https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/Random-Number-Generators. > ? * > ? * Manually run this test with > ? * > > Thanks > Max > From weijun.wang at oracle.com Fri Oct 26 13:43:01 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Oct 2018 21:43:01 +0800 Subject: RFR 8213007: Update the link in test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java In-Reply-To: <44a5594c-0dd2-a9bc-d1b7-89992fbea326@oracle.com> References: <3385307A-A9BA-4C04-A9A6-6816F1928696@oracle.com> <44a5594c-0dd2-a9bc-d1b7-89992fbea326@oracle.com> Message-ID: <11950FF6-1D5E-4A95-8825-29C3E1FE064C@oracle.com> > On Oct 26, 2018, at 8:17 PM, Sean Mullan wrote: > > I get a "Page Not Found" error for https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/documents/drbg/drbgtestvectors.zip > > This works: > > https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/drbg/drbgtestvectors.zip This is the new link in my updated code. Maybe you clicked the removed one? > > --Sean > > On 10/25/18 11:22 PM, Weijun Wang wrote: >> Oops, I should have updated the link in the actual CAVP test whiling fixing JDK-8212867. Here is it: >> *diff --git a/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java b/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java* >> *--- a/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java* >> *+++ b/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java* >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2016, 2018, 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 >> @@ -46,8 +46,9 @@ >> import static java.security.DrbgParameters.Capability.*; >> /** >> - * The Known-output DRBG test. The test vector can be obtained from >> - * http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip. >> + * The Known-output DRBG test. The test vector can be downloaded from >> + * https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/drbg/drbgtestvectors.zip. >> + * The test is described on https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/Random-Number-Generators. >> * >> * Manually run this test with >> * >> Thanks >> Max From sean.mullan at oracle.com Fri Oct 26 14:08:36 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Oct 2018 10:08:36 -0400 Subject: RFR 8213007: Update the link in test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java In-Reply-To: <11950FF6-1D5E-4A95-8825-29C3E1FE064C@oracle.com> References: <3385307A-A9BA-4C04-A9A6-6816F1928696@oracle.com> <44a5594c-0dd2-a9bc-d1b7-89992fbea326@oracle.com> <11950FF6-1D5E-4A95-8825-29C3E1FE064C@oracle.com> Message-ID: <7c3f26ff-d416-5a35-a201-337d354486c9@oracle.com> On 10/26/18 9:43 AM, Weijun Wang wrote: > > >> On Oct 26, 2018, at 8:17 PM, Sean Mullan wrote: >> >> I get a "Page Not Found" error for https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/documents/drbg/drbgtestvectors.zip >> >> This works: >> >> https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/drbg/drbgtestvectors.zip > > This is the new link in my updated code. Maybe you clicked the removed one? Weird. I don't know why I clicked on that URL now. Anyway, looks good, go ahead and push the fix. --Sean > >> >> --Sean >> >> On 10/25/18 11:22 PM, Weijun Wang wrote: >>> Oops, I should have updated the link in the actual CAVP test whiling fixing JDK-8212867. Here is it: >>> *diff --git a/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java b/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java* >>> *--- a/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java* >>> *+++ b/test/jdk/sun/security/provider/SecureRandom/DrbgCavp.java* >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2016, 2018, 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 >>> @@ -46,8 +46,9 @@ >>> import static java.security.DrbgParameters.Capability.*; >>> /** >>> - * The Known-output DRBG test. The test vector can be obtained from >>> - * http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip. >>> + * The Known-output DRBG test. The test vector can be downloaded from >>> + * https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/drbg/drbgtestvectors.zip. >>> + * The test is described on https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program/Random-Number-Generators. >>> * >>> * Manually run this test with >>> * >>> Thanks >>> Max > From mbalao at redhat.com Fri Oct 26 17:57:30 2018 From: mbalao at redhat.com (Martin Balao) Date: Fri, 26 Oct 2018 14:57:30 -0300 Subject: RFR 6913047: SunPKCS11 memory leak In-Reply-To: References: <6b00e3d4-c795-f3e4-38ca-fa897f8680ea@oracle.com> <2a8e2986-631a-02f5-f419-e28c18232b33@oracle.com> <44a3e1c4-64ca-47bf-2061-4fe55fa7b827@oracle.com> <540e790d-1edf-732e-bb15-85537a6aa9c8@oracle.com> <566016d0-00ba-e938-693f-56948b9013da@oracle.com> Message-ID: Hi Valerie, I fixed all previously discussed issues in Webrev.13: * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.13/ * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.13.zip In addition to that, I fixed a couple of bugs introduced in p11_keymgmt.c. In Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo function, the first call to C_GetAttributeValue (to get CKA_CLASS, CKA_KEY_TYPE, CKA_SENSITIVE and CKA_NETSCAPE_DB attributes) may fail because the key may not have a CKA_NETSCAPE_DB attribute. That is fine. It just means that we are not going to get that attribute -which does not exist- and it won't be needed for key unwrapping. Later in Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo function, a similar issue happened. The call to get buffer lengths may return an error if one of the attributes does not exist. This is fine because length values are obtained anyways and based on that we were not going to query for non-existent attributes later. These bugs were silently making all keys not to be extracted. Thanks, Martin.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Oct 26 20:10:46 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Oct 2018 16:10:46 -0400 Subject: RFR [12]: 8191136: Remove deprecated java.security.{Certificate,Identity,IdentityScope,Signer} APIs Message-ID: <183dbd3b-8ae6-b446-508e-19a9842f2458@oracle.com> Please remove this change to remove the Certificate, Identity, IdentityScope, and Signer APIs. These APIs were marked for removal in Java SE 10. They have been deprecated since Java SE 1.2, and have long been superseded by other security APIs. Several SecurityPermission targets and one security property that are only applicable to these APIs have also been removed. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191136/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8212916 --Sean From sean.mullan at oracle.com Fri Oct 26 20:13:25 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Oct 2018 16:13:25 -0400 Subject: RFR [12]: 8191136: Remove deprecated java.security.{Certificate,Identity,IdentityScope,Signer} APIs In-Reply-To: <183dbd3b-8ae6-b446-508e-19a9842f2458@oracle.com> References: <183dbd3b-8ae6-b446-508e-19a9842f2458@oracle.com> Message-ID: On 10/26/18 4:10 PM, Sean Mullan wrote: > Please remove this change to remove the Certificate, Identity, Typo above - s/remove this change/review this change/ Must be Friday ... ;) --Sean > IdentityScope, and Signer APIs. These APIs were marked for removal in > Java SE 10. They have been deprecated since Java SE 1.2, and have long > been superseded by other security APIs. Several SecurityPermission > targets and one security property that are only applicable to these APIs > have also been removed. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191136/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8212916 > > --Sean From lj.slo at hotmail.com Sat Oct 27 10:23:15 2018 From: lj.slo at hotmail.com (John Newman) Date: Sat, 27 Oct 2018 10:23:15 +0000 Subject: Hashing in Java and Java Cryptography Architecture (JCA) design In-Reply-To: <7c1a719c-522e-47c1-6ee4-7149fbf1c5af@suche.org> References: , <7c1a719c-522e-47c1-6ee4-7149fbf1c5af@suche.org> Message-ID: Not to be rude to Thomas but has anyone else have any thoughts on this? --Janez ________________________________ From: security-dev on behalf of Thomas Lu?nig Sent: Tuesday, October 23, 2018 8:24:33 PM To: security-dev at openjdk.java.net Subject: Re: Hashing in Java and Java Cryptography Architecture (JCA) design Hi, even if it looks complicated for you the idea is that your code is not hard wired to MD5 or SHA1 but in ideal case it is configured. Than you do not know in advance if the selected digest is available. On the other hand no one say that you can create your own helper/tools class. The idea is that you are not fixed to one algo but what if you say "MD4" or "POLY1305" only some algorithm where available at coding time thy can be removed later (maybe even via policy) or newly been added. For this there is the NoSuchAlgorithmException to show the developer there can be some error. RuntimeException would be ignored and may crash the whole program or task. Gru? Thomas class DIGEST { static byte[] SHA1(byte[]... args) { ... } } then you can simply call DIGEST.SHA1(a,b,c) On 23.10.2018 19:50:44, John Newman wrote: > This seems to me overly complicated for a simple task of > instantiating a MessageDigest object: > > MessageDigest md = null; > try { > md = MessageDigest.getInstance("SHA-1"); > } catch (NoSuchAlgorithmException nsae) {} > > Couldn't MessageDigest simply be an *interface* and > the SHA funcionality a special *implementation*, like so: > > MessageDigest md = new ShaMessageDigest(); > > ? > > But instead we have these factory methods (accross all of the JCA > core classes) which throw exceptions, polluting the code. Is the > Provider abstraction really needed? The only real benefit I see is > neater class names. > > In fact - couldn't we get rid of the entire Java Cryptography Architecture (JCA) > as it is and redesign it to be more object oriented? For example, couldn't this: > > byte [][] args = //... > MessageDigest md = //.. > md.update(args[0]) > md.update(args[1]); > md.digest(); > > become this: > > byte [][] args = //... > MessageDigest md = //.. > md.update(args[0]).update(args[1]).digest(); > > or maybe even this: > > MessageDigest md = //.. > byte [][] args = //... > new IntermediateDigest( > md, > args[0], > args[1] > ).bytes() > > where IntermediateDigest itself could be an argument to MessageDigest's update() > method, making things like H(H(x), y) look much more compact and readable? > > > --Janez -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sun Oct 28 06:54:12 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 28 Oct 2018 14:54:12 +0800 Subject: RFR [12]: 8191136: Remove deprecated java.security.{Certificate,Identity,IdentityScope,Signer} APIs In-Reply-To: <183dbd3b-8ae6-b446-508e-19a9842f2458@oracle.com> References: <183dbd3b-8ae6-b446-508e-19a9842f2458@oracle.com> Message-ID: <819BDCA3-07C6-43B3-A741-86F7C21187B6@oracle.com> Change looks fine, and I added myself a a reviewer in the CSR. Thanks Max > On Oct 27, 2018, at 4:10 AM, Sean Mullan wrote: > > Please review this change to remove the Certificate, Identity, IdentityScope, and Signer APIs. These APIs were marked for removal in Java SE 10. They have been deprecated since Java SE 1.2, and have long been superseded by other security APIs. Several SecurityPermission targets and one security property that are only applicable to these APIs have also been removed. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191136/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8212916 > > --Sean From christoph.langer at sap.com Mon Oct 29 09:26:56 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Oct 2018 09:26:56 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) Message-ID: <5030914b571a449bba7a98152fdc0850@sap.com> Hi, here's an update of my webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.1/ I added synchronization to the updating of permCache in ZipUtils.java to avoid concurrent modifications. As per request from Alan, I'm adding security-dev to get a review from security perspective. Thanks Christoph From: Langer, Christoph Sent: Freitag, 26. Oktober 2018 17:13 To: core-libs-dev ; nio-dev ; 'Xueming Shen' Cc: Schmelter, Ralf ; 'Volker Simonis' Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions Hi, please review this enhancement of jdk.nio.zipfs to support Posix file permissions. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 I had already posted this change as part of a larger fix for "6194856: Zip Files lose ALL ownership and permissions of the files" [1]. With the original proposal I was also addressing the java.util.zip API and the jar tool. However, I've decided to split this endeavor into 2 parts. While I still want to follow up on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in first. Both places don't have dependencies to each other and since zipfs does not change an external API, I guess the bar here is lower. Maybe it is even a candidate for down-porting to jdk11u in the future. After my fix, zipfs will support the PosixFileAttributeView. Posix file attributes can't be fully supported since owner and group are not handled in zip files. So methods supposed to get these attributes will return an UnsupportedOperationException. But the posix permissions will now be correctly handled, that is stored into and read from the zip file. @Sherman: Following suggestions from your review, I removed the test with the binary zip file. I initially thought it is a good idea to test on a well-known file. However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip file and reading it again so I guess test coverage is quite complete here. Furthermore, I made some public declarations in ZipUtils package private which should suffice. I also tried to address your performance concerns with permsToFlags and permsFromFlags. In permsToFlags I will now simply iterate to the set of permissions and add the flags to the return value. It's probably more performant than the streaming approach and doesn't look much worse in the code. In permsFromFlags I added a cache of permission sets which should avoid constant calls to the streaming. However, as the return value needs to be mutable, I have to clone the cached permissions. Maybe it would have the same or even better performance if we iteratively fill a new set of permissions each time permsToFlags gets called. What do you think? Do we need a CSR for this patch? Thanks & Best regards Christoph [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055971.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Oct 29 12:06:00 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Oct 2018 12:06:00 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) In-Reply-To: <5030914b571a449bba7a98152fdc0850@sap.com> References: <5030914b571a449bba7a98152fdc0850@sap.com> Message-ID: On 29/10/2018 09:26, Langer, Christoph wrote: > : > > As per request from Alan, I?m adding security-dev to get a review from > security perspective. > > For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Oct 29 14:55:20 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Oct 2018 14:55:20 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) In-Reply-To: References: <5030914b571a449bba7a98152fdc0850@sap.com> Message-ID: <85c85aadb98b4b82a9ec0a6ee9cb8fa7@sap.com> Hi Alan, security guys, I've proposed a CSR for this change now: https://bugs.openjdk.java.net/browse/JDK-8213082. I also updated the webrev, simplifying jdk.nio.zipfs.ZipUtils.permsFromFlags and eliminating the WeakHashMap: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ Since I've decoupled the changes to java.util.zip and jartool from those in jdk.zipfs, we're discussing only jdk.zipfs here. The implication of my change is that when working with files backed by the nio FileSystemProvider (java.nio.file.spi.FileSystemProvider) named "jar", which is the alias for zipfs, the files will support attributes of type java.nio.file.attribute.PosixFilePermissions ("posix:permissions"). It basically means that some methods of java.nio.file.Files that would return null or UnsupportedOperationException before would find an implementation now. Examples: https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getPosixFilePermissions(java.nio.file.Path,java.nio.file.LinkOption...) https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#setPosixFilePermissions(java.nio.file.Path,java.util.Set) https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#readAttributes(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributes.html https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getFileAttributeView(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributeView.html Thanks in advance for reviewing. Best regards Christoph From: Alan Bateman Sent: Montag, 29. Oktober 2018 13:06 To: Langer, Christoph ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen Cc: Volker Simonis ; Andrew Luo ; nio-dev Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) On 29/10/2018 09:26, Langer, Christoph wrote: : As per request from Alan, I'm adding security-dev to get a review from security perspective. For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Mon Oct 29 16:10:22 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 29 Oct 2018 12:10:22 -0400 Subject: Hashing in Java and Java Cryptography Architecture (JCA) design In-Reply-To: References: <7c1a719c-522e-47c1-6ee4-7149fbf1c5af@suche.org> Message-ID: <1bb622cf-7a30-0cdb-d230-3474c69469a0@oracle.com> There are several ways in which JCA is deficient when viewed from the standpoint of modern API design. At some point, we will probably want to develop a new API that doesn't have these issues. I expect this to require significant effort, though, and this sort of work gets lower priority compared to implementing new algorithms/standards and TLS 1.3 work. So it is hard to tell if/when anyone will have time to work on this. FWIW, I partially agree with the complaint about provider selection complexity. I think the provider/algorithm selection mechanism is important, but perhaps not everyone needs it, and it shouldn't clutter up the core APIs. A more typical pattern for this sort of thing is to include a configuration layer on top of the core abstractions/implementation, and all of the provider selection complexity would go in this layer. I also agree that there are ways to improve the core APIs, including making them more functional/streaming, using fluent syntax, etc. On 10/27/2018 6:23 AM, John Newman wrote: > Not to be rude to Thomas but has anyone else have any thoughts on this? > --Janez > ------------------------------------------------------------------------ > *From:* security-dev on behalf > of Thomas Lu?nig > *Sent:* Tuesday, October 23, 2018 8:24:33 PM > *To:* security-dev at openjdk.java.net > *Subject:* Re: Hashing in Java and Java Cryptography Architecture > (JCA) design > Hi, > > even if it looks complicated for you the idea is that your code is not > hard wired to MD5 or SHA1 but in ideal case > it is configured. Than you do not know in advance if the selected digest > is available. > On the other hand no one say that you can create your own helper/tools > class. > The idea is that you are not fixed to one algo but what if you say "MD4" > or "POLY1305" only some algorithm > where available at coding time thy can be removed later (maybe even via > policy) or newly been added. For > this there is the NoSuchAlgorithmException to show the developer there > can be some error. > RuntimeException would be ignored and may crash the whole program or task. > > > Gru? Thomas > > class DIGEST { > > static byte[] SHA1(byte[]... args) { > ... > } > > } > > then you can simply call DIGEST.SHA1(a,b,c) > > On 23.10.2018 19:50:44, John Newman wrote: > > This seems to me overly complicated for a simple task of > > instantiating a MessageDigest object: > > > > MessageDigest md = null; > > try { > >????? md = MessageDigest.getInstance("SHA-1"); > > } catch (NoSuchAlgorithmException nsae) {} > > > > Couldn't MessageDigest simply be an *interface* and > > the SHA funcionality a special *implementation*, like so: > > > > MessageDigest md = new ShaMessageDigest(); > > > > ? > > > > But instead we have these factory methods (accross all of the JCA > > core classes) which throw exceptions, polluting the code. Is the > > Provider abstraction really needed? The only real benefit I see is > > neater class names. > > > > In fact - couldn't we get rid of the entire Java Cryptography > Architecture (JCA) > > as it is and redesign it to be more object oriented? For example, > couldn't this: > > > > byte [][] args = //... > > MessageDigest md = //.. > > md.update(args[0]) > > md.update(args[1]); > > md.digest(); > > > > become this: > > > > byte [][] args = //... > > MessageDigest md = //.. > > md.update(args[0]).update(args[1]).digest(); > > > > or maybe even this: > > > > MessageDigest md = //.. > > byte [][] args = //... > > new IntermediateDigest( > >????? md, > >????? args[0], > >????? args[1] > > ).bytes() > > > > where IntermediateDigest itself could be an argument to > MessageDigest's update() > > method, making things like H(H(x), y) look much more compact and > readable? > > > > > > --Janez -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Oct 29 17:41:51 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 29 Oct 2018 10:41:51 -0700 Subject: Code Review Request, JDK-8212738, Incorrectly named signature scheme ecdsa_secp512r1_sha512 Message-ID: <58a81830-ed92-b310-6c5e-d68fb3b59b8a@oracle.com> Hi, Please review the update: http://cr.openjdk.java.net/~xuelei/8212738/webrev.00/ The signature algorithm name should be ""ecdsa_secp521r1_sha512", instead of "ecdsa_secp512r1_sha512". No new regression test. Trivial update, no impact on the behaviors except the debug log message. Thanks, Xuelei From anthony.scarpino at oracle.com Mon Oct 29 17:48:34 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 29 Oct 2018 10:48:34 -0700 Subject: Code Review Request, JDK-8212738, Incorrectly named signature scheme ecdsa_secp512r1_sha512 In-Reply-To: <58a81830-ed92-b310-6c5e-d68fb3b59b8a@oracle.com> References: <58a81830-ed92-b310-6c5e-d68fb3b59b8a@oracle.com> Message-ID: <408c4500-177c-c41a-9099-50eaf8d5ac7b@oracle.com> Looks good to me Tony On 10/29/2018 10:41 AM, Xuelei Fan wrote: > Hi, > > Please review the update: > > ??? http://cr.openjdk.java.net/~xuelei/8212738/webrev.00/ > > The signature algorithm name should be ""ecdsa_secp521r1_sha512", > instead of "ecdsa_secp512r1_sha512". > > No new regression test.? Trivial update, no impact on the behaviors > except the debug log message. > > Thanks, > Xuelei From mstjohns at comcast.net Mon Oct 29 18:22:12 2018 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 29 Oct 2018 14:22:12 -0400 Subject: RFR 8026953: Add support for MS Cryptography next generation (CNG) (step 1) In-Reply-To: <07189124-90E7-4A36-8FCA-14B912AB928E@oracle.com> References: <75632D2A-5E1A-42D9-9434-E20736E20B3C@oracle.com> <135316bf-6810-d572-b6a5-feee584d596a@comcast.net> <07189124-90E7-4A36-8FCA-14B912AB928E@oracle.com> Message-ID: <93ffbdad-524a-ae6d-91c9-25574fb91ff9@comcast.net> On 10/25/2018 11:09 PM, Weijun Wang wrote: > Hi Mike > > Thanks for the feedback. > > I understand the current SunMSCAPI implementation recognizes RSA keys only and it's certainly incorrect to put something like getModulus() and getPublicExponent() in a general CKey class. They will be fixed later. When I have more sub class names, I'll definitely use them. You can see I've moved some CSignature methods into CSignature$RSA. I just haven't done it everywhere. OK. > > We'll still need a base CKey for a CNG key, no matter what the underlying algorithm is. Since CNG uses the same NCRYPT_KEY_HANDLE type for different types of keys, we will do something similar on the Java side. Since the current CPublicKey and CPrivateKey are very light, it will be easy to move the content into algorithm-specific classes. This is where I think you need to fix the structure: abstract class CKey public class CRSAPublicKey extends CKey implements RSAKey, RSAPublicKey, PublicKey public class CRSAExtractablePrivateKey extends CKey implements RSAKey, RSAPrivateKey, PrivateKey[,RSAMultiPrimePrivateCrt | RSAPrivateCrtKey] public class CRSAPrivateKey extends CKey implements RSAKey, PrivateKey public class CECPublicKey extends CKey implements ECKey, ECPublicKey, PublicKey public class CECExtractablePrivateKey extends CKey implements ECKey, PrivateKey public class CECPrivateKey extends CKey implements ECKey, ECPrivateKey, ECPrivateKey Note the two different versions of the private keys to match up with the key handling bits as well as some additional interfaces that may be needed to be added to support the underlying provider's requirements for the RSA keys. Also, I'm looking ahead a little bit and thinking about how the JCA would use the windows PCP (Platform Crypto Provider) which uses the TPM to enforce hardware security.? It would be useful if you didn't have to re-write everything just because of a different underlying Windows provider. (There's a PCP development kit that's got some useful sample code that might help a little bit with refactoring the JCA MSCAPI provider even for the existing code).?? E.g. eventually supporting an MSCAPI-PCP provider shouldn't require all new code. > > The main reason I want to take this first step is that after some study on CNG I make some progress and also see some blockers. For example, I am able to expose a EC CNG key stored in Windows-MY now and use it to sign/verify. However, I still don't know how to import external keys inside there (certmgr.exe can so it's possible). Until now, the most requested function is to use existing keys in signatures and I want to start working on it. The first thing I noticed then is that the current class names are unsuitable and I think a refactoring will make them look better. AFAICT, you're not going to be able to use any external key without importing it or running it through a key factory.? The main class you're going to be using is NCryptImportKey (or alternately BCryptImportKeyPair). > > Once I start working on the next step, I'll need to have different sub classes in CKey and CSignature. I even have an alternative plan to ditch CPublicKey and use the PublicKey classes in SunEC and SunRsaSign. This was actually already used in the RSASSA-PSS signature handling in SunMSCAPI we added into JDK 11 in the last minute. So you just use software classes in another provider for encrypting/verifying?? To be honest this sounds messy and may come back to bite you down the road. > > As for KeyFactory, we do not have an urgent requirement to use external keys in a CNG Signature object or store them into Windows-MY. Also, we can use the one in SunRsaSign. Hmm... one of the more common things is to move around .p12 files with your certs and keys.? They can be imported by the Windows tools - it would be *really* nice if you can do the same thing with the Java provider. > > Thanks again. > > --Max > >> On Oct 26, 2018, at 1:25 AM, Michael StJohns wrote: >> >> Hi Max - >> >> For the same reason I was pushing back on Adam's EC provider I think I need to push back here. You're recasting an RSAPublicKey to just a PublicKey and making it difficult to move key material in and out of the MSCAPI proivider. Same thing with the private key. >> >> For example, in the CPublicKey class you still have "getModulus()" and "getPublicExponent()", but to get at them you'd have to use CPublicKey rather than PublicKey. >> >> And looking forward, I'm not sure how you actually implement the EC classes here using this model. >> >> I'd suggest not making the change this way and overloading the existing classes, but instead adding the appropriate provider classes for new key types as you implement support for them. E.g. Keep CRSAKey, CRSAPublicKey and CRSAPrivateKey as distinct classes, add CECKey, CECPublicKey and CECPrivateKey when you get there. >> >> Are you missing a KeyFactory class as well? >> >> Lastly, you may want to change the subclass/methods for CSignature (and probably other classes) to reflect the type of Signature you're returning: >> >>> if (algo.equals("NONEwithRSA")) { >>> >>> - return new RSASignature.Raw(); >>> + return new CSignature.Raw(); >> Instead: "return new CSignature.RSARaw()" >> >> And this definitely isn't going to work if you have even one other Cipher you'll be returning: >>> if (algo.equals("RSA") || >>> algo.equals("RSA/ECB/PKCS1Padding")) { >>> >>> - return new RSACipher(); >>> + return new CCipher(); >>> >>> } >>> >> >> Later, Mike >> >> >> >> >> >> On 10/25/2018 4:38 AM, Weijun Wang wrote: >>> Please review the change at >>> >>> >>> https://cr.openjdk.java.net/~weijun/8026953/webrev.00/ >>> >>> >>> (I will use a sub-task id for this change but currently JBS is down). >>> >>> The major change is renaming classes. Since we are going to support algorithms other than RSA, I've renamed the classes like RSAPrivateKey -> CPrivateKey. Classes that have the same name as JCA classes (like Key, KeyStore) are also renamed (to CKey, CKeyStore) so it's easy to tell them apart. >>> >>> Others are not about renaming but they are also related to supporting other algorithms, and there is no behavior change. They include: >>> >>> - CKey (plus its child classes CPublicKey and CPrivateKey) has a new field "algorithm". This field is used by CKeyStore::generateRSAKeyAndCertificateChain and its value is obtained from the public key algorithm in a cert [1]. >>> >>> - Child class named "RSA" of CKeyPairGenerator. >>> >>> - Child class named "RSA" of CSignature. I also moved some RSA-related methods into this child class as overridden methods. >>> >>> - CKeyStore::setPrivateKey's key parameter has a new type Key, but it still only accepts RSAPrivateCrtKey now. >>> >>> Noreg-cleanup. >>> >>> Thanks >>> Max >>> >>> [1] >>> https://docs.microsoft.com/en-gb/windows/desktop/api/wincrypt/ns-wincrypt-_crypt_algorithm_identifier From sean.mullan at oracle.com Tue Oct 30 14:28:40 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 30 Oct 2018 10:28:40 -0400 Subject: RFR 8212217: JGSS: Don't dispose() of creds too eagerly In-Reply-To: References: Message-ID: <1dc74431-222d-2b83-1e24-3b7839f85a65@oracle.com> I think you should put braces around the conditional statements on lines 332, 357, & 359. It would read better and avoid accidental bugs. Where does delegatedCred get used? It seems to be never set. Otherwise looks fine. You will need to add a noreg label if you can't write a test. --Sean On 10/15/18 9:43 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8212217/webrev.00/ > > This bug is reported and fixed by Nico Williams . > > I'll think if a regression test can be added. > > Thanks > Max > From mbalao at redhat.com Tue Oct 30 17:44:11 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 30 Oct 2018 14:44:11 -0300 Subject: [RFR] JDK-8213154: Update copyright headers of files in src tree that are missing Classpath exception Message-ID: Hi, Can I have a review for JDK-8213154 [1]? * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.00/ * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.00.zip Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8213154 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Oct 30 17:50:53 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Oct 2018 17:50:53 +0000 Subject: [RFR] JDK-8213154: Update copyright headers of files in src tree that are missing Classpath exception In-Reply-To: References: Message-ID: On 30/10/2018 17:44, Martin Balao wrote: > Hi, > > Can I have a review for JDK-8213154 [1]? > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.00/ > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.00.zip > > Did you mean to include a test in this update? Just asking because tests doesn't usually have the Classpath exception. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Tue Oct 30 17:59:39 2018 From: mbalao at redhat.com (Martin Balao) Date: Tue, 30 Oct 2018 14:59:39 -0300 Subject: [RFR] JDK-8213154: Update copyright headers of files in src tree that are missing Classpath exception In-Reply-To: References: Message-ID: Hi, You're right, this is not relevant for a test. * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.01 * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.01.zip Thanks, Martin.- On Tue, Oct 30, 2018 at 2:50 PM, Alan Bateman wrote: > On 30/10/2018 17:44, Martin Balao wrote: > > Hi, > > Can I have a review for JDK-8213154 [1]? > > * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/8213154.webrev.00/ > * http://cr.openjdk.java.net/~mbalao/webrevs/8213154/ > 8213154.webrev.00.zip > > Did you mean to include a test in this update? Just asking because tests > doesn't usually have the Classpath exception. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajan.halade at oracle.com Tue Oct 30 18:58:42 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 30 Oct 2018 11:58:42 -0700 Subject: RFR: 8207059: Update test certificates in QuoVadisCA.java test Message-ID: <422ffefb-09e6-bee6-6f81-38274b3c4c40@oracle.com> Please review this fix to update test certificates used in QuoVadis CA tests. Webrev: http://cr.openjdk.java.net/~rhalade/8207059/webrev.00/ Thanks, Rajan From xuelei.fan at oracle.com Tue Oct 30 20:55:10 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 30 Oct 2018 13:55:10 -0700 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession Message-ID: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> Hi, For the current HttpsURLConnection, there is not much security parameters exposed in the public APIs. An application may need richer information for the underlying TLS connections, for example the negotiated TLS protocol version. Please let me know if you have concerns to add a new method HttpsURLConnection.getSSLSession() and deprecate the duplicated methods, by the end of Nov. 2, 2018. Here is the proposal: https://bugs.openjdk.java.net/browse/JDK-8213161 Thanks, Xuelei From matthias.baesken at sap.com Wed Oct 31 09:13:55 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 31 Oct 2018 09:13:55 +0000 Subject: 8207059: Update test certificates in QuoVadisCA.java test In-Reply-To: <422ffefb-09e6-bee6-6f81-38274b3c4c40@oracle.com> References: <422ffefb-09e6-bee6-6f81-38274b3c4c40@oracle.com> Message-ID: Hi Rajan, thanks for looking into it. Change looks good to me (not a Reviewer however). The QuoVadisCA.java test passed on linux x86_64 (run with current jdk/jdk build). Would be probably a good idea to bring this also into jdk11 . Thanks, Matthias > -----Original Message----- > From: Rajan Halade > Sent: Dienstag, 30. Oktober 2018 19:59 > To: security-dev ; Sean Mullan > ; Lindenmaier, Goetz > ; Baesken, Matthias > > Subject: RFR: 8207059: Update test certificates in QuoVadisCA.java test > > Please review this fix to update test certificates used in QuoVadis CA > tests. > > Webrev: http://cr.openjdk.java.net/~rhalade/8207059/webrev.00/ > > Thanks, > Rajan From weijun.wang at oracle.com Wed Oct 31 09:22:27 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 31 Oct 2018 17:22:27 +0800 Subject: RFR 8212217: JGSS: Don't dispose() of creds too eagerly In-Reply-To: <1dc74431-222d-2b83-1e24-3b7839f85a65@oracle.com> References: <1dc74431-222d-2b83-1e24-3b7839f85a65@oracle.com> Message-ID: <3A967B4D-BCF7-47E0-AA9C-75111386C3CE@oracle.com> Copying Nico the original author. > On Oct 30, 2018, at 10:28 PM, Sean Mullan wrote: > > I think you should put braces around the conditional statements on lines 332, 357, & 359. It would read better and avoid accidental bugs. > > Where does delegatedCred get used? It seems to be never set. It's set in a native method 322 outToken = cStub.acceptContext(pCred, cb, inToken, this); > > Otherwise looks fine. You will need to add a noreg label if you can't write a test. Yes. Thanks Max > > --Sean > > On 10/15/18 9:43 PM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8212217/webrev.00/ >> This bug is reported and fixed by Nico Williams . >> I'll think if a regression test can be added. >> Thanks >> Max From sean.mullan at oracle.com Wed Oct 31 13:43:00 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 31 Oct 2018 09:43:00 -0400 Subject: RFR: 8207059: Update test certificates in QuoVadisCA.java test In-Reply-To: <422ffefb-09e6-bee6-6f81-38274b3c4c40@oracle.com> References: <422ffefb-09e6-bee6-6f81-38274b3c4c40@oracle.com> Message-ID: <30204cef-f3f8-8df0-e18e-42fa40e83f63@oracle.com> Looks fine to me. --Sean On 10/30/18 2:58 PM, Rajan Halade wrote: > Please review this fix to update test certificates used in QuoVadis CA > tests. > > Webrev: http://cr.openjdk.java.net/~rhalade/8207059/webrev.00/ > > Thanks, > Rajan From chris.hegarty at oracle.com Wed Oct 31 15:52:29 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 31 Oct 2018 15:52:29 +0000 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> Message-ID: Xuelei, On 30/10/18 20:55, Xuelei Fan wrote: > Hi, > > For the current HttpsURLConnection, there is not much security > parameters exposed in the public APIs.? An application may need richer > information for the underlying TLS connections, for example the > negotiated TLS protocol version. > > Please let me know if you have concerns to add a new method > HttpsURLConnection.getSSLSession() and deprecate the duplicated methods, > by the end of Nov. 2, 2018. > > Here is the proposal: > ??? https://bugs.openjdk.java.net/browse/JDK-8213161 > > Thanks, > Xuelei The new method looks fine. On the deprecation, minimally the annotation should contain the "since" element, which will have a value of `12`. Also, I wonder, now that I see the spec, whether or not it is actually a good idea to deprecate these methods. The reason I ask this is that the new method, getSSLSession, can throw UOE, which effectively makes it an optional method. Access to the specific security parameters provided by the existing methods is non-optional. This is a clear difference, and possibly a reason, for folk not interested in the "new" parameters, to continue to use the existing methods. -Chris From xuelei.fan at oracle.com Wed Oct 31 20:03:05 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 31 Oct 2018 13:03:05 -0700 Subject: A new proposal to add methods to HttpsURLConnection to access SSLSession In-Reply-To: References: <7c3d0991-7864-06df-76cb-7b921244810b@oracle.com> Message-ID: <55db048d-b47e-deec-839d-ae25e2c70982@oracle.com> On 10/31/2018 8:52 AM, Chris Hegarty wrote: > Xuelei, > > On 30/10/18 20:55, Xuelei Fan wrote: >> Hi, >> >> For the current HttpsURLConnection, there is not much security >> parameters exposed in the public APIs.? An application may need richer >> information for the underlying TLS connections, for example the >> negotiated TLS protocol version. >> >> Please let me know if you have concerns to add a new method >> HttpsURLConnection.getSSLSession() and deprecate the duplicated >> methods, by the end of Nov. 2, 2018. >> >> Here is the proposal: >> ???? https://bugs.openjdk.java.net/browse/JDK-8213161 >> >> Thanks, >> Xuelei > > The new method looks fine. > > On the deprecation, minimally the annotation should contain > the "since" element, which will have a value of `12`. > Hm, it looks better now if using the "since" element. Thanks! > Also, I wonder, now that I see the spec, whether or not it is > actually a good idea to deprecate these methods. The reason > I ask this is that the new method, getSSLSession, can throw > UOE, which effectively makes it an optional method. Access > to the specific security parameters provided by the existing > methods is non-optional. This is a clear difference, and > possibly a reason, for folk not interested in the "new" > parameters, to continue to use the existing methods. > Yes. I had the same concern about the optional operation. However, I came to a different conclusion if I'm from viewpoint of these users that need to use this new operation. If an application have to use this new operation, for example to access the negotiated TLS version, this operation is essential to it. Unfortunately, because of compatibility impact, we cannot force all implementation supports this new added operation. It is a potential problem to those applications that need it. It would be nice if an implementation can support this operation as soon as possible. If we just add the operation, providers may not aware there is a need to update their implementation. Unfortunately. there is not much we can do to notify the provider. If we deprecated the duplicated methods, it is easier for providers to catch up with this new added operation, and move forward to support it. As the deprecating will show up building warnings, or even error if run in strict building mode. To make it more clear, I added a implNote in the getSSLSession() method, and recommend to support it in all implementations. I prefer to deprecate these methods a little bit more, but not very strong. If there is a strong preference, I can live with it. BTW, I also updated the java.net.SecureCacheResponse accordingly. I'm not sure if SecureCacheResponse is really used in practice. I did not find the implementation of it in JDK. Here is the webrev if you want to look at the implementation details: http://cr.openjdk.java.net/~xuelei/8212261/webrev.00/ Thanks, Xuelei From Nico.Williams at twosigma.com Wed Oct 31 21:25:04 2018 From: Nico.Williams at twosigma.com (Nico Williams) Date: Wed, 31 Oct 2018 21:25:04 +0000 Subject: RFR 8212217: JGSS: Don't dispose() of creds too eagerly In-Reply-To: <3A967B4D-BCF7-47E0-AA9C-75111386C3CE@oracle.com> References: <1dc74431-222d-2b83-1e24-3b7839f85a65@oracle.com> <3A967B4D-BCF7-47E0-AA9C-75111386C3CE@oracle.com> Message-ID: <20181031212504.GI26310@twosigma.com> On Wed, Oct 31, 2018 at 05:22:27PM +0800, Weijun Wang wrote: > > On Oct 30, 2018, at 10:28 PM, Sean Mullan wrote: > > > > I think you should put braces around the conditional statements on lines > > 332, 357, & 359. It would read better and avoid accidental bugs. Is that part of a published Java style? (Personally, I dislike braces for single statement blocks. But we'll follow whatever style guide exists.) > > Where does delegatedCred get used? It seems to be never set. > > It's set in a native method Correct. > 322 outToken = cStub.acceptContext(pCred, cb, inToken, this); > > > Otherwise looks fine. You will need to add a noreg label if you can't write a test. > > Yes. Not sure what that means. Nico -- From sean.mullan at oracle.com Wed Oct 31 22:12:06 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 31 Oct 2018 18:12:06 -0400 Subject: RFR 8212217: JGSS: Don't dispose() of creds too eagerly In-Reply-To: <20181031212504.GI26310@twosigma.com> References: <1dc74431-222d-2b83-1e24-3b7839f85a65@oracle.com> <3A967B4D-BCF7-47E0-AA9C-75111386C3CE@oracle.com> <20181031212504.GI26310@twosigma.com> Message-ID: <5039102f-a19a-ff69-9752-fad8fd4c43dc@oracle.com> On 10/31/18 5:25 PM, Nico Williams wrote: >>> I think you should put braces around the conditional statements on lines >>> 332, 357, & 359. It would read better and avoid accidental bugs. > Is that part of a published Java style? > > (Personally, I dislike braces for single statement blocks. But we'll follow > whatever style guide exists.) Mostly for consistency, but it can help avoid accidental bugs where you forget to put the braces in, ex: if (a == true) doThis(); doThat(); It's not yet an official style guide, but here is a draft of the Java style guidelines: http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-braces Of course, not all code in the JDK follows this rule, and I am sure there are personal preferences each way but I think what is worse is when you have a mix of both styles within the same class or package. Other coding guidelines such as from Google [1] also give similar advice. --Sean [1] https://google.github.io/styleguide/javaguide.html#s4.1-braces From dean.long at oracle.com Wed Oct 31 22:23:12 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 15:23:12 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged Message-ID: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8212605 http://cr.openjdk.java.net/~dlong/8212605/webrev.1 This change implements AccessController.doPrivileged in Java.? This gives a performance improvement while also being useful to Project Loom by removing the Java --> native --> Java transition.? One reason doPrivileged has historically been in native is because of the need to guarantee the cleanup of the privileged context when doPrivileged returns.? To do that in Java, the information that AccessController.getContext needs is pushed onto the Java stack as arguments to a method that getContext will recognize during its stack walk.? This allows us to remove the native privileged stack while guaranteeing that the privileged context goes away when the method returns. Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security tests.? For the first few rounds of testing, I kept the old native privileged stack and compared the results of the old and new implementations for each getContext call, which did catch some early bugs.? The changes were also examined by internal security experts and run through additional internal security tests. The improvement on this [1] doPrivileged microbenchmark is approximate 50x. There is no attempt to optimize getContext() or security permission checks in this change, however, this is intended to be a first step towards other possible improvements, for example those proposed here [2]. dl [1] http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java [2] http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html From david.holmes at oracle.com Wed Oct 31 23:06:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Nov 2018 09:06:02 +1000 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> Message-ID: <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> Hi Dean, Looking only at the hotspot changes. The removal of the DoPrivileged and related privileged_stack code seems okay. I have a few related comments: src/hotspot/share/classfile/systemDictionary.hpp You added the java_security_AccessController class after java_security_AccessControlContext. Did you actually verify where in the load/initialization order the AccessController class appears today, and where it appears after your change? (Note the comments at the start of WK_KLASSES_DO). Changes to the initialization order would be my biggest concern with this patch. --- I'm unclear about the change to the test: test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm as it still refers to the now non-existent JVM_DoPrivileged in the summary. Does this test still make sense? Should it be moved to the Java side now it doesn't actually test anything in the VM? --- There may be further dead code to remove now: vmSymbols.hpp: codesource_permissioncollection_signature is now unreferenced and can be removed. javaClasses.*: - java_lang_System::has_security_manager - java_security_AccessControlContext::is_authorized ./share/memory/universe.hpp: static Method* protection_domain_implies_method() --- Thanks, David On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8212605 > http://cr.openjdk.java.net/~dlong/8212605/webrev.1 > > This change implements AccessController.doPrivileged in Java.? This > gives a performance improvement while also being useful to Project Loom > by removing the Java --> native --> Java transition.? One reason > doPrivileged has historically been in native is because of the need to > guarantee the cleanup of the privileged context when doPrivileged > returns.? To do that in Java, the information that > AccessController.getContext needs is pushed onto the Java stack as > arguments to a method that getContext will recognize during its stack > walk.? This allows us to remove the native privileged stack while > guaranteeing that the privileged context goes away when the method returns. > > Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security > tests.? For the first few rounds of testing, I kept the old native > privileged stack and compared the results of the old and new > implementations for each getContext call, which did catch some early > bugs.? The changes were also examined by internal security experts and > run through additional internal security tests. > > The improvement on this [1] doPrivileged microbenchmark is approximate 50x. > > There is no attempt to optimize getContext() or security permission > checks in this change, however, this is intended to be a first step > towards other possible improvements, for example those proposed here [2]. > > dl > > [1] > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html > > From Daniel.Christensen at microfocus.com Mon Oct 8 21:34:07 2018 From: Daniel.Christensen at microfocus.com (Daniel Christensen) Date: Mon, 08 Oct 2018 21:34:07 -0000 Subject: TLSv1.3 fails to read cert chain after HTTP redirect Message-ID: <5BBBCD48020000BE0009B4B0@prvgwdev-52.provo.novell.com> I have a custom HostnameVerifier that attempts to examine the certificate chain using SSLSession#getPeerCertificates(). After upgrading to Java 11, where it seems that TLSv1.3 is used by default, I am seeing that getPeerCertificates() throws an SSLPeerUnverifiedException after an HTTP redirect has occurred. If I force the protocol to TLSv1.2 this does not occur. If there is no redirect, then this does not occur. Is this a bug in Java or a change in behavior with TLSv1.3? The code below demonstrates the problem when 'protocol' is either 'TLS' or 'TLSv1.3' and path is '/redirect'. doTest("TLSv1.3", "/redirect"); // Fails with SSLPeerUnverifiedException doTest("TLSv1.3", "/content"); // Succeeds doTest("TLSv1.2", "/redirect"); // Succeeds doTest("TLSv1.2", "/content"); // Succeeds private void doTest(String protocol, String path) throws IOException, NoSuchAlgorithmException, KeyManagementException { whenHttp(server) .match(get("/redirect")) .then(status(HttpStatus.MOVED_PERMANENTLY_301), contentType("text/html"), header("Location", "/content"), stringContent("redirected")); whenHttp(server) .match(get("/content")) .then(ok(), contentType("text/html"), stringContent("ok")); URL url = new URL("https", "localhost", server.getPort(), path); HttpsURLConnection conn = (HttpsURLConnection)url.openConnection(); SSLContext ctx = SSLContext.getInstance(protocol); TrustManager[] tms = {new X509TrustManager() { @Override public void checkClientTrusted(X509Certificate[] chain, String authType){} @Override public void checkServerTrusted(X509Certificate[] chain, String authType){} @Override public X509Certificate[] getAcceptedIssuers() { return new X509Certificate[0]; } }}; ctx.init(null, tms, new SecureRandom()); conn.setSSLSocketFactory(ctx.getSocketFactory()); conn.setHostnameVerifier(new HostnameVerifier() { @Override public boolean verify(String hostname, SSLSession session) { java.security.cert.Certificate[] chain = null; try { chain = session.getPeerCertificates(); } catch (SSLPeerUnverifiedException e) { throw new RuntimeException(e); } return true; } }); int status = conn.getResponseCode(); assertEquals(200, status); } Thanks, Dan Daniel L. Christensen Distinguished Engineer Micro Focus http://www.microfocus.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Daniel Christensen.vcf Type: application/octet-stream Size: 2640 bytes Desc: not available URL: