From xuelei.fan at oracle.com Sun Jul 1 19:39:46 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 02 Jul 2012 10:39:46 +0800 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java Message-ID: <4FF109F2.90307@oracle.com> Hi Weijun, Would you please review the test update for CR 7180038? http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ We cannot reproduce the issue. However, from the test log, there is two possible issues exposed by this CR. 1. the improper test case senarios of un/wrap() In the test case, the scenarios is unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != clientMsg.length". After the wrap(), the next operation may need to be unwrap() to get more incoming data before comparing serverIn buffer with the expected client message. This fix is trying to do the comparing after the engine has closed. 2. From the log, the engine status and handshaking status move from CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS handshaking just finished. As the handshaking should have completed for a while, it does not sound like a correct status change. However, I did not find why this happens. Need more info. So I added a line of log (suggested by Brad Wetmore) to collect the next failure: IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE HAVE BEEN UNABLE TO RELIABLY DUPLICATE. Thanks, Xuelei From weijun.wang at oracle.com Mon Jul 2 01:35:06 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 02 Jul 2012 16:35:06 +0800 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java In-Reply-To: <4FF109F2.90307@oracle.com> References: <4FF109F2.90307@oracle.com> Message-ID: <4FF15D3A.1000706@oracle.com> I take a look at the test output. When the last handshake starts: ================ server unwrap: OK/NEED_TASK, 230/0 bytes running delegated task... new HandshakeStatus: NEED_WRAP ---- server wrap: OK/NEED_WRAP, 0/86 bytes ================ Here the first wrap only generates 86 bytes, I guess that's the ServerHello message? It keeps the state at NEED_WRAP but then never really generates the Certificate message. What might be the problem? Thanks Max On 07/02/2012 10:39 AM, Xuelei Fan wrote: > Hi Weijun, > > Would you please review the test update for CR 7180038? > http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ > > We cannot reproduce the issue. However, from the test log, there is two > possible issues exposed by this CR. > 1. the improper test case senarios of un/wrap() > In the test case, the scenarios is > unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != > clientMsg.length". After the wrap(), the next operation may need to be > unwrap() to get more incoming data before comparing serverIn buffer with > the expected client message. > > This fix is trying to do the comparing after the engine has closed. > > 2. From the log, the engine status and handshaking status move from > CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS > handshaking just finished. As the handshaking should have completed for > a while, it does not sound like a correct status change. > > However, I did not find why this happens. Need more info. So I added > a line of log (suggested by Brad Wetmore) to collect the next failure: > > IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE HAVE > BEEN UNABLE TO RELIABLY DUPLICATE. > > > Thanks, > Xuelei > From jason.uh at oracle.com Mon Jul 2 08:00:31 2012 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 02 Jul 2012 08:00:31 -0700 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file Message-ID: <4FF1B78F.7010203@oracle.com> Hi all, This change is documentation for allowing a user to specify an alternate java.security file. Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 Thanks, Jason From sean.mullan at oracle.com Mon Jul 2 08:15:45 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 02 Jul 2012 11:15:45 -0400 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF1B78F.7010203@oracle.com> References: <4FF1B78F.7010203@oracle.com> Message-ID: <4FF1BB21.7080405@oracle.com> On 07/02/2012 11:00 AM, Jason Uh wrote: > Hi all, > > This change is documentation for allowing a user to specify an alternate > java.security file. > > Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ On line 13 and 20, add a "#" at the beginning of line to indicate it is still a comment even though it is a blank line. Otherwise looks fine to me. --Sean > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 > > Thanks, > Jason From tom.hawtin at oracle.com Mon Jul 2 08:45:16 2012 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 02 Jul 2012 16:45:16 +0100 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF1B78F.7010203@oracle.com> References: <4FF1B78F.7010203@oracle.com> Message-ID: <4FF1C20C.3070604@oracle.com> On 02/07/2012 16:00, Jason Uh wrote: > This change is documentation for allowing a user to specify an alternate > java.security file. > > Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 +# An alternate java.security properties file may be specified +# from the command line via the system property +# +# java.security.properties= I think that should be: +# -Djava.security.properties= Tom From jason.uh at oracle.com Mon Jul 2 08:54:05 2012 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 02 Jul 2012 08:54:05 -0700 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF1C20C.3070604@oracle.com> References: <4FF1B78F.7010203@oracle.com> <4FF1C20C.3070604@oracle.com> Message-ID: <4FF1C41D.6000604@oracle.com> Thanks for your comments. Please see updated webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.01 Jason On 07/02/2012 08:45 AM, Tom Hawtin wrote: > On 02/07/2012 16:00, Jason Uh wrote: > >> This change is documentation for allowing a user to specify an alternate >> java.security file. >> >> Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 > > > +# An alternate java.security properties file may be specified > +# from the command line via the system property > +# > +# java.security.properties= > > I think that should be: > > +# -Djava.security.properties= > > Tom From tom.hawtin at oracle.com Mon Jul 2 08:59:37 2012 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 02 Jul 2012 16:59:37 +0100 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF1C41D.6000604@oracle.com> References: <4FF1B78F.7010203@oracle.com> <4FF1C20C.3070604@oracle.com> <4FF1C41D.6000604@oracle.com> Message-ID: <4FF1C569.7080109@oracle.com> Looks good. Tom On 02/07/2012 16:54, Jason Uh wrote: > Thanks for your comments. > > Please see updated webrev: > http://cr.openjdk.java.net/~juh/7133344/webrev.01 > > Jason > > On 07/02/2012 08:45 AM, Tom Hawtin wrote: >> On 02/07/2012 16:00, Jason Uh wrote: >> >>> This change is documentation for allowing a user to specify an alternate >>> java.security file. >>> >>> Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ >>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 >> >> >> +# An alternate java.security properties file may be specified >> +# from the command line via the system property >> +# >> +# java.security.properties= >> >> I think that should be: >> >> +# -Djava.security.properties= >> >> Tom From sean.mullan at oracle.com Mon Jul 2 10:34:42 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 02 Jul 2012 13:34:42 -0400 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF1C569.7080109@oracle.com> References: <4FF1B78F.7010203@oracle.com> <4FF1C20C.3070604@oracle.com> <4FF1C41D.6000604@oracle.com> <4FF1C569.7080109@oracle.com> Message-ID: <4FF1DBB2.5010304@oracle.com> Yep, looks good. On 07/02/2012 11:59 AM, Tom Hawtin wrote: > Looks good. > > Tom > > On 02/07/2012 16:54, Jason Uh wrote: >> Thanks for your comments. >> >> Please see updated webrev: >> http://cr.openjdk.java.net/~juh/7133344/webrev.01 >> >> Jason >> >> On 07/02/2012 08:45 AM, Tom Hawtin wrote: >>> On 02/07/2012 16:00, Jason Uh wrote: >>> >>>> This change is documentation for allowing a user to specify an >>>> alternate >>>> java.security file. >>>> >>>> Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ >>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 >>> >>> >>> +# An alternate java.security properties file may be specified >>> +# from the command line via the system property >>> +# >>> +# java.security.properties= >>> >>> I think that should be: >>> >>> +# -Djava.security.properties= >>> >>> Tom From rob.mckenna at oracle.com Mon Jul 2 11:31:13 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Mon, 02 Jul 2012 18:31:13 +0000 Subject: hg: jdk8/tl/jdk: 7174887: Deadlock in jndi ldap connection cleanup Message-ID: <20120702183131.4FCF647C41@hg.openjdk.java.net> Changeset: ecc5dd3790a1 Author: robm Date: 2012-07-02 19:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecc5dd3790a1 7174887: Deadlock in jndi ldap connection cleanup Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java From stuart.marks at oracle.com Mon Jul 2 14:33:13 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Mon, 02 Jul 2012 21:33:13 +0000 Subject: hg: jdk8/tl/jdk: 7176907: additional warnings cleanup in java.util, java.util.regexp, java.util.zip Message-ID: <20120702213335.F20FA47C53@hg.openjdk.java.net> Changeset: b2fc66012451 Author: smarks Date: 2012-07-02 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2fc66012451 7176907: additional warnings cleanup in java.util, java.util.regexp, java.util.zip Reviewed-by: forax, khazra, smarks Contributed-by: Mani Sarkar ! src/share/classes/java/util/InvalidPropertiesFormatException.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/GZIPInputStream.java From xuelei.fan at oracle.com Mon Jul 2 18:48:51 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 03 Jul 2012 09:48:51 +0800 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java In-Reply-To: <4FF15D3A.1000706@oracle.com> References: <4FF109F2.90307@oracle.com> <4FF15D3A.1000706@oracle.com> Message-ID: <4FF24F83.7030200@oracle.com> On 7/2/2012 4:35 PM, Weijun Wang wrote: > I take a look at the test output. When the last handshake starts: > > ================ > server unwrap: OK/NEED_TASK, 230/0 bytes > running delegated task... > new HandshakeStatus: NEED_WRAP > ---- > server wrap: OK/NEED_WRAP, 0/86 bytes > ================ > > Here the first wrap only generates 86 bytes, I guess that's the > ServerHello message? It keeps the state at NEED_WRAP but then never > really generates the Certificate message. What might be the problem? > Good catch! It was the abbreviated handshaking. I guess that the previous client has not closed the socket completely, so for *this* handshaking, the abbreviated handshaking rather than the full handshaking is used. For full handshaking, it is the client sending the "Finished" message at first. However, for abbreviated handshaking, the server send the "Finished" message at first. In the current scenarios, it is expected that the client sends its application data (26 bytes), and then the server sends its application data (29 bytes). However, the abbreviated handshaking disorder the sequence in that it is the sever sends it application data (29 bytes) before client. In such cases, the following logic does not stand any more: if (!closed && (serverOut.remaining() == 0)) { closed = true; ... if (serverIn.remaining() != clientMsg.length) { throw new Exception("Client: Data length error"); } ... } Because the server has not receive the client message when the server sends its application data. I think it is a test issue, the current fix should has already addressed the issue. Xuelei > Thanks > Max > > On 07/02/2012 10:39 AM, Xuelei Fan wrote: >> Hi Weijun, >> >> Would you please review the test update for CR 7180038? >> http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ >> >> We cannot reproduce the issue. However, from the test log, there is two >> possible issues exposed by this CR. >> 1. the improper test case senarios of un/wrap() >> In the test case, the scenarios is >> unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != >> clientMsg.length". After the wrap(), the next operation may need to be >> unwrap() to get more incoming data before comparing serverIn buffer with >> the expected client message. >> >> This fix is trying to do the comparing after the engine has closed. >> >> 2. From the log, the engine status and handshaking status move from >> CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS >> handshaking just finished. As the handshaking should have completed for >> a while, it does not sound like a correct status change. >> >> However, I did not find why this happens. Need more info. So I added >> a line of log (suggested by Brad Wetmore) to collect the next failure: >> >> IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE HAVE >> BEEN UNABLE TO RELIABLY DUPLICATE. >> >> >> Thanks, >> Xuelei >> > From weijun.wang at oracle.com Mon Jul 2 19:02:41 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 03 Jul 2012 10:02:41 +0800 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java In-Reply-To: <4FF24F83.7030200@oracle.com> References: <4FF109F2.90307@oracle.com> <4FF15D3A.1000706@oracle.com> <4FF24F83.7030200@oracle.com> Message-ID: <4FF252C1.1000606@oracle.com> On 07/03/2012 09:48 AM, Xuelei Fan wrote: > On 7/2/2012 4:35 PM, Weijun Wang wrote: >> I take a look at the test output. When the last handshake starts: >> >> ================ >> server unwrap: OK/NEED_TASK, 230/0 bytes >> running delegated task... >> new HandshakeStatus: NEED_WRAP >> ---- >> server wrap: OK/NEED_WRAP, 0/86 bytes >> ================ >> >> Here the first wrap only generates 86 bytes, I guess that's the >> ServerHello message? It keeps the state at NEED_WRAP but then never >> really generates the Certificate message. What might be the problem? >> > Good catch! > > It was the abbreviated handshaking. I guess that the previous client has > not closed the socket completely, so for *this* handshaking, the > abbreviated handshaking rather than the full handshaking is used. > > For full handshaking, it is the client sending the "Finished" message at > first. However, for abbreviated handshaking, the server send the > "Finished" message at first. > > In the current scenarios, it is expected that the client sends its > application data (26 bytes), and then the server sends its application > data (29 bytes). However, the abbreviated handshaking disorder the > sequence in that it is the sever sends it application data (29 bytes) > before client. In such cases, the following logic does not stand any more: > if (!closed && (serverOut.remaining() == 0)) { > closed = true; > ... > if (serverIn.remaining() != clientMsg.length) { > > throw new Exception("Client: Data length error"); > } > ... > } > > Because the server has not receive the client message when the server > sends its application data. > > I think it is a test issue, the current fix should has already addressed > the issue. That's great. Since the reason is clear, can you reproduce this failure and then confirm the current fix does solve the problem? Thanks Max > > Xuelei > >> Thanks >> Max >> >> On 07/02/2012 10:39 AM, Xuelei Fan wrote: >>> Hi Weijun, >>> >>> Would you please review the test update for CR 7180038? >>> http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ >>> >>> We cannot reproduce the issue. However, from the test log, there is two >>> possible issues exposed by this CR. >>> 1. the improper test case senarios of un/wrap() >>> In the test case, the scenarios is >>> unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != >>> clientMsg.length". After the wrap(), the next operation may need to be >>> unwrap() to get more incoming data before comparing serverIn buffer with >>> the expected client message. >>> >>> This fix is trying to do the comparing after the engine has closed. >>> >>> 2. From the log, the engine status and handshaking status move from >>> CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS >>> handshaking just finished. As the handshaking should have completed for >>> a while, it does not sound like a correct status change. >>> >>> However, I did not find why this happens. Need more info. So I added >>> a line of log (suggested by Brad Wetmore) to collect the next failure: >>> >>> IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE HAVE >>> BEEN UNABLE TO RELIABLY DUPLICATE. >>> >>> >>> Thanks, >>> Xuelei >>> >> > > From xuelei.fan at oracle.com Mon Jul 2 19:37:24 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 03 Jul 2012 10:37:24 +0800 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java In-Reply-To: <4FF252C1.1000606@oracle.com> References: <4FF109F2.90307@oracle.com> <4FF15D3A.1000706@oracle.com> <4FF24F83.7030200@oracle.com> <4FF252C1.1000606@oracle.com> Message-ID: <4FF25AE4.4010703@oracle.com> On 7/3/2012 10:02 AM, Weijun Wang wrote: > > > On 07/03/2012 09:48 AM, Xuelei Fan wrote: >> On 7/2/2012 4:35 PM, Weijun Wang wrote: >>> I take a look at the test output. When the last handshake starts: >>> >>> ================ >>> server unwrap: OK/NEED_TASK, 230/0 bytes >>> running delegated task... >>> new HandshakeStatus: NEED_WRAP >>> ---- >>> server wrap: OK/NEED_WRAP, 0/86 bytes >>> ================ >>> >>> Here the first wrap only generates 86 bytes, I guess that's the >>> ServerHello message? It keeps the state at NEED_WRAP but then never >>> really generates the Certificate message. What might be the problem? >>> >> Good catch! >> >> It was the abbreviated handshaking. I guess that the previous client has >> not closed the socket completely, so for *this* handshaking, the >> abbreviated handshaking rather than the full handshaking is used. >> >> For full handshaking, it is the client sending the "Finished" message at >> first. However, for abbreviated handshaking, the server send the >> "Finished" message at first. >> >> In the current scenarios, it is expected that the client sends its >> application data (26 bytes), and then the server sends its application >> data (29 bytes). However, the abbreviated handshaking disorder the >> sequence in that it is the sever sends it application data (29 bytes) >> before client. In such cases, the following logic does not stand any >> more: >> if (!closed && (serverOut.remaining() == 0)) { >> closed = true; >> ... >> if (serverIn.remaining() != clientMsg.length) { >> >> throw new Exception("Client: Data length error"); >> } >> ... >> } >> >> Because the server has not receive the client message when the server >> sends its application data. >> >> I think it is a test issue, the current fix should has already addressed >> the issue. > > That's great. > > Since the reason is clear, can you reproduce this failure and then > confirm the current fix does solve the problem? > It is possible to reproduce this failure with a new test case. But it is pretty hard to reproduce it within this test. I was wondering as it is test bug, so we may not want a extra test case to prove that this test is correct. We also have a nested remind that, "IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE HAVE BEEN UNABLE TO RELIABLY DUPLICATE." I think it might be OK that we do not reproduce this issue at present. What do you think? Thanks, Xuelei > Thanks > Max > >> >> Xuelei >> >>> Thanks >>> Max >>> >>> On 07/02/2012 10:39 AM, Xuelei Fan wrote: >>>> Hi Weijun, >>>> >>>> Would you please review the test update for CR 7180038? >>>> http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ >>>> >>>> We cannot reproduce the issue. However, from the test log, there is two >>>> possible issues exposed by this CR. >>>> 1. the improper test case senarios of un/wrap() >>>> In the test case, the scenarios is >>>> unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != >>>> clientMsg.length". After the wrap(), the next operation may need to be >>>> unwrap() to get more incoming data before comparing serverIn buffer >>>> with >>>> the expected client message. >>>> >>>> This fix is trying to do the comparing after the engine has >>>> closed. >>>> >>>> 2. From the log, the engine status and handshaking status move from >>>> CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS >>>> handshaking just finished. As the handshaking should have completed for >>>> a while, it does not sound like a correct status change. >>>> >>>> However, I did not find why this happens. Need more info. So I >>>> added >>>> a line of log (suggested by Brad Wetmore) to collect the next failure: >>>> >>>> IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE HAVE >>>> BEEN UNABLE TO RELIABLY DUPLICATE. >>>> >>>> >>>> Thanks, >>>> Xuelei >>>> >>> >> >> > From weijun.wang at oracle.com Mon Jul 2 19:40:31 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 03 Jul 2012 10:40:31 +0800 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java In-Reply-To: <4FF25AE4.4010703@oracle.com> References: <4FF109F2.90307@oracle.com> <4FF15D3A.1000706@oracle.com> <4FF24F83.7030200@oracle.com> <4FF252C1.1000606@oracle.com> <4FF25AE4.4010703@oracle.com> Message-ID: <4FF25B9F.3020805@oracle.com> No new test needed. I only think that you might be able to hack the current test a little to reproduce this and see if the failure is the same and if your code change can fix it. There is no need to keep this hack in your final changeset. -Max On 07/03/2012 10:37 AM, Xuelei Fan wrote: > On 7/3/2012 10:02 AM, Weijun Wang wrote: >> >> >> On 07/03/2012 09:48 AM, Xuelei Fan wrote: >>> On 7/2/2012 4:35 PM, Weijun Wang wrote: >>>> I take a look at the test output. When the last handshake starts: >>>> >>>> ================ >>>> server unwrap: OK/NEED_TASK, 230/0 bytes >>>> running delegated task... >>>> new HandshakeStatus: NEED_WRAP >>>> ---- >>>> server wrap: OK/NEED_WRAP, 0/86 bytes >>>> ================ >>>> >>>> Here the first wrap only generates 86 bytes, I guess that's the >>>> ServerHello message? It keeps the state at NEED_WRAP but then never >>>> really generates the Certificate message. What might be the problem? >>>> >>> Good catch! >>> >>> It was the abbreviated handshaking. I guess that the previous client has >>> not closed the socket completely, so for *this* handshaking, the >>> abbreviated handshaking rather than the full handshaking is used. >>> >>> For full handshaking, it is the client sending the "Finished" message at >>> first. However, for abbreviated handshaking, the server send the >>> "Finished" message at first. >>> >>> In the current scenarios, it is expected that the client sends its >>> application data (26 bytes), and then the server sends its application >>> data (29 bytes). However, the abbreviated handshaking disorder the >>> sequence in that it is the sever sends it application data (29 bytes) >>> before client. In such cases, the following logic does not stand any >>> more: >>> if (!closed && (serverOut.remaining() == 0)) { >>> closed = true; >>> ... >>> if (serverIn.remaining() != clientMsg.length) { >>> >>> throw new Exception("Client: Data length error"); >>> } >>> ... >>> } >>> >>> Because the server has not receive the client message when the server >>> sends its application data. >>> >>> I think it is a test issue, the current fix should has already addressed >>> the issue. >> >> That's great. >> >> Since the reason is clear, can you reproduce this failure and then >> confirm the current fix does solve the problem? >> > It is possible to reproduce this failure with a new test case. But it is > pretty hard to reproduce it within this test. I was wondering as it is > test bug, so we may not want a extra test case to prove that this test > is correct. > > We also have a nested remind that, "IF THIS FAILS, PLEASE REPORT THIS TO > THE SECURITY TEAM. WE HAVE BEEN UNABLE TO RELIABLY DUPLICATE." I think > it might be OK that we do not reproduce this issue at present. > > What do you think? > > Thanks, > Xuelei > >> Thanks >> Max >> >>> >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>>> On 07/02/2012 10:39 AM, Xuelei Fan wrote: >>>>> Hi Weijun, >>>>> >>>>> Would you please review the test update for CR 7180038? >>>>> http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ >>>>> >>>>> We cannot reproduce the issue. However, from the test log, there is two >>>>> possible issues exposed by this CR. >>>>> 1. the improper test case senarios of un/wrap() >>>>> In the test case, the scenarios is >>>>> unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != >>>>> clientMsg.length". After the wrap(), the next operation may need to be >>>>> unwrap() to get more incoming data before comparing serverIn buffer >>>>> with >>>>> the expected client message. >>>>> >>>>> This fix is trying to do the comparing after the engine has >>>>> closed. >>>>> >>>>> 2. From the log, the engine status and handshaking status move from >>>>> CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS >>>>> handshaking just finished. As the handshaking should have completed for >>>>> a while, it does not sound like a correct status change. >>>>> >>>>> However, I did not find why this happens. Need more info. So I >>>>> added >>>>> a line of log (suggested by Brad Wetmore) to collect the next failure: >>>>> >>>>> IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE HAVE >>>>> BEEN UNABLE TO RELIABLY DUPLICATE. >>>>> >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>> >>> >>> >> > > From xuelei.fan at oracle.com Mon Jul 2 20:00:10 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 03 Jul 2012 11:00:10 +0800 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java In-Reply-To: <4FF25B9F.3020805@oracle.com> References: <4FF109F2.90307@oracle.com> <4FF15D3A.1000706@oracle.com> <4FF24F83.7030200@oracle.com> <4FF252C1.1000606@oracle.com> <4FF25AE4.4010703@oracle.com> <4FF25B9F.3020805@oracle.com> Message-ID: <4FF2603A.7020708@oracle.com> On 7/3/2012 10:40 AM, Weijun Wang wrote: > No new test needed. I only think that you might be able to hack the > current test a little to reproduce this and see if the failure is the > same and if your code change can fix it. There is no need to keep this > hack in your final changeset. > I tied several different approaches within this test, but failed to reproduce the abbreviated handshaking. ;-) It is not easy to hack the test without significant changes. Xuelei > -Max > > > On 07/03/2012 10:37 AM, Xuelei Fan wrote: >> On 7/3/2012 10:02 AM, Weijun Wang wrote: >>> >>> >>> On 07/03/2012 09:48 AM, Xuelei Fan wrote: >>>> On 7/2/2012 4:35 PM, Weijun Wang wrote: >>>>> I take a look at the test output. When the last handshake starts: >>>>> >>>>> ================ >>>>> server unwrap: OK/NEED_TASK, 230/0 bytes >>>>> running delegated task... >>>>> new HandshakeStatus: NEED_WRAP >>>>> ---- >>>>> server wrap: OK/NEED_WRAP, 0/86 bytes >>>>> ================ >>>>> >>>>> Here the first wrap only generates 86 bytes, I guess that's the >>>>> ServerHello message? It keeps the state at NEED_WRAP but then never >>>>> really generates the Certificate message. What might be the problem? >>>>> >>>> Good catch! >>>> >>>> It was the abbreviated handshaking. I guess that the previous client >>>> has >>>> not closed the socket completely, so for *this* handshaking, the >>>> abbreviated handshaking rather than the full handshaking is used. >>>> >>>> For full handshaking, it is the client sending the "Finished" >>>> message at >>>> first. However, for abbreviated handshaking, the server send the >>>> "Finished" message at first. >>>> >>>> In the current scenarios, it is expected that the client sends its >>>> application data (26 bytes), and then the server sends its application >>>> data (29 bytes). However, the abbreviated handshaking disorder the >>>> sequence in that it is the sever sends it application data (29 bytes) >>>> before client. In such cases, the following logic does not stand any >>>> more: >>>> if (!closed && (serverOut.remaining() == 0)) { >>>> closed = true; >>>> ... >>>> if (serverIn.remaining() != clientMsg.length) { >>>> >>>> throw new Exception("Client: Data length error"); >>>> } >>>> ... >>>> } >>>> >>>> Because the server has not receive the client message when the server >>>> sends its application data. >>>> >>>> I think it is a test issue, the current fix should has already >>>> addressed >>>> the issue. >>> >>> That's great. >>> >>> Since the reason is clear, can you reproduce this failure and then >>> confirm the current fix does solve the problem? >>> >> It is possible to reproduce this failure with a new test case. But it is >> pretty hard to reproduce it within this test. I was wondering as it is >> test bug, so we may not want a extra test case to prove that this test >> is correct. >> >> We also have a nested remind that, "IF THIS FAILS, PLEASE REPORT THIS TO >> THE SECURITY TEAM. WE HAVE BEEN UNABLE TO RELIABLY DUPLICATE." I think >> it might be OK that we do not reproduce this issue at present. >> >> What do you think? >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>>> >>>> Xuelei >>>> >>>>> Thanks >>>>> Max >>>>> >>>>> On 07/02/2012 10:39 AM, Xuelei Fan wrote: >>>>>> Hi Weijun, >>>>>> >>>>>> Would you please review the test update for CR 7180038? >>>>>> http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ >>>>>> >>>>>> We cannot reproduce the issue. However, from the test log, there >>>>>> is two >>>>>> possible issues exposed by this CR. >>>>>> 1. the improper test case senarios of un/wrap() >>>>>> In the test case, the scenarios is >>>>>> unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != >>>>>> clientMsg.length". After the wrap(), the next operation may need >>>>>> to be >>>>>> unwrap() to get more incoming data before comparing serverIn buffer >>>>>> with >>>>>> the expected client message. >>>>>> >>>>>> This fix is trying to do the comparing after the engine has >>>>>> closed. >>>>>> >>>>>> 2. From the log, the engine status and handshaking status move from >>>>>> CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS >>>>>> handshaking just finished. As the handshaking should have >>>>>> completed for >>>>>> a while, it does not sound like a correct status change. >>>>>> >>>>>> However, I did not find why this happens. Need more info. So I >>>>>> added >>>>>> a line of log (suggested by Brad Wetmore) to collect the next >>>>>> failure: >>>>>> >>>>>> IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE >>>>>> HAVE >>>>>> BEEN UNABLE TO RELIABLY DUPLICATE. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>> >>>> >>>> >>> >> >> > From weijun.wang at oracle.com Mon Jul 2 20:09:09 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 03 Jul 2012 11:09:09 +0800 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java In-Reply-To: <4FF2603A.7020708@oracle.com> References: <4FF109F2.90307@oracle.com> <4FF15D3A.1000706@oracle.com> <4FF24F83.7030200@oracle.com> <4FF252C1.1000606@oracle.com> <4FF25AE4.4010703@oracle.com> <4FF25B9F.3020805@oracle.com> <4FF2603A.7020708@oracle.com> Message-ID: <4FF26255.8010908@oracle.com> Your fix looks fine. IMHO, the remind is not really useful unless you dump more info, say, the value of serverIn.remaining(). QE would report the failure to "THE SECURITY TEAM" anyway. -Max On 07/03/2012 11:00 AM, Xuelei Fan wrote: > On 7/3/2012 10:40 AM, Weijun Wang wrote: >> No new test needed. I only think that you might be able to hack the >> current test a little to reproduce this and see if the failure is the >> same and if your code change can fix it. There is no need to keep this >> hack in your final changeset. >> > I tied several different approaches within this test, but failed to > reproduce the abbreviated handshaking. ;-) It is not easy to hack the > test without significant changes. > > Xuelei > >> -Max >> >> >> On 07/03/2012 10:37 AM, Xuelei Fan wrote: >>> On 7/3/2012 10:02 AM, Weijun Wang wrote: >>>> >>>> >>>> On 07/03/2012 09:48 AM, Xuelei Fan wrote: >>>>> On 7/2/2012 4:35 PM, Weijun Wang wrote: >>>>>> I take a look at the test output. When the last handshake starts: >>>>>> >>>>>> ================ >>>>>> server unwrap: OK/NEED_TASK, 230/0 bytes >>>>>> running delegated task... >>>>>> new HandshakeStatus: NEED_WRAP >>>>>> ---- >>>>>> server wrap: OK/NEED_WRAP, 0/86 bytes >>>>>> ================ >>>>>> >>>>>> Here the first wrap only generates 86 bytes, I guess that's the >>>>>> ServerHello message? It keeps the state at NEED_WRAP but then never >>>>>> really generates the Certificate message. What might be the problem? >>>>>> >>>>> Good catch! >>>>> >>>>> It was the abbreviated handshaking. I guess that the previous client >>>>> has >>>>> not closed the socket completely, so for *this* handshaking, the >>>>> abbreviated handshaking rather than the full handshaking is used. >>>>> >>>>> For full handshaking, it is the client sending the "Finished" >>>>> message at >>>>> first. However, for abbreviated handshaking, the server send the >>>>> "Finished" message at first. >>>>> >>>>> In the current scenarios, it is expected that the client sends its >>>>> application data (26 bytes), and then the server sends its application >>>>> data (29 bytes). However, the abbreviated handshaking disorder the >>>>> sequence in that it is the sever sends it application data (29 bytes) >>>>> before client. In such cases, the following logic does not stand any >>>>> more: >>>>> if (!closed && (serverOut.remaining() == 0)) { >>>>> closed = true; >>>>> ... >>>>> if (serverIn.remaining() != clientMsg.length) { >>>>> >>>>> throw new Exception("Client: Data length error"); >>>>> } >>>>> ... >>>>> } >>>>> >>>>> Because the server has not receive the client message when the server >>>>> sends its application data. >>>>> >>>>> I think it is a test issue, the current fix should has already >>>>> addressed >>>>> the issue. >>>> >>>> That's great. >>>> >>>> Since the reason is clear, can you reproduce this failure and then >>>> confirm the current fix does solve the problem? >>>> >>> It is possible to reproduce this failure with a new test case. But it is >>> pretty hard to reproduce it within this test. I was wondering as it is >>> test bug, so we may not want a extra test case to prove that this test >>> is correct. >>> >>> We also have a nested remind that, "IF THIS FAILS, PLEASE REPORT THIS TO >>> THE SECURITY TEAM. WE HAVE BEEN UNABLE TO RELIABLY DUPLICATE." I think >>> it might be OK that we do not reproduce this issue at present. >>> >>> What do you think? >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>>>> >>>>> Xuelei >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> On 07/02/2012 10:39 AM, Xuelei Fan wrote: >>>>>>> Hi Weijun, >>>>>>> >>>>>>> Would you please review the test update for CR 7180038? >>>>>>> http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ >>>>>>> >>>>>>> We cannot reproduce the issue. However, from the test log, there >>>>>>> is two >>>>>>> possible issues exposed by this CR. >>>>>>> 1. the improper test case senarios of un/wrap() >>>>>>> In the test case, the scenarios is >>>>>>> unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != >>>>>>> clientMsg.length". After the wrap(), the next operation may need >>>>>>> to be >>>>>>> unwrap() to get more incoming data before comparing serverIn buffer >>>>>>> with >>>>>>> the expected client message. >>>>>>> >>>>>>> This fix is trying to do the comparing after the engine has >>>>>>> closed. >>>>>>> >>>>>>> 2. From the log, the engine status and handshaking status move from >>>>>>> CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS >>>>>>> handshaking just finished. As the handshaking should have >>>>>>> completed for >>>>>>> a while, it does not sound like a correct status change. >>>>>>> >>>>>>> However, I did not find why this happens. Need more info. So I >>>>>>> added >>>>>>> a line of log (suggested by Brad Wetmore) to collect the next >>>>>>> failure: >>>>>>> >>>>>>> IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE >>>>>>> HAVE >>>>>>> BEEN UNABLE TO RELIABLY DUPLICATE. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From weijun.wang at oracle.com Mon Jul 2 20:14:44 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 03 Jul 2012 11:14:44 +0800 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF1DBB2.5010304@oracle.com> References: <4FF1B78F.7010203@oracle.com> <4FF1C20C.3070604@oracle.com> <4FF1C41D.6000604@oracle.com> <4FF1C569.7080109@oracle.com> <4FF1DBB2.5010304@oracle.com> Message-ID: <4FF263A4.6010201@oracle.com> One minor thing: Line 25 should be empty, this starts another paragraph on providers. Thanks Max On 07/03/2012 01:34 AM, Sean Mullan wrote: > Yep, looks good. > > On 07/02/2012 11:59 AM, Tom Hawtin wrote: >> Looks good. >> >> Tom >> >> On 02/07/2012 16:54, Jason Uh wrote: >>> Thanks for your comments. >>> >>> Please see updated webrev: >>> http://cr.openjdk.java.net/~juh/7133344/webrev.01 >>> >>> Jason >>> >>> On 07/02/2012 08:45 AM, Tom Hawtin wrote: >>>> On 02/07/2012 16:00, Jason Uh wrote: >>>> >>>>> This change is documentation for allowing a user to specify an >>>>> alternate >>>>> java.security file. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ >>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 >>>> >>>> >>>> +# An alternate java.security properties file may be specified >>>> +# from the command line via the system property >>>> +# >>>> +# java.security.properties= >>>> >>>> I think that should be: >>>> >>>> +# -Djava.security.properties= >>>> >>>> Tom > > From xuelei.fan at oracle.com Mon Jul 2 20:15:19 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 03 Jul 2012 11:15:19 +0800 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java In-Reply-To: <4FF26255.8010908@oracle.com> References: <4FF109F2.90307@oracle.com> <4FF15D3A.1000706@oracle.com> <4FF24F83.7030200@oracle.com> <4FF252C1.1000606@oracle.com> <4FF25AE4.4010703@oracle.com> <4FF25B9F.3020805@oracle.com> <4FF2603A.7020708@oracle.com> <4FF26255.8010908@oracle.com> Message-ID: <4FF263C7.1030808@oracle.com> On 7/3/2012 11:09 AM, Weijun Wang wrote: > Your fix looks fine. > Thanks! > IMHO, the remind is not really useful unless you dump more info, say, > the value of serverIn.remaining(). We can get the value from analysis of the log. The remind is only used for the case that we do not really fix the issue with this update. Xuelei > QE would report the failure to "THE > SECURITY TEAM" anyway. > > -Max > > On 07/03/2012 11:00 AM, Xuelei Fan wrote: >> On 7/3/2012 10:40 AM, Weijun Wang wrote: >>> No new test needed. I only think that you might be able to hack the >>> current test a little to reproduce this and see if the failure is the >>> same and if your code change can fix it. There is no need to keep this >>> hack in your final changeset. >>> >> I tied several different approaches within this test, but failed to >> reproduce the abbreviated handshaking. ;-) It is not easy to hack the >> test without significant changes. >> >> Xuelei >> >>> -Max >>> >>> >>> On 07/03/2012 10:37 AM, Xuelei Fan wrote: >>>> On 7/3/2012 10:02 AM, Weijun Wang wrote: >>>>> >>>>> >>>>> On 07/03/2012 09:48 AM, Xuelei Fan wrote: >>>>>> On 7/2/2012 4:35 PM, Weijun Wang wrote: >>>>>>> I take a look at the test output. When the last handshake starts: >>>>>>> >>>>>>> ================ >>>>>>> server unwrap: OK/NEED_TASK, 230/0 bytes >>>>>>> running delegated task... >>>>>>> new HandshakeStatus: NEED_WRAP >>>>>>> ---- >>>>>>> server wrap: OK/NEED_WRAP, 0/86 bytes >>>>>>> ================ >>>>>>> >>>>>>> Here the first wrap only generates 86 bytes, I guess that's the >>>>>>> ServerHello message? It keeps the state at NEED_WRAP but then never >>>>>>> really generates the Certificate message. What might be the problem? >>>>>>> >>>>>> Good catch! >>>>>> >>>>>> It was the abbreviated handshaking. I guess that the previous client >>>>>> has >>>>>> not closed the socket completely, so for *this* handshaking, the >>>>>> abbreviated handshaking rather than the full handshaking is used. >>>>>> >>>>>> For full handshaking, it is the client sending the "Finished" >>>>>> message at >>>>>> first. However, for abbreviated handshaking, the server send the >>>>>> "Finished" message at first. >>>>>> >>>>>> In the current scenarios, it is expected that the client sends its >>>>>> application data (26 bytes), and then the server sends its >>>>>> application >>>>>> data (29 bytes). However, the abbreviated handshaking disorder the >>>>>> sequence in that it is the sever sends it application data (29 bytes) >>>>>> before client. In such cases, the following logic does not stand any >>>>>> more: >>>>>> if (!closed && (serverOut.remaining() == 0)) { >>>>>> closed = true; >>>>>> ... >>>>>> if (serverIn.remaining() != clientMsg.length) { >>>>>> >>>>>> throw new Exception("Client: Data length error"); >>>>>> } >>>>>> ... >>>>>> } >>>>>> >>>>>> Because the server has not receive the client message when the server >>>>>> sends its application data. >>>>>> >>>>>> I think it is a test issue, the current fix should has already >>>>>> addressed >>>>>> the issue. >>>>> >>>>> That's great. >>>>> >>>>> Since the reason is clear, can you reproduce this failure and then >>>>> confirm the current fix does solve the problem? >>>>> >>>> It is possible to reproduce this failure with a new test case. But >>>> it is >>>> pretty hard to reproduce it within this test. I was wondering as it is >>>> test bug, so we may not want a extra test case to prove that this test >>>> is correct. >>>> >>>> We also have a nested remind that, "IF THIS FAILS, PLEASE REPORT >>>> THIS TO >>>> THE SECURITY TEAM. WE HAVE BEEN UNABLE TO RELIABLY DUPLICATE." I think >>>> it might be OK that we do not reproduce this issue at present. >>>> >>>> What do you think? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> >>>>>> Xuelei >>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> On 07/02/2012 10:39 AM, Xuelei Fan wrote: >>>>>>>> Hi Weijun, >>>>>>>> >>>>>>>> Would you please review the test update for CR 7180038? >>>>>>>> http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ >>>>>>>> >>>>>>>> We cannot reproduce the issue. However, from the test log, there >>>>>>>> is two >>>>>>>> possible issues exposed by this CR. >>>>>>>> 1. the improper test case senarios of un/wrap() >>>>>>>> In the test case, the scenarios is >>>>>>>> unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != >>>>>>>> clientMsg.length". After the wrap(), the next operation may need >>>>>>>> to be >>>>>>>> unwrap() to get more incoming data before comparing serverIn buffer >>>>>>>> with >>>>>>>> the expected client message. >>>>>>>> >>>>>>>> This fix is trying to do the comparing after the engine has >>>>>>>> closed. >>>>>>>> >>>>>>>> 2. From the log, the engine status and handshaking status move from >>>>>>>> CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS >>>>>>>> handshaking just finished. As the handshaking should have >>>>>>>> completed for >>>>>>>> a while, it does not sound like a correct status change. >>>>>>>> >>>>>>>> However, I did not find why this happens. Need more >>>>>>>> info. So I >>>>>>>> added >>>>>>>> a line of log (suggested by Brad Wetmore) to collect the next >>>>>>>> failure: >>>>>>>> >>>>>>>> IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE >>>>>>>> HAVE >>>>>>>> BEEN UNABLE TO RELIABLY DUPLICATE. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From sean.mullan at oracle.com Tue Jul 3 04:49:49 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 03 Jul 2012 07:49:49 -0400 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF263A4.6010201@oracle.com> References: <4FF1B78F.7010203@oracle.com> <4FF1C20C.3070604@oracle.com> <4FF1C41D.6000604@oracle.com> <4FF1C569.7080109@oracle.com> <4FF1DBB2.5010304@oracle.com> <4FF263A4.6010201@oracle.com> Message-ID: <4FF2DC5D.8070401@oracle.com> On 7/2/12 11:14 PM, Weijun Wang wrote: > One minor thing: > > Line 25 should be empty, this starts another paragraph on providers. I'm not sure I understand the comment as it is empty already. --Sean > > Thanks > Max > > On 07/03/2012 01:34 AM, Sean Mullan wrote: >> Yep, looks good. >> >> On 07/02/2012 11:59 AM, Tom Hawtin wrote: >>> Looks good. >>> >>> Tom >>> >>> On 02/07/2012 16:54, Jason Uh wrote: >>>> Thanks for your comments. >>>> >>>> Please see updated webrev: >>>> http://cr.openjdk.java.net/~juh/7133344/webrev.01 >>>> >>>> Jason >>>> >>>> On 07/02/2012 08:45 AM, Tom Hawtin wrote: >>>>> On 02/07/2012 16:00, Jason Uh wrote: >>>>> >>>>>> This change is documentation for allowing a user to specify an >>>>>> alternate >>>>>> java.security file. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ >>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 >>>>> >>>>> >>>>> +# An alternate java.security properties file may be specified >>>>> +# from the command line via the system property >>>>> +# >>>>> +# java.security.properties= >>>>> >>>>> I think that should be: >>>>> >>>>> +# -Djava.security.properties= >>>>> >>>>> Tom >> >> > From weijun.wang at oracle.com Tue Jul 3 04:57:45 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 03 Jul 2012 19:57:45 +0800 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF2DC5D.8070401@oracle.com> References: <4FF1B78F.7010203@oracle.com> <4FF1C20C.3070604@oracle.com> <4FF1C41D.6000604@oracle.com> <4FF1C569.7080109@oracle.com> <4FF1DBB2.5010304@oracle.com> <4FF263A4.6010201@oracle.com> <4FF2DC5D.8070401@oracle.com> Message-ID: <4FF2DE39.1060908@oracle.com> The current line 25 has a "#" and I prefer it to be a real empty line. -Max On 07/03/2012 07:49 PM, Sean Mullan wrote: > On 7/2/12 11:14 PM, Weijun Wang wrote: >> One minor thing: >> >> Line 25 should be empty, this starts another paragraph on providers. > > I'm not sure I understand the comment as it is empty already. > > --Sean > >> >> Thanks >> Max >> >> On 07/03/2012 01:34 AM, Sean Mullan wrote: >>> Yep, looks good. >>> >>> On 07/02/2012 11:59 AM, Tom Hawtin wrote: >>>> Looks good. >>>> >>>> Tom >>>> >>>> On 02/07/2012 16:54, Jason Uh wrote: >>>>> Thanks for your comments. >>>>> >>>>> Please see updated webrev: >>>>> http://cr.openjdk.java.net/~juh/7133344/webrev.01 >>>>> >>>>> Jason >>>>> >>>>> On 07/02/2012 08:45 AM, Tom Hawtin wrote: >>>>>> On 02/07/2012 16:00, Jason Uh wrote: >>>>>> >>>>>>> This change is documentation for allowing a user to specify an >>>>>>> alternate >>>>>>> java.security file. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ >>>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 >>>>>> >>>>>> >>>>>> +# An alternate java.security properties file may be specified >>>>>> +# from the command line via the system property >>>>>> +# >>>>>> +# java.security.properties= >>>>>> >>>>>> I think that should be: >>>>>> >>>>>> +# -Djava.security.properties= >>>>>> >>>>>> Tom >>> >>> >> > From sean.mullan at oracle.com Tue Jul 3 05:00:09 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 03 Jul 2012 08:00:09 -0400 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF2DE39.1060908@oracle.com> References: <4FF1B78F.7010203@oracle.com> <4FF1C20C.3070604@oracle.com> <4FF1C41D.6000604@oracle.com> <4FF1C569.7080109@oracle.com> <4FF1DBB2.5010304@oracle.com> <4FF263A4.6010201@oracle.com> <4FF2DC5D.8070401@oracle.com> <4FF2DE39.1060908@oracle.com> Message-ID: <4FF2DEC9.3070308@oracle.com> On 7/3/12 7:57 AM, Weijun Wang wrote: > The current line 25 has a "#" and I prefer it to be a real empty line. Ok, I understand now. Yes, I agree that would be a good change. --Sean > > -Max > > On 07/03/2012 07:49 PM, Sean Mullan wrote: >> On 7/2/12 11:14 PM, Weijun Wang wrote: >>> One minor thing: >>> >>> Line 25 should be empty, this starts another paragraph on providers. >> >> I'm not sure I understand the comment as it is empty already. >> >> --Sean >> >>> >>> Thanks >>> Max >>> >>> On 07/03/2012 01:34 AM, Sean Mullan wrote: >>>> Yep, looks good. >>>> >>>> On 07/02/2012 11:59 AM, Tom Hawtin wrote: >>>>> Looks good. >>>>> >>>>> Tom >>>>> >>>>> On 02/07/2012 16:54, Jason Uh wrote: >>>>>> Thanks for your comments. >>>>>> >>>>>> Please see updated webrev: >>>>>> http://cr.openjdk.java.net/~juh/7133344/webrev.01 >>>>>> >>>>>> Jason >>>>>> >>>>>> On 07/02/2012 08:45 AM, Tom Hawtin wrote: >>>>>>> On 02/07/2012 16:00, Jason Uh wrote: >>>>>>> >>>>>>>> This change is documentation for allowing a user to specify an >>>>>>>> alternate >>>>>>>> java.security file. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ >>>>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 >>>>>>> >>>>>>> >>>>>>> +# An alternate java.security properties file may be specified >>>>>>> +# from the command line via the system property >>>>>>> +# >>>>>>> +# java.security.properties= >>>>>>> >>>>>>> I think that should be: >>>>>>> >>>>>>> +# -Djava.security.properties= >>>>>>> >>>>>>> Tom >>>> >>>> >>> >> > From jason.uh at oracle.com Tue Jul 3 11:28:44 2012 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 03 Jul 2012 11:28:44 -0700 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF2DEC9.3070308@oracle.com> References: <4FF1B78F.7010203@oracle.com> <4FF1C20C.3070604@oracle.com> <4FF1C41D.6000604@oracle.com> <4FF1C569.7080109@oracle.com> <4FF1DBB2.5010304@oracle.com> <4FF263A4.6010201@oracle.com> <4FF2DC5D.8070401@oracle.com> <4FF2DE39.1060908@oracle.com> <4FF2DEC9.3070308@oracle.com> Message-ID: <4FF339DC.2050304@oracle.com> Thanks, Max and Sean. Now with the empty line: http://cr.openjdk.java.net/~juh/7133344/webrev.02/ Jason On 07/03/2012 05:00 AM, Sean Mullan wrote: > On 7/3/12 7:57 AM, Weijun Wang wrote: >> The current line 25 has a "#" and I prefer it to be a real empty line. > > Ok, I understand now. Yes, I agree that would be a good change. > > --Sean > >> >> -Max >> >> On 07/03/2012 07:49 PM, Sean Mullan wrote: >>> On 7/2/12 11:14 PM, Weijun Wang wrote: >>>> One minor thing: >>>> >>>> Line 25 should be empty, this starts another paragraph on providers. >>> >>> I'm not sure I understand the comment as it is empty already. >>> >>> --Sean >>> >>>> >>>> Thanks >>>> Max >>>> >>>> On 07/03/2012 01:34 AM, Sean Mullan wrote: >>>>> Yep, looks good. >>>>> >>>>> On 07/02/2012 11:59 AM, Tom Hawtin wrote: >>>>>> Looks good. >>>>>> >>>>>> Tom >>>>>> >>>>>> On 02/07/2012 16:54, Jason Uh wrote: >>>>>>> Thanks for your comments. >>>>>>> >>>>>>> Please see updated webrev: >>>>>>> http://cr.openjdk.java.net/~juh/7133344/webrev.01 >>>>>>> >>>>>>> Jason >>>>>>> >>>>>>> On 07/02/2012 08:45 AM, Tom Hawtin wrote: >>>>>>>> On 02/07/2012 16:00, Jason Uh wrote: >>>>>>>> >>>>>>>>> This change is documentation for allowing a user to specify an >>>>>>>>> alternate >>>>>>>>> java.security file. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ >>>>>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 >>>>>>>> >>>>>>>> >>>>>>>> +# An alternate java.security properties file may be specified >>>>>>>> +# from the command line via the system property >>>>>>>> +# >>>>>>>> +# java.security.properties= >>>>>>>> >>>>>>>> I think that should be: >>>>>>>> >>>>>>>> +# -Djava.security.properties= >>>>>>>> >>>>>>>> Tom >>>>> >>>>> >>>> >>> >> > From sean.mullan at oracle.com Tue Jul 3 11:57:34 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 03 Jul 2012 18:57:34 +0000 Subject: hg: jdk8/tl/jdk: 7133344: Document the java.security.properties system property feature in the java.security file Message-ID: <20120703185805.837DD47C70@hg.openjdk.java.net> Changeset: d375ea39ce9c Author: mullan Date: 2012-07-03 14:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d375ea39ce9c 7133344: Document the java.security.properties system property feature in the java.security file Reviewed-by: hawtin, mullan, weijun Contributed-by: jason.uh at oracle.com ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows From sean.mullan at oracle.com Tue Jul 3 11:58:17 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 03 Jul 2012 14:58:17 -0400 Subject: JDK8 Code review request for 7133344: Document the java.security.properties system property feature in the java.security file In-Reply-To: <4FF339DC.2050304@oracle.com> References: <4FF1B78F.7010203@oracle.com> <4FF1C20C.3070604@oracle.com> <4FF1C41D.6000604@oracle.com> <4FF1C569.7080109@oracle.com> <4FF1DBB2.5010304@oracle.com> <4FF263A4.6010201@oracle.com> <4FF2DC5D.8070401@oracle.com> <4FF2DE39.1060908@oracle.com> <4FF2DEC9.3070308@oracle.com> <4FF339DC.2050304@oracle.com> Message-ID: <4FF340C9.1050404@oracle.com> Looks good. I'll push the changeset for you. --Sean On 7/3/12 2:28 PM, Jason Uh wrote: > Thanks, Max and Sean. > > Now with the empty line: http://cr.openjdk.java.net/~juh/7133344/webrev.02/ > > Jason > > On 07/03/2012 05:00 AM, Sean Mullan wrote: >> On 7/3/12 7:57 AM, Weijun Wang wrote: >>> The current line 25 has a "#" and I prefer it to be a real empty line. >> >> Ok, I understand now. Yes, I agree that would be a good change. >> >> --Sean >> >>> >>> -Max >>> >>> On 07/03/2012 07:49 PM, Sean Mullan wrote: >>>> On 7/2/12 11:14 PM, Weijun Wang wrote: >>>>> One minor thing: >>>>> >>>>> Line 25 should be empty, this starts another paragraph on providers. >>>> >>>> I'm not sure I understand the comment as it is empty already. >>>> >>>> --Sean >>>> >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> On 07/03/2012 01:34 AM, Sean Mullan wrote: >>>>>> Yep, looks good. >>>>>> >>>>>> On 07/02/2012 11:59 AM, Tom Hawtin wrote: >>>>>>> Looks good. >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> On 02/07/2012 16:54, Jason Uh wrote: >>>>>>>> Thanks for your comments. >>>>>>>> >>>>>>>> Please see updated webrev: >>>>>>>> http://cr.openjdk.java.net/~juh/7133344/webrev.01 >>>>>>>> >>>>>>>> Jason >>>>>>>> >>>>>>>> On 07/02/2012 08:45 AM, Tom Hawtin wrote: >>>>>>>>> On 02/07/2012 16:00, Jason Uh wrote: >>>>>>>>> >>>>>>>>>> This change is documentation for allowing a user to specify an >>>>>>>>>> alternate >>>>>>>>>> java.security file. >>>>>>>>>> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~juh/7133344/webrev.00/ >>>>>>>>>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133344 >>>>>>>>> >>>>>>>>> >>>>>>>>> +# An alternate java.security properties file may be specified >>>>>>>>> +# from the command line via the system property >>>>>>>>> +# >>>>>>>>> +# java.security.properties= >>>>>>>>> >>>>>>>>> I think that should be: >>>>>>>>> >>>>>>>>> +# -Djava.security.properties= >>>>>>>>> >>>>>>>>> Tom >>>>>> >>>>>> >>>>> >>>> >>> >> From lana.steuck at oracle.com Tue Jul 3 19:20:43 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 04 Jul 2012 02:20:43 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b45 for changeset 633f2378c904 Message-ID: <20120704022043.899B747C8C@hg.openjdk.java.net> Changeset: 27fa766a2298 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/27fa766a2298 Added tag jdk8-b45 for changeset 633f2378c904 ! .hgtags From lana.steuck at oracle.com Tue Jul 3 19:20:41 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 04 Jul 2012 02:20:41 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20120704022046.7064847C8F@hg.openjdk.java.net> Changeset: 30141e598d72 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/30141e598d72 Added tag jdk8-b45 for changeset 747dad9e9d37 ! .hgtags Changeset: 666efea2df67 Author: lana Date: 2012-07-03 18:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/666efea2df67 Merge From lana.steuck at oracle.com Tue Jul 3 19:20:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 04 Jul 2012 02:20:51 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b45 for changeset e80ac58b5ba9 Message-ID: <20120704022100.92DD747C92@hg.openjdk.java.net> Changeset: ae368a83c240 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ae368a83c240 Added tag jdk8-b45 for changeset e80ac58b5ba9 ! .hgtags From lana.steuck at oracle.com Tue Jul 3 19:20:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 04 Jul 2012 02:20:51 +0000 Subject: hg: jdk8/tl/langtools: Added tag jdk8-b45 for changeset e111e4587cca Message-ID: <20120704022100.E21CF47C95@hg.openjdk.java.net> Changeset: 4ca599497172 Author: katleman Date: 2012-06-28 09:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4ca599497172 Added tag jdk8-b45 for changeset e111e4587cca ! .hgtags From lana.steuck at oracle.com Tue Jul 3 19:21:00 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 04 Jul 2012 02:21:00 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20120704022111.DCFA847C99@hg.openjdk.java.net> Changeset: 300f45e99064 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/300f45e99064 Added tag jdk8-b45 for changeset 57476f66e13c ! .hgtags Changeset: 9cb8be5e6119 Author: lana Date: 2012-07-03 18:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9cb8be5e6119 Merge From lana.steuck at oracle.com Tue Jul 3 19:21:02 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 04 Jul 2012 02:21:02 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120704022123.331DC47C9C@hg.openjdk.java.net> Changeset: 8d2ed9d58453 Author: katleman Date: 2012-06-28 09:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d2ed9d58453 Added tag jdk8-b45 for changeset b92353a01aa0 ! .hgtags Changeset: 8ccbd5aabeab Author: lana Date: 2012-07-03 18:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ccbd5aabeab Merge From lana.steuck at oracle.com Tue Jul 3 19:21:09 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 04 Jul 2012 02:21:09 +0000 Subject: hg: jdk8/tl/hotspot: 33 new changesets Message-ID: <20120704022217.B693047C9F@hg.openjdk.java.net> Changeset: a8b9798c1d45 Author: katleman Date: 2012-06-28 09:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a8b9798c1d45 Added tag jdk8-b45 for changeset 9d5f20961bc5 ! .hgtags Changeset: 1c280e5b8d31 Author: amurillo Date: 2012-06-15 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1c280e5b8d31 7175515: new hotspot build - hs24-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e9140bf80b4a Author: coleenp Date: 2012-06-13 19:52 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e9140bf80b4a 7158800: Improve storage of symbol tables Summary: Use an alternate version of hashing algorithm for symbol string tables and after a certain bucket size to improve performance Reviewed-by: pbk, kamg, dlong, kvn, fparain + src/share/vm/classfile/altHashing.cpp + src/share/vm/classfile/altHashing.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp + test/runtime/7158800/BadUtf8.java + test/runtime/7158800/InternTest.java + test/runtime/7158800/badstrings.txt Changeset: b87e5a681416 Author: poonam Date: 2012-06-14 02:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b87e5a681416 6310967: SA: jstack -m produce failures in output Summary: While looking for the sender frame check that the frame pointer should not be less than the stack pointer. Reviewed-by: dholmes, sla ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/amd64/AMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/cdbg/basic/x86/X86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/sparc/LinuxSPARCCFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcCFrame.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java Changeset: e16bc4ad5f20 Author: poonam Date: 2012-06-14 22:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e16bc4ad5f20 Merge Changeset: 86e17e45019d Author: coleenp Date: 2012-06-15 07:51 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86e17e45019d 7177307: fix fo CR7158800 doesn't contain Test7158800.sh Summary: forgot to hg add it Reviewed-by: pbk, kamg, dlong, kvn, fparain + test/runtime/7158800/Test7158800.sh Changeset: 58ad5f22317e Author: sla Date: 2012-06-18 11:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58ad5f22317e Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/runtime/globals.hpp Changeset: d1b0644d6acf Author: dcubed Date: 2012-06-20 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1b0644d6acf 7175255: symlinks are wrong, which caused jdk8-promote-2 to fail (client/64/64 directories in debuginfo zips) Summary: Fix bad paths in client/64 and server/64 debug info and symlink creation Reviewed-by: ohair, dholmes ! make/solaris/makefiles/add_gnu_debuglink.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fix_empty_sec_hdr_flags.make Changeset: 7de1d3b57419 Author: dcubed Date: 2012-06-20 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7de1d3b57419 Merge ! make/solaris/makefiles/defs.make Changeset: cfa2c82f4c04 Author: minqi Date: 2012-06-22 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cfa2c82f4c04 7175133: jinfo failed to get system properties after 6924259 Summary: String offset and count fields as fix of 6924259 were removed, and become optional. SA still use offset and count fields to read String contents and failed. Fix if they exist, use them other then use value field only to read, this keeps consistent with the changes in 6924259. Reviewed-by: dholmes, mikael Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java Changeset: d8a240abb23a Author: minqi Date: 2012-06-22 15:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8a240abb23a 7177128: SA cannot get correct system properties after 7126277 Summary: Bug fix of 7126277 changed hashing algorithm and also changed key as final field, this led SA unable to set correct value for key. Solution by reading key/value and insert them into the new table. Reviewed-by: dholmes, mikael Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/ObjectReader.java Changeset: 588f559105c1 Author: sla Date: 2012-06-25 14:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/588f559105c1 7178846: IterateThroughHeap: heap_iteration_callback passes a negative size Summary: Missing cast caused integer overflow Reviewed-by: rbackman, dholmes ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 246d977b51f2 Author: coleenp Date: 2012-06-25 21:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/246d977b51f2 7178670: runtime/7158800/BadUtf8.java fails in SymbolTable::rehash_table Summary: Cannot delete _buckets and HashtableEntries in shared space (CDS) Reviewed-by: acorn, kvn, dlong, dcubed, kamg ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 36b2d4cfcf03 Author: coleenp Date: 2012-06-25 18:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/36b2d4cfcf03 Merge Changeset: 74533f63b116 Author: sla Date: 2012-06-27 15:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/74533f63b116 7178667: ALT_EXPORT_PATH does not export server jvm on macosx Summary: Missing .PHONY targets in makefile Reviewed-by: dholmes, dsamersoff ! make/bsd/makefiles/universal.gmk Changeset: f7baf26515fc Author: collins Date: 2012-06-19 21:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7baf26515fc 7178113: build environment change Summary: Simple change to enable proper builds of arm target Reviewed-by: ohair, dholmes ! make/jprt.properties Changeset: 634b8615a6ba Author: jiangli Date: 2012-06-22 14:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/634b8615a6ba 7177409: Perf regression in JVM_GetClassDeclaredFields after generic signature changes. Summary: In fieldDescriptor::generic_signature() returns NULL immediately if the field has no generic signature. Reviewed-by: dholmes, coleenp, jcoomes ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 06320b1578cb Author: dlong Date: 2012-06-25 15:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06320b1578cb 7156729: PPC: R_PPC_REL24 relocation error related to some libraries built without -fPIC Summary: build powerpc with -fPIC Reviewed-by: mikael, vladidan, roland Contributed-by: dean.long at oracle.com ! make/pic.make Changeset: 7d5f65916db0 Author: bdelsart Date: 2012-06-28 04:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d5f65916db0 Merge Changeset: 8c92982cbbc4 Author: kvn Date: 2012-06-15 01:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8c92982cbbc4 7119644: Increase superword's vector size up to 256 bits Summary: Increase vector size up to 256-bits for YMM AVX registers on x86. Reviewed-by: never, twisti, roland ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/register_x86.cpp ! src/cpu/x86/vm/register_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vmreg_x86.cpp ! src/cpu/x86/vm/vmreg_x86.inline.hpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/code/vmreg.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/opcodes.cpp ! src/share/vm/opto/opcodes.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/7119644/TestBooleanVect.java + test/compiler/7119644/TestByteDoubleVect.java + test/compiler/7119644/TestByteFloatVect.java + test/compiler/7119644/TestByteIntVect.java + test/compiler/7119644/TestByteLongVect.java + test/compiler/7119644/TestByteShortVect.java + test/compiler/7119644/TestByteVect.java + test/compiler/7119644/TestCharShortVect.java + test/compiler/7119644/TestCharVect.java + test/compiler/7119644/TestDoubleVect.java + test/compiler/7119644/TestFloatDoubleVect.java + test/compiler/7119644/TestFloatVect.java + test/compiler/7119644/TestIntDoubleVect.java + test/compiler/7119644/TestIntFloatVect.java + test/compiler/7119644/TestIntLongVect.java + test/compiler/7119644/TestIntVect.java + test/compiler/7119644/TestLongDoubleVect.java + test/compiler/7119644/TestLongFloatVect.java + test/compiler/7119644/TestLongVect.java + test/compiler/7119644/TestShortDoubleVect.java + test/compiler/7119644/TestShortFloatVect.java + test/compiler/7119644/TestShortIntVect.java + test/compiler/7119644/TestShortLongVect.java + test/compiler/7119644/TestShortVect.java Changeset: eeb819cf36e5 Author: roland Date: 2012-06-18 09:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eeb819cf36e5 7174363: Arrays.copyOfRange leads to VM crash with -Xcomp -server if executed by testing framework Summary: Arrays.copyOfRange(original, from, to) with from > original.length tries to do a copy with a negative length. Reviewed-by: kvn, twisti ! src/share/vm/opto/library_call.cpp + test/compiler/7174363/Test7174363.java Changeset: f8de958e5b2c Author: twisti Date: 2012-06-18 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f8de958e5b2c 7176856: add the JRE name to the error log Reviewed-by: coleenp, jrose, kvn, twisti Contributed-by: Krystal Mok ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 765ee2d1674b Author: twisti Date: 2012-06-18 15:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/765ee2d1674b 7157365: jruby/bench.bench_timeout crashes with JVM internal error Reviewed-by: jrose, kvn ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/type.cpp Changeset: 6f8f439e247d Author: kvn Date: 2012-06-19 15:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f8f439e247d 7177923: SIGBUS on sparc in compiled code for java.util.Calendar.clear() Summary: disable vectorization of a memory access with more elements per vector than one which is used for alignment on sparc Reviewed-by: twisti ! src/cpu/x86/vm/x86.ad ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp Changeset: 40782a131183 Author: roland Date: 2012-06-21 09:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40782a131183 7129715: MAC: SIGBUS in nsk stress test Summary: StackOverflowError may get lost on OSX. Reviewed-by: kvn, dcubed ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: 424142833d10 Author: kvn Date: 2012-06-22 10:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/424142833d10 7178280: Failed new vector regression tests Summary: When looking for the same value in an other register check that all parts of that register has the same value. Reviewed-by: johnc, twisti ! src/share/vm/opto/postaloc.cpp Changeset: 751bd303aa45 Author: kvn Date: 2012-06-26 09:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/751bd303aa45 7179138: Incorrect result with String concatenation optimization Summary: check for and skip diamond shaped NULL check code for the result of toString() Reviewed-by: twisti, roland ! src/share/vm/opto/stringopts.cpp + test/compiler/7179138/Test7179138_1.java + test/compiler/7179138/Test7179138_2.java Changeset: de2f17add1fb Author: kvn Date: 2012-06-28 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de2f17add1fb Merge Changeset: 7994a5a35fcf Author: johnc Date: 2012-06-25 16:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7994a5a35fcf 6921087: G1: remove per-GC-thread expansion tables from the fine-grain remembered sets Summary: Remove the per-thread expansion tables (PosParPRT) and associated expansion and compaction from the fine grain RSet entries. This code has been unused for a while. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: 22de825d6faf Author: jcoomes Date: 2012-06-29 11:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22de825d6faf Merge Changeset: 61a94c2da7c4 Author: coleenp Date: 2012-06-29 14:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/61a94c2da7c4 7179759: ENV: Nightly fails during jdk copiyng for solaris platforms after FDS unzipping Summary: libjvm_g_db.so and libjvm_g_dtrace.so links in .diz file still had 64 directory Reviewed-by: kamg, dholmes, sspitsyn ! make/solaris/makefiles/dtrace.make Changeset: 40e5a3f2907e Author: amurillo Date: 2012-06-29 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40e5a3f2907e Merge Changeset: cf37a594c38d Author: amurillo Date: 2012-06-29 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cf37a594c38d Added tag hs24-b15 for changeset 40e5a3f2907e ! .hgtags From xuelei.fan at oracle.com Tue Jul 3 20:30:00 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 04 Jul 2012 03:30:00 +0000 Subject: hg: jdk8/tl/jdk: 7180038: regression test failure, SSLEngineBadBufferArrayAccess.java Message-ID: <20120704033019.3BDAE47CB8@hg.openjdk.java.net> Changeset: 3ae91286f313 Author: xuelei Date: 2012-07-03 20:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ae91286f313 7180038: regression test failure, SSLEngineBadBufferArrayAccess.java Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java From weijun.wang at oracle.com Thu Jul 5 01:34:28 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 05 Jul 2012 16:34:28 +0800 Subject: OpenJDK krb5 ignore /etc/krb5.conf? Message-ID: <4FF55194.5050403@oracle.com> Hi Scott On Mac since Lion, sun.security.krb5.Config tries to locate the config info in this order: 1. java.security.krb5.conf system property 2. ${jre}/lib/security/krb5.conf 3. SCDynamicStoreConfig The main difference from other platforms is that it will not try config files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. On the other hand, even /usr/bin/kinit comes with Lion reads the config file (if there is no SCDynamicStoreConfig setting). Is there a special reason for the current Java behavior? I do notice that the Apple 6u33 already does this. Thanks Max From dan.xu at oracle.com Thu Jul 5 13:38:38 2012 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 05 Jul 2012 13:38:38 -0700 Subject: Please Review Test Fix of Bug 7177045 In-Reply-To: <4FECF72A.6090102@oracle.com> References: <4FECC35C.10105@oracle.com> <4FECF72A.6090102@oracle.com> Message-ID: <4FF5FB4E.10804@oracle.com> Hi Brad, Thanks for your good suggestions. I have fixed most of them and re-uploaded my changes at http://cr.openjdk.java.net/~dxu/7177045.01/. The reason that I chose ArrayDeque instead of LinkedList is that ArrayDequeseems have better performance. According to the java doc, "most ArrayDeque operations run in amortized constant time" and "this class is likely to be faster then LinkedList when used as a queue." It is also very easy to remove last elements to back off memory allocation. In addition, I did not switch to diamond operator. Because old Jdk bundles, say jdk 1.7.0-ea-b23 and jdk 1.7.0-ea-b29 used in my testing, failed to compile diamond operator. Here are the compilation error messages, TestProviderLeak.java:62: illegal start of type Deque data = new ArrayDeque<>(); ^ 1 error I guess those jdk might be too early to adopt the diamond operator changes. I am not sure whether we still take these old jdk bundles into consideration here. Thanks! -Dan On 06/28/2012 05:30 PM, Brad Wetmore wrote: > Dan, congrats on assembling and posting your first webrev. Besides > the big picture things, since you are new, I'll also be looking for > minor things that you may or may not know yet. > > On 6/28/2012 1:49 PM, Dan Xu wrote: >> Security code reviewers, >> >> I have fixed a security test failure and posted my changes at >> http://cr.openjdk.java.net/~dxu/7177045/. Please help review it. Thanks! > > Minor nit: line 38 has a space at the end of the line. Current > jstyle guidelines state no indention with tabs and no whitespace at > the end of the lines. > > Lines 61/89: memroy->memory > > Just wondering why you chose a Deque instead of a simpler LinkedList? > > Suggest more liberal use of comments, either in the method's comments > or inline. Good to explain your assumptions/approach in case things > aren't obvious. For example, why do you backoff 3MB after allocating > available memory? And at line 134: the operation could either time > out or threw an exception. Nice to make that clear. > > dummyData could be a local variable. > > Line 64/113: consider using the JDK 7 diamond <> operator on your > generics. > > Line 114: consider adding a @overrides annotation on the call() method. > > Line 139: I'm being paranoid here, but shutdownNow doesn't guarantee > threads will be stopped. If we actually got into a situation where > there was a timeout, executor.shutdownNow() *may* never return. One > reason is it might be hanging somewhere waiting for memory. I would > suggest as part of your finally block, you dequeue all the memory in > dummyData, call System.gc(), then run executor.shutdownNow(). JTREG > will timeout after two minutes, but if we can proactively help the > situation, we might as well. > > Otherwise, looks good. We'll wait to see if anyone has other > thoughts, and if not, we'll push when you're back from vacation. > > Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20120705/c27695f9/attachment.html From stuart.marks at oracle.com Thu Jul 5 15:10:37 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 05 Jul 2012 22:10:37 +0000 Subject: hg: jdk8/tl/jdk: 6948101: java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently Message-ID: <20120705221056.E6DAA47D18@hg.openjdk.java.net> Changeset: 97eb7a4b1fdd Author: smarks Date: 2012-07-05 15:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97eb7a4b1fdd 6948101: java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently Reviewed-by: dholmes, smarks Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/rmi/transport/pinLastArguments/PinLastArguments.java From stuart.marks at oracle.com Thu Jul 5 15:15:01 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 05 Jul 2012 22:15:01 +0000 Subject: hg: jdk8/tl/jdk: 7123972: test/java/lang/annotation/loaderLeak/Main.java fails intermittently Message-ID: <20120705221511.D9FF647D1B@hg.openjdk.java.net> Changeset: 4ad204cc7433 Author: smarks Date: 2012-07-05 15:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad204cc7433 7123972: test/java/lang/annotation/loaderLeak/Main.java fails intermittently Reviewed-by: dholmes, smarks Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/lang/annotation/loaderLeak/Main.java From valerie.peng at oracle.com Thu Jul 5 16:03:35 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 05 Jul 2012 16:03:35 -0700 Subject: Request for refactoring: Config.getXXX() In-Reply-To: <4FDFDEFA.6000005@oracle.com> References: <4FDFDEFA.6000005@oracle.com> Message-ID: <4FF61D47.3090101@oracle.com> Yes, I prefer the idea of explicitly specifying the path for finding the values even if more calls are needed. Valerie On 06/18/12 19:07, Weijun Wang wrote: > This is about the internal class sun.security.krb5.Config. > > If you want to get a value from inside krb5.conf, you can call > getDefault(String). This might be good to get a value from the > [libdefaults] section. However, the method was designed to be so smart > that it can recursively search for key/value pairs no matter how deep > it is. > > For example, given a krb5.conf > > [s1] > a=b > > [s2] > c=d > > [s3] > e = { > f = g > } > > getDefault("a") = "b", getDefault("c") = "d", and astonishingly, > getDefault("f") = "g". > > I don't think this is a good design, for several reasons: > > 1. It depends on the order of sections if there are key/value pairs > with the same key. > > 2. It ignores wrong settings. For example, when doing a cross-realm > auth, the Realm.getRealmsList(from,to) is used to get a path which > should be defined in [capaths]. However, the method simply crawls > recursively into any subsection it found and won't notice the > [capaths] being mistakenly typed as [capath] > > 3. It lacks certain features. Because the function always return a > String (same with the getDefault(String,String) method), > getDefault("e") can only return a null. Therefore there is no way to > find out the existence of the subsection e unless we also know it > contains a key f. > > 4. The current Config class needs to know what subsections contains > more subsections, and it hardcodes names like [capaths] and [realms]. > > In short, it's just too smart and becomes unsafe to use. I suggest > removing all this smartness and a user must use the full paths to get > a value, say, > > kdc = config.get("realms", "SUN.COM", "kdc") > > My full spec is: > > 1. The Config class should understand a krb5.conf without knowing any > specific section names. All it maintains is a Value, which can be > either of > > String > List > TreeMap > > Here I use TreeMap to preserve the order (might not be necessary). > > 2. The basic retrieval method will be > > Value get(String... key) > > 3. There are simply methods if you already know what the type in your > case is > > String getAsString(String... key) > List getAsStringList(String... key) > > The compatibility risk will be low, and if there really comes a > compatibility issue, most likely it will be because the caller had > written his krb5.conf wrong. > > One of the advantages of the original design is that when a key is > provided in both [libdefaults] and a given realm, the method can find > it anyway. This will be useful for keys like kdc_timeout, max_retries. > However, I think this automatic retrieval is confusing and > error-prone, I'd rather manually call the get() method twice. > > Thanks > Max > From luchsh at linux.vnet.ibm.com Thu Jul 5 19:38:27 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Fri, 06 Jul 2012 02:38:27 +0000 Subject: hg: jdk8/tl/jdk: 7181353: Update error message to distinguish native OOM and java OOM in net Message-ID: <20120706023846.83B1847D34@hg.openjdk.java.net> Changeset: 15a6b0bceb1e Author: zhouyx Date: 2012-07-06 10:36 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/15a6b0bceb1e 7181353: Update error message to distinguish native OOM and java OOM in net Reviewed-by: chegar ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c From weijun.wang at oracle.com Thu Jul 5 22:03:23 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 06 Jul 2012 13:03:23 +0800 Subject: Code review request: 7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes In-Reply-To: <19780024.1341533557483.JavaMail.sbladm@swsblss4-new.central.sun.com> References: <19780024.1341533557483.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <4FF6719B.3040005@oracle.com> Hi All I have two fixes for this bug: For 7u6: http://cr.openjdk.java.net/~weijun/7180907/7u/webrev.00/ This simply makes the name recognizable. It's safe and I don't want anything broken in 7u6. For 8: http://cr.openjdk.java.net/~weijun/7180907/webrev.00/ This changes the internal name tables of AlgorithmId to match with the Standard Names doc [1]. I've searched thru all codes inside JDK that calls the AlgorithmId.getName() and made some trivial changes. Both using the same regression test. JPRT for jdk8 on the way. Thanks Max [1] http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html -------- Original Message -------- === *Description* ============================================================ SHORT SUMMARY: If a signature block (.RSA, a PKCS#7 object) contains authenticated attributes and uses a SHA-256 digest, verification will fail. The digest algorithm is stored in the PKCS7 using the correct OID (2.16.840.1.101.3.4.2.1) but sun.security.x509.AlgorithmId maps this back to an algorithm with name "SHA256". This is not a valid MessageDigest name - the correct version is SHA-256. The debug output from: jarsigner -J-Djava.security.debug=all -verbose -verify i3.jar debug.txt and i3.jar available here: ftp://bugftp.us.oracle.com/upload/bug_13/bug13941476 INDICATORS: COUNTER INDICATORS: TRIGGERS: KNOWN WORKAROUND: PRESENT SINCE: N/A HOW TO VERIFY: Run attached test case NOTES FOR SE: None REGRESSION: From Xuelei.Fan at Oracle.COM Thu Jul 5 23:44:27 2012 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Fri, 06 Jul 2012 14:44:27 +0800 Subject: Code review request: 7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes In-Reply-To: <4FF6719B.3040005@oracle.com> References: <19780024.1341533557483.JavaMail.sbladm@swsblss4-new.central.sun.com> <4FF6719B.3040005@oracle.com> Message-ID: <4FF6894B.9070406@Oracle.COM> On 7/6/2012 1:03 PM, Weijun Wang wrote: > Hi All > > I have two fixes for this bug: > > For 7u6: http://cr.openjdk.java.net/~weijun/7180907/7u/webrev.00/ > Looks fine to me, except a very minor copyright date: you may want to use 2012 for SignerInfo.java. > This simply makes the name recognizable. It's safe and I don't want > anything broken in 7u6. > > For 8: http://cr.openjdk.java.net/~weijun/7180907/webrev.00/ > Looks fine to me. Xuelei > This changes the internal name tables of AlgorithmId to match with the > Standard Names doc [1]. I've searched thru all codes inside JDK that > calls the AlgorithmId.getName() and made some trivial changes. > > Both using the same regression test. > > JPRT for jdk8 on the way. > > Thanks > Max > > [1] > http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html > > > -------- Original Message -------- > === *Description* > ============================================================ > SHORT SUMMARY: > If a signature block (.RSA, a PKCS#7 object) contains authenticated > attributes > and uses a SHA-256 digest, verification will fail. The digest algorithm is > stored in the PKCS7 using the correct OID (2.16.840.1.101.3.4.2.1) but > sun.security.x509.AlgorithmId maps this back to an algorithm with name > "SHA256". This is not a valid MessageDigest name - the correct version is > SHA-256. > > The debug output from: > jarsigner -J-Djava.security.debug=all -verbose -verify i3.jar > debug.txt and i3.jar available here: > ftp://bugftp.us.oracle.com/upload/bug_13/bug13941476 > INDICATORS: > COUNTER INDICATORS: > TRIGGERS: > KNOWN WORKAROUND: > > PRESENT SINCE: > N/A > HOW TO VERIFY: > Run attached test case > NOTES FOR SE: > None > REGRESSION: > From luchsh at linux.vnet.ibm.com Fri Jul 6 02:16:39 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 06 Jul 2012 17:16:39 +0800 Subject: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale In-Reply-To: <4F97E496.9020509@oracle.com> References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com> <4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com> <4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com> <4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com> Message-ID: <4FF6ACF7.6020200@linux.vnet.ibm.com> Hello Max, I's been a long time since my last mail, I did some investigation and had some discussion with i18n developers, but still did not see a nice solution for the alignment problem. There does not seem be an existing API to do this job in JDK scope. So I implemented a simple format function, and use it to format under different locales. http://cr.openjdk.java.net/~luchsh/7163483_3/ The patch is trying to format the code in the same way as java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz yyyy", except for using names of month and DOW in localized format. So far, it works good for me under all supported locales. Here's a test case to verify the vertical alignment, which I has been posted to i18n mailing list before, http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java It may still fail under "vi_VN" locale with this solution due to test case limit, but I do not think it is a real failure since the result fields still get aligned except for multiple words in one field. Could you please take a look at the patch? Many thanks & best regards Jonathan On 04/25/2012 07:48 PM, Weijun Wang wrote: > Hi Jonathan > > I'm using English. > > In your test all the files have a similar modified time so you cannot > see the difference. However, in my example, you can see that the > widths for date and hour are not zero-padded so the width can be > either 1 or 2. > > French is even worse > > smk 76 10 nov. 2009 08:57:54 bin/vbin/go > smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans > smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown > smk 671 8 f?vr. 2012 20:11:22 bin/vbin/ssh.desktop > smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf > > So here even the width of month abbr can be different. > > Thanks > Max > > > On 04/25/2012 07:09 PM, Jonathan Lu wrote: >> Hello Max, >> >> Terribly sorry for my misunderstanding! >> >> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>> >>> >>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>> Hi Max, >>>> >>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>> >>>>> >>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>> Hi Weijun, >>>>>> >>>>>> Thanks for your time, I've updated the webrev, could you please >>>>>> take a >>>>>> look? >>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>> >>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>> Hi Jonathan >>>>>>> >>>>>>> Some comments: >>>>>>> >>>>>>> 1. Can you be sure that the new format always has the same length? >>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>> should be >>>>>>> aligned. >>>>>> >>>>>> I'm not sure of that, so the test case was updated to compare the >>>>>> first >>>>>> several tokens to determine whether there's any differences in the >>>>>> expression of date time. >>>>> >>>>> Sorry, I didn't make myself clear last time, I was mainly afraid of >>>>> unaligned lines that make the output ugly. >>>>> >>>>> For example: >>>>> >>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>> >>>> >>>> I think that would not be a problem in the new test case which >>>> compares >>>> tokenized strings splited by blank spaces instead of String#equals. >>>> Does >>>> that make sense? >>> >>> I'm not talking about the test. It's the output of jarsigner looking >>> ugly. >>> >>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>> >>> Compare with the current output: >>> >>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >> >> I did not see unaligned format in my testing, did you get these >> unaligned output after applying the patch? From above lines, I see the >> starting indices of date string in each line are always the same, which >> is achieved by jarsigner, but the length of the date strings are not the >> same, which locale were you testing on? >> >>> >>> Thanks >>> Max >>> >>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> >>>>>>> >>>>>>> 2. You might need to reformat the modified line to make it fit >>>>>>> into 80 >>>>>>> characters width. >>>>>>> >>>>>>> 3. Why not include the test inside the changeset? >>>>>> 2, 3 were done in the new patch >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>> Hello security-dev, >>>>>>>> >>>>>>>> Here's a patch for bug 7163483, could anybody please help to >>>>>>>> take a >>>>>>>> look? >>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>> >>>>>>>> The problem is that command "jarsigner -verify -verbose my.jar" >>>>>>>> does not >>>>>>>> format date string according to current locale. following simple >>>>>>>> test >>>>>>>> case can be used to disclose this problem. >>>>>>>> >>>>>>>> /* >>>>>>>> * Copyright (c) 2012 Oracle and/or its affiliates. All rights >>>>>>>> reserved. >>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>>> * >>>>>>>> * This code is free software; you can redistribute it and/or >>>>>>>> modify it >>>>>>>> * under the terms of the GNU General Public License version 2 >>>>>>>> only, as >>>>>>>> * published by the Free Software Foundation. >>>>>>>> * >>>>>>>> * This code is distributed in the hope that it will be useful, but >>>>>>>> WITHOUT >>>>>>>> * ANY WARRANTY; without even the implied warranty of >>>>>>>> MERCHANTABILITY or >>>>>>>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>>>>> License >>>>>>>> * version 2 for more details (a copy is included in the LICENSE >>>>>>>> file >>>>>>>> that >>>>>>>> * accompanied this code). >>>>>>>> * >>>>>>>> * You should have received a copy of the GNU General Public >>>>>>>> License >>>>>>>> version >>>>>>>> * 2 along with this work; if not, write to the Free Software >>>>>>>> Foundation, >>>>>>>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>>>>>> * >>>>>>>> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>>>>>> 94065 >>>>>>>> USA >>>>>>>> * or visit www.oracle.com if you need additional information or >>>>>>>> have any >>>>>>>> * questions. >>>>>>>> */ >>>>>>>> >>>>>>>> /* >>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>> */ >>>>>>>> >>>>>>>> >>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>> import java.io.PrintStream; >>>>>>>> import java.util.Locale; >>>>>>>> import sun.security.tools.JarSigner; >>>>>>>> >>>>>>>> public class bug7163483 { >>>>>>>> >>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>> >>>>>>>> ByteArrayOutputStream stream = new ByteArrayOutputStream(1024*64); >>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>> System.setOut(out); >>>>>>>> >>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>> JarSigner js = new JarSigner(); >>>>>>>> js.run(arg); >>>>>>>> >>>>>>>> out.flush(); >>>>>>>> String s1 = stream.toString(); >>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>> stream.reset(); >>>>>>>> >>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>> js = new JarSigner(); >>>>>>>> js.run(arg); >>>>>>>> >>>>>>>> out.flush(); >>>>>>>> String s2 = stream.toString(); >>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>> >>>>>>>> if (s1.equals(s2)) { >>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>> throw new RuntimeException( >>>>>>>> "JarSigner verbose outputs are the same after setting locale!!"); >>>>>>>> } else { >>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>> System.err.println("Test passed!"); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> Thanks and best regards! >>>>>>>> - Jonathan Lu >>>>>>>> >>>>>>> >>>>>> >>>>>> Best regards! >>>>>> - Jonathan >>>>>> >>>>> >>>> Thanks & regards! >>>> - Jonathan >>>> >>> >> >> Thanks >> - Jonathan >> > From weijun.wang at oracle.com Fri Jul 6 03:27:22 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 06 Jul 2012 18:27:22 +0800 Subject: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale) In-Reply-To: <4FF6ACF7.6020200@linux.vnet.ibm.com> References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com> <4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com> <4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com> <4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com> <4FF6ACF7.6020200@linux.vnet.ibm.com> Message-ID: <4FF6BD8A.4080500@oracle.com> Hi Jonathan I have these questions: 1. Why always CAPITAL letters for month and weekday? 2. Why always "dd HH:mm:ss zzz yyyy" for the rest? Some locales uses "." instead of ":" as times delimiters. 3. Why always dd after MMM? Some locales prefer dd before MMM. Well, if you really think the current "Fri Jul" output is too English, instead of localizing the string, how about we de-localize it totally and choose a neutral format? There are several flavors of ISO date/time format at http://www.w3.org/TR/NOTE-datetime or we can just choose YYYY-MM-dd HH:mm:ss zzz BTW, the jar command is using the same format, therefore I'm adding core-libs-dev. Thanks Max On 07/06/2012 05:16 PM, Jonathan Lu wrote: > Hello Max, > > I's been a long time since my last mail, I did some investigation and > had some discussion with i18n developers, but still did not see a nice > solution for the alignment problem. There does not seem be an existing > API to do this job in JDK scope. So I implemented a simple format > function, and use it to format under different locales. > > http://cr.openjdk.java.net/~luchsh/7163483_3/ > > The patch is trying to format the code in the same way as > java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz > yyyy", except for using names of month and DOW in localized format. So > far, it works good for me under all supported locales. > > Here's a test case to verify the vertical alignment, which I has been > posted to i18n mailing list before, > http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java > > It may still fail under "vi_VN" locale with this solution due to test > case limit, but I do not think it is a real failure since the result > fields still get aligned except for multiple words in one field. > > Could you please take a look at the patch? > > Many thanks & best regards > Jonathan > > On 04/25/2012 07:48 PM, Weijun Wang wrote: >> Hi Jonathan >> >> I'm using English. >> >> In your test all the files have a similar modified time so you cannot >> see the difference. However, in my example, you can see that the >> widths for date and hour are not zero-padded so the width can be >> either 1 or 2. >> >> French is even worse >> >> smk 76 10 nov. 2009 08:57:54 bin/vbin/go >> smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans >> smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown >> smk 671 8 f?vr. 2012 20:11:22 bin/vbin/ssh.desktop >> smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf >> >> So here even the width of month abbr can be different. >> >> Thanks >> Max >> >> >> On 04/25/2012 07:09 PM, Jonathan Lu wrote: >>> Hello Max, >>> >>> Terribly sorry for my misunderstanding! >>> >>> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>>> >>>> >>>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>>> Hi Max, >>>>> >>>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>>> >>>>>> >>>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>>> Hi Weijun, >>>>>>> >>>>>>> Thanks for your time, I've updated the webrev, could you please >>>>>>> take a >>>>>>> look? >>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>>> >>>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>>> Hi Jonathan >>>>>>>> >>>>>>>> Some comments: >>>>>>>> >>>>>>>> 1. Can you be sure that the new format always has the same length? >>>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>>> should be >>>>>>>> aligned. >>>>>>> >>>>>>> I'm not sure of that, so the test case was updated to compare the >>>>>>> first >>>>>>> several tokens to determine whether there's any differences in the >>>>>>> expression of date time. >>>>>> >>>>>> Sorry, I didn't make myself clear last time, I was mainly afraid of >>>>>> unaligned lines that make the output ugly. >>>>>> >>>>>> For example: >>>>>> >>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>> >>>>> >>>>> I think that would not be a problem in the new test case which >>>>> compares >>>>> tokenized strings splited by blank spaces instead of String#equals. >>>>> Does >>>>> that make sense? >>>> >>>> I'm not talking about the test. It's the output of jarsigner looking >>>> ugly. >>>> >>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>> >>>> Compare with the current output: >>>> >>>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >>> >>> I did not see unaligned format in my testing, did you get these >>> unaligned output after applying the patch? From above lines, I see the >>> starting indices of date string in each line are always the same, which >>> is achieved by jarsigner, but the length of the date strings are not the >>> same, which locale were you testing on? >>> >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> >>>>>>>> >>>>>>>> 2. You might need to reformat the modified line to make it fit >>>>>>>> into 80 >>>>>>>> characters width. >>>>>>>> >>>>>>>> 3. Why not include the test inside the changeset? >>>>>>> 2, 3 were done in the new patch >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>>> Hello security-dev, >>>>>>>>> >>>>>>>>> Here's a patch for bug 7163483, could anybody please help to >>>>>>>>> take a >>>>>>>>> look? >>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>>> >>>>>>>>> The problem is that command "jarsigner -verify -verbose my.jar" >>>>>>>>> does not >>>>>>>>> format date string according to current locale. following simple >>>>>>>>> test >>>>>>>>> case can be used to disclose this problem. >>>>>>>>> >>>>>>>>> /* >>>>>>>>> * Copyright (c) 2012 Oracle and/or its affiliates. All rights >>>>>>>>> reserved. >>>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>>>> * >>>>>>>>> * This code is free software; you can redistribute it and/or >>>>>>>>> modify it >>>>>>>>> * under the terms of the GNU General Public License version 2 >>>>>>>>> only, as >>>>>>>>> * published by the Free Software Foundation. >>>>>>>>> * >>>>>>>>> * This code is distributed in the hope that it will be useful, but >>>>>>>>> WITHOUT >>>>>>>>> * ANY WARRANTY; without even the implied warranty of >>>>>>>>> MERCHANTABILITY or >>>>>>>>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>>>>>> License >>>>>>>>> * version 2 for more details (a copy is included in the LICENSE >>>>>>>>> file >>>>>>>>> that >>>>>>>>> * accompanied this code). >>>>>>>>> * >>>>>>>>> * You should have received a copy of the GNU General Public >>>>>>>>> License >>>>>>>>> version >>>>>>>>> * 2 along with this work; if not, write to the Free Software >>>>>>>>> Foundation, >>>>>>>>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>>>>>>> * >>>>>>>>> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>>>>>>> 94065 >>>>>>>>> USA >>>>>>>>> * or visit www.oracle.com if you need additional information or >>>>>>>>> have any >>>>>>>>> * questions. >>>>>>>>> */ >>>>>>>>> >>>>>>>>> /* >>>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>>> */ >>>>>>>>> >>>>>>>>> >>>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>>> import java.io.PrintStream; >>>>>>>>> import java.util.Locale; >>>>>>>>> import sun.security.tools.JarSigner; >>>>>>>>> >>>>>>>>> public class bug7163483 { >>>>>>>>> >>>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>>> >>>>>>>>> ByteArrayOutputStream stream = new ByteArrayOutputStream(1024*64); >>>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>>> System.setOut(out); >>>>>>>>> >>>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>>> JarSigner js = new JarSigner(); >>>>>>>>> js.run(arg); >>>>>>>>> >>>>>>>>> out.flush(); >>>>>>>>> String s1 = stream.toString(); >>>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>>> stream.reset(); >>>>>>>>> >>>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>>> js = new JarSigner(); >>>>>>>>> js.run(arg); >>>>>>>>> >>>>>>>>> out.flush(); >>>>>>>>> String s2 = stream.toString(); >>>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>>> >>>>>>>>> if (s1.equals(s2)) { >>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>> throw new RuntimeException( >>>>>>>>> "JarSigner verbose outputs are the same after setting locale!!"); >>>>>>>>> } else { >>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>> System.err.println("Test passed!"); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> Thanks and best regards! >>>>>>>>> - Jonathan Lu >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Best regards! >>>>>>> - Jonathan >>>>>>> >>>>>> >>>>> Thanks & regards! >>>>> - Jonathan >>>>> >>>> >>> >>> Thanks >>> - Jonathan >>> >> > > From bradford.wetmore at oracle.com Fri Jul 6 19:26:56 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 06 Jul 2012 19:26:56 -0700 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java In-Reply-To: <4FF263C7.1030808@oracle.com> References: <4FF109F2.90307@oracle.com> <4FF15D3A.1000706@oracle.com> <4FF24F83.7030200@oracle.com> <4FF252C1.1000606@oracle.com> <4FF25AE4.4010703@oracle.com> <4FF25B9F.3020805@oracle.com> <4FF2603A.7020708@oracle.com> <4FF26255.8010908@oracle.com> <4FF263C7.1030808@oracle.com> Message-ID: <4FF79E70.5070409@oracle.com> > It was the abbreviated handshaking. I guess that the previous client > has not closed the socket completely, so for *this* handshaking, the > abbreviated handshaking rather than the full handshaking is used. The issue is not due to closing the previous connections completely. The two close messages are racing and the messages appeared out of the "normal" ordering in this one case when the thread did a simple session resume. > I tied several different approaches within this test, but failed to > reproduce the abbreviated handshaking. It is not easy to hack the > test without significant changes. The original testcase was for the bad_record_mac issue, and testing whether or not ByteBuffers with valid hasArray() was working correctly. I wasn't intending to test renegotiation/abbreviated handshakes. I obviously didn't completely step through the code when I added the second runTest(). :( That explains the race condition on close ordering, and the issue is still there. A better fix would be the following so that the test is actually starting from scratch each time (no session resumes): diff --git a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java --- a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java +++ b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java @@ -146,14 +146,13 @@ "SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2" }; for (String protocol : protocols) { - log("Testing " + protocol); /* * Run the tests with direct and indirect buffers. */ - SSLEngineBadBufferArrayAccess test = - new SSLEngineBadBufferArrayAccess(protocol); - test.runTest(true); - test.runTest(false); + log("Testing " + protocol + ":true"); + new SSLEngineBadBufferArrayAccess(protocol).runTest(true); + log("Testing " + protocol + ":false"); + new SSLEngineBadBufferArrayAccess(protocol).runTest(false); } System.out.println("Test Passed."); Please consider opening a new bug and changing. Brad On 7/2/2012 8:15 PM, Xuelei Fan wrote: > On 7/3/2012 11:09 AM, Weijun Wang wrote: >> Your fix looks fine. >> > Thanks! > >> IMHO, the remind is not really useful unless you dump more info, say, >> the value of serverIn.remaining(). > We can get the value from analysis of the log. The remind is only used > for the case that we do not really fix the issue with this update. > > Xuelei > >> QE would report the failure to "THE >> SECURITY TEAM" anyway. >> >> -Max >> >> On 07/03/2012 11:00 AM, Xuelei Fan wrote: >>> On 7/3/2012 10:40 AM, Weijun Wang wrote: >>>> No new test needed. I only think that you might be able to hack the >>>> current test a little to reproduce this and see if the failure is the >>>> same and if your code change can fix it. There is no need to keep this >>>> hack in your final changeset. >>>> >>> I tied several different approaches within this test, but failed to >>> reproduce the abbreviated handshaking. ;-) It is not easy to hack the >>> test without significant changes. >>> >>> Xuelei >>> >>>> -Max >>>> >>>> >>>> On 07/03/2012 10:37 AM, Xuelei Fan wrote: >>>>> On 7/3/2012 10:02 AM, Weijun Wang wrote: >>>>>> >>>>>> >>>>>> On 07/03/2012 09:48 AM, Xuelei Fan wrote: >>>>>>> On 7/2/2012 4:35 PM, Weijun Wang wrote: >>>>>>>> I take a look at the test output. When the last handshake starts: >>>>>>>> >>>>>>>> ================ >>>>>>>> server unwrap: OK/NEED_TASK, 230/0 bytes >>>>>>>> running delegated task... >>>>>>>> new HandshakeStatus: NEED_WRAP >>>>>>>> ---- >>>>>>>> server wrap: OK/NEED_WRAP, 0/86 bytes >>>>>>>> ================ >>>>>>>> >>>>>>>> Here the first wrap only generates 86 bytes, I guess that's the >>>>>>>> ServerHello message? It keeps the state at NEED_WRAP but then never >>>>>>>> really generates the Certificate message. What might be the problem? >>>>>>>> >>>>>>> Good catch! >>>>>>> >>>>>>> It was the abbreviated handshaking. I guess that the previous client >>>>>>> has >>>>>>> not closed the socket completely, so for *this* handshaking, the >>>>>>> abbreviated handshaking rather than the full handshaking is used. >>>>>>> >>>>>>> For full handshaking, it is the client sending the "Finished" >>>>>>> message at >>>>>>> first. However, for abbreviated handshaking, the server send the >>>>>>> "Finished" message at first. >>>>>>> >>>>>>> In the current scenarios, it is expected that the client sends its >>>>>>> application data (26 bytes), and then the server sends its >>>>>>> application >>>>>>> data (29 bytes). However, the abbreviated handshaking disorder the >>>>>>> sequence in that it is the sever sends it application data (29 bytes) >>>>>>> before client. In such cases, the following logic does not stand any >>>>>>> more: >>>>>>> if (!closed&& (serverOut.remaining() == 0)) { >>>>>>> closed = true; >>>>>>> ... >>>>>>> if (serverIn.remaining() != clientMsg.length) { >>>>>>> >>>>>>> throw new Exception("Client: Data length error"); >>>>>>> } >>>>>>> ... >>>>>>> } >>>>>>> >>>>>>> Because the server has not receive the client message when the server >>>>>>> sends its application data. >>>>>>> >>>>>>> I think it is a test issue, the current fix should has already >>>>>>> addressed >>>>>>> the issue. >>>>>> >>>>>> That's great. >>>>>> >>>>>> Since the reason is clear, can you reproduce this failure and then >>>>>> confirm the current fix does solve the problem? >>>>>> >>>>> It is possible to reproduce this failure with a new test case. But >>>>> it is >>>>> pretty hard to reproduce it within this test. I was wondering as it is >>>>> test bug, so we may not want a extra test case to prove that this test >>>>> is correct. >>>>> >>>>> We also have a nested remind that, "IF THIS FAILS, PLEASE REPORT >>>>> THIS TO >>>>> THE SECURITY TEAM. WE HAVE BEEN UNABLE TO RELIABLY DUPLICATE." I think >>>>> it might be OK that we do not reproduce this issue at present. >>>>> >>>>> What do you think? >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> On 07/02/2012 10:39 AM, Xuelei Fan wrote: >>>>>>>>> Hi Weijun, >>>>>>>>> >>>>>>>>> Would you please review the test update for CR 7180038? >>>>>>>>> http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ >>>>>>>>> >>>>>>>>> We cannot reproduce the issue. However, from the test log, there >>>>>>>>> is two >>>>>>>>> possible issues exposed by this CR. >>>>>>>>> 1. the improper test case senarios of un/wrap() >>>>>>>>> In the test case, the scenarios is >>>>>>>>> unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != >>>>>>>>> clientMsg.length". After the wrap(), the next operation may need >>>>>>>>> to be >>>>>>>>> unwrap() to get more incoming data before comparing serverIn buffer >>>>>>>>> with >>>>>>>>> the expected client message. >>>>>>>>> >>>>>>>>> This fix is trying to do the comparing after the engine has >>>>>>>>> closed. >>>>>>>>> >>>>>>>>> 2. From the log, the engine status and handshaking status move from >>>>>>>>> CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS >>>>>>>>> handshaking just finished. As the handshaking should have >>>>>>>>> completed for >>>>>>>>> a while, it does not sound like a correct status change. >>>>>>>>> >>>>>>>>> However, I did not find why this happens. Need more >>>>>>>>> info. So I >>>>>>>>> added >>>>>>>>> a line of log (suggested by Brad Wetmore) to collect the next >>>>>>>>> failure: >>>>>>>>> >>>>>>>>> IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY TEAM. WE >>>>>>>>> HAVE >>>>>>>>> BEEN UNABLE TO RELIABLY DUPLICATE. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From xuelei.fan at oracle.com Sun Jul 8 19:30:05 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 09 Jul 2012 10:30:05 +0800 Subject: Code review request, CR 7180038 regression test failure, SSLEngineBadBufferArrayAccess.java In-Reply-To: <4FF79E70.5070409@oracle.com> References: <4FF109F2.90307@oracle.com> <4FF15D3A.1000706@oracle.com> <4FF24F83.7030200@oracle.com> <4FF252C1.1000606@oracle.com> <4FF25AE4.4010703@oracle.com> <4FF25B9F.3020805@oracle.com> <4FF2603A.7020708@oracle.com> <4FF26255.8010908@oracle.com> <4FF263C7.1030808@oracle.com> <4FF79E70.5070409@oracle.com> Message-ID: <4FFA422D.4040809@oracle.com> On 7/7/2012 10:26 AM, Brad Wetmore wrote: >> It was the abbreviated handshaking. I guess that the previous client >> has not closed the socket completely, so for *this* handshaking, the >> abbreviated handshaking rather than the full handshaking is used. > > The issue is not due to closing the previous connections completely. The > two close messages are racing and the messages appeared out of the > "normal" ordering in this one case when the thread did a simple session > resume. > I think there may be no two racing close messages. It is just a session resuming that cause abbreviated handshaking. >> I tied several different approaches within this test, but failed to >> reproduce the abbreviated handshaking. It is not easy to hack the >> test without significant changes. > > The original testcase was for the bad_record_mac issue, and testing > whether or not ByteBuffers with valid hasArray() was working correctly. > I wasn't intending to test renegotiation/abbreviated handshakes. I see. But you don't mind if the handshaking is abbreviated handshakes, right? I think renegotiation/abbreviated handshakes also expose the the bad_record_mac issue. > I > obviously didn't completely step through the code when I added the > second runTest(). :( That explains the race condition on close > ordering, and the issue is still there. > > A better fix would be the following so that the test is actually > starting from scratch each time (no session resumes): > The following fix only disables abbreviate handshakes. I don't think it addresses the issue properly. There is a assumption in the test that after the final wrap() in runTest(), when server send out its application data, the server should have already received application data from client. That's not true, the next call after the final wrap() may need a unwrap() to parser application data from client. Please see my evaluation in the bug or my previous mails in the thread. Abbreviated handshaking just expose the issue. Abbreviated handshaking is not the real issue. Thanks for the comments. Xuelei > diff --git > a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java > b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java > > --- > a/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java > > +++ > b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java > > @@ -146,14 +146,13 @@ > "SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2" }; > > for (String protocol : protocols) { > - log("Testing " + protocol); > /* > * Run the tests with direct and indirect buffers. > */ > - SSLEngineBadBufferArrayAccess test = > - new SSLEngineBadBufferArrayAccess(protocol); > - test.runTest(true); > - test.runTest(false); > + log("Testing " + protocol + ":true"); > + new SSLEngineBadBufferArrayAccess(protocol).runTest(true); > + log("Testing " + protocol + ":false"); > + new SSLEngineBadBufferArrayAccess(protocol).runTest(false); > } > > System.out.println("Test Passed."); > > Please consider opening a new bug and changing. > > Brad > > > > > On 7/2/2012 8:15 PM, Xuelei Fan wrote: >> On 7/3/2012 11:09 AM, Weijun Wang wrote: >>> Your fix looks fine. >>> >> Thanks! >> >>> IMHO, the remind is not really useful unless you dump more info, say, >>> the value of serverIn.remaining(). >> We can get the value from analysis of the log. The remind is only used >> for the case that we do not really fix the issue with this update. >> >> Xuelei >> >>> QE would report the failure to "THE >>> SECURITY TEAM" anyway. >>> >>> -Max >>> >>> On 07/03/2012 11:00 AM, Xuelei Fan wrote: >>>> On 7/3/2012 10:40 AM, Weijun Wang wrote: >>>>> No new test needed. I only think that you might be able to hack the >>>>> current test a little to reproduce this and see if the failure is the >>>>> same and if your code change can fix it. There is no need to keep this >>>>> hack in your final changeset. >>>>> >>>> I tied several different approaches within this test, but failed to >>>> reproduce the abbreviated handshaking. ;-) It is not easy to hack the >>>> test without significant changes. >>>> >>>> Xuelei >>>> >>>>> -Max >>>>> >>>>> >>>>> On 07/03/2012 10:37 AM, Xuelei Fan wrote: >>>>>> On 7/3/2012 10:02 AM, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>> On 07/03/2012 09:48 AM, Xuelei Fan wrote: >>>>>>>> On 7/2/2012 4:35 PM, Weijun Wang wrote: >>>>>>>>> I take a look at the test output. When the last handshake starts: >>>>>>>>> >>>>>>>>> ================ >>>>>>>>> server unwrap: OK/NEED_TASK, 230/0 bytes >>>>>>>>> running delegated task... >>>>>>>>> new HandshakeStatus: NEED_WRAP >>>>>>>>> ---- >>>>>>>>> server wrap: OK/NEED_WRAP, 0/86 bytes >>>>>>>>> ================ >>>>>>>>> >>>>>>>>> Here the first wrap only generates 86 bytes, I guess that's the >>>>>>>>> ServerHello message? It keeps the state at NEED_WRAP but then >>>>>>>>> never >>>>>>>>> really generates the Certificate message. What might be the >>>>>>>>> problem? >>>>>>>>> >>>>>>>> Good catch! >>>>>>>> >>>>>>>> It was the abbreviated handshaking. I guess that the previous >>>>>>>> client >>>>>>>> has >>>>>>>> not closed the socket completely, so for *this* handshaking, the >>>>>>>> abbreviated handshaking rather than the full handshaking is used. >>>>>>>> >>>>>>>> For full handshaking, it is the client sending the "Finished" >>>>>>>> message at >>>>>>>> first. However, for abbreviated handshaking, the server send the >>>>>>>> "Finished" message at first. >>>>>>>> >>>>>>>> In the current scenarios, it is expected that the client sends its >>>>>>>> application data (26 bytes), and then the server sends its >>>>>>>> application >>>>>>>> data (29 bytes). However, the abbreviated handshaking disorder the >>>>>>>> sequence in that it is the sever sends it application data (29 >>>>>>>> bytes) >>>>>>>> before client. In such cases, the following logic does not stand >>>>>>>> any >>>>>>>> more: >>>>>>>> if (!closed&& (serverOut.remaining() == 0)) { >>>>>>>> closed = true; >>>>>>>> ... >>>>>>>> if (serverIn.remaining() != clientMsg.length) { >>>>>>>> >>>>>>>> throw new Exception("Client: Data length error"); >>>>>>>> } >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> Because the server has not receive the client message when the >>>>>>>> server >>>>>>>> sends its application data. >>>>>>>> >>>>>>>> I think it is a test issue, the current fix should has already >>>>>>>> addressed >>>>>>>> the issue. >>>>>>> >>>>>>> That's great. >>>>>>> >>>>>>> Since the reason is clear, can you reproduce this failure and then >>>>>>> confirm the current fix does solve the problem? >>>>>>> >>>>>> It is possible to reproduce this failure with a new test case. But >>>>>> it is >>>>>> pretty hard to reproduce it within this test. I was wondering as >>>>>> it is >>>>>> test bug, so we may not want a extra test case to prove that this >>>>>> test >>>>>> is correct. >>>>>> >>>>>> We also have a nested remind that, "IF THIS FAILS, PLEASE REPORT >>>>>> THIS TO >>>>>> THE SECURITY TEAM. WE HAVE BEEN UNABLE TO RELIABLY DUPLICATE." I >>>>>> think >>>>>> it might be OK that we do not reproduce this issue at present. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> >>>>>>>> Xuelei >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 07/02/2012 10:39 AM, Xuelei Fan wrote: >>>>>>>>>> Hi Weijun, >>>>>>>>>> >>>>>>>>>> Would you please review the test update for CR 7180038? >>>>>>>>>> http://cr.openjdk.java.net./~xuelei/7180038/webrev.00/ >>>>>>>>>> >>>>>>>>>> We cannot reproduce the issue. However, from the test log, there >>>>>>>>>> is two >>>>>>>>>> possible issues exposed by this CR. >>>>>>>>>> 1. the improper test case senarios of un/wrap() >>>>>>>>>> In the test case, the scenarios is >>>>>>>>>> unwrap()->wrap()->serverOut.remaining()->"serverIn.remaining() != >>>>>>>>>> clientMsg.length". After the wrap(), the next operation may need >>>>>>>>>> to be >>>>>>>>>> unwrap() to get more incoming data before comparing serverIn >>>>>>>>>> buffer >>>>>>>>>> with >>>>>>>>>> the expected client message. >>>>>>>>>> >>>>>>>>>> This fix is trying to do the comparing after the >>>>>>>>>> engine has >>>>>>>>>> closed. >>>>>>>>>> >>>>>>>>>> 2. From the log, the engine status and handshaking status move >>>>>>>>>> from >>>>>>>>>> CLOSED/NOT_HANDSHAKING to OK/FINISHED. FINISHED means the TLS >>>>>>>>>> handshaking just finished. As the handshaking should have >>>>>>>>>> completed for >>>>>>>>>> a while, it does not sound like a correct status change. >>>>>>>>>> >>>>>>>>>> However, I did not find why this happens. Need more >>>>>>>>>> info. So I >>>>>>>>>> added >>>>>>>>>> a line of log (suggested by Brad Wetmore) to collect the next >>>>>>>>>> failure: >>>>>>>>>> >>>>>>>>>> IF THIS FAILS, PLEASE REPORT THIS TO THE SECURITY >>>>>>>>>> TEAM. WE >>>>>>>>>> HAVE >>>>>>>>>> BEEN UNABLE TO RELIABLY DUPLICATE. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> From luchsh at linux.vnet.ibm.com Mon Jul 9 00:24:22 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 09 Jul 2012 15:24:22 +0800 Subject: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale) In-Reply-To: <4FF6BD8A.4080500@oracle.com> References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com> <4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com> <4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com> <4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com> <4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com> Message-ID: <4FFA8726.60306@linux.vnet.ibm.com> Hi Max, Thanks for reviewing. On 07/06/2012 06:27 PM, Weijun Wang wrote: > Hi Jonathan > > I have these questions: > > 1. Why always CAPITAL letters for month and weekday? This is a fault of the patch, which can be easily fixed by updating the format string. > > 2. Why always "dd HH:mm:ss zzz yyyy" for the rest? Some locales uses > "." instead of ":" as times delimiters. > > 3. Why always dd after MMM? Some locales prefer dd before MMM. For question #2 and #3, I was just trying to follow the original format of Date.toString(). > > Well, if you really think the current "Fri Jul" output is too English, > instead of localizing the string, how about we de-localize it totally > and choose a neutral format? > > There are several flavors of ISO date/time format at > > http://www.w3.org/TR/NOTE-datetime > > or we can just choose > > YYYY-MM-dd HH:mm:ss zzz Good idea, how about a patch in this way? http://cr.openjdk.java.net/~luchsh/7163483_4/ And I prefer to your format since it looks more readable to me. Thanks and best regards! Jonathan > > BTW, the jar command is using the same format, therefore I'm adding > core-libs-dev. > > Thanks > Max > > > On 07/06/2012 05:16 PM, Jonathan Lu wrote: >> Hello Max, >> >> I's been a long time since my last mail, I did some investigation and >> had some discussion with i18n developers, but still did not see a nice >> solution for the alignment problem. There does not seem be an existing >> API to do this job in JDK scope. So I implemented a simple format >> function, and use it to format under different locales. >> >> http://cr.openjdk.java.net/~luchsh/7163483_3/ >> >> The patch is trying to format the code in the same way as >> java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz >> yyyy", except for using names of month and DOW in localized format. So >> far, it works good for me under all supported locales. >> >> Here's a test case to verify the vertical alignment, which I has been >> posted to i18n mailing list before, >> http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java >> >> It may still fail under "vi_VN" locale with this solution due to test >> case limit, but I do not think it is a real failure since the result >> fields still get aligned except for multiple words in one field. >> >> Could you please take a look at the patch? >> >> Many thanks & best regards >> Jonathan >> >> On 04/25/2012 07:48 PM, Weijun Wang wrote: >>> Hi Jonathan >>> >>> I'm using English. >>> >>> In your test all the files have a similar modified time so you cannot >>> see the difference. However, in my example, you can see that the >>> widths for date and hour are not zero-padded so the width can be >>> either 1 or 2. >>> >>> French is even worse >>> >>> smk 76 10 nov. 2009 08:57:54 bin/vbin/go >>> smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans >>> smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown >>> smk 671 8 f?vr. 2012 20:11:22 bin/vbin/ssh.desktop >>> smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf >>> >>> So here even the width of month abbr can be different. >>> >>> Thanks >>> Max >>> >>> >>> On 04/25/2012 07:09 PM, Jonathan Lu wrote: >>>> Hello Max, >>>> >>>> Terribly sorry for my misunderstanding! >>>> >>>> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>>>> >>>>> >>>>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>>>> Hi Max, >>>>>> >>>>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>>>> Hi Weijun, >>>>>>>> >>>>>>>> Thanks for your time, I've updated the webrev, could you please >>>>>>>> take a >>>>>>>> look? >>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>>>> >>>>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>>>> Hi Jonathan >>>>>>>>> >>>>>>>>> Some comments: >>>>>>>>> >>>>>>>>> 1. Can you be sure that the new format always has the same >>>>>>>>> length? >>>>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>>>> should be >>>>>>>>> aligned. >>>>>>>> >>>>>>>> I'm not sure of that, so the test case was updated to compare the >>>>>>>> first >>>>>>>> several tokens to determine whether there's any differences in the >>>>>>>> expression of date time. >>>>>>> >>>>>>> Sorry, I didn't make myself clear last time, I was mainly afraid of >>>>>>> unaligned lines that make the output ugly. >>>>>>> >>>>>>> For example: >>>>>>> >>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>> >>>>>> >>>>>> I think that would not be a problem in the new test case which >>>>>> compares >>>>>> tokenized strings splited by blank spaces instead of String#equals. >>>>>> Does >>>>>> that make sense? >>>>> >>>>> I'm not talking about the test. It's the output of jarsigner looking >>>>> ugly. >>>>> >>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>> >>>>> Compare with the current output: >>>>> >>>>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>>>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>>>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>>>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>>>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >>>> >>>> I did not see unaligned format in my testing, did you get these >>>> unaligned output after applying the patch? From above lines, I see the >>>> starting indices of date string in each line are always the same, >>>> which >>>> is achieved by jarsigner, but the length of the date strings are >>>> not the >>>> same, which locale were you testing on? >>>> >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 2. You might need to reformat the modified line to make it fit >>>>>>>>> into 80 >>>>>>>>> characters width. >>>>>>>>> >>>>>>>>> 3. Why not include the test inside the changeset? >>>>>>>> 2, 3 were done in the new patch >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>>>> Hello security-dev, >>>>>>>>>> >>>>>>>>>> Here's a patch for bug 7163483, could anybody please help to >>>>>>>>>> take a >>>>>>>>>> look? >>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>>>> >>>>>>>>>> The problem is that command "jarsigner -verify -verbose my.jar" >>>>>>>>>> does not >>>>>>>>>> format date string according to current locale. following simple >>>>>>>>>> test >>>>>>>>>> case can be used to disclose this problem. >>>>>>>>>> >>>>>>>>>> /* >>>>>>>>>> * Copyright (c) 2012 Oracle and/or its affiliates. All rights >>>>>>>>>> reserved. >>>>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>>>>> * >>>>>>>>>> * This code is free software; you can redistribute it and/or >>>>>>>>>> modify it >>>>>>>>>> * under the terms of the GNU General Public License version 2 >>>>>>>>>> only, as >>>>>>>>>> * published by the Free Software Foundation. >>>>>>>>>> * >>>>>>>>>> * This code is distributed in the hope that it will be >>>>>>>>>> useful, but >>>>>>>>>> WITHOUT >>>>>>>>>> * ANY WARRANTY; without even the implied warranty of >>>>>>>>>> MERCHANTABILITY or >>>>>>>>>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>>>>>>> License >>>>>>>>>> * version 2 for more details (a copy is included in the LICENSE >>>>>>>>>> file >>>>>>>>>> that >>>>>>>>>> * accompanied this code). >>>>>>>>>> * >>>>>>>>>> * You should have received a copy of the GNU General Public >>>>>>>>>> License >>>>>>>>>> version >>>>>>>>>> * 2 along with this work; if not, write to the Free Software >>>>>>>>>> Foundation, >>>>>>>>>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>>>>>>>> * >>>>>>>>>> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>>>>>>>> 94065 >>>>>>>>>> USA >>>>>>>>>> * or visit www.oracle.com if you need additional information or >>>>>>>>>> have any >>>>>>>>>> * questions. >>>>>>>>>> */ >>>>>>>>>> >>>>>>>>>> /* >>>>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>>>> */ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>>>> import java.io.PrintStream; >>>>>>>>>> import java.util.Locale; >>>>>>>>>> import sun.security.tools.JarSigner; >>>>>>>>>> >>>>>>>>>> public class bug7163483 { >>>>>>>>>> >>>>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>>>> >>>>>>>>>> ByteArrayOutputStream stream = new >>>>>>>>>> ByteArrayOutputStream(1024*64); >>>>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>>>> System.setOut(out); >>>>>>>>>> >>>>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>>>> JarSigner js = new JarSigner(); >>>>>>>>>> js.run(arg); >>>>>>>>>> >>>>>>>>>> out.flush(); >>>>>>>>>> String s1 = stream.toString(); >>>>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>>>> stream.reset(); >>>>>>>>>> >>>>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>>>> js = new JarSigner(); >>>>>>>>>> js.run(arg); >>>>>>>>>> >>>>>>>>>> out.flush(); >>>>>>>>>> String s2 = stream.toString(); >>>>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>>>> >>>>>>>>>> if (s1.equals(s2)) { >>>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>>> throw new RuntimeException( >>>>>>>>>> "JarSigner verbose outputs are the same after setting >>>>>>>>>> locale!!"); >>>>>>>>>> } else { >>>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>>> System.err.println("Test passed!"); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Thanks and best regards! >>>>>>>>>> - Jonathan Lu >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Best regards! >>>>>>>> - Jonathan >>>>>>>> >>>>>>> >>>>>> Thanks & regards! >>>>>> - Jonathan >>>>>> >>>>> >>>> >>>> Thanks >>>> - Jonathan >>>> >>> >> >> > From yiming.wang at oracle.com Mon Jul 9 01:13:45 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Mon, 09 Jul 2012 16:13:45 +0800 Subject: Review request (Resend) - bug 7147060 com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode Message-ID: <4FFA92B9.50604@oracle.com> Hi Sean, Looks that security-dev alias rejected my previous mail as i was not the member of it. so I resent this fix again. Can you please help to review? Thanks! Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: 7147060.zip Type: application/x-zip-compressed Size: 82921 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20120709/b23e2cd0/7147060.zip -------------- next part -------------- --- old/test/ProblemList.txt 2012-07-05 15:57:49.477164126 +0800 +++ new/test/ProblemList.txt 2012-07-05 15:57:45.177070426 +0800 @@ -290,9 +290,6 @@ # 7177556 com/sun/crypto/provider/KeyFactory/TestProviderLeak.java generic-all -# 7147060 -com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java generic-all - # Failing on Solaris i586, 3/9/2010, not a -samevm issue (jdk_security3) sun/security/pkcs11/Secmod/AddPrivateKey.java solaris-i586 sun/security/pkcs11/ec/ReadCertificates.java generic-all -------------- next part -------------- --- old/test/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java 2012-07-05 15:57:56.799140287 +0800 +++ new/test/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java 2012-07-05 15:57:54.790043435 +0800 @@ -39,7 +39,7 @@ public class ClassLoaderTest { - private final static String BASE = System.getProperty("test.src", "./"); + private final static String BASE = System.getProperty("test.classes", "./"); public static void main(String[] args) throws Exception { @@ -50,15 +50,26 @@ URLClassLoader ucl = new URLClassLoader(urls); Class c = ucl.loadClass("MyTransform"); Constructor cons = c.getConstructor(); - Object o = cons.newInstance(); - // Apache code swallows the ClassNotFoundExc, so we need to - // check if the Transform has already been registered by registering - // it again and catching an AlgorithmAlreadyRegisteredExc + + Thread curThread = Thread.currentThread(); + ClassLoader ctxLoader = curThread.getContextClassLoader(); + ClassLoader loader = MyTransform.class.getClassLoader(); try { + // In agentvm mode, the class MyTransform is loaded by the child of + // context ClassLoader of this thread. Replace context ClassLoader + // with its child to avoid ClassNotFoundException thrown from + // Transform.register(String, String) method. + curThread.setContextClassLoader(loader); + Object o = cons.newInstance(); + // Apache code swallows the ClassNotFoundExc, so we need to + // check if the Transform has already been registered by registering + // it again and catching an AlgorithmAlreadyRegisteredExc Transform.register(MyTransform.URI, "MyTransform"); throw new Exception("ClassLoaderTest failed"); } catch (AlgorithmAlreadyRegisteredException e) { // test passed + } finally { + curThread.setContextClassLoader(ctxLoader); } } } From rob.mckenna at oracle.com Mon Jul 9 14:24:13 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Mon, 09 Jul 2012 21:24:13 +0000 Subject: hg: jdk8/tl/jdk: 7179305: (fs) Method name sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled Message-ID: <20120709212431.5266947EB8@hg.openjdk.java.net> Changeset: 516e0c884af2 Author: robm Date: 2012-07-09 22:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/516e0c884af2 7179305: (fs) Method name sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled Reviewed-by: dholmes, chegar ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixException.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixPath.java From weijun.wang at oracle.com Mon Jul 9 17:54:28 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 10 Jul 2012 08:54:28 +0800 Subject: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale) In-Reply-To: <4FFA8726.60306@linux.vnet.ibm.com> References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com> <4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com> <4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com> <4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com> <4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com> <4FFA8726.60306@linux.vnet.ibm.com> Message-ID: <4FFB7D44.8010201@oracle.com> Hi Jonathon This is better. Two minor comments, you can decide what to do or we can see what core-lib-devs think: 1. Current output uses "zzz" for timezones, you're using "ZZZ". It might be more of an ISO flavor. 2. The DateFormat.format(Date,StringBuffer,FilePosition) is quite advanced. If it's me, I'll use the simpler format(Data) method. Since the jar command also uses the same output format, can you also make the same change there (that's sun.tools.jar.Main) and ask core-libs-dev at openjdk.java.net for a review? Sherman (xueming.shen at oracle.com) owns the jar tool. Thanks Max On 07/09/2012 03:24 PM, Jonathan Lu wrote: > Hi Max, > > Thanks for reviewing. > > On 07/06/2012 06:27 PM, Weijun Wang wrote: >> Hi Jonathan >> >> I have these questions: >> >> 1. Why always CAPITAL letters for month and weekday? > > This is a fault of the patch, which can be easily fixed by updating the > format string. > >> >> 2. Why always "dd HH:mm:ss zzz yyyy" for the rest? Some locales uses >> "." instead of ":" as times delimiters. >> 3. Why always dd after MMM? Some locales prefer dd before MMM. > > For question #2 and #3, I was just trying to follow the original format > of Date.toString(). > >> >> Well, if you really think the current "Fri Jul" output is too English, >> instead of localizing the string, how about we de-localize it totally >> and choose a neutral format? >> >> There are several flavors of ISO date/time format at >> >> http://www.w3.org/TR/NOTE-datetime >> >> or we can just choose >> >> YYYY-MM-dd HH:mm:ss zzz > > Good idea, how about a patch in this way? > http://cr.openjdk.java.net/~luchsh/7163483_4/ > > And I prefer to your format since it looks more readable to me. > > Thanks and best regards! > Jonathan > >> >> BTW, the jar command is using the same format, therefore I'm adding >> core-libs-dev. >> >> Thanks >> Max >> >> >> On 07/06/2012 05:16 PM, Jonathan Lu wrote: >>> Hello Max, >>> >>> I's been a long time since my last mail, I did some investigation and >>> had some discussion with i18n developers, but still did not see a nice >>> solution for the alignment problem. There does not seem be an existing >>> API to do this job in JDK scope. So I implemented a simple format >>> function, and use it to format under different locales. >>> >>> http://cr.openjdk.java.net/~luchsh/7163483_3/ >>> >>> The patch is trying to format the code in the same way as >>> java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz >>> yyyy", except for using names of month and DOW in localized format. So >>> far, it works good for me under all supported locales. >>> >>> Here's a test case to verify the vertical alignment, which I has been >>> posted to i18n mailing list before, >>> http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java >>> >>> It may still fail under "vi_VN" locale with this solution due to test >>> case limit, but I do not think it is a real failure since the result >>> fields still get aligned except for multiple words in one field. >>> >>> Could you please take a look at the patch? >>> >>> Many thanks & best regards >>> Jonathan >>> >>> On 04/25/2012 07:48 PM, Weijun Wang wrote: >>>> Hi Jonathan >>>> >>>> I'm using English. >>>> >>>> In your test all the files have a similar modified time so you cannot >>>> see the difference. However, in my example, you can see that the >>>> widths for date and hour are not zero-padded so the width can be >>>> either 1 or 2. >>>> >>>> French is even worse >>>> >>>> smk 76 10 nov. 2009 08:57:54 bin/vbin/go >>>> smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans >>>> smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown >>>> smk 671 8 f?vr. 2012 20:11:22 bin/vbin/ssh.desktop >>>> smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf >>>> >>>> So here even the width of month abbr can be different. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 04/25/2012 07:09 PM, Jonathan Lu wrote: >>>>> Hello Max, >>>>> >>>>> Terribly sorry for my misunderstanding! >>>>> >>>>> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>>>>> >>>>>> >>>>>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>>>>> Hi Weijun, >>>>>>>>> >>>>>>>>> Thanks for your time, I've updated the webrev, could you please >>>>>>>>> take a >>>>>>>>> look? >>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>>>>> >>>>>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>>>>> Hi Jonathan >>>>>>>>>> >>>>>>>>>> Some comments: >>>>>>>>>> >>>>>>>>>> 1. Can you be sure that the new format always has the same >>>>>>>>>> length? >>>>>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>>>>> should be >>>>>>>>>> aligned. >>>>>>>>> >>>>>>>>> I'm not sure of that, so the test case was updated to compare the >>>>>>>>> first >>>>>>>>> several tokens to determine whether there's any differences in the >>>>>>>>> expression of date time. >>>>>>>> >>>>>>>> Sorry, I didn't make myself clear last time, I was mainly afraid of >>>>>>>> unaligned lines that make the output ugly. >>>>>>>> >>>>>>>> For example: >>>>>>>> >>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>> >>>>>>> >>>>>>> I think that would not be a problem in the new test case which >>>>>>> compares >>>>>>> tokenized strings splited by blank spaces instead of String#equals. >>>>>>> Does >>>>>>> that make sense? >>>>>> >>>>>> I'm not talking about the test. It's the output of jarsigner looking >>>>>> ugly. >>>>>> >>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>> >>>>>> Compare with the current output: >>>>>> >>>>>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>>>>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>>>>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>>>>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>>>>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >>>>> >>>>> I did not see unaligned format in my testing, did you get these >>>>> unaligned output after applying the patch? From above lines, I see the >>>>> starting indices of date string in each line are always the same, >>>>> which >>>>> is achieved by jarsigner, but the length of the date strings are >>>>> not the >>>>> same, which locale were you testing on? >>>>> >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2. You might need to reformat the modified line to make it fit >>>>>>>>>> into 80 >>>>>>>>>> characters width. >>>>>>>>>> >>>>>>>>>> 3. Why not include the test inside the changeset? >>>>>>>>> 2, 3 were done in the new patch >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>>>>> Hello security-dev, >>>>>>>>>>> >>>>>>>>>>> Here's a patch for bug 7163483, could anybody please help to >>>>>>>>>>> take a >>>>>>>>>>> look? >>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>>>>> >>>>>>>>>>> The problem is that command "jarsigner -verify -verbose my.jar" >>>>>>>>>>> does not >>>>>>>>>>> format date string according to current locale. following simple >>>>>>>>>>> test >>>>>>>>>>> case can be used to disclose this problem. >>>>>>>>>>> >>>>>>>>>>> /* >>>>>>>>>>> * Copyright (c) 2012 Oracle and/or its affiliates. All rights >>>>>>>>>>> reserved. >>>>>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>>>>>> * >>>>>>>>>>> * This code is free software; you can redistribute it and/or >>>>>>>>>>> modify it >>>>>>>>>>> * under the terms of the GNU General Public License version 2 >>>>>>>>>>> only, as >>>>>>>>>>> * published by the Free Software Foundation. >>>>>>>>>>> * >>>>>>>>>>> * This code is distributed in the hope that it will be >>>>>>>>>>> useful, but >>>>>>>>>>> WITHOUT >>>>>>>>>>> * ANY WARRANTY; without even the implied warranty of >>>>>>>>>>> MERCHANTABILITY or >>>>>>>>>>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>>>>>>>> License >>>>>>>>>>> * version 2 for more details (a copy is included in the LICENSE >>>>>>>>>>> file >>>>>>>>>>> that >>>>>>>>>>> * accompanied this code). >>>>>>>>>>> * >>>>>>>>>>> * You should have received a copy of the GNU General Public >>>>>>>>>>> License >>>>>>>>>>> version >>>>>>>>>>> * 2 along with this work; if not, write to the Free Software >>>>>>>>>>> Foundation, >>>>>>>>>>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>>>>>>>>>> * >>>>>>>>>>> * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>>>>>>>>>> 94065 >>>>>>>>>>> USA >>>>>>>>>>> * or visit www.oracle.com if you need additional information or >>>>>>>>>>> have any >>>>>>>>>>> * questions. >>>>>>>>>>> */ >>>>>>>>>>> >>>>>>>>>>> /* >>>>>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>>>>> */ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>>>>> import java.io.PrintStream; >>>>>>>>>>> import java.util.Locale; >>>>>>>>>>> import sun.security.tools.JarSigner; >>>>>>>>>>> >>>>>>>>>>> public class bug7163483 { >>>>>>>>>>> >>>>>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>>>>> >>>>>>>>>>> ByteArrayOutputStream stream = new >>>>>>>>>>> ByteArrayOutputStream(1024*64); >>>>>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>>>>> System.setOut(out); >>>>>>>>>>> >>>>>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>>>>> JarSigner js = new JarSigner(); >>>>>>>>>>> js.run(arg); >>>>>>>>>>> >>>>>>>>>>> out.flush(); >>>>>>>>>>> String s1 = stream.toString(); >>>>>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>>>>> stream.reset(); >>>>>>>>>>> >>>>>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>>>>> js = new JarSigner(); >>>>>>>>>>> js.run(arg); >>>>>>>>>>> >>>>>>>>>>> out.flush(); >>>>>>>>>>> String s2 = stream.toString(); >>>>>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>>>>> >>>>>>>>>>> if (s1.equals(s2)) { >>>>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>>>> throw new RuntimeException( >>>>>>>>>>> "JarSigner verbose outputs are the same after setting >>>>>>>>>>> locale!!"); >>>>>>>>>>> } else { >>>>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>>>> System.err.println("Test passed!"); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Thanks and best regards! >>>>>>>>>>> - Jonathan Lu >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards! >>>>>>>>> - Jonathan >>>>>>>>> >>>>>>>> >>>>>>> Thanks & regards! >>>>>>> - Jonathan >>>>>>> >>>>>> >>>>> >>>>> Thanks >>>>> - Jonathan >>>>> >>>> >>> >>> >> > > From rgolan at redhat.com Tue Jul 10 03:08:45 2012 From: rgolan at redhat.com (Roy Golan) Date: Tue, 10 Jul 2012 13:08:45 +0300 Subject: no PTR is needed for TGS-Req in openjdk7? Message-ID: <4FFBFF2D.3000405@redhat.com> I all, In our project (www.ovirt.org) we do some kerberos authentication and we've seen different behavior between jdk6 and 7 in the process of doing the TGS-Req to the KDC. with jdk6, wh must have a PTR record for our KDC to run while using jdk7 we see its ignoring it. To check it we have put a wrong record in /etc/hosts for our KDC server, say "1.1.1.1 wrongkdc.example.com" while it should be kdc.example.com and we saw that jdk6 is failing with PRINCIPAL_UKNOWN . the PRINCIPAL in jdk6 is 1.1.1.1/wrongkdc.example.com and with jdk7 is 1.1.1.1/kdc.example.com which is why it works. is this a change is by design or maybe a bug? can someone explain if there is no intent of using reverse records (PTR) for the PRINCIPAL in TGS requests? I can supply tcp dumps if that will help to shed light here. Thanks, Roy From weijun.wang at oracle.com Tue Jul 10 06:30:57 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 10 Jul 2012 21:30:57 +0800 Subject: no PTR is needed for TGS-Req in openjdk7? In-Reply-To: <4FFBFF2D.3000405@redhat.com> References: <4FFBFF2D.3000405@redhat.com> Message-ID: <4FFC2E91.9050200@oracle.com> Hi Roy In JDK 6 we canonicalize the service host name before requesting for a service ticket. In JDK 7 we don't, for security reasons, see http://tools.ietf.org/html/rfc4120#section-1.3. But I don't see how it affects locating the KDC. Another change is that we always use DNS to locate a KDC if there is none in krb5.conf, i.e. dns_lookup_kdc's default value is now regarded true. Can you be more specific? tcp dumps are always welcomed. -Max On 07/10/2012 06:08 PM, Roy Golan wrote: > I all, > > In our project (www.ovirt.org) we do some kerberos authentication and > we've seen different behavior between jdk6 and 7 in the process > of doing the TGS-Req to the KDC. with jdk6, wh must have a PTR record > for our KDC to run while using jdk7 we see its ignoring it. > To check it we have put a wrong record in /etc/hosts for our KDC server, > say "1.1.1.1 wrongkdc.example.com" while it should be kdc.example.com and > we saw that jdk6 is failing with PRINCIPAL_UKNOWN . the PRINCIPAL in > jdk6 is 1.1.1.1/wrongkdc.example.com and with > jdk7 is 1.1.1.1/kdc.example.com which is why it works. > > is this a change is by design or maybe a bug? can someone explain if > there is no intent > of using reverse records (PTR) for the PRINCIPAL in TGS requests? > > I can supply tcp dumps if that will help to shed light here. > > Thanks, > Roy > From vincent.x.ryan at oracle.com Tue Jul 10 13:34:20 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 10 Jul 2012 21:34:20 +0100 Subject: 7182500 OCSP revocation checking fails if OCSP response does not contain certificates Message-ID: <4FFC91CC.9090203@oracle.com> Hello, Please review the following changeset for JDK 7u6: http://cr.openjdk.java.net/~vinnie/7182500/ The bug report is at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182500 The error occurs when an OCSP responder opts not to return the signing certificate used in an OCSP response. The fix is to set the default signer cert to be the cert of the issuer of the cert being validated. This fix addresses a regression in the OCSP client which was introduced in my fix for CR 7168191 (http://hg.openjdk.java.net/jdk7u/jdk7u6-dev/jdk/rev/52ab0f489dab). Thanks. From xuelei.fan at oracle.com Tue Jul 10 18:40:39 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 11 Jul 2012 09:40:39 +0800 Subject: 7182500 OCSP revocation checking fails if OCSP response does not contain certificates In-Reply-To: <4FFC91CC.9090203@oracle.com> References: <4FFC91CC.9090203@oracle.com> Message-ID: <4FFCD997.1090405@oracle.com> Looks fine to me. Xuelei On 7/11/2012 4:34 AM, Vincent Ryan wrote: > Hello, > > Please review the following changeset for JDK 7u6: > http://cr.openjdk.java.net/~vinnie/7182500/ > > The bug report is at: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182500 > > The error occurs when an OCSP responder opts not to return the signing > certificate used in an OCSP response. The fix is to set the default > signer cert to be the cert of the issuer of the cert being validated. > > This fix addresses a regression in the OCSP client which was introduced > in my fix for CR 7168191 > (http://hg.openjdk.java.net/jdk7u/jdk7u6-dev/jdk/rev/52ab0f489dab). > > Thanks. From luchsh at linux.vnet.ibm.com Tue Jul 10 23:07:25 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 11 Jul 2012 14:07:25 +0800 Subject: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale) In-Reply-To: <4FFB7D44.8010201@oracle.com> References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com> <4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com> <4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com> <4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com> <4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com> <4FFA8726.60306@linux.vnet.ibm.com> <4FFB7D44.8010201@oracle.com> Message-ID: <4FFD181D.3030709@linux.vnet.ibm.com> Hello Max, Thanks a lot for review, here's the updated patch, http://cr.openjdk.java.net/~luchsh/7163483_5/ On 07/10/2012 08:54 AM, Weijun Wang wrote: > Hi Jonathon > > This is better. Two minor comments, you can decide what to do or we > can see what core-lib-devs think: I was proposing my solution for this issue and I'd like to hear more from core-lib-devs list. :) > > 1. Current output uses "zzz" for timezones, you're using "ZZZ". It > might be more of an ISO flavor. Changed to "zzz" format which seems to be more readable for me. > > 2. The DateFormat.format(Date,StringBuffer,FilePosition) is quite > advanced. If it's me, I'll use the simpler format(Data) method. Updated in the new patch. > > Since the jar command also uses the same output format, can you also > make the same change there (that's sun.tools.jar.Main) and ask > core-libs-dev at openjdk.java.net for a review? Sherman > (xueming.shen at oracle.com) owns the jar tool. I've included sun.tools.jar.Main in the latest patch and CCed Sherman. Could you please help to take another look? Many thanks Jonathan > > Thanks > Max > > > On 07/09/2012 03:24 PM, Jonathan Lu wrote: >> Hi Max, >> >> Thanks for reviewing. >> >> On 07/06/2012 06:27 PM, Weijun Wang wrote: >>> Hi Jonathan >>> >>> I have these questions: >>> >>> 1. Why always CAPITAL letters for month and weekday? >> >> This is a fault of the patch, which can be easily fixed by updating the >> format string. >> >>> >>> 2. Why always "dd HH:mm:ss zzz yyyy" for the rest? Some locales uses >>> "." instead of ":" as times delimiters. >>> 3. Why always dd after MMM? Some locales prefer dd before MMM. >> >> For question #2 and #3, I was just trying to follow the original format >> of Date.toString(). >> >>> >>> Well, if you really think the current "Fri Jul" output is too English, >>> instead of localizing the string, how about we de-localize it totally >>> and choose a neutral format? >>> >>> There are several flavors of ISO date/time format at >>> >>> http://www.w3.org/TR/NOTE-datetime >>> >>> or we can just choose >>> >>> YYYY-MM-dd HH:mm:ss zzz >> >> Good idea, how about a patch in this way? >> http://cr.openjdk.java.net/~luchsh/7163483_4/ >> >> And I prefer to your format since it looks more readable to me. >> >> Thanks and best regards! >> Jonathan >> >>> >>> BTW, the jar command is using the same format, therefore I'm adding >>> core-libs-dev. >>> >>> Thanks >>> Max >>> >>> >>> On 07/06/2012 05:16 PM, Jonathan Lu wrote: >>>> Hello Max, >>>> >>>> I's been a long time since my last mail, I did some investigation and >>>> had some discussion with i18n developers, but still did not see a >>>> nice >>>> solution for the alignment problem. There does not seem be an existing >>>> API to do this job in JDK scope. So I implemented a simple format >>>> function, and use it to format under different locales. >>>> >>>> http://cr.openjdk.java.net/~luchsh/7163483_3/ >>>> >>>> The patch is trying to format the code in the same way as >>>> java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz >>>> yyyy", except for using names of month and DOW in localized format. So >>>> far, it works good for me under all supported locales. >>>> >>>> Here's a test case to verify the vertical alignment, which I has been >>>> posted to i18n mailing list before, >>>> http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java >>>> >>>> It may still fail under "vi_VN" locale with this solution due to test >>>> case limit, but I do not think it is a real failure since the result >>>> fields still get aligned except for multiple words in one field. >>>> >>>> Could you please take a look at the patch? >>>> >>>> Many thanks & best regards >>>> Jonathan >>>> >>>> On 04/25/2012 07:48 PM, Weijun Wang wrote: >>>>> Hi Jonathan >>>>> >>>>> I'm using English. >>>>> >>>>> In your test all the files have a similar modified time so you cannot >>>>> see the difference. However, in my example, you can see that the >>>>> widths for date and hour are not zero-padded so the width can be >>>>> either 1 or 2. >>>>> >>>>> French is even worse >>>>> >>>>> smk 76 10 nov. 2009 08:57:54 bin/vbin/go >>>>> smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans >>>>> smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown >>>>> smk 671 8 f?vr. 2012 20:11:22 bin/vbin/ssh.desktop >>>>> smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf >>>>> >>>>> So here even the width of month abbr can be different. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 04/25/2012 07:09 PM, Jonathan Lu wrote: >>>>>> Hello Max, >>>>>> >>>>>> Terribly sorry for my misunderstanding! >>>>>> >>>>>> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>>>>>> Hi Weijun, >>>>>>>>>> >>>>>>>>>> Thanks for your time, I've updated the webrev, could you please >>>>>>>>>> take a >>>>>>>>>> look? >>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>>>>>> >>>>>>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>>>>>> Hi Jonathan >>>>>>>>>>> >>>>>>>>>>> Some comments: >>>>>>>>>>> >>>>>>>>>>> 1. Can you be sure that the new format always has the same >>>>>>>>>>> length? >>>>>>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>>>>>> should be >>>>>>>>>>> aligned. >>>>>>>>>> >>>>>>>>>> I'm not sure of that, so the test case was updated to compare >>>>>>>>>> the >>>>>>>>>> first >>>>>>>>>> several tokens to determine whether there's any differences >>>>>>>>>> in the >>>>>>>>>> expression of date time. >>>>>>>>> >>>>>>>>> Sorry, I didn't make myself clear last time, I was mainly >>>>>>>>> afraid of >>>>>>>>> unaligned lines that make the output ugly. >>>>>>>>> >>>>>>>>> For example: >>>>>>>>> >>>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>>> >>>>>>>> >>>>>>>> I think that would not be a problem in the new test case which >>>>>>>> compares >>>>>>>> tokenized strings splited by blank spaces instead of >>>>>>>> String#equals. >>>>>>>> Does >>>>>>>> that make sense? >>>>>>> >>>>>>> I'm not talking about the test. It's the output of jarsigner >>>>>>> looking >>>>>>> ugly. >>>>>>> >>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>> >>>>>>> Compare with the current output: >>>>>>> >>>>>>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>>>>>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>>>>>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>>>>>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>>>>>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >>>>>> >>>>>> I did not see unaligned format in my testing, did you get these >>>>>> unaligned output after applying the patch? From above lines, I >>>>>> see the >>>>>> starting indices of date string in each line are always the same, >>>>>> which >>>>>> is achieved by jarsigner, but the length of the date strings are >>>>>> not the >>>>>> same, which locale were you testing on? >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2. You might need to reformat the modified line to make it fit >>>>>>>>>>> into 80 >>>>>>>>>>> characters width. >>>>>>>>>>> >>>>>>>>>>> 3. Why not include the test inside the changeset? >>>>>>>>>> 2, 3 were done in the new patch >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>>>>>> Hello security-dev, >>>>>>>>>>>> >>>>>>>>>>>> Here's a patch for bug 7163483, could anybody please help to >>>>>>>>>>>> take a >>>>>>>>>>>> look? >>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>>>>>> >>>>>>>>>>>> The problem is that command "jarsigner -verify -verbose >>>>>>>>>>>> my.jar" >>>>>>>>>>>> does not >>>>>>>>>>>> format date string according to current locale. following >>>>>>>>>>>> simple >>>>>>>>>>>> test >>>>>>>>>>>> case can be used to disclose this problem. >>>>>>>>>>>> >>>>>>>>>>>> /* >>>>>>>>>>>> * Copyright (c) 2012 Oracle and/or its affiliates. All rights >>>>>>>>>>>> reserved. >>>>>>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE >>>>>>>>>>>> HEADER. >>>>>>>>>>>> * >>>>>>>>>>>> * This code is free software; you can redistribute it and/or >>>>>>>>>>>> modify it >>>>>>>>>>>> * under the terms of the GNU General Public License version 2 >>>>>>>>>>>> only, as >>>>>>>>>>>> * published by the Free Software Foundation. >>>>>>>>>>>> * >>>>>>>>>>>> * This code is distributed in the hope that it will be >>>>>>>>>>>> useful, but >>>>>>>>>>>> WITHOUT >>>>>>>>>>>> * ANY WARRANTY; without even the implied warranty of >>>>>>>>>>>> MERCHANTABILITY or >>>>>>>>>>>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>>>>>>>>> License >>>>>>>>>>>> * version 2 for more details (a copy is included in the >>>>>>>>>>>> LICENSE >>>>>>>>>>>> file >>>>>>>>>>>> that >>>>>>>>>>>> * accompanied this code). >>>>>>>>>>>> * >>>>>>>>>>>> * You should have received a copy of the GNU General Public >>>>>>>>>>>> License >>>>>>>>>>>> version >>>>>>>>>>>> * 2 along with this work; if not, write to the Free Software >>>>>>>>>>>> Foundation, >>>>>>>>>>>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 >>>>>>>>>>>> USA. >>>>>>>>>>>> * >>>>>>>>>>>> * Please contact Oracle, 500 Oracle Parkway, Redwood >>>>>>>>>>>> Shores, CA >>>>>>>>>>>> 94065 >>>>>>>>>>>> USA >>>>>>>>>>>> * or visit www.oracle.com if you need additional >>>>>>>>>>>> information or >>>>>>>>>>>> have any >>>>>>>>>>>> * questions. >>>>>>>>>>>> */ >>>>>>>>>>>> >>>>>>>>>>>> /* >>>>>>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>>>>>> */ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>>>>>> import java.io.PrintStream; >>>>>>>>>>>> import java.util.Locale; >>>>>>>>>>>> import sun.security.tools.JarSigner; >>>>>>>>>>>> >>>>>>>>>>>> public class bug7163483 { >>>>>>>>>>>> >>>>>>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>>>>>> >>>>>>>>>>>> ByteArrayOutputStream stream = new >>>>>>>>>>>> ByteArrayOutputStream(1024*64); >>>>>>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>>>>>> System.setOut(out); >>>>>>>>>>>> >>>>>>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>>>>>> JarSigner js = new JarSigner(); >>>>>>>>>>>> js.run(arg); >>>>>>>>>>>> >>>>>>>>>>>> out.flush(); >>>>>>>>>>>> String s1 = stream.toString(); >>>>>>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>>>>>> stream.reset(); >>>>>>>>>>>> >>>>>>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>>>>>> js = new JarSigner(); >>>>>>>>>>>> js.run(arg); >>>>>>>>>>>> >>>>>>>>>>>> out.flush(); >>>>>>>>>>>> String s2 = stream.toString(); >>>>>>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>>>>>> >>>>>>>>>>>> if (s1.equals(s2)) { >>>>>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>>>>> throw new RuntimeException( >>>>>>>>>>>> "JarSigner verbose outputs are the same after setting >>>>>>>>>>>> locale!!"); >>>>>>>>>>>> } else { >>>>>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>>>>> System.err.println("Test passed!"); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Thanks and best regards! >>>>>>>>>>>> - Jonathan Lu >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best regards! >>>>>>>>>> - Jonathan >>>>>>>>>> >>>>>>>>> >>>>>>>> Thanks & regards! >>>>>>>> - Jonathan >>>>>>>> >>>>>>> >>>>>> >>>>>> Thanks >>>>>> - Jonathan >>>>>> >>>>> >>>> >>>> >>> >> >> > From weijun.wang at oracle.com Tue Jul 10 23:21:18 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 11 Jul 2012 14:21:18 +0800 Subject: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale) In-Reply-To: <4FFD181D.3030709@linux.vnet.ibm.com> References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com> <4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com> <4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com> <4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com> <4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com> <4FFA8726.60306@linux.vnet.ibm.com> <4FFB7D44.8010201@oracle.com> <4FFD181D.3030709@linux.vnet.ibm.com> Message-ID: <4FFD1B5E.2090208@oracle.com> Mostly fine. 1. "import java.text.FieldPosition;" is not needed anymore. 2. In jar/Main, you can also consider creating a separate SimpleDateFormat object (maybe private final static?). It seems the initialization is quite heavy. You recently became a jdk8 committer, right? That means you can do your own push but if you want to make any changes to the bug database, just tell me. Thanks Max On 07/11/2012 02:07 PM, Jonathan Lu wrote: > Hello Max, > > Thanks a lot for review, here's the updated patch, > > http://cr.openjdk.java.net/~luchsh/7163483_5/ > > On 07/10/2012 08:54 AM, Weijun Wang wrote: >> Hi Jonathon >> >> This is better. Two minor comments, you can decide what to do or we >> can see what core-lib-devs think: > > I was proposing my solution for this issue and I'd like to hear more > from core-lib-devs list. :) > >> >> 1. Current output uses "zzz" for timezones, you're using "ZZZ". It >> might be more of an ISO flavor. > > Changed to "zzz" format which seems to be more readable for me. > >> >> 2. The DateFormat.format(Date,StringBuffer,FilePosition) is quite >> advanced. If it's me, I'll use the simpler format(Data) method. > > Updated in the new patch. > >> >> Since the jar command also uses the same output format, can you also >> make the same change there (that's sun.tools.jar.Main) and ask >> core-libs-dev at openjdk.java.net for a review? Sherman >> (xueming.shen at oracle.com) owns the jar tool. > I've included sun.tools.jar.Main in the latest patch and CCed Sherman. > > Could you please help to take another look? > > Many thanks > > Jonathan > >> >> Thanks >> Max >> >> >> On 07/09/2012 03:24 PM, Jonathan Lu wrote: >>> Hi Max, >>> >>> Thanks for reviewing. >>> >>> On 07/06/2012 06:27 PM, Weijun Wang wrote: >>>> Hi Jonathan >>>> >>>> I have these questions: >>>> >>>> 1. Why always CAPITAL letters for month and weekday? >>> >>> This is a fault of the patch, which can be easily fixed by updating the >>> format string. >>> >>>> >>>> 2. Why always "dd HH:mm:ss zzz yyyy" for the rest? Some locales uses >>>> "." instead of ":" as times delimiters. >>>> 3. Why always dd after MMM? Some locales prefer dd before MMM. >>> >>> For question #2 and #3, I was just trying to follow the original format >>> of Date.toString(). >>> >>>> >>>> Well, if you really think the current "Fri Jul" output is too English, >>>> instead of localizing the string, how about we de-localize it totally >>>> and choose a neutral format? >>>> >>>> There are several flavors of ISO date/time format at >>>> >>>> http://www.w3.org/TR/NOTE-datetime >>>> >>>> or we can just choose >>>> >>>> YYYY-MM-dd HH:mm:ss zzz >>> >>> Good idea, how about a patch in this way? >>> http://cr.openjdk.java.net/~luchsh/7163483_4/ >>> >>> And I prefer to your format since it looks more readable to me. >>> >>> Thanks and best regards! >>> Jonathan >>> >>>> >>>> BTW, the jar command is using the same format, therefore I'm adding >>>> core-libs-dev. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 07/06/2012 05:16 PM, Jonathan Lu wrote: >>>>> Hello Max, >>>>> >>>>> I's been a long time since my last mail, I did some investigation and >>>>> had some discussion with i18n developers, but still did not see a >>>>> nice >>>>> solution for the alignment problem. There does not seem be an existing >>>>> API to do this job in JDK scope. So I implemented a simple format >>>>> function, and use it to format under different locales. >>>>> >>>>> http://cr.openjdk.java.net/~luchsh/7163483_3/ >>>>> >>>>> The patch is trying to format the code in the same way as >>>>> java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz >>>>> yyyy", except for using names of month and DOW in localized format. So >>>>> far, it works good for me under all supported locales. >>>>> >>>>> Here's a test case to verify the vertical alignment, which I has been >>>>> posted to i18n mailing list before, >>>>> http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java >>>>> >>>>> It may still fail under "vi_VN" locale with this solution due to test >>>>> case limit, but I do not think it is a real failure since the result >>>>> fields still get aligned except for multiple words in one field. >>>>> >>>>> Could you please take a look at the patch? >>>>> >>>>> Many thanks & best regards >>>>> Jonathan >>>>> >>>>> On 04/25/2012 07:48 PM, Weijun Wang wrote: >>>>>> Hi Jonathan >>>>>> >>>>>> I'm using English. >>>>>> >>>>>> In your test all the files have a similar modified time so you cannot >>>>>> see the difference. However, in my example, you can see that the >>>>>> widths for date and hour are not zero-padded so the width can be >>>>>> either 1 or 2. >>>>>> >>>>>> French is even worse >>>>>> >>>>>> smk 76 10 nov. 2009 08:57:54 bin/vbin/go >>>>>> smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans >>>>>> smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown >>>>>> smk 671 8 f?vr. 2012 20:11:22 bin/vbin/ssh.desktop >>>>>> smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf >>>>>> >>>>>> So here even the width of month abbr can be different. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> On 04/25/2012 07:09 PM, Jonathan Lu wrote: >>>>>>> Hello Max, >>>>>>> >>>>>>> Terribly sorry for my misunderstanding! >>>>>>> >>>>>>> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>>>>>>> Hi Weijun, >>>>>>>>>>> >>>>>>>>>>> Thanks for your time, I've updated the webrev, could you please >>>>>>>>>>> take a >>>>>>>>>>> look? >>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>>>>>>> >>>>>>>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>>>>>>> Hi Jonathan >>>>>>>>>>>> >>>>>>>>>>>> Some comments: >>>>>>>>>>>> >>>>>>>>>>>> 1. Can you be sure that the new format always has the same >>>>>>>>>>>> length? >>>>>>>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>>>>>>> should be >>>>>>>>>>>> aligned. >>>>>>>>>>> >>>>>>>>>>> I'm not sure of that, so the test case was updated to compare >>>>>>>>>>> the >>>>>>>>>>> first >>>>>>>>>>> several tokens to determine whether there's any differences >>>>>>>>>>> in the >>>>>>>>>>> expression of date time. >>>>>>>>>> >>>>>>>>>> Sorry, I didn't make myself clear last time, I was mainly >>>>>>>>>> afraid of >>>>>>>>>> unaligned lines that make the output ugly. >>>>>>>>>> >>>>>>>>>> For example: >>>>>>>>>> >>>>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think that would not be a problem in the new test case which >>>>>>>>> compares >>>>>>>>> tokenized strings splited by blank spaces instead of >>>>>>>>> String#equals. >>>>>>>>> Does >>>>>>>>> that make sense? >>>>>>>> >>>>>>>> I'm not talking about the test. It's the output of jarsigner >>>>>>>> looking >>>>>>>> ugly. >>>>>>>> >>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>> >>>>>>>> Compare with the current output: >>>>>>>> >>>>>>>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>>>>>>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>>>>>>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>>>>>>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>>>>>>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >>>>>>> >>>>>>> I did not see unaligned format in my testing, did you get these >>>>>>> unaligned output after applying the patch? From above lines, I >>>>>>> see the >>>>>>> starting indices of date string in each line are always the same, >>>>>>> which >>>>>>> is achieved by jarsigner, but the length of the date strings are >>>>>>> not the >>>>>>> same, which locale were you testing on? >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2. You might need to reformat the modified line to make it fit >>>>>>>>>>>> into 80 >>>>>>>>>>>> characters width. >>>>>>>>>>>> >>>>>>>>>>>> 3. Why not include the test inside the changeset? >>>>>>>>>>> 2, 3 were done in the new patch >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>>>>>>> Hello security-dev, >>>>>>>>>>>>> >>>>>>>>>>>>> Here's a patch for bug 7163483, could anybody please help to >>>>>>>>>>>>> take a >>>>>>>>>>>>> look? >>>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>>>>>>> >>>>>>>>>>>>> The problem is that command "jarsigner -verify -verbose >>>>>>>>>>>>> my.jar" >>>>>>>>>>>>> does not >>>>>>>>>>>>> format date string according to current locale. following >>>>>>>>>>>>> simple >>>>>>>>>>>>> test >>>>>>>>>>>>> case can be used to disclose this problem. >>>>>>>>>>>>> >>>>>>>>>>>>> /* >>>>>>>>>>>>> * Copyright (c) 2012 Oracle and/or its affiliates. All rights >>>>>>>>>>>>> reserved. >>>>>>>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE >>>>>>>>>>>>> HEADER. >>>>>>>>>>>>> * >>>>>>>>>>>>> * This code is free software; you can redistribute it and/or >>>>>>>>>>>>> modify it >>>>>>>>>>>>> * under the terms of the GNU General Public License version 2 >>>>>>>>>>>>> only, as >>>>>>>>>>>>> * published by the Free Software Foundation. >>>>>>>>>>>>> * >>>>>>>>>>>>> * This code is distributed in the hope that it will be >>>>>>>>>>>>> useful, but >>>>>>>>>>>>> WITHOUT >>>>>>>>>>>>> * ANY WARRANTY; without even the implied warranty of >>>>>>>>>>>>> MERCHANTABILITY or >>>>>>>>>>>>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >>>>>>>>>>>>> License >>>>>>>>>>>>> * version 2 for more details (a copy is included in the >>>>>>>>>>>>> LICENSE >>>>>>>>>>>>> file >>>>>>>>>>>>> that >>>>>>>>>>>>> * accompanied this code). >>>>>>>>>>>>> * >>>>>>>>>>>>> * You should have received a copy of the GNU General Public >>>>>>>>>>>>> License >>>>>>>>>>>>> version >>>>>>>>>>>>> * 2 along with this work; if not, write to the Free Software >>>>>>>>>>>>> Foundation, >>>>>>>>>>>>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 >>>>>>>>>>>>> USA. >>>>>>>>>>>>> * >>>>>>>>>>>>> * Please contact Oracle, 500 Oracle Parkway, Redwood >>>>>>>>>>>>> Shores, CA >>>>>>>>>>>>> 94065 >>>>>>>>>>>>> USA >>>>>>>>>>>>> * or visit www.oracle.com if you need additional >>>>>>>>>>>>> information or >>>>>>>>>>>>> have any >>>>>>>>>>>>> * questions. >>>>>>>>>>>>> */ >>>>>>>>>>>>> >>>>>>>>>>>>> /* >>>>>>>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>>>>>>> */ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>>>>>>> import java.io.PrintStream; >>>>>>>>>>>>> import java.util.Locale; >>>>>>>>>>>>> import sun.security.tools.JarSigner; >>>>>>>>>>>>> >>>>>>>>>>>>> public class bug7163483 { >>>>>>>>>>>>> >>>>>>>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>>>>>>> >>>>>>>>>>>>> ByteArrayOutputStream stream = new >>>>>>>>>>>>> ByteArrayOutputStream(1024*64); >>>>>>>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>>>>>>> System.setOut(out); >>>>>>>>>>>>> >>>>>>>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>>>>>>> JarSigner js = new JarSigner(); >>>>>>>>>>>>> js.run(arg); >>>>>>>>>>>>> >>>>>>>>>>>>> out.flush(); >>>>>>>>>>>>> String s1 = stream.toString(); >>>>>>>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>>>>>>> stream.reset(); >>>>>>>>>>>>> >>>>>>>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>>>>>>> js = new JarSigner(); >>>>>>>>>>>>> js.run(arg); >>>>>>>>>>>>> >>>>>>>>>>>>> out.flush(); >>>>>>>>>>>>> String s2 = stream.toString(); >>>>>>>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>>>>>>> >>>>>>>>>>>>> if (s1.equals(s2)) { >>>>>>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>>>>>> throw new RuntimeException( >>>>>>>>>>>>> "JarSigner verbose outputs are the same after setting >>>>>>>>>>>>> locale!!"); >>>>>>>>>>>>> } else { >>>>>>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>>>>>> System.err.println("Test passed!"); >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks and best regards! >>>>>>>>>>>>> - Jonathan Lu >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards! >>>>>>>>>>> - Jonathan >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> Thanks & regards! >>>>>>>>> - Jonathan >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> - Jonathan >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From rgolan at redhat.com Tue Jul 10 23:31:14 2012 From: rgolan at redhat.com (Roy Golan) Date: Wed, 11 Jul 2012 09:31:14 +0300 Subject: no PTR is needed for TGS-Req in openjdk7? In-Reply-To: <4FFC2E91.9050200@oracle.com> References: <4FFBFF2D.3000405@redhat.com> <4FFC2E91.9050200@oracle.com> Message-ID: <4FFD1DB2.9080503@redhat.com> On 07/10/2012 04:30 PM, Weijun Wang wrote: > Hi Roy > > In JDK 6 we canonicalize the service host name before requesting for a > service ticket. In JDK 7 we don't, for security reasons, see > http://tools.ietf.org/html/rfc4120#section-1.3. But I don't see how it > affects locating the KDC. > > Another change is that we always use DNS to locate a KDC if there is > none in krb5.conf, i.e. dns_lookup_kdc's default value is now regarded > true. > > Can you be more specific? tcp dumps are always welcomed. > Attached 2 dumps for each jdk. My krb5.conf has dns_lookup_kdc = true and my KDC is also specified in the domain section. We have an active directory server which is also the DNS server. The SRV records are all fine and point to the right KDC and LDAP. Resolving the KDC address is not a problem but we must have back resolving too (as for jdk6...). To do that I have put a record in my /etc/hosts 10.35.64.1 xxqa1.qa.lab###. I'm intentionally putting a wrong record off course, just to proof the behavior. look at the dumps and you will see that jdk6 used the record in /etc/hosts in the KDC_REQ_BODY so the request is for server ldap/xxqa1.qa.lab### and jdk7 just uses the correct ldap/qa1.qa.lab#### > -Max > > On 07/10/2012 06:08 PM, Roy Golan wrote: >> I all, >> >> In our project (www.ovirt.org) we do some kerberos authentication and >> we've seen different behavior between jdk6 and 7 in the process >> of doing the TGS-Req to the KDC. with jdk6, wh must have a PTR record >> for our KDC to run while using jdk7 we see its ignoring it. >> To check it we have put a wrong record in /etc/hosts for our KDC server, >> say "1.1.1.1 wrongkdc.example.com" while it should be kdc.example.com >> and >> we saw that jdk6 is failing with PRINCIPAL_UKNOWN . the PRINCIPAL in >> jdk6 is 1.1.1.1/wrongkdc.example.com and with >> jdk7 is 1.1.1.1/kdc.example.com which is why it works. >> >> is this a change is by design or maybe a bug? can someone explain if >> there is no intent >> of using reverse records (PTR) for the PRINCIPAL in TGS requests? >> >> I can supply tcp dumps if that will help to shed light here. >> >> Thanks, >> Roy >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk7.kerberos.cap Type: application/vnd.tcpdump.pcap Size: 7041 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20120711/50fd5c93/jdk7.kerberos.cap -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk6.kerberos.cap Type: application/vnd.tcpdump.pcap Size: 5807 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/security-dev/attachments/20120711/50fd5c93/jdk6.kerberos.cap From xueming.shen at oracle.com Wed Jul 11 00:13:01 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 11 Jul 2012 00:13:01 -0700 Subject: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale) In-Reply-To: <4FFD1B5E.2090208@oracle.com> References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com> <4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com> <4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com> <4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com> <4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com> <4FFA8726.60306@linux.vnet.ibm.com> <4FFB7D44.8010201@oracle.com> <4FFD181D.3030709@linux.vnet.ibm.com> <4FFD1B5E.2090208@oracle.com> Message-ID: <4FFD277D.9050000@oracle.com> As Max point out, you definitely need to avoid creating SDF everytime you have to print out one entry. But I'm more worried about the fact you are changing the out put of jar t. Jar is a widely used tool, It might be a surprise to someone who has code depend on the current output format. Personally I would suggest not make this change in jar tool. -Sherman On 7/10/2012 11:21 PM, Weijun Wang wrote: > Mostly fine. > > 1. "import java.text.FieldPosition;" is not needed anymore. > > 2. In jar/Main, you can also consider creating a separate > SimpleDateFormat object (maybe private final static?). It seems the > initialization is quite heavy. > > You recently became a jdk8 committer, right? That means you can do > your own push but if you want to make any changes to the bug database, > just tell me. > > Thanks > Max > > On 07/11/2012 02:07 PM, Jonathan Lu wrote: >> Hello Max, >> >> Thanks a lot for review, here's the updated patch, >> >> http://cr.openjdk.java.net/~luchsh/7163483_5/ >> >> On 07/10/2012 08:54 AM, Weijun Wang wrote: >>> Hi Jonathon >>> >>> This is better. Two minor comments, you can decide what to do or we >>> can see what core-lib-devs think: >> >> I was proposing my solution for this issue and I'd like to hear more >> from core-lib-devs list. :) >> >>> >>> 1. Current output uses "zzz" for timezones, you're using "ZZZ". It >>> might be more of an ISO flavor. >> >> Changed to "zzz" format which seems to be more readable for me. >> >>> >>> 2. The DateFormat.format(Date,StringBuffer,FilePosition) is quite >>> advanced. If it's me, I'll use the simpler format(Data) method. >> >> Updated in the new patch. >> >>> >>> Since the jar command also uses the same output format, can you also >>> make the same change there (that's sun.tools.jar.Main) and ask >>> core-libs-dev at openjdk.java.net for a review? Sherman >>> (xueming.shen at oracle.com) owns the jar tool. >> I've included sun.tools.jar.Main in the latest patch and CCed Sherman. >> >> Could you please help to take another look? >> >> Many thanks >> >> Jonathan >> >>> >>> Thanks >>> Max >>> >>> >>> On 07/09/2012 03:24 PM, Jonathan Lu wrote: >>>> Hi Max, >>>> >>>> Thanks for reviewing. >>>> >>>> On 07/06/2012 06:27 PM, Weijun Wang wrote: >>>>> Hi Jonathan >>>>> >>>>> I have these questions: >>>>> >>>>> 1. Why always CAPITAL letters for month and weekday? >>>> >>>> This is a fault of the patch, which can be easily fixed by updating >>>> the >>>> format string. >>>> >>>>> >>>>> 2. Why always "dd HH:mm:ss zzz yyyy" for the rest? Some locales uses >>>>> "." instead of ":" as times delimiters. >>>>> 3. Why always dd after MMM? Some locales prefer dd before MMM. >>>> >>>> For question #2 and #3, I was just trying to follow the original >>>> format >>>> of Date.toString(). >>>> >>>>> >>>>> Well, if you really think the current "Fri Jul" output is too >>>>> English, >>>>> instead of localizing the string, how about we de-localize it totally >>>>> and choose a neutral format? >>>>> >>>>> There are several flavors of ISO date/time format at >>>>> >>>>> http://www.w3.org/TR/NOTE-datetime >>>>> >>>>> or we can just choose >>>>> >>>>> YYYY-MM-dd HH:mm:ss zzz >>>> >>>> Good idea, how about a patch in this way? >>>> http://cr.openjdk.java.net/~luchsh/7163483_4/ >>>> >>>> And I prefer to your format since it looks more readable to me. >>>> >>>> Thanks and best regards! >>>> Jonathan >>>> >>>>> >>>>> BTW, the jar command is using the same format, therefore I'm adding >>>>> core-libs-dev. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 07/06/2012 05:16 PM, Jonathan Lu wrote: >>>>>> Hello Max, >>>>>> >>>>>> I's been a long time since my last mail, I did some investigation >>>>>> and >>>>>> had some discussion with i18n developers, but still did not see a >>>>>> nice >>>>>> solution for the alignment problem. There does not seem be an >>>>>> existing >>>>>> API to do this job in JDK scope. So I implemented a simple format >>>>>> function, and use it to format under different locales. >>>>>> >>>>>> http://cr.openjdk.java.net/~luchsh/7163483_3/ >>>>>> >>>>>> The patch is trying to format the code in the same way as >>>>>> java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz >>>>>> yyyy", except for using names of month and DOW in localized >>>>>> format. So >>>>>> far, it works good for me under all supported locales. >>>>>> >>>>>> Here's a test case to verify the vertical alignment, which I has >>>>>> been >>>>>> posted to i18n mailing list before, >>>>>> http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java >>>>>> >>>>>> It may still fail under "vi_VN" locale with this solution due to >>>>>> test >>>>>> case limit, but I do not think it is a real failure since the result >>>>>> fields still get aligned except for multiple words in one field. >>>>>> >>>>>> Could you please take a look at the patch? >>>>>> >>>>>> Many thanks & best regards >>>>>> Jonathan >>>>>> >>>>>> On 04/25/2012 07:48 PM, Weijun Wang wrote: >>>>>>> Hi Jonathan >>>>>>> >>>>>>> I'm using English. >>>>>>> >>>>>>> In your test all the files have a similar modified time so you >>>>>>> cannot >>>>>>> see the difference. However, in my example, you can see that the >>>>>>> widths for date and hour are not zero-padded so the width can be >>>>>>> either 1 or 2. >>>>>>> >>>>>>> French is even worse >>>>>>> >>>>>>> smk 76 10 nov. 2009 08:57:54 bin/vbin/go >>>>>>> smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans >>>>>>> smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown >>>>>>> smk 671 8 f?vr. 2012 20:11:22 bin/vbin/ssh.desktop >>>>>>> smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf >>>>>>> >>>>>>> So here even the width of month abbr can be different. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> On 04/25/2012 07:09 PM, Jonathan Lu wrote: >>>>>>>> Hello Max, >>>>>>>> >>>>>>>> Terribly sorry for my misunderstanding! >>>>>>>> >>>>>>>> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>>>>>>>> Hi Weijun, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for your time, I've updated the webrev, could you >>>>>>>>>>>> please >>>>>>>>>>>> take a >>>>>>>>>>>> look? >>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>>>>>>>> >>>>>>>>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>>>>>>>> Hi Jonathan >>>>>>>>>>>>> >>>>>>>>>>>>> Some comments: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Can you be sure that the new format always has the same >>>>>>>>>>>>> length? >>>>>>>>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>>>>>>>> should be >>>>>>>>>>>>> aligned. >>>>>>>>>>>> >>>>>>>>>>>> I'm not sure of that, so the test case was updated to compare >>>>>>>>>>>> the >>>>>>>>>>>> first >>>>>>>>>>>> several tokens to determine whether there's any differences >>>>>>>>>>>> in the >>>>>>>>>>>> expression of date time. >>>>>>>>>>> >>>>>>>>>>> Sorry, I didn't make myself clear last time, I was mainly >>>>>>>>>>> afraid of >>>>>>>>>>> unaligned lines that make the output ugly. >>>>>>>>>>> >>>>>>>>>>> For example: >>>>>>>>>>> >>>>>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think that would not be a problem in the new test case which >>>>>>>>>> compares >>>>>>>>>> tokenized strings splited by blank spaces instead of >>>>>>>>>> String#equals. >>>>>>>>>> Does >>>>>>>>>> that make sense? >>>>>>>>> >>>>>>>>> I'm not talking about the test. It's the output of jarsigner >>>>>>>>> looking >>>>>>>>> ugly. >>>>>>>>> >>>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>>> >>>>>>>>> Compare with the current output: >>>>>>>>> >>>>>>>>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>>>>>>>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>>>>>>>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>>>>>>>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>>>>>>>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >>>>>>>> >>>>>>>> I did not see unaligned format in my testing, did you get these >>>>>>>> unaligned output after applying the patch? From above lines, I >>>>>>>> see the >>>>>>>> starting indices of date string in each line are always the same, >>>>>>>> which >>>>>>>> is achieved by jarsigner, but the length of the date strings are >>>>>>>> not the >>>>>>>> same, which locale were you testing on? >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2. You might need to reformat the modified line to make it >>>>>>>>>>>>> fit >>>>>>>>>>>>> into 80 >>>>>>>>>>>>> characters width. >>>>>>>>>>>>> >>>>>>>>>>>>> 3. Why not include the test inside the changeset? >>>>>>>>>>>> 2, 3 were done in the new patch >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>>>>>>>> Hello security-dev, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here's a patch for bug 7163483, could anybody please help to >>>>>>>>>>>>>> take a >>>>>>>>>>>>>> look? >>>>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> The problem is that command "jarsigner -verify -verbose >>>>>>>>>>>>>> my.jar" >>>>>>>>>>>>>> does not >>>>>>>>>>>>>> format date string according to current locale. following >>>>>>>>>>>>>> simple >>>>>>>>>>>>>> test >>>>>>>>>>>>>> case can be used to disclose this problem. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /* >>>>>>>>>>>>>> * Copyright (c) 2012 Oracle and/or its affiliates. All >>>>>>>>>>>>>> rights >>>>>>>>>>>>>> reserved. >>>>>>>>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE >>>>>>>>>>>>>> HEADER. >>>>>>>>>>>>>> * >>>>>>>>>>>>>> * This code is free software; you can redistribute it and/or >>>>>>>>>>>>>> modify it >>>>>>>>>>>>>> * under the terms of the GNU General Public License >>>>>>>>>>>>>> version 2 >>>>>>>>>>>>>> only, as >>>>>>>>>>>>>> * published by the Free Software Foundation. >>>>>>>>>>>>>> * >>>>>>>>>>>>>> * This code is distributed in the hope that it will be >>>>>>>>>>>>>> useful, but >>>>>>>>>>>>>> WITHOUT >>>>>>>>>>>>>> * ANY WARRANTY; without even the implied warranty of >>>>>>>>>>>>>> MERCHANTABILITY or >>>>>>>>>>>>>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General >>>>>>>>>>>>>> Public >>>>>>>>>>>>>> License >>>>>>>>>>>>>> * version 2 for more details (a copy is included in the >>>>>>>>>>>>>> LICENSE >>>>>>>>>>>>>> file >>>>>>>>>>>>>> that >>>>>>>>>>>>>> * accompanied this code). >>>>>>>>>>>>>> * >>>>>>>>>>>>>> * You should have received a copy of the GNU General Public >>>>>>>>>>>>>> License >>>>>>>>>>>>>> version >>>>>>>>>>>>>> * 2 along with this work; if not, write to the Free Software >>>>>>>>>>>>>> Foundation, >>>>>>>>>>>>>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 >>>>>>>>>>>>>> USA. >>>>>>>>>>>>>> * >>>>>>>>>>>>>> * Please contact Oracle, 500 Oracle Parkway, Redwood >>>>>>>>>>>>>> Shores, CA >>>>>>>>>>>>>> 94065 >>>>>>>>>>>>>> USA >>>>>>>>>>>>>> * or visit www.oracle.com if you need additional >>>>>>>>>>>>>> information or >>>>>>>>>>>>>> have any >>>>>>>>>>>>>> * questions. >>>>>>>>>>>>>> */ >>>>>>>>>>>>>> >>>>>>>>>>>>>> /* >>>>>>>>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>>>>>>>> */ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>>>>>>>> import java.io.PrintStream; >>>>>>>>>>>>>> import java.util.Locale; >>>>>>>>>>>>>> import sun.security.tools.JarSigner; >>>>>>>>>>>>>> >>>>>>>>>>>>>> public class bug7163483 { >>>>>>>>>>>>>> >>>>>>>>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>>>>>>>> >>>>>>>>>>>>>> ByteArrayOutputStream stream = new >>>>>>>>>>>>>> ByteArrayOutputStream(1024*64); >>>>>>>>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>>>>>>>> System.setOut(out); >>>>>>>>>>>>>> >>>>>>>>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>>>>>>>> JarSigner js = new JarSigner(); >>>>>>>>>>>>>> js.run(arg); >>>>>>>>>>>>>> >>>>>>>>>>>>>> out.flush(); >>>>>>>>>>>>>> String s1 = stream.toString(); >>>>>>>>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>>>>>>>> stream.reset(); >>>>>>>>>>>>>> >>>>>>>>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>>>>>>>> js = new JarSigner(); >>>>>>>>>>>>>> js.run(arg); >>>>>>>>>>>>>> >>>>>>>>>>>>>> out.flush(); >>>>>>>>>>>>>> String s2 = stream.toString(); >>>>>>>>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>>>>>>>> >>>>>>>>>>>>>> if (s1.equals(s2)) { >>>>>>>>>>>>>> System.err.println("Header output for GERMAN locale >>>>>>>>>>>>>> is:"+s1); >>>>>>>>>>>>>> System.err.println("Header output for FRANCE locale >>>>>>>>>>>>>> is:"+s2); >>>>>>>>>>>>>> throw new RuntimeException( >>>>>>>>>>>>>> "JarSigner verbose outputs are the same after setting >>>>>>>>>>>>>> locale!!"); >>>>>>>>>>>>>> } else { >>>>>>>>>>>>>> System.err.println("Header output for GERMAN locale >>>>>>>>>>>>>> is:"+s1); >>>>>>>>>>>>>> System.err.println("Header output for FRANCE locale >>>>>>>>>>>>>> is:"+s2); >>>>>>>>>>>>>> System.err.println("Test passed!"); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks and best regards! >>>>>>>>>>>>>> - Jonathan Lu >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards! >>>>>>>>>>>> - Jonathan >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Thanks & regards! >>>>>>>>>> - Jonathan >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> - Jonathan >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From luchsh at linux.vnet.ibm.com Wed Jul 11 00:56:09 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 11 Jul 2012 15:56:09 +0800 Subject: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale) In-Reply-To: <4FFD277D.9050000@oracle.com> References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com> <4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com> <4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com> <4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com> <4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com> <4FFA8726.60306@linux.vnet.ibm.com> <4FFB7D44.8010201@oracle.com> <4FFD181D.3030709@linux.vnet.ibm.com> <4FFD1B5E.2090208@oracle.com> <4FFD277D.9050000@oracle.com> Message-ID: <4FFD3199.7050909@linux.vnet.ibm.com> Hello Sherman, Thanks a lot for review! I've made another patch to no include the changes for jar tool, http://cr.openjdk.java.net/~luchsh/7163483_6/ And to Max, Does it make sense for you to change jarSigner only? best regards! Jonathan On 07/11/2012 03:13 PM, Xueming Shen wrote: > > As Max point out, you definitely need to avoid creating SDF everytime > you have to > print out one entry. But I'm more worried about the fact you are > changing the out > put of jar t. Jar is a widely used tool, It might be a surprise to > someone who has code > depend on the current output format. Personally I would suggest not > make this change > in jar tool. > > -Sherman > > On 7/10/2012 11:21 PM, Weijun Wang wrote: >> Mostly fine. >> >> 1. "import java.text.FieldPosition;" is not needed anymore. >> >> 2. In jar/Main, you can also consider creating a separate >> SimpleDateFormat object (maybe private final static?). It seems the >> initialization is quite heavy. >> >> You recently became a jdk8 committer, right? That means you can do >> your own push but if you want to make any changes to the bug >> database, just tell me. >> >> Thanks >> Max >> >> On 07/11/2012 02:07 PM, Jonathan Lu wrote: >>> Hello Max, >>> >>> Thanks a lot for review, here's the updated patch, >>> >>> http://cr.openjdk.java.net/~luchsh/7163483_5/ >>> >>> On 07/10/2012 08:54 AM, Weijun Wang wrote: >>>> Hi Jonathon >>>> >>>> This is better. Two minor comments, you can decide what to do or we >>>> can see what core-lib-devs think: >>> >>> I was proposing my solution for this issue and I'd like to hear more >>> from core-lib-devs list. :) >>> >>>> >>>> 1. Current output uses "zzz" for timezones, you're using "ZZZ". It >>>> might be more of an ISO flavor. >>> >>> Changed to "zzz" format which seems to be more readable for me. >>> >>>> >>>> 2. The DateFormat.format(Date,StringBuffer,FilePosition) is quite >>>> advanced. If it's me, I'll use the simpler format(Data) method. >>> >>> Updated in the new patch. >>> >>>> >>>> Since the jar command also uses the same output format, can you also >>>> make the same change there (that's sun.tools.jar.Main) and ask >>>> core-libs-dev at openjdk.java.net for a review? Sherman >>>> (xueming.shen at oracle.com) owns the jar tool. >>> I've included sun.tools.jar.Main in the latest patch and CCed Sherman. >>> >>> Could you please help to take another look? >>> >>> Many thanks >>> >>> Jonathan >>> >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> On 07/09/2012 03:24 PM, Jonathan Lu wrote: >>>>> Hi Max, >>>>> >>>>> Thanks for reviewing. >>>>> >>>>> On 07/06/2012 06:27 PM, Weijun Wang wrote: >>>>>> Hi Jonathan >>>>>> >>>>>> I have these questions: >>>>>> >>>>>> 1. Why always CAPITAL letters for month and weekday? >>>>> >>>>> This is a fault of the patch, which can be easily fixed by >>>>> updating the >>>>> format string. >>>>> >>>>>> >>>>>> 2. Why always "dd HH:mm:ss zzz yyyy" for the rest? Some locales uses >>>>>> "." instead of ":" as times delimiters. >>>>>> 3. Why always dd after MMM? Some locales prefer dd before MMM. >>>>> >>>>> For question #2 and #3, I was just trying to follow the original >>>>> format >>>>> of Date.toString(). >>>>> >>>>>> >>>>>> Well, if you really think the current "Fri Jul" output is too >>>>>> English, >>>>>> instead of localizing the string, how about we de-localize it >>>>>> totally >>>>>> and choose a neutral format? >>>>>> >>>>>> There are several flavors of ISO date/time format at >>>>>> >>>>>> http://www.w3.org/TR/NOTE-datetime >>>>>> >>>>>> or we can just choose >>>>>> >>>>>> YYYY-MM-dd HH:mm:ss zzz >>>>> >>>>> Good idea, how about a patch in this way? >>>>> http://cr.openjdk.java.net/~luchsh/7163483_4/ >>>>> >>>>> And I prefer to your format since it looks more readable to me. >>>>> >>>>> Thanks and best regards! >>>>> Jonathan >>>>> >>>>>> >>>>>> BTW, the jar command is using the same format, therefore I'm adding >>>>>> core-libs-dev. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> >>>>>> On 07/06/2012 05:16 PM, Jonathan Lu wrote: >>>>>>> Hello Max, >>>>>>> >>>>>>> I's been a long time since my last mail, I did some >>>>>>> investigation and >>>>>>> had some discussion with i18n developers, but still did not see a >>>>>>> nice >>>>>>> solution for the alignment problem. There does not seem be an >>>>>>> existing >>>>>>> API to do this job in JDK scope. So I implemented a simple format >>>>>>> function, and use it to format under different locales. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_3/ >>>>>>> >>>>>>> The patch is trying to format the code in the same way as >>>>>>> java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz >>>>>>> yyyy", except for using names of month and DOW in localized >>>>>>> format. So >>>>>>> far, it works good for me under all supported locales. >>>>>>> >>>>>>> Here's a test case to verify the vertical alignment, which I has >>>>>>> been >>>>>>> posted to i18n mailing list before, >>>>>>> http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java >>>>>>> >>>>>>> It may still fail under "vi_VN" locale with this solution due to >>>>>>> test >>>>>>> case limit, but I do not think it is a real failure since the >>>>>>> result >>>>>>> fields still get aligned except for multiple words in one field. >>>>>>> >>>>>>> Could you please take a look at the patch? >>>>>>> >>>>>>> Many thanks & best regards >>>>>>> Jonathan >>>>>>> >>>>>>> On 04/25/2012 07:48 PM, Weijun Wang wrote: >>>>>>>> Hi Jonathan >>>>>>>> >>>>>>>> I'm using English. >>>>>>>> >>>>>>>> In your test all the files have a similar modified time so you >>>>>>>> cannot >>>>>>>> see the difference. However, in my example, you can see that the >>>>>>>> widths for date and hour are not zero-padded so the width can be >>>>>>>> either 1 or 2. >>>>>>>> >>>>>>>> French is even worse >>>>>>>> >>>>>>>> smk 76 10 nov. 2009 08:57:54 bin/vbin/go >>>>>>>> smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans >>>>>>>> smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown >>>>>>>> smk 671 8 f?vr. 2012 20:11:22 bin/vbin/ssh.desktop >>>>>>>> smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf >>>>>>>> >>>>>>>> So here even the width of month abbr can be different. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>> On 04/25/2012 07:09 PM, Jonathan Lu wrote: >>>>>>>>> Hello Max, >>>>>>>>> >>>>>>>>> Terribly sorry for my misunderstanding! >>>>>>>>> >>>>>>>>> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>>>>>>>>> Hi Weijun, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for your time, I've updated the webrev, could you >>>>>>>>>>>>> please >>>>>>>>>>>>> take a >>>>>>>>>>>>> look? >>>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>>>>>>>>> >>>>>>>>>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>>>>>>>>> Hi Jonathan >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some comments: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Can you be sure that the new format always has the same >>>>>>>>>>>>>> length? >>>>>>>>>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>>>>>>>>> should be >>>>>>>>>>>>>> aligned. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not sure of that, so the test case was updated to compare >>>>>>>>>>>>> the >>>>>>>>>>>>> first >>>>>>>>>>>>> several tokens to determine whether there's any differences >>>>>>>>>>>>> in the >>>>>>>>>>>>> expression of date time. >>>>>>>>>>>> >>>>>>>>>>>> Sorry, I didn't make myself clear last time, I was mainly >>>>>>>>>>>> afraid of >>>>>>>>>>>> unaligned lines that make the output ugly. >>>>>>>>>>>> >>>>>>>>>>>> For example: >>>>>>>>>>>> >>>>>>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I think that would not be a problem in the new test case which >>>>>>>>>>> compares >>>>>>>>>>> tokenized strings splited by blank spaces instead of >>>>>>>>>>> String#equals. >>>>>>>>>>> Does >>>>>>>>>>> that make sense? >>>>>>>>>> >>>>>>>>>> I'm not talking about the test. It's the output of jarsigner >>>>>>>>>> looking >>>>>>>>>> ugly. >>>>>>>>>> >>>>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>>>> >>>>>>>>>> Compare with the current output: >>>>>>>>>> >>>>>>>>>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>>>>>>>>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>>>>>>>>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>>>>>>>>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>>>>>>>>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >>>>>>>>> >>>>>>>>> I did not see unaligned format in my testing, did you get these >>>>>>>>> unaligned output after applying the patch? From above lines, I >>>>>>>>> see the >>>>>>>>> starting indices of date string in each line are always the same, >>>>>>>>> which >>>>>>>>> is achieved by jarsigner, but the length of the date strings are >>>>>>>>> not the >>>>>>>>> same, which locale were you testing on? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2. You might need to reformat the modified line to make >>>>>>>>>>>>>> it fit >>>>>>>>>>>>>> into 80 >>>>>>>>>>>>>> characters width. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3. Why not include the test inside the changeset? >>>>>>>>>>>>> 2, 3 were done in the new patch >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>>>>>>>>> Hello security-dev, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Here's a patch for bug 7163483, could anybody please >>>>>>>>>>>>>>> help to >>>>>>>>>>>>>>> take a >>>>>>>>>>>>>>> look? >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The problem is that command "jarsigner -verify -verbose >>>>>>>>>>>>>>> my.jar" >>>>>>>>>>>>>>> does not >>>>>>>>>>>>>>> format date string according to current locale. following >>>>>>>>>>>>>>> simple >>>>>>>>>>>>>>> test >>>>>>>>>>>>>>> case can be used to disclose this problem. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /* >>>>>>>>>>>>>>> * Copyright (c) 2012 Oracle and/or its affiliates. All >>>>>>>>>>>>>>> rights >>>>>>>>>>>>>>> reserved. >>>>>>>>>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE >>>>>>>>>>>>>>> HEADER. >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> * This code is free software; you can redistribute it >>>>>>>>>>>>>>> and/or >>>>>>>>>>>>>>> modify it >>>>>>>>>>>>>>> * under the terms of the GNU General Public License >>>>>>>>>>>>>>> version 2 >>>>>>>>>>>>>>> only, as >>>>>>>>>>>>>>> * published by the Free Software Foundation. >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> * This code is distributed in the hope that it will be >>>>>>>>>>>>>>> useful, but >>>>>>>>>>>>>>> WITHOUT >>>>>>>>>>>>>>> * ANY WARRANTY; without even the implied warranty of >>>>>>>>>>>>>>> MERCHANTABILITY or >>>>>>>>>>>>>>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General >>>>>>>>>>>>>>> Public >>>>>>>>>>>>>>> License >>>>>>>>>>>>>>> * version 2 for more details (a copy is included in the >>>>>>>>>>>>>>> LICENSE >>>>>>>>>>>>>>> file >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> * accompanied this code). >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> * You should have received a copy of the GNU General Public >>>>>>>>>>>>>>> License >>>>>>>>>>>>>>> version >>>>>>>>>>>>>>> * 2 along with this work; if not, write to the Free >>>>>>>>>>>>>>> Software >>>>>>>>>>>>>>> Foundation, >>>>>>>>>>>>>>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 >>>>>>>>>>>>>>> USA. >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> * Please contact Oracle, 500 Oracle Parkway, Redwood >>>>>>>>>>>>>>> Shores, CA >>>>>>>>>>>>>>> 94065 >>>>>>>>>>>>>>> USA >>>>>>>>>>>>>>> * or visit www.oracle.com if you need additional >>>>>>>>>>>>>>> information or >>>>>>>>>>>>>>> have any >>>>>>>>>>>>>>> * questions. >>>>>>>>>>>>>>> */ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /* >>>>>>>>>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>>>>>>>>> */ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>>>>>>>>> import java.io.PrintStream; >>>>>>>>>>>>>>> import java.util.Locale; >>>>>>>>>>>>>>> import sun.security.tools.JarSigner; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> public class bug7163483 { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>>>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>>>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ByteArrayOutputStream stream = new >>>>>>>>>>>>>>> ByteArrayOutputStream(1024*64); >>>>>>>>>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>>>>>>>>> System.setOut(out); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>>>>>>>>> JarSigner js = new JarSigner(); >>>>>>>>>>>>>>> js.run(arg); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> out.flush(); >>>>>>>>>>>>>>> String s1 = stream.toString(); >>>>>>>>>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>>>>>>>>> stream.reset(); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>>>>>>>>> js = new JarSigner(); >>>>>>>>>>>>>>> js.run(arg); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> out.flush(); >>>>>>>>>>>>>>> String s2 = stream.toString(); >>>>>>>>>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> if (s1.equals(s2)) { >>>>>>>>>>>>>>> System.err.println("Header output for GERMAN locale >>>>>>>>>>>>>>> is:"+s1); >>>>>>>>>>>>>>> System.err.println("Header output for FRANCE locale >>>>>>>>>>>>>>> is:"+s2); >>>>>>>>>>>>>>> throw new RuntimeException( >>>>>>>>>>>>>>> "JarSigner verbose outputs are the same after setting >>>>>>>>>>>>>>> locale!!"); >>>>>>>>>>>>>>> } else { >>>>>>>>>>>>>>> System.err.println("Header output for GERMAN locale >>>>>>>>>>>>>>> is:"+s1); >>>>>>>>>>>>>>> System.err.println("Header output for FRANCE locale >>>>>>>>>>>>>>> is:"+s2); >>>>>>>>>>>>>>> System.err.println("Test passed!"); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks and best regards! >>>>>>>>>>>>>>> - Jonathan Lu >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards! >>>>>>>>>>>>> - Jonathan >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Thanks & regards! >>>>>>>>>>> - Jonathan >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> - Jonathan >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > From weijun.wang at oracle.com Wed Jul 11 01:22:13 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 11 Jul 2012 16:22:13 +0800 Subject: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale) In-Reply-To: <4FFD3199.7050909@linux.vnet.ibm.com> References: <4F9524EE.1000803@linux.vnet.ibm.com> <4F9650E0.2030603@oracle.com> <4F97A7A0.1050808@linux.vnet.ibm.com> <4F97BFE0.8010708@oracle.com> <4F97C29D.8030909@linux.vnet.ibm.com> <4F97C657.2010009@oracle.com> <4F97DB75.3040204@linux.vnet.ibm.com> <4F97E496.9020509@oracle.com> <4FF6ACF7.6020200@linux.vnet.ibm.com> <4FF6BD8A.4080500@oracle.com> <4FFA8726.60306@linux.vnet.ibm.com> <4FFB7D44.8010201@oracle.com> <4FFD181D.3030709@linux.vnet.ibm.com> <4FFD1B5E.2090208@oracle.com> <4FFD277D.9050000@oracle.com> <4FFD3199.7050909@linux.vnet.ibm.com> Message-ID: <4FFD37B5.6060204@oracle.com> On 07/11/2012 03:56 PM, Jonathan Lu wrote: > Hello Sherman, > > Thanks a lot for review! > > I've made another patch to no include the changes for jar tool, > http://cr.openjdk.java.net/~luchsh/7163483_6/ > > And to Max, > > Does it make sense for you to change jarSigner only? I don't think so. My understanding is that if we want to make a change, we should change both. Otherwise, neither. Jar is much more widely used, so people read the jar output much more than jarsigner. This bug is about whether the "locale correctness" is more important than compatibility, and I think the answer applies to both tools. If a user is OK with the jar output, I see no reason why he/she cannot tolerate the jarsigner output. Is there a business case? Thanks Max > > best regards! > > Jonathan > > On 07/11/2012 03:13 PM, Xueming Shen wrote: >> >> As Max point out, you definitely need to avoid creating SDF everytime >> you have to >> print out one entry. But I'm more worried about the fact you are >> changing the out >> put of jar t. Jar is a widely used tool, It might be a surprise to >> someone who has code >> depend on the current output format. Personally I would suggest not >> make this change >> in jar tool. >> >> -Sherman >> >> On 7/10/2012 11:21 PM, Weijun Wang wrote: >>> Mostly fine. >>> >>> 1. "import java.text.FieldPosition;" is not needed anymore. >>> >>> 2. In jar/Main, you can also consider creating a separate >>> SimpleDateFormat object (maybe private final static?). It seems the >>> initialization is quite heavy. >>> >>> You recently became a jdk8 committer, right? That means you can do >>> your own push but if you want to make any changes to the bug >>> database, just tell me. >>> >>> Thanks >>> Max >>> >>> On 07/11/2012 02:07 PM, Jonathan Lu wrote: >>>> Hello Max, >>>> >>>> Thanks a lot for review, here's the updated patch, >>>> >>>> http://cr.openjdk.java.net/~luchsh/7163483_5/ >>>> >>>> On 07/10/2012 08:54 AM, Weijun Wang wrote: >>>>> Hi Jonathon >>>>> >>>>> This is better. Two minor comments, you can decide what to do or we >>>>> can see what core-lib-devs think: >>>> >>>> I was proposing my solution for this issue and I'd like to hear more >>>> from core-lib-devs list. :) >>>> >>>>> >>>>> 1. Current output uses "zzz" for timezones, you're using "ZZZ". It >>>>> might be more of an ISO flavor. >>>> >>>> Changed to "zzz" format which seems to be more readable for me. >>>> >>>>> >>>>> 2. The DateFormat.format(Date,StringBuffer,FilePosition) is quite >>>>> advanced. If it's me, I'll use the simpler format(Data) method. >>>> >>>> Updated in the new patch. >>>> >>>>> >>>>> Since the jar command also uses the same output format, can you also >>>>> make the same change there (that's sun.tools.jar.Main) and ask >>>>> core-libs-dev at openjdk.java.net for a review? Sherman >>>>> (xueming.shen at oracle.com) owns the jar tool. >>>> I've included sun.tools.jar.Main in the latest patch and CCed Sherman. >>>> >>>> Could you please help to take another look? >>>> >>>> Many thanks >>>> >>>> Jonathan >>>> >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> >>>>> On 07/09/2012 03:24 PM, Jonathan Lu wrote: >>>>>> Hi Max, >>>>>> >>>>>> Thanks for reviewing. >>>>>> >>>>>> On 07/06/2012 06:27 PM, Weijun Wang wrote: >>>>>>> Hi Jonathan >>>>>>> >>>>>>> I have these questions: >>>>>>> >>>>>>> 1. Why always CAPITAL letters for month and weekday? >>>>>> >>>>>> This is a fault of the patch, which can be easily fixed by >>>>>> updating the >>>>>> format string. >>>>>> >>>>>>> >>>>>>> 2. Why always "dd HH:mm:ss zzz yyyy" for the rest? Some locales uses >>>>>>> "." instead of ":" as times delimiters. >>>>>>> 3. Why always dd after MMM? Some locales prefer dd before MMM. >>>>>> >>>>>> For question #2 and #3, I was just trying to follow the original >>>>>> format >>>>>> of Date.toString(). >>>>>> >>>>>>> >>>>>>> Well, if you really think the current "Fri Jul" output is too >>>>>>> English, >>>>>>> instead of localizing the string, how about we de-localize it >>>>>>> totally >>>>>>> and choose a neutral format? >>>>>>> >>>>>>> There are several flavors of ISO date/time format at >>>>>>> >>>>>>> http://www.w3.org/TR/NOTE-datetime >>>>>>> >>>>>>> or we can just choose >>>>>>> >>>>>>> YYYY-MM-dd HH:mm:ss zzz >>>>>> >>>>>> Good idea, how about a patch in this way? >>>>>> http://cr.openjdk.java.net/~luchsh/7163483_4/ >>>>>> >>>>>> And I prefer to your format since it looks more readable to me. >>>>>> >>>>>> Thanks and best regards! >>>>>> Jonathan >>>>>> >>>>>>> >>>>>>> BTW, the jar command is using the same format, therefore I'm adding >>>>>>> core-libs-dev. >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> On 07/06/2012 05:16 PM, Jonathan Lu wrote: >>>>>>>> Hello Max, >>>>>>>> >>>>>>>> I's been a long time since my last mail, I did some >>>>>>>> investigation and >>>>>>>> had some discussion with i18n developers, but still did not see a >>>>>>>> nice >>>>>>>> solution for the alignment problem. There does not seem be an >>>>>>>> existing >>>>>>>> API to do this job in JDK scope. So I implemented a simple format >>>>>>>> function, and use it to format under different locales. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_3/ >>>>>>>> >>>>>>>> The patch is trying to format the code in the same way as >>>>>>>> java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz >>>>>>>> yyyy", except for using names of month and DOW in localized >>>>>>>> format. So >>>>>>>> far, it works good for me under all supported locales. >>>>>>>> >>>>>>>> Here's a test case to verify the vertical alignment, which I has >>>>>>>> been >>>>>>>> posted to i18n mailing list before, >>>>>>>> http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java >>>>>>>> >>>>>>>> It may still fail under "vi_VN" locale with this solution due to >>>>>>>> test >>>>>>>> case limit, but I do not think it is a real failure since the >>>>>>>> result >>>>>>>> fields still get aligned except for multiple words in one field. >>>>>>>> >>>>>>>> Could you please take a look at the patch? >>>>>>>> >>>>>>>> Many thanks & best regards >>>>>>>> Jonathan >>>>>>>> >>>>>>>> On 04/25/2012 07:48 PM, Weijun Wang wrote: >>>>>>>>> Hi Jonathan >>>>>>>>> >>>>>>>>> I'm using English. >>>>>>>>> >>>>>>>>> In your test all the files have a similar modified time so you >>>>>>>>> cannot >>>>>>>>> see the difference. However, in my example, you can see that the >>>>>>>>> widths for date and hour are not zero-padded so the width can be >>>>>>>>> either 1 or 2. >>>>>>>>> >>>>>>>>> French is even worse >>>>>>>>> >>>>>>>>> smk 76 10 nov. 2009 08:57:54 bin/vbin/go >>>>>>>>> smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans >>>>>>>>> smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown >>>>>>>>> smk 671 8 f?vr. 2012 20:11:22 bin/vbin/ssh.desktop >>>>>>>>> smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf >>>>>>>>> >>>>>>>>> So here even the width of month abbr can be different. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04/25/2012 07:09 PM, Jonathan Lu wrote: >>>>>>>>>> Hello Max, >>>>>>>>>> >>>>>>>>>> Terribly sorry for my misunderstanding! >>>>>>>>>> >>>>>>>>>> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>>>>>>>>>> Hi Weijun, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for your time, I've updated the webrev, could you >>>>>>>>>>>>>> please >>>>>>>>>>>>>> take a >>>>>>>>>>>>>> look? >>>>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>>>>>>>>>> Hi Jonathan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some comments: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Can you be sure that the new format always has the same >>>>>>>>>>>>>>> length? >>>>>>>>>>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>>>>>>>>>> should be >>>>>>>>>>>>>>> aligned. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not sure of that, so the test case was updated to compare >>>>>>>>>>>>>> the >>>>>>>>>>>>>> first >>>>>>>>>>>>>> several tokens to determine whether there's any differences >>>>>>>>>>>>>> in the >>>>>>>>>>>>>> expression of date time. >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry, I didn't make myself clear last time, I was mainly >>>>>>>>>>>>> afraid of >>>>>>>>>>>>> unaligned lines that make the output ugly. >>>>>>>>>>>>> >>>>>>>>>>>>> For example: >>>>>>>>>>>>> >>>>>>>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I think that would not be a problem in the new test case which >>>>>>>>>>>> compares >>>>>>>>>>>> tokenized strings splited by blank spaces instead of >>>>>>>>>>>> String#equals. >>>>>>>>>>>> Does >>>>>>>>>>>> that make sense? >>>>>>>>>>> >>>>>>>>>>> I'm not talking about the test. It's the output of jarsigner >>>>>>>>>>> looking >>>>>>>>>>> ugly. >>>>>>>>>>> >>>>>>>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>>>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>>>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>>>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>>>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>>>>>>> >>>>>>>>>>> Compare with the current output: >>>>>>>>>>> >>>>>>>>>>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>>>>>>>>>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>>>>>>>>>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>>>>>>>>>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>>>>>>>>>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >>>>>>>>>> >>>>>>>>>> I did not see unaligned format in my testing, did you get these >>>>>>>>>> unaligned output after applying the patch? From above lines, I >>>>>>>>>> see the >>>>>>>>>> starting indices of date string in each line are always the same, >>>>>>>>>> which >>>>>>>>>> is achieved by jarsigner, but the length of the date strings are >>>>>>>>>> not the >>>>>>>>>> same, which locale were you testing on? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. You might need to reformat the modified line to make >>>>>>>>>>>>>>> it fit >>>>>>>>>>>>>>> into 80 >>>>>>>>>>>>>>> characters width. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3. Why not include the test inside the changeset? >>>>>>>>>>>>>> 2, 3 were done in the new patch >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>>>>>>>>>> Hello security-dev, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Here's a patch for bug 7163483, could anybody please >>>>>>>>>>>>>>>> help to >>>>>>>>>>>>>>>> take a >>>>>>>>>>>>>>>> look? >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The problem is that command "jarsigner -verify -verbose >>>>>>>>>>>>>>>> my.jar" >>>>>>>>>>>>>>>> does not >>>>>>>>>>>>>>>> format date string according to current locale. following >>>>>>>>>>>>>>>> simple >>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>> case can be used to disclose this problem. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /* >>>>>>>>>>>>>>>> * Copyright (c) 2012 Oracle and/or its affiliates. All >>>>>>>>>>>>>>>> rights >>>>>>>>>>>>>>>> reserved. >>>>>>>>>>>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE >>>>>>>>>>>>>>>> HEADER. >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> * This code is free software; you can redistribute it >>>>>>>>>>>>>>>> and/or >>>>>>>>>>>>>>>> modify it >>>>>>>>>>>>>>>> * under the terms of the GNU General Public License >>>>>>>>>>>>>>>> version 2 >>>>>>>>>>>>>>>> only, as >>>>>>>>>>>>>>>> * published by the Free Software Foundation. >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> * This code is distributed in the hope that it will be >>>>>>>>>>>>>>>> useful, but >>>>>>>>>>>>>>>> WITHOUT >>>>>>>>>>>>>>>> * ANY WARRANTY; without even the implied warranty of >>>>>>>>>>>>>>>> MERCHANTABILITY or >>>>>>>>>>>>>>>> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General >>>>>>>>>>>>>>>> Public >>>>>>>>>>>>>>>> License >>>>>>>>>>>>>>>> * version 2 for more details (a copy is included in the >>>>>>>>>>>>>>>> LICENSE >>>>>>>>>>>>>>>> file >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> * accompanied this code). >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> * You should have received a copy of the GNU General Public >>>>>>>>>>>>>>>> License >>>>>>>>>>>>>>>> version >>>>>>>>>>>>>>>> * 2 along with this work; if not, write to the Free >>>>>>>>>>>>>>>> Software >>>>>>>>>>>>>>>> Foundation, >>>>>>>>>>>>>>>> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 >>>>>>>>>>>>>>>> USA. >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> * Please contact Oracle, 500 Oracle Parkway, Redwood >>>>>>>>>>>>>>>> Shores, CA >>>>>>>>>>>>>>>> 94065 >>>>>>>>>>>>>>>> USA >>>>>>>>>>>>>>>> * or visit www.oracle.com if you need additional >>>>>>>>>>>>>>>> information or >>>>>>>>>>>>>>>> have any >>>>>>>>>>>>>>>> * questions. >>>>>>>>>>>>>>>> */ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /* >>>>>>>>>>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>>>>>>>>>> */ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>>>>>>>>>> import java.io.PrintStream; >>>>>>>>>>>>>>>> import java.util.Locale; >>>>>>>>>>>>>>>> import sun.security.tools.JarSigner; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> public class bug7163483 { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>>>>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>>>>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ByteArrayOutputStream stream = new >>>>>>>>>>>>>>>> ByteArrayOutputStream(1024*64); >>>>>>>>>>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>>>>>>>>>> System.setOut(out); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>>>>>>>>>> JarSigner js = new JarSigner(); >>>>>>>>>>>>>>>> js.run(arg); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> out.flush(); >>>>>>>>>>>>>>>> String s1 = stream.toString(); >>>>>>>>>>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>>>>>>>>>> stream.reset(); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>>>>>>>>>> js = new JarSigner(); >>>>>>>>>>>>>>>> js.run(arg); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> out.flush(); >>>>>>>>>>>>>>>> String s2 = stream.toString(); >>>>>>>>>>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> if (s1.equals(s2)) { >>>>>>>>>>>>>>>> System.err.println("Header output for GERMAN locale >>>>>>>>>>>>>>>> is:"+s1); >>>>>>>>>>>>>>>> System.err.println("Header output for FRANCE locale >>>>>>>>>>>>>>>> is:"+s2); >>>>>>>>>>>>>>>> throw new RuntimeException( >>>>>>>>>>>>>>>> "JarSigner verbose outputs are the same after setting >>>>>>>>>>>>>>>> locale!!"); >>>>>>>>>>>>>>>> } else { >>>>>>>>>>>>>>>> System.err.println("Header output for GERMAN locale >>>>>>>>>>>>>>>> is:"+s1); >>>>>>>>>>>>>>>> System.err.println("Header output for FRANCE locale >>>>>>>>>>>>>>>> is:"+s2); >>>>>>>>>>>>>>>> System.err.println("Test passed!"); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks and best regards! >>>>>>>>>>>>>>>> - Jonathan Lu >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards! >>>>>>>>>>>>>> - Jonathan >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Thanks & regards! >>>>>>>>>>>> - Jonathan >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> - Jonathan >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > > From weijun.wang at oracle.com Wed Jul 11 02:14:19 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 11 Jul 2012 09:14:19 +0000 Subject: hg: jdk8/tl/jdk: 6966259: Make PrincipalName and Realm immutable Message-ID: <20120711091601.75D4147F60@hg.openjdk.java.net> Changeset: 79b63e8eceda Author: weijun Date: 2012-07-11 17:10 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79b63e8eceda 6966259: Make PrincipalName and Realm immutable Reviewed-by: xuelei ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAppMessage.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbException.java ! src/share/classes/sun/security/krb5/KrbKdcRep.java ! src/share/classes/sun/security/krb5/KrbPriv.java ! src/share/classes/sun/security/krb5/KrbSafe.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/RealmException.java - src/share/classes/sun/security/krb5/ServiceName.java ! src/share/classes/sun/security/krb5/internal/ASRep.java ! src/share/classes/sun/security/krb5/internal/Authenticator.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/EncASRepPart.java ! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java ! src/share/classes/sun/security/krb5/internal/EncTGSRepPart.java ! src/share/classes/sun/security/krb5/internal/EncTicketPart.java ! src/share/classes/sun/security/krb5/internal/KDCRep.java ! src/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/TGSRep.java ! src/share/classes/sun/security/krb5/internal/Ticket.java ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/share/classes/sun/security/krb5/internal/ccache/CredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ccache/MemoryCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/KinitOptions.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/windows/native/sun/security/krb5/NativeCreds.c - test/sun/security/krb5/ServiceNameClone.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/name/Constructors.java + test/sun/security/krb5/name/empty.conf + test/sun/security/krb5/name/krb5.conf From vincent.x.ryan at oracle.com Wed Jul 11 03:55:43 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 11 Jul 2012 11:55:43 +0100 Subject: 7182500 OCSP revocation checking fails if OCSP response does not contain certificates In-Reply-To: <4FFCD997.1090405@oracle.com> References: <4FFC91CC.9090203@oracle.com> <4FFCD997.1090405@oracle.com> Message-ID: <4FFD5BAF.4030103@oracle.com> Thanks Xuelei. On 07/11/12 02:40 AM, Xuelei Fan wrote: > Looks fine to me. > > Xuelei > > On 7/11/2012 4:34 AM, Vincent Ryan wrote: >> Hello, >> >> Please review the following changeset for JDK 7u6: >> http://cr.openjdk.java.net/~vinnie/7182500/ >> >> The bug report is at: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7182500 >> >> The error occurs when an OCSP responder opts not to return the signing >> certificate used in an OCSP response. The fix is to set the default >> signer cert to be the cert of the issuer of the cert being validated. >> >> This fix addresses a regression in the OCSP client which was introduced >> in my fix for CR 7168191 >> (http://hg.openjdk.java.net/jdk7u/jdk7u6-dev/jdk/rev/52ab0f489dab). >> >> Thanks. > > From mala.bankal at oracle.com Wed Jul 11 04:27:02 2012 From: mala.bankal at oracle.com (Mala Bankal) Date: Wed, 11 Jul 2012 16:57:02 +0530 Subject: Request for approval (7157903 : JSSE client sockets are very slow) for 6-open Message-ID: <4FFD6306.8030709@oracle.com> HI, Request approval for : 7157903 JSSE client sockets are very slow for 6-open webrev : http://cr.openjdk.java.net/~mbankal/7157903/webrev.00/ Nagle Algorithm (TCP_NODELAY) which affects small packets is false by default. As a result, the kernel was throttling the JSSE output waiting for the peer's TCP ACK before sending the next packet. Fix is to combine the small/output packets if TCP_NODELAY is not active. JDK8 and JDK7 integrations : http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10480cf00dcd http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/0b287839e567 rgds mala From weijun.wang at oracle.com Wed Jul 11 18:42:30 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 12 Jul 2012 09:42:30 +0800 Subject: Code review request: 7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes In-Reply-To: <4FF6894B.9070406@Oracle.COM> References: <19780024.1341533557483.JavaMail.sbladm@swsblss4-new.central.sun.com> <4FF6719B.3040005@oracle.com> <4FF6894B.9070406@Oracle.COM> Message-ID: <4FFE2B86.2030308@oracle.com> Someone else can review the 7u6 part? I need two reviewers. Thanks Max On 07/06/2012 02:44 PM, Xuelei Fan wrote: > On 7/6/2012 1:03 PM, Weijun Wang wrote: >> Hi All >> >> I have two fixes for this bug: >> >> For 7u6: http://cr.openjdk.java.net/~weijun/7180907/7u/webrev.00/ >> > Looks fine to me, except a very minor copyright date: you may want to > use 2012 for SignerInfo.java. > >> This simply makes the name recognizable. It's safe and I don't want >> anything broken in 7u6. >> >> Thanks >> Max >> >> [1] >> http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html >> >> >> >> -------- Original Message -------- >> === *Description* >> ============================================================ >> SHORT SUMMARY: >> If a signature block (.RSA, a PKCS#7 object) contains authenticated >> attributes >> and uses a SHA-256 digest, verification will fail. The digest >> algorithm is >> stored in the PKCS7 using the correct OID (2.16.840.1.101.3.4.2.1) but >> sun.security.x509.AlgorithmId maps this back to an algorithm with name >> "SHA256". This is not a valid MessageDigest name - the correct version is >> SHA-256. >> >> The debug output from: >> jarsigner -J-Djava.security.debug=all -verbose -verify i3.jar >> debug.txt and i3.jar available here: >> ftp://bugftp.us.oracle.com/upload/bug_13/bug13941476 >> INDICATORS: >> COUNTER INDICATORS: >> TRIGGERS: >> KNOWN WORKAROUND: >> >> PRESENT SINCE: >> N/A >> HOW TO VERIFY: >> Run attached test case >> NOTES FOR SE: >> None >> REGRESSION: >> > From vincent.x.ryan at oracle.com Thu Jul 12 02:41:40 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 12 Jul 2012 10:41:40 +0100 Subject: Code review request: 7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes In-Reply-To: <4FFE2B86.2030308@oracle.com> References: <19780024.1341533557483.JavaMail.sbladm@swsblss4-new.central.sun.com> <4FF6719B.3040005@oracle.com> <4FF6894B.9070406@Oracle.COM> <4FFE2B86.2030308@oracle.com> Message-ID: <4FFE9BD4.8020100@oracle.com> Your fix looks good Max. Thanks. On 07/12/12 02:42 AM, Weijun Wang wrote: > Someone else can review the 7u6 part? I need two reviewers. > > Thanks > Max > > On 07/06/2012 02:44 PM, Xuelei Fan wrote: >> On 7/6/2012 1:03 PM, Weijun Wang wrote: >>> Hi All >>> >>> I have two fixes for this bug: >>> >>> For 7u6: http://cr.openjdk.java.net/~weijun/7180907/7u/webrev.00/ >>> >> Looks fine to me, except a very minor copyright date: you may want to >> use 2012 for SignerInfo.java. >> >>> This simply makes the name recognizable. It's safe and I don't want >>> anything broken in 7u6. >>> >>> Thanks >>> Max >>> >>> [1] >>> http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html >>> >>> >>> >>> >>> -------- Original Message -------- >>> === *Description* >>> ============================================================ >>> SHORT SUMMARY: >>> If a signature block (.RSA, a PKCS#7 object) contains authenticated >>> attributes >>> and uses a SHA-256 digest, verification will fail. The digest >>> algorithm is >>> stored in the PKCS7 using the correct OID (2.16.840.1.101.3.4.2.1) but >>> sun.security.x509.AlgorithmId maps this back to an algorithm with name >>> "SHA256". This is not a valid MessageDigest name - the correct >>> version is >>> SHA-256. >>> >>> The debug output from: >>> jarsigner -J-Djava.security.debug=all -verbose -verify i3.jar >>> debug.txt and i3.jar available here: >>> ftp://bugftp.us.oracle.com/upload/bug_13/bug13941476 >>> INDICATORS: >>> COUNTER INDICATORS: >>> TRIGGERS: >>> KNOWN WORKAROUND: >>> >>> PRESENT SINCE: >>> N/A >>> HOW TO VERIFY: >>> Run attached test case >>> NOTES FOR SE: >>> None >>> REGRESSION: >>> >> > From vincent.x.ryan at oracle.com Thu Jul 12 13:48:16 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 12 Jul 2012 21:48:16 +0100 Subject: code review request for 6880559: Enable PKCS11 64-bit windows builds Message-ID: <4FFF3810.1080404@oracle.com> Please review this changeset to (finally) add support for PKCS11 on 64-bit Windows. Bug Report: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880559 Webrev: http://cr.openjdk.java.net/~vinnie/6880559/webrev.00/ It includes NSS 3.13.1 libraries for Windows 32-bit and 64-bit in the PKCS11 testsuite. PKCS11 tests on Solaris and Linux continue to use NSS from the operating system. Thanks. From mstjohns at comcast.net Thu Jul 12 13:53:50 2012 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 12 Jul 2012 16:53:50 -0400 Subject: code review request for 6880559: Enable PKCS11 64-bit windows builds In-Reply-To: <4FFF3810.1080404@oracle.com> References: <4FFF3810.1080404@oracle.com> Message-ID: Any chance this will get back-ported to jdk7? (or has it already?) Mike Sent from my iPad On Jul 12, 2012, at 16:48, Vincent Ryan wrote: > Please review this changeset to (finally) add support for PKCS11 on 64-bit Windows. > > Bug Report: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880559 > > Webrev: > http://cr.openjdk.java.net/~vinnie/6880559/webrev.00/ > > It includes NSS 3.13.1 libraries for Windows 32-bit and 64-bit in the > PKCS11 testsuite. PKCS11 tests on Solaris and Linux continue to use > NSS from the operating system. > > Thanks. From christophe.ravel at oracle.com Thu Jul 12 14:25:27 2012 From: christophe.ravel at oracle.com (Christophe Ravel) Date: Thu, 12 Jul 2012 14:25:27 -0700 Subject: code review request for 6880559: Enable PKCS11 64-bit windows builds In-Reply-To: <4FFF3810.1080404@oracle.com> References: <4FFF3810.1080404@oracle.com> Message-ID: <9379C689-9D13-4C50-A023-CCD0AECEF709@oracle.com> Looks good to me. Christophe. On Jul 12, 2012, at 1:48 PM, Vincent Ryan wrote: > Please review this changeset to (finally) add support for PKCS11 on 64-bit Windows. > > Bug Report: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880559 > > Webrev: > http://cr.openjdk.java.net/~vinnie/6880559/webrev.00/ > > It includes NSS 3.13.1 libraries for Windows 32-bit and 64-bit in the > PKCS11 testsuite. PKCS11 tests on Solaris and Linux continue to use > NSS from the operating system. > > Thanks. Christophe Ravel | Principal Member of Technical Staff | +1.650.506.2162 Oracle Java SQE - Security 4220 Network Circle, B160A, Santa Clara, CA From valerie.peng at oracle.com Thu Jul 12 15:57:16 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 12 Jul 2012 15:57:16 -0700 Subject: code review request for 6880559: Enable PKCS11 64-bit windows builds In-Reply-To: <4FFF3810.1080404@oracle.com> References: <4FFF3810.1080404@oracle.com> Message-ID: <4FFF564C.3030900@oracle.com> Looks good to me. Thanks, Valerie On 07/12/12 13:48, Vincent Ryan wrote: > Please review this changeset to (finally) add support for PKCS11 on > 64-bit Windows. > > Bug Report: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880559 > > Webrev: > http://cr.openjdk.java.net/~vinnie/6880559/webrev.00/ > > It includes NSS 3.13.1 libraries for Windows 32-bit and 64-bit in the > PKCS11 testsuite. PKCS11 tests on Solaris and Linux continue to use > NSS from the operating system. > > Thanks. From bradford.wetmore at oracle.com Thu Jul 12 16:22:10 2012 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 12 Jul 2012 16:22:10 -0700 Subject: Please Review Test Fix of Bug 7177045 In-Reply-To: <4FF5FB4E.10804@oracle.com> References: <4FECC35C.10105@oracle.com> <4FECF72A.6090102@oracle.com> <4FF5FB4E.10804@oracle.com> Message-ID: <4FFF5C22.3050107@oracle.com> Sorry for the delay Dan. Please work with Kurchi to get this pushed. On 7/5/2012 1:38 PM, Dan Xu wrote: > Hi Brad, > > Thanks for your good suggestions. I have fixed most of them and > re-uploaded my changes at http://cr.openjdk.java.net/~dxu/7177045.01/. > > The reason that I chose ArrayDeque instead of LinkedList is that > ArrayDequeseems have better performance. According to the java doc, > "most ArrayDeque operations run in amortized constant time" and "this > class is likely to be faster then LinkedList when used as a queue." It > is also very easy to remove last elements to back off memory allocation. Great, thanks for the pointer. > In addition, I did not switch to diamond operator. Because old Jdk > bundles, say jdk 1.7.0-ea-b23 and jdk 1.7.0-ea-b29 used in my testing, > failed to compile diamond operator. Here are the compilation error messages, > > TestProviderLeak.java:62: illegal start of type > Deque data = new ArrayDeque<>(); > ^ > 1 error > > I guess those jdk might be too early to adopt the diamond operator > changes. I am not sure whether we still take these old jdk bundles into > consideration here. Thanks! Yes, it would be good to actually show that it failed on b23 and not on b29 without having to modify the source. Good point. >> Minor nit: line 38 has a space at the end of the line. Current >> jstyle guidelines state no indention with tabs and no whitespace at >> the end of the lines. Looks good. >> Suggest more liberal use of comments, either in the method's comments >> or inline. Good to explain your assumptions/approach in case things >> aren't obvious. For example, why do you backoff 3MB after allocating >> available memory? And at line 134: the operation could either time >> out or threw an exception. Nice to make that clear. Thanks! >> Line 114: consider adding a @overrides annotation on the call() method. Good. >> Line 139: I'm being paranoid here, but shutdownNow doesn't guarantee >> threads will be stopped. If we actually got into a situation where >> there was a timeout, executor.shutdownNow() *may* never return. One >> reason is it might be hanging somewhere waiting for memory. I would >> suggest as part of your finally block, you dequeue all the memory in >> dummyData, call System.gc(), then run executor.shutdownNow(). JTREG >> will timeout after two minutes, but if we can proactively help the >> situation, we might as well. >> >> Otherwise, looks good. We'll wait to see if anyone has other >> thoughts, and if not, we'll push when you're back from vacation. Thanks. Brad From vincent.x.ryan at oracle.com Thu Jul 12 16:45:03 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 13 Jul 2012 00:45:03 +0100 Subject: code review request for 6880559: Enable PKCS11 64-bit windows builds In-Reply-To: References: <4FFF3810.1080404@oracle.com> Message-ID: <4FFF617F.4010603@oracle.com> It's not done yet but as you can see from the webrev there are no difficulties supporting this in JDK 7. On 12/07/2012 21:53, Michael StJohns wrote: > Any chance this will get back-ported to jdk7? (or has it already?) > > Mike > > Sent from my iPad > > On Jul 12, 2012, at 16:48, Vincent Ryan wrote: > >> Please review this changeset to (finally) add support for PKCS11 on 64-bit Windows. >> >> Bug Report: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880559 >> >> Webrev: >> http://cr.openjdk.java.net/~vinnie/6880559/webrev.00/ >> >> It includes NSS 3.13.1 libraries for Windows 32-bit and 64-bit in the >> PKCS11 testsuite. PKCS11 tests on Solaris and Linux continue to use >> NSS from the operating system. >> >> Thanks. From maurizio.cimadamore at oracle.com Fri Jul 13 05:01:09 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 13 Jul 2012 12:01:09 +0000 Subject: hg: jdk8/tl/langtools: 7181578: javac reports uninitialized variable with nested try...finally blocks Message-ID: <20120713120114.3458147027@hg.openjdk.java.net> Changeset: 934a89402f85 Author: mcimadamore Date: 2012-07-13 12:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/934a89402f85 7181578: javac reports uninitialized variable with nested try...finally blocks Summary: regression introduced in refactoring of Flow.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/DefiniteAssignment/T7181578.java From huizhe.wang at oracle.com Thu Jul 12 21:05:04 2012 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 13 Jul 2012 04:05:04 +0000 Subject: hg: jdk8/tl/jaxp: 7183760: DocumentBuilder.parse(String uri) is not IPv6 enabled Message-ID: <20120713040508.1C09A48000@hg.openjdk.java.net> Changeset: 6e444b892c99 Author: joehw Date: 2012-07-12 21:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6e444b892c99 7183760: DocumentBuilder.parse(String uri) is not IPv6 enabled Summary: removing the hack of using escapeNonUSAscii. this is the same patch as 7166896 for 7u8. Reviewed-by: psandoz, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java From mark.reinhold at oracle.com Fri Jul 13 12:04:20 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 13 Jul 2012 12:04:20 -0700 Subject: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale) In-Reply-To: weijun.wang@oracle.com; Fri, 06 Jul 2012 18:27:22 +0800; <4FF6BD8A.4080500@oracle.com> Message-ID: <20120713190420.17A10AAF@eggemoggin.niobe.net> 2012/7/6 3:27 -0700, weijun.wang at oracle.com: > I have these questions: > > ... > > Well, if you really think the current "Fri Jul" output is too English, instead > of localizing the string, how about we de-localize it totally and choose a > neutral format? Excellent idea! > There are several flavors of ISO date/time format at > > http://www.w3.org/TR/NOTE-datetime > > or we can just choose > > YYYY-MM-dd HH:mm:ss zzz > > BTW, the jar command is using the same format ... Changing the jarsigner command to use the same format as the jar command makes the most sense to me. - Mark From kurchi.subhra.hazra at oracle.com Fri Jul 13 16:04:20 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 13 Jul 2012 23:04:20 +0000 Subject: hg: jdk8/tl/jdk: 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node Message-ID: <20120713230446.C14E747036@hg.openjdk.java.net> Changeset: e9461aeff91f Author: khazra Date: 2012-07-13 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9461aeff91f 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node Summary: Change native code to convey to Java code whether a new node was added Reviewed-by: alanb, chegar ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/native/java/util/MacOSXPreferencesFile.m + test/java/util/prefs/AddNodeChangeListener.java From kumar.x.srinivasan at oracle.com Sat Jul 14 20:27:42 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sun, 15 Jul 2012 03:27:42 +0000 Subject: hg: jdk8/tl/jdk: 7184145: (pack200) pack200 --repack throws NullPointerException when JAR file specified without path Message-ID: <20120715032804.575674705F@hg.openjdk.java.net> Changeset: 9e5150e8bcf5 Author: ksrini Date: 2012-07-14 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e5150e8bcf5 7184145: (pack200) pack200 --repack throws NullPointerException when JAR file specified without path Reviewed-by: alanb, sherman ! src/share/classes/com/sun/java/util/jar/pack/Driver.java + test/tools/pack200/RepackTest.java From weijun.wang at oracle.com Mon Jul 16 03:23:01 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 16 Jul 2012 18:23:01 +0800 Subject: Code review request: 7183203: ShortRSAKeynnn.sh tests intermittent failure In-Reply-To: <1392965.1342000259989.JavaMail.sbladm@swsblss4-new.central.sun.com> References: <1392965.1342000259989.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <5003EB85.60606@oracle.com> Hi Xuelei The ShortRSAKeyNNN tests have failed several times recently, showing strange error messages like "Signature not verified" or "Cannot create key" for the keytool command. It might be some internal MSCAPI problem but I'm not sure. Therefore I'm adding a "-debug" option to keytool calls. Also, it looks to me these tests are almost identical, so I've consolidated them into one. Please take a review: http://cr.openjdk.java.net/~weijun/7183203/webrev.00/ Thanks Max -------- Original Message -------- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183203 7183203: ShortRSAKeynnn.sh tests intermittent failure Product: java Category: java Subcategory: classes_security Type: Defect === *Description* ============================================================ sun/security/mscapi/ShortRSAKey1024.sh sun/security/mscapi/ShortRSAKey768.sh sun/security/mscapi/ShortRSAKey512.sh We are seeing these tests intermittent failure recently. Error is on keytool -genkeypair command, sometimes "Bad key" sometimes "Invalid signature". Not sure if it's an MSCAPI problem or multiple tests are modifying Windows-MY at the same time. This CR intends to add more debug info and combine the tests into one that run consequently. From weijun.wang at oracle.com Mon Jul 16 06:18:03 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 16 Jul 2012 21:18:03 +0800 Subject: Code review request: 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified In-Reply-To: <7863435.1341936690854.JavaMail.sbladm@swsblss4-new.central.sun.com> References: <7863435.1341936690854.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <5004148B.7020305@oracle.com> Hi Please take a review at http://cr.openjdk.java.net/~weijun/7102106/webrev.00/ The new environment variable allows you to set an alternative path to old JDK releases if the default /java/re/j2se is not what you want. Thanks Max -------- Original Message -------- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7102106 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified === *Description* ============================================================ test used "/java/re" for latest binaries and failed because it is slowly or not available from some russia lab machines (timeout) test show wrong status "Passed" if /java/re is not available on machine (reproducible on stt-52.ru.oracle.com) latest binaries can be defined by env variable(s) and than lines: OLDJAVA=" /java/re/j2se/1.6.0/latest/binaries/${PF} /java/re/j2se/1.5.0/latest/binaries/${PF} /java/re/j2se/1.4.2/latest/binaries/${PF} " can be replaced, for example, on following lines: OLDJAVA=" ${JDK_LATEST_BASE_PATH}${FS}1.6.0${FS}latest${FS}binaries${FS}${PF} ${JDK_LATEST_BASE_PATH}${FS}1.5.0${FS}latest${FS}binaries${FS}${PF} ${JDK_LATEST_BASE_PATH}${FS}1.4.2${FS}latest${FS}binaries${FS}${PF} " JDK_LATEST_BASE_PATH can be set to /java/re by default and redefined to available location if needed test passed after relocate latest binaries at local Russia server and change OLDJAVA From sean.mullan at oracle.com Mon Jul 16 07:22:52 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 16 Jul 2012 10:22:52 -0400 Subject: Code review request: 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified In-Reply-To: <5004148B.7020305@oracle.com> References: <7863435.1341936690854.JavaMail.sbladm@swsblss4-new.central.sun.com> <5004148B.7020305@oracle.com> Message-ID: <500423BC.1050901@oracle.com> Hi Max, The fix looks fine, but I am wondering if it is appropriate to require that everyone that runs these tests must have these older JREs installed or mounted for this test to pass. It seems like it would have been better to pre-generate the serialized data and add them as test data files. I know binary files are discouraged, but in this case it should be relatively easy to reproduce the serialized forms if we ever need to, and other tests already do this - for example see test/java/security/BasicPermission/SerialVersion.java --Sean On 07/16/2012 09:18 AM, Weijun Wang wrote: > Hi > > Please take a review at > > http://cr.openjdk.java.net/~weijun/7102106/webrev.00/ > > The new environment variable allows you to set an alternative path to > old JDK releases if the default /java/re/j2se is not what you want. > > Thanks > Max > > > -------- Original Message -------- > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7102106 > 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified > > === *Description* > ============================================================ > test used "/java/re" for latest binaries and failed because it is slowly > or not available from some russia lab machines (timeout) > > test show wrong status "Passed" if /java/re is not available on machine > (reproducible on stt-52.ru.oracle.com) > > latest binaries can be defined by env variable(s) and than lines: > > OLDJAVA=" > /java/re/j2se/1.6.0/latest/binaries/${PF} > /java/re/j2se/1.5.0/latest/binaries/${PF} > /java/re/j2se/1.4.2/latest/binaries/${PF} > " > > can be replaced, for example, on following lines: > OLDJAVA=" > ${JDK_LATEST_BASE_PATH}${FS}1.6.0${FS}latest${FS}binaries${FS}${PF} > ${JDK_LATEST_BASE_PATH}${FS}1.5.0${FS}latest${FS}binaries${FS}${PF} > ${JDK_LATEST_BASE_PATH}${FS}1.4.2${FS}latest${FS}binaries${FS}${PF} > " > > JDK_LATEST_BASE_PATH can be set to /java/re by default and redefined to > available location if needed > > test passed after relocate latest binaries at local Russia server and > change OLDJAVA From weijun.wang at oracle.com Mon Jul 16 07:43:08 2012 From: weijun.wang at oracle.com (Wei-jun Wang) Date: Mon, 16 Jul 2012 22:43:08 +0800 Subject: Code review request: 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified In-Reply-To: <500423BC.1050901@oracle.com> References: <7863435.1341936690854.JavaMail.sbladm@swsblss4-new.central.sun.com> <5004148B.7020305@oracle.com> <500423BC.1050901@oracle.com> Message-ID: The interop test is bi-directional. The new JDK needs to understand what older JDKs produce, vice versa. Therefore it must launch those older JDKs. Thanks Max ?? Jul 16, 2012??10:22 PM??Sean Mullan ?????? > Hi Max, > > The fix looks fine, but I am wondering if it is appropriate to require that everyone that runs these tests must have these older JREs installed or mounted for this test to pass. It seems like it would have been better to pre-generate the serialized data and add them as test data files. I know binary files are discouraged, but in this case it should be relatively easy to reproduce the serialized forms if we ever need to, and other tests already do this - for example see test/java/security/BasicPermission/SerialVersion.java > > --Sean > > On 07/16/2012 09:18 AM, Weijun Wang wrote: >> Hi >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/7102106/webrev.00/ >> >> The new environment variable allows you to set an alternative path to >> old JDK releases if the default /java/re/j2se is not what you want. >> >> Thanks >> Max >> >> >> -------- Original Message -------- >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7102106 >> 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified >> >> === *Description* >> ============================================================ >> test used "/java/re" for latest binaries and failed because it is slowly >> or not available from some russia lab machines (timeout) >> >> test show wrong status "Passed" if /java/re is not available on machine >> (reproducible on stt-52.ru.oracle.com) >> >> latest binaries can be defined by env variable(s) and than lines: >> >> OLDJAVA=" >> /java/re/j2se/1.6.0/latest/binaries/${PF} >> /java/re/j2se/1.5.0/latest/binaries/${PF} >> /java/re/j2se/1.4.2/latest/binaries/${PF} >> " >> >> can be replaced, for example, on following lines: >> OLDJAVA=" >> ${JDK_LATEST_BASE_PATH}${FS}1.6.0${FS}latest${FS}binaries${FS}${PF} >> ${JDK_LATEST_BASE_PATH}${FS}1.5.0${FS}latest${FS}binaries${FS}${PF} >> ${JDK_LATEST_BASE_PATH}${FS}1.4.2${FS}latest${FS}binaries${FS}${PF} >> " >> >> JDK_LATEST_BASE_PATH can be set to /java/re by default and redefined to >> available location if needed >> >> test passed after relocate latest binaries at local Russia server and >> change OLDJAVA > > From vincent.x.ryan at oracle.com Mon Jul 16 09:44:25 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 16 Jul 2012 17:44:25 +0100 Subject: code review request for 6880559: Enable PKCS11 64-bit windows builds In-Reply-To: <4FFF3810.1080404@oracle.com> References: <4FFF3810.1080404@oracle.com> Message-ID: <500444E9.4060300@oracle.com> FYI I've updated this changeset to include the NSS sources, in compliance with the requirements of MPL 2.0 license. http://cr.openjdk.java.net/~vinnie/6880559/webrev.01/ On 07/12/12 09:48 PM, Vincent Ryan wrote: > Please review this changeset to (finally) add support for PKCS11 on > 64-bit Windows. > > Bug Report: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6880559 > > Webrev: > http://cr.openjdk.java.net/~vinnie/6880559/webrev.00/ > > It includes NSS 3.13.1 libraries for Windows 32-bit and 64-bit in the > PKCS11 testsuite. PKCS11 tests on Solaris and Linux continue to use > NSS from the operating system. > > Thanks. From tom.deneau at amd.com Mon Jul 16 13:08:45 2012 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 16 Jul 2012 20:08:45 +0000 Subject: Request for Review: AESCrypt.init performance JDK change Message-ID: Please review the following webrev which improves performance for the com/sun/crypto/provider when the algorithm is AES for some kinds of Cipher usage patterns. http://cr.openjdk.java.net/~tdeneau/aescrypt-init-performance/webrev.01/ I do not have a bug number for this change but a description would be something like the following: Consider an application which holds on to a Cipher object for AES and keeps the same key but calls Cipher.init to change the Cipher between encryption and decryption. The current code in AESCrypt.java recomputes the expanded key (which is an expensive operation) with each call to init. The proposed code saves the key and, if it has not changed, does not need to recompute on subsequent calls to Cipher.init. The proposed code also incorporates into the key calculation the final step which was the expansion of the key to a 1-dimensional array of ints. This step used to be done in the routine setSubKey. -- Tom Deneau From vincent.x.ryan at oracle.com Mon Jul 16 14:42:18 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 16 Jul 2012 21:42:18 +0000 Subject: hg: jdk8/tl/jdk: 6880559: Enable PKCS11 64-bit windows builds Message-ID: <20120716214241.A20AC470A2@hg.openjdk.java.net> Changeset: 5cee646eaaa7 Author: vinnie Date: 2012-07-16 22:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5cee646eaaa7 6880559: Enable PKCS11 64-bit windows builds Reviewed-by: valeriep ! THIRD_PARTY_README ! make/sun/security/Makefile ! test/sun/security/pkcs11/PKCS11Test.java + test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libnspr4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libplc4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/libplds4.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nss3.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.lib + test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.chk + test/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll + test/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll + test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.lib + test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nss3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.lib + test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.chk + test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll + test/sun/security/pkcs11/nss/lib/windows-i586/ssl3.lib + test/sun/security/pkcs11/nss/src/MD5SUMS + test/sun/security/pkcs11/nss/src/SHA1SUMS + test/sun/security/pkcs11/nss/src/nss-3.13.1.tar.gz From vincent.x.ryan at oracle.com Mon Jul 16 14:44:03 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 16 Jul 2012 21:44:03 +0000 Subject: hg: jdk8/tl: 6880559: Enable PKCS11 64-bit windows builds Message-ID: <20120716214403.8316D470A3@hg.openjdk.java.net> Changeset: 0562a97bd601 Author: vinnie Date: 2012-07-16 22:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0562a97bd601 6880559: Enable PKCS11 64-bit windows builds Reviewed-by: valeriep ! THIRD_PARTY_README From kurchi.subhra.hazra at oracle.com Mon Jul 16 16:31:20 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Mon, 16 Jul 2012 23:31:20 +0000 Subject: hg: jdk8/tl/jdk: 7177045: Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors. Message-ID: <20120716233142.CBD14470AE@hg.openjdk.java.net> Changeset: 1469be7182b4 Author: khazra Date: 2012-07-16 16:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1469be7182b4 7177045: Rework the TestProviderLeak.java regression test, it is too fragile to low memory errors. Summary: Increase Xmx to 20 MB and add mechanisms to eat up most of the JVM free memory. Reviewed-by: wetmore Contributed-by: dan.xu at oracle.com ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java From weijun.wang at oracle.com Mon Jul 16 18:36:48 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 17 Jul 2012 09:36:48 +0800 Subject: Code review request: 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified In-Reply-To: References: <7863435.1341936690854.JavaMail.sbladm@swsblss4-new.central.sun.com> <5004148B.7020305@oracle.com> <500423BC.1050901@oracle.com> Message-ID: <5004C1B0.3020106@oracle.com> Also, the test skips an old JDK (and shows a warning) if its path does not exist. What this bug wants to solve is that the path exists but is too slow. -Max On 07/16/2012 10:43 PM, Wei-jun Wang wrote: > The interop test is bi-directional. The new JDK needs to understand what older JDKs produce, vice versa. Therefore it must launch those older JDKs. > > Thanks > Max > > > > ?? Jul 16, 2012??10:22 PM??Sean Mullan ?????? > >> Hi Max, >> >> The fix looks fine, but I am wondering if it is appropriate to require that everyone that runs these tests must have these older JREs installed or mounted for this test to pass. It seems like it would have been better to pre-generate the serialized data and add them as test data files. I know binary files are discouraged, but in this case it should be relatively easy to reproduce the serialized forms if we ever need to, and other tests already do this - for example see test/java/security/BasicPermission/SerialVersion.java >> >> --Sean >> >> On 07/16/2012 09:18 AM, Weijun Wang wrote: >>> Hi >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/7102106/webrev.00/ >>> >>> The new environment variable allows you to set an alternative path to >>> old JDK releases if the default /java/re/j2se is not what you want. >>> >>> Thanks >>> Max >>> >>> >>> -------- Original Message -------- >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7102106 >>> 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified >>> >>> === *Description* >>> ============================================================ >>> test used "/java/re" for latest binaries and failed because it is slowly >>> or not available from some russia lab machines (timeout) >>> >>> test show wrong status "Passed" if /java/re is not available on machine >>> (reproducible on stt-52.ru.oracle.com) >>> >>> latest binaries can be defined by env variable(s) and than lines: >>> >>> OLDJAVA=" >>> /java/re/j2se/1.6.0/latest/binaries/${PF} >>> /java/re/j2se/1.5.0/latest/binaries/${PF} >>> /java/re/j2se/1.4.2/latest/binaries/${PF} >>> " >>> >>> can be replaced, for example, on following lines: >>> OLDJAVA=" >>> ${JDK_LATEST_BASE_PATH}${FS}1.6.0${FS}latest${FS}binaries${FS}${PF} >>> ${JDK_LATEST_BASE_PATH}${FS}1.5.0${FS}latest${FS}binaries${FS}${PF} >>> ${JDK_LATEST_BASE_PATH}${FS}1.4.2${FS}latest${FS}binaries${FS}${PF} >>> " >>> >>> JDK_LATEST_BASE_PATH can be set to /java/re by default and redefined to >>> available location if needed >>> >>> test passed after relocate latest binaries at local Russia server and >>> change OLDJAVA >> >> From xuelei.fan at oracle.com Mon Jul 16 19:35:00 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 17 Jul 2012 10:35:00 +0800 Subject: Code review request: 7183203: ShortRSAKeynnn.sh tests intermittent failure In-Reply-To: <5003EB85.60606@oracle.com> References: <1392965.1342000259989.JavaMail.sbladm@swsblss4-new.central.sun.com> <5003EB85.60606@oracle.com> Message-ID: <5004CF54.7060008@oracle.com> Looks fine to me. Thanks for addressing this issue. Xuelei On 7/16/2012 6:23 PM, Weijun Wang wrote: > Hi Xuelei > > The ShortRSAKeyNNN tests have failed several times recently, showing > strange error messages like "Signature not verified" or "Cannot create > key" for the keytool command. It might be some internal MSCAPI problem > but I'm not sure. > > Therefore I'm adding a "-debug" option to keytool calls. Also, it looks > to me these tests are almost identical, so I've consolidated them into > one. Please take a review: > > http://cr.openjdk.java.net/~weijun/7183203/webrev.00/ > > Thanks > Max > > > -------- Original Message -------- > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183203 > > 7183203: ShortRSAKeynnn.sh tests intermittent failure > > Product: java > Category: java > Subcategory: classes_security > Type: Defect > > === *Description* > ============================================================ > sun/security/mscapi/ShortRSAKey1024.sh > sun/security/mscapi/ShortRSAKey768.sh > sun/security/mscapi/ShortRSAKey512.sh > > We are seeing these tests intermittent failure recently. Error is on > keytool -genkeypair command, sometimes "Bad key" sometimes "Invalid > signature". > > Not sure if it's an MSCAPI problem or multiple tests are modifying > Windows-MY at the same time. This CR intends to add more debug info and > combine the tests into one that run consequently. > From weijun.wang at oracle.com Mon Jul 16 20:28:44 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 17 Jul 2012 03:28:44 +0000 Subject: hg: jdk8/tl/jdk: 7183203: ShortRSAKeynnn.sh tests intermittent failure Message-ID: <20120717032905.9D5CA470B5@hg.openjdk.java.net> Changeset: e2d265c9b592 Author: weijun Date: 2012-07-17 11:28 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2d265c9b592 7183203: ShortRSAKeynnn.sh tests intermittent failure Reviewed-by: xuelei ! test/sun/security/mscapi/ShortRSAKey1024.sh - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh From weijun.wang at oracle.com Mon Jul 16 20:32:40 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 17 Jul 2012 11:32:40 +0800 Subject: OpenJDK krb5 ignore /etc/krb5.conf? In-Reply-To: <4FF55194.5050403@oracle.com> References: <4FF55194.5050403@oracle.com> Message-ID: <5004DCD8.6080805@oracle.com> Ping again. On 07/05/2012 04:34 PM, Weijun Wang wrote: > Hi Scott > > On Mac since Lion, sun.security.krb5.Config tries to locate the config > info in this order: > > 1. java.security.krb5.conf system property > 2. ${jre}/lib/security/krb5.conf > 3. SCDynamicStoreConfig > > The main difference from other platforms is that it will not try config > files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. > > On the other hand, even /usr/bin/kinit comes with Lion reads the config > file (if there is no SCDynamicStoreConfig setting). > > Is there a special reason for the current Java behavior? I do notice > that the Apple 6u33 already does this. > > Thanks > Max From weijun.wang at oracle.com Mon Jul 16 20:57:52 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 17 Jul 2012 03:57:52 +0000 Subject: hg: jdk8/tl/jdk: 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified Message-ID: <20120717035802.78DFE470B7@hg.openjdk.java.net> Changeset: 2a39c98c1241 Author: weijun Date: 2012-07-17 11:57 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a39c98c1241 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified Reviewed-by: mullan ! test/sun/security/util/Oid/S11N.sh From lana.steuck at oracle.com Mon Jul 16 22:12:06 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 17 Jul 2012 05:12:06 +0000 Subject: hg: jdk8/tl: 6 new changesets Message-ID: <20120717051207.0452E470BB@hg.openjdk.java.net> Changeset: f6a685069274 Author: katleman Date: 2012-07-05 18:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f6a685069274 Added tag jdk8-b46 for changeset 27fa766a2298 ! .hgtags Changeset: c8d320b48626 Author: erikj Date: 2012-07-03 16:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c8d320b48626 7181504: Update of latest build-infra Makefiles Reviewed-by: ohair ! common/autoconf/autogen.sh ! common/autoconf/build-aux/config.guess ! common/autoconf/builddeps.conf.example ! common/autoconf/builddeps.m4 ! common/autoconf/configure ! common/autoconf/configure.ac - common/autoconf/cores.m4 ! common/autoconf/help.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/bin/compareimage.sh ! common/bin/diffexec.sh ! common/bin/diffjarzip.sh ! common/bin/difflib.sh ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk - common/makefiles/RMICompile.gmk Changeset: 3156dff953b1 Author: erikj Date: 2012-07-05 18:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3156dff953b1 7182051: Update of latest build-infra Makefiles (missing files) Reviewed-by: ohair + common/autoconf/basics.m4 + common/autoconf/boot-jdk.m4 + common/autoconf/build-aux/autoconf-config.guess + common/autoconf/build-performance.m4 + common/autoconf/generated-configure.sh + common/autoconf/jdk-options.m4 + common/autoconf/libraries.m4 + common/autoconf/source-dirs.m4 + common/autoconf/spec.sh.in + common/autoconf/toolchain.m4 + common/bin/compare-objects.sh ! common/makefiles/IdlCompilation.gmk + common/makefiles/MakeHelpers.gmk ! common/makefiles/NativeCompilation.gmk + common/makefiles/RMICompilation.gmk Changeset: 1dcb4b7b9373 Author: katleman Date: 2012-07-11 16:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1dcb4b7b9373 Merge - common/autoconf/cores.m4 - common/makefiles/RMICompile.gmk Changeset: aaae5471808d Author: katleman Date: 2012-07-12 16:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/aaae5471808d Added tag jdk8-b47 for changeset 1dcb4b7b9373 ! .hgtags Changeset: c88aceaf2f3f Author: lana Date: 2012-07-16 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c88aceaf2f3f Merge - common/autoconf/cores.m4 - common/makefiles/RMICompile.gmk From lana.steuck at oracle.com Mon Jul 16 22:12:03 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 17 Jul 2012 05:12:03 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20120717051212.3FF12470BC@hg.openjdk.java.net> Changeset: cb31b67326bc Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cb31b67326bc Added tag jdk8-b46 for changeset 30141e598d72 ! .hgtags Changeset: 21e46ea21c6a Author: lana Date: 2012-07-10 11:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/21e46ea21c6a Merge Changeset: 7e2b179a5b4d Author: katleman Date: 2012-07-12 16:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7e2b179a5b4d Added tag jdk8-b47 for changeset 21e46ea21c6a ! .hgtags From lana.steuck at oracle.com Mon Jul 16 22:11:58 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 17 Jul 2012 05:11:58 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120717051219.85727470BD@hg.openjdk.java.net> Changeset: fe6a060afc40 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/fe6a060afc40 Added tag jdk8-b46 for changeset ae368a83c240 ! .hgtags Changeset: efb564de8a8e Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/efb564de8a8e Added tag jdk8-b47 for changeset fe6a060afc40 ! .hgtags From lana.steuck at oracle.com Mon Jul 16 22:11:56 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 17 Jul 2012 05:11:56 +0000 Subject: hg: jdk8/tl/hotspot: 2 new changesets Message-ID: <20120717051219.D71AE470BE@hg.openjdk.java.net> Changeset: 0c7bb1f4f9c8 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c7bb1f4f9c8 Added tag jdk8-b46 for changeset cf37a594c38d ! .hgtags Changeset: fa0c28fabbb1 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa0c28fabbb1 Added tag jdk8-b47 for changeset 0c7bb1f4f9c8 ! .hgtags From lana.steuck at oracle.com Mon Jul 16 22:11:56 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 17 Jul 2012 05:11:56 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20120717051227.A461A470BF@hg.openjdk.java.net> Changeset: bf27b857c6ee Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bf27b857c6ee Added tag jdk8-b46 for changeset 300f45e99064 ! .hgtags Changeset: 404521944ac9 Author: lana Date: 2012-07-10 11:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/404521944ac9 Merge Changeset: 1c88da9a1365 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1c88da9a1365 Added tag jdk8-b47 for changeset 404521944ac9 ! .hgtags Changeset: df4092828362 Author: lana Date: 2012-07-16 17:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/df4092828362 Merge From lana.steuck at oracle.com Mon Jul 16 22:11:56 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 17 Jul 2012 05:11:56 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20120717051228.582D0470C0@hg.openjdk.java.net> Changeset: c7e62fc9df92 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7e62fc9df92 Added tag jdk8-b46 for changeset 4ca599497172 ! .hgtags Changeset: 01d9911df25d Author: erikj Date: 2012-06-28 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/01d9911df25d 7180594: Fix GenStubs in langtools for build-infra builds Reviewed-by: ohair ! make/tools/genstubs/GenStubs.java Changeset: 7e6be2f239c9 Author: ohair Date: 2012-07-08 20:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7e6be2f239c9 Merge Changeset: afb0a5231557 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/afb0a5231557 Added tag jdk8-b47 for changeset 7e6be2f239c9 ! .hgtags Changeset: 1f8fc9e50a1f Author: lana Date: 2012-07-16 17:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f8fc9e50a1f Merge From lana.steuck at oracle.com Mon Jul 16 22:13:09 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 17 Jul 2012 05:13:09 +0000 Subject: hg: jdk8/tl/jdk: 22 new changesets Message-ID: <20120717052455.79C10470C7@hg.openjdk.java.net> Changeset: 9d1738ef61d6 Author: katleman Date: 2012-07-05 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d1738ef61d6 Added tag jdk8-b46 for changeset 8d2ed9d58453 ! .hgtags Changeset: 9881db0a65bf Author: prr Date: 2012-06-26 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9881db0a65bf 7145771: [macosx] CreateFont/Register.java test fails because of cached results of getAllFonts() Reviewed-by: igor, flar ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java Changeset: c689cc1ef29a Author: prr Date: 2012-06-26 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c689cc1ef29a 7176447: Lunix/Solaris fontpath.c : double free(family) Reviewed-by: igor, flar ! src/solaris/native/sun/awt/fontpath.c Changeset: ad126e65ccc5 Author: prr Date: 2012-06-26 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad126e65ccc5 7164282: check for NULL return from malloc is testing wrong variable name. Reviewed-by: igor, flar ! src/windows/native/sun/font/lcdglyph.c Changeset: c960cb8d0f8b Author: lana Date: 2012-06-27 18:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c960cb8d0f8b Merge Changeset: 8e6b8a676596 Author: lana Date: 2012-07-03 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e6b8a676596 Merge Changeset: 7d1eae258183 Author: serb Date: 2012-06-26 13:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d1eae258183 7142091: [macosx] RFE: Refactoring of peer initialization/disposing Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: c66b34ec39c3 Author: bagiras Date: 2012-06-26 16:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c66b34ec39c3 7024749: JDK7 b131---a crash in: Java_sun_awt_windows_ThemeReader_isGetThemeTransitionDurationDefined+0x75 Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp + test/java/awt/Frame/7024749/bug7024749.java Changeset: 6d37b95f0555 Author: anthony Date: 2012-06-26 17:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d37b95f0555 7124326: [macosx] An issue similar to autoshutdown one in two AppContexts situation. Summary: Don't add SystemTrayPeer to the peers map Reviewed-by: art, leonidr ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 7cadd5bb6983 Author: lana Date: 2012-06-27 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cadd5bb6983 Merge Changeset: 85f72a4f5f68 Author: rupashka Date: 2012-06-28 14:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85f72a4f5f68 7169111: Unreadable menu bar with Ambiance theme in GTK L&F Reviewed-by: kizune ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyleFactory.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java Changeset: 8a284872ee2d Author: lana Date: 2012-07-03 20:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a284872ee2d Merge Changeset: d828938945af Author: lana Date: 2012-07-03 20:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d828938945af Merge Changeset: 9957b4759354 Author: lana Date: 2012-07-10 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9957b4759354 Merge Changeset: 6df318863178 Author: erikj Date: 2012-07-03 16:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6df318863178 7181504: Update of latest build-infra Makefiles Reviewed-by: ohair ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CopySamples.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataHtml32dtd.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateData.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcIcons.gmk + makefiles/GensrcJObjC.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk + makefiles/Import.gmk - makefiles/LegacyMakefiles.gmk ! makefiles/Makefile - makefiles/OldImages.gmk ! makefiles/Tools.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy ! makefiles/mapfiles/libjava/mapfile-vers ! makefiles/mapfiles/libjfr/mapfile-vers ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-solaris - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 8cb908672d9e Author: erikj Date: 2012-07-03 11:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cb908672d9e 7181508: Remove GenerateNativeHeader on awt java file Reviewed-by: ohair ! src/share/classes/java/awt/image/DirectColorModel.java ! src/share/classes/sun/awt/CharsetString.java ! src/share/classes/sun/java2d/pipe/RegionIterator.java ! src/share/native/sun/awt/image/cvutils/img_globals.c Changeset: 6cd68b7bd962 Author: erikj Date: 2012-07-03 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cd68b7bd962 7181501: Add some GenerateNativeHeader annotations and misc Mac adjustments to makefiles Reviewed-by: ohair ! src/macosx/native/jobjc/build.xml ! src/macosx/native/jobjc/src/core/PrimitiveCoder.hs ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/FrameworkClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Clazz.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/ComplexCoderDescriptor.java Changeset: 5b0f880eb154 Author: ohair Date: 2012-07-05 13:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b0f880eb154 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 00b22b23269a Author: katleman Date: 2012-07-11 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00b22b23269a Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 3e4ab821f461 Author: katleman Date: 2012-07-12 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e4ab821f461 Added tag jdk8-b47 for changeset 00b22b23269a ! .hgtags Changeset: 7b5e4a64368a Author: lana Date: 2012-07-16 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b5e4a64368a Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: c7e3106e455a Author: lana Date: 2012-07-16 22:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c7e3106e455a Merge - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh From Alan.Bateman at oracle.com Tue Jul 17 01:00:23 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Jul 2012 09:00:23 +0100 Subject: Request for Review: AESCrypt.init performance JDK change In-Reply-To: References: Message-ID: <50051B97.4050805@oracle.com> On 16/07/2012 21:08, Deneau, Tom wrote: > Please review the following webrev which improves performance for the > com/sun/crypto/provider when the algorithm is AES for some kinds of > Cipher usage patterns. > > http://cr.openjdk.java.net/~tdeneau/aescrypt-init-performance/webrev.01/ > > I do not have a bug number for this change but a description would be > something like the following: > > Consider an application which holds on to a Cipher object for AES > and keeps the same key but calls Cipher.init to change the Cipher > between encryption and decryption. The current code in > AESCrypt.java recomputes the expanded key (which is an expensive > operation) with each call to init. > > The proposed code saves the key and, if it has not changed, does not > need to recompute on subsequent calls to Cipher.init. The proposed > code also incorporates into the key calculation the final step which > was the expansion of the key to a 1-dimensional array of ints. This > step used to be done in the routine setSubKey. > > -- Tom Deneau Tom - I assume this will need to get reviewed for jdk8 and bake in that forest for a bit before it can be considered for 7u. -Alan. From tom.deneau at amd.com Tue Jul 17 08:10:59 2012 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 17 Jul 2012 15:10:59 +0000 Subject: Request for Review: AESCrypt.init performance JDK change In-Reply-To: <50051B97.4050805@oracle.com> References: <50051B97.4050805@oracle.com> Message-ID: Alan -- Can you tell me the procedure I should follow? I have submitted hotspot webrevs before but not JDK webrevs? -- Tom -----Original Message----- From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, July 17, 2012 3:00 AM To: Deneau, Tom Cc: jdk7u-dev at openjdk.java.net; security-dev at openjdk.java.net Subject: Re: Request for Review: AESCrypt.init performance JDK change On 16/07/2012 21:08, Deneau, Tom wrote: > Please review the following webrev which improves performance for the > com/sun/crypto/provider when the algorithm is AES for some kinds of > Cipher usage patterns. > > http://cr.openjdk.java.net/~tdeneau/aescrypt-init-performance/webrev.01/ > > I do not have a bug number for this change but a description would be > something like the following: > > Consider an application which holds on to a Cipher object for AES > and keeps the same key but calls Cipher.init to change the Cipher > between encryption and decryption. The current code in > AESCrypt.java recomputes the expanded key (which is an expensive > operation) with each call to init. > > The proposed code saves the key and, if it has not changed, does not > need to recompute on subsequent calls to Cipher.init. The proposed > code also incorporates into the key calculation the final step which > was the expansion of the key to a 1-dimensional array of ints. This > step used to be done in the routine setSubKey. > > -- Tom Deneau Tom - I assume this will need to get reviewed for jdk8 and bake in that forest for a bit before it can be considered for 7u. -Alan. From Alan.Bateman at oracle.com Tue Jul 17 08:31:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Jul 2012 16:31:54 +0100 Subject: Request for Review: AESCrypt.init performance JDK change In-Reply-To: References: <50051B97.4050805@oracle.com> Message-ID: <5005856A.8090608@oracle.com> On 17/07/2012 16:10, Deneau, Tom wrote: > Alan -- > > Can you tell me the procedure I should follow? > I have submitted hotspot webrevs before but not JDK webrevs? > > -- Tom > > You'll need to get a sponsor from the security area (you've cc'ed security-dev so that's the right list). The initial target should be jdk8 as changes going into jdk7u need to be in 8 first. -Alan From frances.ho at oracle.com Tue Jul 17 08:46:11 2012 From: frances.ho at oracle.com (Frances Ho) Date: Tue, 17 Jul 2012 08:46:11 -0700 Subject: Request for Review: AESCrypt.init performance JDK change In-Reply-To: <5005856A.8090608@oracle.com> References: <50051B97.4050805@oracle.com> <5005856A.8090608@oracle.com> Message-ID: <500588C3.304@oracle.com> Valerie Peng will be looking into this one. _Frances On 7/17/2012 8:31 AM, Alan Bateman wrote: > On 17/07/2012 16:10, Deneau, Tom wrote: >> Alan -- >> >> Can you tell me the procedure I should follow? >> I have submitted hotspot webrevs before but not JDK webrevs? >> >> -- Tom >> >> > You'll need to get a sponsor from the security area (you've cc'ed > security-dev so that's the right list). The initial target should be > jdk8 as changes going into jdk7u need to be in 8 first. > > -Alan From sean.mullan at oracle.com Tue Jul 17 12:36:24 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Jul 2012 15:36:24 -0400 Subject: Code review request: 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified In-Reply-To: <5004C1B0.3020106@oracle.com> References: <7863435.1341936690854.JavaMail.sbladm@swsblss4-new.central.sun.com> <5004148B.7020305@oracle.com> <500423BC.1050901@oracle.com> <5004C1B0.3020106@oracle.com> Message-ID: <5005BEB8.10802@oracle.com> On 7/16/12 9:36 PM, Weijun Wang wrote: > Also, the test skips an old JDK (and shows a warning) if its path does > not exist. What this bug wants to solve is that the path exists but is > too slow. Ok, got it now. --Sean > > -Max > > > On 07/16/2012 10:43 PM, Wei-jun Wang wrote: >> The interop test is bi-directional. The new JDK needs to understand what older JDKs produce, vice versa. Therefore it must launch those older JDKs. >> >> Thanks >> Max >> >> >> >> ?? Jul 16, 2012??10:22 PM??Sean Mullan ?????? >> >>> Hi Max, >>> >>> The fix looks fine, but I am wondering if it is appropriate to require that everyone that runs these tests must have these older JREs installed or mounted for this test to pass. It seems like it would have been better to pre-generate the serialized data and add them as test data files. I know binary files are discouraged, but in this case it should be relatively easy to reproduce the serialized forms if we ever need to, and other tests already do this - for example see test/java/security/BasicPermission/SerialVersion.java >>> >>> --Sean >>> >>> On 07/16/2012 09:18 AM, Weijun Wang wrote: >>>> Hi >>>> >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/7102106/webrev.00/ >>>> >>>> The new environment variable allows you to set an alternative path to >>>> old JDK releases if the default /java/re/j2se is not what you want. >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> -------- Original Message -------- >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7102106 >>>> 7102106: TEST_BUG: sun/security/util/Oid/S11N.sh should be modified >>>> >>>> === *Description* >>>> ============================================================ >>>> test used "/java/re" for latest binaries and failed because it is slowly >>>> or not available from some russia lab machines (timeout) >>>> >>>> test show wrong status "Passed" if /java/re is not available on machine >>>> (reproducible on stt-52.ru.oracle.com) >>>> >>>> latest binaries can be defined by env variable(s) and than lines: >>>> >>>> OLDJAVA=" >>>> /java/re/j2se/1.6.0/latest/binaries/${PF} >>>> /java/re/j2se/1.5.0/latest/binaries/${PF} >>>> /java/re/j2se/1.4.2/latest/binaries/${PF} >>>> " >>>> >>>> can be replaced, for example, on following lines: >>>> OLDJAVA=" >>>> ${JDK_LATEST_BASE_PATH}${FS}1.6.0${FS}latest${FS}binaries${FS}${PF} >>>> ${JDK_LATEST_BASE_PATH}${FS}1.5.0${FS}latest${FS}binaries${FS}${PF} >>>> ${JDK_LATEST_BASE_PATH}${FS}1.4.2${FS}latest${FS}binaries${FS}${PF} >>>> " >>>> >>>> JDK_LATEST_BASE_PATH can be set to /java/re by default and redefined to >>>> available location if needed >>>> >>>> test passed after relocate latest binaries at local Russia server and >>>> change OLDJAVA >>> >>> > From stuart.marks at oracle.com Tue Jul 17 14:14:26 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 17 Jul 2012 21:14:26 +0000 Subject: hg: jdk8/tl/jdk: 7142596: RMI JPRT tests are failing Message-ID: <20120717211447.1CD49470DE@hg.openjdk.java.net> Changeset: b6f78869c66d Author: dmocek Date: 2012-07-17 11:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b6f78869c66d 7142596: RMI JPRT tests are failing Summary: Changed RMI tests to use random port numbers for the RMI Registry and RMID so the tests can be run concurrently without test failures due to tests using the same port numbers. Reviewed-by: smarks, alanb Contributed-by: olivier.lagneau at oracle.com ! test/ProblemList.txt ! test/TEST.ROOT ! test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java ! test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java ! test/java/rmi/Naming/LookupNameWithColon.java ! test/java/rmi/Naming/RmiIsNoScheme.java ! test/java/rmi/Naming/UnderscoreHost.java ! test/java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java ! test/java/rmi/activation/Activatable/checkActivateRef/security.policy ! test/java/rmi/activation/Activatable/checkAnnotations/security.policy ! test/java/rmi/activation/Activatable/checkImplClassLoader/security.policy ! test/java/rmi/activation/Activatable/checkRegisterInLog/security.policy ! test/java/rmi/activation/Activatable/createPrivateActivable/security.policy ! test/java/rmi/activation/Activatable/downloadParameterClass/security.policy ! test/java/rmi/activation/Activatable/elucidateNoSuchMethod/security.policy ! test/java/rmi/activation/Activatable/extLoadedImpl/security.policy ! test/java/rmi/activation/Activatable/forceLogSnapshot/security.policy ! test/java/rmi/activation/Activatable/inactiveGroup/security.policy ! test/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java ! test/java/rmi/activation/Activatable/nestedActivate/security.policy ! test/java/rmi/activation/Activatable/nonExistentActivatable/security.policy ! test/java/rmi/activation/Activatable/restartCrashedService/security.policy ! test/java/rmi/activation/Activatable/restartLatecomer/security.policy ! test/java/rmi/activation/Activatable/restartService/security.policy ! test/java/rmi/activation/Activatable/shutdownGracefully/security.policy ! test/java/rmi/activation/Activatable/unregisterInactive/security.policy ! test/java/rmi/activation/ActivateFailedException/activateFails/security.policy ! test/java/rmi/activation/ActivationSystem/activeGroup/security.policy ! test/java/rmi/activation/ActivationSystem/modifyDescriptor/security.policy ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java ! test/java/rmi/activation/ActivationSystem/stubClassesPermitted/security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy ! test/java/rmi/activation/CommandEnvironment/SetChildEnv.java ! test/java/rmi/activation/CommandEnvironment/security.policy ! test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/activation/rmidViaInheritedChannel/rmid.security.policy ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java ! test/java/rmi/registry/emptyName/EmptyName.java ! test/java/rmi/registry/interfaceHash/InterfaceHash.java ! test/java/rmi/registry/multipleRegistries/MultipleRegistries.java ! test/java/rmi/registry/readTest/readTest.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/reliability/juicer/AppleUserImpl.java ! test/java/rmi/reliability/juicer/ApplicationServer.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/EchoImpl.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/activatable/security.policy ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/HelloImpl.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/registry/security.policy ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/EchoImpl.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java ! test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/security.policy ! test/java/rmi/server/RemoteServer/AddrInUse.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/KeepAliveDuringCall.java ! test/java/rmi/server/UnicastRemoteObject/keepAliveDuringCall/ShutdownImpl.java ! test/java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java ! test/java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java ! test/java/rmi/server/Unreferenced/leaseCheckInterval/SelfTerminator.java ! test/java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java ! test/java/rmi/server/useCustomRef/UseCustomRef.java ! test/java/rmi/server/useCustomRef/security.policy ! test/java/rmi/testlibrary/ActivationLibrary.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/testlibrary/RegistryRunner.java ! test/java/rmi/testlibrary/StreamPipe.java ! test/java/rmi/testlibrary/TestLibrary.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkFQDN/CheckFQDNClient.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/java/rmi/transport/checkLeaseInfoLeak/LeaseLeakClient.java ! test/java/rmi/transport/checkLeaseInfoLeak/security.policy ! test/java/rmi/transport/closeServerSocket/CloseServerSocket.java ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java ! test/java/rmi/transport/dgcDeadLock/TestImpl.java ! test/java/rmi/transport/handshakeFailure/HandshakeFailure.java ! test/java/rmi/transport/handshakeTimeout/HandshakeTimeout.java ! test/java/rmi/transport/httpSocket/HttpSocketTest.java ! test/java/rmi/transport/httpSocket/security.policy ! test/java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java ! test/java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java ! test/java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java ! test/sun/rmi/rmic/newrmic/equivalence/AppleUserImpl.java ! test/sun/rmi/rmic/newrmic/equivalence/run.sh ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/runtime/Log/checkLogging/CheckLogging.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java From weijun.wang at oracle.com Tue Jul 17 17:26:10 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Jul 2012 08:26:10 +0800 Subject: OpenJDK krb5 ignore /etc/krb5.conf? In-Reply-To: References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> Message-ID: <500602A2.9070803@oracle.com> I'm not familiar with how Mac does it, but normally there are two ways a Kerberos authentication is performed, through the initial login and through kinit. The former is integrated into the system (a pam module?) and I guess in this case the config is inside SCDynamicStoreConfig. For the latter, the Kerberos clients are regarded as standalone tools and a /etc/krb5.conf is needed. Java works in both ways, if there is already a credentials cache it will happily use it. On the other hand, it also includes the Krb5LoginModule that does all the login itself. Therefore, it should read both styles of config on a Mac. I've filed a new bug, It will appear soon at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184815 Thanks Max On 07/17/2012 10:35 PM, Mike Swingler wrote: > On Jul 16, 2012, at 8:32 PM, Weijun Wang wrote: > >> Ping again. >> >> On 07/05/2012 04:34 PM, Weijun Wang wrote: >>> Hi Scott >>> >>> On Mac since Lion, sun.security.krb5.Config tries to locate the config >>> info in this order: >>> >>> 1. java.security.krb5.conf system property >>> 2. ${jre}/lib/security/krb5.conf >>> 3. SCDynamicStoreConfig >>> >>> The main difference from other platforms is that it will not try config >>> files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. >>> >>> On the other hand, even /usr/bin/kinit comes with Lion reads the config >>> file (if there is no SCDynamicStoreConfig setting). >>> >>> Is there a special reason for the current Java behavior? I do notice >>> that the Apple 6u33 already does this. > > No special reason I can think of, beyond simply swapping the implementation to read from the SCDynamicStoreConfig. Java SE 6 had previously had been relying on the system to write out a /Library/Preferences/edu.mit.Kerberos file, but that went away with OS X 10.7, so we didn't see much point in reading the file, since little else on the system would be paying attention to it either for the purposes of SSO. > > It seems perfectly reasonable that if there are no SCDynamicStoreConfig entries, falling back to reading the legacy config files may be a valid option. I'm actually somewhat surprised that they are consulted by kinit. > > Regards, > Mike Swingler > Apple Inc. > From xueming.shen at oracle.com Tue Jul 17 19:49:53 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 18 Jul 2012 02:49:53 +0000 Subject: hg: jdk8/tl/jdk: 7183053: Optimize DoubleByte charset for String.getBytes()/new String(byte[]) Message-ID: <20120718025004.292C3470F5@hg.openjdk.java.net> Changeset: c76ad79a5a2f Author: sherman Date: 2012-07-17 19:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c76ad79a5a2f 7183053: Optimize DoubleByte charset for String.getBytes()/new String(byte[]) Summary: DoubleByte implements sun/nio.cs/ArrayDe/Encoder interface Reviewed-by: alanb ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! test/sun/nio/cs/StrCodingBenchmark.java + test/sun/nio/cs/StrCodingBenchmarkDB.java ! test/sun/nio/cs/TestStringCoding.java From swingler at apple.com Tue Jul 17 07:35:02 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 17 Jul 2012 07:35:02 -0700 Subject: OpenJDK krb5 ignore /etc/krb5.conf? In-Reply-To: <5004DCD8.6080805@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> Message-ID: On Jul 16, 2012, at 8:32 PM, Weijun Wang wrote: > Ping again. > > On 07/05/2012 04:34 PM, Weijun Wang wrote: >> Hi Scott >> >> On Mac since Lion, sun.security.krb5.Config tries to locate the config >> info in this order: >> >> 1. java.security.krb5.conf system property >> 2. ${jre}/lib/security/krb5.conf >> 3. SCDynamicStoreConfig >> >> The main difference from other platforms is that it will not try config >> files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. >> >> On the other hand, even /usr/bin/kinit comes with Lion reads the config >> file (if there is no SCDynamicStoreConfig setting). >> >> Is there a special reason for the current Java behavior? I do notice >> that the Apple 6u33 already does this. No special reason I can think of, beyond simply swapping the implementation to read from the SCDynamicStoreConfig. Java SE 6 had previously had been relying on the system to write out a /Library/Preferences/edu.mit.Kerberos file, but that went away with OS X 10.7, so we didn't see much point in reading the file, since little else on the system would be paying attention to it either for the purposes of SSO. It seems perfectly reasonable that if there are no SCDynamicStoreConfig entries, falling back to reading the legacy config files may be a valid option. I'm actually somewhat surprised that they are consulted by kinit. Regards, Mike Swingler Apple Inc. From weijun.wang at oracle.com Tue Jul 17 23:29:19 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Jul 2012 14:29:19 +0800 Subject: code review request: 7184815 (was Re: OpenJDK krb5 ignore /etc/krb5.conf?) In-Reply-To: <500602A2.9070803@oracle.com> References: <4FF55194.5050403@oracle.com> <5004DCD8.6080805@oracle.com> <500602A2.9070803@oracle.com> Message-ID: <500657BF.3020107@oracle.com> 7184815: [macosx] Need to read Kerberos config in files Please take a review: http://cr.openjdk.java.net/~weijun/7184815/webrev.00/ I break the config setting to Java setting and native setting, and insert the reading of SCDynamicStoreConfig between the two. This should preserve the 6u behavior and add a fallback to legacy config files. No new regression test, because of SCDynamicStoreConfig and system config files, will ask SQE to create a manual test. Thanks Max On 07/18/2012 08:26 AM, Weijun Wang wrote: > I'm not familiar with how Mac does it, but normally there are two ways a > Kerberos authentication is performed, through the initial login and > through kinit. The former is integrated into the system (a pam module?) > and I guess in this case the config is inside SCDynamicStoreConfig. For > the latter, the Kerberos clients are regarded as standalone tools and a > /etc/krb5.conf is needed. > > Java works in both ways, if there is already a credentials cache it will > happily use it. On the other hand, it also includes the Krb5LoginModule > that does all the login itself. Therefore, it should read both styles of > config on a Mac. > > I've filed a new bug, It will appear soon at > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184815 > > Thanks > Max > > > On 07/17/2012 10:35 PM, Mike Swingler wrote: >> On Jul 16, 2012, at 8:32 PM, Weijun Wang wrote: >> >>> Ping again. >>> >>> On 07/05/2012 04:34 PM, Weijun Wang wrote: >>>> Hi Scott >>>> >>>> On Mac since Lion, sun.security.krb5.Config tries to locate the config >>>> info in this order: >>>> >>>> 1. java.security.krb5.conf system property >>>> 2. ${jre}/lib/security/krb5.conf >>>> 3. SCDynamicStoreConfig >>>> >>>> The main difference from other platforms is that it will not try config >>>> files, say, /Library/Preferences/edu.mit.Kerberos or /etc/krb5.conf. >>>> >>>> On the other hand, even /usr/bin/kinit comes with Lion reads the config >>>> file (if there is no SCDynamicStoreConfig setting). >>>> >>>> Is there a special reason for the current Java behavior? I do notice >>>> that the Apple 6u33 already does this. >> >> No special reason I can think of, beyond simply swapping the >> implementation to read from the SCDynamicStoreConfig. Java SE 6 had >> previously had been relying on the system to write out a >> /Library/Preferences/edu.mit.Kerberos file, but that went away with OS >> X 10.7, so we didn't see much point in reading the file, since little >> else on the system would be paying attention to it either for the >> purposes of SSO. >> >> It seems perfectly reasonable that if there are no >> SCDynamicStoreConfig entries, falling back to reading the legacy >> config files may be a valid option. I'm actually somewhat surprised >> that they are consulted by kinit. >> >> Regards, >> Mike Swingler >> Apple Inc. >> > From yiming.wang at oracle.com Wed Jul 18 00:05:57 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 18 Jul 2012 15:05:57 +0800 Subject: Review request (Resend) - bug 7147060 com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode In-Reply-To: <4FFA92B9.50604@oracle.com> References: <4FFA92B9.50604@oracle.com> Message-ID: <50066055.2020506@oracle.com> Hi Sean, As i haven't get the author role, I share webrev to group by using dropbox, Can you please help to review it? Thanks! http://dl.dropbox.com/u/90659131/fixes/7147060/webrev/index.html Regards, Eric On 2012/7/9 16:13, Eric Wang wrote: > Hi Sean, > > Looks that security-dev alias rejected my previous mail as i was not > the member of it. so I resent this fix again. > Can you please help to review? Thanks! > > Eric From yiming.wang at oracle.com Wed Jul 18 01:48:32 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 18 Jul 2012 16:48:32 +0800 Subject: Review request (Resend) - bug 7147060 com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode In-Reply-To: <50066055.2020506@oracle.com> References: <4FFA92B9.50604@oracle.com> <50066055.2020506@oracle.com> Message-ID: <50067860.8000208@oracle.com> Hi Sean, I'd like to withdraw my fix as there are some concerns about bug 6461674 which is verified by ClassLoaderTest.java (Thanks Max for good suggestions): The bug 6461674 is caused by classes cannot be found in current classloader by calling Class.forName(), so the fix of 6461674 is to replace Class.forName() to Thread.currentThread().getContextClassLoader(), however, it looks the bug 7147060 is negative case of 6461674 that classes can be found in current ClassLoader but cannot be found in thread context ClassLoader because in jtreg agentvm mode, the thread context ClassLoader is parent of current ClassLoader. so the concern is whether the fix of 6461674 is completed as it looks that it produced the side effect. Regards, Eric On 2012/7/18 15:05, Eric Wang wrote: > Hi Sean, > > As i haven't get the author role, I share webrev to group by using > dropbox, Can you please help to review it? Thanks! > http://dl.dropbox.com/u/90659131/fixes/7147060/webrev/index.html > > Regards, > Eric > > On 2012/7/9 16:13, Eric Wang wrote: >> Hi Sean, >> >> Looks that security-dev alias rejected my previous mail as i was not >> the member of it. so I resent this fix again. >> Can you please help to review? Thanks! >> >> Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20120718/d5a1d08a/attachment.html From weijun.wang at oracle.com Wed Jul 18 02:12:06 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Jul 2012 17:12:06 +0800 Subject: Code review request: 7178649: TEST BUG: BadKdc3.java needs improvement to ignore the unlikely but possible timeout In-Reply-To: <6698801.1341225412360.JavaMail.sbladm@swsblss4-new.central.sun.com> References: <6698801.1341225412360.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <50067DE6.2080405@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/7178649/webrev.00/ These tests are meant to verify the behavior of KDC fallback with different bad policy settings. Suppose one KDC has a problem, the client would try it several times each with a timeout, and then go on with the next KDC. As there are a lot of timeout, I have designed the default timeout value to be very short to speed up the whole test. Every now and then, even a good KDC might not be able to reply in this short period, and an unexpected timeout appears, and the test fails. This code change is meant to make the verification smarter, so that it tolerates such kind of "real" timeout. Suppose KDC1 is off and KDC2 is on, then with a max-retries of 3, ideally you will see 3 tries on KDC1 and 1 try on KDC2, but you might also see 2 tries on KDC2. I'm now using the regex "1112{1,2}" to denote this possibility. Please note that in some cases a single "real" timeout will make the whole authentication fail if a KDC is only given max_retries as 1. This is the case in BadKdc1.java's 4th and 5th rounds of test, where the newly started KDC2 has max_retries being 1 (because of its bad history). If a timeout happens on it, there is no way to try it again and the whole authentication would fail. Thus I use "-" in the regex pattern as a failure. Thanks Max -------- Original Message -------- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7178649 7178649: TEST BUG: BadKdc3.java needs improvement to ignore the unlikely but possible timeout Product: java Category: java Subcategory: classes_security === *Description* ============================================================ sun/security/krb5/auto/BadKdc3.java Test needs improvement to ignore the unlikely but possible timeout. Currently it might fail due to such timeout. sun/security/krb5/auto/BadKdc1.java has similiar issue From stuart.marks at oracle.com Wed Jul 18 10:02:51 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 18 Jul 2012 17:02:51 +0000 Subject: hg: jdk8/tl/jdk: 7184943: fix failing test com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java; ... Message-ID: <20120718170303.4B29447108@hg.openjdk.java.net> Changeset: 89129c0737f1 Author: dmocek Date: 2012-07-18 10:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89129c0737f1 7184943: fix failing test com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java 7184946: fix failing test com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java Reviewed-by: smarks ! test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java ! test/com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java From michael.x.mcmahon at oracle.com Wed Jul 18 10:52:28 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 18 Jul 2012 17:52:28 +0000 Subject: hg: jdk8/tl/jdk: 7183292: HttpURLConnection.getHeaderFields() throws IllegalArgumentException: Illegal cookie name Message-ID: <20120718175239.1E4B247109@hg.openjdk.java.net> Changeset: 7bd32bfc0539 Author: michaelm Date: 2012-07-18 18:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bd32bfc0539 7183292: HttpURLConnection.getHeaderFields() throws IllegalArgumentException: Illegal cookie name Reviewed-by: khazra, chegar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java + test/java/net/HttpCookie/IllegalCookieNameTest.java From dan.xu at oracle.com Wed Jul 18 13:55:05 2012 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 18 Jul 2012 13:55:05 -0700 Subject: Code Review Request: Bug 7185051 Message-ID: <500722A9.80601@oracle.com> Security code reviewers, Please review the fix of bug 7185051. Its webrev can be checked at http://cr.openjdk.java.net/~dxu/7185051/webrev/. This commit is to remove the TestProviderLeak.java test from the test problem list as it is already fixed in Bug 7177045. Thanks! -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20120718/40406ad4/attachment.html From kurchi.subhra.hazra at oracle.com Wed Jul 18 14:12:32 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Wed, 18 Jul 2012 14:12:32 -0700 Subject: Code Review Request: Bug 7185051 In-Reply-To: <500722A9.80601@oracle.com> References: <500722A9.80601@oracle.com> Message-ID: <500726C0.6010601@oracle.com> Looks good to me. - Kurchi On 7/18/2012 1:55 PM, Dan Xu wrote: > Security code reviewers, > > Please review the fix of bug 7185051. Its webrev can be checked at > http://cr.openjdk.java.net/~dxu/7185051/webrev/. This commit is to > remove the TestProviderLeak.java test from the test problem list as it > is already fixed in Bug 7177045. Thanks! > > -Dan -- -Kurchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20120718/b5d64481/attachment.html From kurchi.subhra.hazra at oracle.com Wed Jul 18 16:40:07 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Wed, 18 Jul 2012 23:40:07 +0000 Subject: hg: jdk8/tl/jdk: 7185051: Remove TestProviderLeak.java from the ProblemList Message-ID: <20120718234027.C9FE14712E@hg.openjdk.java.net> Changeset: 773474da570b Author: khazra Date: 2012-07-18 15:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/773474da570b 7185051: Remove TestProviderLeak.java from the ProblemList Summary: Remove TestProviderLeak.java from jdk test problem list. Reviewed-by: khazra Contributed-by: dan.xu at oracle.com ! test/ProblemList.txt From chris.hegarty at oracle.com Thu Jul 19 10:19:49 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 19 Jul 2012 17:19:49 +0000 Subject: hg: jdk8/tl/jdk: 7081476: test/java/net/InetSocketAddress/B6469803.java failing intermittently Message-ID: <20120719172024.05C0247149@hg.openjdk.java.net> Changeset: 2c2e4ecc8f7e Author: chegar Date: 2012-07-19 18:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c2e4ecc8f7e 7081476: test/java/net/InetSocketAddress/B6469803.java failing intermittently Reviewed-by: chegar Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/net/DatagramPacket/ReuseBuf.java From xueming.shen at oracle.com Thu Jul 19 21:23:51 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 20 Jul 2012 04:23:51 +0000 Subject: hg: jdk8/tl/jdk: 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X Message-ID: <20120720042421.9835647159@hg.openjdk.java.net> Changeset: 84cd98a5641c Author: sherman Date: 2012-07-19 21:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84cd98a5641c 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X Summary: to support Unicode nfd/nfc file path on Macos Reviewed-by: alanb ! make/java/nio/Makefile ! src/share/native/java/io/io_util.h ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java + src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h + src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c + test/java/io/File/MacPathTest.java + test/java/io/File/MacPathTest.sh + test/java/nio/file/Path/MacPathTest.java + test/java/nio/file/Path/MacPathTest.sh From jason.uh at oracle.com Thu Jul 19 22:03:16 2012 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 19 Jul 2012 22:03:16 -0700 Subject: JDK8 Code review request for 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) Message-ID: <5008E694.7020009@oracle.com> Hi all, Please review my fix for 7026347. This change is introduces verify(PublicKey key, Provider sigProvider) methods for Certificate and X509CRL that allow Providers not registered in java.security. Change has been filed with CCC and is accepted. Webrev: http://cr.openjdk.java.net/~juh/7026347/webrev.03/ CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7026347 Thanks, Jason From weijun.wang at oracle.com Thu Jul 19 23:25:06 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 20 Jul 2012 14:25:06 +0800 Subject: JDK8 Code review request for 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) In-Reply-To: <5008E694.7020009@oracle.com> References: <5008E694.7020009@oracle.com> Message-ID: <5008F9C2.7000606@oracle.com> Hi Jason The existing verify(PublicKey key, String sigProvider) method caches the result and returns it if the same key and sigProvider is used. Is it possible to do the same in your new method? Also, the new method is very similar to the old one. I have no good idea how to reuse the old code but if you find a way that would be very nice. As for the CCC, is it really necessary to add these lines? * Note that the specified * Provider object does not have to be registered in the provider list. * *

This method was added to version 1.8 of the Java Platform * Standard Edition. In order to maintain backwards compatibility with * existing service providers, this method cannot be abstract * and by default throws an UnsupportedOperationException. Thanks Max On 07/20/2012 01:03 PM, Jason Uh wrote: > Hi all, > > Please review my fix for 7026347. > > This change is introduces verify(PublicKey key, Provider sigProvider) > methods for Certificate and X509CRL that allow Providers not registered > in java.security. Change has been filed with CCC and is accepted. > > Webrev: http://cr.openjdk.java.net/~juh/7026347/webrev.03/ > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7026347 > > Thanks, > Jason From xuelei.fan at oracle.com Fri Jul 20 00:20:49 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 20 Jul 2012 15:20:49 +0800 Subject: JDK8 Code review request for 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) In-Reply-To: <5008E694.7020009@oracle.com> References: <5008E694.7020009@oracle.com> Message-ID: <500906D1.3090703@oracle.com> I was wondering, for better compatibility with previous providers, it may be considerable to make use of the existing APIs as the implementation of Certificate.verify(PublicKey key, Provider sigProvider): public void verify(PublicKey key, Provider sigProvider) throws CertificateException, NoSuchAlgorithmException, InvalidKeyException, SignatureException { - throw new UnsupportedOperationException(); + verify(key, sigProvider.getName()); } As may simplify both the spec and implementation. Xuelei On 7/20/2012 1:03 PM, Jason Uh wrote: > Hi all, > > Please review my fix for 7026347. > > This change is introduces verify(PublicKey key, Provider sigProvider) > methods for Certificate and X509CRL that allow Providers not registered > in java.security. Change has been filed with CCC and is accepted. > > Webrev: http://cr.openjdk.java.net/~juh/7026347/webrev.03/ > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7026347 > > Thanks, > Jason From stephen.flores at oracle.com Fri Jul 20 13:18:20 2012 From: stephen.flores at oracle.com (Stephen Flores) Date: Fri, 20 Jul 2012 16:18:20 -0400 Subject: 6995421: Eliminate the static dependency to sun.security.ec.ECKeyFactory Message-ID: <5009BD0C.4000008@oracle.com> Please review the following webrev: http://cr.openjdk.java.net/~sflores/6995421/ for bug: 6995421 Eliminate the static dependency to sun.security.ec.ECKeyFactory Description of the problem: sun.security.x509.AlgorithmId and sun.security.pkcs11.P11ECKeyFactory depend on an public static fields sun.security.ec.ECKeyFactory Also, while debuging I found that ECPublicKeyImpl did not check for missing domain parameters while parsing a key, the way ECPrivateKeyImpl does. Evaluation: At the time of development of AlgorithmId there was no public provider for EC Key Factory, a public provider has been added since. Description of fix: Since code in sun.security.x509.AlgorithmId the used the provider in ECKeyFactory was removed since the call to the public API now provides EC AlgorithmParameters. sun.security.pkcs11.P11ECKeyFactory was changed to use public KeyFactory API to get a key factory. Additional changes: A null check of the alorithm parameters was added to ECPublicKey.parseKeyBits. The internal provider in ECKeyFactory has been removed and it entries move to the SunEC provider class and any references to it have been changed to use the public provider API. Changed the TestEC to the the public API to get the SunEC provider the way applications would. The PKCS11 test methods that are shared TestEC were changed not to delete the provider given to them, which did not matter in the past since internal provider in ECKeyFactory was being used by EC classes. Thanks, Steve. From sean.mullan at oracle.com Fri Jul 20 13:39:37 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Jul 2012 16:39:37 -0400 Subject: JDK8 Code review request for 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) In-Reply-To: <500906D1.3090703@oracle.com> References: <5008E694.7020009@oracle.com> <500906D1.3090703@oracle.com> Message-ID: <5009C209.2000006@oracle.com> On 7/20/12 3:20 AM, Xuelei Fan wrote: > I was wondering, for better compatibility with previous providers, it > may be considerable to make use of the existing APIs as the > implementation of Certificate.verify(PublicKey key, Provider sigProvider): > > public void verify(PublicKey key, Provider sigProvider) > throws CertificateException, NoSuchAlgorithmException, > InvalidKeyException, SignatureException { > - throw new UnsupportedOperationException(); > + verify(key, sigProvider.getName()); > } > > As may simplify both the spec and implementation. This would mean that the provider would have to be registered, which is violating the current specification (as proposed). --Sean > > Xuelei > > On 7/20/2012 1:03 PM, Jason Uh wrote: >> Hi all, >> >> Please review my fix for 7026347. >> >> This change is introduces verify(PublicKey key, Provider sigProvider) >> methods for Certificate and X509CRL that allow Providers not registered >> in java.security. Change has been filed with CCC and is accepted. >> >> Webrev: http://cr.openjdk.java.net/~juh/7026347/webrev.03/ >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7026347 >> >> Thanks, >> Jason > From sean.mullan at oracle.com Fri Jul 20 13:43:55 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Jul 2012 16:43:55 -0400 Subject: JDK8 Code review request for 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) In-Reply-To: <5008F9C2.7000606@oracle.com> References: <5008E694.7020009@oracle.com> <5008F9C2.7000606@oracle.com> Message-ID: <5009C30B.7060904@oracle.com> On 7/20/12 2:25 AM, Weijun Wang wrote: > Hi Jason > > The existing verify(PublicKey key, String sigProvider) method caches the > result and returns it if the same key and sigProvider is used. Is it > possible to do the same in your new method? > > Also, the new method is very similar to the old one. I have no good idea > how to reuse the old code but if you find a way that would be very nice. > > As for the CCC, is it really necessary to add these lines? > > * Note that the specified > * Provider object does not have to be registered in the provider list. Most of the getInstance methods that take a Provider object include this sentence, so adding this sentence makes the APIs consistent in that regard. > * > *

This method was added to version 1.8 of the Java Platform > * Standard Edition. In order to maintain backwards compatibility with > * existing service providers, this method cannot be abstract > * and by default throws an UnsupportedOperationException. Not critical, but I think it is nice to have this to provide further rationale why the method throws UOE by default, as that may not be apparent. We've done this in other places where we've added non-abstract methods to an abstract class. --Sean > > Thanks > Max > > On 07/20/2012 01:03 PM, Jason Uh wrote: >> Hi all, >> >> Please review my fix for 7026347. >> >> This change is introduces verify(PublicKey key, Provider sigProvider) >> methods for Certificate and X509CRL that allow Providers not registered >> in java.security. Change has been filed with CCC and is accepted. >> >> Webrev: http://cr.openjdk.java.net/~juh/7026347/webrev.03/ >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7026347 >> >> Thanks, >> Jason From sean.mullan at oracle.com Fri Jul 20 13:48:23 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Jul 2012 16:48:23 -0400 Subject: JDK8 Code review request for 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) In-Reply-To: <5008E694.7020009@oracle.com> References: <5008E694.7020009@oracle.com> Message-ID: <5009C417.5090805@oracle.com> Looks good to me. --Sean On 7/20/12 1:03 AM, Jason Uh wrote: > Hi all, > > Please review my fix for 7026347. > > This change is introduces verify(PublicKey key, Provider sigProvider) > methods for Certificate and X509CRL that allow Providers not registered > in java.security. Change has been filed with CCC and is accepted. > > Webrev: http://cr.openjdk.java.net/~juh/7026347/webrev.03/ > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7026347 > > Thanks, > Jason > From weijun.wang at oracle.com Sat Jul 21 05:01:50 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 21 Jul 2012 12:01:50 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120721120238.B496847184@hg.openjdk.java.net> Changeset: 5dc3f32c0d26 Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5dc3f32c0d26 7180907: Jarsigner -verify fails if rsa file used sha-256 with authenticated attributes Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 7e49c6f7507e Author: weijun Date: 2012-07-21 19:56 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e49c6f7507e 7178649: TEST BUG: BadKdc3.java needs improvement to ignore the unlikely but possible timeout Reviewed-by: xuelei ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java From alan.bateman at oracle.com Sun Jul 22 12:33:36 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 22 Jul 2012 19:33:36 +0000 Subject: hg: jdk8/tl/jdk: 6633549: (dc) Include-mode filtering of IPv6 sources does not block datagrams on Linux Message-ID: <20120722193409.01D0F47196@hg.openjdk.java.net> Changeset: 11d5ddc6a6d4 Author: alanb Date: 2012-07-22 20:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11d5ddc6a6d4 6633549: (dc) Include-mode filtering of IPv6 sources does not block datagrams on Linux Reviewed-by: chegar ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c ! src/solaris/native/sun/nio/ch/Net.c ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java From weijun.wang at oracle.com Mon Jul 23 07:24:11 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 23 Jul 2012 22:24:11 +0800 Subject: very simple code review request: 7179796: GSSExceptionImpl outputs duplicate mech oid In-Reply-To: <25040278.1343053268200.JavaMail.sbladm@swsblss4-new.central.sun.com> References: <25040278.1343053268200.JavaMail.sbladm@swsblss4-new.central.sun.com> Message-ID: <500D5E8B.2020307@oracle.com> Hi All Please take a look at GSSExceptionImpl outputs duplicate mech oid The mechOid info is duplicated in the output. Thanks Max -------- Original Message -------- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179796 7179796: GSSExceptionImpl outputs duplicate mech oid === *Description* ============================================================ FULL PRODUCT VERSION : java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b05) Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) ADDITIONAL OS VERSION INFORMATION : Microsoft Windows XP [Version 5.1.2600] A DESCRIPTION OF THE PROBLEM : I have created a SPNEGO security context and except appropriate tokens. Though the client sent me a Kerberos 5 token which of course will be rejected. GssContext#acceptSecContext throws an exception with following message: > GSSException: No credential found for: 1.2.840.113554.1.2.21.2.840.113554.1.2.2 usage: Accept The mech is printed TWICE. It should be: GSSException: No credential found for: 1.2.840.113554.1.2.2 usage: Accept This bug can be easily fixed in JDK 6 and 7 by editing: sun.security.jgss.GSSCredentialImpl Changing throw new GSSExceptionImpl(GSSException.NO_CRED, "No credential found for: " + mechOid + getElementStr(mechOid, initiate? INITIATE_ONLY : ACCEPT_ONLY)); to throw new GSSExceptionImpl(GSSException.NO_CRED, "No credential found for: " + getElementStr(mechOid, initiate? INITIATE_ONLY : ACCEPT_ONLY)); REPRODUCIBILITY : This bug can be reproduced always. From valerie.peng at oracle.com Mon Jul 23 15:23:13 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 23 Jul 2012 15:23:13 -0700 Subject: very simple code review request: 7179796: GSSExceptionImpl outputs duplicate mech oid In-Reply-To: <500D5E8B.2020307@oracle.com> References: <25040278.1343053268200.JavaMail.sbladm@swsblss4-new.central.sun.com> <500D5E8B.2020307@oracle.com> Message-ID: <500DCED1.30102@oracle.com> Looks good to me. BTW, if no regression test added or not caught by existing test, please make a note to the bug report w/ the appropriate keyword. Thanks, Valerie On 07/23/12 07:24, Weijun Wang wrote: > Hi All > > Please take a look at > > GSSExceptionImpl outputs duplicate mech oid > > The mechOid info is duplicated in the output. > > Thanks > Max > > > -------- Original Message -------- > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7179796 > 7179796: GSSExceptionImpl outputs duplicate mech oid > > === *Description* > ============================================================ > FULL PRODUCT VERSION : > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b05) > Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) > > ADDITIONAL OS VERSION INFORMATION : > Microsoft Windows XP [Version 5.1.2600] > > A DESCRIPTION OF THE PROBLEM : > I have created a SPNEGO security context and except appropriate > tokens. Though the client sent me a Kerberos 5 token which of course > will be rejected. GssContext#acceptSecContext throws an exception with > following message: > >> GSSException: No credential found for: >> 1.2.840.113554.1.2.21.2.840.113554.1.2.2 usage: Accept > > The mech is printed TWICE. > > It should be: > GSSException: No credential found for: 1.2.840.113554.1.2.2 usage: Accept > > This bug can be easily fixed in JDK 6 and 7 by editing: > sun.security.jgss.GSSCredentialImpl > > Changing throw new GSSExceptionImpl(GSSException.NO_CRED, > "No credential found for: " + > mechOid + getElementStr(mechOid, > initiate? INITIATE_ONLY : > ACCEPT_ONLY)); > > to throw new GSSExceptionImpl(GSSException.NO_CRED, > "No credential found for: " + > getElementStr(mechOid, > initiate? INITIATE_ONLY : > ACCEPT_ONLY)); > > > REPRODUCIBILITY : > This bug can be reproduced always. > From xuelei.fan at oracle.com Mon Jul 23 18:21:12 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 24 Jul 2012 09:21:12 +0800 Subject: Code review request, 7185576 Need to consider the connection timeout at test/com/sun/jndi/ldap/InvalidLdapFilters.java Message-ID: <500DF888.50608@oracle.com> webrve: http://cr.openjdk.java.net./~xuelei/7185576/webrev.00/ Thanks, Xuelei From weijun.wang at oracle.com Mon Jul 23 18:21:12 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 24 Jul 2012 01:21:12 +0000 Subject: hg: jdk8/tl/jdk: 7179796: GSSExceptionImpl outputs duplicate mech oid Message-ID: <20120724012131.8E1BA471C2@hg.openjdk.java.net> Changeset: f7731fc8c98a Author: weijun Date: 2012-07-24 09:20 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7731fc8c98a 7179796: GSSExceptionImpl outputs duplicate mech oid Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java From neil.richards at ngmr.net Mon Jul 23 21:13:45 2012 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 24 Jul 2012 05:13:45 +0100 Subject: Code review request: 6733443: JCA/JCE init does not completely reset the delayed provider selection mechanism. Message-ID: <1343103225.26375.66.camel@chalkhill> Hi all, The PKCS11 documentation [1] describes how the selection of a security provider implementation is (re-)performed each time any initialization (init*) method is called on objects of the classes: * javax.crypto.Cipher * javax.crypto.KeyAgreement * javax.crypto.Mac * java.security.Signature so that a suitable implementation is chosen for the Key object given to these initialization methods. This behaviour, whose description was introduced in Java 5, is entirely sensible (from a user's point of view), I think. However, the (Sun/Oracle/OpenJDK) implementation was not modified to actually implement the described behaviour. Java bug 6733443 was raised to report the discrepancy [2]. I have created a webrev [3] with suggested changes to make the implementation conform to the described behaviour. It also holds a testcase for the change, which has a bespoke (minimally implemented) test-specific Provider implementation and associated classes. These implementations contain function just sufficient for the tests' needs, to support things to the point of initialization. All other functions are stubbed out. Also, the (invocation of the) tests for Cipher, KeyAgreement & Mac are currently commented out, as they will only work when the provider is held in a signed jar file, and I wasn't sure how to accomplish that in a jtreg test. However, I have successfully run all these tests using versions of the Cipher, KeyAgreement & Mac classes which have been mildly hacked to remove their check to JceSecurity.canUseProvider() in chooseProvider(). Please review the suggested fix and let me your thoughts on it. Thanks, Neil [1] http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html#DelayedSelect [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6733443 [3] http://cr.openjdk.java.net/~ngmr/6733443/webrev.00/ -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From vincent.x.ryan at oracle.com Tue Jul 24 02:15:13 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 24 Jul 2012 10:15:13 +0100 Subject: Code review request, 7185576 Need to consider the connection timeout at test/com/sun/jndi/ldap/InvalidLdapFilters.java In-Reply-To: <500DF888.50608@oracle.com> References: <500DF888.50608@oracle.com> Message-ID: <500E67A1.6000900@oracle.com> Your fix looks good. Thanks. On 24/07/2012 02:21, Xuelei Fan wrote: > webrve: http://cr.openjdk.java.net./~xuelei/7185576/webrev.00/ > > Thanks, > Xuelei From xuelei.fan at oracle.com Tue Jul 24 03:33:00 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 24 Jul 2012 10:33:00 +0000 Subject: hg: jdk8/tl/jdk: 7185576: Need to consider the connection timeout at test/com/sun/jndi/ldap/InvalidLdapFilters.java Message-ID: <20120724103329.95ACC471D1@hg.openjdk.java.net> Changeset: e0e7cc711bda Author: xuelei Date: 2012-07-24 03:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0e7cc711bda 7185576: Need to consider the connection timeout at test/com/sun/jndi/ldap/InvalidLdapFilters.java Reviewed-by: vinnie ! test/com/sun/jndi/ldap/InvalidLdapFilters.java From xueming.shen at oracle.com Tue Jul 24 12:16:28 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 24 Jul 2012 19:16:28 +0000 Subject: hg: jdk8/tl/jdk: 6653797: Reimplement JDK charset repository charsets.jar Message-ID: <20120724191654.CB822471DA@hg.openjdk.java.net> Changeset: a18f2806bef2 Author: sherman Date: 2012-07-24 12:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a18f2806bef2 6653797: Reimplement JDK charset repository charsets.jar Summary: Migrated all jis based charsets to new implementation Reviewed-by: okutsu ! make/java/nio/FILES_java.gmk ! make/java/sun_nio/FILES_java.gmk ! make/sun/nio/cs/FILES_java.gmk ! make/tools/CharsetMapping/DoubleByte-X.java.template + make/tools/CharsetMapping/JIS_X_0201.c2b ! make/tools/CharsetMapping/JIS_X_0201.map + make/tools/CharsetMapping/JIS_X_0208.map + make/tools/CharsetMapping/JIS_X_0208_MS5022X.c2b + make/tools/CharsetMapping/JIS_X_0208_MS5022X.map + make/tools/CharsetMapping/JIS_X_0208_MS932.map + make/tools/CharsetMapping/JIS_X_0208_MS932.nr + make/tools/CharsetMapping/JIS_X_0208_Solaris.map + make/tools/CharsetMapping/JIS_X_0208_Solaris.nr + make/tools/CharsetMapping/JIS_X_0212.map + make/tools/CharsetMapping/JIS_X_0212_MS5022X.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.map + make/tools/CharsetMapping/JIS_X_0212_Solaris.nr + make/tools/CharsetMapping/PCK.c2b + make/tools/CharsetMapping/PCK.map + make/tools/CharsetMapping/PCK.nr + make/tools/CharsetMapping/SJIS.c2b + make/tools/CharsetMapping/SJIS.map ! make/tools/CharsetMapping/dbcs ! make/tools/CharsetMapping/extsbcs ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! src/share/classes/sun/nio/cs/SingleByte.java - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/IBM834.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java ! src/share/classes/sun/nio/cs/ext/MS50220.java ! src/share/classes/sun/nio/cs/ext/MS50221.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java ! src/solaris/classes/sun/awt/motif/X11JIS0201.java ! src/solaris/classes/sun/awt/motif/X11JIS0208.java ! src/solaris/classes/sun/awt/motif/X11JIS0212.java ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/sun/nio/cs/OLD/DoubleByteDecoder.java ! test/sun/nio/cs/OLD/DoubleByteEncoder.java + test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java + test/sun/nio/cs/OLD/EUC_JP_OLD.java + test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java + test/sun/nio/cs/OLD/JIS_X_0201_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0208_OLD.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java + test/sun/nio/cs/OLD/JIS_X_0212_OLD.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java + test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/OLD/MS932_OLD.java + test/sun/nio/cs/OLD/PCK_OLD.java + test/sun/nio/cs/OLD/SJIS_OLD.java + test/sun/nio/cs/OLD/SingleByteDecoder.java + test/sun/nio/cs/OLD/SingleByteEncoder.java ! test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/TestX11JIS0201.java From kurchi.subhra.hazra at oracle.com Tue Jul 24 13:39:49 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Tue, 24 Jul 2012 20:39:49 +0000 Subject: hg: jdk8/tl/jdk: 7184287: (prefs) BackingStoreException when calling flush on root node[macosx] Message-ID: <20120724204017.C5C5B471E2@hg.openjdk.java.net> Changeset: 74ceda3a98a0 Author: khazra Date: 2012-07-24 13:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74ceda3a98a0 7184287: (prefs) BackingStoreException when calling flush on root node[macosx] Summary: Change implementation to enable user without administrative privileges to call flush Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! test/ProblemList.txt From vincent.x.ryan at oracle.com Wed Jul 25 08:22:23 2012 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 25 Jul 2012 16:22:23 +0100 Subject: 6995421: Eliminate the static dependency to sun.security.ec.ECKeyFactory In-Reply-To: <5009BD0C.4000008@oracle.com> References: <5009BD0C.4000008@oracle.com> Message-ID: <50100F2F.6030408@oracle.com> Hello Stephen, Your changes look good. Thanks. On 20/07/2012 21:18, Stephen Flores wrote: > Please review the following webrev: > > http://cr.openjdk.java.net/~sflores/6995421/ > > for bug: 6995421 Eliminate the static dependency to > sun.security.ec.ECKeyFactory > > Description of the problem: > > sun.security.x509.AlgorithmId and sun.security.pkcs11.P11ECKeyFactory > depend on an public static fields sun.security.ec.ECKeyFactory > > Also, while debuging I found that ECPublicKeyImpl did not check for > missing domain parameters while parsing a key, the way ECPrivateKeyImpl > does. > > Evaluation: > > At the time of development of AlgorithmId there was no public provider > for EC Key Factory, a public provider has been added since. > > Description of fix: > > Since code in sun.security.x509.AlgorithmId the used the provider in > ECKeyFactory was removed since the call to the public API now provides > EC AlgorithmParameters. > > sun.security.pkcs11.P11ECKeyFactory was changed to use public KeyFactory > API to get a key factory. > > Additional changes: > > A null check of the alorithm parameters was added to > ECPublicKey.parseKeyBits. > > The internal provider in ECKeyFactory has been removed and it entries > move to the SunEC provider class and any references to it have been > changed to use the public provider API. > > Changed the TestEC to the the public API to get the SunEC provider the > way applications would. > > The PKCS11 test methods that are shared TestEC were changed not to > delete the provider given to them, which did not matter in the past > since internal provider in ECKeyFactory was being used by EC classes. > > Thanks, > > Steve. From xueming.shen at oracle.com Wed Jul 25 12:45:42 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 25 Jul 2012 19:45:42 +0000 Subject: hg: jdk8/tl/jdk: 7186829: test/sun/nio/cs/OLD/JIS_X_0201_OLD.java failed in jdk8 TL nightly build Message-ID: <20120725194553.03F5E471FD@hg.openjdk.java.net> Changeset: 42eac77355d2 Author: sherman Date: 2012-07-25 12:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42eac77355d2 7186829: test/sun/nio/cs/OLD/JIS_X_0201_OLD.java failed in jdk8 TL nightly build Summary: fixed the test case Reviewed-by: alanb ! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java From valerie.peng at oracle.com Wed Jul 25 17:21:53 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 25 Jul 2012 17:21:53 -0700 Subject: Code Review Request for 7107613, 7107616, 7185471 Message-ID: <50108DA1.9060200@oracle.com> Hi, Max or Xuelei, Either of you have cycles to review the following 3 perf related fixes? 7107613: scalability bloker in javax.crypto.CryptoPermissions 7107616: scalability bloker in javax.crypto.JceSecurityManager 7185471: Avoid key expansion when AES cipher is re-init w/ the same key Webrevs are at: http://cr.openjdk.java.net/~valeriep/7107613 http://cr.openjdk.java.net/~valeriep/7107616 http://cr.openjdk.java.net/~valeriep/7185471 The changes are for JDK 8. May be backported to 7u later if necessary, Thanks, Valerie From weijun.wang at oracle.com Wed Jul 25 18:29:35 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 26 Jul 2012 09:29:35 +0800 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <50108DA1.9060200@oracle.com> References: <50108DA1.9060200@oracle.com> Message-ID: <50109D7F.5000001@oracle.com> On 07/26/2012 08:21 AM, Valerie (Yu-Ching) Peng wrote: > Hi, Max or Xuelei, > > Either of you have cycles to review the following 3 perf related fixes? > 7107613: scalability bloker in javax.crypto.CryptoPermissions > 7107616: scalability bloker in javax.crypto.JceSecurityManager > 7185471: Avoid key expansion when AES cipher is re-init w/ the same key > > Webrevs are at: > http://cr.openjdk.java.net/~valeriep/7107613 Looks fine. > http://cr.openjdk.java.net/~valeriep/7107616 You have 122 CryptoPermissions appPerms = exemptCache.get(callerCodeBase); 123 // Found result in cache 124 if (appPerms != null) { 125 if (appPerms == CACHE_NULL_MARK) appPerms = null; 126 } else { 127 synchronized (this.getClass()) { 128 appPerms = getAppPermissions(callerCodeBase); 129 exemptCache.putIfAbsent(callerCodeBase, 130 (appPerms == null? CACHE_NULL_MARK:appPerms)); 131 } 132 } This is not as optimized as before, that there is a chance getAppPermissions could be called twice, and this seems to make the synchronized block not worth syncing. > http://cr.openjdk.java.net/~valeriep/7185471 I haven't looked at this yet. Seems a lot of math there. Thanks Max > > The changes are for JDK 8. May be backported to 7u later if necessary, > Thanks, > Valerie From sean.coffey at oracle.com Wed Jul 25 18:49:39 2012 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Wed, 25 Jul 2012 18:49:39 -0700 Subject: RFR for CR 7179879 : SSLSocket connect times out instead of throwing socket closed exception Message-ID: <5010A233.4060200@oracle.com> Requesting a review for the following issue : http://bugs.sun.com/view_bug.do?bug_id=7179879 The SSLSocketImpl doesn't appear to handle the case where a connect operation is cancelled before an SSL session has begun (we simple ignore such a case) Fix would be to honour the close call which interrupts the connect request and close out the socket with the appropriate socket closed exception. webrev : http://cr.openjdk.java.net/~coffeys/webrev.7179879.jdk8/ I've run the testcase manually and verified the fix. I've attempted to automate the testcase but had issue in getting an SSLServerSocket to not over eagerly accept a client socket connect request (client connect succeeding even before server code makes an accept call) Regards, Sean. From weijun.wang at oracle.com Wed Jul 25 19:15:20 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 26 Jul 2012 10:15:20 +0800 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <50108DA1.9060200@oracle.com> References: <50108DA1.9060200@oracle.com> Message-ID: <5010A838.9000305@oracle.com> On 07/26/2012 08:21 AM, Valerie (Yu-Ching) Peng wrote: > Hi, Max or Xuelei, > > Either of you have cycles to review the following 3 perf related fixes? > 7107613: scalability bloker in javax.crypto.CryptoPermissions > 7107616: scalability bloker in javax.crypto.JceSecurityManager > 7185471: Avoid key expansion when AES cipher is re-init w/ the same key > > Webrevs are at: > http://cr.openjdk.java.net/~valeriep/7107613 > http://cr.openjdk.java.net/~valeriep/7107616 Already sent in another mail. > http://cr.openjdk.java.net/~valeriep/7185471 Looks fine, but I want to confirm if my understanding is correct: 1. I guess ROUNDS being 10, 12 and 14 means keysize of of 128, 192, 256? 2. The original code has confused ROUNDS and key length a little, so the line 57 /** (ROUNDS-1) * 4 */ was incorrect. You've fixed this and used different names for them. Thanks Max > > The changes are for JDK 8. May be backported to 7u later if necessary, > Thanks, > Valerie From xuelei.fan at oracle.com Wed Jul 25 19:37:12 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 26 Jul 2012 10:37:12 +0800 Subject: RFR for CR 7179879 : SSLSocket connect times out instead of throwing socket closed exception In-Reply-To: <5010A233.4060200@oracle.com> References: <5010A233.4060200@oracle.com> Message-ID: <5010AD58.504@oracle.com> Looks fine to me. Thanks, Xuelei On 7/26/2012 9:49 AM, Se?n Coffey wrote: > Requesting a review for the following issue : > > http://bugs.sun.com/view_bug.do?bug_id=7179879 > > The SSLSocketImpl doesn't appear to handle the case where a connect > operation is cancelled > before an SSL session has begun (we simple ignore such a case) > > Fix would be to honour the close call which interrupts the connect > request and close out the socket with the appropriate socket closed > exception. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7179879.jdk8/ > > > I've run the testcase manually and verified the fix. I've attempted to > automate the testcase but had issue in getting an SSLServerSocket to not > over eagerly accept a client socket connect request (client connect > succeeding even before server code makes an accept call) > > Regards, > Sean. From weijun.wang at oracle.com Thu Jul 26 01:41:10 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 26 Jul 2012 16:41:10 +0800 Subject: Code review request: 7187051: ShortRSAKeynnn.sh tests should do cleanup before start tes In-Reply-To: <5004CF54.7060008@oracle.com> References: <1392965.1342000259989.JavaMail.sbladm@swsblss4-new.central.sun.com> <5003EB85.60606@oracle.com> <5004CF54.7060008@oracle.com> Message-ID: <501102A6.5050203@oracle.com> Hi Xuelei You might have to review the fix to the same test again http://cr.openjdk.java.net/~weijun/7187051/webrev.00/ This time it's 7187051 ShortRSAKeynnn.sh tests should do cleanup before start test Thanks Max On 07/17/2012 10:35 AM, Xuelei Fan wrote: > Looks fine to me. Thanks for addressing this issue. > > Xuelei > > On 7/16/2012 6:23 PM, Weijun Wang wrote: >> Hi Xuelei >> >> The ShortRSAKeyNNN tests have failed several times recently, showing >> strange error messages like "Signature not verified" or "Cannot create >> key" for the keytool command. It might be some internal MSCAPI problem >> but I'm not sure. >> >> Therefore I'm adding a "-debug" option to keytool calls. Also, it looks >> to me these tests are almost identical, so I've consolidated them into >> one. Please take a review: >> >> http://cr.openjdk.java.net/~weijun/7183203/webrev.00/ >> >> Thanks >> Max >> >> >> -------- Original Message -------- >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183203 >> >> 7183203: ShortRSAKeynnn.sh tests intermittent failure >> >> Product: java >> Category: java >> Subcategory: classes_security >> Type: Defect >> >> === *Description* >> ============================================================ >> sun/security/mscapi/ShortRSAKey1024.sh >> sun/security/mscapi/ShortRSAKey768.sh >> sun/security/mscapi/ShortRSAKey512.sh >> >> We are seeing these tests intermittent failure recently. Error is on >> keytool -genkeypair command, sometimes "Bad key" sometimes "Invalid >> signature". >> >> Not sure if it's an MSCAPI problem or multiple tests are modifying >> Windows-MY at the same time. This CR intends to add more debug info and >> combine the tests into one that run consequently. >> > > From xuelei.fan at oracle.com Thu Jul 26 03:36:57 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 26 Jul 2012 18:36:57 +0800 Subject: Code review request: 7187051: ShortRSAKeynnn.sh tests should do cleanup before start tes In-Reply-To: <501102A6.5050203@oracle.com> References: <1392965.1342000259989.JavaMail.sbladm@swsblss4-new.central.sun.com> <5003EB85.60606@oracle.com> <5004CF54.7060008@oracle.com> <501102A6.5050203@oracle.com> Message-ID: <50111DC9.4000606@oracle.com> Looks fine to me. Xuelei On 7/26/2012 4:41 PM, Weijun Wang wrote: > Hi Xuelei > > You might have to review the fix to the same test again > > http://cr.openjdk.java.net/~weijun/7187051/webrev.00/ > > This time it's > > 7187051 ShortRSAKeynnn.sh tests should do cleanup before start test > > Thanks > Max > > On 07/17/2012 10:35 AM, Xuelei Fan wrote: >> Looks fine to me. Thanks for addressing this issue. >> >> Xuelei >> >> On 7/16/2012 6:23 PM, Weijun Wang wrote: >>> Hi Xuelei >>> >>> The ShortRSAKeyNNN tests have failed several times recently, showing >>> strange error messages like "Signature not verified" or "Cannot create >>> key" for the keytool command. It might be some internal MSCAPI problem >>> but I'm not sure. >>> >>> Therefore I'm adding a "-debug" option to keytool calls. Also, it looks >>> to me these tests are almost identical, so I've consolidated them into >>> one. Please take a review: >>> >>> http://cr.openjdk.java.net/~weijun/7183203/webrev.00/ >>> >>> Thanks >>> Max >>> >>> >>> -------- Original Message -------- >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183203 >>> >>> 7183203: ShortRSAKeynnn.sh tests intermittent failure >>> >>> Product: java >>> Category: java >>> Subcategory: classes_security >>> Type: Defect >>> >>> === *Description* >>> ============================================================ >>> sun/security/mscapi/ShortRSAKey1024.sh >>> sun/security/mscapi/ShortRSAKey768.sh >>> sun/security/mscapi/ShortRSAKey512.sh >>> >>> We are seeing these tests intermittent failure recently. Error is on >>> keytool -genkeypair command, sometimes "Bad key" sometimes "Invalid >>> signature". >>> >>> Not sure if it's an MSCAPI problem or multiple tests are modifying >>> Windows-MY at the same time. This CR intends to add more debug info and >>> combine the tests into one that run consequently. >>> >> >> From weijun.wang at oracle.com Thu Jul 26 05:39:08 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 26 Jul 2012 12:39:08 +0000 Subject: hg: jdk8/tl/jdk: 7187051: ShortRSAKeynnn.sh tests should do cleanup before start test Message-ID: <20120726123938.886A64721A@hg.openjdk.java.net> Changeset: f267302093d4 Author: weijun Date: 2012-07-26 20:38 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f267302093d4 7187051: ShortRSAKeynnn.sh tests should do cleanup before start test Reviewed-by: xuelei ! test/sun/security/mscapi/ShortRSAKey1024.sh From xuelei.fan at oracle.com Thu Jul 26 05:54:52 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 26 Jul 2012 20:54:52 +0800 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <50108DA1.9060200@oracle.com> References: <50108DA1.9060200@oracle.com> Message-ID: <50113E1C.9070303@oracle.com> On 7/26/2012 8:21 AM, Valerie (Yu-Ching) Peng wrote: > Hi, Max or Xuelei, > > Either of you have cycles to review the following 3 perf related fixes? > 7107613: scalability bloker in javax.crypto.CryptoPermissions > 7107616: scalability bloker in javax.crypto.JceSecurityManager > 7185471: Avoid key expansion when AES cipher is re-init w/ the same key > > Webrevs are at: > http://cr.openjdk.java.net/~valeriep/7107613 In this update, the filed "perms" was declared as transient: ---------- - private Hashtable perms; + private transient ConcurrentHashMap perms; ---------- The ObjectOutputStream.PutField and ObjectInputStream.GetField will call: ---------- + Hashtable permTable = + (Hashtable) (fields.get("perms", null)); + Hashtable permTable = + (Hashtable) (fields.get("perms", null)); ---------- As will try to get the field offset of "perms" from the instance of this class, CryptoPermissions. Because "perms" has been declared as transient, a exception is properly thrown, java.lang.IllegalArgumentException: no such field perms with type class java.lang.Object I think we may need to override the "serialPersistentFields" of ObjectStreamField, as [1][2]: + private static final ObjectStreamField[] serialPersistentFields = { + new ObjectStreamField("perms", Hashtable.class), + }; + + private void readObject(ObjectInputStream s) + throws IOException, ClassNotFoundException { + ... Alternatively, I was wondering maybe we reserver the hashtable variable, "perms", and add a new transient ConcurrentHashMap variable, "transientPerms": ------------------ private Hashtable perms; + private transient + ConcurrentHashMap transientPerms; ------------------ Then we will not need to override the serialPersistentFields variable any more. The readObject and writeObject looks like: ------------------ + private void readObject(ObjectInputStream s) + throws IOException, ClassNotFoundException { + + s.defaultReadObject(); + transientPerms = new ConcurrentHashMap<>(perms); + perms = null; + } + + private void writeObject(ObjectOutputStream s) throws IOException { + perms = new Hashtable<>(transientPerms); + s.defaultWriteObject(); + perms = null; + } ------------------ Xuelei [1] http://docs.oracle.com/javase/6/docs/platform/serialization/spec/input.html#4936 [2] http://docs.oracle.com/javase/6/docs/platform/serialization/spec/class.html#3127 > http://cr.openjdk.java.net/~valeriep/7107616 > http://cr.openjdk.java.net/~valeriep/7185471 > > The changes are for JDK 8. May be backported to 7u later if necessary, > Thanks, > Valerie From valerie.peng at oracle.com Thu Jul 26 11:31:04 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 26 Jul 2012 11:31:04 -0700 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <5010A838.9000305@oracle.com> References: <50108DA1.9060200@oracle.com> <5010A838.9000305@oracle.com> Message-ID: <50118CE8.8070703@oracle.com> Yes, I find the definition for rounds seems inconsistent in the original code, so I did a little clean up. Valerie On 07/25/12 19:15, Weijun Wang wrote: >> http://cr.openjdk.java.net/~valeriep/7185471 > > Looks fine, but I want to confirm if my understanding is correct: > > 1. I guess ROUNDS being 10, 12 and 14 means keysize of of 128, 192, 256? > > 2. The original code has confused ROUNDS and key length a little, so > the line > > 57 /** (ROUNDS-1) * 4 */ > > was incorrect. You've fixed this and used different names for them. > > Thanks > Max > > >> >> The changes are for JDK 8. May be backported to 7u later if necessary, >> Thanks, >> Valerie From valerie.peng at oracle.com Thu Jul 26 11:46:01 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 26 Jul 2012 11:46:01 -0700 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <50113E1C.9070303@oracle.com> References: <50108DA1.9060200@oracle.com> <50113E1C.9070303@oracle.com> Message-ID: <50119069.3000009@oracle.com> Xuelei, I pondered with the "preserving the Vector 'perms' and add a new transient ConcurrentHashMap 'permsMap'" idea in one of my previous changes. Felt that it's cleaner to only have one assuming no lengthy/complicated custom serialization methods needed. I will look at the ObjectOutputStream.* aspect some more to see how to properly address this. Thanks for the good catch! Valerie On 07/26/12 05:54, Xuelei Fan wrote: > On 7/26/2012 8:21 AM, Valerie (Yu-Ching) Peng wrote: >> Hi, Max or Xuelei, >> >> Either of you have cycles to review the following 3 perf related fixes? >> 7107613: scalability bloker in javax.crypto.CryptoPermissions >> 7107616: scalability bloker in javax.crypto.JceSecurityManager >> 7185471: Avoid key expansion when AES cipher is re-init w/ the same key >> >> Webrevs are at: >> http://cr.openjdk.java.net/~valeriep/7107613 > In this update, the filed "perms" was declared as transient: > ---------- > - private Hashtable perms; > + private transient ConcurrentHashMap perms; > ---------- > > The ObjectOutputStream.PutField and ObjectInputStream.GetField will call: > ---------- > + Hashtable permTable = > + (Hashtable) > (fields.get("perms", null)); > > + Hashtable permTable = > + (Hashtable) > (fields.get("perms", null)); > ---------- > > As will try to get the field offset of "perms" from the instance of this > class, CryptoPermissions. Because "perms" has been declared as > transient, a exception is properly thrown, > java.lang.IllegalArgumentException: no such field perms with type class > java.lang.Object > > I think we may need to override the "serialPersistentFields" of > ObjectStreamField, as [1][2]: > > + private static final ObjectStreamField[] serialPersistentFields = { > + new ObjectStreamField("perms", Hashtable.class), > + }; > + > + private void readObject(ObjectInputStream s) > + throws IOException, ClassNotFoundException { > + ... > > > > > Alternatively, I was wondering maybe we reserver the hashtable variable, > "perms", and add a new transient ConcurrentHashMap variable, > "transientPerms": > ------------------ > private Hashtable perms; > + private transient > + ConcurrentHashMap transientPerms; > ------------------ > > Then we will not need to override the serialPersistentFields variable > any more. The readObject and writeObject looks like: > ------------------ > + private void readObject(ObjectInputStream s) > + throws IOException, ClassNotFoundException { > + > + s.defaultReadObject(); > + transientPerms = new ConcurrentHashMap<>(perms); > + perms = null; > + } > + > + private void writeObject(ObjectOutputStream s) throws IOException { > + perms = new Hashtable<>(transientPerms); > + s.defaultWriteObject(); > + perms = null; > + } > ------------------ > > > Xuelei > > [1] > http://docs.oracle.com/javase/6/docs/platform/serialization/spec/input.html#4936 > [2] > http://docs.oracle.com/javase/6/docs/platform/serialization/spec/class.html#3127 > >> http://cr.openjdk.java.net/~valeriep/7107616 >> http://cr.openjdk.java.net/~valeriep/7185471 >> >> The changes are for JDK 8. May be backported to 7u later if necessary, >> Thanks, >> Valerie From chris.hegarty at oracle.com Thu Jul 26 12:11:01 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 Jul 2012 12:11:01 -0700 Subject: RFR for CR 7179879 : SSLSocket connect times out instead of throwing socket closed exception In-Reply-To: <5010AD58.504@oracle.com> References: <5010A233.4060200@oracle.com> <5010AD58.504@oracle.com> Message-ID: <50119645.30406@oracle.com> On 25/07/12 19:37, Xuelei Fan wrote: > Looks fine to me. Looks fine to me too. -Chris. > > Thanks, > Xuelei > > On 7/26/2012 9:49 AM, Se?n Coffey wrote: >> Requesting a review for the following issue : >> >> http://bugs.sun.com/view_bug.do?bug_id=7179879 >> >> The SSLSocketImpl doesn't appear to handle the case where a connect >> operation is cancelled >> before an SSL session has begun (we simple ignore such a case) >> >> Fix would be to honour the close call which interrupts the connect >> request and close out the socket with the appropriate socket closed >> exception. >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7179879.jdk8/ >> >> >> I've run the testcase manually and verified the fix. I've attempted to >> automate the testcase but had issue in getting an SSLServerSocket to not >> over eagerly accept a client socket connect request (client connect >> succeeding even before server code makes an accept call) >> >> Regards, >> Sean. > From sean.coffey at oracle.com Thu Jul 26 13:58:35 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 26 Jul 2012 20:58:35 +0000 Subject: hg: jdk8/tl/jdk: 7179879: SSLSocket connect times out instead of throwing socket closed exception Message-ID: <20120726205857.A53094722F@hg.openjdk.java.net> Changeset: 35fec642fd32 Author: coffeys Date: 2012-07-26 22:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35fec642fd32 7179879: SSLSocket connect times out instead of throwing socket closed exception Reviewed-by: xuelei, chegar ! src/share/classes/sun/security/ssl/SSLSocketImpl.java From valerie.peng at oracle.com Thu Jul 26 16:26:41 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 26 Jul 2012 16:26:41 -0700 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <50109D7F.5000001@oracle.com> References: <50108DA1.9060200@oracle.com> <50109D7F.5000001@oracle.com> Message-ID: <5011D231.6000708@oracle.com> Max, So, do you want me to check the exemptCache again, i.e. what line 122- 125 do, inside the synchronized block before calling getAppPermissions(...)? Thanks, Valerie On 07/25/12 18:29, Weijun Wang wrote: >> http://cr.openjdk.java.net/~valeriep/7107616 > > You have > > 122 CryptoPermissions appPerms = > exemptCache.get(callerCodeBase); > 123 // Found result in cache > 124 if (appPerms != null) { > 125 if (appPerms == CACHE_NULL_MARK) appPerms = null; > 126 } else { > 127 synchronized (this.getClass()) { > 128 appPerms = getAppPermissions(callerCodeBase); > 129 exemptCache.putIfAbsent(callerCodeBase, > 130 (appPerms == null? CACHE_NULL_MARK:appPerms)); > 131 } > 132 } > > This is not as optimized as before, that there is a chance > getAppPermissions could be called twice, and this seems to make the > synchronized block not worth syncing. > >> http://cr.openjdk.java.net/~valeriep/7185471 > > I haven't looked at this yet. Seems a lot of math there. > > Thanks > Max > >> >> The changes are for JDK 8. May be backported to 7u later if necessary, >> Thanks, >> Valerie From weijun.wang at oracle.com Thu Jul 26 16:35:24 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 27 Jul 2012 07:35:24 +0800 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <5011D231.6000708@oracle.com> References: <50108DA1.9060200@oracle.com> <50109D7F.5000001@oracle.com> <5011D231.6000708@oracle.com> Message-ID: <5011D43C.3010603@oracle.com> On 07/27/2012 07:26 AM, Valerie (Yu-Ching) Peng wrote: > Max, > > So, do you want me to check the exemptCache again, i.e. what line 122- > 125 do, inside the synchronized block before calling > getAppPermissions(...)? Yes, that should work. If you do believe this is a very rare case and you don't mind getAppPermissions() called twice, the synchonized block seems unnecessary. Both getAppPermissions and putIfAbsent should be thread-safe methods. Thanks Max > > Thanks, > Valerie > > On 07/25/12 18:29, Weijun Wang wrote: >>> http://cr.openjdk.java.net/~valeriep/7107616 >> >> You have >> >> 122 CryptoPermissions appPerms = >> exemptCache.get(callerCodeBase); >> 123 // Found result in cache >> 124 if (appPerms != null) { >> 125 if (appPerms == CACHE_NULL_MARK) appPerms = null; >> 126 } else { >> 127 synchronized (this.getClass()) { >> 128 appPerms = getAppPermissions(callerCodeBase); >> 129 exemptCache.putIfAbsent(callerCodeBase, >> 130 (appPerms == null? CACHE_NULL_MARK:appPerms)); >> 131 } >> 132 } >> >> This is not as optimized as before, that there is a chance >> getAppPermissions could be called twice, and this seems to make the >> synchronized block not worth syncing. >> > >>> http://cr.openjdk.java.net/~valeriep/7185471 >> >> I haven't looked at this yet. Seems a lot of math there. >> >> Thanks >> Max >> >>> >>> The changes are for JDK 8. May be backported to 7u later if necessary, >>> Thanks, >>> Valerie > From valerie.peng at oracle.com Thu Jul 26 18:13:57 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 26 Jul 2012 18:13:57 -0700 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <50108DA1.9060200@oracle.com> References: <50108DA1.9060200@oracle.com> Message-ID: <5011EB55.2070509@oracle.com> Thanks Max and Xuelei for your reviews! I've updated the webrevs for 7107613, and 7107616: http://cr.openjdk.java.net/~valeriep/7107613/webrev.01 http://cr.openjdk.java.net/~valeriep/7107616/webrev.01 Please let me know if you have more comments. Thanks, Valerie On 07/25/12 17:21, Valerie (Yu-Ching) Peng wrote: > Hi, Max or Xuelei, > > Either of you have cycles to review the following 3 perf related fixes? > 7107613: scalability bloker in javax.crypto.CryptoPermissions > 7107616: scalability bloker in javax.crypto.JceSecurityManager > 7185471: Avoid key expansion when AES cipher is re-init w/ the same key > > Webrevs are at: > http://cr.openjdk.java.net/~valeriep/7107613 > http://cr.openjdk.java.net/~valeriep/7107616 > http://cr.openjdk.java.net/~valeriep/7185471 > > The changes are for JDK 8. May be backported to 7u later if necessary, > Thanks, > Valerie From xuelei.fan at oracle.com Fri Jul 27 00:39:33 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 27 Jul 2012 15:39:33 +0800 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <5011EB55.2070509@oracle.com> References: <50108DA1.9060200@oracle.com> <5011EB55.2070509@oracle.com> Message-ID: <501245B5.3040208@oracle.com> Both looks fine to me. Thanks, Xuelei On 7/27/2012 9:13 AM, Valerie (Yu-Ching) Peng wrote: > Thanks Max and Xuelei for your reviews! > I've updated the webrevs for 7107613, and 7107616: > > http://cr.openjdk.java.net/~valeriep/7107613/webrev.01 > http://cr.openjdk.java.net/~valeriep/7107616/webrev.01 > > Please let me know if you have more comments. > Thanks, > Valerie > > On 07/25/12 17:21, Valerie (Yu-Ching) Peng wrote: >> Hi, Max or Xuelei, >> >> Either of you have cycles to review the following 3 perf related fixes? >> 7107613: scalability bloker in javax.crypto.CryptoPermissions >> 7107616: scalability bloker in javax.crypto.JceSecurityManager >> 7185471: Avoid key expansion when AES cipher is re-init w/ the same key >> >> Webrevs are at: >> http://cr.openjdk.java.net/~valeriep/7107613 >> http://cr.openjdk.java.net/~valeriep/7107616 >> http://cr.openjdk.java.net/~valeriep/7185471 >> >> The changes are for JDK 8. May be backported to 7u later if necessary, >> Thanks, >> Valerie > From tom.deneau at amd.com Fri Jul 27 08:46:06 2012 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 27 Jul 2012 15:46:06 +0000 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: <5011EB55.2070509@oracle.com> References: <50108DA1.9060200@oracle.com> <5011EB55.2070509@oracle.com> Message-ID: Valerie, Max, Xuelei -- >From one who is not too familiar with the crypto architecture, can you tell me under which provider scenario should we see gains on 7107613 and 7107616? -- Tom -----Original Message----- From: Valerie (Yu-Ching) Peng [mailto:valerie.peng at oracle.com] Sent: Thursday, July 26, 2012 8:14 PM To: valerie.peng at oracle.com Cc: OpenJDK Dev list; Deneau, Tom Subject: Re: Code Review Request for 7107613, 7107616, 7185471 Thanks Max and Xuelei for your reviews! I've updated the webrevs for 7107613, and 7107616: http://cr.openjdk.java.net/~valeriep/7107613/webrev.01 http://cr.openjdk.java.net/~valeriep/7107616/webrev.01 Please let me know if you have more comments. Thanks, Valerie On 07/25/12 17:21, Valerie (Yu-Ching) Peng wrote: > Hi, Max or Xuelei, > > Either of you have cycles to review the following 3 perf related fixes? > 7107613: scalability bloker in javax.crypto.CryptoPermissions > 7107616: scalability bloker in javax.crypto.JceSecurityManager > 7185471: Avoid key expansion when AES cipher is re-init w/ the same key > > Webrevs are at: > http://cr.openjdk.java.net/~valeriep/7107613 > http://cr.openjdk.java.net/~valeriep/7107616 > http://cr.openjdk.java.net/~valeriep/7185471 > > The changes are for JDK 8. May be backported to 7u later if necessary, > Thanks, > Valerie From valerie.peng at oracle.com Fri Jul 27 11:18:06 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 27 Jul 2012 11:18:06 -0700 Subject: Code Review Request for 7107613, 7107616, 7185471 In-Reply-To: References: <50108DA1.9060200@oracle.com> <5011EB55.2070509@oracle.com> Message-ID: <5012DB5E.3090303@oracle.com> The changes in 107613 and 7107616 are related to the JCE framework which means they are applied regardless which provider is used. Valerie On 07/27/12 08:46, Deneau, Tom wrote: > Valerie, Max, Xuelei -- > > From one who is not too familiar with the crypto architecture, > can you tell me under which provider scenario should we see > gains on 7107613 and 7107616? > > -- Tom > > -----Original Message----- > From: Valerie (Yu-Ching) Peng [mailto:valerie.peng at oracle.com] > Sent: Thursday, July 26, 2012 8:14 PM > To: valerie.peng at oracle.com > Cc: OpenJDK Dev list; Deneau, Tom > Subject: Re: Code Review Request for 7107613, 7107616, 7185471 > > Thanks Max and Xuelei for your reviews! > I've updated the webrevs for 7107613, and 7107616: > > http://cr.openjdk.java.net/~valeriep/7107613/webrev.01 > http://cr.openjdk.java.net/~valeriep/7107616/webrev.01 > > Please let me know if you have more comments. > Thanks, > Valerie > > On 07/25/12 17:21, Valerie (Yu-Ching) Peng wrote: >> Hi, Max or Xuelei, >> >> Either of you have cycles to review the following 3 perf related fixes? >> 7107613: scalability bloker in javax.crypto.CryptoPermissions >> 7107616: scalability bloker in javax.crypto.JceSecurityManager >> 7185471: Avoid key expansion when AES cipher is re-init w/ the same key >> >> Webrevs are at: >> http://cr.openjdk.java.net/~valeriep/7107613 >> http://cr.openjdk.java.net/~valeriep/7107616 >> http://cr.openjdk.java.net/~valeriep/7185471 >> >> The changes are for JDK 8. May be backported to 7u later if necessary, >> Thanks, >> Valerie > > From stuart.marks at oracle.com Fri Jul 27 16:53:08 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 27 Jul 2012 23:53:08 +0000 Subject: hg: jdk8/tl/jdk: 7186111: fix bugs in java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup Message-ID: <20120727235332.1EC9D4726A@hg.openjdk.java.net> Changeset: 018e555a7a07 Author: dmocek Date: 2012-07-27 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/018e555a7a07 7186111: fix bugs in java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup Reviewed-by: smarks, jgish ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/group.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy ! test/java/rmi/activation/ActivationSystem/unregisterGroup/security.policy From valerie.peng at oracle.com Fri Jul 27 17:15:59 2012 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 27 Jul 2012 17:15:59 -0700 Subject: Code review request: 6733443: JCA/JCE init does not completely reset the delayed provider selection mechanism. In-Reply-To: <1343103225.26375.66.camel@chalkhill> References: <1343103225.26375.66.camel@chalkhill> Message-ID: <50132F3F.6000509@oracle.com> Neil, Thanks for the feedback, I will take a look and let you know my thoughts sometime next week. Valerie On 07/23/12 21:13, Neil Richards wrote: > Hi all, > > The PKCS11 documentation [1] describes how the selection of a security > provider implementation is (re-)performed each time any initialization > (init*) method is called on objects of the classes: > * javax.crypto.Cipher > * javax.crypto.KeyAgreement > * javax.crypto.Mac > * java.security.Signature > so that a suitable implementation is chosen for the Key object given to > these initialization methods. > > This behaviour, whose description was introduced in Java 5, is entirely > sensible (from a user's point of view), I think. > > However, the (Sun/Oracle/OpenJDK) implementation was not modified to > actually implement the described behaviour. > > Java bug 6733443 was raised to report the discrepancy [2]. > > I have created a webrev [3] with suggested changes to make the > implementation conform to the described behaviour. > > It also holds a testcase for the change, which has a bespoke (minimally > implemented) test-specific Provider implementation and associated > classes. These implementations contain function just sufficient for the > tests' needs, to support things to the point of initialization. All > other functions are stubbed out. > > Also, the (invocation of the) tests for Cipher, KeyAgreement& Mac are > currently commented out, as they will only work when the provider is > held in a signed jar file, and I wasn't sure how to accomplish that in a > jtreg test. > > However, I have successfully run all these tests using versions of the > Cipher, KeyAgreement& Mac classes which have been mildly hacked to > remove their check to JceSecurity.canUseProvider() in chooseProvider(). > > Please review the suggested fix and let me your thoughts on it. > > Thanks, > Neil > > [1]http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html#DelayedSelect > [2]http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6733443 > [3]http://cr.openjdk.java.net/~ngmr/6733443/webrev.00/ > From lana.steuck at oracle.com Fri Jul 27 23:39:01 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 06:39:01 +0000 Subject: hg: jdk8/tl: 6 new changesets Message-ID: <20120728063902.3449547274@hg.openjdk.java.net> Changeset: ba77d95ed219 Author: ohair Date: 2012-07-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ba77d95ed219 7184406: Adjust get_source/hgforest script to allow for trailing // characters Reviewed-by: tbell ! make/scripts/hgforest.sh Changeset: 3f6c72d1c2a6 Author: katleman Date: 2012-07-18 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3f6c72d1c2a6 Merge Changeset: 969c75896558 Author: cl Date: 2012-07-23 12:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/969c75896558 Added tag jdk8-b48 for changeset 3f6c72d1c2a6 ! .hgtags Changeset: 36998bc84cff Author: lana Date: 2012-07-18 16:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/36998bc84cff Merge Changeset: c97b99424815 Author: lana Date: 2012-07-24 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c97b99424815 Merge Changeset: 2fd67618b9a3 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2fd67618b9a3 Added tag jdk8-b49 for changeset c97b99424815 ! .hgtags From lana.steuck at oracle.com Fri Jul 27 23:39:01 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 06:39:01 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20120728063905.0514347275@hg.openjdk.java.net> Changeset: fe44e58a6bdb Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/fe44e58a6bdb Added tag jdk8-b48 for changeset 7e2b179a5b4d ! .hgtags Changeset: d20d9eb9f093 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d20d9eb9f093 Added tag jdk8-b49 for changeset fe44e58a6bdb ! .hgtags From lana.steuck at oracle.com Fri Jul 27 23:39:10 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 06:39:10 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120728063918.95EC947276@hg.openjdk.java.net> Changeset: b48865af8ac5 Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b48865af8ac5 Added tag jdk8-b48 for changeset efb564de8a8e ! .hgtags Changeset: bdab72e87b83 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/bdab72e87b83 Added tag jdk8-b49 for changeset b48865af8ac5 ! .hgtags From lana.steuck at oracle.com Fri Jul 27 23:39:04 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 06:39:04 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20120728063920.533F547277@hg.openjdk.java.net> Changeset: a7e6e1048e4c Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a7e6e1048e4c Added tag jdk8-b48 for changeset 1c88da9a1365 ! .hgtags Changeset: f81e981eca7b Author: lana Date: 2012-07-24 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f81e981eca7b Merge Changeset: 2791ec55f66b Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2791ec55f66b Added tag jdk8-b49 for changeset f81e981eca7b ! .hgtags From lana.steuck at oracle.com Fri Jul 27 23:39:13 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 06:39:13 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20120728063922.5FA4347278@hg.openjdk.java.net> Changeset: 9ee07e5dc0e2 Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9ee07e5dc0e2 Added tag jdk8-b48 for changeset afb0a5231557 ! .hgtags Changeset: c72c164ced67 Author: lana Date: 2012-07-24 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c72c164ced67 Merge Changeset: b2d8a270f5f2 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b2d8a270f5f2 Added tag jdk8-b49 for changeset c72c164ced67 ! .hgtags From lana.steuck at oracle.com Fri Jul 27 23:39:23 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 06:39:23 +0000 Subject: hg: jdk8/tl/hotspot: 18 new changesets Message-ID: <20120728064002.5E56347279@hg.openjdk.java.net> Changeset: bcffa4c5eef6 Author: amurillo Date: 2012-06-29 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bcffa4c5eef6 7180882: new hotspot build - hs24-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3759236eea14 Author: kamg Date: 2012-07-02 10:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3759236eea14 7167142: Consider a warning when finding a .hotspotrc or .hotspot_compiler file that isn't used Summary: Send warnings to output stream Reviewed-by: dholmes, fparain ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d2a62e0f25eb Author: zgu Date: 2012-06-28 17:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d2a62e0f25eb 6995781: Native Memory Tracking (Phase 1) 7151532: DCmd for hotspot native memory tracking Summary: Implementation of native memory tracking phase 1, which tracks VM native memory usage, and related DCmd Reviewed-by: acorn, coleenp, fparain ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! make/bsd/makefiles/jvmg.make ! make/linux/makefiles/jvmg.make ! make/solaris/makefiles/jvmg.make ! make/windows/makefiles/debug.make ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/dtrace/hs_private.d ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/javaAssertions.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/collectorCounters.cpp ! src/share/vm/gc_implementation/shared/collectorCounters.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp ! src/share/vm/gc_implementation/shared/gcStats.hpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/oopMapCache.hpp ! src/share/vm/libadt/set.cpp ! src/share/vm/libadt/vectset.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/generationSpec.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEnvThreadState.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiExtensions.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRawMonitor.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/prims/jvmtiUtil.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/monitorChunk.cpp ! src/share/vm/runtime/monitorChunk.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/unhandledOops.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.cpp ! src/share/vm/runtime/vframe_hp.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticArgument.hpp ! src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/gcNotifier.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/management.cpp + src/share/vm/services/memBaseline.cpp + src/share/vm/services/memBaseline.hpp + src/share/vm/services/memPtr.cpp + src/share/vm/services/memPtr.hpp + src/share/vm/services/memPtrArray.hpp + src/share/vm/services/memRecorder.cpp + src/share/vm/services/memRecorder.hpp + src/share/vm/services/memReporter.cpp + src/share/vm/services/memReporter.hpp + src/share/vm/services/memSnapshot.cpp + src/share/vm/services/memSnapshot.hpp + src/share/vm/services/memTrackWorker.cpp + src/share/vm/services/memTrackWorker.hpp + src/share/vm/services/memTracker.cpp + src/share/vm/services/memTracker.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp + src/share/vm/services/nmtDCmd.cpp + src/share/vm/services/nmtDCmd.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/histogram.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/intHisto.cpp ! src/share/vm/utilities/intHisto.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/stack.hpp ! src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/xmlstream.cpp Changeset: 24b9c7f4cae6 Author: coleenp Date: 2012-07-02 13:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24b9c7f4cae6 Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/memory/universe.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 3f1ab0c19c30 Author: dholmes Date: 2012-07-03 01:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f1ab0c19c30 7179383: MaxDirectMemorySize argument parsing is broken for values >2G Summary: change hotspot flag to be unsigned Reviewed-by: dholmes, sla, fparain, brutisso Contributed-by: Chris Dennis ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 65906dc96aa1 Author: mikael Date: 2012-07-03 17:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65906dc96aa1 7129724: MAC: Core file location is wrong in crash report Summary: Updated core path location to reflect macosx default Reviewed-by: dholmes, kamg ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/runtime/os.hpp Changeset: ace99a6ffc83 Author: coleenp Date: 2012-07-04 15:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ace99a6ffc83 7181200: JVM new hashing code breaks SA in product mode Summary: Made new_hash() overloaded rather than a virtual function so SA code doesn't need to be changed. Reviewed-by: kvn, acorn, dholmes, fparain ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 5a1f452f8f90 Author: sla Date: 2012-06-28 11:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a1f452f8f90 7178703: Fix handling of quoted arguments and better error messages in dcmd Reviewed-by: coleenp, mgronlun, rbackman ! src/share/vm/prims/whitebox.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp ! test/serviceability/ParserTest.java Changeset: 04ade88d9712 Author: fparain Date: 2012-07-09 01:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04ade88d9712 6294277: java -Xdebug crashes on SourceDebugExtension attribute larger than 64K Reviewed-by: sspitsyn, dholmes, coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp + test/runtime/6294277/SourceDebugExtension.java + test/runtime/6294277/Test6294277.sh Changeset: 90d5a592ea8f Author: coleenp Date: 2012-07-12 14:26 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/90d5a592ea8f Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d50605d9417e Author: roland Date: 2012-07-02 09:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d50605d9417e 7177917: Failed test java/lang/Math/PowTests.java Summary: When c2 intrinsifies pow/exp, it should never inline the java implementations. Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp + test/compiler/7177917/Test7177917.java Changeset: 70862d781d01 Author: kvn Date: 2012-07-02 12:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/70862d781d01 7180769: assert(tboth->klass_is_exact()) failed: klass should be exact Summary: Use class exactness as part of the condition for class compare optimization instead of assert. Reviewed-by: twisti, roland ! src/share/vm/opto/parse2.cpp Changeset: ae9241bbce4a Author: kvn Date: 2012-07-11 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae9241bbce4a 7181658: CTW: assert(t->meet(t0) == t) failed: Not monotonic Summary: Use uncast node equivalence checks in CmpUNode::sub. Reviewed-by: kvn, twisti Contributed-by: vladimir.x.ivanov at oracle.com ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp Changeset: cc787232c4c5 Author: kvn Date: 2012-07-12 14:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc787232c4c5 Merge Changeset: 66b0450071c1 Author: amurillo Date: 2012-07-13 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/66b0450071c1 Merge Changeset: 1e26f61bbb52 Author: amurillo Date: 2012-07-13 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e26f61bbb52 Added tag hs24-b16 for changeset 66b0450071c1 ! .hgtags Changeset: e3619706a725 Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3619706a725 Added tag jdk8-b48 for changeset 1e26f61bbb52 ! .hgtags Changeset: ea926f2921d6 Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea926f2921d6 Added tag jdk8-b49 for changeset e3619706a725 ! .hgtags From lana.steuck at oracle.com Fri Jul 27 23:39:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 28 Jul 2012 06:39:51 +0000 Subject: hg: jdk8/tl/jdk: 18 new changesets Message-ID: <20120728064259.5316E4727A@hg.openjdk.java.net> Changeset: 09a79167142c Author: cl Date: 2012-07-23 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09a79167142c Added tag jdk8-b48 for changeset 3e4ab821f461 ! .hgtags Changeset: a18a547546a4 Author: prr Date: 2012-07-12 16:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a18a547546a4 7183458: Metrics of space character in algorithmically emboldened font have changed in JDK 7. Reviewed-by: igor, jgodinez + test/java/awt/FontMetrics/StyledSpaceAdvance.java Changeset: 9f21c95bfbc1 Author: lana Date: 2012-07-16 16:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f21c95bfbc1 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: ab0b2720a756 Author: prr Date: 2012-07-17 16:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab0b2720a756 7183251: Netbeans editor renders text wrong on JDK 7u6 build 17 Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunLayoutEngine.java Changeset: f1a90ee31b38 Author: serb Date: 2012-07-04 14:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1a90ee31b38 7124244: [macosx] Shaped windows support Reviewed-by: anthony, art ! src/macosx/classes/sun/java2d/opengl/CGLLayer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWRepaintArea.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTWindow.m ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/awt/SunToolkit.java Changeset: 80c592c9458e Author: serb Date: 2012-07-04 15:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80c592c9458e 7124513: [macosx] Support NSTexturedBackgroundWindowMask/different titlebar styles to create unified toolbar Reviewed-by: anthony, art ! src/macosx/classes/com/apple/laf/AquaPanelUI.java ! src/macosx/classes/com/apple/laf/AquaRootPaneUI.java ! src/macosx/classes/com/apple/laf/AquaToolBarUI.java ! src/macosx/classes/com/apple/laf/AquaUtils.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/share/classes/javax/swing/JViewport.java Changeset: 911195d40b89 Author: anthony Date: 2012-07-06 14:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/911195d40b89 7177173: [macosx] JFrame.setExtendedState(JFrame.MAXIMIZED_BOTH) not working as expected in JDK 7 Summary: Avoid unnecessary changes to the extended state Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/java/awt/Frame/HideMaximized/HideMaximized.java Changeset: 4d750ca79fb7 Author: ptisnovs Date: 2012-07-12 16:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d750ca79fb7 7022041: TitleBorder Null Pointer Exception Summary: Added check if getTitleFont() and getTitleColor() don't return null Reviewed-by: alexsch ! src/share/classes/javax/swing/border/TitledBorder.java + test/javax/swing/border/Test7022041.java Changeset: 4624486823a7 Author: serb Date: 2012-07-16 14:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4624486823a7 7181438: [OGL] Incorrect alpha used, during blit from SW to the texture. Reviewed-by: prr, campbell ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c + test/sun/java2d/OpenGL/bug7181438.java Changeset: c277657e5e10 Author: serb Date: 2012-07-16 14:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c277657e5e10 7170657: [macosx] There seems to be no keyboard/mouse action to select non-contiguous items in List Reviewed-by: rupashka ! src/share/classes/javax/swing/SwingUtilities.java + test/javax/swing/SwingUtilities/7170657/bug7170657.java Changeset: 6d9ea8c91808 Author: lana Date: 2012-07-16 14:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d9ea8c91808 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers Changeset: 08842f8ce960 Author: bagiras Date: 2012-07-17 12:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08842f8ce960 7177040: Deadlock between PostEventQueue.noEvents, EventQueue.isDispatchThread and SwingUtilities.invokeLater Reviewed-by: anthony, ant ! src/share/classes/sun/awt/SunToolkit.java Changeset: 8a90db6c4d77 Author: alexsch Date: 2012-07-18 18:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a90db6c4d77 7182902: [macosx] Test api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode fails on Mac OS X 10.7 Reviewed-by: bae, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/native/sun/awt/CGraphicsDevice.m Changeset: 86ca943c120b Author: lana Date: 2012-07-18 16:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86ca943c120b Merge Changeset: 255c2c63697e Author: lana Date: 2012-07-18 16:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/255c2c63697e Merge - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 51707c3b75c0 Author: lana Date: 2012-07-24 11:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51707c3b75c0 Merge Changeset: e4bae5c53fca Author: cl Date: 2012-07-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4bae5c53fca Added tag jdk8-b49 for changeset 51707c3b75c0 ! .hgtags Changeset: a093f6247b52 Author: lana Date: 2012-07-27 22:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a093f6247b52 Merge From alan.bateman at oracle.com Sun Jul 29 20:58:21 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 30 Jul 2012 03:58:21 +0000 Subject: hg: jdk8/tl/jdk: 7185340: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Leaky.java failing intermittently [win] Message-ID: <20120730035848.E61B04729D@hg.openjdk.java.net> Changeset: 78644d4a9a32 Author: dxu Date: 2012-07-30 04:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78644d4a9a32 7185340: TEST_BUG: java/nio/channels/AsynchronousSocketChannel/Leaky.java failing intermittently [win] Reviewed-by: alanb ! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java From michael.x.mcmahon at oracle.com Mon Jul 30 14:40:02 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 30 Jul 2012 21:40:02 +0000 Subject: hg: jdk8/tl/jdk: 7120665: Change Java SE spec so that external networking not required Message-ID: <20120730214022.D8D65472B3@hg.openjdk.java.net> Changeset: 38263aa28324 Author: michaelm Date: 2012-07-30 22:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38263aa28324 7120665: Change Java SE spec so that external networking not required Reviewed-by: alanb ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/package.html From robert at swiecki.net Tue Jul 31 06:07:53 2012 From: robert at swiecki.net (=?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?=) Date: Tue, 31 Jul 2012 15:07:53 +0200 Subject: Buffer overflow in C code. Message-ID: Hi, When using Java code compiled with gllibc's fortify source (buffer overflow detection among others). It crashes: $ java -jar jar.jar *** buffer overflow detected ***: java terminated ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7fc56100a007] /lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7fc561008f00] /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libnet.so(Java_java_net_Inet4AddressImpl_getLocalHostName+0x1a0)[0x7fc55d8e4530] [0x7fc555010d28] ======= Memory map: ======== 00400000-00409000 r-xp 00000000 fd:01 2872 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java 00608000-00609000 r--p 00008000 fd:01 2872 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java 00609000-0060a000 rw-p 00009000 fd:01 2872 /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java 01dba000-01ddb000 rw-p 00000000 00:00 0 [heap] cc000000-cca70000 rw-p 00000000 00:00 0 cca70000-d9e00000 rw-p 00000000 00:00 0 d9e00000-db2f0000 rw-p 00000000 00:00 0 db2f0000-f5a00000 rw-p 00000000 00:00 0 f5a00000-f6ec0000 rw-p 00000000 00:00 0 f6ec0000-100000000 rw-p 00000000 00:00 0 7fc538000000-7fc538021000 rw-p 00000000 00:00 0 7fc538021000-7fc53c000000 ---p 00000000 00:00 0 7fc53c000000-7fc53c021000 rw-p 00000000 00:00 0 7fc53c021000-7fc540000000 ---p 00000000 00:00 0 7fc540000000-7fc540021000 rw-p 00000000 00:00 0 7fc540021000-7fc544000000 ---p 00000000 00:00 0 7fc544000000-7fc5440f5000 rw-p 00000000 00:00 0 7fc5440f5000-7fc548000000 ---p 00000000 00:00 0 7fc548000000-7fc548021000 rw-p 00000000 00:00 0 7fc548021000-7fc54c000000 ---p 00000000 00:00 0 IMO, the problem is here http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/jdk/src/solaris/native/java/net/Inet4AddressImpl.c.html (line 112) I.e. MAXHOSTNAMELEN is declarative only (a convention), and it is assumed there that gethostbyaddr-like functions will return strings which are shorter-equal than 64 (typical value of MAXHOSTNAMELEN). The machine's FQDN was way over 64 characters, so it crashed. I don't think it's easily exploitable (requires control over DNS), but it'd be probably good to fix it. -- Robert ?wi?cki From sean.mullan at oracle.com Tue Jul 31 14:43:57 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 31 Jul 2012 17:43:57 -0400 Subject: JDK8 Code review request for 7179715: OCSP revocation checking fails if the signer certificate is identified using the key ID Message-ID: <5018519D.5060203@oracle.com> Hi Vinnie, Can you please review my fix for 7179715? webrev: http://cr.openjdk.java.net/~mullan/webrevs/7179715/webrev.00/ This was a regression caused by the integration of JEP 124. The responderKey was not being parsed correctly and was causing a DER parsing exception. I have also moved the parsing of the responderId inside debugging blocks because it is only currently used for debugging purposes. The bug is not available at bugs.sun.com for some reason. Thanks, Sean From stephen.flores at oracle.com Tue Jul 31 16:20:48 2012 From: stephen.flores at oracle.com (Stephen Flores) Date: Tue, 31 Jul 2012 19:20:48 -0400 Subject: 6995421: Eliminate the static dependency to sun.security.ec.ECKeyFactory In-Reply-To: <50100F2F.6030408@oracle.com> References: <5009BD0C.4000008@oracle.com> <50100F2F.6030408@oracle.com> Message-ID: <50186850.4030107@oracle.com> Vincent, I forgot that there is no longer a need to duplicate the ECKeyFactory class in rt.jar. Can you take a quick look at webrev-2 that has the makefile changes that eliminate the duplication? Thanks, Steve. On 07/25/2012 11:22 AM, Vincent Ryan wrote: > Hello Stephen, > > Your changes look good. > Thanks. > > > On 20/07/2012 21:18, Stephen Flores wrote: >> Please review the following webrev: >> >> http://cr.openjdk.java.net/~sflores/6995421/ >> >> for bug: 6995421 Eliminate the static dependency to >> sun.security.ec.ECKeyFactory >> >> Description of the problem: >> >> sun.security.x509.AlgorithmId and sun.security.pkcs11.P11ECKeyFactory >> depend on an public static fields sun.security.ec.ECKeyFactory >> >> Also, while debuging I found that ECPublicKeyImpl did not check for >> missing domain parameters while parsing a key, the way ECPrivateKeyImpl >> does. >> >> Evaluation: >> >> At the time of development of AlgorithmId there was no public provider >> for EC Key Factory, a public provider has been added since. >> >> Description of fix: >> >> Since code in sun.security.x509.AlgorithmId the used the provider in >> ECKeyFactory was removed since the call to the public API now provides >> EC AlgorithmParameters. >> >> sun.security.pkcs11.P11ECKeyFactory was changed to use public KeyFactory >> API to get a key factory. >> >> Additional changes: >> >> A null check of the alorithm parameters was added to >> ECPublicKey.parseKeyBits. >> >> The internal provider in ECKeyFactory has been removed and it entries >> move to the SunEC provider class and any references to it have been >> changed to use the public provider API. >> >> Changed the TestEC to the the public API to get the SunEC provider the >> way applications would. >> >> The PKCS11 test methods that are shared TestEC were changed not to >> delete the provider given to them, which did not matter in the past >> since internal provider in ECKeyFactory was being used by EC classes. >> >> Thanks, >> >> Steve. From chris.hegarty at oracle.com Tue Jul 31 18:10:47 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 31 Jul 2012 18:10:47 -0700 Subject: Buffer overflow in C code. In-Reply-To: References: Message-ID: <50188217.80006@oracle.com> [cc'ing net-dev mailing list] Thanks for reporting this issue. This looks like 7089443 [1], fixed in jdk8 via 7112670 [2]. Looks like icetea needs to sync up, or maybe they are based against the jdk7 repo. If so, this could be a good candidate to backport from jdk8 to jdk7 ( then I think icetea will get it for free! ). -Chris. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089443 [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7112670 -Chris. On 31/07/12 06:07, Robert ?wi?cki wrote: > Hi, > > When using Java code compiled with gllibc's fortify source (buffer > overflow detection among others). It crashes: > > $ java -jar jar.jar > *** buffer overflow detected ***: java terminated > ======= Backtrace: ========= > /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7fc56100a007] > /lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7fc561008f00] > /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libnet.so(Java_java_net_Inet4AddressImpl_getLocalHostName+0x1a0)[0x7fc55d8e4530] > [0x7fc555010d28] > ======= Memory map: ======== > 00400000-00409000 r-xp 00000000 fd:01 2872 > /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java > 00608000-00609000 r--p 00008000 fd:01 2872 > /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java > 00609000-0060a000 rw-p 00009000 fd:01 2872 > /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java > 01dba000-01ddb000 rw-p 00000000 00:00 0 [heap] > cc000000-cca70000 rw-p 00000000 00:00 0 > cca70000-d9e00000 rw-p 00000000 00:00 0 > d9e00000-db2f0000 rw-p 00000000 00:00 0 > db2f0000-f5a00000 rw-p 00000000 00:00 0 > f5a00000-f6ec0000 rw-p 00000000 00:00 0 > f6ec0000-100000000 rw-p 00000000 00:00 0 > 7fc538000000-7fc538021000 rw-p 00000000 00:00 0 > 7fc538021000-7fc53c000000 ---p 00000000 00:00 0 > 7fc53c000000-7fc53c021000 rw-p 00000000 00:00 0 > 7fc53c021000-7fc540000000 ---p 00000000 00:00 0 > 7fc540000000-7fc540021000 rw-p 00000000 00:00 0 > 7fc540021000-7fc544000000 ---p 00000000 00:00 0 > 7fc544000000-7fc5440f5000 rw-p 00000000 00:00 0 > 7fc5440f5000-7fc548000000 ---p 00000000 00:00 0 > 7fc548000000-7fc548021000 rw-p 00000000 00:00 0 > 7fc548021000-7fc54c000000 ---p 00000000 00:00 0 > > IMO, the problem is here > > http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/jdk/src/solaris/native/java/net/Inet4AddressImpl.c.html > (line 112) > > I.e. MAXHOSTNAMELEN is declarative only (a convention), and it is > assumed there that gethostbyaddr-like functions will return strings > which are shorter-equal than 64 (typical value of MAXHOSTNAMELEN). > > The machine's FQDN was way over 64 characters, so it crashed. I don't > think it's easily exploitable (requires control over DNS), but it'd be > probably good to fix it. >