From claes.redestad at oracle.com Mon Jan 2 11:45:01 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 Jan 2017 12:45:01 +0100 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: References: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> Message-ID: <52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com> On 12/31/2016 12:45 AM, David Holmes wrote: > I'll let you think about it so more. I'll be back in the office on > Tuesday :) After giving it some thought I think it's better to just document the need for some hygiene in the field declaration: http://cr.openjdk.java.net/~redestad/8172048/webrev.02 Thanks! /Claes From simone.bordet at gmail.com Mon Jan 2 14:24:10 2017 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 2 Jan 2017 15:24:10 +0100 Subject: TLS-PSK status ? Message-ID: Hi, https://bugs.openjdk.java.net/browse/JDK-6476446 is closed as a duplicate of JDK-8049402, but unfortunately this latter issue is not public. Is there any status about the implementation of TLS-PSK (RFC 4279, 4785, 5489) ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From chris.hegarty at oracle.com Mon Jan 2 17:02:17 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 2 Jan 2017 17:02:17 +0000 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: <52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com> References: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> <52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com> Message-ID: <4FD22BA4-B420-49C7-B5DF-2BD414029A5A@oracle.com> > On 2 Jan 2017, at 11:45, Claes Redestad wrote: > > On 12/31/2016 12:45 AM, David Holmes wrote: >> I'll let you think about it so more. I'll be back in the office on Tuesday :) > > After giving it some thought I think it's better to just document the need > for some hygiene in the field declaration: > > http://cr.openjdk.java.net/~redestad/8172048/webrev.02 Looks good Claes. Minor suggestion: "For correctness COMMA care must ?" -Chris. From claes.redestad at oracle.com Mon Jan 2 17:49:02 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 2 Jan 2017 18:49:02 +0100 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: <4FD22BA4-B420-49C7-B5DF-2BD414029A5A@oracle.com> References: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> <52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com> <4FD22BA4-B420-49C7-B5DF-2BD414029A5A@oracle.com> Message-ID: <1d875de3-6b32-4333-e3dc-09719b30402a@oracle.com> On 2017-01-02 18:02, Chris Hegarty wrote: > >> On 2 Jan 2017, at 11:45, Claes Redestad wrote: >> >> On 12/31/2016 12:45 AM, David Holmes wrote: >>> I'll let you think about it so more. I'll be back in the office on Tuesday :) >> >> After giving it some thought I think it's better to just document the need >> for some hygiene in the field declaration: >> >> http://cr.openjdk.java.net/~redestad/8172048/webrev.02 > > Looks good Claes. Thanks, Chris! > > Minor suggestion: "For correctness COMMA care must ?" Done. I won't bother to generate a new webrev for this, though. :-) /Claes From david.holmes at oracle.com Mon Jan 2 23:46:45 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Jan 2017 09:46:45 +1000 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: <52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com> References: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> <52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com> Message-ID: <0824397d-63f8-0f00-55f5-585edbbc2400@oracle.com> On 2/01/2017 9:45 PM, Claes Redestad wrote: > On 12/31/2016 12:45 AM, David Holmes wrote: >> I'll let you think about it so more. I'll be back in the office on >> Tuesday :) > > After giving it some thought I think it's better to just document the need > for some hygiene in the field declaration: > > http://cr.openjdk.java.net/~redestad/8172048/webrev.02 Looks fine to me! Thanks, David > Thanks! > > /Claes From weijun.wang at oracle.com Tue Jan 3 03:30:44 2017 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 3 Jan 2017 11:30:44 +0800 Subject: RFR 8172017: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and rcache_usemd5.sh fail on Solaris (Additional pre-authentication required) In-Reply-To: <57aaff7a-ed0f-2d4d-8b05-100359ba104c@oracle.com> References: <57aaff7a-ed0f-2d4d-8b05-100359ba104c@oracle.com> Message-ID: <81265fdf-dbaf-2f67-92f9-37432f4b51ae@oracle.com> Ping again. On 12/27/2016 3:25 AM, Wang Weijun wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8172017/webrev.00 > > On Solaris when launched by root, the rcache directory is a little > different. > > I've manually tested this on a Solaris machine, and seen rcache > files created at different directories when the test was launched by > root and a normal user. > > Thanks Max From weijun.wang at oracle.com Tue Jan 3 03:31:19 2017 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 3 Jan 2017 11:31:19 +0800 Subject: RFR 8170732: GssKrb5Client sends non-zero buffer size when qop is "auth" In-Reply-To: <4DAED2E1-205B-4F36-B593-FC458876C83D@oracle.com> References: <4DAED2E1-205B-4F36-B593-FC458876C83D@oracle.com> Message-ID: <6cf15a1e-fe1c-7214-2be3-08d9ea356755@oracle.com> Ping again. On 12/22/2016 9:52 AM, Wang Weijun wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8170732/webrev.00/ > > According to https://tools.ietf.org/html/rfc4752#section-3.1: > > The client then constructs data, with the first octet containing the > bit-mask specifying the selected security layer, the second through > fourth octets containing in network byte order the maximum size > output_message the client is able to receive (which MUST be 0 if the > client does not support any security layer), > > A test is modified to check this case. Please note that when there is > no security layer, you cannot call wrap/unwrap anymore. > > Thanks Max > From weijun.wang at oracle.com Tue Jan 3 03:42:27 2017 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 3 Jan 2017 11:42:27 +0800 Subject: RFR 8157389: Release Note: New default -sigalg for jarsigner and keytool In-Reply-To: <328FBA04-5369-49D7-A715-370121A5E0C0@oracle.com> References: <328FBA04-5369-49D7-A715-370121A5E0C0@oracle.com> Message-ID: <30176C1C-060C-4B37-8CF4-7951670A8453@oracle.com> Ping again. Please review https://bugs.openjdk.java.net/browse/JDK-8157389. JDK-8171190 was already resolved. Thanks Max > On Dec 14, 2016, at 10:04 AM, Wang Weijun wrote: > > I copied the exact @implNote from JarSigner into the release note. > > BTW, I noticed NIST 800-57 Part 1 has a new revision 4, which has the same tables as in revision 3. A new bug https://bugs.openjdk.java.net/browse/JDK-8171190 created and I'll create a webrev soon. > > Thanks > Max > >> On Dec 14, 2016, at 5:09 AM, Sean Mullan wrote: >> >> Hi Max, >> >> Could you include more information that shows what signature algorithm is used based on the key size range and algorithm? >> >> --Sean >> >> On 12/11/16 9:53 PM, Wang Weijun wrote: >>> Please take a review at the release note at >>> >>> https://bugs.openjdk.java.net/browse/JDK-8157389 >>> >>> Thanks >>> Max >>> > From sean.mullan at oracle.com Tue Jan 3 15:49:43 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 3 Jan 2017 10:49:43 -0500 Subject: RFR 8157389: Release Note: New default -sigalg for jarsigner and keytool In-Reply-To: <30176C1C-060C-4B37-8CF4-7951670A8453@oracle.com> References: <328FBA04-5369-49D7-A715-370121A5E0C0@oracle.com> <30176C1C-060C-4B37-8CF4-7951670A8453@oracle.com> Message-ID: On 1/2/17 10:42 PM, Wang Weijun wrote: > Ping again. Please review https://bugs.openjdk.java.net/browse/JDK-8157389. Looks good. Is there also a docs issue for jarsigner and keytool to add this information to the man pages/tool docs? Please link it to this issue. --Sean > > JDK-8171190 was already resolved. > > Thanks > Max > >> On Dec 14, 2016, at 10:04 AM, Wang Weijun wrote: >> >> I copied the exact @implNote from JarSigner into the release note. >> >> BTW, I noticed NIST 800-57 Part 1 has a new revision 4, which has the same tables as in revision 3. A new bug https://bugs.openjdk.java.net/browse/JDK-8171190 created and I'll create a webrev soon. >> >> Thanks >> Max >> >>> On Dec 14, 2016, at 5:09 AM, Sean Mullan wrote: >>> >>> Hi Max, >>> >>> Could you include more information that shows what signature algorithm is used based on the key size range and algorithm? >>> >>> --Sean >>> >>> On 12/11/16 9:53 PM, Wang Weijun wrote: >>>> Please take a review at the release note at >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8157389 >>>> >>>> Thanks >>>> Max >>>> >> > From sean.mullan at oracle.com Tue Jan 3 16:14:05 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 3 Jan 2017 11:14:05 -0500 Subject: RFR 8172017: Two tests sun/security/krb5/auto/ReplayCacheTestProc.java and rcache_usemd5.sh fail on Solaris (Additional pre-authentication required) In-Reply-To: <81265fdf-dbaf-2f67-92f9-37432f4b51ae@oracle.com> References: <57aaff7a-ed0f-2d4d-8b05-100359ba104c@oracle.com> <81265fdf-dbaf-2f67-92f9-37432f4b51ae@oracle.com> Message-ID: <3a006764-05bd-e601-7a77-b0f5865d85ad@oracle.com> On 1/2/17 10:30 PM, Wang Weijun wrote: > Ping again. Looks ok to me. --Sean > > On 12/27/2016 3:25 AM, Wang Weijun wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8172017/webrev.00 >> >> On Solaris when launched by root, the rcache directory is a little >> different. >> >> I've manually tested this on a Solaris machine, and seen rcache >> files created at different directories when the test was launched by >> root and a normal user. >> >> Thanks Max From xuelei.fan at oracle.com Tue Jan 3 17:50:43 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 3 Jan 2017 09:50:43 -0800 Subject: TLS-PSK status ? In-Reply-To: References: Message-ID: <8d489db4-6451-5713-1592-d13152714ea6@oracle.com> Now JDK-8049402 is public. https://bugs.openjdk.java.net/browse/JDK-8049402 Thanks, Xuelei On 1/2/2017 6:24 AM, Simone Bordet wrote: > Hi, > > https://bugs.openjdk.java.net/browse/JDK-6476446 > > is closed as a duplicate of JDK-8049402, but unfortunately this latter > issue is not public. > > Is there any status about the implementation of TLS-PSK (RFC 4279, 4785, 5489) ? > > Thanks ! > From adam.petcher at oracle.com Tue Jan 3 18:51:14 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 3 Jan 2017 13:51:14 -0500 Subject: RFR 8172003: getInstance() with unknown provider throws NPE Message-ID: Please review the following: http://cr.openjdk.java.net/~apetcher/8172003/webrev.00/ This is a small conformance fix. Some XML crypto classes are throwing an NPE instead of NoSuchProviderException when the provider is not found. From sean.mullan at oracle.com Tue Jan 3 21:00:07 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 3 Jan 2017 16:00:07 -0500 Subject: RFR 8172003: getInstance() with unknown provider throws NPE In-Reply-To: References: Message-ID: <6c1b6a5d-db6f-4ef3-4e7b-687a9681b517@oracle.com> Looks good to me. --Sean On 1/3/17 1:51 PM, Adam Petcher wrote: > Please review the following: > > http://cr.openjdk.java.net/~apetcher/8172003/webrev.00/ > > This is a small conformance fix. Some XML crypto classes are throwing an > NPE instead of NoSuchProviderException when the provider is not found. > From simone.bordet at gmail.com Tue Jan 3 22:31:12 2017 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 3 Jan 2017 23:31:12 +0100 Subject: TLS-PSK status ? In-Reply-To: <8d489db4-6451-5713-1592-d13152714ea6@oracle.com> References: <8d489db4-6451-5713-1592-d13152714ea6@oracle.com> Message-ID: Hi, On Tue, Jan 3, 2017 at 6:50 PM, Xuelei Fan wrote: > Now JDK-8049402 is public. > > https://bugs.openjdk.java.net/browse/JDK-8049402 Thanks ! The issue is marked as "fix for 10", so is it correct to assume that nothing will be done in time for JDK 9 or even 8 (via backport) ? It is just to know and to respond to people that asked about supporting TLS-PSK support. Thanks again ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Tue Jan 3 22:56:34 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 3 Jan 2017 14:56:34 -0800 Subject: RFR 8170732: GssKrb5Client sends non-zero buffer size when qop is "auth" In-Reply-To: <6cf15a1e-fe1c-7214-2be3-08d9ea356755@oracle.com> References: <4DAED2E1-205B-4F36-B593-FC458876C83D@oracle.com> <6cf15a1e-fe1c-7214-2be3-08d9ea356755@oracle.com> Message-ID: <17352bf2-b5a4-4a4e-0adb-9ed242407969@oracle.com> Would you mind add a comment about this MUST-BE-ZERO behavior? Otherwise, looks fine to me. Xuelei On 1/2/2017 7:31 PM, Wang Weijun wrote: > Ping again. > > On 12/22/2016 9:52 AM, Wang Weijun wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8170732/webrev.00/ >> >> According to https://tools.ietf.org/html/rfc4752#section-3.1: >> >> The client then constructs data, with the first octet containing the >> bit-mask specifying the selected security layer, the second through >> fourth octets containing in network byte order the maximum size >> output_message the client is able to receive (which MUST be 0 if the >> client does not support any security layer), >> >> A test is modified to check this case. Please note that when there is >> no security layer, you cannot call wrap/unwrap anymore. >> >> Thanks Max >> From xuelei.fan at oracle.com Tue Jan 3 23:23:37 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 3 Jan 2017 15:23:37 -0800 Subject: Code Review Request JDK-8172217, Need debug log for the intermittent failure of AnonCipherWithWantClientAuth Message-ID: <274bd11d-c1a4-f288-c114-b814db1a5abb@oracle.com> Hi, The intermittent test failure of test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java was fond again. However, the underlying reason is still not clear. Need to dump more debug log for further evaluation. https://bugs.openjdk.java.net/browse/JDK-8172217 $ hg diff AnonCipherWithWantClientAuth.java - * @run main/othervm AnonCipherWithWantClientAuth + * @run main/othervm -Djavax.net.debug=all AnonCipherWithWantClientAuth Thanks, Xuelei From weijun.wang at oracle.com Tue Jan 3 23:54:40 2017 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 4 Jan 2017 07:54:40 +0800 Subject: Code Review Request JDK-8172217, Need debug log for the intermittent failure of AnonCipherWithWantClientAuth In-Reply-To: <274bd11d-c1a4-f288-c114-b814db1a5abb@oracle.com> References: <274bd11d-c1a4-f288-c114-b814db1a5abb@oracle.com> Message-ID: <7FFDCA9E-972B-4DD2-8208-2BF966869764@oracle.com> This looks good. On the other hand, it might be better to add exception stack trace or links to failures to the bug report. Maybe you think they are too useless? Thanks Max > On Jan 4, 2017, at 7:23 AM, Xuelei Fan wrote: > > Hi, > > The intermittent test failure of test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java was fond again. However, the underlying reason is still not clear. Need to dump more debug log for further evaluation. > > https://bugs.openjdk.java.net/browse/JDK-8172217 > > $ hg diff AnonCipherWithWantClientAuth.java > > - * @run main/othervm AnonCipherWithWantClientAuth > + * @run main/othervm -Djavax.net.debug=all AnonCipherWithWantClientAuth > > Thanks, > Xuelei From xuelei.fan at oracle.com Tue Jan 3 23:59:23 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 3 Jan 2017 15:59:23 -0800 Subject: Code Review Request JDK-8172217, Need debug log for the intermittent failure of AnonCipherWithWantClientAuth In-Reply-To: <7FFDCA9E-972B-4DD2-8208-2BF966869764@oracle.com> References: <274bd11d-c1a4-f288-c114-b814db1a5abb@oracle.com> <7FFDCA9E-972B-4DD2-8208-2BF966869764@oracle.com> Message-ID: On 1/3/2017 3:54 PM, Wang Weijun wrote: > This looks good. > > On the other hand, it might be better to add exception stack trace or links to failures to the bug report. Maybe you think they are too useless? > As this is a sub-tack of JDK-8172005: https://bugs.openjdk.java.net/browse/JDK-8172005 It's always good to add more details in the bug report. I just added the exception stack. Thanks, Xuelei > Thanks > Max > >> On Jan 4, 2017, at 7:23 AM, Xuelei Fan wrote: >> >> Hi, >> >> The intermittent test failure of test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java was fond again. However, the underlying reason is still not clear. Need to dump more debug log for further evaluation. >> >> https://bugs.openjdk.java.net/browse/JDK-8172217 >> >> $ hg diff AnonCipherWithWantClientAuth.java >> >> - * @run main/othervm AnonCipherWithWantClientAuth >> + * @run main/othervm -Djavax.net.debug=all AnonCipherWithWantClientAuth >> >> Thanks, >> Xuelei > From xuelei.fan at oracle.com Wed Jan 4 00:26:53 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 3 Jan 2017 16:26:53 -0800 Subject: TLS-PSK status ? In-Reply-To: References: <8d489db4-6451-5713-1592-d13152714ea6@oracle.com> Message-ID: <69cee1ca-771f-b72b-bf9b-440c1dcc3a7d@oracle.com> Hi Simone, We will integrate into JDK 10 at first. And the decision to backport to 9 or 8 will be made later. Thanks, Xuelei On 1/3/2017 2:31 PM, Simone Bordet wrote: > Hi, > > On Tue, Jan 3, 2017 at 6:50 PM, Xuelei Fan wrote: >> Now JDK-8049402 is public. >> >> https://bugs.openjdk.java.net/browse/JDK-8049402 > > Thanks ! > > The issue is marked as "fix for 10", so is it correct to assume that > nothing will be done in time for JDK 9 or even 8 (via backport) ? > It is just to know and to respond to people that asked about > supporting TLS-PSK support. > > Thanks again ! > From weijun.wang at oracle.com Wed Jan 4 00:51:53 2017 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 4 Jan 2017 08:51:53 +0800 Subject: Code Review Request JDK-8172217, Need debug log for the intermittent failure of AnonCipherWithWantClientAuth In-Reply-To: References: <274bd11d-c1a4-f288-c114-b814db1a5abb@oracle.com> <7FFDCA9E-972B-4DD2-8208-2BF966869764@oracle.com> Message-ID: <879a6777-cae2-9650-4f91-9419b0c2be25@oracle.com> Sorry, I didn't notice it. --Max On 1/4/2017 7:59 AM, Xuelei Fan wrote: > > > On 1/3/2017 3:54 PM, Wang Weijun wrote: >> This looks good. >> >> On the other hand, it might be better to add exception stack trace or >> links to failures to the bug report. Maybe you think they are too >> useless? >> > As this is a sub-tack of JDK-8172005: > https://bugs.openjdk.java.net/browse/JDK-8172005 > > It's always good to add more details in the bug report. I just added > the exception stack. > > Thanks, > Xuelei > >> Thanks >> Max >> >>> On Jan 4, 2017, at 7:23 AM, Xuelei Fan wrote: >>> >>> Hi, >>> >>> The intermittent test failure of >>> test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java >>> was fond again. However, the underlying reason is still not clear. >>> Need to dump more debug log for further evaluation. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8172217 >>> >>> $ hg diff AnonCipherWithWantClientAuth.java >>> >>> - * @run main/othervm AnonCipherWithWantClientAuth >>> + * @run main/othervm -Djavax.net.debug=all AnonCipherWithWantClientAuth >>> >>> Thanks, >>> Xuelei >> From bradford.wetmore at oracle.com Wed Jan 4 01:06:07 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 3 Jan 2017 17:06:07 -0800 Subject: Code Review Request JDK-8172217, Need debug log for the intermittent failure of AnonCipherWithWantClientAuth In-Reply-To: <879a6777-cae2-9650-4f91-9419b0c2be25@oracle.com> References: <274bd11d-c1a4-f288-c114-b814db1a5abb@oracle.com> <7FFDCA9E-972B-4DD2-8208-2BF966869764@oracle.com> <879a6777-cae2-9650-4f91-9419b0c2be25@oracle.com> Message-ID: Looks good, thanks. Brad On 1/3/2017 4:51 PM, Wang Weijun wrote: > Sorry, I didn't notice it. > > --Max > > On 1/4/2017 7:59 AM, Xuelei Fan wrote: >> >> >> On 1/3/2017 3:54 PM, Wang Weijun wrote: >>> This looks good. >>> >>> On the other hand, it might be better to add exception stack trace or >>> links to failures to the bug report. Maybe you think they are too >>> useless? >>> >> As this is a sub-tack of JDK-8172005: >> https://bugs.openjdk.java.net/browse/JDK-8172005 >> >> It's always good to add more details in the bug report. I just added >> the exception stack. >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>>> On Jan 4, 2017, at 7:23 AM, Xuelei Fan wrote: >>>> >>>> Hi, >>>> >>>> The intermittent test failure of >>>> test/sun/security/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java >>>> >>>> was fond again. However, the underlying reason is still not clear. >>>> Need to dump more debug log for further evaluation. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8172217 >>>> >>>> $ hg diff AnonCipherWithWantClientAuth.java >>>> >>>> - * @run main/othervm AnonCipherWithWantClientAuth >>>> + * @run main/othervm -Djavax.net.debug=all >>>> AnonCipherWithWantClientAuth >>>> >>>> Thanks, >>>> Xuelei >>> From nikita.j.jain at oracle.com Wed Jan 4 07:02:04 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Tue, 3 Jan 2017 23:02:04 -0800 (PST) Subject: [8u] RFA for backport of JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed In-Reply-To: <7030bf10-d252-4652-ab4f-ea89a694b4c4@default> References: <29d048f7-42f5-4607-a78e-4cd4b76f8146@default> <7030bf10-d252-4652-ab4f-ea89a694b4c4@default> Message-ID: Sorry, I made a mistake. The trivial backport requires a code review. JDK8 webrev link is mentioned in previous mail. The changeset didn't apply cleanly. I had edited it manually, since it was just removing the test entries from the ProblemList.txt. From: Nikita Jain Sent: Wednesday, January 4, 2017 10:41 AM To: jdk8u-dev at openjdk.java.net Subject: [8u] RFA for backport of JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed Hi All, I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8157665 Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/dc99fd161d90 Public review: http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014077.html JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/8157665/webrev.00/ Tested with jprt. Would you please help with approval of the backport? Thanks in advance, Nikita -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Jan 4 11:14:35 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 4 Jan 2017 11:14:35 +0000 Subject: [8u] RFA for backport of JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed In-Reply-To: References: <29d048f7-42f5-4607-a78e-4cd4b76f8146@default> <7030bf10-d252-4652-ab4f-ea89a694b4c4@default> Message-ID: <586CD91B.3040802@oracle.com> The changes look fine. Please ensure that the tests pass on JPRT solaris platforms before pushing. Approved. Regards, Sean. On 04/01/17 07:02, Nikita Jain wrote: > Sorry, I made a mistake. The trivial backport requires a code review. JDK8 webrev link is mentioned in previous mail. > > > > The changeset didn't apply cleanly. I had edited it manually, since it was just removing the test entries from the ProblemList.txt. > > > > From: Nikita Jain > Sent: Wednesday, January 4, 2017 10:41 AM > To: jdk8u-dev at openjdk.java.net > Subject: [8u] RFA for backport of JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed > > > > Hi All, > > > > I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157665 > > Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/dc99fd161d90 > > Public review: http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014077.html > > JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/8157665/webrev.00/ > > > > > > Tested with jprt. Would you please help with approval of the backport? > > > > Thanks in advance, > > Nikita > > > > > > From xuelei.fan at oracle.com Wed Jan 4 18:38:06 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 4 Jan 2017 10:38:06 -0800 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: <93dffa6c-9815-e580-73ad-50b03c425a7d@oracle.com> References: <7aa674d4-8384-54b2-ffc0-6c06db8974da@oracle.com> <93dffa6c-9815-e580-73ad-50b03c425a7d@oracle.com> Message-ID: Updated to use synchronized method. Most of the time, the synchronized only perform the read access to the variables. The impact on performance should be acceptable. http://cr.openjdk.java.net/~xuelei/8129988/webrev.03/ Only the TrustStoreManager.java implementation get updated in this webrev. Thanks, Xuelei On 12/23/2016 7:52 AM, Sean Mullan wrote: > On 12/22/16 2:52 PM, Xuelei Fan wrote: >> updated: http://cr.openjdk.java.net/~xuelei/8129988/webrev.02/ > > I think there are still some race conditions. For example: > > 264 TrustStoreDescriptor temporaryDesc = this.descriptor; > 265 KeyStore cachedKeyStore = ksRef.get(); > 266 if (descriptor.equals(temporaryDesc) && (cachedKeyStore > != null)) { > 267 return cachedKeyStore; > 268 } > > There is no locking here. > > Maybe that's ok based on your explanation below, but it seems a bit > fragile and could lead to problems that are hard to debug. Have you > looked at the AtomicReference class? You could define a new class > containing the descriptor, keystore, and certs and wrap that in an > AtomicReference and then use the methods on that class to update it. > Might be worth exploring that a bit more. > > --Sean > > >> On 12/22/2016 9:32 AM, Sean Mullan wrote: >>> On 12/20/16 3:21 PM, Xuelei Fan wrote: >>> >>>>> 213 if (storePassword != null && >>>>> !storePassword.isEmpty()) { >>>>> 214 MessageDigest md = >>>>> JsseJce.getMessageDigest("SHA-256"); >>>>> 215 result = 31 * result + >>>>> 216 Arrays.hashCode(md.digest(storePassword.getBytes())); >>>>> 217 } >>>>> >>>>> Why are you hashing the password here? Are you afraid this could be >>>>> leaked or guessed somehow? >>>> Yes. The hash code of the password part can be computed. I was >>>> wondering the String.hashCode() may not have sufficient strength. >>>> >>>>> I would just leave the password out of the >>>>> hashcode and equals. It doesn't matter, it's still the same file, >>>>> right? >>>>> I'm not sure if the type or provider matter either. Don't you just >>>>> care >>>>> about the name of the file and the modification time? >>>>> >>>> For file type key store, the file and the modification time should be >>>> sufficient. But for non-file (PKCS11) key store, the provider and >>>> password may be sensible. The basic idea is that, if one of the system >>>> property get updated, the key store should be reloaded. Checking every >>>> property update makes the code more straightforward. >>> >>> But the main focus of this performance issue is for the cacerts file, >>> which is not PKCS11. So I would not use the password and other >>> non-relevant or security-sensitive attributes. A hash of the password >>> isn't sufficient against dictionary-type attacks, for example. >>> >> I see your point. The password hash code block is removed. >> >>>>> 268 if ((temporaryDesc != null) && >>>>> >>>>> Why would a null descriptor ever be ok? Shouldn't you just let this >>>>> throw NPE? Same comment on line 301. >>>>> >>>> The temporaryDesc is initialized as null. A singleton service >>>> (TrustStoreManage.tam) is used and lazy loaded. Null means the >>>> descriptor has not been assigned. >>> >>> I think there are thread-safeness issues in the TrustStoreManager class. >>> You are not synchronizing when you read so looks like there can be >>> various race conditions. For example, this.descriptor and this.ksRef can >>> be updated by another thread in the middle of this code >>> >>> 267 TrustStoreDescriptor temporaryDesc = this.descriptor; >>> 268 if ((temporaryDesc != null) && >>> 269 temporaryDesc.equals(descriptor)) { >>> 270 KeyStore ks = ksRef.get(); >>> 271 if (ks != null) { >>> 272 return ks; >>> 273 } >>> 274 } >>> >>> Maybe that doesn't really matter, but I'm not sure -- have you thought >>> about it? >>> >> I thought about the issue. But I really missed to the double check >> idiom. Updated. >> >> For performance consideration, I'm trying to mitigate the impact of >> synchronization. Once the key store get loaded, there is a strong >> reference, and it can be used safely. If another thread is trying to >> modify the descriptor and key store, this thread will use the existing >> key store, and another thread can use the new key store. If two threads >> try to modify the key store for the same descriptor, I added the double >> check idiom so that the first thread will complete the update and the >> 2nd thread will use the 1st thread updated key store. If two threads >> try to modify the key store for different descriptor, each will get a >> different key store and the 2nd thread will reset the final key store >> for future use. >> >> In general, applications would not modify the system properties. So the >> use of the synchronized block should be very rare. It benefits the >> performance in multiple threading computation environment. >> >> Xuelei >> >>> --Sean From sean.mullan at oracle.com Wed Jan 4 21:27:15 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 4 Jan 2017 16:27:15 -0500 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: References: <7aa674d4-8384-54b2-ffc0-6c06db8974da@oracle.com> <93dffa6c-9815-e580-73ad-50b03c425a7d@oracle.com> Message-ID: <3f7d53f0-1600-61af-b64d-7f7ddb50de3a@oracle.com> It's unfortunate that the previous code read the system properties each time a TrustManagerFactory was initialized. I think in practice, if applications are changing these system properties on the fly it isn't going to work predictably. This implementation would have been much simpler if the properties were read once, and then you could just check the lastModified time. But, I suppose we should err on the side of caution and maintain that behavior. A few comments: 160 // Not break, the file is inaccessbile. Typo: inaccessible 191 Objects.equals(this.storePassword, that.storePassword)); Let's avoid this. I don't think it's possible for an app to leverage this to try to guess the password, but let's err on the side of caution. If the password has changed, then the file's lastModified time would need to be updated anyway, so you don't really need to check this. 326 this.ksRef = new WeakReference<>(ks); ks is a local variable that goes out of scope when this method is finished, so I don't think this will work as you expect. --Sean On 1/4/17 1:38 PM, Xuelei Fan wrote: > Updated to use synchronized method. Most of the time, the synchronized > only perform the read access to the variables. The impact on performance > should be acceptable. > > http://cr.openjdk.java.net/~xuelei/8129988/webrev.03/ > > Only the TrustStoreManager.java implementation get updated in this webrev. > > Thanks, > Xuelei > > On 12/23/2016 7:52 AM, Sean Mullan wrote: >> On 12/22/16 2:52 PM, Xuelei Fan wrote: >>> updated: http://cr.openjdk.java.net/~xuelei/8129988/webrev.02/ >> >> I think there are still some race conditions. For example: >> >> 264 TrustStoreDescriptor temporaryDesc = this.descriptor; >> 265 KeyStore cachedKeyStore = ksRef.get(); >> 266 if (descriptor.equals(temporaryDesc) && (cachedKeyStore >> != null)) { >> 267 return cachedKeyStore; >> 268 } >> >> There is no locking here. >> >> Maybe that's ok based on your explanation below, but it seems a bit >> fragile and could lead to problems that are hard to debug. Have you >> looked at the AtomicReference class? You could define a new class >> containing the descriptor, keystore, and certs and wrap that in an >> AtomicReference and then use the methods on that class to update it. >> Might be worth exploring that a bit more. >> >> --Sean >> >> >>> On 12/22/2016 9:32 AM, Sean Mullan wrote: >>>> On 12/20/16 3:21 PM, Xuelei Fan wrote: >>>> >>>>>> 213 if (storePassword != null && >>>>>> !storePassword.isEmpty()) { >>>>>> 214 MessageDigest md = >>>>>> JsseJce.getMessageDigest("SHA-256"); >>>>>> 215 result = 31 * result + >>>>>> 216 Arrays.hashCode(md.digest(storePassword.getBytes())); >>>>>> 217 } >>>>>> >>>>>> Why are you hashing the password here? Are you afraid this could be >>>>>> leaked or guessed somehow? >>>>> Yes. The hash code of the password part can be computed. I was >>>>> wondering the String.hashCode() may not have sufficient strength. >>>>> >>>>>> I would just leave the password out of the >>>>>> hashcode and equals. It doesn't matter, it's still the same file, >>>>>> right? >>>>>> I'm not sure if the type or provider matter either. Don't you just >>>>>> care >>>>>> about the name of the file and the modification time? >>>>>> >>>>> For file type key store, the file and the modification time should be >>>>> sufficient. But for non-file (PKCS11) key store, the provider and >>>>> password may be sensible. The basic idea is that, if one of the >>>>> system >>>>> property get updated, the key store should be reloaded. Checking >>>>> every >>>>> property update makes the code more straightforward. >>>> >>>> But the main focus of this performance issue is for the cacerts file, >>>> which is not PKCS11. So I would not use the password and other >>>> non-relevant or security-sensitive attributes. A hash of the password >>>> isn't sufficient against dictionary-type attacks, for example. >>>> >>> I see your point. The password hash code block is removed. >>> >>>>>> 268 if ((temporaryDesc != null) && >>>>>> >>>>>> Why would a null descriptor ever be ok? Shouldn't you just let this >>>>>> throw NPE? Same comment on line 301. >>>>>> >>>>> The temporaryDesc is initialized as null. A singleton service >>>>> (TrustStoreManage.tam) is used and lazy loaded. Null means the >>>>> descriptor has not been assigned. >>>> >>>> I think there are thread-safeness issues in the TrustStoreManager >>>> class. >>>> You are not synchronizing when you read so looks like there can be >>>> various race conditions. For example, this.descriptor and this.ksRef >>>> can >>>> be updated by another thread in the middle of this code >>>> >>>> 267 TrustStoreDescriptor temporaryDesc = this.descriptor; >>>> 268 if ((temporaryDesc != null) && >>>> 269 temporaryDesc.equals(descriptor)) { >>>> 270 KeyStore ks = ksRef.get(); >>>> 271 if (ks != null) { >>>> 272 return ks; >>>> 273 } >>>> 274 } >>>> >>>> Maybe that doesn't really matter, but I'm not sure -- have you thought >>>> about it? >>>> >>> I thought about the issue. But I really missed to the double check >>> idiom. Updated. >>> >>> For performance consideration, I'm trying to mitigate the impact of >>> synchronization. Once the key store get loaded, there is a strong >>> reference, and it can be used safely. If another thread is trying to >>> modify the descriptor and key store, this thread will use the existing >>> key store, and another thread can use the new key store. If two threads >>> try to modify the key store for the same descriptor, I added the double >>> check idiom so that the first thread will complete the update and the >>> 2nd thread will use the 1st thread updated key store. If two threads >>> try to modify the key store for different descriptor, each will get a >>> different key store and the 2nd thread will reset the final key store >>> for future use. >>> >>> In general, applications would not modify the system properties. So the >>> use of the synchronized block should be very rare. It benefits the >>> performance in multiple threading computation environment. >>> >>> Xuelei >>> >>>> --Sean From xuelei.fan at oracle.com Thu Jan 5 01:17:57 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 4 Jan 2017 17:17:57 -0800 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: <3f7d53f0-1600-61af-b64d-7f7ddb50de3a@oracle.com> References: <7aa674d4-8384-54b2-ffc0-6c06db8974da@oracle.com> <93dffa6c-9815-e580-73ad-50b03c425a7d@oracle.com> <3f7d53f0-1600-61af-b64d-7f7ddb50de3a@oracle.com> Message-ID: <76d3ba7e-9ede-f597-392f-d91c26e078c7@oracle.com> New webrev: http://cr.openjdk.java.net/~xuelei/8129988/webrev.04/ On 1/4/2017 1:27 PM, Sean Mullan wrote: > It's unfortunate that the previous code read the system properties each > time a TrustManagerFactory was initialized. I think in practice, if > applications are changing these system properties on the fly it isn't > going to work predictably. This implementation would have been much > simpler if the properties were read once, and then you could just check > the lastModified time. > > But, I suppose we should err on the side of caution and maintain that > behavior. > I don't like the old behavior, which is error-prone. But for safe we may want to keep the behavior unchanged at this stage. > A few comments: > > 160 // Not break, the file is inaccessbile. > > Typo: inaccessible > > 191 Objects.equals(this.storePassword, > that.storePassword)); > > Let's avoid this. I don't think it's possible for an app to leverage > this to try to guess the password, but let's err on the side of caution. > If the password has changed, then the file's lastModified time would > need to be updated anyway, so you don't really need to check this. > Good. Updated. > 326 this.ksRef = new WeakReference<>(ks); > > ks is a local variable that goes out of scope when this method is > finished, so I don't think this will work as you expect. > Good catch! I made an update that the local key store reference will not reserved any more. Thanks, Xuelei > --Sean > > > On 1/4/17 1:38 PM, Xuelei Fan wrote: >> Updated to use synchronized method. Most of the time, the synchronized >> only perform the read access to the variables. The impact on performance >> should be acceptable. >> >> http://cr.openjdk.java.net/~xuelei/8129988/webrev.03/ >> >> Only the TrustStoreManager.java implementation get updated in this >> webrev. >> >> Thanks, >> Xuelei >> >> On 12/23/2016 7:52 AM, Sean Mullan wrote: >>> On 12/22/16 2:52 PM, Xuelei Fan wrote: >>>> updated: http://cr.openjdk.java.net/~xuelei/8129988/webrev.02/ >>> >>> I think there are still some race conditions. For example: >>> >>> 264 TrustStoreDescriptor temporaryDesc = this.descriptor; >>> 265 KeyStore cachedKeyStore = ksRef.get(); >>> 266 if (descriptor.equals(temporaryDesc) && (cachedKeyStore >>> != null)) { >>> 267 return cachedKeyStore; >>> 268 } >>> >>> There is no locking here. >>> >>> Maybe that's ok based on your explanation below, but it seems a bit >>> fragile and could lead to problems that are hard to debug. Have you >>> looked at the AtomicReference class? You could define a new class >>> containing the descriptor, keystore, and certs and wrap that in an >>> AtomicReference and then use the methods on that class to update it. >>> Might be worth exploring that a bit more. >>> >>> --Sean >>> >>> >>>> On 12/22/2016 9:32 AM, Sean Mullan wrote: >>>>> On 12/20/16 3:21 PM, Xuelei Fan wrote: >>>>> >>>>>>> 213 if (storePassword != null && >>>>>>> !storePassword.isEmpty()) { >>>>>>> 214 MessageDigest md = >>>>>>> JsseJce.getMessageDigest("SHA-256"); >>>>>>> 215 result = 31 * result + >>>>>>> 216 Arrays.hashCode(md.digest(storePassword.getBytes())); >>>>>>> 217 } >>>>>>> >>>>>>> Why are you hashing the password here? Are you afraid this could be >>>>>>> leaked or guessed somehow? >>>>>> Yes. The hash code of the password part can be computed. I was >>>>>> wondering the String.hashCode() may not have sufficient strength. >>>>>> >>>>>>> I would just leave the password out of the >>>>>>> hashcode and equals. It doesn't matter, it's still the same file, >>>>>>> right? >>>>>>> I'm not sure if the type or provider matter either. Don't you just >>>>>>> care >>>>>>> about the name of the file and the modification time? >>>>>>> >>>>>> For file type key store, the file and the modification time should be >>>>>> sufficient. But for non-file (PKCS11) key store, the provider and >>>>>> password may be sensible. The basic idea is that, if one of the >>>>>> system >>>>>> property get updated, the key store should be reloaded. Checking >>>>>> every >>>>>> property update makes the code more straightforward. >>>>> >>>>> But the main focus of this performance issue is for the cacerts file, >>>>> which is not PKCS11. So I would not use the password and other >>>>> non-relevant or security-sensitive attributes. A hash of the password >>>>> isn't sufficient against dictionary-type attacks, for example. >>>>> >>>> I see your point. The password hash code block is removed. >>>> >>>>>>> 268 if ((temporaryDesc != null) && >>>>>>> >>>>>>> Why would a null descriptor ever be ok? Shouldn't you just let this >>>>>>> throw NPE? Same comment on line 301. >>>>>>> >>>>>> The temporaryDesc is initialized as null. A singleton service >>>>>> (TrustStoreManage.tam) is used and lazy loaded. Null means the >>>>>> descriptor has not been assigned. >>>>> >>>>> I think there are thread-safeness issues in the TrustStoreManager >>>>> class. >>>>> You are not synchronizing when you read so looks like there can be >>>>> various race conditions. For example, this.descriptor and this.ksRef >>>>> can >>>>> be updated by another thread in the middle of this code >>>>> >>>>> 267 TrustStoreDescriptor temporaryDesc = this.descriptor; >>>>> 268 if ((temporaryDesc != null) && >>>>> 269 temporaryDesc.equals(descriptor)) { >>>>> 270 KeyStore ks = ksRef.get(); >>>>> 271 if (ks != null) { >>>>> 272 return ks; >>>>> 273 } >>>>> 274 } >>>>> >>>>> Maybe that doesn't really matter, but I'm not sure -- have you thought >>>>> about it? >>>>> >>>> I thought about the issue. But I really missed to the double check >>>> idiom. Updated. >>>> >>>> For performance consideration, I'm trying to mitigate the impact of >>>> synchronization. Once the key store get loaded, there is a strong >>>> reference, and it can be used safely. If another thread is trying to >>>> modify the descriptor and key store, this thread will use the existing >>>> key store, and another thread can use the new key store. If two >>>> threads >>>> try to modify the key store for the same descriptor, I added the double >>>> check idiom so that the first thread will complete the update and the >>>> 2nd thread will use the 1st thread updated key store. If two threads >>>> try to modify the key store for different descriptor, each will get a >>>> different key store and the 2nd thread will reset the final key store >>>> for future use. >>>> >>>> In general, applications would not modify the system properties. So >>>> the >>>> use of the synchronized block should be very rare. It benefits the >>>> performance in multiple threading computation environment. >>>> >>>> Xuelei >>>> >>>>> --Sean From sean.mullan at oracle.com Thu Jan 5 16:13:48 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 05 Jan 2017 11:13:48 -0500 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: <76d3ba7e-9ede-f597-392f-d91c26e078c7@oracle.com> References: <7aa674d4-8384-54b2-ffc0-6c06db8974da@oracle.com> <93dffa6c-9815-e580-73ad-50b03c425a7d@oracle.com> <3f7d53f0-1600-61af-b64d-7f7ddb50de3a@oracle.com> <76d3ba7e-9ede-f597-392f-d91c26e078c7@oracle.com> Message-ID: <586E70BC.5090601@oracle.com> 265 if (descriptor.equals(temporaryDesc) && (ks != null)) { Not sure if JVM will optimize this, but probably better to check if ks != null first, and avoid calling equals unless necessary: 265 if (ks != null && descriptor.equals(temporaryDesc)) { Also, similar comment for getTrustedCerts -- you should first check if csRef.get() is null. If it is null, then you don't have to check the TrustStoreDescriptor, you can go straight to reloading the keystore and getting the certs. No other comments. --Sean On 1/4/2017 8:17 PM, Xuelei Fan wrote: > New webrev: > > http://cr.openjdk.java.net/~xuelei/8129988/webrev.04/ From xuelei.fan at oracle.com Thu Jan 5 17:32:08 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 5 Jan 2017 09:32:08 -0800 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: <586E70BC.5090601@oracle.com> References: <7aa674d4-8384-54b2-ffc0-6c06db8974da@oracle.com> <93dffa6c-9815-e580-73ad-50b03c425a7d@oracle.com> <3f7d53f0-1600-61af-b64d-7f7ddb50de3a@oracle.com> <76d3ba7e-9ede-f597-392f-d91c26e078c7@oracle.com> <586E70BC.5090601@oracle.com> Message-ID: Thanks for the comments. http://cr.openjdk.java.net/~xuelei/8129988/webrev.05/ I re-write the getTrustedCerts() implementation. It looks more compact now. Thanks, Xuelei On 1/5/2017 8:13 AM, Sean Mullan wrote: > 265 if (descriptor.equals(temporaryDesc) && (ks != null)) { > > Not sure if JVM will optimize this, but probably better to check if ks > != null first, and avoid calling equals unless necessary: > > 265 if (ks != null && descriptor.equals(temporaryDesc)) { > > Also, similar comment for getTrustedCerts -- you should first check if > csRef.get() is null. > If it is null, then you don't have to check the TrustStoreDescriptor, > you can go straight to > reloading the keystore and getting the certs. > > No other comments. > > --Sean > > On 1/4/2017 8:17 PM, Xuelei Fan wrote: >> New webrev: >> >> http://cr.openjdk.java.net/~xuelei/8129988/webrev.04/ > From sean.mullan at oracle.com Thu Jan 5 20:44:58 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 5 Jan 2017 15:44:58 -0500 Subject: Code Review Request JDK-8129988 JSSE should create a single instance of the cacerts KeyStore In-Reply-To: References: <7aa674d4-8384-54b2-ffc0-6c06db8974da@oracle.com> <93dffa6c-9815-e580-73ad-50b03c425a7d@oracle.com> <3f7d53f0-1600-61af-b64d-7f7ddb50de3a@oracle.com> <76d3ba7e-9ede-f597-392f-d91c26e078c7@oracle.com> <586E70BC.5090601@oracle.com> Message-ID: <4a44c280-d33e-c3b1-ac43-74772c339a3e@oracle.com> if ((certs != null) && descriptor.equals(temporaryDesc)) { return certs; } else if (certs != null) { // use new descriptor This would be more readable as: if (certs != null) { if (descriptor.equals(temporaryDesc)) { return certs; } else { // use new descriptor ... } No need to post another webrev just for this ... --Sean On 1/5/17 12:32 PM, Xuelei Fan wrote: > Thanks for the comments. > > http://cr.openjdk.java.net/~xuelei/8129988/webrev.05/ > > I re-write the getTrustedCerts() implementation. It looks more compact > now. > > Thanks, > Xuelei > > On 1/5/2017 8:13 AM, Sean Mullan wrote: >> 265 if (descriptor.equals(temporaryDesc) && (ks != null)) { >> >> Not sure if JVM will optimize this, but probably better to check if ks >> != null first, and avoid calling equals unless necessary: >> >> 265 if (ks != null && descriptor.equals(temporaryDesc)) { >> >> Also, similar comment for getTrustedCerts -- you should first check if >> csRef.get() is null. >> If it is null, then you don't have to check the TrustStoreDescriptor, >> you can go straight to >> reloading the keystore and getting the certs. >> >> No other comments. >> >> --Sean >> >> On 1/4/2017 8:17 PM, Xuelei Fan wrote: >>> New webrev: >>> >>> http://cr.openjdk.java.net/~xuelei/8129988/webrev.04/ >> From xuelei.fan at oracle.com Thu Jan 5 23:10:56 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 5 Jan 2017 15:10:56 -0800 Subject: Code Review Request JDK-8172273, SSLEngine.unwrap fails with ArrayIndexOutOfBoundsException Message-ID: Hi, Please review an implementation mistakes while converting SSLv2Hello message to SSL/TLS ClientHello message. http://cr.openjdk.java.net/~xuelei/8172273/webrev.00/ Thanks, Xuelei From bradford.wetmore at oracle.com Fri Jan 6 00:00:31 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 5 Jan 2017 16:00:31 -0800 Subject: Code Review Request JDK-8172273, SSLEngine.unwrap fails with ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: <0de9b12d-cbc0-61b5-6eb0-7ab2345347d6@oracle.com> Looks good. Thanks, Brad On 1/5/2017 3:10 PM, Xuelei Fan wrote: > Hi, > > Please review an implementation mistakes while converting SSLv2Hello > message to SSL/TLS ClientHello message. > http://cr.openjdk.java.net/~xuelei/8172273/webrev.00/ > > Thanks, > Xuelei From weijun.wang at oracle.com Fri Jan 6 08:52:12 2017 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Jan 2017 16:52:12 +0800 Subject: RFR: release note for JDK-7004967 SecureRandom should be more explicit about threading Message-ID: https://bugs.openjdk.java.net/browse/JDK-8165115 Thanks Max From sean.mullan at oracle.com Fri Jan 6 14:26:14 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 6 Jan 2017 09:26:14 -0500 Subject: RFR: release note for JDK-7004967 SecureRandom should be more explicit about threading In-Reply-To: References: Message-ID: Looks good to me. --Sean On 1/6/17 3:52 AM, Wang Weijun wrote: > https://bugs.openjdk.java.net/browse/JDK-8165115 > > Thanks > Max From sean.mullan at oracle.com Mon Jan 9 19:25:02 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 9 Jan 2017 14:25:02 -0500 Subject: RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default Message-ID: Please review this JDK 9 change to make the SecurityManager::checkPackageAccess and checkPackageDefinition implementations restrict access to the same set of internal JDK packages as the module system. This overall change will improve security by making these two mechanisms consistent and reduce the amount of work needed to maintain the package.access and package.definition security properties going forward. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8055206 JDK webrev: http://cr.openjdk.java.net/~mullan/webrevs/8055206/jdk/webrev.00/ JAXP webrev: http://cr.openjdk.java.net/~mullan/webrevs/8055206/jaxp/webrev.00/ The JBS bug has more details, but the fix consists of essentially 3 main parts: 1. Remove most packages from the package.{access,definition} security properties 2. Changes to the SecurityManager::checkPackage{Access,Definition} APIs to allow an implementation to restrict a default set of packages (in addition to those listed in the package.{access,definition} properties) 3. Changes to the default SecurityManager::checkPackage{Access,Definition} implementation to use Module APIs to compute the list of non-exported packages loaded by the platform class loader or its ancestors. Several tests also had to be modified to be granted additional permission(s) to access the newly restricted packages under a SecurityManager. JAXP also needed a change to grant additional permissions to access internal packages that are exported to the modules that are dynamically created for use with XSLT. Thanks, Sean From sha.jiang at oracle.com Wed Jan 11 03:35:34 2017 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 11 Jan 2017 11:35:34 +0800 Subject: RFR[9] JDK-8167146: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java failed with "Remote host terminated the handshake" Message-ID: <818c381d-f0f4-265e-f090-89bbbba14808@oracle.com> Hi, This patch fixes the intermittent SSLHandshakeException failure for test sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java. The fix applies some code patterns in javax/net/ssl/templates/SSLSocketTemplate.java. Webrev: http://cr.openjdk.java.net/~jjiang/8167146/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8167146 Best regards, John Jiang From adam.petcher at oracle.com Wed Jan 11 13:34:56 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 11 Jan 2017 08:34:56 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization Message-ID: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> Please review the following bug fix: http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ This fixes a bug in which a permission check would try to load resources while the system class loader is being initialized. Resources cannot be loaded at this time, so this change ensures that the resources are loaded earlier. From claes.redestad at oracle.com Wed Jan 11 14:27:00 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 11 Jan 2017 15:27:00 +0100 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> Message-ID: <6fb86f7b-a522-f6b7-a80f-4f0502372af1@oracle.com> Hi Adam, On 01/11/2017 02:34 PM, Adam Petcher wrote: > Please review the following bug fix: > > http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ > > This fixes a bug in which a permission check would try to load > resources while the system class loader is being initialized. > Resources cannot be loaded at this time, so this change ensures that > the resources are loaded earlier. > couldn't this be done in System.setSecurityManager rather than in a static block in SecurityManager? http://cr.openjdk.java.net/~redestad/scratch/8168075.alt/ The provided EarlyLoad test still pass with this approach, and this would avoid loading a few classes and a resource bundle when not installing a security manager (the SecurityManager class is always loaded on bootstrap). Thanks! /Claes From adam.petcher at oracle.com Wed Jan 11 14:56:00 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 11 Jan 2017 09:56:00 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <6fb86f7b-a522-f6b7-a80f-4f0502372af1@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <6fb86f7b-a522-f6b7-a80f-4f0502372af1@oracle.com> Message-ID: <47767e6a-5675-abfd-4629-d815df0abbdb@oracle.com> On 1/11/2017 9:27 AM, Claes Redestad wrote: > Hi Adam, > > On 01/11/2017 02:34 PM, Adam Petcher wrote: >> Please review the following bug fix: >> >> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >> >> This fixes a bug in which a permission check would try to load >> resources while the system class loader is being initialized. >> Resources cannot be loaded at this time, so this change ensures that >> the resources are loaded earlier. >> > > couldn't this be done in System.setSecurityManager rather than in a > static block > in SecurityManager? > > http://cr.openjdk.java.net/~redestad/scratch/8168075.alt/ > > The provided EarlyLoad test still pass with this approach, and this > would avoid loading a few > classes and a resource bundle when not installing a security manager > (the SecurityManager > class is always loaded on bootstrap). That would work, but I was trying to avoid cluttering up System.java with this code. What if we put it in the SecurityManager constructor? Would that accomplish the same goal? > > Thanks! > > /Claes From sibabrata.sahoo at oracle.com Wed Jan 11 15:33:46 2017 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Wed, 11 Jan 2017 07:33:46 -0800 (PST) Subject: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: Message-ID: <9deec53c-b568-448d-9d29-be596a2a8814@default> Hi Adam/Sean, This patch is waiting for your review. Thanks, Siba From: Sibabrata Sahoo Sent: Friday, December 02, 2016 6:56 PM To: Sean Mullan; security-dev at openjdk.java.net Subject: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization Hi, Please review the patch for, JBS: https://bugs.openjdk.java.net/browse/JDK-8168423 Webrev: http://cr.openjdk.java.net/~ssahoo/8168423/webrev.00/ Description: This webrev address all possible cases for Classloader with SecurityManager having combination of valid/malformed policy file. This Test is going to fail until JDK-8168075 get fixed. In the mean time, it can be used to verify the fix for JDK-8168075. Here is the generic Logic behind generating all possible Test cases with different combination of policy file, class loader and module types. for(policyFile : {"NO_POLICY", "VALID", "MALFORMED"}) { for(classLoader : {"SystemClassLoader", "CustomClassLoader"}){ // It uses possible set of regular/modular jars to generate all possible Test cases in -cp and -module-path. for(clientModuletype : {"STRICT", "AUTO", "UNKNOWN"}) { for(classLoaderModuleType : {"STRICT", "AUTO", "UNKNOWN"}) { Create and run java command line for each possible Test cases and verify result. } } } } Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Jan 11 15:39:14 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 11 Jan 2017 16:39:14 +0100 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <47767e6a-5675-abfd-4629-d815df0abbdb@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <6fb86f7b-a522-f6b7-a80f-4f0502372af1@oracle.com> <47767e6a-5675-abfd-4629-d815df0abbdb@oracle.com> Message-ID: <794ee18d-66ed-338d-fb29-bc18d816c9fb@oracle.com> Hi, On 01/11/2017 03:56 PM, Adam Petcher wrote: > > On 1/11/2017 9:27 AM, Claes Redestad wrote: >> Hi Adam, >> >> On 01/11/2017 02:34 PM, Adam Petcher wrote: >>> Please review the following bug fix: >>> >>> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >>> >>> This fixes a bug in which a permission check would try to load >>> resources while the system class loader is being initialized. >>> Resources cannot be loaded at this time, so this change ensures that >>> the resources are loaded earlier. >>> >> >> couldn't this be done in System.setSecurityManager rather than in a >> static block >> in SecurityManager? >> >> http://cr.openjdk.java.net/~redestad/scratch/8168075.alt/ >> >> The provided EarlyLoad test still pass with this approach, and this >> would avoid loading a few >> classes and a resource bundle when not installing a security manager >> (the SecurityManager >> class is always loaded on bootstrap). > That would work, but I was trying to avoid cluttering up System.java > with this code. What if we put it in the SecurityManager constructor? > Would that accomplish the same goal? the public default constructor of SecurityManager will always be run no matter how the class is overridden, so I guess it would, yes. Thanks! /Claes >> >> Thanks! >> >> /Claes > From simone.bordet at gmail.com Wed Jan 11 16:57:20 2017 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 11 Jan 2017 17:57:20 +0100 Subject: Feedback on SSLEngine.setHandshakeApplicationProtocolSelector() Message-ID: Hi, I just wanted to report that I have implemented the new mechanism provided by SSLEngine.setHandshakeApplicationProtocolSelector() in Jetty, and it works well in a much much simpler way. The amount of code required now is trivial (a couple of lines), there is no need to parse the ClientHello, and we basically tap into the existing mechanism that Jetty had. No big surprises here since the new JDK mechanism is very similar to what Jetty has for JDK 8. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From amanda.jiang at oracle.com Wed Jan 11 19:05:29 2017 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Wed, 11 Jan 2017 11:05:29 -0800 Subject: RFR 8171423: Relocate /test/lib/security/SecurityTools.java Message-ID: <7e7759ae-f1df-41b6-07f3-1166d563e267@oracle.com> Hi All, Please help to review the webrev below, which moves the utility class SecurityTools to root repo. Bug: https://bugs.openjdk.java.net/browse/JDK-8171423 Webrev: http://cr.openjdk.java.net/~amjiang/8171423/webrev.00/ Thanks, Amanda From claes.redestad at oracle.com Wed Jan 11 23:18:40 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 12 Jan 2017 00:18:40 +0100 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <6fb86f7b-a522-f6b7-a80f-4f0502372af1@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <6fb86f7b-a522-f6b7-a80f-4f0502372af1@oracle.com> Message-ID: Hi again, On 2017-01-11 15:27, Claes Redestad wrote: > Hi Adam, > > On 01/11/2017 02:34 PM, Adam Petcher wrote: >> Please review the following bug fix: >> >> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >> >> This fixes a bug in which a permission check would try to load >> resources while the system class loader is being initialized. >> Resources cannot be loaded at this time, so this change ensures that >> the resources are loaded earlier. >> > > couldn't this be done in System.setSecurityManager rather than in a > static block > in SecurityManager? > > http://cr.openjdk.java.net/~redestad/scratch/8168075.alt/ > > The provided EarlyLoad test still pass with this approach, and this > would avoid loading a few > classes and a resource bundle when not installing a security manager > (the SecurityManager class is always loaded on bootstrap). it turns out this isn't actually an issue: the SecurityManager class is loaded very early during bootstrap by the VM, but not initialized unless actually created (this can be seen by comparing -Xlog:class+load and -Xlog:class+init output). Thus for the purposes of startup then the original patch was OK. Thanks! /Claes From weijun.wang at oracle.com Thu Jan 12 01:14:33 2017 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 12 Jan 2017 09:14:33 +0800 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <6fb86f7b-a522-f6b7-a80f-4f0502372af1@oracle.com> Message-ID: <3D086840-AF1F-40CB-9C29-1AF9A2B78DEA@oracle.com> Is there a valid case where a security manager is created but not set? --Max > On Jan 12, 2560 BE, at 7:18 AM, Claes Redestad wrote: > > Hi again, > > On 2017-01-11 15:27, Claes Redestad wrote: >> Hi Adam, >> >> On 01/11/2017 02:34 PM, Adam Petcher wrote: >>> Please review the following bug fix: >>> >>> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >>> >>> This fixes a bug in which a permission check would try to load >>> resources while the system class loader is being initialized. >>> Resources cannot be loaded at this time, so this change ensures that >>> the resources are loaded earlier. >>> >> >> couldn't this be done in System.setSecurityManager rather than in a >> static block >> in SecurityManager? >> >> http://cr.openjdk.java.net/~redestad/scratch/8168075.alt/ >> >> The provided EarlyLoad test still pass with this approach, and this >> would avoid loading a few >> classes and a resource bundle when not installing a security manager >> (the SecurityManager class is always loaded on bootstrap). > > it turns out this isn't actually an issue: the SecurityManager class is > loaded very early during bootstrap by the VM, but not initialized > unless actually created (this can be seen by comparing -Xlog:class+load > and -Xlog:class+init output). Thus for the purposes of startup then > the original patch was OK. > > Thanks! > > /Claes > From weijun.wang at oracle.com Thu Jan 12 07:56:34 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 12 Jan 2017 15:56:34 +0800 Subject: RFR 8171423: Relocate /test/lib/security/SecurityTools.java In-Reply-To: <7e7759ae-f1df-41b6-07f3-1166d563e267@oracle.com> References: <7e7759ae-f1df-41b6-07f3-1166d563e267@oracle.com> Message-ID: <3a229ecd-74d2-737c-1cff-d2b993f3fc48@oracle.com> Looks fine to me. Thanks Max On 01/12/2017 03:05 AM, Amanda Jiang wrote: > Hi All, > > Please help to review the webrev below, which moves the utility class > SecurityTools to root repo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171423 > Webrev: http://cr.openjdk.java.net/~amjiang/8171423/webrev.00/ > > Thanks, > Amanda From weijun.wang at oracle.com Thu Jan 12 07:58:04 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 12 Jan 2017 15:58:04 +0800 Subject: RFR 8171423: Relocate /test/lib/security/SecurityTools.java In-Reply-To: <3a229ecd-74d2-737c-1cff-d2b993f3fc48@oracle.com> References: <7e7759ae-f1df-41b6-07f3-1166d563e267@oracle.com> <3a229ecd-74d2-737c-1cff-d2b993f3fc48@oracle.com> Message-ID: Sorry, I am replying too fast. If you can remove the existing file in the jdk repo, then everything is fine. Thanks Max On 01/12/2017 03:56 PM, Weijun Wang wrote: > Looks fine to me. > > Thanks > Max > > On 01/12/2017 03:05 AM, Amanda Jiang wrote: >> Hi All, >> >> Please help to review the webrev below, which moves the utility class >> SecurityTools to root repo. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8171423 >> Webrev: http://cr.openjdk.java.net/~amjiang/8171423/webrev.00/ >> >> Thanks, >> Amanda From weijun.wang at oracle.com Thu Jan 12 08:03:46 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 12 Jan 2017 16:03:46 +0800 Subject: Is it possible to find out the key size of the signer if we only have the signature Message-ID: <0e8e9ffc-ea65-c53b-2480-f36749c573dd@oracle.com> I am writing a tool to warn about weak key usage in a certificate or CRL. One of the warnings is if it's signed by a cert with a small key size. But the signer's cert is not always available. I can see that the signature's size depends on the signer's key size. Is there a reliable way to calculate this key size? The only existing knowledge is the signature bytes and the signature algorithm. Thanks Max From claes.redestad at oracle.com Thu Jan 12 14:48:24 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 12 Jan 2017 15:48:24 +0100 Subject: RFR: 8037325: Class.getConstructor() performance regression Message-ID: Hi, please review this fix to various performance regressions observed as the security model has evolved over the years. Bug: https://bugs.openjdk.java.net/browse/JDK-8037325 Webrev: http://cr.openjdk.java.net/~redestad/8037325/webrev.01 - For cases where a SecurityManager is not installed, this improves performance by avoiding calls to Reflection.getCallerClass, which can be very expensive when not inlined. Regrettably this adds some boilerplate. - For cases where a SecurityManager is installed, this improves performance slightly by avoiding repeated calls to System.getSecurityManager (which does volatile read). - Use of Class.getPackageName when appropriate reduce the number of allocations done. - Places where doPrivileged calls were used to bypass access checking when calling methods on Class can safely be replaced by calling corresponding private methods directly if care is taken to copy the end result as appropriate. - Finally, by using the recently used ReflectionFactory.getExecutableSharedParameterTypes we also get rid of some unnecessary copying. Thanks! /Claes From sean.mullan at oracle.com Thu Jan 12 18:50:06 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Jan 2017 13:50:06 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> Message-ID: <01e94488-ea9b-380c-b12c-677af5c11e4b@oracle.com> Fix looks good to me. --Sean On 1/11/17 8:34 AM, Adam Petcher wrote: > Please review the following bug fix: > > http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ > > This fixes a bug in which a permission check would try to load resources > while the system class loader is being initialized. Resources cannot be > loaded at this time, so this change ensures that the resources are > loaded earlier. > From mstjohns at comcast.net Thu Jan 12 18:50:40 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 12 Jan 2017 13:50:40 -0500 Subject: Is it possible to find out the key size of the signer if we only have the signature In-Reply-To: <0e8e9ffc-ea65-c53b-2480-f36749c573dd@oracle.com> References: <0e8e9ffc-ea65-c53b-2480-f36749c573dd@oracle.com> Message-ID: <3f53f792-dbaa-54bb-e5a6-94db5e87f18e@comcast.net> On 1/12/2017 3:03 AM, Weijun Wang wrote: > I am writing a tool to warn about weak key usage in a certificate or > CRL. One of the warnings is if it's signed by a cert with a small key > size. > > But the signer's cert is not always available. I can see that the > signature's size depends on the signer's key size. Is there a reliable > way to calculate this key size? The only existing knowledge is the > signature bytes and the signature algorithm. > > Thanks > Max If it's an RSA key then signature length == key length. If it's an EC key then a good approximation is (signature size in bytes - 7)/2 * 8. The EC signature is encoded as an ASN1 sequence of two INTEGERS. The ASN1 encoding overhead is about 3 bytes for the sequence and 2 for each of the integers. If you want an absolute floor on the key size, find the body of each of the integers (the octets that make up the value field) and normalize them (remove leading zeros). Take the maximum of the two lengths. That's the floor of the key size. Once in about 65K signatures that floor is going to be less than the actual key size. From mstjohns at comcast.net Thu Jan 12 18:53:39 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 12 Jan 2017 13:53:39 -0500 Subject: Is it possible to find out the key size of the signer if we only have the signature In-Reply-To: <3f53f792-dbaa-54bb-e5a6-94db5e87f18e@comcast.net> References: <0e8e9ffc-ea65-c53b-2480-f36749c573dd@oracle.com> <3f53f792-dbaa-54bb-e5a6-94db5e87f18e@comcast.net> Message-ID: On 1/12/2017 1:50 PM, Michael StJohns wrote: > On 1/12/2017 3:03 AM, Weijun Wang wrote: >> I am writing a tool to warn about weak key usage in a certificate or >> CRL. One of the warnings is if it's signed by a cert with a small key >> size. >> >> But the signer's cert is not always available. I can see that the >> signature's size depends on the signer's key size. Is there a >> reliable way to calculate this key size? The only existing knowledge >> is the signature bytes and the signature algorithm. >> >> Thanks >> Max > > > If it's an RSA key then signature length == key length. > > > If it's an EC key then a good approximation is (signature size in > bytes - 7)/2 * 8. The EC signature is encoded as an ASN1 sequence of > two INTEGERS. The ASN1 encoding overhead is about 3 bytes for the > sequence and 2 for each of the integers. If you want an absolute > floor on the key size, find the body of each of the integers (the > octets that make up the value field) and normalize them (remove > leading zeros). Take the maximum of the two lengths. That's the > floor of the key size. Once in about 65K signatures that floor is > going to be less than the actual key size. > Oh yeah - Reduce the signature strength to a minimum of the bits provided by the hash function. So if you've got a SHA256withECDSA but a signature by P384 key, the strength of the signature is only 256 bits. Mike From adam.petcher at oracle.com Thu Jan 12 19:00:33 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 12 Jan 2017 14:00:33 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <01e94488-ea9b-380c-b12c-677af5c11e4b@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <01e94488-ea9b-380c-b12c-677af5c11e4b@oracle.com> Message-ID: I need to incorporate some feedback. Also, one of Siba's tests still fails on this code, so I need to fix that. Stand by for the next diff. On 1/12/2017 1:50 PM, Sean Mullan wrote: > Fix looks good to me. > > --Sean > > On 1/11/17 8:34 AM, Adam Petcher wrote: >> Please review the following bug fix: >> >> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >> >> This fixes a bug in which a permission check would try to load resources >> while the system class loader is being initialized. Resources cannot be >> loaded at this time, so this change ensures that the resources are >> loaded earlier. >> From simone.bordet at gmail.com Thu Jan 12 19:04:16 2017 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 12 Jan 2017 20:04:16 +0100 Subject: Feedback on SSLEngine.setHandshakeApplicationProtocolSelector() In-Reply-To: References: Message-ID: Hi, On Wed, Jan 11, 2017 at 5:57 PM, Simone Bordet wrote: > Hi, > > I just wanted to report that I have implemented the new mechanism > provided by SSLEngine.setHandshakeApplicationProtocolSelector() in > Jetty, and it works well in a much much simpler way. > > The amount of code required now is trivial (a couple of lines), there > is no need to parse the ClientHello, and we basically tap into the > existing mechanism that Jetty had. > No big surprises here since the new JDK mechanism is very similar to > what Jetty has for JDK 8. For the record, I have implemented also the client-side mechanism using the JDK 9 APIs. Looks simple enough and works fine. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From mandy.chung at oracle.com Thu Jan 12 20:53:56 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 Jan 2017 12:53:56 -0800 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> Message-ID: <55523B56-7F5D-4D29-A85C-7B63DAE7FBE3@oracle.com> > On Jan 11, 2017, at 5:34 AM, Adam Petcher wrote: > > Please review the following bug fix: > > http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ > > This fixes a bug in which a permission check would try to load resources while the system class loader is being initialized. Resources cannot be loaded at this time, so this change ensures that the resources are loaded earlier. This seems a reasonable approach. There is a slight overhead for this change when the resource bundle is never used but it?s not an issue since the initialization of a security manager is not cheap anyway. It may be helpful to add a check to ensure that the resource bundle is loaded either VM.isBooted() or initLevel != 3. It would make it clear of this circular bootstrapping issue. You do this in SecurityManager class initialization. Have you considered doing it in the SecurityManager constructor? As Claes clarified, SM is loaded but not initialized during early VM startup. So no issue to do it in clinit. The alternative is to do it in the constructor as lazy initialization. ResourcesMgr.java Is the doPrivileged necessary? It?s old code written long ago. Perhaps we should file a bug to clean this up later. Otherwise, looks good. Mandy From mandy.chung at oracle.com Fri Jan 13 07:38:46 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 Jan 2017 23:38:46 -0800 Subject: RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default In-Reply-To: References: Message-ID: > On Jan 9, 2017, at 11:25 AM, Sean Mullan wrote: > > Please review this JDK 9 change to make the SecurityManager::checkPackageAccess and checkPackageDefinition implementations restrict access to the same set of internal JDK packages as the module system. > > This overall change will improve security by making these two mechanisms consistent and reduce the amount of work needed to maintain the package.access and package.definition security properties going forward. > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8055206 > JDK webrev: http://cr.openjdk.java.net/~mullan/webrevs/8055206/jdk/webrev.00/ > JAXP webrev: http://cr.openjdk.java.net/~mullan/webrevs/8055206/jaxp/webrev.00/ > This looks quite good. It?s good that the restricted package list for the system modules is no longer modifiable. This change may impact existing applications that are running with security manager and uses a JDK internal API from the runtime that was not in the package.access list. It may require the application to grant additional ?accessClassInPackage.? permissions in addition to using `?-add-exports` to break into encapsulation. Similar to the feedback I suggest for JDK-8168075. We can move this initialization to the holder class and trigger the initialization in the SecurityManager constructor. > : > Several tests also had to be modified to be granted additional permission(s) to access the newly restricted packages under a SecurityManager. JAXP also needed a change to grant additional permissions to access internal packages that are exported to the modules that are dynamically created for use with XSLT. We will have to see if any dynamic generated bytecode in the field will need access to internal API like XSLT case. It seems something not right for a module that has access to an internal package in another module via qualified exports is required to have ?accessClassInPackage.? runtime permission. I believe the ?accessClassInPackage.? permission is checked when a deprivileged module loads an internal class in a module defined by the boot loader even if the package of that internal class is exported to it to access. I do think we should follow up and look into the potential solutions to respect the qualified exports. In addition, we should file an issue to look into any possibility to respect `?-add-exports` if specified (perhaps automatically add an entry in the default policy?). I?m okay to follow up these with separate JBS issues. Otherwise looks good. Mandy From weijun.wang at oracle.com Fri Jan 13 09:09:31 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 13 Jan 2017 17:09:31 +0800 Subject: Asking for a name change in sun.security.provider.certpath.BasicChecker Message-ID: <08ca3fe8-dcc2-a1fe-5fa5-73ce286290be@oracle.com> This class has a method called verifyTimestamp() but it's actually about the validity period fields in a certificate. I found it quite misleading because whenever I see timestamp I think of TSA and RFC 3161. Are you OK with changing all occurrences of "timestamp" to "validity"? This includes the title in the exception message. Thanks Max From weijun.wang at oracle.com Fri Jan 13 11:51:52 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 13 Jan 2017 19:51:52 +0800 Subject: RFR 8172422: jarsigner needs to understand -? Message-ID: <6331a44e-3b1e-0007-eb78-acc543a5ee03@oracle.com> Please review this code change: diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Main.java b/src/java.base/share/classes/sun/security/tools/keytool/Main.java --- a/src/java.base/share/classes/sun/security/tools/keytool/Main.java +++ b/src/java.base/share/classes/sun/security/tools/keytool/Main.java @@ -474,7 +474,9 @@ if (c != null) { command = c; - } else if (collator.compare(flags, "-help") == 0) { + } else if (collator.compare(flags, "-help") == 0 || + collator.compare(flags, "-h") == 0 || + collator.compare(flags, "-?") == 0) { help = true; } else if (collator.compare(flags, "-conf") == 0) { i++; diff --git a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java --- a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java +++ b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java @@ -444,6 +444,7 @@ } else if (collator.compare(flags, "-strict") ==0) { strict = true; } else if (collator.compare(flags, "-h") == 0 || + collator.compare(flags, "-?") == 0 || collator.compare(flags, "-help") == 0) { fullusage(); } else { I don't intend to show it in the help screen. These tools have no other options or commands that show an "alias". Some do have "legacy" names (For example, "-genkeypair" was "-genkey") but they are not shown either. Noreg-trivial. Thanks Max From sean.mullan at oracle.com Fri Jan 13 12:31:36 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Jan 2017 07:31:36 -0500 Subject: RFR 8172422: jarsigner needs to understand -? In-Reply-To: <6331a44e-3b1e-0007-eb78-acc543a5ee03@oracle.com> References: <6331a44e-3b1e-0007-eb78-acc543a5ee03@oracle.com> Message-ID: <63be7940-ce02-afa6-cde0-fe9e7680f5d7@oracle.com> Looks ok, but is this for JDK 9? If so, we shouldn't be fixing P4 bugs now since we are in Rampdown Phase 1. --Sean On 1/13/17 6:51 AM, Weijun Wang wrote: > Please review this code change: > > diff --git > a/src/java.base/share/classes/sun/security/tools/keytool/Main.java > b/src/java.base/share/classes/sun/security/tools/keytool/Main.java > --- a/src/java.base/share/classes/sun/security/tools/keytool/Main.java > +++ b/src/java.base/share/classes/sun/security/tools/keytool/Main.java > @@ -474,7 +474,9 @@ > > if (c != null) { > command = c; > - } else if (collator.compare(flags, "-help") == 0) { > + } else if (collator.compare(flags, "-help") == 0 || > + collator.compare(flags, "-h") == 0 || > + collator.compare(flags, "-?") == 0) { > help = true; > } else if (collator.compare(flags, "-conf") == 0) { > i++; > diff --git > a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java > b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java > --- a/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java > +++ b/src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java > @@ -444,6 +444,7 @@ > } else if (collator.compare(flags, "-strict") ==0) { > strict = true; > } else if (collator.compare(flags, "-h") == 0 || > + collator.compare(flags, "-?") == 0 || > collator.compare(flags, "-help") == 0) { > fullusage(); > } else { > > I don't intend to show it in the help screen. These tools have no other > options or commands that show an "alias". Some do have "legacy" names > (For example, "-genkeypair" was "-genkey") but they are not shown either. > > Noreg-trivial. > > Thanks > Max From claes.redestad at oracle.com Fri Jan 13 12:58:02 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 13 Jan 2017 13:58:02 +0100 Subject: RFR: 8037325: Class.getConstructor() performance regression In-Reply-To: <000001d26d98$b50e8550$1f2b8ff0$@freenet.de> References: <000001d26d98$b50e8550$1f2b8ff0$@freenet.de> Message-ID: <09f64edb-94ab-7f8d-b39b-8a55909354b6@oracle.com> Hi Christoph, thanks for looking at this! Extracting methodName was part cleanup, part meant to outline some rarely executed error handling code, which can help a JIT focus on the critical path. I'd prefer not to micro-optimize argumentTypesToString (and would likely look at other things than StringJoiner if it was performance sensitive). Thanks! /Claes On 01/13/2017 01:29 PM, Christoph Dreis wrote: > Hey, > > your extraction of methodName() made me aware of another small thing. What about rewriting argumentTypesToString() to avoid creating the StringJoiner if not needed? > > private static String argumentTypesToString(Class[] argTypes) { > if (argTypes != null) { > StringJoiner sj = new StringJoiner(", ", "(", ")"); > for (int i = 0; i < argTypes.length; i++) { > Class c = argTypes[i]; > sj.add((c == null) ? "null" : c.getName()); > } > return sj.toString(); > } > return "()"; > } > > Should have a very minor impact though. Apart from that looks good to me. > > Cheers, > Christoph > > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Claes Redestad > Sent: Thursday, January 12, 2017 3:48 PM > To: core-libs-dev Libs ; Security Dev OpenJDK > Subject: RFR: 8037325: Class.getConstructor() performance regression > > Hi, > > please review this fix to various performance regressions observed > as the security model has evolved over the years. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037325 > Webrev: http://cr.openjdk.java.net/~redestad/8037325/webrev.01 > > - For cases where a SecurityManager is not installed, this improves > performance by avoiding calls to Reflection.getCallerClass, which > can be very expensive when not inlined. Regrettably this adds some > boilerplate. > > - For cases where a SecurityManager is installed, this improves > performance slightly by avoiding repeated calls to > System.getSecurityManager (which does volatile read). > > - Use of Class.getPackageName when appropriate reduce the > number of allocations done. > > - Places where doPrivileged calls were used to bypass access checking > when calling methods on Class can safely be replaced by calling > corresponding private methods directly if care is taken to copy the > end result as appropriate. > > - Finally, by using the recently used > ReflectionFactory.getExecutableSharedParameterTypes we also get rid of > some unnecessary copying. > > Thanks! > > /Claes > From sean.mullan at oracle.com Fri Jan 13 13:28:41 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Jan 2017 08:28:41 -0500 Subject: Asking for a name change in sun.security.provider.certpath.BasicChecker In-Reply-To: <08ca3fe8-dcc2-a1fe-5fa5-73ce286290be@oracle.com> References: <08ca3fe8-dcc2-a1fe-5fa5-73ce286290be@oracle.com> Message-ID: On 1/13/17 4:09 AM, Weijun Wang wrote: > This class has a method called verifyTimestamp() but it's actually about > the validity period fields in a certificate. I found it quite misleading > because whenever I see timestamp I think of TSA and RFC 3161. > > Are you OK with changing all occurrences of "timestamp" to "validity"? > This includes the title in the exception message. Yes. --Sean From sean.mullan at oracle.com Fri Jan 13 15:30:33 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Jan 2017 10:30:33 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <55523B56-7F5D-4D29-A85C-7B63DAE7FBE3@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <55523B56-7F5D-4D29-A85C-7B63DAE7FBE3@oracle.com> Message-ID: On 1/12/17 3:53 PM, Mandy Chung wrote: > >> On Jan 11, 2017, at 5:34 AM, Adam Petcher >> wrote: >> >> Please review the following bug fix: >> >> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >> >> This fixes a bug in which a permission check would try to load >> resources while the system class loader is being initialized. >> Resources cannot be loaded at this time, so this change ensures >> that the resources are loaded earlier. > > This seems a reasonable approach. There is a slight overhead for > this change when the resource bundle is never used but it?s not an > issue since the initialization of a security manager is not cheap > anyway. > > It may be helpful to add a check to ensure that the resource bundle > is loaded either VM.isBooted() or initLevel != 3. It would make it > clear of this circular bootstrapping issue. > > You do this in SecurityManager class initialization. Have you > considered doing it in the SecurityManager constructor? As Claes > clarified, SM is loaded but not initialized during early VM startup. > So no issue to do it in clinit. The alternative is to do it in the > constructor as lazy initialization. I don't see any particular performance advantage of moving it to the constructor. The SM will be initialized and instantiated in phase 3 before it initializes the system classloader. Did you have another concern in mind? > > ResourcesMgr.java Is the doPrivileged necessary? It?s old code > written long ago. Perhaps we should file a bug to clean this up > later. At this point in JDK 9, it's probably better to leave it alone until we have more time to evaluate it. Adam, please file a bug to look into this more, unless you can quickly determine that it is needed. --Sean From adam.petcher at oracle.com Fri Jan 13 17:01:25 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Fri, 13 Jan 2017 12:01:25 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <55523B56-7F5D-4D29-A85C-7B63DAE7FBE3@oracle.com> Message-ID: <2aea9fb8-5354-9464-3872-d71e1ff60628@oracle.com> On 1/13/2017 10:30 AM, Sean Mullan wrote: > On 1/12/17 3:53 PM, Mandy Chung wrote: >> >>> On Jan 11, 2017, at 5:34 AM, Adam Petcher >>> wrote: >>> >>> Please review the following bug fix: >>> >>> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >>> >>> This fixes a bug in which a permission check would try to load >>> resources while the system class loader is being initialized. >>> Resources cannot be loaded at this time, so this change ensures >>> that the resources are loaded earlier. >> >> This seems a reasonable approach. There is a slight overhead for >> this change when the resource bundle is never used but it?s not an >> issue since the initialization of a security manager is not cheap >> anyway. >> >> It may be helpful to add a check to ensure that the resource bundle >> is loaded either VM.isBooted() or initLevel != 3. It would make it >> clear of this circular bootstrapping issue. >> >> You do this in SecurityManager class initialization. Have you >> considered doing it in the SecurityManager constructor? As Claes >> clarified, SM is loaded but not initialized during early VM startup. >> So no issue to do it in clinit. The alternative is to do it in the >> constructor as lazy initialization. > > I don't see any particular performance advantage of moving it to the > constructor. The SM will be initialized and instantiated in phase 3 > before it initializes the system classloader. Did you have another > concern in mind? > >> >> ResourcesMgr.java Is the doPrivileged necessary? It?s old code >> written long ago. Perhaps we should file a bug to clean this up >> later. > > At this point in JDK 9, it's probably better to leave it alone until > we have more time to evaluate it. Adam, please file a bug to look into > this more, unless you can quickly determine that it is needed. JDK-8172808 created. > > --Sean From mandy.chung at oracle.com Fri Jan 13 17:03:43 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Jan 2017 09:03:43 -0800 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <55523B56-7F5D-4D29-A85C-7B63DAE7FBE3@oracle.com> Message-ID: <5C7EC68E-CD67-419C-BDDB-FF36A08935E1@oracle.com> > On Jan 13, 2017, at 7:30 AM, Sean Mullan wrote: > > On 1/12/17 3:53 PM, Mandy Chung wrote: >> >>> On Jan 11, 2017, at 5:34 AM, Adam Petcher >>> wrote: >>> >>> Please review the following bug fix: >>> >>> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >>> >>> This fixes a bug in which a permission check would try to load >>> resources while the system class loader is being initialized. >>> Resources cannot be loaded at this time, so this change ensures >>> that the resources are loaded earlier. >> >> This seems a reasonable approach. There is a slight overhead for >> this change when the resource bundle is never used but it?s not an >> issue since the initialization of a security manager is not cheap >> anyway. >> >> It may be helpful to add a check to ensure that the resource bundle >> is loaded either VM.isBooted() or initLevel != 3. It would make it >> clear of this circular bootstrapping issue. >> >> You do this in SecurityManager class initialization. Have you >> considered doing it in the SecurityManager constructor? As Claes >> clarified, SM is loaded but not initialized during early VM startup. >> So no issue to do it in clinit. The alternative is to do it in the >> constructor as lazy initialization. > > I don't see any particular performance advantage of moving it to the constructor. The SM will be initialized and instantiated in phase 3 before it initializes the system classloader. Did you have another concern in mind? > No. There isn?t any performance difference since such code is invoked when a security manager is created. I?m okay to push this as is. Perhaps you can look into it as part of JDK-8055206 since JDK-8055206 has the initialization code too. Mandy From weijun.wang at oracle.com Mon Jan 16 01:41:22 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 16 Jan 2017 09:41:22 +0800 Subject: RFR 8172422: jarsigner needs to understand -? Message-ID: Please review the code change at http://cr.openjdk.java.net/~weijun/8172529/webrev.02 The validator is updated to be a PKIXValidator of the Validator.VAR_CODE_SIGNING variant. In order to have the same output message and exit code as before, the ValidatorException thrown when validation fails is suppressed when there are existing error flags for several reasons. *jigsaw-dev*: The following change is made in java.base/module-info.java: + exports sun.security.validator to + jdk.jartool; Thanks Max From weijun.wang at oracle.com Mon Jan 16 01:42:37 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 16 Jan 2017 09:42:37 +0800 Subject: 8172529: Use PKIXValidator in jarsigner In-Reply-To: References: Message-ID: <3c95fafb-7bed-6809-18e9-25fcfaf06d81@oracle.com> Sorry, wrong subject, resending. On 01/16/2017 09:41 AM, Weijun Wang wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8172529/webrev.02 > > The validator is updated to be a PKIXValidator of the > Validator.VAR_CODE_SIGNING variant. In order to have the same output > message and exit code as before, the ValidatorException thrown when > validation fails is suppressed when there are existing error flags for > several reasons. > > *jigsaw-dev*: The following change is made in java.base/module-info.java: > > + exports sun.security.validator to > + jdk.jartool; > > Thanks > Max From sha.jiang at oracle.com Mon Jan 16 02:43:15 2017 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 16 Jan 2017 10:43:15 +0800 Subject: RFR[9] JDK-8167146: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java failed with "Remote host terminated the handshake" In-Reply-To: <818c381d-f0f4-265e-f090-89bbbba14808@oracle.com> References: <818c381d-f0f4-265e-f090-89bbbba14808@oracle.com> Message-ID: <8058017f-60c1-00b3-41ba-93b665779929@oracle.com> Please review this patch. Thanks! John Jiang On 2017/1/11 11:35, John Jiang wrote: > Hi, > This patch fixes the intermittent SSLHandshakeException failure for > test sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java. > The fix applies some code patterns in > javax/net/ssl/templates/SSLSocketTemplate.java. > > Webrev: http://cr.openjdk.java.net/~jjiang/8167146/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8167146 > > Best regards, > John Jiang > > From xuelei.fan at oracle.com Mon Jan 16 03:57:22 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 15 Jan 2017 19:57:22 -0800 Subject: RFR[9] JDK-8167146: sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java failed with "Remote host terminated the handshake" In-Reply-To: <8058017f-60c1-00b3-41ba-93b665779929@oracle.com> References: <818c381d-f0f4-265e-f090-89bbbba14808@oracle.com> <8058017f-60c1-00b3-41ba-93b665779929@oracle.com> Message-ID: <58216c7a-76cd-b052-49d2-a11e0f129180@oracle.com> Looks fine to me. Xuelei On 1/15/2017 6:43 PM, John Jiang wrote: > Please review this patch. > Thanks! > > John Jiang > > On 2017/1/11 11:35, John Jiang wrote: >> Hi, >> This patch fixes the intermittent SSLHandshakeException failure for >> test sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java. >> The fix applies some code patterns in >> javax/net/ssl/templates/SSLSocketTemplate.java. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8167146/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8167146 >> >> Best regards, >> John Jiang >> >> > From Alan.Bateman at oracle.com Mon Jan 16 09:37:10 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Jan 2017 09:37:10 +0000 Subject: RFR 8172422: jarsigner needs to understand -? In-Reply-To: References: Message-ID: <64a9aee8-68c3-dc66-c665-5f73f6cbd6a0@oracle.com> On 16/01/2017 01:41, Weijun Wang wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8172529/webrev.02 > > The validator is updated to be a PKIXValidator of the > Validator.VAR_CODE_SIGNING variant. In order to have the same output > message and exit code as before, the ValidatorException thrown when > validation fails is suppressed when there are existing error flags for > several reasons. > > *jigsaw-dev*: The following change is made in java.base/module-info.java: > > + exports sun.security.validator to > + jdk.jartool; That part looks okay to me although at some point we need to go over every one of these qualified exports with a view to removing as many of possible. -Alan From vincent.x.ryan at oracle.com Mon Jan 16 11:11:30 2017 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 16 Jan 2017 11:11:30 +0000 Subject: Feedback on SSLEngine.setHandshakeApplicationProtocolSelector() In-Reply-To: References: Message-ID: <1C5F63A2-024A-4EC8-89AC-C13F6139540A@oracle.com> That?s good news. Thanks for validating the new mechanism in Jetty. > On 12 Jan 2017, at 19:04, Simone Bordet wrote: > > Hi, > > On Wed, Jan 11, 2017 at 5:57 PM, Simone Bordet wrote: >> Hi, >> >> I just wanted to report that I have implemented the new mechanism >> provided by SSLEngine.setHandshakeApplicationProtocolSelector() in >> Jetty, and it works well in a much much simpler way. >> >> The amount of code required now is trivial (a couple of lines), there >> is no need to parse the ClientHello, and we basically tap into the >> existing mechanism that Jetty had. >> No big surprises here since the new JDK mechanism is very similar to >> what Jetty has for JDK 8. > > For the record, I have implemented also the client-side mechanism > using the JDK 9 APIs. > Looks simple enough and works fine. > > -- > Simone Bordet > http://bordet.blogspot.com > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz From xuelei.fan at oracle.com Mon Jan 16 17:26:07 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 Jan 2017 09:26:07 -0800 Subject: 8172529: Use PKIXValidator in jarsigner In-Reply-To: <3c95fafb-7bed-6809-18e9-25fcfaf06d81@oracle.com> References: <3c95fafb-7bed-6809-18e9-25fcfaf06d81@oracle.com> Message-ID: <68ff0e2c-504c-9345-a542-99da5b97b6a5@oracle.com> On 1/15/2017 5:42 PM, Weijun Wang wrote: > Sorry, wrong subject, resending. > > On 01/16/2017 09:41 AM, Weijun Wang wrote: >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8172529/webrev.02 >> >> The validator is updated to be a PKIXValidator of the >> Validator.VAR_CODE_SIGNING variant. What's the variant used by plugin? Is it VAR_PLUGIN_CODE_SIGNING? I'm asking because the behaviors of VAR_PLUGIN_CODE_SIGNING and VAR_CODE_SIGNING is a little bit different (See the use of PKIXValidator.plugin variable). Xuelei >> In order to have the same output >> message and exit code as before, the ValidatorException thrown when >> validation fails is suppressed when there are existing error flags for >> several reasons. >> >> *jigsaw-dev*: The following change is made in java.base/module-info.java: >> >> + exports sun.security.validator to >> + jdk.jartool; >> >> Thanks >> Max From mandy.chung at oracle.com Mon Jan 16 21:39:57 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 16 Jan 2017 13:39:57 -0800 Subject: RFR: 8037325: Class.getConstructor() performance regression In-Reply-To: References: Message-ID: > On Jan 12, 2017, at 6:48 AM, Claes Redestad wrote: > > Hi, > > please review this fix to various performance regressions observed > as the security model has evolved over the years. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8037325 > Webrev: http://cr.openjdk.java.net/~redestad/8037325/webrev.01 > Looks good. Nit: methodName method returns the string representation of the method signature and so more than the method name. Maybe it should call ?methodToString?? The argumentTypesToString method is only used to print the method signature. You could merge these two methods if you like. ReflectUtil.java 262 public static boolean isNonPublicProxyClass(Class cls) { 263 String pkg; 264 return Proxy.isProxyClass(cls) && 265 ((pkg = cls.getPackageName()) == null || !pkg.startsWith(PROXY_PACKAGE)); 266 } Nit: just a personal preference: move Proxy.isProxyClass(cls) check in a separate if-statement and the declaration pkg can be moved with the assignment. Mandy From claes.redestad at oracle.com Mon Jan 16 21:59:50 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 16 Jan 2017 22:59:50 +0100 Subject: RFR: 8037325: Class.getConstructor() performance regression In-Reply-To: References: Message-ID: <20e15902-ccac-01b3-21c6-879c58e29521@oracle.com> On 2017-01-16 22:39, Mandy Chung wrote: > >> On Jan 12, 2017, at 6:48 AM, Claes Redestad wrote: >> >> Hi, >> >> please review this fix to various performance regressions observed >> as the security model has evolved over the years. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8037325 >> Webrev: http://cr.openjdk.java.net/~redestad/8037325/webrev.01 >> > > Looks good. Thanks! > > Nit: methodName method returns the string representation of the method signature and so more than the method name. Maybe it should call ?methodToString?? The argumentTypesToString method is only used to print the method signature. You could merge these two methods if you like. > > ReflectUtil.java > 262 public static boolean isNonPublicProxyClass(Class cls) { > 263 String pkg; > 264 return Proxy.isProxyClass(cls) && > 265 ((pkg = cls.getPackageName()) == null || !pkg.startsWith(PROXY_PACKAGE)); > 266 } > > Nit: just a personal preference: move Proxy.isProxyClass(cls) check in a separate if-statement and the declaration pkg can be moved with the assignment. http://cr.openjdk.java.net/~redestad/8037325/webrev.02/ Like that? /Claes > > Mandy > From mandy.chung at oracle.com Mon Jan 16 22:27:27 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 16 Jan 2017 14:27:27 -0800 Subject: RFR: 8037325: Class.getConstructor() performance regression In-Reply-To: <20e15902-ccac-01b3-21c6-879c58e29521@oracle.com> References: <20e15902-ccac-01b3-21c6-879c58e29521@oracle.com> Message-ID: > On Jan 16, 2017, at 1:59 PM, Claes Redestad wrote: > > http://cr.openjdk.java.net/~redestad/8037325/webrev.02/ +1 Mandy From weijun.wang at oracle.com Tue Jan 17 02:09:20 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 17 Jan 2017 10:09:20 +0800 Subject: 8172529: Use PKIXValidator in jarsigner In-Reply-To: <68ff0e2c-504c-9345-a542-99da5b97b6a5@oracle.com> References: <3c95fafb-7bed-6809-18e9-25fcfaf06d81@oracle.com> <68ff0e2c-504c-9345-a542-99da5b97b6a5@oracle.com> Message-ID: <38bf65d6-3369-af27-cb1d-326061520385@oracle.com> On 01/17/2017 01:26 AM, Xuelei Fan wrote: > On 1/15/2017 5:42 PM, Weijun Wang wrote: >> Sorry, wrong subject, resending. >> >> On 01/16/2017 09:41 AM, Weijun Wang wrote: >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/8172529/webrev.02 >>> >>> The validator is updated to be a PKIXValidator of the >>> Validator.VAR_CODE_SIGNING variant. > What's the variant used by plugin? Is it VAR_PLUGIN_CODE_SIGNING? Yes, it is. > I'm asking because the behaviors of VAR_PLUGIN_CODE_SIGNING and > VAR_CODE_SIGNING is a little bit different (See the use of > PKIXValidator.plugin variable). There is a small difference. If I read correctly, the different code allows Plugin to validate a chain anyway (even if there is no trust anchor) and then decide if the last cert can be trusted itself, most likely by showing a dialog and asking the user to decide. In jarsigner, the certpath validation is used for showing warnings and the jar file is signed anyway. The warning is enough to alert the user and I do not intend to add a layer of user interaction here like in Plugin. The major purpose of the fix is to detect a cross-signed certificate in the certchain. I should update the bug description. Thanks Max > > Xuelei > >>> In order to have the same output message and exit code as before, >>> the ValidatorException thrown when validation fails is suppressed >>> when there are existing error flags for several reasons. >>> >>> *jigsaw-dev*: The following change is made in >>> java.base/module-info.java: >>> >>> + exports sun.security.validator to + jdk.jartool; >>> >>> Thanks Max From Xuelei.Fan at Oracle.Com Tue Jan 17 03:03:01 2017 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Mon, 16 Jan 2017 19:03:01 -0800 Subject: 8172529: Use PKIXValidator in jarsigner In-Reply-To: <38bf65d6-3369-af27-cb1d-326061520385@oracle.com> References: <3c95fafb-7bed-6809-18e9-25fcfaf06d81@oracle.com> <68ff0e2c-504c-9345-a542-99da5b97b6a5@oracle.com> <38bf65d6-3369-af27-cb1d-326061520385@oracle.com> Message-ID: <6105DA76-BE41-4144-8100-003501368EC8@Oracle.Com> Ok. Looks good. Xuelei > On Jan 16, 2017, at 6:09 PM, Weijun Wang wrote: > > > >> On 01/17/2017 01:26 AM, Xuelei Fan wrote: >>> On 1/15/2017 5:42 PM, Weijun Wang wrote: >>> Sorry, wrong subject, resending. >>> >>>> On 01/16/2017 09:41 AM, Weijun Wang wrote: >>>> Please review the code change at >>>> >>>> http://cr.openjdk.java.net/~weijun/8172529/webrev.02 >>>> >>>> The validator is updated to be a PKIXValidator of the >>>> Validator.VAR_CODE_SIGNING variant. >> What's the variant used by plugin? Is it VAR_PLUGIN_CODE_SIGNING? > > Yes, it is. > >> I'm asking because the behaviors of VAR_PLUGIN_CODE_SIGNING and >> VAR_CODE_SIGNING is a little bit different (See the use of >> PKIXValidator.plugin variable). > > There is a small difference. If I read correctly, the different code allows Plugin to validate a chain anyway (even if there is no trust anchor) and then decide if the last cert can be trusted itself, most likely by showing a dialog and asking the user to decide. > > In jarsigner, the certpath validation is used for showing warnings and the jar file is signed anyway. The warning is enough to alert the user and I do not intend to add a layer of user interaction here like in Plugin. > > The major purpose of the fix is to detect a cross-signed certificate in the certchain. I should update the bug description. > > Thanks > Max > >> >> Xuelei >> >>>> In order to have the same output message and exit code as before, >>>> the ValidatorException thrown when validation fails is suppressed >>>> when there are existing error flags for several reasons. >>>> >>>> *jigsaw-dev*: The following change is made in >>>> java.base/module-info.java: >>>> >>>> + exports sun.security.validator to + jdk.jartool; >>>> >>>> Thanks Max From sean.mullan at oracle.com Tue Jan 17 20:23:54 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Jan 2017 15:23:54 -0500 Subject: RFR 8172422: jarsigner needs to understand -? In-Reply-To: References: Message-ID: Looks good to me. --Sean On 1/15/17 8:41 PM, Weijun Wang wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8172529/webrev.02 > > The validator is updated to be a PKIXValidator of the > Validator.VAR_CODE_SIGNING variant. In order to have the same output > message and exit code as before, the ValidatorException thrown when > validation fails is suppressed when there are existing error flags for > several reasons. > > *jigsaw-dev*: The following change is made in java.base/module-info.java: > > + exports sun.security.validator to > + jdk.jartool; > > Thanks > Max From weijun.wang at oracle.com Wed Jan 18 14:50:56 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Jan 2017 22:50:56 +0800 Subject: RFR 8172975: SecurityTools.keytool() needs to accept user input Message-ID: <3d7e0589-3b76-927c-8f79-3b29d4dac12b@oracle.com> Please review the code changes at root: http://cr.openjdk.java.net/~weijun/8172975/root/webrev.00/ jdk: http://cr.openjdk.java.net/~weijun/8172975/webrev.00/ The fix is in root repo. This is not an elegant solution because it uses a separate method to provide the response. This means you have to clear the response if the next keytool call does not need it. This also means you cannot run keytool in multiple threads. I didn't provide the response as an extra argument because there are already many overloaded keytool() methods, and I do not want to invent a new method name (say, keytoolWithResponse) and implement the same number of overloaded methods. If you are strongly against this solution, I'll think of another way. The jdk change includes a test for this change, as well as a trivial fix for keytool's getYesNoReply() method. Otherwise an NPE is thrown with the following command: cat untrusted.cert | keytool -importcert -alias a Thanks Max From sean.mullan at oracle.com Wed Jan 18 21:23:10 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 Jan 2017 16:23:10 -0500 Subject: RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default In-Reply-To: References: Message-ID: On 1/13/17 2:38 AM, Mandy Chung wrote: > >> On Jan 9, 2017, at 11:25 AM, Sean Mullan >> wrote: >> >> Please review this JDK 9 change to make the >> SecurityManager::checkPackageAccess and checkPackageDefinition >> implementations restrict access to the same set of internal JDK >> packages as the module system. >> >> This overall change will improve security by making these two >> mechanisms consistent and reduce the amount of work needed to >> maintain the package.access and package.definition security >> properties going forward. >> >> JBS issue: https://bugs.openjdk.java.net/browse/JDK-8055206 JDK >> webrev: >> http://cr.openjdk.java.net/~mullan/webrevs/8055206/jdk/webrev.00/ >> JAXP webrev: >> http://cr.openjdk.java.net/~mullan/webrevs/8055206/jaxp/webrev.00/ >> > > This looks quite good. It?s good that the restricted package list > for the system modules is no longer modifiable. This change may > impact existing applications that are running with security manager > and uses a JDK internal API from the runtime that was not in the > package.access list. It may require the application to grant > additional ?accessClassInPackage.? permissions in addition to > using `?-add-exports` to break into encapsulation. Correct. > Similar to the feedback I suggest for JDK-8168075. We can move this > initialization to the holder class and trigger the initialization in > the SecurityManager constructor. For now, I would prefer to leave it as is. In an earlier revision, I experimented with delaying the initialization of nonExportedPkgs until checkPackageAccess was called and ran into some circular permission checking issues. It could be moving it to the ctor is ok, but since I have every test passing right now, I'd rather not tinker with it :) >> : Several tests also had to be modified to be granted additional >> permission(s) to access the newly restricted packages under a >> SecurityManager. JAXP also needed a change to grant additional >> permissions to access internal packages that are exported to the >> modules that are dynamically created for use with XSLT. > > We will have to see if any dynamic generated bytecode in the field > will need access to internal API like XSLT case. Yes. I have checked several other use cases in the JDK that create dynamic modules (nashorn, rmi, jmx) and not found any issues. > It seems something > not right for a module that has access to an internal package in > another module via qualified exports is required to have > ?accessClassInPackage.? runtime permission. I believe the > ?accessClassInPackage.? permission is checked when a > deprivileged module loads an internal class in a module defined by > the boot loader even if the package of that internal class is > exported to it to access. I do think we should follow up and look > into the potential solutions to respect the qualified exports. I agree. > In addition, we should file an issue to look into any possibility to > respect `?-add-exports` if specified (perhaps automatically add an > entry in the default policy?). I?m okay to follow up these with > separate JBS issues. Will do. > Otherwise looks good. Mandy Thanks, Sean From mandy.chung at oracle.com Wed Jan 18 21:25:48 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Jan 2017 13:25:48 -0800 Subject: RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default In-Reply-To: References: Message-ID: <2ED35CE6-8755-4ED0-AE3B-39967060C094@oracle.com> > On Jan 18, 2017, at 1:23 PM, Sean Mullan wrote: > >> Similar to the feedback I suggest for JDK-8168075. We can move this >> initialization to the holder class and trigger the initialization in >> the SecurityManager constructor. > > For now, I would prefer to leave it as is. In an earlier revision, I experimented with delaying the initialization of nonExportedPkgs until checkPackageAccess was called and ran into some circular permission checking issues. It could be moving it to the ctor is ok, but since I have every test passing right now, I'd rather not tinker with it :) Okay with me. > >>> : Several tests also had to be modified to be granted additional >>> permission(s) to access the newly restricted packages under a >>> SecurityManager. JAXP also needed a change to grant additional >>> permissions to access internal packages that are exported to the >>> modules that are dynamically created for use with XSLT. >> >> We will have to see if any dynamic generated bytecode in the field >> will need access to internal API like XSLT case. > > Yes. I have checked several other use cases in the JDK that create dynamic modules (nashorn, rmi, jmx) and not found any issues. Thanks for the confirmation. Mandy From weijun.wang at oracle.com Thu Jan 19 02:40:33 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 19 Jan 2017 10:40:33 +0800 Subject: RFR release notes for multiple enhancements: krb5, SASL, JAAS, policytool Message-ID: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> Hi All Please review the following release notes. For each one, I've listed the JBS URL for the release-note task, the original bug (in parentheses), the synopsis, and the intended release note text: https://bugs.openjdk.java.net/browse/JDK-8173011 (https://bugs.openjdk.java.net/browse/JDK-8029995) accept yes/no for boolean krb5.conf settings krb5.conf now accepts "yes" or "no" for boolean-valued settings. https://bugs.openjdk.java.net/browse/JDK-8173012 (https://bugs.openjdk.java.net/browse/JDK-8044085) Access ExtendedGSSContext.inquireSecContext() result through SASL The output of `ExtendedGSSContext.inquireSecContext()` is now available as negotiated properties for the SASL GSSAPI mechanism using the name "com.sun.security.jgss.inquiretype.", where "type_name" is the string form of the `InquireType` enum parameter in lower case, for example, "com.sun.security.jgss.inquiretype.krb5_get_session_key_ex" for the session key of an established Kerberos 5 security context. https://bugs.openjdk.java.net/browse/JDK-8173014 (https://bugs.openjdk.java.net/browse/JDK-8047789) auth.login.LoginContext needs to be updated to work with modules After this change, besides including the necessary methods (`initialize`, `login`, `logout`, `commit`, `abort`), any login module must implement the `LoginModule` interface. Otherwise a `LoginException` will thrown when the login module is used. https://bugs.openjdk.java.net/browse/JDK-8173015 (https://bugs.openjdk.java.net/browse/JDK-8056174) New APIs for jar signing A new `jdk.security.jarsigner.JarSigner` API is added to the `jdk.jartool` module which can be used to sign a jar file. https://bugs.openjdk.java.net/browse/JDK-8173016 (https://bugs.openjdk.java.net/browse/JDK-8147400) Deprecate policytool The policytool is moved to the `jdk.policytool` and deprecated. https://bugs.openjdk.java.net/browse/JDK-8173017 (https://bugs.openjdk.java.net/browse/JDK-8157848) Deprecate the javax.security.auth.Policy API with forRemoval=true The `javax.security.auth.Policy` class has been deprecated since JDK 1.4 and superseded/replaced by java.security.Policy. It is now marked `forRemoval=true` and will be removed in a future release. Thanks Max From weijun.wang at oracle.com Thu Jan 19 02:45:25 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 19 Jan 2017 10:45:25 +0800 Subject: RFR release notes for multiple enhancements: krb5, SASL, JAAS, policytool In-Reply-To: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> References: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> Message-ID: <656811d6-b474-0ba4-4c71-8d251db2376f@oracle.com> One more: https://bugs.openjdk.java.net/browse/JDK-8173018 (https://bugs.openjdk.java.net/browse/JDK-8076535) Deprecate the com.sun.jarsigner package The `com.sun.jarsigner` package is being deprecated. This includes the `ContentSigner` class, the `ContentSignerParameters` interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options. Thanks Max On 01/19/2017 10:40 AM, Weijun Wang wrote: > Hi All > > Please review the following release notes. For each one, I've listed the > JBS URL for the release-note task, the original bug (in parentheses), > the synopsis, and the intended release note text: > > https://bugs.openjdk.java.net/browse/JDK-8173011 > (https://bugs.openjdk.java.net/browse/JDK-8029995) > accept yes/no for boolean krb5.conf settings > > krb5.conf now accepts "yes" or "no" for boolean-valued settings. > > https://bugs.openjdk.java.net/browse/JDK-8173012 > (https://bugs.openjdk.java.net/browse/JDK-8044085) > Access ExtendedGSSContext.inquireSecContext() result through SASL > > The output of `ExtendedGSSContext.inquireSecContext()` is now > available as negotiated properties for the SASL GSSAPI mechanism using > the name "com.sun.security.jgss.inquiretype.", where > "type_name" is the string form of the `InquireType` enum parameter in > lower case, for example, > "com.sun.security.jgss.inquiretype.krb5_get_session_key_ex" for the > session key of an established Kerberos 5 security context. > > https://bugs.openjdk.java.net/browse/JDK-8173014 > (https://bugs.openjdk.java.net/browse/JDK-8047789) > auth.login.LoginContext needs to be updated to work with modules > > After this change, besides including the necessary methods > (`initialize`, `login`, `logout`, `commit`, `abort`), any login module > must implement the `LoginModule` interface. Otherwise a `LoginException` > will thrown when the login module is used. > > https://bugs.openjdk.java.net/browse/JDK-8173015 > (https://bugs.openjdk.java.net/browse/JDK-8056174) > New APIs for jar signing > > A new `jdk.security.jarsigner.JarSigner` API is added to the > `jdk.jartool` module which can be used to sign a jar file. > > https://bugs.openjdk.java.net/browse/JDK-8173016 > (https://bugs.openjdk.java.net/browse/JDK-8147400) > Deprecate policytool > > The policytool is moved to the `jdk.policytool` and deprecated. > > https://bugs.openjdk.java.net/browse/JDK-8173017 > (https://bugs.openjdk.java.net/browse/JDK-8157848) > Deprecate the javax.security.auth.Policy API with forRemoval=true > > The `javax.security.auth.Policy` class has been deprecated since JDK > 1.4 and superseded/replaced by java.security.Policy. It is now marked > `forRemoval=true` and will be removed in a future release. > > Thanks > Max From mandy.chung at oracle.com Thu Jan 19 04:10:33 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 Jan 2017 20:10:33 -0800 Subject: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth Message-ID: Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.00/ sun.security.util.ResourcesMgr::getString(String s, String altBundleName) is one existing mechanism to get the localized string from AuthResources and have sun.security.util.AuthResources resource bundle encapsulated in java.base. jdk.security.auth loads ?sun.security.util.AuthResources? resource bundle in some place and uses ResourcesMgr::getString as well. This patch replaces direct loading of AuthResources resource bundle from jdk.security.auth so that jdk.security.auth does not need to access the resource bundle directly. I ran all core tests. Mandy From artem.smotrakov at oracle.com Thu Jan 19 13:40:42 2017 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 19 Jan 2017 16:40:42 +0300 Subject: RFR 8172975: SecurityTools.keytool() needs to accept user input In-Reply-To: <3d7e0589-3b76-927c-8f79-3b29d4dac12b@oracle.com> References: <3d7e0589-3b76-927c-8f79-3b29d4dac12b@oracle.com> Message-ID: Hi Max, In general, looks okay. Would it be better if it called redirectInput() only if the response file exists? keytool() method might also delete the response file after reading it. These two measures may prevent situations when the response file is unnecessary used. What do you think? Artem On 01/18/2017 05:50 PM, Weijun Wang wrote: > Please review the code changes at > > root: http://cr.openjdk.java.net/~weijun/8172975/root/webrev.00/ > jdk: http://cr.openjdk.java.net/~weijun/8172975/webrev.00/ > > The fix is in root repo. This is not an elegant solution because it > uses a separate method to provide the response. This means you have to > clear the response if the next keytool call does not need it. This > also means you cannot run keytool in multiple threads. > > I didn't provide the response as an extra argument because there are > already many overloaded keytool() methods, and I do not want to invent > a new method name (say, keytoolWithResponse) and implement the same > number of overloaded methods. > > If you are strongly against this solution, I'll think of another way. > > The jdk change includes a test for this change, as well as a trivial > fix for keytool's getYesNoReply() method. Otherwise an NPE is thrown > with the following command: > > cat untrusted.cert | keytool -importcert -alias a > > Thanks > Max From weijun.wang at oracle.com Thu Jan 19 14:15:16 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 19 Jan 2017 22:15:16 +0800 Subject: RFR 8172975: SecurityTools.keytool() needs to accept user input In-Reply-To: References: <3d7e0589-3b76-927c-8f79-3b29d4dac12b@oracle.com> Message-ID: <39d7eee0-1189-30f8-b657-21176adac2c3@oracle.com> On 01/19/2017 09:40 PM, Artem Smotrakov wrote: > Hi Max, > > In general, looks okay. > > Would it be better if it called redirectInput() only if the response > file exists? keytool() method might also delete the response file after > reading it. These two measures may prevent situations when the response > file is unnecessary used. Yes, it's good to remove the file after reading it, so this means people need to set it for every call. On the other hand, I still think creating an empty file and call redirectInput() on it is necessary when the response file does not exist. This prevents the keytool() call from hanging forever if it actually needs user input but the test has not provided any. Also, I am feeling that the jarsigner-related calls are quite complicated. I suggest we use the same method for signing and verifying and ask the user to provide all arguments in their order. So instead of calling SecurityTools.jarsigner("x.jar", "alias", "..."); we just call SecurityTools.jarsigner("... x.jar alias"); This is consistent with keytool(), and we can also provide 3 overloaded forms. What do you think? :-) Thanks Max > > What do you think? > > Artem > > > On 01/18/2017 05:50 PM, Weijun Wang wrote: >> Please review the code changes at >> >> root: http://cr.openjdk.java.net/~weijun/8172975/root/webrev.00/ >> jdk: http://cr.openjdk.java.net/~weijun/8172975/webrev.00/ >> >> The fix is in root repo. This is not an elegant solution because it >> uses a separate method to provide the response. This means you have to >> clear the response if the next keytool call does not need it. This >> also means you cannot run keytool in multiple threads. >> >> I didn't provide the response as an extra argument because there are >> already many overloaded keytool() methods, and I do not want to invent >> a new method name (say, keytoolWithResponse) and implement the same >> number of overloaded methods. >> >> If you are strongly against this solution, I'll think of another way. >> >> The jdk change includes a test for this change, as well as a trivial >> fix for keytool's getYesNoReply() method. Otherwise an NPE is thrown >> with the following command: >> >> cat untrusted.cert | keytool -importcert -alias a >> >> Thanks >> Max > From weijun.wang at oracle.com Thu Jan 19 14:20:49 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 19 Jan 2017 22:20:49 +0800 Subject: RFR release notes for multiple enhancements: krb5, SASL, JAAS, policytool In-Reply-To: <656811d6-b474-0ba4-4c71-8d251db2376f@oracle.com> References: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> <656811d6-b474-0ba4-4c71-8d251db2376f@oracle.com> Message-ID: Another one: https://bugs.openjdk.java.net/browse/JDK-8173035 (https://bugs.openjdk.java.net/browse/JDK-8029904) Remove com.sun.security.auth.callback.DialogCallbackHandler `com.sun.security.auth.callback.DialogCallbackHandler` has been removed in JDK 9. This class, in the JDK-specific extensions to JAAS, was deprecated in JDK 8 and previously flagged for removal. Thanks Max On 01/19/2017 10:45 AM, Weijun Wang wrote: > One more: > > https://bugs.openjdk.java.net/browse/JDK-8173018 > (https://bugs.openjdk.java.net/browse/JDK-8076535) > Deprecate the com.sun.jarsigner package > > The `com.sun.jarsigner` package is being deprecated. This includes > the `ContentSigner` class, the `ContentSignerParameters` interface, and > the jarsigner command's "-altsigner" and "-altsignerpath" options. > > Thanks > Max > > On 01/19/2017 10:40 AM, Weijun Wang wrote: >> Hi All >> >> Please review the following release notes. For each one, I've listed the >> JBS URL for the release-note task, the original bug (in parentheses), >> the synopsis, and the intended release note text: >> >> https://bugs.openjdk.java.net/browse/JDK-8173011 >> (https://bugs.openjdk.java.net/browse/JDK-8029995) >> accept yes/no for boolean krb5.conf settings >> >> krb5.conf now accepts "yes" or "no" for boolean-valued settings. >> >> https://bugs.openjdk.java.net/browse/JDK-8173012 >> (https://bugs.openjdk.java.net/browse/JDK-8044085) >> Access ExtendedGSSContext.inquireSecContext() result through SASL >> >> The output of `ExtendedGSSContext.inquireSecContext()` is now >> available as negotiated properties for the SASL GSSAPI mechanism using >> the name "com.sun.security.jgss.inquiretype.", where >> "type_name" is the string form of the `InquireType` enum parameter in >> lower case, for example, >> "com.sun.security.jgss.inquiretype.krb5_get_session_key_ex" for the >> session key of an established Kerberos 5 security context. >> >> https://bugs.openjdk.java.net/browse/JDK-8173014 >> (https://bugs.openjdk.java.net/browse/JDK-8047789) >> auth.login.LoginContext needs to be updated to work with modules >> >> After this change, besides including the necessary methods >> (`initialize`, `login`, `logout`, `commit`, `abort`), any login module >> must implement the `LoginModule` interface. Otherwise a `LoginException` >> will thrown when the login module is used. >> >> https://bugs.openjdk.java.net/browse/JDK-8173015 >> (https://bugs.openjdk.java.net/browse/JDK-8056174) >> New APIs for jar signing >> >> A new `jdk.security.jarsigner.JarSigner` API is added to the >> `jdk.jartool` module which can be used to sign a jar file. >> >> https://bugs.openjdk.java.net/browse/JDK-8173016 >> (https://bugs.openjdk.java.net/browse/JDK-8147400) >> Deprecate policytool >> >> The policytool is moved to the `jdk.policytool` and deprecated. >> >> https://bugs.openjdk.java.net/browse/JDK-8173017 >> (https://bugs.openjdk.java.net/browse/JDK-8157848) >> Deprecate the javax.security.auth.Policy API with forRemoval=true >> >> The `javax.security.auth.Policy` class has been deprecated since JDK >> 1.4 and superseded/replaced by java.security.Policy. It is now marked >> `forRemoval=true` and will be removed in a future release. >> >> Thanks >> Max From adam.petcher at oracle.com Thu Jan 19 15:28:58 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Thu, 19 Jan 2017 10:28:58 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> Message-ID: My last attempt to solve this problem didn't work because some classes needed for string formatting were not loaded by init level 3 in some cases. So I had to backtrack and try a different approach. This patch avoids localization and message formatting when the VM is not booted. In this case, non-localized messages are printed, and simplified message formatting code is used. Once the VM is loaded, messages are localized and formatted in the usual way. http://cr.openjdk.java.net/~apetcher/8168075/webrev.01/ On 1/11/2017 8:34 AM, Adam Petcher wrote: > Please review the following bug fix: > > http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ > > This fixes a bug in which a permission check would try to load > resources while the system class loader is being initialized. > Resources cannot be loaded at this time, so this change ensures that > the resources are loaded earlier. > From jamil.j.nimeh at oracle.com Thu Jan 19 17:14:45 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 19 Jan 2017 09:14:45 -0800 Subject: Review: release note for JDK-8015081 Message-ID: <530be73a-aa90-0712-442e-1d0803b1c3d2@oracle.com> Hello all, Please review this one release note that documents a change in behavior for the Subject class and it's underlying SecureSet collections: Original bug: https://bugs.openjdk.java.net/browse/JDK-8015081 Release note: https://bugs.openjdk.java.net/browse/JDK-8173069 Text of the release note: -------------------------------------- Inputs to Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods. For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided. For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions: * add(), remove(), or contains() provides a null parameter. * addAll(), removeAll(), containsAll() or retainsAll() provides a Collection containing a null element. -------------------------------------- Thanks, --Jamil From xuelei.fan at oracle.com Thu Jan 19 17:37:48 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 19 Jan 2017 09:37:48 -0800 Subject: Code Review Request, JDK-8173066 More verbose debug output for selection of X509 certs Message-ID: <215097d1-ed85-b951-446e-c4e0585bc157@oracle.com> Hi Sean, Would you please review this debug log update for JSSE key manager implementation: http://cr.openjdk.java.net/~xuelei/8173066/webrev.00/ Trivial update, no new regression test. Thanks, Xuelei From sean.coffey at oracle.com Thu Jan 19 17:50:54 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 19 Jan 2017 17:50:54 +0000 Subject: Code Review Request, JDK-8173066 More verbose debug output for selection of X509 certs In-Reply-To: <215097d1-ed85-b951-446e-c4e0585bc157@oracle.com> References: <215097d1-ed85-b951-446e-c4e0585bc157@oracle.com> Message-ID: <8da35c1b-905f-7c3b-8807-8947733e058a@oracle.com> Looks good. Thanks for the quick turn around. regards, Sean. On 19/01/2017 17:37, Xuelei Fan wrote: > Hi Sean, > > Would you please review this debug log update for JSSE key manager > implementation: > > http://cr.openjdk.java.net/~xuelei/8173066/webrev.00/ > > Trivial update, no new regression test. > > Thanks, > Xuelei From xuelei.fan at oracle.com Thu Jan 19 17:57:50 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 19 Jan 2017 09:57:50 -0800 Subject: RFR release notes for multiple enhancements: krb5, SASL, JAAS, policytool In-Reply-To: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> References: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> Message-ID: On 1/18/2017 6:40 PM, Weijun Wang wrote: > https://bugs.openjdk.java.net/browse/JDK-8173011 > (https://bugs.openjdk.java.net/browse/JDK-8029995) > accept yes/no for boolean krb5.conf settings > > krb5.conf now accepts "yes" or "no" for boolean-valued settings. Looks fine to me. May be nice to state "yes" is equivalent to "true", and "no" is equivalent to "false" (with an example?). Xuelei From anthony.scarpino at oracle.com Thu Jan 19 19:39:13 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 19 Jan 2017 11:39:13 -0800 Subject: RFR 8172527: Rename jdk.crypto.token to jdk.crypto.cryptoki Message-ID: <56378996-fc6c-aef6-9ff9-f87dee6ae0f7@oracle.com> Hi, I need a review to rename the jdk.crypto.token to jdk.crypto.cryptoki. This is to change what 8171202 had done to the original jdk.crypto.pkcs11 module. For those not familiar with discussions elsewhere, the term "token" is confusing and unclear as it can mean many things cryptographically. The use of cryptoki is more accurate to the original 'pkcs11' name and still conforming to the new naming standard. http://cr.openjdk.java.net/~ascarpino/8172527/webrev-root/ http://cr.openjdk.java.net/~ascarpino/8172527/webrev-jdk/ thanks Tony From mandy.chung at oracle.com Thu Jan 19 19:50:17 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Jan 2017 11:50:17 -0800 Subject: RFR 8172527: Rename jdk.crypto.token to jdk.crypto.cryptoki In-Reply-To: <56378996-fc6c-aef6-9ff9-f87dee6ae0f7@oracle.com> References: <56378996-fc6c-aef6-9ff9-f87dee6ae0f7@oracle.com> Message-ID: <397405C0-6063-40A0-9308-E1D346ADEE84@oracle.com> > On Jan 19, 2017, at 11:39 AM, Anthony Scarpino wrote: > > Hi, > > I need a review to rename the jdk.crypto.token to jdk.crypto.cryptoki. This is to change what 8171202 had done to the original jdk.crypto.pkcs11 module. For those not familiar with discussions elsewhere, the term "token" is confusing and unclear as it can mean many things cryptographically. The use of cryptoki is more accurate to the original 'pkcs11' name and still conforming to the new naming standard. > > http://cr.openjdk.java.net/~ascarpino/8172527/webrev-root/ > http://cr.openjdk.java.net/~ascarpino/8172527/webrev-jdk/ The webrev shows deleted/new files for src/jdk.crypto.token source files rather than rename. Did you use hg rename? Changes in other files looks good. Mandy From bradford.wetmore at oracle.com Thu Jan 19 22:13:32 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Thu, 19 Jan 2017 14:13:32 -0800 Subject: RFR 8172527: Rename jdk.crypto.token to jdk.crypto.cryptoki In-Reply-To: <397405C0-6063-40A0-9308-E1D346ADEE84@oracle.com> References: <56378996-fc6c-aef6-9ff9-f87dee6ae0f7@oracle.com> <397405C0-6063-40A0-9308-E1D346ADEE84@oracle.com> Message-ID: Similar problem about the rename. rename or addremove (likely) should work, but hg add/hg remove won't. To check that all references to jdk.crypto.{token,pkcs11} are gone, I ran a test over lunch and applied the webrev patches to a clean workspace. There was a problem applying the jdk webrev via gpatch on Solaris. This may be a bug in gpatch or pilot error, but please check it out. patching file src/jdk.crypto.token/share/classes/sun/security/pkcs11/P11Signature.java Reversed (or previously applied) patch detected! Assume -R? [n] Then at the end of the gpatch, these files were left in the directory. src/jdk.crypto.token/share/classes/sun/security/pkcs11: P11Signature.java P11Signature.java.orig P11Signature.java.rej Otherwise, everything seems to be fine. Brad On 1/19/2017 11:50 AM, Mandy Chung wrote: > >> On Jan 19, 2017, at 11:39 AM, Anthony Scarpino wrote: >> >> Hi, >> >> I need a review to rename the jdk.crypto.token to jdk.crypto.cryptoki. This is to change what 8171202 had done to the original jdk.crypto.pkcs11 module. For those not familiar with discussions elsewhere, the term "token" is confusing and unclear as it can mean many things cryptographically. The use of cryptoki is more accurate to the original 'pkcs11' name and still conforming to the new naming standard. >> >> http://cr.openjdk.java.net/~ascarpino/8172527/webrev-root/ >> http://cr.openjdk.java.net/~ascarpino/8172527/webrev-jdk/ > > The webrev shows deleted/new files for src/jdk.crypto.token source files rather than rename. Did you use hg rename? > > Changes in other files looks good. > > Mandy > From jamil.j.nimeh at oracle.com Thu Jan 19 22:26:04 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 19 Jan 2017 14:26:04 -0800 Subject: RFR release notes for multiple enhancements: krb5, SASL, JAAS, policytool In-Reply-To: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> References: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> Message-ID: <510ff542-8969-4cf2-942d-a051b963faf8@oracle.com> Hi Max, just one nit for JDK-8044085: The release note is one sentence, but it is a bit of a run-on. It might be worth breaking it up into two sentences, the first for the description and the second containing the example. Aside from that they look good to me. --Jamil On 1/18/2017 6:40 PM, Weijun Wang wrote: > Hi All > > Please review the following release notes. For each one, I've listed > the JBS URL for the release-note task, the original bug (in > parentheses), the synopsis, and the intended release note text: > > https://bugs.openjdk.java.net/browse/JDK-8173011 > (https://bugs.openjdk.java.net/browse/JDK-8029995) > accept yes/no for boolean krb5.conf settings > > krb5.conf now accepts "yes" or "no" for boolean-valued settings. > > https://bugs.openjdk.java.net/browse/JDK-8173012 > (https://bugs.openjdk.java.net/browse/JDK-8044085) > Access ExtendedGSSContext.inquireSecContext() result through SASL > > The output of `ExtendedGSSContext.inquireSecContext()` is now > available as negotiated properties for the SASL GSSAPI mechanism using > the name "com.sun.security.jgss.inquiretype.", where > "type_name" is the string form of the `InquireType` enum parameter in > lower case, for example, > "com.sun.security.jgss.inquiretype.krb5_get_session_key_ex" for the > session key of an established Kerberos 5 security context. > > https://bugs.openjdk.java.net/browse/JDK-8173014 > (https://bugs.openjdk.java.net/browse/JDK-8047789) > auth.login.LoginContext needs to be updated to work with modules > > After this change, besides including the necessary methods > (`initialize`, `login`, `logout`, `commit`, `abort`), any login module > must implement the `LoginModule` interface. Otherwise a > `LoginException` will thrown when the login module is used. > > https://bugs.openjdk.java.net/browse/JDK-8173015 > (https://bugs.openjdk.java.net/browse/JDK-8056174) > New APIs for jar signing > > A new `jdk.security.jarsigner.JarSigner` API is added to the > `jdk.jartool` module which can be used to sign a jar file. > > https://bugs.openjdk.java.net/browse/JDK-8173016 > (https://bugs.openjdk.java.net/browse/JDK-8147400) > Deprecate policytool > > The policytool is moved to the `jdk.policytool` and deprecated. > > https://bugs.openjdk.java.net/browse/JDK-8173017 > (https://bugs.openjdk.java.net/browse/JDK-8157848) > Deprecate the javax.security.auth.Policy API with forRemoval=true > > The `javax.security.auth.Policy` class has been deprecated since > JDK 1.4 and superseded/replaced by java.security.Policy. It is now > marked `forRemoval=true` and will be removed in a future release. > > Thanks > Max From weijun.wang at oracle.com Fri Jan 20 00:08:21 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 20 Jan 2017 08:08:21 +0800 Subject: RFR release notes for multiple enhancements: krb5, SASL, JAAS, policytool In-Reply-To: References: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> Message-ID: <32879900-0aa0-0d88-c24d-b62f8d04b651@oracle.com> On 01/20/2017 01:57 AM, Xuelei Fan wrote: > On 1/18/2017 6:40 PM, Weijun Wang wrote: >> https://bugs.openjdk.java.net/browse/JDK-8173011 >> (https://bugs.openjdk.java.net/browse/JDK-8029995) >> accept yes/no for boolean krb5.conf settings >> >> krb5.conf now accepts "yes" or "no" for boolean-valued settings. > Looks fine to me. May be nice to state "yes" is equivalent to "true", > and "no" is equivalent to "false" (with an example?). Good idea, but maybe an example is too much. I assume people will understand it easily. Furthermore, this is mainly for interop with MIT krb5. If someone already has a "setting = yes" I don't want Java krb5 to misunderstand it. This RFE is not intended to persuade people using the new values. Thanks Max > > Xuelei From artem.smotrakov at oracle.com Fri Jan 20 09:01:08 2017 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 20 Jan 2017 12:01:08 +0300 Subject: RFR 8172975: SecurityTools.keytool() needs to accept user input In-Reply-To: <39d7eee0-1189-30f8-b657-21176adac2c3@oracle.com> References: <3d7e0589-3b76-927c-8f79-3b29d4dac12b@oracle.com> <39d7eee0-1189-30f8-b657-21176adac2c3@oracle.com> Message-ID: <240311c4-2b15-a263-1950-496612710e2b@oracle.com> Hi Max, Please see inline. On 01/19/2017 05:15 PM, Weijun Wang wrote: > > > On 01/19/2017 09:40 PM, Artem Smotrakov wrote: >> Hi Max, >> >> In general, looks okay. >> >> Would it be better if it called redirectInput() only if the response >> file exists? keytool() method might also delete the response file after >> reading it. These two measures may prevent situations when the response >> file is unnecessary used. > > Yes, it's good to remove the file after reading it, so this means > people need to set it for every call. > > On the other hand, I still think creating an empty file and call > redirectInput() on it is necessary when the response file does not > exist. This prevents the keytool() call from hanging forever if it > actually needs user input but the test has not provided any. It looks like a test issue with particular test, I don't remember many tests which failed because of this. > > Also, I am feeling that the jarsigner-related calls are quite > complicated. I suggest we use the same method for signing and > verifying and ask the user to provide all arguments in their order. So > instead of calling > > SecurityTools.jarsigner("x.jar", "alias", "..."); > > we just call > > SecurityTools.jarsigner("... x.jar alias"); This looks better to me as well. I am fine with current webrevs. Artem > > This is consistent with keytool(), and we can also provide 3 > overloaded forms. > > What do you think? :-) > > Thanks > Max > >> >> What do you think? >> >> Artem >> >> >> On 01/18/2017 05:50 PM, Weijun Wang wrote: >>> Please review the code changes at >>> >>> root: http://cr.openjdk.java.net/~weijun/8172975/root/webrev.00/ >>> jdk: http://cr.openjdk.java.net/~weijun/8172975/webrev.00/ >>> >>> The fix is in root repo. This is not an elegant solution because it >>> uses a separate method to provide the response. This means you have to >>> clear the response if the next keytool call does not need it. This >>> also means you cannot run keytool in multiple threads. >>> >>> I didn't provide the response as an extra argument because there are >>> already many overloaded keytool() methods, and I do not want to invent >>> a new method name (say, keytoolWithResponse) and implement the same >>> number of overloaded methods. >>> >>> If you are strongly against this solution, I'll think of another way. >>> >>> The jdk change includes a test for this change, as well as a trivial >>> fix for keytool's getYesNoReply() method. Otherwise an NPE is thrown >>> with the following command: >>> >>> cat untrusted.cert | keytool -importcert -alias a >>> >>> Thanks >>> Max >> From weijun.wang at oracle.com Fri Jan 20 09:23:59 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 20 Jan 2017 17:23:59 +0800 Subject: RFR 8172975: SecurityTools.keytool() needs to accept user input In-Reply-To: <240311c4-2b15-a263-1950-496612710e2b@oracle.com> References: <3d7e0589-3b76-927c-8f79-3b29d4dac12b@oracle.com> <39d7eee0-1189-30f8-b657-21176adac2c3@oracle.com> <240311c4-2b15-a263-1950-496612710e2b@oracle.com> Message-ID: <1b0d6cdf-f5df-9ff2-154d-39249c517421@oracle.com> On 01/20/2017 05:01 PM, Artem Smotrakov wrote: > Hi Max, > > Please see inline. > > > On 01/19/2017 05:15 PM, Weijun Wang wrote: >> >> >> On 01/19/2017 09:40 PM, Artem Smotrakov wrote: >>> Hi Max, >>> >>> In general, looks okay. >>> >>> Would it be better if it called redirectInput() only if the response >>> file exists? keytool() method might also delete the response file after >>> reading it. These two measures may prevent situations when the response >>> file is unnecessary used. >> >> Yes, it's good to remove the file after reading it, so this means >> people need to set it for every call. >> >> On the other hand, I still think creating an empty file and call >> redirectInput() on it is necessary when the response file does not >> exist. This prevents the keytool() call from hanging forever if it >> actually needs user input but the test has not provided any. > It looks like a test issue with particular test, I don't remember many > tests which failed because of this. It's certainly a test issue, but I'd like it to fail fast. There were no test failing like this now. I notice this because I am working on JDK-8171319 to add more warnings and promptings to keytool and several tests timeout. >> >> Also, I am feeling that the jarsigner-related calls are quite >> complicated. I suggest we use the same method for signing and >> verifying and ask the user to provide all arguments in their order. So >> instead of calling >> >> SecurityTools.jarsigner("x.jar", "alias", "..."); >> >> we just call >> >> SecurityTools.jarsigner("... x.jar alias"); > This looks better to me as well. > > I am fine with current webrevs. A little confused. Do you think the current webrev is fine or is it better to rewrite jarsigner()? Thanks Max > > Artem >> >> This is consistent with keytool(), and we can also provide 3 >> overloaded forms. >> >> What do you think? :-) >> >> Thanks >> Max >> >>> >>> What do you think? >>> >>> Artem >>> >>> >>> On 01/18/2017 05:50 PM, Weijun Wang wrote: >>>> Please review the code changes at >>>> >>>> root: http://cr.openjdk.java.net/~weijun/8172975/root/webrev.00/ >>>> jdk: http://cr.openjdk.java.net/~weijun/8172975/webrev.00/ >>>> >>>> The fix is in root repo. This is not an elegant solution because it >>>> uses a separate method to provide the response. This means you have to >>>> clear the response if the next keytool call does not need it. This >>>> also means you cannot run keytool in multiple threads. >>>> >>>> I didn't provide the response as an extra argument because there are >>>> already many overloaded keytool() methods, and I do not want to invent >>>> a new method name (say, keytoolWithResponse) and implement the same >>>> number of overloaded methods. >>>> >>>> If you are strongly against this solution, I'll think of another way. >>>> >>>> The jdk change includes a test for this change, as well as a trivial >>>> fix for keytool's getYesNoReply() method. Otherwise an NPE is thrown >>>> with the following command: >>>> >>>> cat untrusted.cert | keytool -importcert -alias a >>>> >>>> Thanks >>>> Max >>> > From artem.smotrakov at oracle.com Fri Jan 20 11:23:58 2017 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 20 Jan 2017 14:23:58 +0300 Subject: RFR 8172975: SecurityTools.keytool() needs to accept user input In-Reply-To: <1b0d6cdf-f5df-9ff2-154d-39249c517421@oracle.com> References: <3d7e0589-3b76-927c-8f79-3b29d4dac12b@oracle.com> <39d7eee0-1189-30f8-b657-21176adac2c3@oracle.com> <240311c4-2b15-a263-1950-496612710e2b@oracle.com> <1b0d6cdf-f5df-9ff2-154d-39249c517421@oracle.com> Message-ID: <81529176-0814-0355-0185-65fbb596993f@oracle.com> It's up to you. You can change it now if you have time, or we can do it once we need to update jarsigner tests. Artem On 01/20/2017 12:23 PM, Weijun Wang wrote: >>> Also, I am feeling that the jarsigner-related calls are quite >>> complicated. I suggest we use the same method for signing and >>> verifying and ask the user to provide all arguments in their order. So >>> instead of calling >>> >>> SecurityTools.jarsigner("x.jar", "alias", "..."); >>> >>> we just call >>> >>> SecurityTools.jarsigner("... x.jar alias"); >> This looks better to me as well. >> >> I am fine with current webrevs. > > A little confused. Do you think the current webrev is fine or is it > better to rewrite jarsigner()? -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Jan 20 11:44:28 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 20 Jan 2017 19:44:28 +0800 Subject: RFR 8172975: SecurityTools.keytool() needs to accept user input In-Reply-To: <81529176-0814-0355-0185-65fbb596993f@oracle.com> References: <3d7e0589-3b76-927c-8f79-3b29d4dac12b@oracle.com> <39d7eee0-1189-30f8-b657-21176adac2c3@oracle.com> <240311c4-2b15-a263-1950-496612710e2b@oracle.com> <1b0d6cdf-f5df-9ff2-154d-39249c517421@oracle.com> <81529176-0814-0355-0185-65fbb596993f@oracle.com> Message-ID: <859e67f1-f921-cb6b-625a-c8b63be9c708@oracle.com> Updated http://cr.openjdk.java.net/~weijun/8172975/root/webrev.01/ http://cr.openjdk.java.net/~weijun/8172975/webrev.01/ I'll need this in my other work. Thanks Max On 01/20/2017 07:23 PM, Artem Smotrakov wrote: > It's up to you. You can change it now if you have time, or we can do it > once we need to update jarsigner tests. > > Artem From artem.smotrakov at oracle.com Fri Jan 20 12:01:02 2017 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 20 Jan 2017 15:01:02 +0300 Subject: RFR 8172975: SecurityTools.keytool() needs to accept user input In-Reply-To: <859e67f1-f921-cb6b-625a-c8b63be9c708@oracle.com> References: <3d7e0589-3b76-927c-8f79-3b29d4dac12b@oracle.com> <39d7eee0-1189-30f8-b657-21176adac2c3@oracle.com> <240311c4-2b15-a263-1950-496612710e2b@oracle.com> <1b0d6cdf-f5df-9ff2-154d-39249c517421@oracle.com> <81529176-0814-0355-0185-65fbb596993f@oracle.com> <859e67f1-f921-cb6b-625a-c8b63be9c708@oracle.com> Message-ID: <770c21ec-7436-a19a-7824-02254a512887@oracle.com> It might be better to remove the response file in a finally block. Main.java needs new copyright year. Otherwise, looks fine. I see you removed public sign() and verify() methods in SecurityTools, please make sure that they are not used by other tests. Artem On 01/20/2017 02:44 PM, Weijun Wang wrote: > Updated > > http://cr.openjdk.java.net/~weijun/8172975/root/webrev.01/ > http://cr.openjdk.java.net/~weijun/8172975/webrev.01/ > > I'll need this in my other work. > > Thanks > Max > > On 01/20/2017 07:23 PM, Artem Smotrakov wrote: >> It's up to you. You can change it now if you have time, or we can do it >> once we need to update jarsigner tests. >> >> Artem > From weijun.wang at oracle.com Fri Jan 20 12:18:11 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 20 Jan 2017 20:18:11 +0800 Subject: RFR 8172975: SecurityTools.keytool() needs to accept user input In-Reply-To: <770c21ec-7436-a19a-7824-02254a512887@oracle.com> References: <3d7e0589-3b76-927c-8f79-3b29d4dac12b@oracle.com> <39d7eee0-1189-30f8-b657-21176adac2c3@oracle.com> <240311c4-2b15-a263-1950-496612710e2b@oracle.com> <1b0d6cdf-f5df-9ff2-154d-39249c517421@oracle.com> <81529176-0814-0355-0185-65fbb596993f@oracle.com> <859e67f1-f921-cb6b-625a-c8b63be9c708@oracle.com> <770c21ec-7436-a19a-7824-02254a512887@oracle.com> Message-ID: <96e44eb3-0c0e-46f7-bcb2-f5d3eb03a01f@oracle.com> Thanks. All suggestions accepted. Will push after updated. --Max On 01/20/2017 08:01 PM, Artem Smotrakov wrote: > It might be better to remove the response file in a finally block. > Main.java needs new copyright year. > > Otherwise, looks fine. > > I see you removed public sign() and verify() methods in SecurityTools, > please make sure that they are not used by other tests. > > Artem > > > On 01/20/2017 02:44 PM, Weijun Wang wrote: >> Updated >> >> http://cr.openjdk.java.net/~weijun/8172975/root/webrev.01/ >> http://cr.openjdk.java.net/~weijun/8172975/webrev.01/ >> >> I'll need this in my other work. >> >> Thanks >> Max >> >> On 01/20/2017 07:23 PM, Artem Smotrakov wrote: >>> It's up to you. You can change it now if you have time, or we can do it >>> once we need to update jarsigner tests. >>> >>> Artem >> > From anthony.scarpino at oracle.com Fri Jan 20 18:22:09 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 20 Jan 2017 10:22:09 -0800 Subject: RFR 8172527: Rename jdk.crypto.token to jdk.crypto.cryptoki In-Reply-To: <397405C0-6063-40A0-9308-E1D346ADEE84@oracle.com> References: <56378996-fc6c-aef6-9ff9-f87dee6ae0f7@oracle.com> <397405C0-6063-40A0-9308-E1D346ADEE84@oracle.com> Message-ID: <706c8cff-5687-9858-d3ff-15a17981aa5b@oracle.com> On 01/19/2017 11:50 AM, Mandy Chung wrote: > >> On Jan 19, 2017, at 11:39 AM, Anthony Scarpino wrote: >> >> Hi, >> >> I need a review to rename the jdk.crypto.token to jdk.crypto.cryptoki. This is to change what 8171202 had done to the original jdk.crypto.pkcs11 module. For those not familiar with discussions elsewhere, the term "token" is confusing and unclear as it can mean many things cryptographically. The use of cryptoki is more accurate to the original 'pkcs11' name and still conforming to the new naming standard. >> >> http://cr.openjdk.java.net/~ascarpino/8172527/webrev-root/ >> http://cr.openjdk.java.net/~ascarpino/8172527/webrev-jdk/ > > The webrev shows deleted/new files for src/jdk.crypto.token source files rather than rename. Did you use hg rename? > > Changes in other files looks good. > > Mandy > Good catch.. that'll teach me for trusting the graphical tool to rename a directory when I used 'Rename'. Also I found Brad's issue as it was a new changeset that just showed up in that file. I updated the webrev, which looks better now: http://cr.openjdk.java.net/~ascarpino/8172527/webrev-jdk.01/ Tony From mandy.chung at oracle.com Fri Jan 20 23:57:48 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 Jan 2017 15:57:48 -0800 Subject: RFR 8172527: Rename jdk.crypto.token to jdk.crypto.cryptoki In-Reply-To: <706c8cff-5687-9858-d3ff-15a17981aa5b@oracle.com> References: <56378996-fc6c-aef6-9ff9-f87dee6ae0f7@oracle.com> <397405C0-6063-40A0-9308-E1D346ADEE84@oracle.com> <706c8cff-5687-9858-d3ff-15a17981aa5b@oracle.com> Message-ID: > On Jan 20, 2017, at 10:22 AM, Anthony Scarpino wrote: > > Good catch.. that'll teach me for trusting the graphical tool to rename a directory when I used 'Rename'. > > Also I found Brad's issue as it was a new changeset that just showed up in that file. > > I updated the webrev, which looks better now: > http://cr.openjdk.java.net/~ascarpino/8172527/webrev-jdk.01/ +1 Mandy From mandy.chung at oracle.com Sat Jan 21 21:55:55 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 21 Jan 2017 13:55:55 -0800 Subject: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth In-Reply-To: References: Message-ID: <9FBDA48E-B142-48FC-83ED-EE369F7E4C18@oracle.com> Since AuthResources is the only altBundle, Max suggests to replace getString(String, String) with a method for AuthResources bundle specifically. It?s an alternative I considered too. Here is the revised webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.01/ Mandy > On Jan 18, 2017, at 8:10 PM, Mandy Chung wrote: > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.00/ > > sun.security.util.ResourcesMgr::getString(String s, String altBundleName) is one existing mechanism to get the localized string from AuthResources and have sun.security.util.AuthResources resource bundle encapsulated in java.base. > > jdk.security.auth loads ?sun.security.util.AuthResources? resource bundle in some place and uses ResourcesMgr::getString as well. > > This patch replaces direct loading of AuthResources resource bundle from jdk.security.auth so that jdk.security.auth does not need to access the resource bundle directly. > > I ran all core tests. > > Mandy From weijun.wang at oracle.com Sun Jan 22 01:02:46 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 22 Jan 2017 09:02:46 +0800 Subject: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth In-Reply-To: <9FBDA48E-B142-48FC-83ED-EE369F7E4C18@oracle.com> References: <9FBDA48E-B142-48FC-83ED-EE369F7E4C18@oracle.com> Message-ID: Why isn't the new getAuthResourceString() using AccessController.doPrivileged anymore? Thanks Max On 01/22/2017 05:55 AM, Mandy Chung wrote: > Since AuthResources is the only altBundle, Max suggests to replace getString(String, String) with a method for AuthResources bundle specifically. It?s an alternative I considered too. Here is the revised webrev: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.01/ > > Mandy > >> On Jan 18, 2017, at 8:10 PM, Mandy Chung wrote: >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.00/ >> >> sun.security.util.ResourcesMgr::getString(String s, String altBundleName) is one existing mechanism to get the localized string from AuthResources and have sun.security.util.AuthResources resource bundle encapsulated in java.base. >> >> jdk.security.auth loads ?sun.security.util.AuthResources? resource bundle in some place and uses ResourcesMgr::getString as well. >> >> This patch replaces direct loading of AuthResources resource bundle from jdk.security.auth so that jdk.security.auth does not need to access the resource bundle directly. >> >> I ran all core tests. >> >> Mandy > From mandy.chung at oracle.com Sun Jan 22 01:18:10 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 21 Jan 2017 17:18:10 -0800 Subject: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth In-Reply-To: References: <9FBDA48E-B142-48FC-83ED-EE369F7E4C18@oracle.com> Message-ID: AFAIK, no permission check from RB::getBundle loading this resource bundle. The implementation should wrap all security sensitive calls with doPriv. I also mentioned that in [1] I have a simple test that calls new X500Principal(null) and it runs fine with security manager. Mandy [1] http://mail.openjdk.java.net/pipermail/security-dev/2017-January/015436.html > On Jan 21, 2017, at 5:02 PM, Weijun Wang wrote: > > Why isn't the new getAuthResourceString() using AccessController.doPrivileged anymore? > > Thanks > Max > > On 01/22/2017 05:55 AM, Mandy Chung wrote: >> Since AuthResources is the only altBundle, Max suggests to replace getString(String, String) with a method for AuthResources bundle specifically. It?s an alternative I considered too. Here is the revised webrev: >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.01/ >> >> Mandy >> >>> On Jan 18, 2017, at 8:10 PM, Mandy Chung wrote: >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.00/ >>> >>> sun.security.util.ResourcesMgr::getString(String s, String altBundleName) is one existing mechanism to get the localized string from AuthResources and have sun.security.util.AuthResources resource bundle encapsulated in java.base. >>> >>> jdk.security.auth loads ?sun.security.util.AuthResources? resource bundle in some place and uses ResourcesMgr::getString as well. >>> >>> This patch replaces direct loading of AuthResources resource bundle from jdk.security.auth so that jdk.security.auth does not need to access the resource bundle directly. >>> >>> I ran all core tests. >>> >>> Mandy >> From weijun.wang at oracle.com Sun Jan 22 02:37:11 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 22 Jan 2017 10:37:11 +0800 Subject: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth In-Reply-To: References: <9FBDA48E-B142-48FC-83ED-EE369F7E4C18@oracle.com> Message-ID: <3012726f-00a9-c431-c049-0419edb1fe01@oracle.com> On 01/22/2017 09:18 AM, Mandy Chung wrote: > AFAIK, no permission check from RB::getBundle loading this resource bundle. The implementation should wrap all security sensitive calls with doPriv. I also mentioned that in [1] I see. It just feels strange to see getString() and getAuthResourcesString() implemented so differently in this webrev. Since you think they should be the same, how about creating a private method that includes the VM.initLevel and bundles.computeIfAbsent calls? We'll let Adam to decide if getString() can also call it. Thanks Max > > I have a simple test that calls new X500Principal(null) and it runs fine with security manager. > > Mandy > [1] http://mail.openjdk.java.net/pipermail/security-dev/2017-January/015436.html > >> On Jan 21, 2017, at 5:02 PM, Weijun Wang wrote: >> >> Why isn't the new getAuthResourceString() using AccessController.doPrivileged anymore? >> >> Thanks >> Max >> >> On 01/22/2017 05:55 AM, Mandy Chung wrote: >>> Since AuthResources is the only altBundle, Max suggests to replace getString(String, String) with a method for AuthResources bundle specifically. It?s an alternative I considered too. Here is the revised webrev: >>> >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.01/ >>> >>> Mandy >>> >>>> On Jan 18, 2017, at 8:10 PM, Mandy Chung wrote: >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173024/webrev.00/ >>>> >>>> sun.security.util.ResourcesMgr::getString(String s, String altBundleName) is one existing mechanism to get the localized string from AuthResources and have sun.security.util.AuthResources resource bundle encapsulated in java.base. >>>> >>>> jdk.security.auth loads ?sun.security.util.AuthResources? resource bundle in some place and uses ResourcesMgr::getString as well. >>>> >>>> This patch replaces direct loading of AuthResources resource bundle from jdk.security.auth so that jdk.security.auth does not need to access the resource bundle directly. >>>> >>>> I ran all core tests. >>>> >>>> Mandy >>> > From mandy.chung at oracle.com Sun Jan 22 04:02:59 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 21 Jan 2017 20:02:59 -0800 Subject: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth In-Reply-To: <3012726f-00a9-c431-c049-0419edb1fe01@oracle.com> References: <9FBDA48E-B142-48FC-83ED-EE369F7E4C18@oracle.com> <3012726f-00a9-c431-c049-0419edb1fe01@oracle.com> Message-ID: <072845C6-A2FE-4AD5-B43E-2B5E478037DB@oracle.com> > On Jan 21, 2017, at 6:37 PM, Weijun Wang wrote: > > > > On 01/22/2017 09:18 AM, Mandy Chung wrote: >> AFAIK, no permission check from RB::getBundle loading this resource bundle. The implementation should wrap all security sensitive calls with doPriv. I also mentioned that in [1] > > I see. > > It just feels strange to see getString() and getAuthResourcesString() implemented so differently in this webrev. Since you think they should be the same, how about creating a private method that includes the VM.initLevel and bundles.computeIfAbsent calls? We'll let Adam to decide if getString() can also call it. > I agree it looks strange but I hope Adam can leverage that. It?s better to leave it for the fix for JDK-8168075. Do you approve this fix? Mandy From weijun.wang at oracle.com Sun Jan 22 04:18:14 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 22 Jan 2017 12:18:14 +0800 Subject: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth In-Reply-To: <072845C6-A2FE-4AD5-B43E-2B5E478037DB@oracle.com> References: <9FBDA48E-B142-48FC-83ED-EE369F7E4C18@oracle.com> <3012726f-00a9-c431-c049-0419edb1fe01@oracle.com> <072845C6-A2FE-4AD5-B43E-2B5E478037DB@oracle.com> Message-ID: <2f4d70b3-03f5-ff19-60a8-5ee9865a764b@oracle.com> On 01/22/2017 12:02 PM, Mandy Chung wrote: > >> On Jan 21, 2017, at 6:37 PM, Weijun Wang wrote: >> >> >> >> On 01/22/2017 09:18 AM, Mandy Chung wrote: >>> AFAIK, no permission check from RB::getBundle loading this resource bundle. The implementation should wrap all security sensitive calls with doPriv. I also mentioned that in [1] >> >> I see. >> >> It just feels strange to see getString() and getAuthResourcesString() implemented so differently in this webrev. Since you think they should be the same, how about creating a private method that includes the VM.initLevel and bundles.computeIfAbsent calls? We'll let Adam to decide if getString() can also call it. >> > > I agree it looks strange but I hope Adam can leverage that. It?s better to leave it for the fix for JDK-8168075. > > Do you approve this fix? Yes. --Max > > Mandy > > From weijun.wang at oracle.com Sun Jan 22 09:34:06 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 22 Jan 2017 17:34:06 +0800 Subject: RFR release notes for multiple enhancements: krb5, SASL, JAAS, policytool In-Reply-To: <510ff542-8969-4cf2-942d-a051b963faf8@oracle.com> References: <732cd15e-967a-7125-224c-138e7641ea77@oracle.com> <510ff542-8969-4cf2-942d-a051b963faf8@oracle.com> Message-ID: <4a66e7ce-b0e4-facf-8328-6357059f4107@oracle.com> Hi Jamil Many thanks to the review. How do you think of the other two in my follow up mails? > https://bugs.openjdk.java.net/browse/JDK-8173035 > (https://bugs.openjdk.java.net/browse/JDK-8029904) Remove > com.sun.security.auth.callback.DialogCallbackHandler > > `com.sun.security.auth.callback.DialogCallbackHandler` has been > removed in JDK 9. This class, in the JDK-specific extensions to JAAS, > was deprecated in JDK 8 and previously flagged for removal. > >> https://bugs.openjdk.java.net/browse/JDK-8173018 >> (https://bugs.openjdk.java.net/browse/JDK-8076535) Deprecate the >> com.sun.jarsigner package >> >> The `com.sun.jarsigner` package is being deprecated. This includes >> the `ContentSigner` class, the `ContentSignerParameters` interface, >> and the jarsigner command's "-altsigner" and "-altsignerpath" >> options. >> Thanks Max On 01/20/2017 06:26 AM, Jamil Nimeh wrote: > Hi Max, just one nit for JDK-8044085: > > The release note is one sentence, but it is a bit of a run-on. It > might be worth breaking it up into two sentences, the first for the > description and the second containing the example. > > Aside from that they look good to me. From weijun.wang at oracle.com Mon Jan 23 10:02:42 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 23 Jan 2017 18:02:42 +0800 Subject: RFR 8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms Message-ID: <46c26a65-7886-3a64-60f1-808ae07cd028@oracle.com> Hi All Please take a review at http://cr.openjdk.java.net/~weijun/8171319/webrev.00/ Warnings are printed to System.err when weak algorithms/keysizes are detected during the execution, this includes input, output, and any certs used. The detection applies to many keytool functions: - generation of certificate, certificate request, CRL - reading (printing, listing, exporting) of above - importing of certificate or certificates reply The behavior of most functions remains unchanged. The only exception is "keytool -importcert", where the user must reply to a prompt if weak algorithms/keysizes are detected, unless -noprompt is specified on the command line. Warnings are either printed at the end, or before a prompt. If there are multiple weak points, multiple warnings will be printed. The detection is based on the security property jdk.certpath.disabledAlgorithms. For example: $ keytool -genkeypair -alias a -dname CN=a -keyalg RSA -sigalg MD5withRSA Warning: The MD5withRSA signature algorithm is considered a security risk. $ keytool -keystore ks -storepass changeit -keypass changeit -list Keystore type: JKS Keystore provider: SUN Your keystore contains 3 entries b, Jan 23, 2017, PrivateKeyEntry, Certificate fingerprint (SHA-256): D8:46:B7:0B:8B:97:C2:DE:A2:17:62:01:27:82:2B:CE:B1:9B:12:0B:24:D5:47:BF:BD:54:EE:8A:71:29:2B:CE a, Jan 23, 2017, PrivateKeyEntry, Certificate fingerprint (SHA-256): 66:70:DF:11:14:A1:96:58:92:F5:6A:10:09:B1:2F:CC:1C:CC:2D:55:47:1D:EE:74:75:AA:26:63:E4:9D:EA:83 Warning: 's 512-bit RSA key is considered a security risk. 's MD5withRSA signature algorithm is considered a security risk. $ keytool -importcert -alias a -file b+a.certs Warning: Reply #2 of 2's 512-bit RSA key is considered a security risk. Install reply anyway? [no]:no Certificate reply was not installed in keystore Thanks Max From sha.jiang at oracle.com Mon Jan 23 13:17:20 2017 From: sha.jiang at oracle.com (John Jiang) Date: Mon, 23 Jan 2017 21:17:20 +0800 Subject: RFR[9] JDK-8171900: javax/net/ssl/SSLSession/SessionTimeOutTests.java failed with "SSLHandshakeException: Remote host terminated the handshake" Message-ID: Hi, The patch takes some code patterns from SSLSocketTemplate.java to try to resolve the following issues: JDK-8171900: javax/net/ssl/SSLSession/SessionTimeOutTests.java failed with "SSLHandshakeException: Remote host terminated the handshake" JDK-8173142: javax/net/ssl/SSLSession/SessionTimeOutTests.java fails with SocketException: Address already in use Besides the above issues, I also find two more problems. 1. It is too late to set property javax.net.debug. Since the debug flag is false, this problem is not exposed. 2. In theory, the test can take multiple clients to connect to one server, namely MAX_ACTIVE_CONNECTIONS [1] could be greater than PORTS [2]. But this test execution would hang for this case. Because the connections between the client side and server side possibly are not matched if MAX_ACTIVE_CONNECTIONS is not a multiple of PORTS. For example, a client wants to connect to a specified server for 3 times, however, the server can accept only 2 requests. And at the meantime, another server are waiting for 3 connections, but the client side send only 2 requests to it. Since MAX_ACTIVE_CONNECTIONS is equal to PORTS, the problem also doesn't raise in practice, but that still be a bug in logic. Webrev: http://cr.openjdk.java.net/~jjiang/8171900/webrev.00/ [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/57ef255b367b/test/javax/net/ssl/SSLSession/SessionTimeOutTests.java#l109 [2] http://hg.openjdk.java.net/jdk9/dev/jdk/file/57ef255b367b/test/javax/net/ssl/SSLSession/SessionTimeOutTests.java#l78 Best regards, John Jiang -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Mon Jan 23 14:59:08 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 23 Jan 2017 09:59:08 -0500 Subject: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth In-Reply-To: <072845C6-A2FE-4AD5-B43E-2B5E478037DB@oracle.com> References: <9FBDA48E-B142-48FC-83ED-EE369F7E4C18@oracle.com> <3012726f-00a9-c431-c049-0419edb1fe01@oracle.com> <072845C6-A2FE-4AD5-B43E-2B5E478037DB@oracle.com> Message-ID: <54494ee0-e7a2-7085-445f-00b19a7ff2ab@oracle.com> Comments below. On 1/21/2017 11:02 PM, Mandy Chung wrote: >> On Jan 21, 2017, at 6:37 PM, Weijun Wang wrote: >> >> >> >> On 01/22/2017 09:18 AM, Mandy Chung wrote: >>> AFAIK, no permission check from RB::getBundle loading this resource bundle. The implementation should wrap all security sensitive calls with doPriv. I also mentioned that in [1] >> I see. >> >> It just feels strange to see getString() and getAuthResourcesString() implemented so differently in this webrev. Since you think they should be the same, how about creating a private method that includes the VM.initLevel and bundles.computeIfAbsent calls? We'll let Adam to decide if getString() can also call it. >> > I agree it looks strange but I hope Adam can leverage that. It?s better to leave it for the fix for JDK-8168075. Thanks. I've updated JDK-8172808 to indicate that there is some potential for refactoring here. Though it seems like there is an issue with ResourceMgr::getString in your latest diff. The bundle is loaded, but it is not stored in the map (unless I'm missing it). So the resource bundle would be loaded for every call to this method. > > Do you approve this fix? > > Mandy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Jan 23 16:16:48 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Jan 2017 08:16:48 -0800 Subject: Review Request: JDK-8173024 Replace direct use of AuthResources resource bundle from jdk.security.auth In-Reply-To: <54494ee0-e7a2-7085-445f-00b19a7ff2ab@oracle.com> References: <9FBDA48E-B142-48FC-83ED-EE369F7E4C18@oracle.com> <3012726f-00a9-c431-c049-0419edb1fe01@oracle.com> <072845C6-A2FE-4AD5-B43E-2B5E478037DB@oracle.com> <54494ee0-e7a2-7085-445f-00b19a7ff2ab@oracle.com> Message-ID: <54341636-935B-417C-9FA6-F5240E2A4F25@oracle.com> > On Jan 23, 2017, at 6:59 AM, Adam Petcher wrote: > > Comments below. > > On 1/21/2017 11:02 PM, Mandy Chung wrote: >>> On Jan 21, 2017, at 6:37 PM, Weijun Wang wrote: >>> >>> >>> >>> On 01/22/2017 09:18 AM, Mandy Chung wrote: >>>> AFAIK, no permission check from RB::getBundle loading this resource bundle. The implementation should wrap all security sensitive calls with doPriv. I also mentioned that in [1] >>> I see. >>> >>> It just feels strange to see getString() and getAuthResourcesString() implemented so differently in this webrev. Since you think they should be the same, how about creating a private method that includes the VM.initLevel and bundles.computeIfAbsent calls? We'll let Adam to decide if getString() can also call it. >>> >> I agree it looks strange but I hope Adam can leverage that. It?s better to leave it for the fix for JDK-8168075. > > Thanks. I've updated JDK-8172808 to indicate that there is some potential for refactoring here. > > Though it seems like there is an issue with ResourceMgr::getString in your latest diff. The bundle is loaded, but it is not stored in the map (unless I'm missing it). So the resource bundle would be loaded for every call to this method. Good catch. I missed that. The good things is that ResourceBundle is cached after it?s loaded via getBundle method and there should be no loss of performance. I?ll fix it and should probably take JDK-8172808. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Jan 23 17:15:20 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 23 Jan 2017 12:15:20 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> Message-ID: On 1/19/17 10:28 AM, Adam Petcher wrote: > My last attempt to solve this problem didn't work because some classes > needed for string formatting were not loaded by init level 3 in some > cases. So I had to backtrack and try a different approach. > > This patch avoids localization and message formatting when the VM is not > booted. In this case, non-localized messages are printed, and simplified > message formatting code is used. Once the VM is loaded, messages are > localized and formatted in the usual way. > > http://cr.openjdk.java.net/~apetcher/8168075/webrev.01/ Looks good, just a couple of comments: - PolicyUtil.getLocalizedMessage Don't think you need this method, since LocalizedMessage.getLocalizedString is public. - LocalizedMessage.java Not sure I see the need for the constructor or toLocalizedString method, as I think you can just call getLocalizedString, ex: LocalizedMessage localizedMsg = new LocalizedMessage ("alias.name.not.provided.pe.name."); Object[] source = {pe.name}; throw new Exception(localizedMsg.toLocalizedString(source)); becomes: throw new Exception(LocalizedMessage.getLocalizedString("alias.name.not.provided.pe.name.", source)); (saves creating an extra object). - MessageFormatting.java Minor nit: please use "java.security.policy==error.policy" instead of "policy=error.policy" The java.security.policy is a newer jtreg option that matches the syntax of the java.security.policy option. I'd like to discourage use of the policy option going forward. Thanks, Sean > > > On 1/11/2017 8:34 AM, Adam Petcher wrote: >> Please review the following bug fix: >> >> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >> >> This fixes a bug in which a permission check would try to load >> resources while the system class loader is being initialized. >> Resources cannot be loaded at this time, so this change ensures that >> the resources are loaded earlier. >> > From mandy.chung at oracle.com Mon Jan 23 20:06:42 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Jan 2017 12:06:42 -0800 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> Message-ID: > On Jan 19, 2017, at 7:28 AM, Adam Petcher wrote: > > My last attempt to solve this problem didn't work because some classes needed for string formatting were not loaded by init level 3 in some cases. So I had to backtrack and try a different approach. > > This patch avoids localization and message formatting when the VM is not booted. In this case, non-localized messages are printed, and simplified message formatting code is used. Once the VM is loaded, messages are localized and formatted in the usual way. > > http://cr.openjdk.java.net/~apetcher/8168075/webrev.01/ This change looks fine. This will make sure that MessageFormat will be used only after VM is booted. MessageFormatting.java - missing @bug Nit: test/sun/security/util/Resources/ClassLoader - perhaps renaming ?ClassLoader? directory to ?customSysLoader? to make it clear. Mandy From valerie.peng at oracle.com Mon Jan 23 20:28:49 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 23 Jan 2017 12:28:49 -0800 Subject: RFR[9] 8062731: Cipher object can be created without calling Cipher.getInstance Message-ID: <7f32650b-dda8-a860-d548-50e608c99da1@oracle.com> Hi Brad, Would you have time to review this? I changed the code to base the trust decision on the immediate caller of Cipher(CipherSpi, Provider, String). In addition, the specified Provider object is only taken into account when it shares the same origin (codebase or module) with the caller. Webrev: http://cr.openjdk.java.net/~valeriep/8062731/webrev.00/ Thanks, Valerie From anthony.scarpino at oracle.com Mon Jan 23 23:27:34 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 23 Jan 2017 15:27:34 -0800 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties Message-ID: Hi, I need a code review of this change that brings more detail constraints checking and control to certpath and jar disabled algorithm Security properties. http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ thanks Tony From xuelei.fan at oracle.com Tue Jan 24 17:03:00 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 24 Jan 2017 09:03:00 -0800 Subject: RFR[9] JDK-8171900: javax/net/ssl/SSLSession/SessionTimeOutTests.java failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: Hi John, Looks fine to me. Thanks for the update. Xuelei On 1/23/2017 5:17 AM, John Jiang wrote: > Hi, > The patch takes some code patterns from SSLSocketTemplate.java to try to > resolve the following issues: > JDK-8171900: javax/net/ssl/SSLSession/SessionTimeOutTests.java failed > with "SSLHandshakeException: Remote host terminated the handshake" > JDK-8173142: javax/net/ssl/SSLSession/SessionTimeOutTests.java fails > with SocketException: Address already in use > > Besides the above issues, I also find two more problems. > 1. It is too late to set property javax.net.debug. Since the debug flag > is false, this problem is not exposed. > > 2. In theory, the test can take multiple clients to connect to one > server, namely MAX_ACTIVE_CONNECTIONS [1] could be greater than PORTS > [2]. But this test execution would hang for this case. Because the > connections between the client side and server side possibly are not > matched if MAX_ACTIVE_CONNECTIONS is not a multiple of PORTS. > For example, a client wants to connect to a specified server for 3 > times, however, the server can accept only 2 requests. And at the > meantime, another server are waiting for 3 connections, but the client > side send only 2 requests to it. > Since MAX_ACTIVE_CONNECTIONS is equal to PORTS, the problem also doesn't > raise in practice, but that still be a bug in logic. > > Webrev: http://cr.openjdk.java.net/~jjiang/8171900/webrev.00/ > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/file/57ef255b367b/test/javax/net/ssl/SSLSession/SessionTimeOutTests.java#l109 > [2] > http://hg.openjdk.java.net/jdk9/dev/jdk/file/57ef255b367b/test/javax/net/ssl/SSLSession/SessionTimeOutTests.java#l78 > > Best regards, > John Jiang > From adam.petcher at oracle.com Tue Jan 24 17:38:06 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 24 Jan 2017 12:38:06 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> Message-ID: <469f5c61-3a61-7ac7-25b3-d7fd73d28879@oracle.com> Thanks Sean and Mandy for the feedback. I believe I incorporated all feedback into the latest patch, with one exception (Sean see below). http://cr.openjdk.java.net/~apetcher/8168075/webrev.02/ On 1/23/2017 12:15 PM, Sean Mullan wrote: > On 1/19/17 10:28 AM, Adam Petcher wrote: >> My last attempt to solve this problem didn't work because some classes >> needed for string formatting were not loaded by init level 3 in some >> cases. So I had to backtrack and try a different approach. >> >> This patch avoids localization and message formatting when the VM is not >> booted. In this case, non-localized messages are printed, and simplified >> message formatting code is used. Once the VM is loaded, messages are >> localized and formatted in the usual way. >> >> http://cr.openjdk.java.net/~apetcher/8168075/webrev.01/ > > Looks good, just a couple of comments: > > - PolicyUtil.getLocalizedMessage > > Don't think you need this method, since > LocalizedMessage.getLocalizedString is public. Removed. I also renamed LocalizedMessage.getLocalizedString to "getMessage" to remove some redundancy and make the expressions that reference it shorter. > > - LocalizedMessage.java > > Not sure I see the need for the constructor or toLocalizedString > method, as I think you can just call getLocalizedString, ex: > > LocalizedMessage localizedMsg = new LocalizedMessage > ("alias.name.not.provided.pe.name."); > Object[] source = {pe.name}; > throw new Exception(localizedMsg.toLocalizedString(source)); > > becomes: > > throw new > Exception(LocalizedMessage.getLocalizedString("alias.name.not.provided.pe.name.", > source)); In PolicyParser.ParsingException, there is a comment stating that the MessageFormat is stored in the exception, and it is only formatted when getLocalizedMessage() is called on the exception. This arrangement avoids unnecessary formatting and permission checks in cases where the message is never localized and formatted. I kept this arrangement after I replaced MessageFormat with LocalizedMessage. If there is no value to delaying/avoiding the message formatting, then I can remove the constructor and non-static method as you suggest. Here are the changes I made based on this feedback: 1) I changed the name of LocalizedMessage.toLocalizedString to "format" to make it more clear that I was trying to mirror the behavior of MessageFormat (and also to shorten the name and remove redundancy). 2) I added a comment to the constructor describing how it can be used to delay/avoid message formatting. 3) I changed all references to LocalizedMessage that don't involve ParsingException to use only the static method of LocalizedMessage, as you suggested. > > (saves creating an extra object). > > - MessageFormatting.java > > Minor nit: please use "java.security.policy==error.policy" instead of > "policy=error.policy" The java.security.policy is a newer jtreg option > that matches the syntax of the java.security.policy option. I'd like > to discourage use of the policy option going forward. > > Thanks, > Sean > > >> >> >> On 1/11/2017 8:34 AM, Adam Petcher wrote: >>> Please review the following bug fix: >>> >>> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/ >>> >>> This fixes a bug in which a permission check would try to load >>> resources while the system class loader is being initialized. >>> Resources cannot be loaded at this time, so this change ensures that >>> the resources are loaded earlier. >>> >> From sean.mullan at oracle.com Tue Jan 24 19:17:01 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 24 Jan 2017 14:17:01 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <469f5c61-3a61-7ac7-25b3-d7fd73d28879@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <469f5c61-3a61-7ac7-25b3-d7fd73d28879@oracle.com> Message-ID: <7ec804a3-1890-c527-2bb1-bc55942189f3@oracle.com> On 1/24/17 12:38 PM, Adam Petcher wrote: > Thanks Sean and Mandy for the feedback. I believe I incorporated all > feedback into the latest patch, with one exception (Sean see below). > > http://cr.openjdk.java.net/~apetcher/8168075/webrev.02/ > > In PolicyParser.ParsingException, there is a comment stating that the > MessageFormat is stored in the exception, and it is only formatted when > getLocalizedMessage() is called on the exception. This arrangement > avoids unnecessary formatting and permission checks in cases where the > message is never localized and formatted. I kept this arrangement after > I replaced MessageFormat with LocalizedMessage. If there is no value to > delaying/avoiding the message formatting, then I can remove the > constructor and non-static method as you suggest. Ok I see. I think now you better leave that code as is since it was added as part of JDK-8150468. > Here are the changes I made based on this feedback: > 1) I changed the name of LocalizedMessage.toLocalizedString to "format" > to make it more clear that I was trying to mirror the behavior of > MessageFormat (and also to shorten the name and remove redundancy). > 2) I added a comment to the constructor describing how it can be used to > delay/avoid message formatting. > 3) I changed all references to LocalizedMessage that don't involve > ParsingException to use only the static method of LocalizedMessage, as > you suggested. It looks like there is a leftover import for PolicyUtil in PolicyParser.java. Otherwise looks good and I can push this fix for you after you send me an updated patch/webrev. --Sean From xuelei.fan at oracle.com Tue Jan 24 19:24:26 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 24 Jan 2017 11:24:26 -0800 Subject: Code Review Request, JDK-8172869 4096 is not supported yet for the DH Parameter Generator Message-ID: <1ac58fee-e1a9-2214-83ff-56b2052c6194@oracle.com> Hi, Please review this spec documentation update: http://cr.openjdk.java.net/~xuelei/8172869/webrev.00/ In the java.security.AlgorithmParameterGenerator specification, 4096 bits DH parameter generator is specified as a required feature. However, the 4096 bits DH parameter generator is not supported yet in JDK. Although the 4096 bits DH key generation is supported, but it uses the predefined DH parameters. This update removes the 4096 bits DH parameter generator requirement from the java.security.AlgorithmParameterGenerator specification. Thanks, Xuelei From anthony.scarpino at oracle.com Tue Jan 24 19:46:34 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 24 Jan 2017 11:46:34 -0800 Subject: Code Review Request, JDK-8172869 4096 is not supported yet for the DH Parameter Generator In-Reply-To: <1ac58fee-e1a9-2214-83ff-56b2052c6194@oracle.com> References: <1ac58fee-e1a9-2214-83ff-56b2052c6194@oracle.com> Message-ID: <9f8971e5-cbae-f42f-9d68-b0028636f290@oracle.com> On 01/24/2017 11:24 AM, Xuelei Fan wrote: > Hi, > > Please review this spec documentation update: > http://cr.openjdk.java.net/~xuelei/8172869/webrev.00/ > > In the java.security.AlgorithmParameterGenerator specification, 4096 > bits DH parameter generator is specified as a required feature. > > However, the 4096 bits DH parameter generator is not supported yet in > JDK. Although the 4096 bits DH key generation is supported, but it uses > the predefined DH parameters. > > This update removes the 4096 bits DH parameter generator requirement > from the java.security.AlgorithmParameterGenerator specification. > > Thanks, > Xuelei The change looks fine, but does it make sense to mention that 4k bit DH uses predefined parameters in the this section or somewhere else? Tony From adam.petcher at oracle.com Tue Jan 24 19:48:26 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 24 Jan 2017 14:48:26 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <7ec804a3-1890-c527-2bb1-bc55942189f3@oracle.com> References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <469f5c61-3a61-7ac7-25b3-d7fd73d28879@oracle.com> <7ec804a3-1890-c527-2bb1-bc55942189f3@oracle.com> Message-ID: On 1/24/2017 2:17 PM, Sean Mullan wrote: > > It looks like there is a leftover import for PolicyUtil in > PolicyParser.java. Otherwise looks good and I can push this fix for > you after you send me an updated patch/webrev. > > --Sean Fixed in the latest webrev: http://cr.openjdk.java.net/~apetcher/8168075/webrev.03/ I also added the missing @test tag that Mandy requested and I neglected to include in webrev.02. From xuelei.fan at oracle.com Tue Jan 24 20:09:03 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 24 Jan 2017 12:09:03 -0800 Subject: Code Review Request, JDK-8172869 4096 is not supported yet for the DH Parameter Generator In-Reply-To: <9f8971e5-cbae-f42f-9d68-b0028636f290@oracle.com> References: <1ac58fee-e1a9-2214-83ff-56b2052c6194@oracle.com> <9f8971e5-cbae-f42f-9d68-b0028636f290@oracle.com> Message-ID: <4e2f5683-29ad-ffe8-fafa-719d7cec406b@oracle.com> On 1/24/2017 11:46 AM, Anthony Scarpino wrote: > On 01/24/2017 11:24 AM, Xuelei Fan wrote: >> Hi, >> >> Please review this spec documentation update: >> http://cr.openjdk.java.net/~xuelei/8172869/webrev.00/ >> >> In the java.security.AlgorithmParameterGenerator specification, 4096 >> bits DH parameter generator is specified as a required feature. >> >> However, the 4096 bits DH parameter generator is not supported yet in >> JDK. Although the 4096 bits DH key generation is supported, but it uses >> the predefined DH parameters. >> >> This update removes the 4096 bits DH parameter generator requirement >> from the java.security.AlgorithmParameterGenerator specification. >> >> Thanks, >> Xuelei > > The change looks fine, but does it make sense to mention that 4k bit DH > uses predefined parameters in the this section or somewhere else? > As it is an implementation details of JDK, I was wondering to state it in the KeyPairGenerator section in Oracle Providers documentation. I filed a sub-task of JDK-8015388 to track this doc update. https://bugs.openjdk.java.net/browse/JDK-8173298 Thanks, Xuelei From mandy.chung at oracle.com Tue Jan 24 20:14:27 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 24 Jan 2017 12:14:27 -0800 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <469f5c61-3a61-7ac7-25b3-d7fd73d28879@oracle.com> <7ec804a3-1890-c527-2bb1-bc55942189f3@oracle.com> Message-ID: > On Jan 24, 2017, at 11:48 AM, Adam Petcher wrote: > > > On 1/24/2017 2:17 PM, Sean Mullan wrote: >> >> It looks like there is a leftover import for PolicyUtil in PolicyParser.java. Otherwise looks good and I can push this fix for you after you send me an updated patch/webrev. >> >> --Sean > > Fixed in the latest webrev: http://cr.openjdk.java.net/~apetcher/8168075/webrev.03/ > I also added the missing @test tag that Mandy requested and I neglected to include in webrev.02. +1 Mandy From sean.mullan at oracle.com Tue Jan 24 21:00:04 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 24 Jan 2017 16:00:04 -0500 Subject: Code Review Request, JDK-8172869 4096 is not supported yet for the DH Parameter Generator In-Reply-To: <1ac58fee-e1a9-2214-83ff-56b2052c6194@oracle.com> References: <1ac58fee-e1a9-2214-83ff-56b2052c6194@oracle.com> Message-ID: <0ace183a-6e1e-512d-d869-245d130aa5d3@oracle.com> Looks good. --Sean On 1/24/17 2:24 PM, Xuelei Fan wrote: > Hi, > > Please review this spec documentation update: > http://cr.openjdk.java.net/~xuelei/8172869/webrev.00/ > > In the java.security.AlgorithmParameterGenerator specification, 4096 > bits DH parameter generator is specified as a required feature. > > However, the 4096 bits DH parameter generator is not supported yet in > JDK. Although the 4096 bits DH key generation is supported, but it uses > the predefined DH parameters. > > This update removes the 4096 bits DH parameter generator requirement > from the java.security.AlgorithmParameterGenerator specification. > > Thanks, > Xuelei From mandy.chung at oracle.com Tue Jan 24 22:25:00 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 24 Jan 2017 14:25:00 -0800 Subject: Review Request JDK-8172808: Handle sun.security.util.Resources bundle in ResourcesMgr in the same way as AuthResources Message-ID: <085A6260-1F38-4BE3-B065-CC018E9731A2@oracle.com> Adam, Sean, Can you review this simple fix: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172808/webrev.00/ This change updates ResourcesMgr to handle both Resources and AuthResources consistently. This removes doPrivileged block because it is not really needed. This is covered by an existing test, jdk/test/sun/security/util/Resources/Format.java. I ran all core tests to verify as well. Mandy From weijun.wang at oracle.com Wed Jan 25 01:20:32 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 25 Jan 2017 09:20:32 +0800 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <469f5c61-3a61-7ac7-25b3-d7fd73d28879@oracle.com> <7ec804a3-1890-c527-2bb1-bc55942189f3@oracle.com> Message-ID: The copyright header for src is different from that for test. You need to mention the "Classpath" exception. --Max On 01/25/2017 03:48 AM, Adam Petcher wrote: > > On 1/24/2017 2:17 PM, Sean Mullan wrote: >> >> It looks like there is a leftover import for PolicyUtil in >> PolicyParser.java. Otherwise looks good and I can push this fix for >> you after you send me an updated patch/webrev. >> >> --Sean > > Fixed in the latest webrev: > http://cr.openjdk.java.net/~apetcher/8168075/webrev.03/ > I also added the missing @test tag that Mandy requested and I neglected > to include in webrev.02. > From mandy.chung at oracle.com Wed Jan 25 16:37:01 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 Jan 2017 08:37:01 -0800 Subject: Review Request JDK-8172808: Handle sun.security.util.Resources bundle in ResourcesMgr in the same way as AuthResources In-Reply-To: <085A6260-1F38-4BE3-B065-CC018E9731A2@oracle.com> References: <085A6260-1F38-4BE3-B065-CC018E9731A2@oracle.com> Message-ID: <97082FA0-726E-4BBB-B3EA-4C8F87ED1E8D@oracle.com> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172808/webrev.01/ This includes a simple patch from Adam to fixup the copyright headers in the fix for JDK-8168075. Mandy > On Jan 24, 2017, at 2:25 PM, Mandy Chung wrote: > > Adam, Sean, > > Can you review this simple fix: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172808/webrev.00/ > > This change updates ResourcesMgr to handle both Resources > and AuthResources consistently. This removes doPrivileged > block because it is not really needed. This is covered by > an existing test, jdk/test/sun/security/util/Resources/Format.java. > > I ran all core tests to verify as well. > > Mandy > From sean.mullan at oracle.com Wed Jan 25 16:50:10 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 25 Jan 2017 11:50:10 -0500 Subject: Review Request JDK-8172808: Handle sun.security.util.Resources bundle in ResourcesMgr in the same way as AuthResources In-Reply-To: <97082FA0-726E-4BBB-B3EA-4C8F87ED1E8D@oracle.com> References: <085A6260-1F38-4BE3-B065-CC018E9731A2@oracle.com> <97082FA0-726E-4BBB-B3EA-4C8F87ED1E8D@oracle.com> Message-ID: Looks good. --Sean On 1/25/17 11:37 AM, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172808/webrev.01/ > > This includes a simple patch from Adam to fixup the copyright headers in the fix for JDK-8168075. > > Mandy > >> On Jan 24, 2017, at 2:25 PM, Mandy Chung wrote: >> >> Adam, Sean, >> >> Can you review this simple fix: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172808/webrev.00/ >> >> This change updates ResourcesMgr to handle both Resources >> and AuthResources consistently. This removes doPrivileged >> block because it is not really needed. This is covered by >> an existing test, jdk/test/sun/security/util/Resources/Format.java. >> >> I ran all core tests to verify as well. >> >> Mandy >> > From adam.petcher at oracle.com Wed Jan 25 16:53:10 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 25 Jan 2017 11:53:10 -0500 Subject: RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: References: <23b2be13-c4ed-1e8f-14e7-0315d9905261@oracle.com> <469f5c61-3a61-7ac7-25b3-d7fd73d28879@oracle.com> <7ec804a3-1890-c527-2bb1-bc55942189f3@oracle.com> Message-ID: <976aa355-2988-d265-9904-0256dfee653b@oracle.com> Thanks. The fix for 8168075 was already pushed, but Mandy agreed to correct the copyright headers along with the other cleanup activity she is doing for 8172808. On 1/24/2017 8:20 PM, Weijun Wang wrote: > The copyright header for src is different from that for test. You need > to mention the "Classpath" exception. > > --Max > > On 01/25/2017 03:48 AM, Adam Petcher wrote: >> >> On 1/24/2017 2:17 PM, Sean Mullan wrote: >>> >>> It looks like there is a leftover import for PolicyUtil in >>> PolicyParser.java. Otherwise looks good and I can push this fix for >>> you after you send me an updated patch/webrev. >>> >>> --Sean >> >> Fixed in the latest webrev: >> http://cr.openjdk.java.net/~apetcher/8168075/webrev.03/ >> I also added the missing @test tag that Mandy requested and I neglected >> to include in webrev.02. >> From christoph.dreis at freenet.de Fri Jan 13 12:29:37 2017 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Fri, 13 Jan 2017 13:29:37 +0100 Subject: RFR: 8037325: Class.getConstructor() performance regression Message-ID: <000001d26d98$b50e8550$1f2b8ff0$@freenet.de> Hey, your extraction of methodName() made me aware of another small thing. What about rewriting argumentTypesToString() to avoid creating the StringJoiner if not needed? private static String argumentTypesToString(Class[] argTypes) { if (argTypes != null) { StringJoiner sj = new StringJoiner(", ", "(", ")"); for (int i = 0; i < argTypes.length; i++) { Class c = argTypes[i]; sj.add((c == null) ? "null" : c.getName()); } return sj.toString(); } return "()"; } Should have a very minor impact though. Apart from that looks good to me. Cheers, Christoph -----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Claes Redestad Sent: Thursday, January 12, 2017 3:48 PM To: core-libs-dev Libs ; Security Dev OpenJDK Subject: RFR: 8037325: Class.getConstructor() performance regression Hi, please review this fix to various performance regressions observed as the security model has evolved over the years. Bug: https://bugs.openjdk.java.net/browse/JDK-8037325 Webrev: http://cr.openjdk.java.net/~redestad/8037325/webrev.01 - For cases where a SecurityManager is not installed, this improves performance by avoiding calls to Reflection.getCallerClass, which can be very expensive when not inlined. Regrettably this adds some boilerplate. - For cases where a SecurityManager is installed, this improves performance slightly by avoiding repeated calls to System.getSecurityManager (which does volatile read). - Use of Class.getPackageName when appropriate reduce the number of allocations done. - Places where doPrivileged calls were used to bypass access checking when calling methods on Class can safely be replaced by calling corresponding private methods directly if care is taken to copy the end result as appropriate. - Finally, by using the recently used ReflectionFactory.getExecutableSharedParameterTypes we also get rid of some unnecessary copying. Thanks! /Claes From doug.simon at oracle.com Mon Jan 23 21:56:58 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 23 Jan 2017 22:56:58 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied Message-ID: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a security manager is present. Since neither of these modules is accessible to application code, it should be ok to give them all permissions. This seems to be the approach for a number of other modules including jdk.scripting.nashorn, jdk.dynalink, jdk.jsobject etc. Please review this small change that configures this proposed permission level. http://cr.openjdk.java.net/~dnsimon/8145337/webrev/ https://bugs.openjdk.java.net/browse/JDK-8145337 -Doug From bradford.wetmore at oracle.com Thu Jan 26 01:15:57 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 25 Jan 2017 17:15:57 -0800 Subject: RFR[9] 8062731: Cipher object can be created without calling Cipher.getInstance In-Reply-To: <7f32650b-dda8-a860-d548-50e608c99da1@oracle.com> References: <7f32650b-dda8-a860-d548-50e608c99da1@oracle.com> Message-ID: Looks ok. One minor nit: 258: indention problem. Brad On 1/23/2017 12:28 PM, Valerie Peng wrote: > Hi Brad, > > Would you have time to review this? I changed the code to base the trust > decision on the immediate caller of Cipher(CipherSpi, Provider, String). > In addition, the specified Provider object is only taken into account > when it shares the same origin (codebase or module) with the caller. > > Webrev: http://cr.openjdk.java.net/~valeriep/8062731/webrev.00/ > > Thanks, > > Valerie > From valerie.peng at oracle.com Thu Jan 26 02:12:34 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 25 Jan 2017 18:12:34 -0800 Subject: RFR[9] 8062731: Cipher object can be created without calling Cipher.getInstance In-Reply-To: References: <7f32650b-dda8-a860-d548-50e608c99da1@oracle.com> Message-ID: <05ed20f7-37ae-477b-0635-80e3d6efaf76@oracle.com> Fixed, thanks for the review! Valerie On 1/25/2017 5:15 PM, Bradford Wetmore wrote: > Looks ok. > > One minor nit: > > 258: indention problem. > > Brad > > > On 1/23/2017 12:28 PM, Valerie Peng wrote: >> Hi Brad, >> >> Would you have time to review this? I changed the code to base the trust >> decision on the immediate caller of Cipher(CipherSpi, Provider, String). >> In addition, the specified Provider object is only taken into account >> when it shares the same origin (codebase or module) with the caller. >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8062731/webrev.00/ >> >> Thanks, >> >> Valerie >> From mandy.chung at oracle.com Thu Jan 26 02:32:38 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 Jan 2017 18:32:38 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> Message-ID: <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> (dropping jdk9-dev. security-libs is the appropriate list to review security permission) > On Jan 23, 2017, at 1:56 PM, Doug Simon wrote: > > Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a security manager is present. Since neither of these modules is accessible to application code, it should be ok to give them all permissions. This seems to be the approach for a number of other modules including jdk.scripting.nashorn, jdk.dynalink, jdk.jsobject etc. Please review this small change that configures this proposed permission level. > > http://cr.openjdk.java.net/~dnsimon/8145337/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8145337 jdk.vm.compiler is defined by the application class loader and it?s used by AOT tool. I wonder why it has to run with security manager. You can reference JDK tools such as jdk.compiler and jdk.jlink that are not granted with any permission. Mandy From mandy.chung at oracle.com Thu Jan 26 16:55:20 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 Jan 2017 08:55:20 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> Message-ID: <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> > On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: > >> >> jdk.vm.compiler is defined by the application class loader and it?s used by AOT tool. I wonder why it has to run with security manager. > > Without java.security.AllPermission, the policy for jdk.vm.compiler required to get through a bootstrap (i.e., java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version) is show below (annotated with comments denoting the methods requiring the permissions): > > : Are -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler supported to use at runtime? > There?s no guarantee that this is all the permissions required since not all code paths are exercised during bootstrap. > >> You can reference JDK tools such as jdk.compiler and jdk.jlink that are not granted with any permission. > > Neither of those tools create code and install it in the VM. I don?t think a fine grained SecurityManager policy makes sense for a VM compiler since it could subvert security by compiling/installing malicious code. That is, a VM compiler has to be a trusted component. Keep in mind that user code cannot get to jdk.vm.compiler. My question is not about granting fine-grained permissions vs AllPermissions. I expect jdk.vm.compiler is used with jdk.aot which does not run with security manager. If jdk.vm.compiler is run with VM as JIT and with security manager, the user can set -Djava.security.policy to a security policy configuring the permission for jdk.vm.compiler. grant codeBase "jrt:/jdk.vm.compiler" { permission java.security.AllPermission; }; If -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler are supported, the other question I have is which loader jdk.vm.compiler should be defined? Mandy From doug.simon at oracle.com Thu Jan 26 11:13:30 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 26 Jan 2017 12:13:30 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> Message-ID: <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> > On 26 Jan 2017, at 03:32, Mandy Chung wrote: > > (dropping jdk9-dev. security-libs is the appropriate list to review security permission) > >> On Jan 23, 2017, at 1:56 PM, Doug Simon wrote: >> >> Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a security manager is present. Since neither of these modules is accessible to application code, it should be ok to give them all permissions. This seems to be the approach for a number of other modules including jdk.scripting.nashorn, jdk.dynalink, jdk.jsobject etc. Please review this small change that configures this proposed permission level. >> >> http://cr.openjdk.java.net/~dnsimon/8145337/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8145337 > > jdk.vm.compiler is defined by the application class loader and it?s used by AOT tool. I wonder why it has to run with security manager. Without java.security.AllPermission, the policy for jdk.vm.compiler required to get through a bootstrap (i.e., java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version) is show below (annotated with comments denoting the methods requiring the permissions): grant codeBase "jrt:/jdk.vm.compiler" { // org.graalvm.compiler.hotspot.HotSpotGraalJVMCIServiceLocator. permission jdk.vm.ci.services.JVMCIPermission; // org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.getSavedProperties permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.misc"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; // org.graalvm.compiler.core.common.util.ModuleAPI. permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.module"; // org.graalvm.compiler.options.OptionValue. permission java.util.PropertyPermission "graal.profileOptionValue", "read"; // org.graalvm.compiler.debug.Debug. permission java.util.PropertyPermission "*", "read,write"; // org.graalvm.compiler.core.common.UnsafeAccess.initUnsafe permission java.lang.RuntimePermission "accessClassInPackage.sun.misc"; // org.graalvm.compiler.hotspot.BootstrapWatchDog. permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; // org.graalvm.compiler.hotspot.replacements.SHA2Substitutions. permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider"; // org.graalvm.compiler.nodes.graphbuilderconf.InvocationPlugins.resolveClass permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.oracle.jrockit.jfr.jdkevents"; }; There?s no guarantee that this is all the permissions required since not all code paths are exercised during bootstrap. > You can reference JDK tools such as jdk.compiler and jdk.jlink that are not granted with any permission. Neither of those tools create code and install it in the VM. I don?t think a fine grained SecurityManager policy makes sense for a VM compiler since it could subvert security by compiling/installing malicious code. That is, a VM compiler has to be a trusted component. Keep in mind that user code cannot get to jdk.vm.compiler. For comparison, below are all the modules currently given java.security.AllPermission by lib/security/default.policy: grant codeBase "jrt:/java.activation" { permission java.security.AllPermission; }; grant codeBase "jrt:/java.compiler" { permission java.security.AllPermission; }; grant codeBase "jrt:/java.corba" { permission java.security.AllPermission; }; grant codeBase "jrt:/jdk.incubator.httpclient" { }; grant codeBase "jrt:/java.scripting" { permission java.security.AllPermission; }; grant codeBase "jrt:/java.security.jgss" { permission java.security.AllPermission; }; grant codeBase "jrt:/java.sql" { permission java.security.AllPermission; }; grant codeBase "jrt:/java.sql.rowset" { permission java.security.AllPermission; }; grant codeBase "jrt:/jdk.dynalink" { permission java.security.AllPermission; }; grant codeBase "jrt:/jdk.internal.le" { permission java.security.AllPermission; }; grant codeBase "jrt:/jdk.jsobject" { permission java.security.AllPermission; }; grant codeBase "jrt:/jdk.naming.dns" { permission java.security.AllPermission; }; grant codeBase "jrt:/jdk.scripting.nashorn" { permission java.security.AllPermission; }; grant codeBase "jrt:/jdk.scripting.nashorn.shell" { permission java.security.AllPermission; }; grant codeBase "jrt:/jdk.security.auth" { permission java.security.AllPermission; }; grant codeBase "jrt:/jdk.security.jgss" { permission java.security.AllPermission; }; From doug.simon at oracle.com Thu Jan 26 17:40:27 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 26 Jan 2017 18:40:27 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> Message-ID: <358DE5D1-E199-4F71-B731-87D0C5323F1D@oracle.com> > On 26 Jan 2017, at 17:55, Mandy Chung wrote: > > >> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: >> >>> >>> jdk.vm.compiler is defined by the application class loader and it?s used by AOT tool. I wonder why it has to run with security manager. >> >> Without java.security.AllPermission, the policy for jdk.vm.compiler required to get through a bootstrap (i.e., java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version) is show below (annotated with comments denoting the methods requiring the permissions): >> >> : > > Are -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler supported to use at runtime? Not sure I understand your question - they cannot be used at any other time apart from runtime. >> There?s no guarantee that this is all the permissions required since not all code paths are exercised during bootstrap. >> >>> You can reference JDK tools such as jdk.compiler and jdk.jlink that are not granted with any permission. >> >> Neither of those tools create code and install it in the VM. I don?t think a fine grained SecurityManager policy makes sense for a VM compiler since it could subvert security by compiling/installing malicious code. That is, a VM compiler has to be a trusted component. Keep in mind that user code cannot get to jdk.vm.compiler. > > My question is not about granting fine-grained permissions vs AllPermissions. I expect jdk.vm.compiler is used with jdk.aot which does not run with security manager. > > If jdk.vm.compiler is run with VM as JIT and with security manager, the user can set -Djava.security.policy to a security policy configuring the permission for jdk.vm.compiler. > > grant codeBase "jrt:/jdk.vm.compiler" { > permission java.security.AllPermission; > }; > > If -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler are supported, the other question I have is which loader jdk.vm.compiler should be defined? I?m no expert on class loaders, but I would guess the same loader as jdk.vm.ci. -Doug From sean.mullan at oracle.com Thu Jan 26 18:36:54 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Jan 2017 13:36:54 -0500 Subject: [9] RFR: 8168423: Test Task: Custom system class loader + security manager + malformed policy file = recursive initialization In-Reply-To: <9deec53c-b568-448d-9d29-be596a2a8814@default> References: <9deec53c-b568-448d-9d29-be596a2a8814@default> Message-ID: Hi Siba, In valid.policy, use 'grant codeBase "file:${test.classes}/*"' so that only the tests are granted the needed permissions. In ClassLoaderTest.java, the @bug should be 8168075. Also, the @summary contains a bunch of lines (29-39) that should probably just be code comments. Seems fine otherwise. --Sean On 1/11/17 10:33 AM, Sibabrata Sahoo wrote: > Hi Adam/Sean, > > > > This patch is waiting for your review. > > > > Thanks, > > Siba > > > > *From:*Sibabrata Sahoo > *Sent:* Friday, December 02, 2016 6:56 PM > *To:* Sean Mullan; security-dev at openjdk.java.net > *Subject:* [9] RFR: 8168423: Test Task: Custom system class loader + > security manager + malformed policy file = recursive initialization > > > > Hi, > > > > Please review the patch for, > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8168423 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8168423/webrev.00/ > > > > Description: > > This webrev address all possible cases for Classloader with > SecurityManager having combination of valid/malformed policy file. This > Test is going to fail until JDK-8168075 get fixed. In the mean time, it > can be used to verify the fix for JDK-8168075. > > > > Here is the generic Logic behind generating all possible Test cases with > different combination of policy file, class loader and module types. > > for(policyFile : {"NO_POLICY", "VALID", "MALFORMED"}) { > > for(classLoader : {"SystemClassLoader", "CustomClassLoader"}){ > > // It uses possible set of regular/modular jars to generate all > possible Test cases in ?cp and ?module-path. > > for(clientModuletype : {"STRICT", "AUTO", "UNKNOWN"}) { > > for(classLoaderModuleType : {"STRICT", "AUTO", "UNKNOWN"}) { > > Create and run java command line for each possible Test > cases and verify result. > > } > > } > > } > > } > > > > Thanks, > > Siba > > > From sean.mullan at oracle.com Thu Jan 26 19:27:25 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Jan 2017 14:27:25 -0500 Subject: Review: release note for JDK-8015081 In-Reply-To: <530be73a-aa90-0712-442e-1d0803b1c3d2@oracle.com> References: <530be73a-aa90-0712-442e-1d0803b1c3d2@oracle.com> Message-ID: In the first sentence I would give the fully qualified name (javax.security.auth.Subject) instead of just Subject to provide a bit more context. Otherwise, looks good. --Sean On 1/19/17 12:14 PM, Jamil Nimeh wrote: > Hello all, > > Please review this one release note that documents a change in behavior > for the Subject class and it's underlying SecureSet collections: > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8015081 > Release note: https://bugs.openjdk.java.net/browse/JDK-8173069 > > Text of the release note: > -------------------------------------- > Inputs to Subject class now prohibit null values in the constructors and > modification operations on the Principal and credential Set objects > returned by Subject methods. > > For the non-default constructor, the principals, pubCredentials, and > privCredentials parameters may not be null, nor may any element within > the Sets be null. A NullPointerException will be thrown if null values > are provided. > > For operations performed on Set objects returned by getPrincipals(), > getPrivateCredentials() and getPublicCredentials(), a > NullPointerException is thrown under the following conditions: > * add(), remove(), or contains() provides a null parameter. > * addAll(), removeAll(), containsAll() or retainsAll() provides a > Collection containing a null element. > -------------------------------------- > > Thanks, > --Jamil From xuelei.fan at oracle.com Thu Jan 26 21:09:47 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 26 Jan 2017 13:09:47 -0800 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: References: Message-ID: <6d5e3b1f-1a92-4789-fb5b-f88f0fc8f1c9@oracle.com> DisabledAlgorithmConstraints.java ================================= public final boolean permits(Set primitives, Key key) { - return checkConstraints(primitives, "", key, null); + try { + permits(new ConstraintsParameters(key.getAlgorithm(), null, key, + null)); + return true; + } catch (CertPathValidatorException e) { + return false; + } } Looks like there are some overlap if this method is not used for cert. What's the point for this update? @@ -172,56 +180,21 @@ - // check the key algorithm - if (!permits(primitives, key.getAlgorithm(), null)) { - return false; - } This block cannot be removed as the standard permits() (seel line 130) still need to this check. Otherwise, looks fine to me. Xuelei On 1/23/2017 3:27 PM, Anthony Scarpino wrote: > Hi, > > I need a code review of this change that brings more detail constraints > checking and control to certpath and jar disabled algorithm Security > properties. > > http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ > > thanks > > Tony From sean.mullan at oracle.com Thu Jan 26 21:57:25 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Jan 2017 16:57:25 -0500 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: References: Message-ID: <7f3ecacd-bc30-3b59-0fc5-2409042c1bd9@oracle.com> Looks good, mostly minor stuff so far, just have one other file I need more time to review: * java.security Update description of new constraints to match CCC. * PKIXExtendedParameters.java Update class description (it is out-of-date). * CertConstraintParameters.java 2 * Copyright (c) 2016, 2017 Oracle and/or its affiliates. All rights reserved. Should be a comma after 2017. * AlgorithmChecker.java 278 String currSigAlg = ((X509Certificate)cert).getSigAlgName(); Just use x509Cert.getSigAlgName() instead * SignatureFileVerifier.java 294 Timestamp[] timestamp = new Timestamp[newSigners.length]; "timestamps" would be more clear as a variable name 299 System.out.println("Timestamp[" + (i - 1) + "] = " + debug.println --Sean On 1/23/17 6:27 PM, Anthony Scarpino wrote: > Hi, > > I need a code review of this change that brings more detail constraints > checking and control to certpath and jar disabled algorithm Security > properties. > > http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ > > thanks > > Tony From sergei.kovalev at oracle.com Fri Jan 27 13:39:38 2017 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Fri, 27 Jan 2017 16:39:38 +0300 Subject: RFR(S): 8173478: SSL related tests failes with message: "java.security.NoSuchAlgorithmException: EC KeyFactory not available" Message-ID: Hi team, Please review a small fix for tests. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8173478 WebReview: http://cr.openjdk.java.net/~skovalev/8173478/webrev.00/ Issue: Three tests failing during execution with module limitation by "--limit-modules" command line option. Solution: declare dependency on jdk.crypto.ec module. -- With best regards, Sergei From xuelei.fan at oracle.com Fri Jan 27 18:12:51 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 27 Jan 2017 10:12:51 -0800 Subject: RFR(S): 8173478: SSL related tests failes with message: "java.security.NoSuchAlgorithmException: EC KeyFactory not available" In-Reply-To: References: Message-ID: Looks fine to me. BTW, if using 'limit-modules" option, some SSL test may behave different if EC modules is excluded. Thanks, Xuelei On 1/27/2017 5:39 AM, Sergei Kovalev wrote: > Hi team, > > Please review a small fix for tests. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8173478 > WebReview: http://cr.openjdk.java.net/~skovalev/8173478/webrev.00/ > > Issue: Three tests failing during execution with module limitation by > "--limit-modules" command line option. > Solution: declare dependency on jdk.crypto.ec module. > From sean.coffey at oracle.com Mon Jan 30 11:31:20 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 30 Jan 2017 11:31:20 +0000 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: <7f3ecacd-bc30-3b59-0fc5-2409042c1bd9@oracle.com> References: <7f3ecacd-bc30-3b59-0fc5-2409042c1bd9@oracle.com> Message-ID: <588F2408.9080204@oracle.com> src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java CertPathValidatorException is caught 3 times in new code but we're not printing out the exact algorithm that caused the exception. AFAIK, that should be in the exception message. Would it be possible to use something e.getMessage() call to print more detail ? You'd have to check for null also. 371 } catch(CertPathValidatorException e) { 372 if (debug != null) { 373 debug.println(key + " uses a disabled algorithm."); 374 } Spacing issue on line 371 of same file : > 371 } catch(CertPathValidatorException e) { Regards, Sean. On 26/01/17 21:57, Sean Mullan wrote: > Looks good, mostly minor stuff so far, just have one other file I need > more time to review: > > * java.security > > Update description of new constraints to match CCC. > > * PKIXExtendedParameters.java > > Update class description (it is out-of-date). > > * CertConstraintParameters.java > > 2 * Copyright (c) 2016, 2017 Oracle and/or its affiliates. All rights > reserved. > > Should be a comma after 2017. > > * AlgorithmChecker.java > > 278 String currSigAlg = ((X509Certificate)cert).getSigAlgName(); > > Just use x509Cert.getSigAlgName() instead > > * SignatureFileVerifier.java > > 294 Timestamp[] timestamp = new Timestamp[newSigners.length]; > > "timestamps" would be more clear as a variable name > > 299 System.out.println("Timestamp[" + (i - 1) + "] = " + > > debug.println > > --Sean > > On 1/23/17 6:27 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this change that brings more detail constraints >> checking and control to certpath and jar disabled algorithm Security >> properties. >> >> http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ >> >> thanks >> >> Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Mon Jan 30 18:21:46 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 30 Jan 2017 10:21:46 -0800 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: <588F2408.9080204@oracle.com> References: <7f3ecacd-bc30-3b59-0fc5-2409042c1bd9@oracle.com> <588F2408.9080204@oracle.com> Message-ID: <76389b6d-b369-59d8-e604-b9f3bde8ed20@oracle.com> Hi Sean, Actually Sean M and I were talking about that offline on thursday. That file is changing a lot. The three sections you mention have changed a lot, but the general idea is the disabled algorithms are captured and reported after all the checks were done. This is because the we can have multiple signatures and one of them maybe allowed. Throwing an exception on the first failure would not pick up a possible second signature that was allowed. thanks Tony On 01/30/2017 03:31 AM, Se?n Coffey wrote: > src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java > > CertPathValidatorException is caught 3 times in new code but we're not > printing out the exact algorithm that caused the exception. AFAIK, that > should be in the exception message. Would it be possible to use > something e.getMessage() call to print more detail ? You'd have to check > for null also. > > 371 } catch(CertPathValidatorException e) { > 372 if (debug != null) { > 373 debug.println(key + " uses a disabled > algorithm."); > 374 } > > Spacing issue on line 371 of same file : > >> 371 } catch(CertPathValidatorException e) { > > Regards, > Sean. > > On 26/01/17 21:57, Sean Mullan wrote: >> Looks good, mostly minor stuff so far, just have one other file I need >> more time to review: >> >> * java.security >> >> Update description of new constraints to match CCC. >> >> * PKIXExtendedParameters.java >> >> Update class description (it is out-of-date). >> >> * CertConstraintParameters.java >> >> 2 * Copyright (c) 2016, 2017 Oracle and/or its affiliates. All rights >> reserved. >> >> Should be a comma after 2017. >> >> * AlgorithmChecker.java >> >> 278 String currSigAlg = ((X509Certificate)cert).getSigAlgName(); >> >> Just use x509Cert.getSigAlgName() instead >> >> * SignatureFileVerifier.java >> >> 294 Timestamp[] timestamp = new Timestamp[newSigners.length]; >> >> "timestamps" would be more clear as a variable name >> >> 299 System.out.println("Timestamp[" + (i - 1) + "] = " + >> >> debug.println >> >> --Sean >> >> On 1/23/17 6:27 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I need a code review of this change that brings more detail constraints >>> checking and control to certpath and jar disabled algorithm Security >>> properties. >>> >>> http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ >>> >>> thanks >>> >>> Tony > From rasbold at google.com Mon Jan 30 19:24:12 2017 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 30 Jan 2017 11:24:12 -0800 Subject: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java Message-ID: Here's a tiny fix for an unintended, but clear, performance regression. I'm not familiar of the current criteria for jdk9 changes. Please advise this mostly HotSpot engineer if / how to move forward. http://cr.openjdk.java.net/~rasbold/8173581/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Jan 30 20:08:09 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 30 Jan 2017 15:08:09 -0500 Subject: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java In-Reply-To: References: Message-ID: <8956ad49-2cea-69f5-83c0-a815ddd170e5@oracle.com> The fix looks ok to me, but I would also like Valerie to review it since she is more familiar with this code. As far as JDK 9 goes, we are in Rampdown Phase 1. According to the rules [1], since it is a P3 and is new in JDK 9 we should try to fix this issue if we can. Were you offering to push this fix or did you want someone in the Security group to take this over from you? --Sean [1] http://openjdk.java.net/projects/jdk9/rdp-1 On 1/30/17 2:24 PM, Chuck Rasbold wrote: > Here's a tiny fix for an unintended, but clear, performance regression. > > I'm not familiar of the current criteria for jdk9 changes. Please advise > this mostly HotSpot engineer if / how to move forward. > > http://cr.openjdk.java.net/~rasbold/8173581/webrev.00/ > From mandy.chung at oracle.com Mon Jan 30 20:55:14 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Jan 2017 12:55:14 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> Message-ID: <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> > On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: > > I?ve extended the webrev with that change - please re-review: > > http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev > +1 > Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. > Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. > BTW, I never answered your question: > > "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? > > It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. Mandy From cthalinger at twitter.com Fri Jan 27 23:40:59 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 27 Jan 2017 13:40:59 -1000 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <358DE5D1-E199-4F71-B731-87D0C5323F1D@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <358DE5D1-E199-4F71-B731-87D0C5323F1D@oracle.com> Message-ID: > On Jan 26, 2017, at 7:40 AM, Doug Simon wrote: > >> >> On 26 Jan 2017, at 17:55, Mandy Chung wrote: >> >> >>> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: >>> >>>> >>>> jdk.vm.compiler is defined by the application class loader and it?s used by AOT tool. I wonder why it has to run with security manager. >>> >>> Without java.security.AllPermission, the policy for jdk.vm.compiler required to get through a bootstrap (i.e., java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version) is show below (annotated with comments denoting the methods requiring the permissions): >>> >>> : >> >> Are -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler supported to use at runtime? > > Not sure I understand your question - they cannot be used at any other time apart from runtime. The question is if these command line options are supported by Oracle in JDK 9. The answer used to be no but that might have changed. Someone from Oracle needs to chime in. Having said that, it would be a shame if we don?t make jdk.vm.compiler a trusted system component because it obviously is. We have to do it at some point anyway so why not now? > >>> There?s no guarantee that this is all the permissions required since not all code paths are exercised during bootstrap. >>> >>>> You can reference JDK tools such as jdk.compiler and jdk.jlink that are not granted with any permission. >>> >>> Neither of those tools create code and install it in the VM. I don?t think a fine grained SecurityManager policy makes sense for a VM compiler since it could subvert security by compiling/installing malicious code. That is, a VM compiler has to be a trusted component. Keep in mind that user code cannot get to jdk.vm.compiler. >> >> My question is not about granting fine-grained permissions vs AllPermissions. I expect jdk.vm.compiler is used with jdk.aot which does not run with security manager. >> >> If jdk.vm.compiler is run with VM as JIT and with security manager, the user can set -Djava.security.policy to a security policy configuring the permission for jdk.vm.compiler. >> >> grant codeBase "jrt:/jdk.vm.compiler" { >> permission java.security.AllPermission; >> }; >> >> If -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler are supported, the other question I have is which loader jdk.vm.compiler should be defined? > > I?m no expert on class loaders, but I would guess the same loader as jdk.vm.ci. > > -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Sun Jan 29 19:34:34 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 29 Jan 2017 11:34:34 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <358DE5D1-E199-4F71-B731-87D0C5323F1D@oracle.com> Message-ID: <62624B55-176D-419D-9E74-3DDAB518B199@oracle.com> > On Jan 27, 2017, at 3:40 PM, Christian Thalinger wrote: > >> >> On Jan 26, 2017, at 7:40 AM, Doug Simon > wrote: >> >>> >>> On 26 Jan 2017, at 17:55, Mandy Chung > wrote: >>> >>> >>>> On Jan 26, 2017, at 3:13 AM, Doug Simon > wrote: >>>> >>>>> >>>>> jdk.vm.compiler is defined by the application class loader and it?s used by AOT tool. I wonder why it has to run with security manager. >>>> >>>> Without java.security.AllPermission, the policy for jdk.vm.compiler required to get through a bootstrap (i.e., java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version) is show below (annotated with comments denoting the methods requiring the permissions): >>>> >>>> : >>> >>> Are -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler supported to use at runtime? >> >> Not sure I understand your question - they cannot be used at any other time apart from runtime. > > The question is if these command line options are supported by Oracle in JDK 9. The answer used to be no but that might have changed. Someone from Oracle needs to chime in. I would imagine that the permissions Doug mentions are required regardless of whether it?s supported on not. igor > > Having said that, it would be a shame if we don?t make jdk.vm.compiler a trusted system component because it obviously is. > > We have to do it at some point anyway so why not now? > >> >>>> There?s no guarantee that this is all the permissions required since not all code paths are exercised during bootstrap. >>>> >>>>> You can reference JDK tools such as jdk.compiler and jdk.jlink that are not granted with any permission. >>>> >>>> Neither of those tools create code and install it in the VM. I don?t think a fine grained SecurityManager policy makes sense for a VM compiler since it could subvert security by compiling/installing malicious code. That is, a VM compiler has to be a trusted component. Keep in mind that user code cannot get to jdk.vm.compiler. >>> >>> My question is not about granting fine-grained permissions vs AllPermissions. I expect jdk.vm.compiler is used with jdk.aot which does not run with security manager. >>> >>> If jdk.vm.compiler is run with VM as JIT and with security manager, the user can set -Djava.security.policy to a security policy configuring the permission for jdk.vm.compiler. >>> >>> grant codeBase "jrt:/jdk.vm.compiler" { >>> permission java.security.AllPermission; >>> }; >>> >>> If -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler are supported, the other question I have is which loader jdk.vm.compiler should be defined? >> >> I?m no expert on class loaders, but I would guess the same loader as jdk.vm.ci. >> >> -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Mon Jan 30 08:13:09 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 30 Jan 2017 09:13:09 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <62624B55-176D-419D-9E74-3DDAB518B199@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <358DE5D1-E199-4F71-B731-87D0C5323F1D@oracle.com> <62624B55-176D-419D-9E74-3DDAB518B199@oracle.com> Message-ID: > On 29 Jan 2017, at 20:34, Igor Veresov wrote: > >> >> On Jan 27, 2017, at 3:40 PM, Christian Thalinger wrote: >> >>> >>> On Jan 26, 2017, at 7:40 AM, Doug Simon wrote: >>> >>>> >>>> On 26 Jan 2017, at 17:55, Mandy Chung wrote: >>>> >>>> >>>>> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: >>>>> >>>>>> >>>>>> jdk.vm.compiler is defined by the application class loader and it?s used by AOT tool. I wonder why it has to run with security manager. >>>>> >>>>> Without java.security.AllPermission, the policy for jdk.vm.compiler required to get through a bootstrap (i.e., java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version) is show below (annotated with comments denoting the methods requiring the permissions): >>>>> >>>>> : >>>> >>>> Are -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler supported to use at runtime? >>> >>> Not sure I understand your question - they cannot be used at any other time apart from runtime. >> >> The question is if these command line options are supported by Oracle in JDK 9. The answer used to be no but that might have changed. Someone from Oracle needs to chime in. > > > I would imagine that the permissions Doug mentions are required regardless of whether it?s supported on not. Correct. Also, sorry for misinterpreting the question Mandy. I thought being experimental means not officially supported. However, I?ve heard that AOT may be supported even though being experimental. In any case, I?m fairly sure using Graal as a JIT is not supported. -Doug >> >> Having said that, it would be a shame if we don?t make jdk.vm.compiler a trusted system component because it obviously is. >> >> We have to do it at some point anyway so why not now? >> >>> >>>>> There?s no guarantee that this is all the permissions required since not all code paths are exercised during bootstrap. >>>>> >>>>>> You can reference JDK tools such as jdk.compiler and jdk.jlink that are not granted with any permission. >>>>> >>>>> Neither of those tools create code and install it in the VM. I don?t think a fine grained SecurityManager policy makes sense for a VM compiler since it could subvert security by compiling/installing malicious code. That is, a VM compiler has to be a trusted component. Keep in mind that user code cannot get to jdk.vm.compiler. >>>> >>>> My question is not about granting fine-grained permissions vs AllPermissions. I expect jdk.vm.compiler is used with jdk.aot which does not run with security manager. >>>> >>>> If jdk.vm.compiler is run with VM as JIT and with security manager, the user can set -Djava.security.policy to a security policy configuring the permission for jdk.vm.compiler. >>>> >>>> grant codeBase "jrt:/jdk.vm.compiler" { >>>> permission java.security.AllPermission; >>>> }; >>>> >>>> If -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler are supported, the other question I have is which loader jdk.vm.compiler should be defined? >>> >>> I?m no expert on class loaders, but I would guess the same loader as jdk.vm.ci. >>> >>> -Doug From doug.simon at oracle.com Mon Jan 30 18:38:35 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 30 Jan 2017 19:38:35 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> Message-ID: <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> > On 30 Jan 2017, at 17:11, Mandy Chung wrote: > > Moving it to platform class loader is okay with me. I?m still unsure if jdk.vm.compiler should be defined by the boot loader instead and you may want to look into in a future release. We also want jdk.vm.compiler to be upgradeable (as discussed in another thread) so that we can test newer development versions of Graal as the VM JIT via --upgrade-module-path instead of having to rebuild the JDK. As far as I understand, this means it cannot be defined by the boot loader. > You can change make/common/Modules.gmk to move it to the PLATFORM_MODULES list. I?ve extended the webrev with that change - please re-review: http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. BTW, I never answered your question: "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. -Doug [1] http://hg.openjdk.java.net/jdk9/hs/hotspot/file/2c44cff993b8/src/jdk.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/services/JVMCIServiceLocator.java#l29 > >> On Jan 29, 2017, at 12:40 PM, Doug Simon wrote: >> >> Both jdk.vm.ci and jdk.vm.compiler should be considered part of the VM since they have the same capabilities as Unsafe. Arguably they could be considered even more trusted as they make it easier to do what one could (in theory) do with Unsafe. However, maybe they can still be defined by the platform class loader as 17 of 27 modules in default.policy[1] are granted AllPermission. >> >> -Doug >> >> [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/java.base/share/lib/security/default.policy >> >>> On 28 Jan 2017, at 02:00, Mandy Chung wrote: >>> >>> To clarify my question, I am not objecting fo jdk.vm.compiler be included in the runtime. I?m trying to figure what the right loader should be. It seems to me that it should be defined by the boot loader, as it is part of the VM. However, another thread suggests that you want jdk.vm.compiler to be upgradeable as Graal version requires other dependencies. We only support modules defined by the platform class loader be upgradeable. >>> >>> Mandy >>> >>>> On Jan 27, 2017, at 9:52 AM, Mandy Chung wrote: >>>> >>>> I have been wondering what defining loader jdk.vm.compiler should be, if used for JIT at runtime. That?s one reason I mentioned that the VM does not delegate to any of its child loader. >>>> >>>> How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader? >>>> >>>> Mandy >>>> >>>>> On Jan 27, 2017, at 9:23 AM, Doug Simon wrote: >>>>> >>>>> Since jdk.vm.compiler can be used as the VM compiler, shouldn't it be loaded by the platform class loader? I hope jdk.vm.ci is using the platform class loader. Where is this decision encoded? >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On Jan 27, 2017, at 5:45 PM, Sean Mullan wrote: >>>>>> >>>>>> I would need more time to understand the issue, but default.policy is not the right place to be granting these permissions, since this module is not loaded by the platform class loader. From the first 3 lines of default.policy: >>>>>> >>>>>> // >>>>>> // Permissions required by modules stored in a run-time image and loaded >>>>>> // by the platform class loader. >>>>>> >>>>>> --Sean >>>>>> >>>>>>> On 1/26/17 7:36 PM, Mandy Chung wrote: >>>>>>> I?ll let Drew and Sean to advise on this. (Drew, Sean - sorry for missing to include you in this offlist thread). >>>>>>> >>>>>>> jdk.vm.compiler is defined by the application class loader. It?d be the first one in JDK if we grant it with AllPermissions and so the security team should be the experts to review this. >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>>> On Jan 26, 2017, at 1:17 PM, Thomas Wuerthinger wrote: >>>>>>>> >>>>>>>> While the addition of "-Djava.security.policy=jit.policy? is not an issue, we would like to avoid the need for additional files. >>>>>>>> >>>>>>>> To me -XX:+UseJVMCICompiler should pretty much imply that ?jdk.vm.compiler? will be granted java.security.AllPermission. The code running in the ?jdk.vm.compiler? module can install machine code in the VM. I don?t think there is a scenario in which one would like to run any ?untrusted? code as part of this module. >>>>>>>> >>>>>>>> - thomas >>>>>>>> >>>>>>>> >>>>>>>>> On 26 Jan 2017, at 19:05, Mandy Chung wrote: >>>>>>>>> >>>>>>>>> Sicen it?s experimental, when -Djava.security.manager is set, is it an option to require to set -Djava.security.policy as well? >>>>>>>>> >>>>>>>>> java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -Djava.security.policy=jit.policy -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version >>>>>>>>> >>>>>>>>> $ cat jit.policy >>>>>>>>> grant codeBase "jrt:/jdk.vm.compiler" { >>>>>>>>> permission java.security.AllPermission; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> jdk.vm.compiler is defined by the application class loader. The bootstrap class loader doesn?t delegate to the application class loader when resolving a class that is initiated from a class that is defined by the bootstrap class loader. I don?t know how VM/JIT interacts with jdk.vm.compiler. Just to mention it. >>>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>>>>>>> On Jan 26, 2017, at 9:34 AM, Thomas Wuerthinger wrote: >>>>>>>>>> >>>>>>>>>> Mandy, >>>>>>>>>> >>>>>>>>>> We do have an agreement that part of the goal for JVMCI is to be able to run under an experimental flag Graal as a JIT in JDK9 in order for external folks to test Graal as a JIT. Not being able to do so would be considered a blocker for us. >>>>>>>>>> >>>>>>>>>> - thomas >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 26 Jan 2017, at 17:57, Mandy Chung wrote: >>>>>>>>>>> >>>>>>>>>>> (offlist) >>>>>>>>>>> >>>>>>>>>>> Hi Doug, >>>>>>>>>>> >>>>>>>>>>> I guess this may be coming from security assessment. As I understand, jdk.vm.compiler is not used for JIT in JDK 9. Why do you need to ensure jdk.vm.compiler can run with security manager out of the box? >>>>>>>>>>> >>>>>>>>>>> Mandy >>>>>>>>>>> >>>>>>>>>>>> On Jan 26, 2017, at 8:55 AM, Mandy Chung wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> On Jan 26, 2017, at 3:13 AM, Doug Simon wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> jdk.vm.compiler is defined by the application class loader and it?s used by AOT tool. I wonder why it has to run with security manager. >>>>>>>>>>>>> >>>>>>>>>>>>> Without java.security.AllPermission, the policy for jdk.vm.compiler required to get through a bootstrap (i.e., java -server -XX:+UnlockExperimentalVMOptions -Djava.security.manager -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler -version) is show below (annotated with comments denoting the methods requiring the permissions): >>>>>>>>>>>>> >>>>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> Are -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler supported to use at runtime? >>>>>>>>>>>> >>>>>>>>>>>>> There?s no guarantee that this is all the permissions required since not all code paths are exercised during bootstrap. >>>>>>>>>>>>> >>>>>>>>>>>>>> You can reference JDK tools such as jdk.compiler and jdk.jlink that are not granted with any permission. >>>>>>>>>>>>> >>>>>>>>>>>>> Neither of those tools create code and install it in the VM. I don?t think a fine grained SecurityManager policy makes sense for a VM compiler since it could subvert security by compiling/installing malicious code. That is, a VM compiler has to be a trusted component. Keep in mind that user code cannot get to jdk.vm.compiler. >>>>>>>>>>>> >>>>>>>>>>>> My question is not about granting fine-grained permissions vs AllPermissions. I expect jdk.vm.compiler is used with jdk.aot which does not run with security manager. >>>>>>>>>>>> >>>>>>>>>>>> If jdk.vm.compiler is run with VM as JIT and with security manager, the user can set -Djava.security.policy to a security policy configuring the permission for jdk.vm.compiler. >>>>>>>>>>>> >>>>>>>>>>>> grant codeBase "jrt:/jdk.vm.compiler" { >>>>>>>>>>>> permission java.security.AllPermission; >>>>>>>>>>>> }; >>>>>>>>>>>> >>>>>>>>>>>> If -XX:+BootstrapJVMCI -XX:+UseJVMCICompiler are supported, the other question I have is which loader jdk.vm.compiler should be defined? >>>>>>>>>>>> >>>>>>>>>>>> Mandy >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Mon Jan 30 21:53:11 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 30 Jan 2017 13:53:11 -0800 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> Message-ID: <52949887-B5EB-4131-B3A1-5E7693334302@oracle.com> > On Jan 30, 2017, at 1:36 PM, Doug Simon wrote: > > >> On 30 Jan 2017, at 21:55, Mandy Chung wrote: >> >> >>> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >>> >>> I?ve extended the webrev with that change - please re-review: >>> >>> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >>> >> >> +1 > > Thanks. Is that a ?Reviewed?? > Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE. Please add it only to PLATFORM_MODULES list instead. Making it an upgradeable module is a separate issue. I suggest you reopen JDK-8171448. Specifically, since upgradeable modules are not tied with java.base, our goal for JDK 9 is to eliminate qualified exports from JDK modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549. > I think I should get at least one sign-off from the security team. > Hope Sean will review this one. Please send an updated webrev. > Also, since this is effectively making jdk.vm.compiler an upgradeable module, No it does not. > what?s the implication for it being a hash-checked module? When a module M is recorded in the ModuleHashes attribute of java.base, the runtime will check if module M resolved in the graph matches the one tied with java.base when created at build time; if not, it will fail. If an upgradeable module > It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. JDK-8145337 is about the security permission. It?s better to separate this review from JDK-8171448. Mandy > > -Doug > >> >>> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >>> >> >> Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. >> >>> BTW, I never answered your question: >>> >>> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >>> >>> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. >> >> Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. >> >> Mandy > From rasbold at google.com Mon Jan 30 22:13:32 2017 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 30 Jan 2017 14:13:32 -0800 Subject: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java In-Reply-To: <8956ad49-2cea-69f5-83c0-a815ddd170e5@oracle.com> References: <8956ad49-2cea-69f5-83c0-a815ddd170e5@oracle.com> Message-ID: Thanks, Sean. Waiting for Valerie sounds good to me. It has been quite some time since I've had the joy of directly pushing my own fix. I can do it myself, or hand it over to the Security team - whatever you prefer. On Mon, Jan 30, 2017 at 12:08 PM, Sean Mullan wrote: > The fix looks ok to me, but I would also like Valerie to review it since > she is more familiar with this code. > > As far as JDK 9 goes, we are in Rampdown Phase 1. According to the rules > [1], since it is a P3 and is new in JDK 9 we should try to fix this issue > if we can. > > Were you offering to push this fix or did you want someone in the Security > group to take this over from you? > > --Sean > > [1] http://openjdk.java.net/projects/jdk9/rdp-1 > > > On 1/30/17 2:24 PM, Chuck Rasbold wrote: > >> Here's a tiny fix for an unintended, but clear, performance regression. >> >> I'm not familiar of the current criteria for jdk9 changes. Please advise >> this mostly HotSpot engineer if / how to move forward. >> >> http://cr.openjdk.java.net/~rasbold/8173581/webrev.00/ >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Mon Jan 30 22:27:28 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 30 Jan 2017 14:27:28 -0800 Subject: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java In-Reply-To: <8956ad49-2cea-69f5-83c0-a815ddd170e5@oracle.com> References: <8956ad49-2cea-69f5-83c0-a815ddd170e5@oracle.com> Message-ID: I judge this to be more serious than P3, even though correctness is not affected, since production services have noticed unacceptable performance regressions. On Mon, Jan 30, 2017 at 12:08 PM, Sean Mullan wrote: > The fix looks ok to me, but I would also like Valerie to review it since > she is more familiar with this code. > > As far as JDK 9 goes, we are in Rampdown Phase 1. According to the rules > [1], since it is a P3 and is new in JDK 9 we should try to fix this issue > if we can. > > Were you offering to push this fix or did you want someone in the Security > group to take this over from you? > > --Sean > > [1] http://openjdk.java.net/projects/jdk9/rdp-1 > > > On 1/30/17 2:24 PM, Chuck Rasbold wrote: > >> Here's a tiny fix for an unintended, but clear, performance regression. >> >> I'm not familiar of the current criteria for jdk9 changes. Please advise >> this mostly HotSpot engineer if / how to move forward. >> >> http://cr.openjdk.java.net/~rasbold/8173581/webrev.00/ >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Jan 30 22:57:12 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 30 Jan 2017 14:57:12 -0800 Subject: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java In-Reply-To: References: <8956ad49-2cea-69f5-83c0-a815ddd170e5@oracle.com> Message-ID: <0cd25d34-3a5d-3030-ad6a-4a33199ce653@oracle.com> I am currently in a meeting and will take a look after this meeting finished. Thanks, Valerie On 1/30/2017 2:27 PM, Martin Buchholz wrote: > I judge this to be more serious than P3, even though correctness is > not affected, since production services have noticed unacceptable > performance regressions. > > On Mon, Jan 30, 2017 at 12:08 PM, Sean Mullan > wrote: > > The fix looks ok to me, but I would also like Valerie to review it > since she is more familiar with this code. > > As far as JDK 9 goes, we are in Rampdown Phase 1. According to the > rules [1], since it is a P3 and is new in JDK 9 we should try to > fix this issue if we can. > > Were you offering to push this fix or did you want someone in the > Security group to take this over from you? > > --Sean > > [1] http://openjdk.java.net/projects/jdk9/rdp-1 > > > > On 1/30/17 2:24 PM, Chuck Rasbold wrote: > > Here's a tiny fix for an unintended, but clear, performance > regression. > > I'm not familiar of the current criteria for jdk9 changes. > Please advise > this mostly HotSpot engineer if / how to move forward. > > http://cr.openjdk.java.net/~rasbold/8173581/webrev.00/ > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Jan 30 23:15:48 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 30 Jan 2017 15:15:48 -0800 Subject: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java In-Reply-To: References: <8956ad49-2cea-69f5-83c0-a815ddd170e5@oracle.com> Message-ID: <1b0a59fd-af72-e9f7-203f-44a8e92385e8@oracle.com> I can push the fix for you after looking it over and running it through the regular testing process. Thanks, Valerie On 1/30/2017 2:13 PM, Chuck Rasbold wrote: > Thanks, Sean. Waiting for Valerie sounds good to me. > > It has been quite some time since I've had the joy of directly pushing > my own fix. > I can do it myself, or hand it over to the Security team - whatever > you prefer. > > On Mon, Jan 30, 2017 at 12:08 PM, Sean Mullan > wrote: > > The fix looks ok to me, but I would also like Valerie to review it > since she is more familiar with this code. > > As far as JDK 9 goes, we are in Rampdown Phase 1. According to the > rules [1], since it is a P3 and is new in JDK 9 we should try to > fix this issue if we can. > > Were you offering to push this fix or did you want someone in the > Security group to take this over from you? > > --Sean > > [1] http://openjdk.java.net/projects/jdk9/rdp-1 > > > > On 1/30/17 2:24 PM, Chuck Rasbold wrote: > > Here's a tiny fix for an unintended, but clear, performance > regression. > > I'm not familiar of the current criteria for jdk9 changes. > Please advise > this mostly HotSpot engineer if / how to move forward. > > http://cr.openjdk.java.net/~rasbold/8173581/webrev.00/ > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Mon Jan 30 23:57:32 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 30 Jan 2017 15:57:32 -0800 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: References: Message-ID: On 01/23/2017 03:27 PM, Anthony Scarpino wrote: > Hi, > > I need a code review of this change that brings more detail constraints > checking and control to certpath and jar disabled algorithm Security > properties. > > http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ > > thanks > > Tony Updated review http://cr.openjdk.java.net/~ascarpino/8160655/webrev.01/ It address the comments and has a different SignatureFileVerifier.java Tony From rasbold at google.com Tue Jan 31 00:41:23 2017 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 30 Jan 2017 16:41:23 -0800 Subject: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java In-Reply-To: <1b0a59fd-af72-e9f7-203f-44a8e92385e8@oracle.com> References: <8956ad49-2cea-69f5-83c0-a815ddd170e5@oracle.com> <1b0a59fd-af72-e9f7-203f-44a8e92385e8@oracle.com> Message-ID: Thank you! On Mon, Jan 30, 2017 at 3:15 PM, Valerie Peng wrote: > > I can push the fix for you after looking it over and running it through > the regular testing process. > Thanks, > Valerie > > > On 1/30/2017 2:13 PM, Chuck Rasbold wrote: > > Thanks, Sean. Waiting for Valerie sounds good to me. > > It has been quite some time since I've had the joy of directly pushing my > own fix. > I can do it myself, or hand it over to the Security team - whatever you > prefer. > > On Mon, Jan 30, 2017 at 12:08 PM, Sean Mullan > wrote: > >> The fix looks ok to me, but I would also like Valerie to review it since >> she is more familiar with this code. >> >> As far as JDK 9 goes, we are in Rampdown Phase 1. According to the rules >> [1], since it is a P3 and is new in JDK 9 we should try to fix this issue >> if we can. >> >> Were you offering to push this fix or did you want someone in the >> Security group to take this over from you? >> >> --Sean >> >> [1] http://openjdk.java.net/projects/jdk9/rdp-1 >> >> >> On 1/30/17 2:24 PM, Chuck Rasbold wrote: >> >>> Here's a tiny fix for an unintended, but clear, performance regression. >>> >>> I'm not familiar of the current criteria for jdk9 changes. Please advise >>> this mostly HotSpot engineer if / how to move forward. >>> >>> http://cr.openjdk.java.net/~rasbold/8173581/webrev.00/ >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Jan 31 01:38:10 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 30 Jan 2017 17:38:10 -0800 Subject: RFR: 8173581 : performance regression in com/sun/crypto/provider/OutputFeedback.java In-Reply-To: <8956ad49-2cea-69f5-83c0-a815ddd170e5@oracle.com> References: <8956ad49-2cea-69f5-83c0-a815ddd170e5@oracle.com> Message-ID: <9b2bce1e-f89e-20bd-fda4-fee2283d7825@oracle.com> Changes look fine. I will work on integrating this shortly. Valerie On 1/30/2017 12:08 PM, Sean Mullan wrote: > The fix looks ok to me, but I would also like Valerie to review it > since she is more familiar with this code. > > As far as JDK 9 goes, we are in Rampdown Phase 1. According to the > rules [1], since it is a P3 and is new in JDK 9 we should try to fix > this issue if we can. > > Were you offering to push this fix or did you want someone in the > Security group to take this over from you? > > --Sean > > [1] http://openjdk.java.net/projects/jdk9/rdp-1 > > On 1/30/17 2:24 PM, Chuck Rasbold wrote: >> Here's a tiny fix for an unintended, but clear, performance regression. >> >> I'm not familiar of the current criteria for jdk9 changes. Please advise >> this mostly HotSpot engineer if / how to move forward. >> >> http://cr.openjdk.java.net/~rasbold/8173581/webrev.00/ >> From sean.coffey at oracle.com Tue Jan 31 17:28:28 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 31 Jan 2017 17:28:28 +0000 Subject: RFR: 8160655 Fix denyAfter and usage types for security properties In-Reply-To: <76389b6d-b369-59d8-e604-b9f3bde8ed20@oracle.com> References: <7f3ecacd-bc30-3b59-0fc5-2409042c1bd9@oracle.com> <588F2408.9080204@oracle.com> <76389b6d-b369-59d8-e604-b9f3bde8ed20@oracle.com> Message-ID: <6197daea-7b3b-5167-d8d3-b747f42c6054@oracle.com> Hi Tony, Thanks for the update. I see your new webrev. I guess my point is that if we're in verbose logging mode, then we should log the message from the exception(.getMessage()) rather than the more (vague) "uses a disabled algorithm" logged message. I see the new code now iterating over the permittedAlgs Map - that will certainly benefit logging. regards, Sean. On 30/01/2017 18:21, Anthony Scarpino wrote: > Hi Sean, > > Actually Sean M and I were talking about that offline on thursday. > That file is changing a lot. > > The three sections you mention have changed a lot, but the general > idea is the disabled algorithms are captured and reported after all > the checks were done. This is because the we can have multiple > signatures and one of them maybe allowed. Throwing an exception on > the first failure would not pick up a possible second signature that > was allowed. > > thanks > > Tony > > On 01/30/2017 03:31 AM, Se?n Coffey wrote: >> src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java >> >> CertPathValidatorException is caught 3 times in new code but we're not >> printing out the exact algorithm that caused the exception. AFAIK, that >> should be in the exception message. Would it be possible to use >> something e.getMessage() call to print more detail ? You'd have to check >> for null also. >> >> 371 } catch(CertPathValidatorException e) { >> 372 if (debug != null) { >> 373 debug.println(key + " uses a disabled >> algorithm."); >> 374 } >> >> Spacing issue on line 371 of same file : >> >>> 371 } catch(CertPathValidatorException e) { >> >> Regards, >> Sean. >> >> On 26/01/17 21:57, Sean Mullan wrote: >>> Looks good, mostly minor stuff so far, just have one other file I need >>> more time to review: >>> >>> * java.security >>> >>> Update description of new constraints to match CCC. >>> >>> * PKIXExtendedParameters.java >>> >>> Update class description (it is out-of-date). >>> >>> * CertConstraintParameters.java >>> >>> 2 * Copyright (c) 2016, 2017 Oracle and/or its affiliates. All rights >>> reserved. >>> >>> Should be a comma after 2017. >>> >>> * AlgorithmChecker.java >>> >>> 278 String currSigAlg = >>> ((X509Certificate)cert).getSigAlgName(); >>> >>> Just use x509Cert.getSigAlgName() instead >>> >>> * SignatureFileVerifier.java >>> >>> 294 Timestamp[] timestamp = new Timestamp[newSigners.length]; >>> >>> "timestamps" would be more clear as a variable name >>> >>> 299 System.out.println("Timestamp[" + (i - 1) + "] = >>> " + >>> >>> debug.println >>> >>> --Sean >>> >>> On 1/23/17 6:27 PM, Anthony Scarpino wrote: >>>> Hi, >>>> >>>> I need a code review of this change that brings more detail >>>> constraints >>>> checking and control to certpath and jar disabled algorithm Security >>>> properties. >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8160655/webrev/ >>>> >>>> thanks >>>> >>>> Tony >> > From doug.simon at oracle.com Mon Jan 30 21:36:10 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 30 Jan 2017 22:36:10 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied In-Reply-To: <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> References: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> <589793F7-0BD0-4B05-AF70-5253EF2907DC@oracle.com> <83F83107-EDB1-4C0A-BA6C-493A700A0AFC@oracle.com> <5C71A420-B6F0-43E1-B2F4-6BB230464B35@oracle.com> <503ACAF4-A166-4950-9EF9-38B7093EE6BB@oracle.com> <0B66D3A8-A571-4881-8CDB-81193030FD01@oracle.com> <1ecd3a3e-d7ce-627e-ddb1-48a740a7edc2@oracle.com> <2891BDE5-2009-4A6E-8012-5DAFF9D8DCA0@oracle.com> <5BB17CBF-E3F2-424D-B140-053A0D0E518F@oracle.com> <0125272C-6FAD-45D7-8E2B-C413C38FCF89@oracle.com> <333E985C-F868-41F9-8B19-A89CE06A59DF@oracle.com> Message-ID: > On 30 Jan 2017, at 21:55, Mandy Chung wrote: > > >> On Jan 30, 2017, at 10:38 AM, Doug Simon wrote: >> >> I?ve extended the webrev with that change - please re-review: >> >> http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev >> > > +1 Thanks. Is that a ?Reviewed?? I think I should get at least one sign-off from the security team. Also, since this is effectively making jdk.vm.compiler an upgradeable module, what?s the implication for it being a hash-checked module? It seems like these changes effectively achieve what I was requesting with https://bugs.openjdk.java.net/browse/JDK-8171448. -Doug > >> Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk. >> > > Default is to be defined by the application class loader. The build will find all modules from the source. There is no need to list all modules. > >> BTW, I never answered your question: >> >> "How does JVMCI call out to jdk.vm.compiler? does it load classes using Class::forName with the system class loader?? >> >> It uses JVMCIServiceLocator[1] which is a mechanism built on the standard ServiceLoader. > > Thanks for the pointer. That confirms my understanding that loads the service providers using the system class loader. > > Mandy