From mandy.chung at oracle.com Mon May 1 19:41:15 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 1 May 2017 12:41:15 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> Message-ID: <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> Looks like this test execs a new VM for 66 times to exhaust the combination of with and without security manager, with a valid or malformed policy, client & custom loader in unnamed, named, automatic module. I think we could take out the automatic module case as named module would verify it. One refactor you can consider by separating them in several @run actions. The timeout will apply to each action but that does not help shorten the test execution time. Mandy > On May 1, 2017, at 11:59 AM, Brent Christian wrote: > > Hi, Joe > > The typical run time of this test is ~18s (on my modestly-equipped laptop). So the test does run within a reasonable amount of time, IMO - under normal circumstances, anyway. > > The increased timeout is to cover the less seldom test run configurations involving Xcomp. Judging by when the test was added and the dates of the failed runs, I think this test has timed out since it was introduced, and there has not been an Xcomp regression. > > The test checks for a recursive initialization issue (8168075), and so needs to launch JVMs using various combinations of system classloader/security manager+policy/various module types. For this reason I think Xcomp hits this test particularly hard, recompiling the startup code on every VM launch. I think we want to maintain thorough test coverage here, though. > > Looking more into the failures, the worst case looks to be getting not quite halfway through the test. We should be able to get away with a more modest increase to the timeout (600, instead of 1200), and still have the test pass, if you would prefer. > > Thanks, > -Brent > > On 4/27/17 2:25 PM, joe darcy wrote: >> I understand the interest in having test pass reliably, but I don't >> think giving the test very large timeouts is the preferred way of >> accomplishing that. >> >> For all configurations, the test can now run for up to 20 minutes, up >> from 4 minutes. We want to run the entire test suite, thousands of >> tests, in about 20 minutes. The the timeout factor used for Xcomp run, >> the test would probably now be able to run for over an hour before >> timing out. >> >> I suggest making the test run faster, or seeing if there has been a >> regressions in Xcomp to make test perform more poorly there. >> >> Thanks, >> >> -Joe >> >> >> On 4/27/2017 12:08 PM, Brent Christian wrote: >>> Hi, >>> >>> This test times out under our automated testing configurations that >>> include -Xcomp. >>> >>> Please review my change to increase the timeout for this test. It is >>> sufficient for the test configurations in question to pass on two >>> different local machines (Mac & Linux). >>> >>> diff -r 7c04ab31b4d6 >>> test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >>> --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >>> Wed Apr 26 09:37:23 2017 -0700 >>> +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >>> Thu Apr 27 12:03:33 2017 -0700 >>> @@ -29,7 +29,7 @@ >>> * @library /lib/testlibrary >>> * @modules java.base/jdk.internal.module >>> * @build JarUtils CompilerUtils >>> - * @run main/timeout=240 ClassLoaderTest >>> + * @run main/timeout=1200 ClassLoaderTest >>> */ >>> >>> Thanks, >>> -Brent >> From mandy.chung at oracle.com Mon May 1 19:50:40 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 1 May 2017 12:50:40 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> Message-ID: <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> > On May 1, 2017, at 12:47 PM, Brent Christian wrote: > > >> One refactor you can consider by separating >> them in several @run actions. The timeout will apply to each action >> but that does not help shorten the test execution time. > > I had the same thought, and concluded that without a reduction in overall execution time, the benefit of such a refactor is pretty limited. I think it would make the test easier to read and understand the cases it cover. Mandy From bradford.wetmore at oracle.com Mon May 1 20:19:36 2017 From: bradford.wetmore at oracle.com (Brad R. Wetmore) Date: Mon, 1 May 2017 13:19:36 -0700 Subject: RFR: 8178014: CryptoPolicyParser's API comment contains < and > characters Message-ID: <995f4c9a-2f8c-a9f3-1a05-9af801f9ad37@oracle.com> Kumar (+ anyone else), Simple review for fixing two errors when building javadocs with -private (non-default option). Also, the 'name' attribute is no longer supported in HTML5. So doing a trivial name->id rename to HTML5 cleanup the XML DSig docs. https://bugs.openjdk.java.net/browse/JDK-8178014 http://cr.openjdk.java.net/~wetmore/8178014/webrev.00/ These are docs-only issues. Thanks, Brad From sean.mullan at oracle.com Mon May 1 20:55:19 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 1 May 2017 16:55:19 -0400 Subject: RFR: 8178014: CryptoPolicyParser's API comment contains < and > characters In-Reply-To: <995f4c9a-2f8c-a9f3-1a05-9af801f9ad37@oracle.com> References: <995f4c9a-2f8c-a9f3-1a05-9af801f9ad37@oracle.com> Message-ID: <9f11bb48-92a7-a538-58da-8f1c4df6383c@oracle.com> Looks good to me. --Sean On 5/1/17 4:19 PM, Brad R. Wetmore wrote: > Kumar (+ anyone else), > > Simple review for fixing two errors when building javadocs with -private > (non-default option). > > Also, the 'name' attribute is no longer supported in HTML5. So > doing a trivial name->id rename to HTML5 cleanup the XML DSig docs. > > https://bugs.openjdk.java.net/browse/JDK-8178014 > http://cr.openjdk.java.net/~wetmore/8178014/webrev.00/ > > These are docs-only issues. > > Thanks, > > Brad > From kumar.x.srinivasan at oracle.com Tue May 2 01:12:44 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 01 May 2017 18:12:44 -0700 Subject: RFR: 8178014: CryptoPolicyParser's API comment contains < and > characters In-Reply-To: <9f11bb48-92a7-a538-58da-8f1c4df6383c@oracle.com> References: <995f4c9a-2f8c-a9f3-1a05-9af801f9ad37@oracle.com> <9f11bb48-92a7-a538-58da-8f1c4df6383c@oracle.com> Message-ID: <5907DD0C.3090402@oracle.com> +1 Kumar On 5/1/2017 1:55 PM, Sean Mullan wrote: > Looks good to me. > > --Sean > > On 5/1/17 4:19 PM, Brad R. Wetmore wrote: >> Kumar (+ anyone else), >> >> Simple review for fixing two errors when building javadocs with -private >> (non-default option). >> >> Also, the 'name' attribute is no longer supported in HTML5. So >> doing a trivial name->id rename to HTML5 cleanup the XML DSig docs. >> >> https://bugs.openjdk.java.net/browse/JDK-8178014 >> http://cr.openjdk.java.net/~wetmore/8178014/webrev.00/ >> >> These are docs-only issues. >> >> Thanks, >> >> Brad >> From anthony.scarpino at oracle.com Wed May 3 00:13:31 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 2 May 2017 17:13:31 -0700 Subject: RFR 8176457: Add verbose option to java.security.debug Message-ID: <5c74a63f-5e29-ebc6-adf5-98b9d76ff3e5@oracle.com> I need a review for adding the verbose option to debugging so that the output is not overwhelmed with unnecessary info. http://cr.openjdk.java.net/~ascarpino/8176457/webrev/ Tony From vincent.x.ryan at oracle.com Wed May 3 06:57:19 2017 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 3 May 2017 07:57:19 +0100 Subject: RFR 8176457: Add verbose option to java.security.debug In-Reply-To: <5c74a63f-5e29-ebc6-adf5-98b9d76ff3e5@oracle.com> References: <5c74a63f-5e29-ebc6-adf5-98b9d76ff3e5@oracle.com> Message-ID: <9616A66E-7CA0-4158-99EA-77FB225D2E17@oracle.com> Your change looks fine to me Tony. Thanks. > On 3 May 2017, at 01:13, Anthony Scarpino wrote: > > I need a review for adding the verbose option to debugging so that the output is not overwhelmed with unnecessary info. > > http://cr.openjdk.java.net/~ascarpino/8176457/webrev/ > > Tony > From sha.jiang at oracle.com Wed May 3 07:22:21 2017 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 3 May 2017 15:22:21 +0800 Subject: RFR[9] 8179451: Confidential copyright header in openjdk Message-ID: Hi, Two test files JSSEClient.java and JSSEServer.java in jdk/test/sun/security/ssl/CertPathRestrictions use wrong copyright notices. This patch corrects this mistake. Issue: https://bugs.openjdk.java.net/browse/JDK-8179451 Webrev: http://cr.openjdk.java.net/~mli/8179451/webrev.00/ Best regards, John Jiang From weijun.wang at oracle.com Wed May 3 07:29:27 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 May 2017 15:29:27 +0800 Subject: RFR[9] 8179451: Confidential copyright header in openjdk In-Reply-To: References: Message-ID: <6f730e0c-f3c3-bf09-e405-6a5b0b0bdaad@oracle.com> There is no "Classpath extension" in copyright notices for tests. --Max On 05/03/2017 03:22 PM, sha.jiang at oracle.com wrote: > Hi, > Two test files JSSEClient.java and JSSEServer.java in > jdk/test/sun/security/ssl/CertPathRestrictions use wrong copyright notices. > This patch corrects this mistake. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8179451 > Webrev: http://cr.openjdk.java.net/~mli/8179451/webrev.00/ > > Best regards, > John Jiang > From sha.jiang at oracle.com Wed May 3 08:13:43 2017 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 3 May 2017 16:13:43 +0800 Subject: RFR[9] 8179451: Confidential copyright header in openjdk In-Reply-To: <6f730e0c-f3c3-bf09-e405-6a5b0b0bdaad@oracle.com> References: <6f730e0c-f3c3-bf09-e405-6a5b0b0bdaad@oracle.com> Message-ID: Hi Max, Thanks for your comment! Please review the updated webrev: http://cr.openjdk.java.net/~mli/8179451/webrev.01/ Best regards, John Jiang On 03/05/2017 15:29, Weijun Wang wrote: > There is no "Classpath extension" in copyright notices for tests. > > --Max > > On 05/03/2017 03:22 PM, sha.jiang at oracle.com wrote: >> Hi, >> Two test files JSSEClient.java and JSSEServer.java in >> jdk/test/sun/security/ssl/CertPathRestrictions use wrong copyright >> notices. >> This patch corrects this mistake. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8179451 >> Webrev: http://cr.openjdk.java.net/~mli/8179451/webrev.00/ >> >> Best regards, >> John Jiang >> > From weijun.wang at oracle.com Wed May 3 09:57:12 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 May 2017 17:57:12 +0800 Subject: RFR[9] 8179451: Confidential copyright header in openjdk In-Reply-To: References: <6f730e0c-f3c3-bf09-e405-6a5b0b0bdaad@oracle.com> Message-ID: <7f915779-df27-9533-0a7e-a056c8e2dd1c@oracle.com> The change looks fine. Thanks Max On 05/03/2017 04:13 PM, sha.jiang at oracle.com wrote: > Hi Max, > Thanks for your comment! > Please review the updated webrev: > http://cr.openjdk.java.net/~mli/8179451/webrev.01/ > > Best regards, > John Jiang > > > On 03/05/2017 15:29, Weijun Wang wrote: >> There is no "Classpath extension" in copyright notices for tests. >> >> --Max >> >> On 05/03/2017 03:22 PM, sha.jiang at oracle.com wrote: >>> Hi, >>> Two test files JSSEClient.java and JSSEServer.java in >>> jdk/test/sun/security/ssl/CertPathRestrictions use wrong copyright >>> notices. >>> This patch corrects this mistake. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8179451 >>> Webrev: http://cr.openjdk.java.net/~mli/8179451/webrev.00/ >>> >>> Best regards, >>> John Jiang >>> >> > From jonathan.gibbons at oracle.com Wed May 3 22:06:47 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 May 2017 15:06:47 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. Message-ID: <590A5477.9050602@oracle.com> This is a review request for two co-dependent fixes. JDK-8179592: Update tables in java.base to be HTML 5-friendly. JDK-8179479: Add new styles to enable HTML 5 tables In doc comments, some of the HTML 4.01 attributes for tables are no longer available in HTML 5, and CSS should be used instead. To this end, some updates have been made to the main/default stylesheet used by javadoc, to define two new CSS classes for tables. The new classes are: Just puts plain borders around each cell, with no background coloring.
Horizontal borders are not used between cells in the table body; instead, alternating backgrounds are used to help distinguish the separate rows. In addition, there is still the default
No borders. These styles are in the langtools webrev, here: http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ The changes to the doc comments in java.base are in the jdk webrev, here: http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ summary vs.
The ARIA recommendations are to use the summary attribute or tag ... but the summary attribute is no longer allowed in HTML 5. In general, the text that has been provided for a summary is not suitable for direct use as a caption. The temporary workaround is to use a caption that is not displayed. In time, the appropriate API owners should update the use of these undisplayed table captions, to modify the text of the caption and make the caption displayed (by removing style="display:none"). Doc comments were changed in files in the following packages: java.io java.lang java.lang.invoke java.lang.reflect java.math java.net java.nio.channels java.nio.charset java.nio.file java.nio.file.attribute java.nio.file.spi java.security java.security.cert java.text java.time.chrono java.time.format java.time.temporal java.util java.util.concurrent java.util.regex java.util.spi javax.net.ssl The intent is that the only changes in this webrev are to the HTML 5 markup. There should be no significant changes to the text in any doc comment. The decision to add the styles to the default stylesheet at this late stage in the release is not taken lightly, and is seen as a temporary measure. JDK-8177283 is a wishlist enhancement for updates to javadoc support of stylesheets, which includes the desire to move JDK-specific styles to a JDK-specific stylesheet. This review is primarily about continuing the ongoing effort to make our docs be HTML 5 compliant. I would prefer not to get into extended discussions about which style class to use for each table, and what the exact definition of the styleclasses should be at this time. But appropriate review feedback is obviously welcome. -- Jon From martinrb at google.com Wed May 3 23:39:37 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 May 2017 16:39:37 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A5477.9050602@oracle.com> References: <590A5477.9050602@oracle.com> Message-ID: Thanks, Jon. For the Deque/Queue tables - * + *
I expected that we would modify these to
which rendered alright and is compliant (although "border" is a weird boolean) and makes the "border intent" clear to humans and to browsers. THIS IS JAVA, so I'd prefer more verbose meaningful names for these style classes ... hmmm ... class="contrasting_rows" ? To me, "plain" is suggestive of no borders at all. Can we have some guidance comments in stylesheet.css explaining when to use the different classes? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 4 00:03:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 May 2017 17:03:13 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> Message-ID: <590A6FC1.5030803@oracle.com> On 05/03/2017 04:39 PM, Martin Buchholz wrote: > Thanks, Jon. > > For the Deque/Queue tables > - *
> + *
> I expected that we would modify these to >
> which rendered alright and is compliant (although "border" is a weird > boolean) and makes the "border intent" clear to humans and to browsers. > > THIS IS JAVA, so I'd prefer more verbose meaningful names for these > style classes ... hmmm ... class="contrasting_rows" ? To me, "plain" > is suggestive of no borders at all. > > Can we have some guidance comments in stylesheet.css explaining when > to use the different classes? > Martin, If you are specifically requesting that the tables in Deque/Queue use "
" then I will do as you request, but I note that the "plain" style does more than just `border="1"`. It adjusts the caption font and the margins above and below the table. Given that the JSR166 doc comments actually use the
tag reasonably, the presentation with the non-default font seemed "better". That being said, prior to doing this work, I did some analysis on the tables coming from doc comments. There are about 484 with 70 different variants of the opening tag. Therefore, there was a secondary goal to simplify the many different visual appearances created using inline styles. How strongly do you feel about the names? As I said at the end of the email, I would like to do a more complete cleanup of javadoc support for stylesheets in a subsequent release. This would involve separating the stylesheet for the HTML generated by the doclet from a stylesheet provided to accompany the doc comments, and would clean up the name space and write a moderately formal specification of the styles in those stylesheets. I can put some comments in the default stylesheet for the time being. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu May 4 00:46:23 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 May 2017 17:46:23 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A6FC1.5030803@oracle.com> References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> Message-ID: Jon, I am happy for you to own the html5 style for the entire javadoc; consistency wins; my comments are only suggestions and I'm no html or css expert. On Wed, May 3, 2017 at 5:03 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > > On 05/03/2017 04:39 PM, Martin Buchholz wrote: > > Thanks, Jon. > > For the Deque/Queue tables > > - *
> + *
> > I expected that we would modify these to >
> which rendered alright and is compliant (although "border" is a weird > boolean) and makes the "border intent" clear to humans and to browsers. > > THIS IS JAVA, so I'd prefer more verbose meaningful names for these style > classes ... hmmm ... class="contrasting_rows" ? To me, "plain" is > suggestive of no borders at all. > > Can we have some guidance comments in stylesheet.css explaining when to > use the different classes? > > > Martin, > > If you are specifically requesting that the tables in Deque/Queue use > "
" then I will do as you request, but I note that the > "plain" style does more than just `border="1"`. It adjusts the caption > font and the margins above and below the table. Given that the JSR166 doc > comments actually use the
tag reasonably, the presentation with > the non-default font seemed "better". > > That being said, prior to doing this work, I did some analysis on the > tables coming from doc comments. There are about 484 with 70 > different variants of the opening tag. Therefore, there was a > secondary goal to simplify the many different visual appearances created > using inline styles. > > How strongly do you feel about the names? As I said at the end of the > email, I would like to do a more complete cleanup of javadoc support for > stylesheets in a subsequent release. This would involve separating the > stylesheet for the HTML generated by the doclet from a stylesheet provided > to accompany the doc comments, and would clean up the name space and write > a moderately formal specification of the styles in those stylesheets. > > I can put some comments in the default stylesheet for the time being. > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 4 01:16:35 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 May 2017 18:16:35 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> Message-ID: <590A80F3.6050904@oracle.com> With my javadoc-tool-developer hat on, I'd like to get out of the business of jdk-style-owner, or at least identify that as a distinct hat. :-) Kumar has identified a problem with the styles as currently defined ... you cannot easily embed a table with a default style inside a table with an explicit style ... which suggests the need for a third named style for "no borders". (And yes, we have nested tables in some places.). Although we disagree with your comment "THIS IS JAVA" (no it's not, it's HTML and CSS) the point is noted. How about the following names, with appropriate comments to come in the style sheet: 1.
it does what it says, but long term, I see this being deprecated in favor of other styles ... there are places where a style with no borders is in use now, but when you add in captions, some amount of bordering would be better. 2.
simple collapsed borders around each cell 3.
previously called altrows. How about longer names, specific to tables, like "borderless-table", "plain-table", "striped-table"? That would make it easier to have named styles for other constructs, although we will need to keep a balance between a proliferation of named styles and too much inline style. All of this would be so much better with sufficient definitions for all the styles used by javadoc to allow adventurous and creative folk to use modified stylesheets for their own API. But not this week. By the way, I forgot to mention in my original email, there is a copy of the API docs showing the proposed changes, available here: http://cr.openjdk.java.net/~jjg/8179479-8179592/api/java.base-summary.html -- Jon On 05/03/2017 05:46 PM, Martin Buchholz wrote: > Jon, I am happy for you to own the html5 style for the entire javadoc; > consistency wins; my comments are only suggestions and I'm no html or > css expert. > > On Wed, May 3, 2017 at 5:03 PM, Jonathan Gibbons > > wrote: > > > > On 05/03/2017 04:39 PM, Martin Buchholz wrote: >> Thanks, Jon. >> >> For the Deque/Queue tables >> - *
>> + *
>> I expected that we would modify these to >>
>> which rendered alright and is compliant (although "border" is a >> weird boolean) and makes the "border intent" clear to humans and >> to browsers. >> >> THIS IS JAVA, so I'd prefer more verbose meaningful names for >> these style classes ... hmmm ... class="contrasting_rows" ? To >> me, "plain" is suggestive of no borders at all. >> >> Can we have some guidance comments in stylesheet.css explaining >> when to use the different classes? >> > > Martin, > > If you are specifically requesting that the tables in Deque/Queue > use "
" then I will do as you request, but I note > that the "plain" style does more than just `border="1"`. It > adjusts the caption font and the margins above and below the > table. Given that the JSR166 doc comments actually use the >
tag reasonably, the presentation with the non-default > font seemed "better". > > That being said, prior to doing this work, I did some analysis on > the tables coming from doc comments. There are about 484 > with 70 different variants of the opening tag. Therefore, > there was a secondary goal to simplify the many different visual > appearances created using inline styles. > > How strongly do you feel about the names? As I said at the end of > the email, I would like to do a more complete cleanup of javadoc > support for stylesheets in a subsequent release. This would > involve separating the stylesheet for the HTML generated by the > doclet from a stylesheet provided to accompany the doc comments, > and would clean up the name space and write a moderately formal > specification of the styles in those stylesheets. > > I can put some comments in the default stylesheet for the time being. > > -- Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu May 4 02:49:29 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 May 2017 19:49:29 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A80F3.6050904@oracle.com> References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> <590A80F3.6050904@oracle.com> Message-ID: Jonathan Gibbons for "css style czar"! --- I checked the tables at http://cr.openjdk.java.net/~jjg/8179479-8179592/api/java/util/concurrent/BlockingDeque.html They look perfectly fine, although I feel a twinge of non-collapsed-border-nostalgia. --- Yes, "striped" is a much better name than "altrows". "striped-tables" as you suggest may be better. Choose your names carefully - we can't change them in the future. --- w3.org doc seems to suggest we should only be defining table styles with borders. https://www.w3.org/TR/html5/tabular-data.html#attr-table-border """Tables should not be used as layout aids. """ """User agents, especially those that do table analysis on arbitrary content, are encouraged to find heuristics to determine which tables actually contain data and which are merely being used for layout. """ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 4 15:16:21 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 4 May 2017 08:16:21 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> <590A80F3.6050904@oracle.com> Message-ID: On 5/3/17 7:49 PM, Martin Buchholz wrote: > > w3.org doc seems to suggest we should only be defining > table styles with borders. > > https://www.w3.org/TR/html5/tabular-data.html#attr-table-border > > """Tables should not be used as layout aids. """ > > """User agents, especially those that do table analysis on arbitrary > content, are encouraged to find heuristics to determine which tables > actually contain data and which are merely being used for layout. """ Understood. The patch as provided already changes some tables with `summary="layout"` into definition lists. There are additional candidates that would be candidates for such a change at some point. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 4 15:27:23 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 4 May 2017 08:27:23 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> <590A80F3.6050904@oracle.com> Message-ID: <307d0c82-5358-5a2e-88a4-344a9f591c21@oracle.com> On 5/3/17 7:49 PM, Martin Buchholz wrote: > > --- > > Yes, "striped" is a much better name than "altrows". "striped-tables" > as you suggest may be better. Choose your names carefully - we can't > change them in the future. > > --- Well, we can, ... but ... A goal of creating specification(s) for the stylesheet(s) provided by javadoc, for the doclet-generated output, and for the doc-comment content, is that the specification(s) should be subject to specification review[1], and not just an impl detail of the javadool tool and/or build system. -- Jon [1] http://mail.openjdk.java.net/pipermail/csr-discuss/2017-April/thread.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Fri May 5 13:17:11 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 5 May 2017 15:17:11 +0200 Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs directory Message-ID: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> The Security Standard Names document will be moved to a new location, so all links needs to be updated. Also, a minor fix to the build system was needed. Bug: https://bugs.openjdk.java.net/browse/JDK-8178278 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01 /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri May 5 15:52:48 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 5 May 2017 08:52:48 -0700 Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs directory In-Reply-To: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> Message-ID: <9ca199f9-5b0f-e210-c068-90cd81353864@oracle.com> What's the reason for adding the conditional around SetupCopyFiles in Javadoc.gmk? The SetupCopyFiles macro should be safe to call with an empty FILES list. It should evaluate to basically nothing in that case. /Erik On 2017-05-05 06:17, Magnus Ihse Bursie wrote: > The Security Standard Names document will be moved to a new location, > so all links needs to be updated. Also, a minor fix to the build > system was needed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178278 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01 > > /Magnus > From sean.mullan at oracle.com Fri May 5 20:50:24 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 5 May 2017 16:50:24 -0400 Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs directory In-Reply-To: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> Message-ID: <1ca80e0c-daa9-7dab-fb10-7762e9605a07@oracle.com> General: change the text of all of the links from "Java Cryptography Architecture Standard Algorithm Name Documentation" (the old name) to "Java Security Standard Algorithm Names Specification". Looks good otherwise. Thanks, Sean On 5/5/17 9:17 AM, Magnus Ihse Bursie wrote: > The Security Standard Names document will be moved to a new location, so > all links needs to be updated. Also, a minor fix to the build system was > needed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178278 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01 > > /Magnus > From jonathan.gibbons at oracle.com Fri May 5 22:52:47 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 05 May 2017 15:52:47 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A5477.9050602@oracle.com> References: <590A5477.9050602@oracle.com> Message-ID: <590D023F.1010809@oracle.com> This is an updated review for the changes to improve tables in java.base. The changes incorporate earlier review feedback, and also address a problem that was discovered with nested tables. The summary of the set of changes since the previous round is: * A new style class is added for borderless tables, to be used in preference to a table tag with no class. * The style classes are now named: borderless plain striped The longer form using a suffix `-table` was considered, but generally, there should not be so many style classes that such a level of discrimination is needed. The names `borderless` and `striped` are most likely to only apply to tables anyway, and `plain` could reasonably be used for other elements without conflict. * Comments are added to the stylesheet regarding these new classes, as a placeholder until a better specification for the styles in these stylesheets is created. * Within java.base, all uses of the `altrows` class have been updated to use `striped`, and tables with no class attribute have been changed to explicitly use `borderless`. Webrevs: langtools (the stylesheet): http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ jdk (changes to java.base): http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ API showing the combined effect of these cahnges: http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html -- Jon On 05/03/2017 03:06 PM, Jonathan Gibbons wrote: > This is a review request for two co-dependent fixes. > > JDK-8179592: Update tables in java.base to be HTML 5-friendly. > JDK-8179479: Add new styles to enable HTML 5 tables > > In doc comments, some of the HTML 4.01 attributes for tables are no > longer available in HTML 5, and CSS should be used instead. > To this end, some updates have been made to the main/default > stylesheet used by javadoc, to define two new CSS classes for tables. > > The new classes are: >
> Just puts plain borders around each cell, with no background > coloring. > >
> Horizontal borders are not used between cells in the table body; > instead, alternating backgrounds are used to help distinguish the > separate rows. > > In addition, there is still the default >
> No borders. > > These styles are in the langtools webrev, here: > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ > > The changes to the doc comments in java.base are in the jdk webrev, here: > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ > > summary vs.
> > The ARIA recommendations are to use the summary attribute or > tag ... but the summary attribute is no longer allowed in > HTML 5. In general, the text that has been provided for a summary is > not suitable for direct use as a caption. The temporary workaround is > to use a caption that is not displayed. In time, the appropriate API > owners should update the use of these undisplayed table captions, to > modify the text of the caption and make the caption displayed (by > removing style="display:none"). > > Doc comments were changed in files in the following packages: > > java.io > java.lang > java.lang.invoke > java.lang.reflect > java.math > java.net > java.nio.channels > java.nio.charset > java.nio.file > java.nio.file.attribute > java.nio.file.spi > java.security > java.security.cert > java.text > java.time.chrono > java.time.format > java.time.temporal > java.util > java.util.concurrent > java.util.regex > java.util.spi > javax.net.ssl > > The intent is that the only changes in this webrev are to the HTML 5 > markup. There should be no significant changes to the text in any doc > comment. > > The decision to add the styles to the default stylesheet at this late > stage in the release is not taken lightly, and is seen as a temporary > measure. JDK-8177283 is a wishlist enhancement for updates to javadoc > support of stylesheets, which includes the desire to move JDK-specific > styles to a JDK-specific stylesheet. > > This review is primarily about continuing the ongoing effort to make > our docs be HTML 5 compliant. I would prefer not to get into extended > discussions about which style class to use for each table, and what > the exact definition of the styleclasses should be at this time. But > appropriate review feedback is obviously welcome. > > -- Jon From bradford.wetmore at oracle.com Sat May 6 00:22:45 2017 From: bradford.wetmore at oracle.com (Brad R. Wetmore) Date: Fri, 5 May 2017 17:22:45 -0700 Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs directory In-Reply-To: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> Message-ID: <91779d8f-c22b-fe0f-3757-ff32dcad998b@oracle.com> I applied the patch to the jdk workspace and verified that all of the instances were updated to {@docRoot}/../specs/security/standard-names.html, and that no links remain to the old StandardNames.html. Sean wrote: > General: change the text of all of the links from "Java Cryptography > Architecture Standard Algorithm Name Documentation" (the old name) to > "Java Security Standard Algorithm Names Specification". +1 Can you add similar wording to that effect in DrbgParameters.java? jdk/src/java.base/share/classes/java/security/cert/CertPathValidator.java 155-156, 193-194: extra spaces at beginning of line. jdk/src/java.base/share/classes/javax/crypto/Cipher.java 153: Why did you choose to use "Cipher Algorithm Names" instead of Cipher Algorithms? None of the other sections use "Names". Can you add a link in the JSSE KeyManagerFactory class description to the standard names sections for KeyManagerFactory's? Even though we don't require any currently, we should probably point to the names anyway. Thanks, Brad On 5/5/2017 6:17 AM, Magnus Ihse Bursie wrote: > The Security Standard Names document will be moved to a new location, so > all links needs to be updated. Also, a minor fix to the build system was > needed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178278 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01 > > /Magnus > From kumar.x.srinivasan at oracle.com Mon May 8 22:12:11 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 08 May 2017 15:12:11 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <590D023F.1010809@oracle.com> References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com> Message-ID: <5910ED3B.9090808@oracle.com> Hi Jon, I looked at the stylesheet can the descriptive comments for each of the classes be moved closer to the class itself, ie. just before the definition ? Kumar > This is an updated review for the changes to improve tables in java.base. > > The changes incorporate earlier review feedback, and also address a > problem that was discovered with nested tables. > > The summary of the set of changes since the previous round is: > > * A new style class is added for borderless tables, to be used in > preference to a table tag with no class. > > * The style classes are now named: > borderless > plain > striped > The longer form using a suffix `-table` was considered, but > generally, there should not be so many style classes that such a level > of discrimination is needed. The names `borderless` and `striped` are > most likely to only apply to tables anyway, and `plain` could > reasonably be used for other elements without conflict. > > * Comments are added to the stylesheet regarding these new classes, as > a placeholder until a better specification for the styles in these > stylesheets is created. > > * Within java.base, all uses of the `altrows` class have been updated > to use `striped`, and tables with no class attribute have been changed > to explicitly use `borderless`. > > > Webrevs: > > langtools (the stylesheet): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ > > jdk (changes to java.base): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ > > API showing the combined effect of these cahnges: > http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html > > > > -- Jon > > > > > On 05/03/2017 03:06 PM, Jonathan Gibbons wrote: >> This is a review request for two co-dependent fixes. >> >> JDK-8179592: Update tables in java.base to be HTML 5-friendly. >> JDK-8179479: Add new styles to enable HTML 5 tables >> >> In doc comments, some of the HTML 4.01 attributes for tables are no >> longer available in HTML 5, and CSS should be used instead. >> To this end, some updates have been made to the main/default >> stylesheet used by javadoc, to define two new CSS classes for tables. >> >> The new classes are: >> >> Just puts plain borders around each cell, with no background >> coloring. >> >>
>> Horizontal borders are not used between cells in the table body; >> instead, alternating backgrounds are used to help distinguish the >> separate rows. >> >> In addition, there is still the default >>
>> No borders. >> >> These styles are in the langtools webrev, here: >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ >> >> The changes to the doc comments in java.base are in the jdk webrev, >> here: >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ >> >> summary vs.
>> >> The ARIA recommendations are to use the summary attribute or >> tag ... but the summary attribute is no longer allowed in >> HTML 5. In general, the text that has been provided for a summary is >> not suitable for direct use as a caption. The temporary workaround is >> to use a caption that is not displayed. In time, the appropriate API >> owners should update the use of these undisplayed table captions, to >> modify the text of the caption and make the caption displayed (by >> removing style="display:none"). >> >> Doc comments were changed in files in the following packages: >> >> java.io >> java.lang >> java.lang.invoke >> java.lang.reflect >> java.math >> java.net >> java.nio.channels >> java.nio.charset >> java.nio.file >> java.nio.file.attribute >> java.nio.file.spi >> java.security >> java.security.cert >> java.text >> java.time.chrono >> java.time.format >> java.time.temporal >> java.util >> java.util.concurrent >> java.util.regex >> java.util.spi >> javax.net.ssl >> >> The intent is that the only changes in this webrev are to the HTML 5 >> markup. There should be no significant changes to the text in any doc >> comment. >> >> The decision to add the styles to the default stylesheet at this late >> stage in the release is not taken lightly, and is seen as a temporary >> measure. JDK-8177283 is a wishlist enhancement for updates to javadoc >> support of stylesheets, which includes the desire to move >> JDK-specific styles to a JDK-specific stylesheet. >> >> This review is primarily about continuing the ongoing effort to make >> our docs be HTML 5 compliant. I would prefer not to get into extended >> discussions about which style class to use for each table, and what >> the exact definition of the styleclasses should be at this time. But >> appropriate review feedback is obviously welcome. >> >> -- Jon > From jonathan.gibbons at oracle.com Mon May 8 22:22:39 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 08 May 2017 15:22:39 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <5910ED3B.9090808@oracle.com> References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com> <5910ED3B.9090808@oracle.com> Message-ID: <5910EFAF.2080609@oracle.com> Kumar, The nature of CSS is such that there is generally no one single definition. The descriptive comments are just before the shared/common parts of the definitions. If I grouped the comment and class definition, someone else would point out that I could be sharing common properties. The better long term solution is a separate document, with examples. -- Jon On 05/08/2017 03:12 PM, Kumar Srinivasan wrote: > > Hi Jon, > > I looked at the stylesheet can the descriptive comments for each of the > classes be moved closer to the class itself, ie. just before the > definition ? > > Kumar > >> This is an updated review for the changes to improve tables in >> java.base. >> >> The changes incorporate earlier review feedback, and also address a >> problem that was discovered with nested tables. >> >> The summary of the set of changes since the previous round is: >> >> * A new style class is added for borderless tables, to be used in >> preference to a table tag with no class. >> >> * The style classes are now named: >> borderless >> plain >> striped >> The longer form using a suffix `-table` was considered, but >> generally, there should not be so many style classes that such a >> level of discrimination is needed. The names `borderless` and >> `striped` are most likely to only apply to tables anyway, and `plain` >> could reasonably be used for other elements without conflict. >> >> * Comments are added to the stylesheet regarding these new classes, >> as a placeholder until a better specification for the styles in these >> stylesheets is created. >> >> * Within java.base, all uses of the `altrows` class have been updated >> to use `striped`, and tables with no class attribute have been >> changed to explicitly use `borderless`. >> >> >> Webrevs: >> >> langtools (the stylesheet): >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ >> >> jdk (changes to java.base): >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ >> >> API showing the combined effect of these cahnges: >> http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html >> >> >> >> -- Jon >> >> >> >> >> On 05/03/2017 03:06 PM, Jonathan Gibbons wrote: >>> This is a review request for two co-dependent fixes. >>> >>> JDK-8179592: Update tables in java.base to be HTML 5-friendly. >>> JDK-8179479: Add new styles to enable HTML 5 tables >>> >>> In doc comments, some of the HTML 4.01 attributes for tables are no >>> longer available in HTML 5, and CSS should be used instead. >>> To this end, some updates have been made to the main/default >>> stylesheet used by javadoc, to define two new CSS classes for tables. >>> >>> The new classes are: >>> >>> Just puts plain borders around each cell, with no background >>> coloring. >>> >>>
>>> Horizontal borders are not used between cells in the table body; >>> instead, alternating backgrounds are used to help distinguish the >>> separate rows. >>> >>> In addition, there is still the default >>>
>>> No borders. >>> >>> These styles are in the langtools webrev, here: >>> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ >>> >>> The changes to the doc comments in java.base are in the jdk webrev, >>> here: >>> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ >>> >>> summary vs.
>>> >>> The ARIA recommendations are to use the summary attribute or >>> tag ... but the summary attribute is no longer allowed in >>> HTML 5. In general, the text that has been provided for a summary >>> is not suitable for direct use as a caption. The temporary >>> workaround is to use a caption that is not displayed. In time, the >>> appropriate API owners should update the use of these undisplayed >>> table captions, to modify the text of the caption and make the >>> caption displayed (by removing style="display:none"). >>> >>> Doc comments were changed in files in the following packages: >>> >>> java.io >>> java.lang >>> java.lang.invoke >>> java.lang.reflect >>> java.math >>> java.net >>> java.nio.channels >>> java.nio.charset >>> java.nio.file >>> java.nio.file.attribute >>> java.nio.file.spi >>> java.security >>> java.security.cert >>> java.text >>> java.time.chrono >>> java.time.format >>> java.time.temporal >>> java.util >>> java.util.concurrent >>> java.util.regex >>> java.util.spi >>> javax.net.ssl >>> >>> The intent is that the only changes in this webrev are to the HTML 5 >>> markup. There should be no significant changes to the text in any >>> doc comment. >>> >>> The decision to add the styles to the default stylesheet at this >>> late stage in the release is not taken lightly, and is seen as a >>> temporary measure. JDK-8177283 is a wishlist enhancement for updates >>> to javadoc support of stylesheets, which includes the desire to move >>> JDK-specific styles to a JDK-specific stylesheet. >>> >>> This review is primarily about continuing the ongoing effort to make >>> our docs be HTML 5 compliant. I would prefer not to get into >>> extended discussions about which style class to use for each table, >>> and what the exact definition of the styleclasses should be at this >>> time. But appropriate review feedback is obviously welcome. >>> >>> -- Jon >> > From magnus.ihse.bursie at oracle.com Tue May 9 11:37:50 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 9 May 2017 13:37:50 +0200 Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs directory In-Reply-To: <9ca199f9-5b0f-e210-c068-90cd81353864@oracle.com> References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> <9ca199f9-5b0f-e210-c068-90cd81353864@oracle.com> Message-ID: <4a008991-3caa-6025-6439-f07bed5f2522@oracle.com> On 2017-05-05 17:52, Erik Joelsson wrote: > What's the reason for adding the conditional around SetupCopyFiles in > Javadoc.gmk? The SetupCopyFiles macro should be safe to call with an > empty FILES list. It should evaluate to basically nothing in that case. I don't think there's an explicit reason. The code evolved that way. The previous version had a check for $(SPECS_$m), since SetupCopyFiles does *not* cope with an empty SRC. (Trust me on this ;-)) However, the new foreach will take care of that, so $d will always be specified. The current pattern also mimicks the call to SetupProcessMarkdown further down. (Which, I believe, would not handle an empty value on FILES. Which it perhaps should.) If nothing else, it would probably save us a few clock cycles. :-) Do you want me to remove it? /Magnus > > /Erik > > > On 2017-05-05 06:17, Magnus Ihse Bursie wrote: >> The Security Standard Names document will be moved to a new location, >> so all links needs to be updated. Also, a minor fix to the build >> system was needed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01 >> >> /Magnus >> > From magnus.ihse.bursie at oracle.com Tue May 9 12:21:38 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 9 May 2017 14:21:38 +0200 Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs directory In-Reply-To: <91779d8f-c22b-fe0f-3757-ff32dcad998b@oracle.com> References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> <91779d8f-c22b-fe0f-3757-ff32dcad998b@oracle.com> Message-ID: On 2017-05-06 02:22, Brad R. Wetmore wrote: > I applied the patch to the jdk workspace and verified that all of the > instances were updated to > {@docRoot}/../specs/security/standard-names.html, and that no links > remain to the old StandardNames.html. > > Sean wrote: > > > General: change the text of all of the links from "Java Cryptography > > Architecture Standard Algorithm Name Documentation" (the old name) to > > "Java Security Standard Algorithm Names Specification". > > +1 I've updated the name in all places that I could find. > Can you add similar wording to that effect in DrbgParameters.java? I'm sorry, that instruction is too unclear for me. :-( The main purpose of this patch is to prepare for the markdown based specification, not fixing the entire content. I'll leave modification of the actual documentation to the component owners. > > jdk/src/java.base/share/classes/java/security/cert/CertPathValidator.java > > 155-156, 193-194: extra spaces at beginning of line. Fixed. > > jdk/src/java.base/share/classes/javax/crypto/Cipher.java > > 153: Why did you choose to use "Cipher Algorithm Names" instead of > Cipher Algorithms? None of the other sections use "Names". I did not choose that, that's what the section is called in the document (and has been since at least JDK 8). The difference here is that the anchor links are named after the actual headings in the document, not arbitrarily named anchors (for better and for worse). > > Can you add a link in the JSSE KeyManagerFactory class description to > the standard names sections for KeyManagerFactory's? Even though we > don't require any currently, we should probably point to the names > anyway. I'll give you the same reply here as for DrbgParameters.java: I don't know enough about the domain to be able to do this job properly. Please file a follow-up bug and fix it yourself, or assign to someone who knows. Updated webrev: (contains whitespace fixes and rename of document, but only the jdk repo) http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.02 /Magnus /Magnus > > Thanks, > > Brad > > > > > > On 5/5/2017 6:17 AM, Magnus Ihse Bursie wrote: >> The Security Standard Names document will be moved to a new location, so >> all links needs to be updated. Also, a minor fix to the build system was >> needed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01 >> >> >> /Magnus >> From erik.joelsson at oracle.com Tue May 9 15:48:05 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 9 May 2017 08:48:05 -0700 Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs directory In-Reply-To: <4a008991-3caa-6025-6439-f07bed5f2522@oracle.com> References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> <9ca199f9-5b0f-e210-c068-90cd81353864@oracle.com> <4a008991-3caa-6025-6439-f07bed5f2522@oracle.com> Message-ID: Nah, it's fine. /Erik On 2017-05-09 04:37, Magnus Ihse Bursie wrote: > > On 2017-05-05 17:52, Erik Joelsson wrote: >> What's the reason for adding the conditional around SetupCopyFiles in >> Javadoc.gmk? The SetupCopyFiles macro should be safe to call with an >> empty FILES list. It should evaluate to basically nothing in that case. > > I don't think there's an explicit reason. The code evolved that way. > The previous version had a check for $(SPECS_$m), since SetupCopyFiles > does *not* cope with an empty SRC. (Trust me on this ;-)) > > However, the new foreach will take care of that, so $d will always be > specified. The current pattern also mimicks the call to > SetupProcessMarkdown further down. (Which, I believe, would not handle > an empty value on FILES. Which it perhaps should.) > > If nothing else, it would probably save us a few clock cycles. :-) > > Do you want me to remove it? > > /Magnus > >> >> /Erik >> >> >> On 2017-05-05 06:17, Magnus Ihse Bursie wrote: >>> The Security Standard Names document will be moved to a new >>> location, so all links needs to be updated. Also, a minor fix to the >>> build system was needed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01 >>> >>> /Magnus >>> >> > From bradford.wetmore at oracle.com Tue May 9 20:11:46 2017 From: bradford.wetmore at oracle.com (Brad R. Wetmore) Date: Tue, 9 May 2017 13:11:46 -0700 Subject: RFR: JDK-8178278 Move Standard Algorithm Names document to specs directory In-Reply-To: References: <353a6ea3-5b0f-6a86-3d27-5dd7c76e2f6c@oracle.com> <91779d8f-c22b-fe0f-3757-ff32dcad998b@oracle.com> Message-ID: >> Can you add similar wording to that effect in DrbgParameters.java? > > I'm sorry, that instruction is too unclear for me. :-( The main purpose > of this patch is to prepare for the markdown based specification, not > fixing the entire content. I'll leave modification of the actual > documentation to the component owners. In rereading this, I withdraw this comment. It didn't make sense. >> jdk/src/java.base/share/classes/java/security/cert/CertPathValidator.java >> >> 155-156, 193-194: extra spaces at beginning of line. > Fixed. > >> >> jdk/src/java.base/share/classes/javax/crypto/Cipher.java >> >> 153: Why did you choose to use "Cipher Algorithm Names" instead of >> Cipher Algorithms? None of the other sections use "Names". > > I did not choose that, that's what the section is called in the document > (and has been since at least JDK 8). The difference here is that the > anchor links are named after the actual headings in the document, not > arbitrarily named anchors (for better and for worse). When I got down into the .md file, I figured out your methodology. Thanks for explaining. >> Can you add a link in the JSSE KeyManagerFactory class description to >> the standard names sections for KeyManagerFactory's? Even though we >> don't require any currently, we should probably point to the names >> anyway. > > I'll give you the same reply here as for DrbgParameters.java: I don't > know enough about the domain to be able to do this job properly. Please > file a follow-up bug and fix it yourself, or assign to someone who knows. I've filed: JDK-8180005 Thanks. > Updated webrev: (contains whitespace fixes and rename of document, but > only the jdk repo) Whitespace looks fine. I did a spot check of the renames and seemed pretty straightforward, so I didn't go through all of them. Brad > http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.02 > > > /Magnus > > > /Magnus > > >> >> Thanks, >> >> Brad >> >> >> >> >> >> On 5/5/2017 6:17 AM, Magnus Ihse Bursie wrote: >>> The Security Standard Names document will be moved to a new location, so >>> all links needs to be updated. Also, a minor fix to the build system was >>> needed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178278 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8178278-standard-names-spec-as-markdown/webrev.01 >>> >>> >>> /Magnus >>> > From mandy.chung at oracle.com Tue May 9 23:27:58 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 May 2017 16:27:58 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> Message-ID: <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> > On May 9, 2017, at 4:23 PM, Brent Christian > > I've removed the test case for automatic modules, and added a @run action for each policy file + system classloader configuration. I also removed the code to compile test sources, using @build instead. > > I also made some (hopefully) clarifying changes to the code. > > The String[] argument to execute() is now separated into args/status/message, instead of being lumped into one String[], and then having to be split() out of a single String. Where execute() is called, it's easier to read the args in order (versus assembled using String.format()). > > I also simplified the code for expected status/output, and made some path variable names more descriptive. > > Webrev: > http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ Thanks for the clean up. Does each @run action need 4 mins timeout? Can it restore to the default timeout? Mandy From sean.mullan at oracle.com Wed May 10 18:48:58 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 May 2017 14:48:58 -0400 Subject: [10] RFR 8179389: X509Certificate generateCRLs is extremely slow using a PEM crl list In-Reply-To: <270204c9-c111-6ad7-69e2-8d44b39c8a89@oracle.com> References: <270204c9-c111-6ad7-69e2-8d44b39c8a89@oracle.com> Message-ID: <5502b854-dc4c-4e23-6ecf-dfe60c83bc6c@oracle.com> On 4/28/17 8:44 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8179389/webrev.00/ > > The bug report [1] is correct that the frequent reallocation of data is > the problem. This fix above delegate this task to ByteArrayOutputStream. > There is no significant performance difference between this fix and the > suggested fix in the bug report. > > The "if (next != 9 && next != 10 && next != 13 && next != 32)" filter is > equivalent to replaceAll("\\s+", "") in Pem.decode(). Can you add a comment above lines 600 and 616 describing what characters it is skipping? Otherwise looks good. --Sean > > noreg-perf. > > Thanks > Max > > [1] https://bugs.openjdk.java.net/browse/JDK-8179389 > [2] > http://web.localhost/%7Eww155710/cgi-bin/hgwebdir.cgi/jdk9/dev/jdk/file/d34833290472/src/java.base/share/classes/sun/security/util/Pem.java#l46 > From mandy.chung at oracle.com Wed May 10 22:50:45 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 May 2017 15:50:45 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <590D023F.1010809@oracle.com> References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com> Message-ID: <63E72F41-CF80-4692-9600-3A3857A5F94E@oracle.com> > On May 5, 2017, at 3:52 PM, Jonathan Gibbons wrote: > > This is an updated review for the changes to improve tables in java.base. > : > Webrevs: > > langtools (the stylesheet): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ > > jdk (changes to java.base): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ > > API showing the combined effect of these cahnges: > http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html > The new style class names are better. I reviewed the javadoc changes in java.base. Mostly looks good. A few table without an explicit class and FileSystemProvider should use striped class table. src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java - * + *
src/java.base/share/classes/java/nio/charset/Charset.java + *
+ *
+ *
+ *
+ *
" in one but not the other? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu May 11 15:17:56 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 11 May 2017 08:17:56 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com> Message-ID: <37cbe0ce-060c-6c4c-044b-7903b291fac2@oracle.com> Martin, I've worked with Bhavesh to sort out these issues. The inconsistency in the syntax has been fixed. The CSS could be more compact ... if we did not have to deal with nested tables. It was also a goal to simplify the use for the doc comment author, such that it was possible to put just one class definition on the
tag, and not have to make additional declarations on the tags within the table. Our experiments showed that when we did not fully specify the structure, it was possible for the details of one style to "leak" into another when a table of one style was nested in another table of a different style. At this point, the goal is to introduce the class names, and to have CSS that works well enough across the major browsers. If someone wants to suggest more concise CSS that works well in all our uses cases, that would be a fine RFE for a future release. -- Jon On 5/10/17 7:10 PM, Martin Buchholz wrote: > Looks good. > > --- > > I suspect there's some way to specify the styles more compactly, but I > don't know enough css to say. > > --- > > +table.borderless thead tr th, table.borderless tbody tr th, > table.borderless tr th, > > +table.plain > thead > tr > th, table.plain > tbody > tr > th, > table.plain > tr > th, > > I was surprised at the difference in syntax; why the ">" in one but > not the other? -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Fri May 12 03:19:17 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 11 May 2017 20:19:17 -0700 Subject: [10] RFR 8166222: Don't treat signed jars with invalid timestamps as unsigned In-Reply-To: References: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com> Message-ID: <7302090f-18fc-04e7-ff03-2a031b7d8c1e@oracle.com> I think your code looks good. You should check the CertPathValidator tests, I think one of them might fail after this change. Tony On 05/10/2017 04:36 PM, Weijun Wang wrote: > Ping again. > > On 04/12/2017 11:52 PM, Weijun Wang wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8166222/webrev.00/ >> >> The major code change is inside SignatureFileVerifier.java. Now if the >> timestamp on a signed jar is invalid (For example, using a weak >> algorithm now disabled), the jar file will be treated as a signed jar >> without a timestamp. Before this change, it was treated unsigned. >> >> In jarsigner/Main.java, I also add a line to validate the TSA cert >> chain. If not validated, a warning will be shown which is similar to the >> one when signer cert chain is not validated. If -strict is on, exit code >> will change too. >> >> I also make a small change at >> >> http://cr.openjdk.java.net/~weijun/8166222/root/webrev.00/ >> >> The executeCommand() method shows more info (mainly stdout and stderr >> outputs) than executeProcess(). >> >> Because of the behavior change and new warnings, this change will need a >> Compatibility and Specification Review (CSR). At the moment, please >> review the code change first. >> >> Thanks >> Max From christoph.langer at sap.com Fri May 12 07:26:28 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 12 May 2017 07:26:28 +0000 Subject: FW: SecurityManager.checkPackageAccess for qualified exports In-Reply-To: <4914956cf9844235b352aa33f1af5873@sap.com> References: <4914956cf9844235b352aa33f1af5873@sap.com> Message-ID: Adding security-dev... Any comments? ----------------------------------------------------------------------------- Hi all, while playing with the security manager (using -Djava.security.manager) in Java 9 and testing platform modules that we have added specifically in our build, I came across the following thing: As we are using some stuff from jdk.internal, I get the AccessControlException: "exception access denied ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.misc")" in several places, even if my code runs priviledged. I figured that I need to grant permission "permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.misc"" to my module. I was looking around where this restriction comes from and learned the following in the documentation of SecurityManager.checkPackageAccess: Implementation Note: This implementation also restricts all non-exported packages of modules loaded by the platform class loader or its ancestors. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module. Reading this, I'm wondering whether the implementation should implicitly grant package access for modules that a package in question was exported to in a qualified fashion? Now one ends up having to additionally add specific permissions which can easily be forgot. Any comments? Shouldn't that be improved? Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri May 12 12:45:18 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 May 2017 08:45:18 -0400 Subject: FW: SecurityManager.checkPackageAccess for qualified exports In-Reply-To: References: <4914956cf9844235b352aa33f1af5873@sap.com> Message-ID: <4034d08b-2144-aaa8-2492-fbcab76cf402@oracle.com> On 5/12/17 3:26 AM, Langer, Christoph wrote: > Adding security-dev? Any comments? > > ----------------------------------------------------------------------------- > > Hi all, > > while playing with the security manager (using -Djava.security.manager) > in Java 9 and testing platform modules that we have added specifically > in our build, I came across the following thing: > > As we are using some stuff from jdk.internal, I get the > AccessControlException: ?exception access denied > ("java.lang.RuntimePermission" > "accessClassInPackage.jdk.internal.misc")? in several places, even if my > code runs priviledged. I figured that I need to grant permission > ?permission java.lang.RuntimePermission > "accessClassInPackage.jdk.internal.misc"? to my module. I was looking > around where this restriction comes from and learned the following in > the documentation of SecurityManager.checkPackageAccess: > > *Implementation Note:*** > > This implementation also restricts all non-exported packages of modules > loaded bythe platform class loader > or > its ancestors. A "non-exported package" refers to a package that is not > exported to all modules. Specifically, it refers to a package that > either is not exported at all by its containing module or is exported in > a qualified fashion by its containing module. > > Reading this, I?m wondering whether the implementation should implicitly > grant package access for modules that a package in question was exported > to in a qualified fashion? Now one ends up having to additionally add > specific permissions which can easily be forgot. It was considered. In particular, the security permission check that is done when loading classes of non-exported packages is essentially equivalent to the module access check. However, in other package access checking cases, the SecurityManager check does a full stack walk and checks that every relevant ProtectionDomain on the stack has permission to access the non-exported package. The module access check only checks if the source module has access. There was some concern that this may not be sufficient to guard against all possible attack scenarios. --Sean > > Any comments? Shouldn?t that be improved? > > Best regards > > Christoph > From christoph.langer at sap.com Fri May 12 13:14:03 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 12 May 2017 13:14:03 +0000 Subject: FW: SecurityManager.checkPackageAccess for qualified exports In-Reply-To: <4034d08b-2144-aaa8-2492-fbcab76cf402@oracle.com> References: <4914956cf9844235b352aa33f1af5873@sap.com> <4034d08b-2144-aaa8-2492-fbcab76cf402@oracle.com> Message-ID: <5c1e2539321540ab89a6f9a02271baf0@sap.com> Hi Sean, thanks for your response. > > > > *Implementation Note:*** > > > > This implementation also restricts all non-exported packages of modules > > loaded bythe platform class loader > > > getPlatformClassLoader-->or > > its ancestors. A "non-exported package" refers to a package that is not > > exported to all modules. Specifically, it refers to a package that > > either is not exported at all by its containing module or is exported in > > a qualified fashion by its containing module. > > > > Reading this, I'm wondering whether the implementation should implicitly > > grant package access for modules that a package in question was exported > > to in a qualified fashion? Now one ends up having to additionally add > > specific permissions which can easily be forgot. > > It was considered. In particular, the security permission check that is > done when loading classes of non-exported packages is essentially > equivalent to the module access check. However, in other package access > checking cases, the SecurityManager check does a full stack walk and > checks that every relevant ProtectionDomain on the stack has permission > to access the non-exported package. The module access check only checks > if the source module has access. There was some concern that this may > not be sufficient to guard against all possible attack scenarios. I think the package access check walking down the whole stack is fine and should be done here, not just the module access check. However, frames originating out of a module that the package was exported to should have the permission to access the package. Such that when I would run in a privileged section there, I would get package access. And if I wouldn't run privileged then all the calling frames would be checked and the check might not be passed. Wouldn't that be the right way? Best regards Christoph From sean.mullan at oracle.com Fri May 12 15:01:55 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 May 2017 11:01:55 -0400 Subject: FW: SecurityManager.checkPackageAccess for qualified exports In-Reply-To: <5c1e2539321540ab89a6f9a02271baf0@sap.com> References: <4914956cf9844235b352aa33f1af5873@sap.com> <4034d08b-2144-aaa8-2492-fbcab76cf402@oracle.com> <5c1e2539321540ab89a6f9a02271baf0@sap.com> Message-ID: <8c481296-d67d-5d71-92e7-14722e359366@oracle.com> On 5/12/17 9:14 AM, Langer, Christoph wrote: > Hi Sean, > > thanks for your response. > >>> >>> *Implementation Note:*** >>> >>> This implementation also restricts all non-exported packages of modules >>> loaded bythe platform class loader >>> >> > getPlatformClassLoader-->or >>> its ancestors. A "non-exported package" refers to a package that is not >>> exported to all modules. Specifically, it refers to a package that >>> either is not exported at all by its containing module or is exported in >>> a qualified fashion by its containing module. >>> >>> Reading this, I'm wondering whether the implementation should implicitly >>> grant package access for modules that a package in question was exported >>> to in a qualified fashion? Now one ends up having to additionally add >>> specific permissions which can easily be forgot. >> >> It was considered. In particular, the security permission check that is >> done when loading classes of non-exported packages is essentially >> equivalent to the module access check. However, in other package access >> checking cases, the SecurityManager check does a full stack walk and >> checks that every relevant ProtectionDomain on the stack has permission >> to access the non-exported package. The module access check only checks >> if the source module has access. There was some concern that this may >> not be sufficient to guard against all possible attack scenarios. > > I think the package access check walking down the whole stack is fine and should be done here, not just the module access check. > > However, frames originating out of a module that the package was exported to should have the permission to access the package. Such that when I would run in a privileged section there, I would get package access. And if I wouldn't run privileged then all the calling frames would be checked and the check might not be passed. Wouldn't that be the right way? Yes, I think something like this is worth considering but needs to be prototyped and carefully reviewed before we would be able to consider it. I can file an issue to track this, but in my opinion it is too late for JDK 9. Thanks, Sean From christoph.langer at sap.com Fri May 12 15:05:17 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 12 May 2017 15:05:17 +0000 Subject: FW: SecurityManager.checkPackageAccess for qualified exports In-Reply-To: <8c481296-d67d-5d71-92e7-14722e359366@oracle.com> References: <4914956cf9844235b352aa33f1af5873@sap.com> <4034d08b-2144-aaa8-2492-fbcab76cf402@oracle.com> <5c1e2539321540ab89a6f9a02271baf0@sap.com> <8c481296-d67d-5d71-92e7-14722e359366@oracle.com> Message-ID: <5cc46dcb51104f84a73df02ecda33056@sap.com> Hi Sean, it's great that you seem to agree. :) So, I would definitely like if you could file a bug. And, it's ok if it won't make it into JDK 9 - the "workaround" is to explicitly grant the permission to my module. Please let me know once you created the bug - or just add me as watcher. Thanks Christoph > -----Original Message----- > From: Sean Mullan [mailto:sean.mullan at oracle.com] > Sent: Freitag, 12. Mai 2017 17:02 > To: Langer, Christoph ; Security Dev OpenJDK > > Subject: Re: FW: SecurityManager.checkPackageAccess for qualified exports > > On 5/12/17 9:14 AM, Langer, Christoph wrote: > > Hi Sean, > > > > thanks for your response. > > > >>> > >>> *Implementation Note:*** > >>> > >>> This implementation also restricts all non-exported packages of modules > >>> loaded bythe platform class loader > >>> > >> > >> getPlatformClassLoader-->or > >>> its ancestors. A "non-exported package" refers to a package that is not > >>> exported to all modules. Specifically, it refers to a package that > >>> either is not exported at all by its containing module or is exported in > >>> a qualified fashion by its containing module. > >>> > >>> Reading this, I'm wondering whether the implementation should > implicitly > >>> grant package access for modules that a package in question was > exported > >>> to in a qualified fashion? Now one ends up having to additionally add > >>> specific permissions which can easily be forgot. > >> > >> It was considered. In particular, the security permission check that is > >> done when loading classes of non-exported packages is essentially > >> equivalent to the module access check. However, in other package access > >> checking cases, the SecurityManager check does a full stack walk and > >> checks that every relevant ProtectionDomain on the stack has permission > >> to access the non-exported package. The module access check only > checks > >> if the source module has access. There was some concern that this may > >> not be sufficient to guard against all possible attack scenarios. > > > > I think the package access check walking down the whole stack is fine and > should be done here, not just the module access check. > > > > However, frames originating out of a module that the package was > exported to should have the permission to access the package. Such that > when I would run in a privileged section there, I would get package access. > And if I wouldn't run privileged then all the calling frames would be checked > and the check might not be passed. Wouldn't that be the right way? > > Yes, I think something like this is worth considering but needs to be > prototyped and carefully reviewed before we would be able to consider > it. I can file an issue to track this, but in my opinion it is too late > for JDK 9. > > Thanks, > Sean From mandy.chung at oracle.com Fri May 12 16:11:52 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 May 2017 09:11:52 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <8bf39416-d566-a192-86c3-ee04f55c2b5f@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> <5cd74a85-eee3-d892-5bd0-cd0e1c2fa0f8@oracle.com> <8bf39416-d566-a192-86c3-ee04f55c2b5f@oracle.com> Message-ID: <8EA37F21-9000-4BF1-AA95-82D8FF2C558A@oracle.com> > On May 11, 2017, at 3:25 PM, Brent Christian wrote: > > Hi, > > I have one more update, with a couple of suggested changes to simplify the execute() calls: > > * execute() takes a vararg, so explicit String[] creation can be omitted (mostly). > > * args common to every execute() call are consolidated into a List. (The resulting arg reordering should not affect test execution.) > > http://cr.openjdk.java.net/~bchristi/8177328/webrev.02/ This looks much cleaner. Thanks for the change. Minor comment: 95 private final List COMMON_ARGS; This is an instance field and you can use lower case as the convention. 238 return !s.equals(""); You can consider using String::isEmpty. No need for an updated webrev. Thanks Mandy From mandy.chung at oracle.com Fri May 12 17:04:05 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 May 2017 10:04:05 -0700 Subject: SecurityManager.checkPackageAccess for qualified exports In-Reply-To: <8c481296-d67d-5d71-92e7-14722e359366@oracle.com> References: <4914956cf9844235b352aa33f1af5873@sap.com> <4034d08b-2144-aaa8-2492-fbcab76cf402@oracle.com> <5c1e2539321540ab89a6f9a02271baf0@sap.com> <8c481296-d67d-5d71-92e7-14722e359366@oracle.com> Message-ID: > On May 12, 2017, at 8:01 AM, Sean Mullan wrote: > > On 5/12/17 9:14 AM, Langer, Christoph wrote: >> >> I think the package access check walking down the whole stack is fine and should be done here, not just the module access check. One thing to mention is that the application class loader?s loadClass method calls SecurityManager::checkPackageAccess which is stack-based permission check. When a class is being loaded by the application class loader, package access permission is checked. >> However, frames originating out of a module that the package was exported to should have the permission to access the package. Such that when I would run in a privileged section there, I would get package access. And if I wouldn't run privileged then all the calling frames would be checked and the check might not be passed. Wouldn't that be the right way? > > Yes, I think something like this is worth considering but needs to be prototyped and carefully reviewed before we would be able to consider it. I can file an issue to track this, but in my opinion it is too late for JDK 9. We discussed this and agree to improve it in a future release. In particular when a module M1 exports qualifiedly to M2, it?d be good to skip that the package access check. Mandy From sean.mullan at oracle.com Fri May 12 17:59:29 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 May 2017 13:59:29 -0400 Subject: [9] RFR: 8180307: Add new JDK 9 Required Algorithms to Cipher class Message-ID: <18087d16-637b-4c06-a2fb-28c7af7d3eb5@oracle.com> A couple of new required algorithms for JDK 9 were accidentally omitted for the Cipher class as part of JDK-8015388. Docs only change. diff --git a/src/java.base/share/classes/javax/crypto/Cipher.java b/src/java.base/share/classes/javax/crypto/Cipher.java --- a/src/java.base/share/classes/javax/crypto/Cipher.java +++ b/src/java.base/share/classes/javax/crypto/Cipher.java @@ -137,6 +137,8 @@ *
  • {@code AES/CBC/PKCS5Padding} (128)
    • *
  • {@code AES/ECB/NoPadding} (128)
    • *
  • {@code AES/ECB/PKCS5Padding} (128)
    • + *
  • {@code AES/GCM/NoPadding} (128)
    • + *
  • {@code AES/GCM/PKCS5Padding} (128)
    • *
  • {@code DES/CBC/NoPadding} (56)
    • *
  • {@code DES/CBC/PKCS5Padding} (56)
    • *
  • {@code DES/ECB/NoPadding} (56)
    • Thanks, Sean From ecki at zusammenkunft.net Fri May 12 19:20:00 2017 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 12 May 2017 21:20:00 +0200 Subject: [9] RFR: 8180307: Add new JDK 9 Required Algorithms to Cipher class In-Reply-To: <18087d16-637b-4c06-a2fb-28c7af7d3eb5@oracle.com> References: <18087d16-637b-4c06-a2fb-28c7af7d3eb5@oracle.com> Message-ID: Is the PKCS5 Padding a real padding with GCM or only an ignored alias? If it is an alias, should it be documented here? 2017-05-12 19:59 GMT+02:00 Sean Mullan : > A couple of new required algorithms for JDK 9 were accidentally omitted > for the Cipher class as part of JDK-8015388. Docs only change. > > diff --git a/src/java.base/share/classes/javax/crypto/Cipher.java > b/src/java.base/share/classes/javax/crypto/Cipher.java > --- a/src/java.base/share/classes/javax/crypto/Cipher.java > +++ b/src/java.base/share/classes/javax/crypto/Cipher.java > @@ -137,6 +137,8 @@ > *
  • {@code AES/CBC/PKCS5Padding} (128)
    • > *
  • {@code AES/ECB/NoPadding} (128)
    • > *
  • {@code AES/ECB/PKCS5Padding} (128)
    • > + *
  • {@code AES/GCM/NoPadding} (128)
    • > + *
  • {@code AES/GCM/PKCS5Padding} (128)
    • > *
  • {@code DES/CBC/NoPadding} (56)
    • > *
  • {@code DES/CBC/PKCS5Padding} (56)
    • > *
  • {@code DES/ECB/NoPadding} (56)
    • > > Thanks, > Sean > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri May 12 23:03:43 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 12 May 2017 16:03:43 -0700 Subject: [9] RFR: 8180307: Add new JDK 9 Required Algorithms to Cipher class In-Reply-To: <18087d16-637b-4c06-a2fb-28c7af7d3eb5@oracle.com> References: <18087d16-637b-4c06-a2fb-28c7af7d3eb5@oracle.com> Message-ID: <26dfa371-4b4c-db2e-a901-45c090a2e751@oracle.com> GCM mode does not need padding, so the required algorithm should just be AES/GCM/NoPadding only. Valerie On 5/12/2017 10:59 AM, Sean Mullan wrote: > A couple of new required algorithms for JDK 9 were accidentally > omitted for the Cipher class as part of JDK-8015388. Docs only change. > > diff --git a/src/java.base/share/classes/javax/crypto/Cipher.java > b/src/java.base/share/classes/javax/crypto/Cipher.java > --- a/src/java.base/share/classes/javax/crypto/Cipher.java > +++ b/src/java.base/share/classes/javax/crypto/Cipher.java > @@ -137,6 +137,8 @@ > *
  • {@code AES/CBC/PKCS5Padding} (128)
    • > *
  • {@code AES/ECB/NoPadding} (128)
    • > *
  • {@code AES/ECB/PKCS5Padding} (128)
    • > + *
  • {@code AES/GCM/NoPadding} (128)
    • > + *
  • {@code AES/GCM/PKCS5Padding} (128)
    • > *
  • {@code DES/CBC/NoPadding} (56)
    • > *
  • {@code DES/CBC/PKCS5Padding} (56)
    • > *
  • {@code DES/ECB/NoPadding} (56)
    • > > Thanks, > Sean From bradford.wetmore at oracle.com Fri May 12 23:52:43 2017 From: bradford.wetmore at oracle.com (Brad R. Wetmore) Date: Fri, 12 May 2017 16:52:43 -0700 Subject: [9] RFR: 8180307: Add new JDK 9 Required Algorithms to Cipher class In-Reply-To: <26dfa371-4b4c-db2e-a901-45c090a2e751@oracle.com> References: <18087d16-637b-4c06-a2fb-28c7af7d3eb5@oracle.com> <26dfa371-4b4c-db2e-a901-45c090a2e751@oracle.com> Message-ID: On 5/12/2017 4:03 PM, Valerie Peng wrote: > > GCM mode does not need padding, so the required algorithm should just be > AES/GCM/NoPadding only. +1. Brad > Valerie > > > On 5/12/2017 10:59 AM, Sean Mullan wrote: >> A couple of new required algorithms for JDK 9 were accidentally >> omitted for the Cipher class as part of JDK-8015388. Docs only change. >> >> diff --git a/src/java.base/share/classes/javax/crypto/Cipher.java >> b/src/java.base/share/classes/javax/crypto/Cipher.java >> --- a/src/java.base/share/classes/javax/crypto/Cipher.java >> +++ b/src/java.base/share/classes/javax/crypto/Cipher.java >> @@ -137,6 +137,8 @@ >> *
  • {@code AES/CBC/PKCS5Padding} (128)
    • >> *
  • {@code AES/ECB/NoPadding} (128)
    • >> *
  • {@code AES/ECB/PKCS5Padding} (128)
    • >> + *
  • {@code AES/GCM/NoPadding} (128)
    • >> + *
  • {@code AES/GCM/PKCS5Padding} (128)
    • >> *
  • {@code DES/CBC/NoPadding} (56)
    • >> *
  • {@code DES/CBC/PKCS5Padding} (56)
    • >> *
  • {@code DES/ECB/NoPadding} (56)
    • >> >> Thanks, >> Sean > From weijun.wang at oracle.com Sat May 13 00:50:28 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 13 May 2017 08:50:28 +0800 Subject: [10] RFR 8166222: Don't treat signed jars with invalid timestamps as unsigned In-Reply-To: <7302090f-18fc-04e7-ff03-2a031b7d8c1e@oracle.com> References: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com> <7302090f-18fc-04e7-ff03-2a031b7d8c1e@oracle.com> Message-ID: <42608afe-d8d3-f9c4-740c-5cfefa0363bb@oracle.com> I assume we will backport this to jdk9u. So I'd like to fix the newly found regression JDK-8180289 along with this bug, since both are about CertPath validation warning messages. I'll need some time thinking about a proper fix. The current warning message on cert expiration is only on "signer certificate", and CertPath validation will report expirations on intermediate CA certs as well as TSA certs. I don't think it's a good idea to print different warnings for them (and their -strict exit codes are all 4) and might show the info in -verbose -certs outputs. Thanks Max On 05/12/2017 11:19 AM, Anthony Scarpino wrote: > I think your code looks good. > > You should check the CertPathValidator tests, I think one of them might > fail after this change. > > Tony > > > On 05/10/2017 04:36 PM, Weijun Wang wrote: >> Ping again. >> >> On 04/12/2017 11:52 PM, Weijun Wang wrote: >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8166222/webrev.00/ >>> >>> The major code change is inside SignatureFileVerifier.java. Now if the >>> timestamp on a signed jar is invalid (For example, using a weak >>> algorithm now disabled), the jar file will be treated as a signed jar >>> without a timestamp. Before this change, it was treated unsigned. >>> >>> In jarsigner/Main.java, I also add a line to validate the TSA cert >>> chain. If not validated, a warning will be shown which is similar to the >>> one when signer cert chain is not validated. If -strict is on, exit code >>> will change too. >>> >>> I also make a small change at >>> >>> http://cr.openjdk.java.net/~weijun/8166222/root/webrev.00/ >>> >>> The executeCommand() method shows more info (mainly stdout and stderr >>> outputs) than executeProcess(). >>> >>> Because of the behavior change and new warnings, this change will need a >>> Compatibility and Specification Review (CSR). At the moment, please >>> review the code change first. >>> >>> Thanks >>> Max > From sean.mullan at oracle.com Mon May 15 18:25:47 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 15 May 2017 14:25:47 -0400 Subject: [9] RFR: 8180307: Add new JDK 9 Required Algorithms to Cipher class In-Reply-To: References: <18087d16-637b-4c06-a2fb-28c7af7d3eb5@oracle.com> <26dfa371-4b4c-db2e-a901-45c090a2e751@oracle.com> Message-ID: On 5/12/17 7:52 PM, Brad R. Wetmore wrote: > On 5/12/2017 4:03 PM, Valerie Peng wrote: >> >> GCM mode does not need padding, so the required algorithm should just be >> AES/GCM/NoPadding only. > > +1. Good catch. I will need to file a CCC to get AES/GCM/PKCS5Padding dropped from the requirements because it was already (accidentally) approved as part of JDK-8015388. --Sean > Brad > > >> Valerie >> >> >> On 5/12/2017 10:59 AM, Sean Mullan wrote: >>> A couple of new required algorithms for JDK 9 were accidentally >>> omitted for the Cipher class as part of JDK-8015388. Docs only change. >>> >>> diff --git a/src/java.base/share/classes/javax/crypto/Cipher.java >>> b/src/java.base/share/classes/javax/crypto/Cipher.java >>> --- a/src/java.base/share/classes/javax/crypto/Cipher.java >>> +++ b/src/java.base/share/classes/javax/crypto/Cipher.java >>> @@ -137,6 +137,8 @@ >>> *
  • {@code AES/CBC/PKCS5Padding} (128)
    • >>> *
  • {@code AES/ECB/NoPadding} (128)
    • >>> *
  • {@code AES/ECB/PKCS5Padding} (128)
    • >>> + *
  • {@code AES/GCM/NoPadding} (128)
    • >>> + *
  • {@code AES/GCM/PKCS5Padding} (128)
    • >>> *
  • {@code DES/CBC/NoPadding} (56)
    • >>> *
  • {@code DES/CBC/PKCS5Padding} (56)
    • >>> *
  • {@code DES/ECB/NoPadding} (56)
    • >>> >>> Thanks, >>> Sean >> From sean.mullan at oracle.com Tue May 16 20:01:06 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 16 May 2017 16:01:06 -0400 Subject: [10] RFR 8166222: Don't treat signed jars with invalid timestamps as unsigned In-Reply-To: References: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com> Message-ID: <53ca2fd6-1454-1c4f-0500-6b59744e478d@oracle.com> * Resources.java [278] s/includes/include/ * SignatureFileVerifier [728] setting ts to null in the catch block seems a bit ugly. Maybe it would be better to refactor that code into a static method that returns a valid Timestamp or null if not. * Main.java [271-2] Perhaps you should use a different exit code to distinguish it from an invalid signer chain? [1064-6] Not sure I understand this block of code. How can a jar have an invalid timestamp if -tsa was not specified? [1546-7] TODO item - Why can't we do this? We need to warn the user if they sign a JAR and the TSA chain is invalid so they know what to expect and are not surprised when it stops working the day after the signer's cert expires. --Sean On 5/10/17 7:36 PM, Weijun Wang wrote: > Ping again. > > On 04/12/2017 11:52 PM, Weijun Wang wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8166222/webrev.00/ >> >> The major code change is inside SignatureFileVerifier.java. Now if the >> timestamp on a signed jar is invalid (For example, using a weak >> algorithm now disabled), the jar file will be treated as a signed jar >> without a timestamp. Before this change, it was treated unsigned. >> >> In jarsigner/Main.java, I also add a line to validate the TSA cert >> chain. If not validated, a warning will be shown which is similar to the >> one when signer cert chain is not validated. If -strict is on, exit code >> will change too. >> >> I also make a small change at >> >> http://cr.openjdk.java.net/~weijun/8166222/root/webrev.00/ >> >> The executeCommand() method shows more info (mainly stdout and stderr >> outputs) than executeProcess(). >> >> Because of the behavior change and new warnings, this change will need a >> Compatibility and Specification Review (CSR). At the moment, please >> review the code change first. >> >> Thanks >> Max From weijun.wang at oracle.com Thu May 18 01:50:34 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 May 2017 09:50:34 +0800 Subject: [10] RFR 8166222: Don't treat signed jars with invalid timestamps as unsigned In-Reply-To: <53ca2fd6-1454-1c4f-0500-6b59744e478d@oracle.com> References: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com> <53ca2fd6-1454-1c4f-0500-6b59744e478d@oracle.com> Message-ID: <89793d58-e08b-516a-14d7-bfc4ae058033@oracle.com> On 05/17/2017 04:01 AM, Sean Mullan wrote: > * Resources.java > > [278] s/includes/include/ > > * SignatureFileVerifier > > [728] setting ts to null in the catch block seems a bit ugly. Maybe it > would be better to refactor that code into a static method that returns > a valid Timestamp or null if not. Or I can initialize ts to be null. > > * Main.java > > [271-2] Perhaps you should use a different exit code to distinguish it > from an invalid signer chain? I can use 64. Although I am not quite sure of the usefulness of difference exit codes now. > > [1064-6] Not sure I understand this block of code. How can a jar have an > invalid timestamp if -tsa was not specified? This is in verification. Because of weak algorithms (and maybe more), it's possible that the API does not show there is a timestamp (noTimestamp) but the PKCS7 block file has a tsToken (hasTimestampBlock). I'd like to show different warnings here. > > [1546-7] TODO item - Why can't we do this? We need to warn the user if > they sign a JAR and the TSA chain is invalid so they know what to expect > and are not surprised when it stops working the day after the signer's > cert expires. Yes, we can. BTW, I am thinking of more changes. jarsigner had so many different warnings (cert expired, cert usage...) because it was not using sun.security.validator.Validator before and checked these all by its own. It should rely on Validator but keep showing the warnings for compatibility. The lines on 1992-2012 was added to deliberately avoid showing both these "legacy" warnings and validation warnings at the same time. I'd prefer to remove these lines. As long as the exit code does not change (they are all the same for signer certs, 4), showing an extra warning line is not harmful. Thanks Max > > --Sean > > On 5/10/17 7:36 PM, Weijun Wang wrote: >> Ping again. >> >> On 04/12/2017 11:52 PM, Weijun Wang wrote: >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8166222/webrev.00/ >>> >>> The major code change is inside SignatureFileVerifier.java. Now if the >>> timestamp on a signed jar is invalid (For example, using a weak >>> algorithm now disabled), the jar file will be treated as a signed jar >>> without a timestamp. Before this change, it was treated unsigned. >>> >>> In jarsigner/Main.java, I also add a line to validate the TSA cert >>> chain. If not validated, a warning will be shown which is similar to the >>> one when signer cert chain is not validated. If -strict is on, exit code >>> will change too. >>> >>> I also make a small change at >>> >>> http://cr.openjdk.java.net/~weijun/8166222/root/webrev.00/ >>> >>> The executeCommand() method shows more info (mainly stdout and stderr >>> outputs) than executeProcess(). >>> >>> Because of the behavior change and new warnings, this change will need a >>> Compatibility and Specification Review (CSR). At the moment, please >>> review the code change first. >>> >>> Thanks >>> Max From weijun.wang at oracle.com Thu May 18 06:01:51 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 May 2017 14:01:51 +0800 Subject: [10] RFR 8166222: Don't treat signed jars with invalid timestamps as unsigned In-Reply-To: <89793d58-e08b-516a-14d7-bfc4ae058033@oracle.com> References: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com> <53ca2fd6-1454-1c4f-0500-6b59744e478d@oracle.com> <89793d58-e08b-516a-14d7-bfc4ae058033@oracle.com> Message-ID: <90c8d6e2-96ad-64b0-d2ad-a480a12dda99@oracle.com> Thinking about this again. Currently we have these warnings and their exit codes (when -strict): - signer cert validity problem - 4 - signer cert keyUsage problem - 8 - other signer cert validation problems - 4 - disabled alg specified while signing - 4 We are now adding - TSA cert validation problems We also intend to add one later - weak (but not yet disabled) alg specified while signing or detected in verification If we want to be compatible with before, I'd like to reuse 8 for extendedKeyUsage issue when a TSA cert does not allow timestamping, and 4 for other TSA validation errors and weak/disabled algs. If we can be imcompatible, I am thinking of 2 - disabled alg used in signing or weak alg used in verification. 4 - any problem with signer certs 8 - any problem with TSA certs Note: 2 was used by "expired soon" some time ago but we stopped using it because this is not a real error. It's now an always-warning (like no timestamp) and no exit code. Thanks Max On 05/18/2017 09:50 AM, Weijun Wang wrote: >> [271-2] Perhaps you should use a different exit code to distinguish it >> from an invalid signer chain? > > I can use 64. Although I am not quite sure of the usefulness of > difference exit codes now. From brent.christian at oracle.com Mon May 1 19:00:20 2017 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 01 May 2017 19:00:20 -0000 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> Message-ID: <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> Hi, Joe The typical run time of this test is ~18s (on my modestly-equipped laptop). So the test does run within a reasonable amount of time, IMO - under normal circumstances, anyway. The increased timeout is to cover the less seldom test run configurations involving Xcomp. Judging by when the test was added and the dates of the failed runs, I think this test has timed out since it was introduced, and there has not been an Xcomp regression. The test checks for a recursive initialization issue (8168075), and so needs to launch JVMs using various combinations of system classloader/security manager+policy/various module types. For this reason I think Xcomp hits this test particularly hard, recompiling the startup code on every VM launch. I think we want to maintain thorough test coverage here, though. Looking more into the failures, the worst case looks to be getting not quite halfway through the test. We should be able to get away with a more modest increase to the timeout (600, instead of 1200), and still have the test pass, if you would prefer. Thanks, -Brent On 4/27/17 2:25 PM, joe darcy wrote: > I understand the interest in having test pass reliably, but I don't > think giving the test very large timeouts is the preferred way of > accomplishing that. > > For all configurations, the test can now run for up to 20 minutes, up > from 4 minutes. We want to run the entire test suite, thousands of > tests, in about 20 minutes. The the timeout factor used for Xcomp run, > the test would probably now be able to run for over an hour before > timing out. > > I suggest making the test run faster, or seeing if there has been a > regressions in Xcomp to make test perform more poorly there. > > Thanks, > > -Joe > > > On 4/27/2017 12:08 PM, Brent Christian wrote: >> Hi, >> >> This test times out under our automated testing configurations that >> include -Xcomp. >> >> Please review my change to increase the timeout for this test. It is >> sufficient for the test configurations in question to pass on two >> different local machines (Mac & Linux). >> >> diff -r 7c04ab31b4d6 >> test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >> --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >> Wed Apr 26 09:37:23 2017 -0700 >> +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >> Thu Apr 27 12:03:33 2017 -0700 >> @@ -29,7 +29,7 @@ >> * @library /lib/testlibrary >> * @modules java.base/jdk.internal.module >> * @build JarUtils CompilerUtils >> - * @run main/timeout=240 ClassLoaderTest >> + * @run main/timeout=1200 ClassLoaderTest >> */ >> >> Thanks, >> -Brent > From brent.christian at oracle.com Mon May 1 19:48:40 2017 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 01 May 2017 19:48:40 -0000 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> Message-ID: On 5/1/17 12:41 PM, Mandy Chung wrote: > Looks like this test execs a new VM for 66 times to exhaust the > combination of with and without security manager, with a valid or > malformed policy, client & custom loader in unnamed, named, automatic > module. Right. > I think we could take out the automatic module case as named > module would verify it. OK, I can do that. I'm pretty sure an increase to the timeout will still be needed, though. > One refactor you can consider by separating > them in several @run actions. The timeout will apply to each action > but that does not help shorten the test execution time. I had the same thought, and concluded that without a reduction in overall execution time, the benefit of such a refactor is pretty limited. Thanks, -Brent From brent.christian at oracle.com Mon May 1 21:16:44 2017 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 01 May 2017 21:16:44 -0000 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> Message-ID: <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> On 5/1/17 12:50 PM, Mandy Chung wrote: >> On May 1, 2017, at 12:47 PM, Brent Christian wrote: >>> >>> One refactor you can consider by separating >>> them in several @run actions. The timeout will apply to each action >>> but that does not help shorten the test execution time. >> >> I had the same thought, and concluded that without a reduction in overall execution time, the benefit of such a refactor is pretty limited. > > I think it would make the test easier to read and understand the cases it cover. > True. I'll see what I can do, then. -Brent From milton.smith.rr at gmail.com Mon May 8 19:46:19 2017 From: milton.smith.rr at gmail.com (Milton Smith) Date: Mon, 8 May 2017 12:46:19 -0700 Subject: JEP-123: Configurable Secure Random-Number Generation Message-ID: Anyone, Wondering if anyone has information(link/docs) on how JEP-123 was implemented? Specifically, interested in the situation where the caller blocks on lack of entropy and how that was addressed. I took a look at the JEP-123 and JavaDocs but it?s not obvious to me. Following is related JEP-123 information, http://openjdk.java.net/jeps/123 . Thanks! Regards, Milton -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent.christian at oracle.com Tue May 9 23:23:49 2017 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 9 May 2017 16:23:49 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> Message-ID: <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> Brent Christian wrote: > Mandy Chung wrote: >> >> I think we could take out the automatic module case as named module >> would verify it. One refactor you can consider by separating them >> in several @run actions. >> ... >> I think it would make the test easier to read and understand the cases >> it cover. > > True. I'll see what I can do, then. I've removed the test case for automatic modules, and added a @run action for each policy file + system classloader configuration. I also removed the code to compile test sources, using @build instead. I also made some (hopefully) clarifying changes to the code. The String[] argument to execute() is now separated into args/status/message, instead of being lumped into one String[], and then having to be split() out of a single String. Where execute() is called, it's easier to read the args in order (versus assembled using String.format()). I also simplified the code for expected status/output, and made some path variable names more descriptive. Webrev: http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ Thanks, -Brent From brent.christian at oracle.com Tue May 9 23:39:47 2017 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 9 May 2017 16:39:47 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> Message-ID: On 5/9/17 4:27 PM, Mandy Chung wrote: >> >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ > > Thanks for the clean up. Does each @run action need 4 mins timeout? Can it restore to the default timeout? Yes. Between the additional @runs and no longer testing automated modules, I believe that should be fine. -Brent From brent.christian at oracle.com Wed May 10 16:42:36 2017 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 10 May 2017 09:42:36 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> Message-ID: <5cd74a85-eee3-d892-5bd0-cd0e1c2fa0f8@oracle.com> On 5/9/17 4:39 PM, Brent Christian wrote: > On 5/9/17 4:27 PM, Mandy Chung wrote: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ >> >> Can it restore to the default timeout? > > Yes. Between the additional @runs and no longer testing automated > modules, I believe that should be fine. Webrev updated in place, with the timeout value removed. -Brent From brent.christian at oracle.com Thu May 11 22:25:02 2017 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 11 May 2017 15:25:02 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <5cd74a85-eee3-d892-5bd0-cd0e1c2fa0f8@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> <5cd74a85-eee3-d892-5bd0-cd0e1c2fa0f8@oracle.com> Message-ID: <8bf39416-d566-a192-86c3-ee04f55c2b5f@oracle.com> Hi, I have one more update, with a couple of suggested changes to simplify the execute() calls: * execute() takes a vararg, so explicit String[] creation can be omitted (mostly). * args common to every execute() call are consolidated into a List. (The resulting arg reordering should not affect test execution.) http://cr.openjdk.java.net/~bchristi/8177328/webrev.02/ Thanks, -Brent On 5/10/17 9:42 AM, Brent Christian wrote: > On 5/9/17 4:39 PM, Brent Christian wrote: >> On 5/9/17 4:27 PM, Mandy Chung wrote: >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ >>> >>> Can it restore to the default timeout? >> >> Yes. Between the additional @runs and no longer testing automated >> modules, I believe that should be fine. > > Webrev updated in place, with the timeout value removed. > > -Brent > From brent.christian at oracle.com Fri May 12 17:10:11 2017 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 12 May 2017 10:10:11 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <8EA37F21-9000-4BF1-AA95-82D8FF2C558A@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> <5cd74a85-eee3-d892-5bd0-cd0e1c2fa0f8@oracle.com> <8bf39416-d566-a192-86c3-ee04f55c2b5f@oracle.com> <8EA37F21-9000-4BF1-AA95-82D8FF2C558A@oracle.com> Message-ID: <2ec6153e-5cbf-1458-449b-7ac6755f0aa8@oracle.com> On 5/12/17 9:11 AM, Mandy Chung wrote: > > Minor comment: > 95 private final List COMMON_ARGS; > > This is an instance field and you can use lower case as the convention. > > 238 return !s.equals(""); > > You can consider using String::isEmpty. Thanks, Mandy. I will make these changes before pushing. -Brent From ivan.gerasimov at oracle.com Fri May 19 16:25:56 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 19 May 2017 09:25:56 -0700 Subject: [jdk8u-dev] Review Request and Approval to Backport: 8140436: Support the FFDHE TLS extension Message-ID: <6e0b055c-d4d2-5e43-4585-aed1ab66976b@oracle.com> Hello! The backport didn't apply cleanly, but was mostly straight-forward. Could you please help review it and, once reviewed, approve for integrating into jdk8u-dev codebase? Bug: https://bugs.openjdk.java.net/browse/JDK-8140436 Jdk10 change: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/87290d66b649 Jdk10 review: http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015790.html Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8140436/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From sean.coffey at oracle.com Mon May 22 08:30:03 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 22 May 2017 09:30:03 +0100 Subject: [jdk8u-dev] Review Request and Approval to Backport: 8140436: Support the FFDHE TLS extension In-Reply-To: <6e0b055c-d4d2-5e43-4585-aed1ab66976b@oracle.com> References: <6e0b055c-d4d2-5e43-4585-aed1ab66976b@oracle.com> Message-ID: Ivan, this is an enhancement backport request for jdk8u. As a result, it's subject to extra steps before push approval can be considered. See Rule 3 : http://openjdk.java.net/projects/jdk8u/groundrules.html regards, Sean. On 19/05/2017 17:25, Ivan Gerasimov wrote: > Hello! > > The backport didn't apply cleanly, but was mostly straight-forward. > > Could you please help review it and, once reviewed, approve for > integrating into jdk8u-dev codebase? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140436 > Jdk10 change: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/87290d66b649 > Jdk10 review: > http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015790.html > > Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8140436/00/webrev/ > > Thanks in advance! > From weijun.wang at oracle.com Mon May 22 15:43:49 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 May 2017 23:43:49 +0800 Subject: [10] RFR 8166222: Don't treat signed jars with invalid timestamps as unsigned In-Reply-To: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com> References: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com> Message-ID: <10e34c58-0b55-0b75-8500-64ba2cc7386b@oracle.com> An updated webrev at http://cr.openjdk.java.net/~weijun/8166222/webrev.01/ Some more changes: - TSA cert chain validation is performed in both verification and signing. The exit code for validation failure when -strict is specified is 64. - printCert() and validateCertChain() know about they are dealing with TSA cert chain and do not touch any flag except for tsaChainNotValidated. Code being a little ugly. - TSA certs lines added to -verbose -certs. BTW, the code change also fixed https://bugs.openjdk.java.net/browse/JDK-8180289. Here is an example: $ jarsigner -verify -strict ts2.jar -verbose -certs s k 75 Mon May 22 22:49:06 CST 2017 META-INF/MANIFEST.MF [entry was signed on 5/22/17, 10:49 PM] >>> Signer X.509, CN=signer (signer) [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM] X.509, CN=CA (ca) [certificate is valid from 4/12/17, 10:49 PM to 10/29/17, 10:49 PM] >>> TSA X.509, CN=ts [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM] [ExtendedKeyUsage extension does not support timestamping] [TSA CertPath not validated: Extended key usage does not permit use for TSA server] 305 Mon May 22 22:49:08 CST 2017 META-INF/SIGNER.SF 3096 Mon May 22 22:51:06 CST 2017 META-INF/SIGNER.RSA smk 1 Mon May 22 22:48:56 CST 2017 A [entry was signed on 5/22/17, 10:49 PM] >>> Signer X.509, CN=signer (signer) [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM] X.509, CN=CA (ca) [certificate is valid from 4/12/17, 10:49 PM to 10/29/17, 10:49 PM] >>> TSA X.509, CN=ts [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM] [TSA CertPath not validated: Extended key usage does not permit use for TSA server] s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore - Signed by "CN=signer" Digest algorithm: SHA-256 Signature algorithm: SHA256withRSA, 2048-bit key Timestamped by "CN=ts" on Mon May 22 14:49:08 UTC 2017 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA1withRSA, 2048-bit key jar verified, with signer errors. Error: This jar contains entries whose TSA certificate chain is not validated. Reason: Extended key usage does not permit use for TSA server Thanks Max On 04/12/2017 11:52 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8166222/webrev.00/ > > The major code change is inside SignatureFileVerifier.java. Now if the > timestamp on a signed jar is invalid (For example, using a weak > algorithm now disabled), the jar file will be treated as a signed jar > without a timestamp. Before this change, it was treated unsigned. > > In jarsigner/Main.java, I also add a line to validate the TSA cert > chain. If not validated, a warning will be shown which is similar to the > one when signer cert chain is not validated. If -strict is on, exit code > will change too. > > I also make a small change at > > http://cr.openjdk.java.net/~weijun/8166222/root/webrev.00/ > > The executeCommand() method shows more info (mainly stdout and stderr > outputs) than executeProcess(). > > Because of the behavior change and new warnings, this change will need a > Compatibility and Specification Review (CSR). At the moment, please > review the code change first. > > Thanks > Max From adam.petcher at oracle.com Mon May 22 19:57:41 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 22 May 2017 15:57:41 -0400 Subject: RFR 8172244: AIOOBE in KeyStore.getCertificateAlias on Windows Message-ID: <3cd6cc0a-1b4e-e814-8aa2-3696416664ba@oracle.com> This is a bug fix related to keys without certificates in the Windows key store. When a key doesn't have a certificate, the native code will set the list of certificates to an empty list. Some of the Java code for the MSCAPI provider doesn't handle this case correctly and throws an AIOOBE. The regression test reproduces the same circumstances in the Java code by bypassing some checks in the KeyStore interface, allowing us to test this without upsetting the test environment. JBS: https://bugs.openjdk.java.net/browse/JDK-8172244 Webrev: http://cr.openjdk.java.net/~apetcher/8172244/webrev.00/ From volker.simonis at gmail.com Tue May 23 07:27:22 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 May 2017 09:27:22 +0200 Subject: JPMS Access Checks, Verification and the Security Manager Message-ID: Hi, my question is if it is OK for a program which otherwise runs fine to fail during class verification if running with a security manager because of module access restrictions? As the following write-up got a little lengthy, I've also uploaded a html version for a nicer reading experience :) http://cr.openjdk.java.net/~simonis/webrevs/2017/veri_with_secman/sm.html Consider the following small, self-contained program which statically references com.sun.crypto.provider.SunJCE: import java.security.Provider; import com.sun.crypto.provider.SunJCE; public class Tricky { public static void main(String args[]) throws Exception { try { System.out.println(Tricky.class + " (" + Tricky.class.getClassLoader() + ")" + args[0]); } catch (Exception e) { Provider p = new SunJCE(); System.out.println(p + " (" + p.toString() + ")"); } } } This program easily compiles and runs with Oracle/OpenJDK 8: $ javac Tricky $ java Tricky "" class Tricky (sun.misc.Launcher$AppClassLoader at 4e0e2f2a) $ java Tricky SunJCE version 1.8 (SunJCE version 1.8) The second invocation (without argument) will cause an exception (when trying to access the first element of the zero length argument array at 'args[0]') which will be caught in the exception handler where we create a new 'SunJCE' object and print its string representation to stdout. The first invocation (with an empty argument) doesn't provoke an exception and will just print the class itself together with its class loader. When we run the same (jdk8 compiled) program with jdk9, we'll see the following result: $ jdk9/java Tricky "" class Tricky (jdk.internal.loader.ClassLoaders$AppClassLoader at ba8a1dc) $ jdk9/java Tricky Exception in thread "main" java.lang.IllegalAccessError: class Tricky (in unnamed module @0x3b192d32) cannot access class com.sun.crypto.provider.SunJCE (in module java.base) because module java.base does not export com.sun.crypto.provider to unnamed module @0x3b192d32 at Tricky.main(Tricky.java:11) $ jdk9/java --add-exports java.base/com.sun.crypto.provider=ALL-UNNAMED Tricky SunJCE version 9 (SunJCE version 9) The first invocation (with an empty argument) still works because we have lazy class loading and 'SunJCE' provider is actually never used. The second invocation (without argument) obviously fails with jdk9 because 'java.base' doesn't export the package com.sun.crypto.provider anymore. This can be fixed by adding '--add-exports java.base/com.sun.crypto.provider=ALL-UNNAMED' to the command line as demonstrated in the third invocation. So far so good - everything worked as expected till now. Now let's run the same program with the default security manager: $ java -Djava.security.manager Tricky "" class Tricky (sun.misc.Launcher$AppClassLoader at 4e0e2f2a) $ java -Djava.security.manager Tricky SunJCE version 1.8 (SunJCE version 1.8) The security manager doesn't change anything for jdk8! So let's try with jdk9: $ jdk9/java -Djava.security.manager Tricky "" Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.crypto.provider") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:471) at java.base/java.security.AccessController.checkPermission(AccessController.java:894) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:561) at java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534) at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:671) at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:669) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:669) at java.base/java.lang.Class.getDeclaredMethods0(Native Method) at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3129) at java.base/java.lang.Class.getMethodsRecursive(Class.java:3270) at java.base/java.lang.Class.getMethod0(Class.java:3256) at java.base/java.lang.Class.getMethod(Class.java:2057) at java.base/sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:712) at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:570) The first invocation (with an empty argument) crashes with a strange JNI error. The call stack unveils that we haven't even entered the main method of our program. Instead we've crashed in the jdk-internal launcher 'sun.launcher.LauncherHelper' during 'checkAndLoadMain()' with a 'java.security.AccessControlException' because we couldn't access the 'com.sun.crypto.provider' package. That's strange because we shouldn't need to load SunJCE provider for this invocation because of lazy class loading. A little reasoning and the right Xlog parameter unveils that the exception happens during class verification: $ jdk9/java -Djava.security.manager -Xlog:verification Tricky "" ... [1,382s][info][verification] locals: { '[Ljava/lang/String;', 'java/lang/Exception', 'com/sun/crypto/provider/SunJCE' } [1,382s][info][verification] stack: { 'java/io/PrintStream', 'java/lang/StringBuilder', 'com/sun/crypto/provider/SunJCE' } [1,382s][info][verification] offset = 77, opcode = invokevirtual [1,589s][info][verification] Verification for Tricky has exception pending java.security.AccessControlException [1,589s][info][verification] End class verification for: Tricky Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.crypto.provider") ... And indeed, switching off class verification will fix the problem: $ jdk9/java -Djava.security.manager -Xlog:verification -noverify Tricky "" class Tricky (jdk.internal.loader.ClassLoaders$AppClassLoader at 1b9e1916) But switching off class verification is not something we usually want to do! So we can try to use '--add-exports java.base/com.sun.crypto.provider=ALL-UNNAMED' (although this wasn't needed without security manager): $ jdk9/java -Djava.security.manager --add-exports java.base/com.sun.crypto.provider=ALL-UNNAMED Tricky "" Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.crypto.provider") ... but the result is still the same. If you feel that '--add-exports java.base/com.sun.crypto.provider=ALL-UNNAMED' should have fixed the problem, you're not alone. That issue is tracked under JDK-8174766 [1]. It was discussed in the review [2] for JDK-8055206 [3] which introduced the problem. Currently, the only way to fix the problem is to add additional permissions through a custom security policy: my.policy --------- grant { permission java.lang.RuntimePermission "accessClassInPackage.com.sun.crypto.provider"; }; $ jdk9/java -Djava.security.manager -Djava.security.policy=my.policy Tricky "" class Tricky (jdk.internal.loader.ClassLoaders$AppClassLoader at 1b9e1916) But the real question remains: why does class verification fails with a security manager and succeeds without? With the right Xlog parameters we can verify, that even without security manager, the 'SunJCE' class is successfully loaded by the verifier for the purpose of verification, and the execution of the program succeeds if we don't reference 'SunJCE' during execution: $ jdk9/java -Xlog:verification -Xlog:class+load Tricky "" ... [1,193s][info][verification] locals: { '[Ljava/lang/String;', 'java/lang/Exception', 'com/sun/crypto/provider/SunJCE' } [1,193s][info][verification] stack: { 'java/io/PrintStream', 'java/lang/StringBuilder', 'com/sun/crypto/provider/SunJCE' } [1,193s][info][verification] offset = 77, opcode = invokevirtual [1,196s][info][class,load ] java.security.Provider source: jrt:/java.base [1,197s][info][class,load ] com.sun.crypto.provider.SunJCE source: jrt:/java.base ... [1,198s][info][verification] End class verification for: Tricky ... class Tricky (jdk.internal.loader.ClassLoaders$AppClassLoader at ba8a1dc) So how does the presence of a security manager changes the class verification process? With a security manager, there are two additional 'accessClassInPackage' checks during class loading. If we recall the verifier log: [1,193s][info][verification] locals: { '[Ljava/lang/String;', 'java/lang/Exception', 'com/sun/crypto/provider/SunJCE' } [1,193s][info][verification] stack: { 'java/io/PrintStream', 'java/lang/StringBuilder', 'com/sun/crypto/provider/SunJCE' } [1,193s][info][verification] offset = 77, opcode = invokevirtual [1,196s][info][class,load ] java.security.Provider source: jrt:/java.base [1,197s][info][class,load ] com.sun.crypto.provider.SunJCE source: jrt:/java.base we see that the verifier has to prove that 'com/sun/crypto/provider/SunJCE' (which is on top of the stack) can be assigned (i.e. is assign-compatible) to 'java.security.Provider' and it is therefor safe to call 'Provider::toString()' on it. Therefor, in order to load the class 'com.sun.crypto.provider.SunJCE', the verifier calls 'SystemDictionary::resolve_or_fail()' which in the end calls 'ClassLoader.loadClass(_class_name)' on the class loader of the class under verification. If that class is a user class, this will call 'jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass()' in Java 9 because that's the actual application class loader (aka system class loader) and ClassLoaders$AppClassLoader.loadClass() will perform the following check if the VM runs with a security manager: @Override protected Class loadClass(String cn, boolean resolve) throws ClassNotFoundException { SecurityManager sm = System.getSecurityManager(); if (sm != null) { int i = cn.lastIndexOf('.'); if (i != -1) { sm.checkPackageAccess(cn.substring(0, i)); } } return super.loadClass(cn, resolve); } Here's the corresponding VM stack trace: j java.lang.SecurityManager.checkPackageAccess(Ljava/lang/String;)V+46 java.base at 9-internal j jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+8 java.base at 9-internal j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 java.base at 9-internal v ~StubRoutines::call_stub V [libjvm.so+0xc6c75d] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6a5 V [libjvm.so+0x1055bab] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x41 V [libjvm.so+0xc6c0a2] JavaCalls::call(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0xaa V [libjvm.so+0xc6b1b3] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x1f1 V [libjvm.so+0xc6b3f0] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Handle, Thread*)+0xd2 V [libjvm.so+0x1201c56] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x93c V [libjvm.so+0x11feda0] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x8c0 V [libjvm.so+0x11fd298] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x262 V [libjvm.so+0x11fcca3] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x45 V [libjvm.so+0x1286586] VerificationType::resolve_and_check_assignability(instanceKlassHandle, Symbol*, Symbol*, bool, bool, bool, Thread*)+0x258 V [libjvm.so+0x128682e] VerificationType::is_reference_assignable_from(VerificationType const&, ClassVerifier*, bool, Thread*) const+0x212 V [libjvm.so+0x118fa55] VerificationType::is_assignable_from(VerificationType const&, ClassVerifier*, bool, Thread*) const+0x191 V [libjvm.so+0x129a98f] StackMapFrame::pop_stack(VerificationType, Thread*)+0x81 V [libjvm.so+0x12978f3] ClassVerifier::verify_invoke_instructions(RawBytecodeStream*, unsigned int, StackMapFrame*, bool, bool*, VerificationType, constantPoolHandle const&, StackMapTable*, Thread*)+0x1249 V [libjvm.so+0x129096b] ClassVerifier::verify_method(methodHandle const&, Thread*)+0x6b71 V [libjvm.so+0x1289d1a] ClassVerifier::verify_class(Thread*)+0x12a V [libjvm.so+0x1287c9e] Verifier::verify(instanceKlassHandle, Verifier::Mode, bool, Thread*)+0x2c0 V [libjvm.so+0xc2b9b0] InstanceKlass::verify_code(instanceKlassHandle, bool, Thread*)+0x7c V [libjvm.so+0xc2c228] InstanceKlass::link_class_impl(instanceKlassHandle, bool, Thread*)+0x55e V [libjvm.so+0xc2bb3d] InstanceKlass::link_class(Thread*)+0xdf V [libjvm.so+0xcf5f80] get_class_declared_methods_helper(JNIEnv_*, _jclass*, unsigned char, bool, Klass*, Thread*)+0x155 V [libjvm.so+0xcf6570] JVM_GetClassDeclaredMethods+0x1d9 j java.lang.Class.getDeclaredMethods0(Z)[Ljava/lang/reflect/Method;+0 java.base at 9-internal j java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method;+34 java.base at 9-internal j java.lang.Class.getMethodsRecursive(Ljava/lang/String;[Ljava/lang/Class;Z)Ljava/lang/PublicMethods$MethodList;+2 java.base at 9-internal j java.lang.Class.getMethod0(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;+14 java.base at 9-internal j java.lang.Class.getMethod(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;+26 java.base at 9-internal j sun.launcher.LauncherHelper.validateMainClass(Ljava/lang/Class;)V+12 java.base at 9-internal j sun.launcher.LauncherHelper.checkAndLoadMain(ZILjava/lang/String;)Ljava/lang/Class;+54 java.base at 9-internal This check succeeds, because class-loading is triggered from sun.launcher.LauncherHelper which is in the 'java.base' package, just like the 'com.sun.crypto.provider.SunJCE' package. But when running with a security manager, there's also a second check, which is performed in the VM by 'SystemDictionary::resolve_instance_class_or_null()', right before it returns the loaded class, by calling 'SystemDictionary::validate_protection_domain()'. This method in turn calls 'java.lang.ClassLoader.checkPackageAccess()' to validate the package access: // Invoked by the VM after loading class with this loader. private void checkPackageAccess(Class cls, ProtectionDomain pd) { final SecurityManager sm = System.getSecurityManager(); if (sm != null) { ... final String name = cls.getName(); final int i = name.lastIndexOf('.'); if (i != -1) { AccessController.doPrivileged(new PrivilegedAction<>() { public Void run() { sm.checkPackageAccess(name.substring(0, i)); return null; } }, new AccessControlContext(new ProtectionDomain[] {pd})); } } } This check is done with the protection domain of the initial class under verification ('Tricky' in our case) which is from the unnamed module and doesn't have the rights to access the unexported classes from java.base. Therefor the check fails the second time. Here's the corresponding VM stack trace: j java.lang.ClassLoader.checkPackageAccess(Ljava/lang/Class;Ljava/security/ProtectionDomain;)V+106 java.base at 9-internal v ~StubRoutines::call_stub V [libjvm.so+0xc6c75d] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6a5 V [libjvm.so+0x1055bab] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x41 V [libjvm.so+0xc6c0a2] JavaCalls::call(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0xaa V [libjvm.so+0xc6b6a9] JavaCalls::call_special(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x173 V [libjvm.so+0xc6ba04] JavaCalls::call_special(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Handle, Handle, Thread*)+0xf6 V [libjvm.so+0x11fdcb0] SystemDictionary::validate_protection_domain(instanceKlassHandle, Handle, Handle, Thread*)+0x22e V [libjvm.so+0x11ff40a] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0xf2a V [libjvm.so+0x11fd298] SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*)+0x262 V [libjvm.so+0x11fcca3] SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x45 V [libjvm.so+0x1286586] VerificationType::resolve_and_check_assignability(instanceKlassHandle, Symbol*, Symbol*, bool, bool, bool, Thread*)+0x258 V [libjvm.so+0x128682e] VerificationType::is_reference_assignable_from(VerificationType const&, ClassVerifier*, bool, Thread*) const+0x212 V [libjvm.so+0x118fa55] VerificationType::is_assignable_from(VerificationType const&, ClassVerifier*, bool, Thread*) const+0x191 V [libjvm.so+0x129a98f] StackMapFrame::pop_stack(VerificationType, Thread*)+0x81 V [libjvm.so+0x12978f3] ClassVerifier::verify_invoke_instructions(RawBytecodeStream*, unsigned int, StackMapFrame*, bool, bool*, VerificationType, constantPoolHandle const&, StackMapTable*, Thread*)+0x1249 V [libjvm.so+0x129096b] ClassVerifier::verify_method(methodHandle const&, Thread*)+0x6b71 V [libjvm.so+0x1289d1a] ClassVerifier::verify_class(Thread*)+0x12a V [libjvm.so+0x1287c9e] Verifier::verify(instanceKlassHandle, Verifier::Mode, bool, Thread*)+0x2c0 V [libjvm.so+0xc2b9b0] InstanceKlass::verify_code(instanceKlassHandle, bool, Thread*)+0x7c V [libjvm.so+0xc2c228] InstanceKlass::link_class_impl(instanceKlassHandle, bool, Thread*)+0x55e V [libjvm.so+0xc2bb3d] InstanceKlass::link_class(Thread*)+0xdf V [libjvm.so+0xcf5f80] get_class_declared_methods_helper(JNIEnv_*, _jclass*, unsigned char, bool, Klass*, Thread*)+0x155 V [libjvm.so+0xcf6570] JVM_GetClassDeclaredMethods+0x1d9 j java.lang.Class.getDeclaredMethods0(Z)[Ljava/lang/reflect/Method;+0 java.base at 9-internal j java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method;+34 java.base at 9-internal j java.lang.Class.getMethodsRecursive(Ljava/lang/String;[Ljava/lang/Class;Z)Ljava/lang/PublicMethods$MethodList;+2 java.base at 9-internal j java.lang.Class.getMethod0(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;+14 java.base at 9-internal j java.lang.Class.getMethod(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;+26 java.base at 9-internal j sun.launcher.LauncherHelper.validateMainClass(Ljava/lang/Class;)V+12 java.base at 9-internal j sun.launcher.LauncherHelper.checkAndLoadMain(ZILjava/lang/String;)Ljava/lang/Class;+54 java.base at 9-internal It is clear that the verifier sometimes has to load classes in order to accomplish its duty, even if these classes won't be used later on, at run-time. But the question remains if it is OK for an application to fail just because the verifier is unable to load classes required for verification because of security manager restrictions or if the verifier should run with higher privileges which allow such accesses? If the answer to this question is "Yes" (i.e. it's OK to fail), the consequence of running with a security manager will be that '--add-exports/--add-opens/--illegal-access=permit' may be not sharp enough knifes to achieve Java 8 backward compatibility. We may also have to grant some additional security permissions to our application classes. If the answer will be "No" (i.e. it's not OK to fail in the verifier) we may have to fix the VM to elevate the permissions used to load classes from within the verifier. Any comments? Thank you and best regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8174766 [2] http://mail.openjdk.java.net/pipermail/security-dev/2017-January/thread.html#15416 [3] https://bugs.openjdk.java.net/browse/JDK-8055206 From Alan.Bateman at oracle.com Tue May 23 08:20:59 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 May 2017 09:20:59 +0100 Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: References: Message-ID: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> Volker - one suggestion for your experiments is to change your JDK 8 security properties file (java.security) to add "com.sun.crypto.provider." to the value of the "package.access" property. That should mean you will get the same AccessControlException with JDK 8 as you do with JDK 9. It may help to reason about the JDK 8 behavior, including what is triggered by verification, before looking at 9. On the "Error: A JNI error has occurred, please check your installation and try again" message. It's not core to your questions of course but I agree it is confusing. Ramanand Patil had a number of attempts on core-libs-dev to improve this and it may be that more is needed there. -Alan From david.holmes at oracle.com Tue May 23 08:51:56 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 May 2017 18:51:56 +1000 Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> References: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> Message-ID: <7d553d52-c5df-adc9-edf8-9b8aa352a48a@oracle.com> On 23/05/2017 6:20 PM, Alan Bateman wrote: > Volker - one suggestion for your experiments is to change your JDK 8 > security properties file (java.security) to add > "com.sun.crypto.provider." to the value of the "package.access" > property. That should mean you will get the same AccessControlException > with JDK 8 as you do with JDK 9. It may help to reason about the JDK 8 > behavior, including what is triggered by verification, before looking at 9. > > On the "Error: A JNI error has occurred, please check your installation > and try again" message. It's not core to your questions of course but I > agree it is confusing. Ramanand Patil had a number of attempts on > core-libs-dev to improve this and it may be that more is needed there. Yes I was sure we had agreed to remove that and I don't see it in Oracle JDK so perhaps it is only in OpenJDK launcher? David > -Alan > From vincent.x.ryan at oracle.com Tue May 23 11:22:02 2017 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 23 May 2017 12:22:02 +0100 Subject: RFR 8172244: AIOOBE in KeyStore.getCertificateAlias on Windows In-Reply-To: <3cd6cc0a-1b4e-e814-8aa2-3696416664ba@oracle.com> References: <3cd6cc0a-1b4e-e814-8aa2-3696416664ba@oracle.com> Message-ID: Your fix looks fine to me. Thanks. > On 22 May 2017, at 20:57, Adam Petcher wrote: > > This is a bug fix related to keys without certificates in the Windows key store. When a key doesn't have a certificate, the native code will set the list of certificates to an empty list. Some of the Java code for the MSCAPI provider doesn't handle this case correctly and throws an AIOOBE. The regression test reproduces the same circumstances in the Java code by bypassing some checks in the KeyStore interface, allowing us to test this without upsetting the test environment. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8172244 > Webrev: http://cr.openjdk.java.net/~apetcher/8172244/webrev.00/ > From volker.simonis at gmail.com Tue May 23 12:45:22 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 May 2017 14:45:22 +0200 Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: <7d553d52-c5df-adc9-edf8-9b8aa352a48a@oracle.com> References: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> <7d553d52-c5df-adc9-edf8-9b8aa352a48a@oracle.com> Message-ID: On Tue, May 23, 2017 at 10:51 AM, David Holmes wrote: > On 23/05/2017 6:20 PM, Alan Bateman wrote: >> >> Volker - one suggestion for your experiments is to change your JDK 8 >> security properties file (java.security) to add "com.sun.crypto.provider." >> to the value of the "package.access" property. That should mean you will get >> the same AccessControlException with JDK 8 as you do with JDK 9. It may help >> to reason about the JDK 8 behavior, including what is triggered by >> verification, before looking at 9. >> >> On the "Error: A JNI error has occurred, please check your installation >> and try again" message. It's not core to your questions of course but I >> agree it is confusing. Ramanand Patil had a number of attempts on >> core-libs-dev to improve this and it may be that more is needed there. > > > Yes I was sure we had agreed to remove that and I don't see it in Oracle JDK > so perhaps it is only in OpenJDK launcher? > Hi David, not sure what you mean? Does the Oracle JDK come with another launcher compared to the OpenJDK? I've just tried with the latest EA build 170 (which I assume is an Oracle JDK) and I see exactly the same error: java -Djava.security.manager -showversion Tricky "" java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+170) Java HotSpot(TM) Server VM (build 9-ea+170, mixed mode) Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.com.sun.crypto.provider") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:471) at java.base/java.security.AccessController.checkPermission(AccessController.java:894) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:561) at java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534) at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:671) at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:669) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:669) at java.base/java.lang.Class.getDeclaredMethods0(Native Method) at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3134) at java.base/java.lang.Class.getMethodsRecursive(Class.java:3275) at java.base/java.lang.Class.getMethod0(Class.java:3261) at java.base/java.lang.Class.getMethod(Class.java:2062) at java.base/sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:712) at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:570) So what do you mean when saying that you don't see it in the Oracle JDK? Regards, Volker > David > > >> -Alan >> > From ecki at zusammenkunft.net Tue May 23 14:08:01 2017 From: ecki at zusammenkunft.net (Bernd) Date: Tue, 23 May 2017 16:08:01 +0200 Subject: ECC Key Usage ignored with and ECDH(E) ciphers Message-ID: Hello, according to RFC 4492 the key usage for ECDHE and ECDH ciphers need to be observed in regards to key agreement: When I use ECDH_ECDSA ciphers then the server certificate must have the keyAgreement usage. When I use ECDHE_ECDSA ciphers then the server certificate must have "digitalSignature". # Note that there is no structural difference between ECDH and ECDSA # keys. A certificate issuer may use X.509 v3 keyUsage and # extendedKeyUsage extensions to restrict the use of an ECC public key # to certain computations [15 ]. This document refers to an ECC key as # ECDH-capable if its use in ECDH is permitted. ECDSA-capable is # defined similarly. This rule is enforced by the openssl s_client: when the server proposes a cipher which does not pass this check it will terminate the connection: > openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect localhost:1234 > 1252:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc cert not for signing:.\ssl\ssl_lib.c:2512: > 1252:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad ecc cert:.\ssl\s3_clnt.c:3544: In this case the certificate had key usage: > [ server-exch ] > extendedKeyUsage = serverAuth > basicConstraints = CA:FALSE > keyUsage = keyAgreement > subjectAltName=IP:127.0.0.1,DNS:localhost. The connect with static ECDH works: > openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234 ... > SSL-Session: > Protocol : TLSv1.2 > Cipher : ECDH-ECDSA-AES128-SHA256 The other way around, when I use the following key usage: > [ server-sign ] > extendedKeyUsage = serverAuth > basicConstraints = CA:FALSE > keyUsage = digitalSignature > subjectAltName=IP:127.0.0.1,DNS:localhost. OpenSSL client works this way: >openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234 >9916:error:1411713D:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc cert not for key agreement >openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect localhost:1234 >SSL-Session: > Protocol : TLSv1.2 > Cipher : ECDHE-ECDSA-AES128-SHA256 In both cases however JSSE (OracleJDK8u121 or OpenJDK 9-ea+162) will offer both cipher suites and not filter them by key usage capabilties. Would you agree this is a bug? And should this also apply to client side? I have not tested it with RSA certificates, but I would expect this to be the same. Gruss Bernd PS: config file and openssl commands to create multiple ECC certificates used for this test: https://gist.github.com/ecki/d66d79bf0cf12872d015804f5edec6e4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue May 23 14:44:11 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 May 2017 16:44:11 +0200 Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> References: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> Message-ID: On Tue, May 23, 2017 at 10:20 AM, Alan Bateman wrote: > Volker - one suggestion for your experiments is to change your JDK 8 > security properties file (java.security) to add "com.sun.crypto.provider." > to the value of the "package.access" property. That should mean you will get > the same AccessControlException with JDK 8 as you do with JDK 9. It may help > to reason about the JDK 8 behavior, including what is triggered by > verification, before looking at 9. > You're right. JDK 8 produces the same error if we add "com.sun.crypto.provider." to the value of the "package.access" property. I didn't wanted to blame jdk9 here - I just saw this difference because "com.sun.crypto.provider." isn't contained in the "package.access" property by default. So maybe I rephrase my question a little more generally: Is it required for the verifier to do security and/or access checks during the verification phase or could/should these checks be postponed to runtime? The issue with verification errors due to missing classes from Remi's previous answer is probably a corner case of this question. The other question is if '--add-exports' should implicitly grant the corresponding security permissions? I understand that package/class visibility and security checks are somewhat orthogonal concepts so I tend to agree with the current functionality (and a part of this problem is now tracked by JDK-8174766). Nevertheless it is probably wise to document these differences so people won't get surprised. > On the "Error: A JNI error has occurred, please check your installation and > try again" message. It's not core to your questions of course but I agree it > is confusing. Ramanand Patil had a number of attempts on core-libs-dev to > improve this and it may be that more is needed there. > Yes, a better error message would be nice but thats a different question. Thanks, Volker > -Alan > From sean.mullan at oracle.com Tue May 23 15:06:33 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 23 May 2017 11:06:33 -0400 Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: References: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> Message-ID: <4fffb23d-66ee-3049-a6d0-b164254751aa@oracle.com> On 5/23/17 10:44 AM, Volker Simonis wrote: > The other question is if '--add-exports' should implicitly grant the > corresponding security permissions? I understand that package/class > visibility and security checks are somewhat orthogonal concepts so I > tend to agree with the current functionality (and a part of this > problem is now tracked by JDK-8174766). Nevertheless it is probably > wise to document these differences so people won't get surprised. We considered it but the SecurityManager checks all callers (and not just the target module) on the stack for the appropriate accessClassInPackage RuntimePermission. Also, SecurityManager.checkPackageAccess does not know what the target module is, all it has is the package name. It is possible however that we could respect the module access rights when loading classes in the internal ClassLoader.checkPackageAccess method. I will be looking more into this in the JDK 10 timeframe. The current javadoc of SecurityManager.checkPackageAccess [1] does document this behavior: "This implementation also restricts all non-exported packages of modules loaded by the platform class loader or its ancestors. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module." --Sean [1] http://download.java.net/java/jdk9/docs/api/java/lang/SecurityManager.html#checkPackageAccess-java.lang.String- From xuelei.fan at oracle.com Tue May 23 17:33:40 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 23 May 2017 10:33:40 -0700 Subject: Code Review Request, JDK-8180856 Remove RecordType.java Message-ID: <9a7ebde9-1da6-6ba1-602e-19953f0f844b@oracle.com> Hi, In the SunJSSE provider implementation, the code of src/java.base/share/classes/sun/security/ssl/RecordType.java was merged into Ciphertext.java. The RecordType.java should be deleted in case of any misleading. Code clean up, no webrev. The update in JDK 10 repository looks like: JDK10/jdk $ hg status . R src/java.base/share/classes/sun/security/ssl/RecordType.java Thanks, Xuelei From forax at univ-mlv.fr Tue May 23 08:06:57 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 23 May 2017 10:06:57 +0200 (CEST) Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: References: Message-ID: <1810521261.1097513.1495526817840.JavaMail.zimbra@u-pem.fr> Hi Volker, this is the behavior of the verifier since 6 (when the split verifier becomes the default one). Let say you have a code like this, public class TestVerifier { static class B extends A { } static class A { } public static void main(String[] args) { A a; if (args.length == 0) { a = new A(); } else { a = new B(); } System.out.println(a.toString()); } } if you compile and then remove TestVerifier$B.class, you will get Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.NoClassDefFoundError: TestVerifier$B at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) at java.lang.Class.privateGetMethodRecursive(Class.java:3048) at java.lang.Class.getMethod0(Class.java:3018) at java.lang.Class.getMethod(Class.java:1784) at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526) Caused by: java.lang.ClassNotFoundException: TestVerifier$B at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 7 more whatever the comand line arguments because it's the verifier that throws an error. There is a workaround for you, if you use an interface instead of a class (in my example, make A an interface), it will work ! The verifier does not verify interface at verification time, the checks in done once by the VM at runtime. so if there is a bug, it's in the way the verifier actually works i.e. if it can not find a class or do not see a class because of the module encapsulation, it should postpone the check at runtime instead of reporting an error at compile time. Thats said, i'm not sure it's a good idea. cheers, R?mi ----- Mail original ----- > De: "Volker Simonis" > ?: "jigsaw-dev" , "security-dev" > Envoy?: Mardi 23 Mai 2017 09:27:22 > Objet: JPMS Access Checks, Verification and the Security Manager > Hi, > > my question is if it is OK for a program which otherwise runs fine to > fail during class verification if running with a security manager > because of module access restrictions? > > As the following write-up got a little lengthy, I've also uploaded a > html version for a nicer reading experience :) > > http://cr.openjdk.java.net/~simonis/webrevs/2017/veri_with_secman/sm.html > > Consider the following small, self-contained program which statically > references com.sun.crypto.provider.SunJCE: > > import java.security.Provider; > import com.sun.crypto.provider.SunJCE; > > public class Tricky { > > public static void main(String args[]) throws Exception { > try { > System.out.println(Tricky.class + " (" + > Tricky.class.getClassLoader() + ")" + args[0]); > } > catch (Exception e) { > Provider p = new SunJCE(); > System.out.println(p + " (" + p.toString() + ")"); > } > } > } > > This program easily compiles and runs with Oracle/OpenJDK 8: > > $ javac Tricky > $ java Tricky "" > class Tricky (sun.misc.Launcher$AppClassLoader at 4e0e2f2a) > $ java Tricky > SunJCE version 1.8 (SunJCE version 1.8) > > The second invocation (without argument) will cause an exception (when > trying to access the first element of the zero length argument array > at 'args[0]') which will be caught in the exception handler where we > create a new 'SunJCE' object and print its string representation to > stdout. The first invocation (with an empty argument) doesn't provoke > an exception and will just print the class itself together with its > class loader. > > When we run the same (jdk8 compiled) program with jdk9, we'll see the > following result: > > $ jdk9/java Tricky "" > class Tricky (jdk.internal.loader.ClassLoaders$AppClassLoader at ba8a1dc) > $ jdk9/java Tricky > Exception in thread "main" java.lang.IllegalAccessError: class Tricky > (in unnamed module @0x3b192d32) cannot access class > com.sun.crypto.provider.SunJCE (in module java.base) because module > java.base does not export com.sun.crypto.provider to unnamed module > @0x3b192d32 > at Tricky.main(Tricky.java:11) > $ jdk9/java --add-exports java.base/com.sun.crypto.provider=ALL-UNNAMED Tricky > SunJCE version 9 (SunJCE version 9) > > The first invocation (with an empty argument) still works because we > have lazy class loading and 'SunJCE' provider is actually never used. > The second invocation (without argument) obviously fails with jdk9 > because 'java.base' doesn't export the package com.sun.crypto.provider > anymore. This can be fixed by adding '--add-exports > java.base/com.sun.crypto.provider=ALL-UNNAMED' to the command line as > demonstrated in the third invocation. > > So far so good - everything worked as expected till now. Now let's run > the same program with the default security manager: > > $ java -Djava.security.manager Tricky "" > class Tricky (sun.misc.Launcher$AppClassLoader at 4e0e2f2a) > $ java -Djava.security.manager Tricky > SunJCE version 1.8 (SunJCE version 1.8) > > The security manager doesn't change anything for jdk8! So let's try with jdk9: > > $ jdk9/java -Djava.security.manager Tricky "" > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.security.AccessControlException: > access denied ("java.lang.RuntimePermission" > "accessClassInPackage.com.sun.crypto.provider") > at > java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:471) > at > java.base/java.security.AccessController.checkPermission(AccessController.java:894) > at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:561) > at > java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534) > at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:671) > at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:669) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.base/java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:669) > at java.base/java.lang.Class.getDeclaredMethods0(Native Method) > at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3129) > at java.base/java.lang.Class.getMethodsRecursive(Class.java:3270) > at java.base/java.lang.Class.getMethod0(Class.java:3256) > at java.base/java.lang.Class.getMethod(Class.java:2057) > at > java.base/sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:712) > at > java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:570) > > The first invocation (with an empty argument) crashes with a strange > JNI error. The call stack unveils that we haven't even entered the > main method of our program. Instead we've crashed in the jdk-internal > launcher 'sun.launcher.LauncherHelper' during 'checkAndLoadMain()' > with a 'java.security.AccessControlException' because we couldn't > access the 'com.sun.crypto.provider' package. That's strange because > we shouldn't need to load SunJCE provider for this invocation because > of lazy class loading. > > A little reasoning and the right Xlog parameter unveils that the > exception happens during class verification: > > $ jdk9/java -Djava.security.manager -Xlog:verification Tricky "" > ... > [1,382s][info][verification] locals: { '[Ljava/lang/String;', > 'java/lang/Exception', 'com/sun/crypto/provider/SunJCE' } > [1,382s][info][verification] stack: { 'java/io/PrintStream', > 'java/lang/StringBuilder', 'com/sun/crypto/provider/SunJCE' } > [1,382s][info][verification] offset = 77, opcode = invokevirtual > [1,589s][info][verification] Verification for Tricky has exception > pending java.security.AccessControlException > [1,589s][info][verification] End class verification for: Tricky > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.security.AccessControlException: > access denied ("java.lang.RuntimePermission" > "accessClassInPackage.com.sun.crypto.provider") > ... > > And indeed, switching off class verification will fix the problem: > > $ jdk9/java -Djava.security.manager -Xlog:verification -noverify Tricky "" > class Tricky (jdk.internal.loader.ClassLoaders$AppClassLoader at 1b9e1916) > > But switching off class verification is not something we usually want to do! > > So we can try to use '--add-exports > java.base/com.sun.crypto.provider=ALL-UNNAMED' (although this wasn't > needed without security manager): > > $ jdk9/java -Djava.security.manager --add-exports > java.base/com.sun.crypto.provider=ALL-UNNAMED Tricky "" > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.security.AccessControlException: > access denied ("java.lang.RuntimePermission" > "accessClassInPackage.com.sun.crypto.provider") > ... > > but the result is still the same. If you feel that '--add-exports > java.base/com.sun.crypto.provider=ALL-UNNAMED' should have fixed the > problem, you're not alone. That issue is tracked under JDK-8174766 > [1]. It was discussed in the review [2] for JDK-8055206 [3] which > introduced the problem. > > Currently, the only way to fix the problem is to add additional > permissions through a custom security policy: > > my.policy > --------- > grant { > permission java.lang.RuntimePermission > "accessClassInPackage.com.sun.crypto.provider"; > }; > > $ jdk9/java -Djava.security.manager -Djava.security.policy=my.policy Tricky "" > class Tricky (jdk.internal.loader.ClassLoaders$AppClassLoader at 1b9e1916) > > But the real question remains: why does class verification fails with > a security manager and succeeds without? > > With the right Xlog parameters we can verify, that even without > security manager, the 'SunJCE' class is successfully loaded by the > verifier for the purpose of verification, and the execution of the > program succeeds if we don't reference 'SunJCE' during execution: > > $ jdk9/java -Xlog:verification -Xlog:class+load Tricky "" > ... > [1,193s][info][verification] locals: { '[Ljava/lang/String;', > 'java/lang/Exception', 'com/sun/crypto/provider/SunJCE' } > [1,193s][info][verification] stack: { 'java/io/PrintStream', > 'java/lang/StringBuilder', 'com/sun/crypto/provider/SunJCE' } > [1,193s][info][verification] offset = 77, opcode = invokevirtual > [1,196s][info][class,load ] java.security.Provider source: jrt:/java.base > [1,197s][info][class,load ] com.sun.crypto.provider.SunJCE source: > jrt:/java.base > ... > [1,198s][info][verification] End class verification for: Tricky > ... > class Tricky (jdk.internal.loader.ClassLoaders$AppClassLoader at ba8a1dc) > > So how does the presence of a security manager changes the class > verification process? > > With a security manager, there are two additional > 'accessClassInPackage' checks during class loading. If we recall the > verifier log: > > [1,193s][info][verification] locals: { '[Ljava/lang/String;', > 'java/lang/Exception', 'com/sun/crypto/provider/SunJCE' } > [1,193s][info][verification] stack: { 'java/io/PrintStream', > 'java/lang/StringBuilder', 'com/sun/crypto/provider/SunJCE' } > [1,193s][info][verification] offset = 77, opcode = invokevirtual > [1,196s][info][class,load ] java.security.Provider source: jrt:/java.base > [1,197s][info][class,load ] com.sun.crypto.provider.SunJCE source: > jrt:/java.base > > we see that the verifier has to prove that > 'com/sun/crypto/provider/SunJCE' (which is on top of the stack) can be > assigned (i.e. is assign-compatible) to 'java.security.Provider' and > it is therefor safe to call 'Provider::toString()' on it. Therefor, in > order to load the class 'com.sun.crypto.provider.SunJCE', the verifier > calls 'SystemDictionary::resolve_or_fail()' which in the end calls > 'ClassLoader.loadClass(_class_name)' on the class loader of the class > under verification. If that class is a user class, this will call > 'jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass()' in Java > 9 because that's the actual application class loader (aka system class > loader) and ClassLoaders$AppClassLoader.loadClass() will perform the > following check if the VM runs with a security manager: > > @Override > protected Class loadClass(String cn, boolean resolve) throws > ClassNotFoundException > { > SecurityManager sm = System.getSecurityManager(); > if (sm != null) { > int i = cn.lastIndexOf('.'); > if (i != -1) { > sm.checkPackageAccess(cn.substring(0, i)); > } > } > return super.loadClass(cn, resolve); > } > > Here's the corresponding VM stack trace: > > j java.lang.SecurityManager.checkPackageAccess(Ljava/lang/String;)V+46 > java.base at 9-internal > j > jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+8 > java.base at 9-internal > j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 > java.base at 9-internal > v ~StubRoutines::call_stub > V [libjvm.so+0xc6c75d] JavaCalls::call_helper(JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*)+0x6a5 > V [libjvm.so+0x1055bab] os::os_exception_wrapper(void > (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), > JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x41 > V [libjvm.so+0xc6c0a2] JavaCalls::call(JavaValue*, methodHandle > const&, JavaCallArguments*, Thread*)+0xaa > V [libjvm.so+0xc6b1b3] JavaCalls::call_virtual(JavaValue*, > KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x1f1 > V [libjvm.so+0xc6b3f0] JavaCalls::call_virtual(JavaValue*, Handle, > KlassHandle, Symbol*, Symbol*, Handle, Thread*)+0xd2 > V [libjvm.so+0x1201c56] > SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x93c > V [libjvm.so+0x11feda0] > SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, > Handle, Thread*)+0x8c0 > V [libjvm.so+0x11fd298] SystemDictionary::resolve_or_null(Symbol*, > Handle, Handle, Thread*)+0x262 > V [libjvm.so+0x11fcca3] SystemDictionary::resolve_or_fail(Symbol*, > Handle, Handle, bool, Thread*)+0x45 > V [libjvm.so+0x1286586] > VerificationType::resolve_and_check_assignability(instanceKlassHandle, > Symbol*, Symbol*, bool, bool, bool, Thread*)+0x258 > V [libjvm.so+0x128682e] > VerificationType::is_reference_assignable_from(VerificationType > const&, ClassVerifier*, bool, Thread*) const+0x212 > V [libjvm.so+0x118fa55] > VerificationType::is_assignable_from(VerificationType const&, > ClassVerifier*, bool, Thread*) const+0x191 > V [libjvm.so+0x129a98f] StackMapFrame::pop_stack(VerificationType, > Thread*)+0x81 > V [libjvm.so+0x12978f3] > ClassVerifier::verify_invoke_instructions(RawBytecodeStream*, unsigned > int, StackMapFrame*, bool, bool*, VerificationType, constantPoolHandle > const&, StackMapTable*, Thread*)+0x1249 > V [libjvm.so+0x129096b] ClassVerifier::verify_method(methodHandle > const&, Thread*)+0x6b71 > V [libjvm.so+0x1289d1a] ClassVerifier::verify_class(Thread*)+0x12a > V [libjvm.so+0x1287c9e] Verifier::verify(instanceKlassHandle, > Verifier::Mode, bool, Thread*)+0x2c0 > V [libjvm.so+0xc2b9b0] > InstanceKlass::verify_code(instanceKlassHandle, bool, Thread*)+0x7c > V [libjvm.so+0xc2c228] > InstanceKlass::link_class_impl(instanceKlassHandle, bool, > Thread*)+0x55e > V [libjvm.so+0xc2bb3d] InstanceKlass::link_class(Thread*)+0xdf > V [libjvm.so+0xcf5f80] get_class_declared_methods_helper(JNIEnv_*, > _jclass*, unsigned char, bool, Klass*, Thread*)+0x155 > V [libjvm.so+0xcf6570] JVM_GetClassDeclaredMethods+0x1d9 > j java.lang.Class.getDeclaredMethods0(Z)[Ljava/lang/reflect/Method;+0 > java.base at 9-internal > j java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method;+34 > java.base at 9-internal > j > java.lang.Class.getMethodsRecursive(Ljava/lang/String;[Ljava/lang/Class;Z)Ljava/lang/PublicMethods$MethodList;+2 > java.base at 9-internal > j > java.lang.Class.getMethod0(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;+14 > java.base at 9-internal > j > java.lang.Class.getMethod(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;+26 > java.base at 9-internal > j sun.launcher.LauncherHelper.validateMainClass(Ljava/lang/Class;)V+12 > java.base at 9-internal > j > sun.launcher.LauncherHelper.checkAndLoadMain(ZILjava/lang/String;)Ljava/lang/Class;+54 > java.base at 9-internal > > This check succeeds, because class-loading is triggered from > sun.launcher.LauncherHelper which is in the 'java.base' package, just > like the 'com.sun.crypto.provider.SunJCE' package. > > But when running with a security manager, there's also a second check, > which is performed in the VM by > 'SystemDictionary::resolve_instance_class_or_null()', right before it > returns the loaded class, by calling > 'SystemDictionary::validate_protection_domain()'. This method in turn > calls 'java.lang.ClassLoader.checkPackageAccess()' to validate the > package access: > > // Invoked by the VM after loading class with this loader. > private void checkPackageAccess(Class cls, ProtectionDomain pd) { > final SecurityManager sm = System.getSecurityManager(); > if (sm != null) { > ... > final String name = cls.getName(); > final int i = name.lastIndexOf('.'); > if (i != -1) { > AccessController.doPrivileged(new PrivilegedAction<>() { > public Void run() { > sm.checkPackageAccess(name.substring(0, i)); > return null; > } > }, new AccessControlContext(new ProtectionDomain[] {pd})); > } > } > } > > This check is done with the protection domain of the initial class > under verification ('Tricky' in our case) which is from the unnamed > module and doesn't have the rights to access the unexported classes > from java.base. Therefor the check fails the second time. Here's the > corresponding VM stack trace: > > j > java.lang.ClassLoader.checkPackageAccess(Ljava/lang/Class;Ljava/security/ProtectionDomain;)V+106 > java.base at 9-internal > v ~StubRoutines::call_stub > V [libjvm.so+0xc6c75d] JavaCalls::call_helper(JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*)+0x6a5 > V [libjvm.so+0x1055bab] os::os_exception_wrapper(void > (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), > JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x41 > V [libjvm.so+0xc6c0a2] JavaCalls::call(JavaValue*, methodHandle > const&, JavaCallArguments*, Thread*)+0xaa > V [libjvm.so+0xc6b6a9] JavaCalls::call_special(JavaValue*, > KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x173 > V [libjvm.so+0xc6ba04] JavaCalls::call_special(JavaValue*, Handle, > KlassHandle, Symbol*, Symbol*, Handle, Handle, Thread*)+0xf6 > V [libjvm.so+0x11fdcb0] > SystemDictionary::validate_protection_domain(instanceKlassHandle, > Handle, Handle, Thread*)+0x22e > V [libjvm.so+0x11ff40a] > SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, > Handle, Thread*)+0xf2a > V [libjvm.so+0x11fd298] SystemDictionary::resolve_or_null(Symbol*, > Handle, Handle, Thread*)+0x262 > V [libjvm.so+0x11fcca3] SystemDictionary::resolve_or_fail(Symbol*, > Handle, Handle, bool, Thread*)+0x45 > V [libjvm.so+0x1286586] > VerificationType::resolve_and_check_assignability(instanceKlassHandle, > Symbol*, Symbol*, bool, bool, bool, Thread*)+0x258 > V [libjvm.so+0x128682e] > VerificationType::is_reference_assignable_from(VerificationType > const&, ClassVerifier*, bool, Thread*) const+0x212 > V [libjvm.so+0x118fa55] > VerificationType::is_assignable_from(VerificationType const&, > ClassVerifier*, bool, Thread*) const+0x191 > V [libjvm.so+0x129a98f] StackMapFrame::pop_stack(VerificationType, > Thread*)+0x81 > V [libjvm.so+0x12978f3] > ClassVerifier::verify_invoke_instructions(RawBytecodeStream*, unsigned > int, StackMapFrame*, bool, bool*, VerificationType, constantPoolHandle > const&, StackMapTable*, Thread*)+0x1249 > V [libjvm.so+0x129096b] ClassVerifier::verify_method(methodHandle > const&, Thread*)+0x6b71 > V [libjvm.so+0x1289d1a] ClassVerifier::verify_class(Thread*)+0x12a > V [libjvm.so+0x1287c9e] Verifier::verify(instanceKlassHandle, > Verifier::Mode, bool, Thread*)+0x2c0 > V [libjvm.so+0xc2b9b0] > InstanceKlass::verify_code(instanceKlassHandle, bool, Thread*)+0x7c > V [libjvm.so+0xc2c228] > InstanceKlass::link_class_impl(instanceKlassHandle, bool, > Thread*)+0x55e > V [libjvm.so+0xc2bb3d] InstanceKlass::link_class(Thread*)+0xdf > V [libjvm.so+0xcf5f80] get_class_declared_methods_helper(JNIEnv_*, > _jclass*, unsigned char, bool, Klass*, Thread*)+0x155 > V [libjvm.so+0xcf6570] JVM_GetClassDeclaredMethods+0x1d9 > j java.lang.Class.getDeclaredMethods0(Z)[Ljava/lang/reflect/Method;+0 > java.base at 9-internal > j java.lang.Class.privateGetDeclaredMethods(Z)[Ljava/lang/reflect/Method;+34 > java.base at 9-internal > j > java.lang.Class.getMethodsRecursive(Ljava/lang/String;[Ljava/lang/Class;Z)Ljava/lang/PublicMethods$MethodList;+2 > java.base at 9-internal > j > java.lang.Class.getMethod0(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;+14 > java.base at 9-internal > j > java.lang.Class.getMethod(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;+26 > java.base at 9-internal > j sun.launcher.LauncherHelper.validateMainClass(Ljava/lang/Class;)V+12 > java.base at 9-internal > j > sun.launcher.LauncherHelper.checkAndLoadMain(ZILjava/lang/String;)Ljava/lang/Class;+54 > java.base at 9-internal > > It is clear that the verifier sometimes has to load classes in order > to accomplish its duty, even if these classes won't be used later on, > at run-time. > > But the question remains if it is OK for an application to fail just > because the verifier is unable to load classes required for > verification because of security manager restrictions or if the > verifier should run with higher privileges which allow such accesses? > > If the answer to this question is "Yes" (i.e. it's OK to fail), the > consequence of running with a security manager will be that > '--add-exports/--add-opens/--illegal-access=permit' may be not sharp > enough knifes to achieve Java 8 backward compatibility. We may also > have to grant some additional security permissions to our application > classes. > > If the answer will be "No" (i.e. it's not OK to fail in the verifier) > we may have to fix the VM to elevate the permissions used to load > classes from within the verifier. > > Any comments? > > Thank you and best regards, > Volker > > [1] https://bugs.openjdk.java.net/browse/JDK-8174766 > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2017-January/thread.html#15416 > [3] https://bugs.openjdk.java.net/browse/JDK-8055206 From xuelei.fan at oracle.com Tue May 23 19:12:10 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 23 May 2017 12:12:10 -0700 Subject: ECC Key Usage ignored with and ECDH(E) ciphers In-Reply-To: References: Message-ID: <1973cb15-ef56-2042-b21c-6a5eb0a82915@oracle.com> Hi Bernd, What are the JSSE key/trust managers used for the testing ("SunX509" or "PKIX")? Thanks & Regards, Xuelei On 5/23/2017 7:08 AM, Bernd wrote: > Hello, > > according to RFC 4492 the key usage for ECDHE and ECDH ciphers need to > be observed in regards to key agreement: When I use ECDH_ECDSA ciphers > then the server certificate must have the keyAgreement usage. When I use > ECDHE_ECDSA ciphers then the server certificate must have > "digitalSignature". > > # Note that there is no structural difference between ECDH and ECDSA > # keys. A certificate issuer may use X.509 v3 keyUsage and > # extendedKeyUsage extensions to restrict the use of an ECC public key > # to certain computations [15 ]. This document refers to an ECC key as > # ECDH-capable if its use in ECDH is permitted. ECDSA-capable is > # defined similarly. > > > This rule is enforced by the openssl s_client: when the server proposes > a cipher which does not pass this check it will terminate the connection: > > > openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect > localhost:1234 > > 1252:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc > cert not for signing:.\ssl\ssl_lib.c:2512: > > 1252:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad > ecc cert:.\ssl\s3_clnt.c:3544: > > In this case the certificate had key usage: > > > [ server-exch ] > > extendedKeyUsage = serverAuth > > basicConstraints = CA:FALSE > > keyUsage = keyAgreement > > subjectAltName=IP:127.0.0.1,DNS:localhost. > > The connect with static ECDH works: > > > openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234 > ... > > SSL-Session: > > Protocol : TLSv1.2 > > Cipher : ECDH-ECDSA-AES128-SHA256 > > The other way around, when I use the following key usage: > > > [ server-sign ] > > extendedKeyUsage = serverAuth > > basicConstraints = CA:FALSE > > keyUsage = digitalSignature > > subjectAltName=IP:127.0.0.1,DNS:localhost. > > OpenSSL client works this way: > > >openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234 > >9916:error:1411713D:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc > cert not for key agreement > > >openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect localhost:1234 > >SSL-Session: > > Protocol : TLSv1.2 > > Cipher : ECDHE-ECDSA-AES128-SHA256 > > In both cases however JSSE (OracleJDK8u121 or OpenJDK 9-ea+162) will > offer both cipher suites and not filter them by key usage capabilties. > Would you agree this is a bug? And should this also apply to client > side? I have not tested it with RSA certificates, but I would expect > this to be the same. > > Gruss > Bernd > > PS: config file and openssl commands to create multiple ECC certificates > used for this test: > https://gist.github.com/ecki/d66d79bf0cf12872d015804f5edec6e4 > > From ecki at zusammenkunft.net Tue May 23 20:34:34 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 23 May 2017 20:34:34 +0000 Subject: ECC Key Usage ignored with and ECDH(E) ciphers In-Reply-To: <1973cb15-ef56-2042-b21c-6a5eb0a82915@oracle.com> References: , <1973cb15-ef56-2042-b21c-6a5eb0a82915@oracle.com> Message-ID: Hello, It is a PKIX KeyManager with a loaded P12 key store. But I tried quite a few alternatives, so maybe there is something wrong within all the commented code. If you think it should work I can try to clean it up for reproduction. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: Xuelei Fan Sent: Tuesday, May 23, 2017 9:12:10 PM To: Bernd; security-dev at openjdk.java.net Subject: Re: ECC Key Usage ignored with and ECDH(E) ciphers Hi Bernd, What are the JSSE key/trust managers used for the testing ("SunX509" or "PKIX")? Thanks & Regards, Xuelei On 5/23/2017 7:08 AM, Bernd wrote: > Hello, > > according to RFC 4492 the key usage for ECDHE and ECDH ciphers need to > be observed in regards to key agreement: When I use ECDH_ECDSA ciphers > then the server certificate must have the keyAgreement usage. When I use > ECDHE_ECDSA ciphers then the server certificate must have > "digitalSignature". > > # Note that there is no structural difference between ECDH and ECDSA > # keys. A certificate issuer may use X.509 v3 keyUsage and > # extendedKeyUsage extensions to restrict the use of an ECC public key > # to certain computations [15 ]. This document refers to an ECC key as > # ECDH-capable if its use in ECDH is permitted. ECDSA-capable is > # defined similarly. > > > This rule is enforced by the openssl s_client: when the server proposes > a cipher which does not pass this check it will terminate the connection: > > > openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect > localhost:1234 > > 1252:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc > cert not for signing:.\ssl\ssl_lib.c:2512: > > 1252:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad > ecc cert:.\ssl\s3_clnt.c:3544: > > In this case the certificate had key usage: > > > [ server-exch ] > > extendedKeyUsage = serverAuth > > basicConstraints = CA:FALSE > > keyUsage = keyAgreement > > subjectAltName=IP:127.0.0.1,DNS:localhost. > > The connect with static ECDH works: > > > openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234 > ... > > SSL-Session: > > Protocol : TLSv1.2 > > Cipher : ECDH-ECDSA-AES128-SHA256 > > The other way around, when I use the following key usage: > > > [ server-sign ] > > extendedKeyUsage = serverAuth > > basicConstraints = CA:FALSE > > keyUsage = digitalSignature > > subjectAltName=IP:127.0.0.1,DNS:localhost. > > OpenSSL client works this way: > > >openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234 > >9916:error:1411713D:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc > cert not for key agreement > > >openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect localhost:1234 > >SSL-Session: > > Protocol : TLSv1.2 > > Cipher : ECDHE-ECDSA-AES128-SHA256 > > In both cases however JSSE (OracleJDK8u121 or OpenJDK 9-ea+162) will > offer both cipher suites and not filter them by key usage capabilties. > Would you agree this is a bug? And should this also apply to client > side? I have not tested it with RSA certificates, but I would expect > this to be the same. > > Gruss > Bernd > > PS: config file and openssl commands to create multiple ECC certificates > used for this test: > https://gist.github.com/ecki/d66d79bf0cf12872d015804f5edec6e4 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue May 23 20:58:46 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 23 May 2017 13:58:46 -0700 Subject: ECC Key Usage ignored with and ECDH(E) ciphers In-Reply-To: References: <1973cb15-ef56-2042-b21c-6a5eb0a82915@oracle.com> Message-ID: <54bb4e0d-2b0a-ef84-335e-942b95e5ed85@oracle.com> On 5/23/2017 1:34 PM, Bernd Eckenfels wrote: > Hello, > > It is a PKIX KeyManager with a loaded P12 key store. But I tried quite a > few alternatives, so maybe there is something wrong within all the > commented code. If you think it should work I can try to clean it up for > reproduction. > I think, it is needed to check the KeyAgreement key usage in both key/trust manager in the JSSE implementation. I appreciate it very much if you can help and clean up the test code for reproduction. Thanks & Regards, Xuelei > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *From:* Xuelei Fan > *Sent:* Tuesday, May 23, 2017 9:12:10 PM > *To:* Bernd; security-dev at openjdk.java.net > *Subject:* Re: ECC Key Usage ignored with and ECDH(E) ciphers > Hi Bernd, > > What are the JSSE key/trust managers used for the testing ("SunX509" or > "PKIX")? > > Thanks & Regards, > Xuelei > > On 5/23/2017 7:08 AM, Bernd wrote: >> Hello, >> >> according to RFC 4492 the key usage for ECDHE and ECDH ciphers need to >> be observed in regards to key agreement: When I use ECDH_ECDSA ciphers >> then the server certificate must have the keyAgreement usage. When I use >> ECDHE_ECDSA ciphers then the server certificate must have >> "digitalSignature". >> >> # Note that there is no structural difference between ECDH and ECDSA >> # keys. A certificate issuer may use X.509 v3 keyUsage and >> # extendedKeyUsage extensions to restrict the use of an ECC public key >> # to certain computations [15 ]. This document refers to > an ECC key as >> # ECDH-capable if its use in ECDH is permitted. ECDSA-capable is >> # defined similarly. >> >> >> This rule is enforced by the openssl s_client: when the server proposes >> a cipher which does not pass this check it will terminate the connection: >> >> > openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect >> localhost:1234 >> > 1252:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc >> cert not for signing:.\ssl\ssl_lib.c:2512: >> > 1252:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad >> ecc cert:.\ssl\s3_clnt.c:3544: >> >> In this case the certificate had key usage: >> >> > [ server-exch ] >> > extendedKeyUsage = serverAuth >> > basicConstraints = CA:FALSE >> > keyUsage = keyAgreement >> > subjectAltName=IP:127.0.0.1,DNS:localhost. >> >> The connect with static ECDH works: >> >> > openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234 >> ... >> > SSL-Session: >> > Protocol : TLSv1.2 >> > Cipher : ECDH-ECDSA-AES128-SHA256 >> >> The other way around, when I use the following key usage: >> >> > [ server-sign ] >> > extendedKeyUsage = serverAuth >> > basicConstraints = CA:FALSE >> > keyUsage = digitalSignature >> > subjectAltName=IP:127.0.0.1,DNS:localhost. >> >> OpenSSL client works this way: >> >> >openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234 >> >9916:error:1411713D:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc >> cert not for key agreement >> >> >openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect localhost:1234 >> >SSL-Session: >> > Protocol : TLSv1.2 >> > Cipher : ECDHE-ECDSA-AES128-SHA256 >> >> In both cases however JSSE (OracleJDK8u121 or OpenJDK 9-ea+162) will >> offer both cipher suites and not filter them by key usage capabilties. >> Would you agree this is a bug? And should this also apply to client >> side? I have not tested it with RSA certificates, but I would expect >> this to be the same. >> >> Gruss >> Bernd >> >> PS: config file and openssl commands to create multiple ECC certificates >> used for this test: >> https://gist.github.com/ecki/d66d79bf0cf12872d015804f5edec6e4 >> >> From valerie.peng at oracle.com Wed May 24 02:13:12 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 23 May 2017 19:13:12 -0700 Subject: [9] RFR 8180635: (doc) Clarify the compatibility and interoperability issue when using provider default values Message-ID: Sean, Can you please review this javadoc-only changes for JDK 9? Bug: https://bugs.openjdk.java.net/browse/JDK-8180635 Webrev: http://cr.openjdk.java.net/~valeriep/8180635/webrev.00/ Thanks, Valerie From david.holmes at oracle.com Wed May 24 02:45:24 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 May 2017 12:45:24 +1000 Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: References: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> <7d553d52-c5df-adc9-edf8-9b8aa352a48a@oracle.com> Message-ID: On 23/05/2017 10:45 PM, Volker Simonis wrote: > On Tue, May 23, 2017 at 10:51 AM, David Holmes wrote: >> On 23/05/2017 6:20 PM, Alan Bateman wrote: >>> >>> Volker - one suggestion for your experiments is to change your JDK 8 >>> security properties file (java.security) to add "com.sun.crypto.provider." >>> to the value of the "package.access" property. That should mean you will get >>> the same AccessControlException with JDK 8 as you do with JDK 9. It may help >>> to reason about the JDK 8 behavior, including what is triggered by >>> verification, before looking at 9. >>> >>> On the "Error: A JNI error has occurred, please check your installation >>> and try again" message. It's not core to your questions of course but I >>> agree it is confusing. Ramanand Patil had a number of attempts on >>> core-libs-dev to improve this and it may be that more is needed there. >> >> >> Yes I was sure we had agreed to remove that and I don't see it in Oracle JDK >> so perhaps it is only in OpenJDK launcher? >> > > Hi David, > > not sure what you mean? Does the Oracle JDK come with another launcher > compared to the OpenJDK? No - I was confusing myself. > I've just tried with the latest EA build 170 (which I assume is an > Oracle JDK) and I see exactly the same error: Ok. I see now that we still have the confusing error message depending on exactly when the exception is thrown. David ----- > java -Djava.security.manager -showversion Tricky "" > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+170) > Java HotSpot(TM) Server VM (build 9-ea+170, mixed mode) > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.security.AccessControlException: > access denied ("java.lang.RuntimePermission" > "accessClassInPackage.com.sun.crypto.provider") > at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:471) > at java.base/java.security.AccessController.checkPermission(AccessController.java:894) > at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:561) > at java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1534) > at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:671) > at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:669) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.base/java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:669) > at java.base/java.lang.Class.getDeclaredMethods0(Native Method) > at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3134) > at java.base/java.lang.Class.getMethodsRecursive(Class.java:3275) > at java.base/java.lang.Class.getMethod0(Class.java:3261) > at java.base/java.lang.Class.getMethod(Class.java:2062) > at java.base/sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:712) > at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:570) > > So what do you mean when saying that you don't see it in the Oracle JDK? > > Regards, > Volker > >> David >> >> >>> -Alan >>> >> From weijun.wang at oracle.com Wed May 24 03:46:44 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 24 May 2017 11:46:44 +0800 Subject: Code Review Request, JDK-8180856 Remove RecordType.java In-Reply-To: <9a7ebde9-1da6-6ba1-602e-19953f0f844b@oracle.com> References: <9a7ebde9-1da6-6ba1-602e-19953f0f844b@oracle.com> Message-ID: <1f6a6d28-ff0b-20f6-067e-ff0e76faa5cc@oracle.com> Change looks fine. --Max On 05/24/2017 01:33 AM, Xuelei Fan wrote: > Hi, > > In the SunJSSE provider implementation, the code of > src/java.base/share/classes/sun/security/ssl/RecordType.java was merged > into Ciphertext.java. The RecordType.java should be deleted in case of > any misleading. > > Code clean up, no webrev. The update in JDK 10 repository looks like: > > JDK10/jdk $ hg status . > R src/java.base/share/classes/sun/security/ssl/RecordType.java > > > Thanks, > Xuelei From volker.simonis at gmail.com Wed May 24 07:13:40 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 24 May 2017 09:13:40 +0200 Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: <59249529.3030103@oracle.com> References: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> <59249529.3030103@oracle.com> Message-ID: On Tue, May 23, 2017 at 10:01 PM, Alex Buckley wrote: > On 5/23/2017 7:44 AM, Volker Simonis wrote: >> >> So maybe I rephrase my question a little more generally: >> >> Is it required for the verifier to do security and/or access checks >> during the verification phase or could/should these checks be >> postponed to runtime? The issue with verification errors due to >> missing classes from Remi's previous answer is probably a corner case >> of this question. > > > Verification must perform class loading in order to check subtyping, but > verification does not check access to the loaded classes. To be precise, > verification in JVMS 4.10.1 does not appeal to class resolution (JVMS > 5.4.3.1) nor to access control (JVMS 5.4.4). Nor does verification in JVMS > 4.10.1 know what the package.access file is. > > What you are seeing when the Security Manager is enabled is that class > loading fails (due to a package.access check in Hotspot) and so verification > fails. The verifier is not performing the package.access check per se. > OK, so from what you say I understand that the verification errors I see with the Security Manager enabled are an implementation detail of HotSpot (because verification uses the same class loading mechanism like the runtime) which is not required but still acceptable under the JVMS. Is that correct? Thanks, Volker > Alex From sean.mullan at oracle.com Thu May 25 14:46:40 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 25 May 2017 10:46:40 -0400 Subject: RFR 8178794: krb5 client should ignore sname in incoming tickets In-Reply-To: <4526fa1e-0019-6103-a410-f688bc49866f@oracle.com> References: <0019ae5b-89da-de04-c143-1095893e5d45@oracle.com> <4526fa1e-0019-6103-a410-f688bc49866f@oracle.com> Message-ID: <210748b9-9da1-9b96-578e-433a980a7542@oracle.com> Looks fine to me. --Sean On 5/10/17 7:35 PM, Weijun Wang wrote: > Ping again. > > On 04/14/2017 03:18 PM, Weijun Wang wrote: >> Hi Valerie >> >> Please take a review of >> >> http://cr.openjdk.java.net/~weijun/8178794/webrev.00/ >> >> The sname field in the ticket is meant to be read by a server and the >> client should use the one inside KDC-REP's enc-part. >> >> Thanks >> Max From sean.mullan at oracle.com Fri May 26 12:48:00 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 May 2017 08:48:00 -0400 Subject: [9] RFR 8180635: (doc) Clarify the compatibility and interoperability issue when using provider default values In-Reply-To: References: Message-ID: Just a couple of comments: - the same text is in KeyPairGeneratorSpi and AlgorithmParameterGeneratorSpi so we should add the warning in those classes too - we should add the same warning to javax.crypto.KeyGenerator and KeyGeneratorSpi - Please change "Oracle Providers" to "JDK Providers", since all of these providers are included in the JDK implementation, and we don't want to include "Oracle" in the javadocs. (Plus the name of this guide will be changed to "JDK Providers" at some point in the near future). - Suggest changing the sentence "Even ..." to "Additionally, the default value for a provider may change in a future version." - s/Thus/Therefore/ --Sean On 5/23/17 10:13 PM, Valerie Peng wrote: > Sean, > > Can you please review this javadoc-only changes for JDK 9? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8180635 > Webrev: http://cr.openjdk.java.net/~valeriep/8180635/webrev.00/ > > Thanks, > Valerie From artem.smotrakov at oracle.com Fri May 26 22:19:39 2017 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 26 May 2017 15:19:39 -0700 Subject: RFR(XS) : 8180895 : java/security/AccessController/DoPrivAccompliceTest.java has to be improved In-Reply-To: <807D35FC-39D4-40BD-A7D0-A5D2FA7B39EB@oracle.com> References: <807D35FC-39D4-40BD-A7D0-A5D2FA7B39EB@oracle.com> Message-ID: <63dff5ef-9e7c-1c4d-11ba-caa21308f792@oracle.com> @summary doesn't seem to be correct, the test uses user.name system property. Otherwise, looks good for me. Artem On 05/23/2017 10:17 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html >> 81 lines changed: 37 ins; 23 del; 21 mod; > Hi all, > > could you please review the fix which improves and refactors DoPrivAccompliceTest.java test? > the test had several issues: > - it did not fail if the java spawned by JavaToolUtils::runJava exists w/ non-zero exit code > - negative test case was not covered, i.e. the test did not check that if privileges are not granted to the right jar-file an exception is thrown > - the test created files inside test.classes, which might interfere w/ other tests > - the test uses JavaToolUtils testlibrary class to create a jar, start a jvm, which duplicates functionality of the common testlibrary and will be removed by 8180898[1] > > webrev: http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html > jbs: https://bugs.openjdk.java.net/browse/JDK-8180895 > testing: affected tests > > [1] https://bugs.openjdk.java.net/browse/JDK-8180898 > > Thanks, > -- Igor From valerie.peng at oracle.com Fri May 26 22:54:11 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 26 May 2017 15:54:11 -0700 Subject: [9] RFR 8180635: (doc) Clarify the compatibility and interoperability issue when using provider default values In-Reply-To: References: Message-ID: <3c9138f0-3d90-0fbc-fd9f-550c34891fa4@oracle.com> Sean, Thanks for the wording suggestions. Webrev updated at: http://cr.openjdk.java.net/~valeriep/8180635/webrev.01/ Have a wonderful long weekend, Valerie On 5/26/2017 5:48 AM, Sean Mullan wrote: > Just a couple of comments: > > - the same text is in KeyPairGeneratorSpi and > AlgorithmParameterGeneratorSpi so we should add the warning in those > classes too > > - we should add the same warning to javax.crypto.KeyGenerator and > KeyGeneratorSpi > > - Please change "Oracle Providers" to "JDK Providers", since all of > these providers are included in the JDK implementation, and we don't > want to include "Oracle" in the javadocs. (Plus the name of this guide > will be changed to "JDK Providers" at some point in the near future). > > - Suggest changing the sentence "Even ..." to "Additionally, the > default value for a provider may change in a future version." > > - s/Thus/Therefore/ > > --Sean > > On 5/23/17 10:13 PM, Valerie Peng wrote: >> Sean, >> >> Can you please review this javadoc-only changes for JDK 9? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8180635 >> Webrev: http://cr.openjdk.java.net/~valeriep/8180635/webrev.00/ >> >> Thanks, >> Valerie > > From sean.mullan at oracle.com Tue May 30 17:50:57 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 30 May 2017 13:50:57 -0400 Subject: [9] RFR 8180635: (doc) Clarify the compatibility and interoperability issue when using provider default values In-Reply-To: <3c9138f0-3d90-0fbc-fd9f-550c34891fa4@oracle.com> References: <3c9138f0-3d90-0fbc-fd9f-550c34891fa4@oracle.com> Message-ID: Just a couple more comments, in this text in each class: * Java™ * Cryptography Architecture JDK Providers Documentation * document for information on the AlgorithmParameterGenerator defaults * used by JDK providers. Don't use bold () on the document name. The words "Documentation" and "document" are redundant. Drop the JCA part. The new guide in JDK 9 will not include that in the title. So, I suggest changing it to simply "JDK Providers", ex: * JDK Providers * document for information on the AlgorithmParameterGenerator defaults * used by JDK providers. --Sean On 5/26/17 6:54 PM, Valerie Peng wrote: > Sean, > > Thanks for the wording suggestions. > Webrev updated at: http://cr.openjdk.java.net/~valeriep/8180635/webrev.01/ > > Have a wonderful long weekend, > Valerie > > On 5/26/2017 5:48 AM, Sean Mullan wrote: >> Just a couple of comments: >> >> - the same text is in KeyPairGeneratorSpi and >> AlgorithmParameterGeneratorSpi so we should add the warning in those >> classes too >> >> - we should add the same warning to javax.crypto.KeyGenerator and >> KeyGeneratorSpi >> >> - Please change "Oracle Providers" to "JDK Providers", since all of >> these providers are included in the JDK implementation, and we don't >> want to include "Oracle" in the javadocs. (Plus the name of this guide >> will be changed to "JDK Providers" at some point in the near future). >> >> - Suggest changing the sentence "Even ..." to "Additionally, the >> default value for a provider may change in a future version." >> >> - s/Thus/Therefore/ >> >> --Sean >> >> On 5/23/17 10:13 PM, Valerie Peng wrote: >>> Sean, >>> >>> Can you please review this javadoc-only changes for JDK 9? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180635 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8180635/webrev.00/ >>> >>> Thanks, >>> Valerie >> >> > From valerie.peng at oracle.com Tue May 30 22:35:22 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 30 May 2017 15:35:22 -0700 Subject: [9] RFR 8180635: (doc) Clarify the compatibility and interoperability issue when using provider default values In-Reply-To: References: <3c9138f0-3d90-0fbc-fd9f-550c34891fa4@oracle.com> Message-ID: <2df1683e-e047-1dc8-a822-e94cb45a2011@oracle.com> Thanks, webrev updated again at: http://cr.openjdk.java.net/~valeriep/8180635/webrev.02/ Valerie On 5/30/2017 10:50 AM, Sean Mullan wrote: > Just a couple more comments, in this text in each class: > > * Java™ > * Cryptography Architecture JDK Providers Documentation > * document for information on the AlgorithmParameterGenerator defaults > * used by JDK providers. > > Don't use bold () on the document name. > > The words "Documentation" and "document" are redundant. > > Drop the JCA part. The new guide in JDK 9 will not include that in the > title. So, I suggest changing it to simply "JDK Providers", ex: > > * JDK Providers > * document for information on the AlgorithmParameterGenerator defaults > * used by JDK providers. > > --Sean > > On 5/26/17 6:54 PM, Valerie Peng wrote: >> Sean, >> >> Thanks for the wording suggestions. >> Webrev updated at: >> http://cr.openjdk.java.net/~valeriep/8180635/webrev.01/ >> >> Have a wonderful long weekend, >> Valerie >> >> On 5/26/2017 5:48 AM, Sean Mullan wrote: >>> Just a couple of comments: >>> >>> - the same text is in KeyPairGeneratorSpi and >>> AlgorithmParameterGeneratorSpi so we should add the warning in those >>> classes too >>> >>> - we should add the same warning to javax.crypto.KeyGenerator and >>> KeyGeneratorSpi >>> >>> - Please change "Oracle Providers" to "JDK Providers", since all of >>> these providers are included in the JDK implementation, and we don't >>> want to include "Oracle" in the javadocs. (Plus the name of this >>> guide will be changed to "JDK Providers" at some point in the near >>> future). >>> >>> - Suggest changing the sentence "Even ..." to "Additionally, the >>> default value for a provider may change in a future version." >>> >>> - s/Thus/Therefore/ >>> >>> --Sean >>> >>> On 5/23/17 10:13 PM, Valerie Peng wrote: >>>> Sean, >>>> >>>> Can you please review this javadoc-only changes for JDK 9? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180635 >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8180635/webrev.00/ >>>> >>>> Thanks, >>>> Valerie >>> >>> >> From felix.yang at oracle.com Wed May 31 09:42:04 2017 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 31 May 2017 17:42:04 +0800 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper Message-ID: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Hi there, please review the patch to various jdk tests to explicitly compiling test libraries and the lib's dependencies. Though it could be a jtreg issue (I think so), it is necessary to get the tests running firstly. Bug: https://bugs.openjdk.java.net/browse/JDK-8181299 Webrev: http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/ Thanks, Felix From daniel.fuchs at oracle.com Wed May 31 10:15:40 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 31 May 2017 03:15:40 -0700 (PDT) Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: <8697e5ea-aa1d-e1ef-9074-fa5c37ff237c@oracle.com> Hi Felix, Looks good to me. Did you try to run each test in isolation (removing JT* between 2 runs) to check that they compile all they need? If you haven't committed yet then I guess a little for f in $(hg st . -nma) ; do \ rm -r JT* ; \ jtreg -verbose:summary -jdk .... $f ; \ done might do the trick ;-) best regards, -- daniel On 31/05/2017 10:42, Felix Yang wrote: > Hi there, > > please review the patch to various jdk tests to explicitly > compiling test libraries and the lib's dependencies. Though it could be > a jtreg issue (I think so), it is necessary to get the tests running > firstly. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8181299 > > Webrev: > > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/ > > Thanks, > > Felix > From chris.hegarty at oracle.com Wed May 31 10:20:18 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 31 May 2017 11:20:18 +0100 Subject: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper In-Reply-To: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com> Message-ID: > On 31 May 2017, at 10:42, Felix Yang wrote: > > Hi there, > > please review the patch to various jdk tests to explicitly compiling test libraries and the lib's dependencies. Though it could be a jtreg issue (I think so), it is necessary to get the tests running firstly. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8181299 > > Webrev: > > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/ This may be ok to get the tests running again, but explicit build targets would be better. The contents, and module dependencies, from classes in the test library are subject to change, so building all classes may require more modules than in the @modules tags in the test. I agree with Daniel, each test should be run separately in a clean environment, to verify that it can build the necessary dependencies. This may be a straight forward way to identify explicit build dependencies and avoid the wildcards. -Chris. From sean.mullan at oracle.com Wed May 31 11:37:39 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 31 May 2017 07:37:39 -0400 Subject: [9] RFR 8180635: (doc) Clarify the compatibility and interoperability issue when using provider default values In-Reply-To: <2df1683e-e047-1dc8-a822-e94cb45a2011@oracle.com> References: <3c9138f0-3d90-0fbc-fd9f-550c34891fa4@oracle.com> <2df1683e-e047-1dc8-a822-e94cb45a2011@oracle.com> Message-ID: <6736995e-de23-a770-af6b-6bf2146de2ce@oracle.com> Just remove the bold-type from "JDK Providers" as I don't think that is necessary. All else looks good, no need to post another review. --Sean On 5/30/17 6:35 PM, Valerie Peng wrote: > Thanks, webrev updated again at: > > http://cr.openjdk.java.net/~valeriep/8180635/webrev.02/ > > Valerie > On 5/30/2017 10:50 AM, Sean Mullan wrote: >> Just a couple more comments, in this text in each class: >> >> * Java™ >> * Cryptography Architecture JDK Providers Documentation >> * document for information on the AlgorithmParameterGenerator defaults >> * used by JDK providers. >> >> Don't use bold () on the document name. >> >> The words "Documentation" and "document" are redundant. >> >> Drop the JCA part. The new guide in JDK 9 will not include that in the >> title. So, I suggest changing it to simply "JDK Providers", ex: >> >> * JDK Providers >> * document for information on the AlgorithmParameterGenerator defaults >> * used by JDK providers. >> >> --Sean >> >> On 5/26/17 6:54 PM, Valerie Peng wrote: >>> Sean, >>> >>> Thanks for the wording suggestions. >>> Webrev updated at: >>> http://cr.openjdk.java.net/~valeriep/8180635/webrev.01/ >>> >>> Have a wonderful long weekend, >>> Valerie >>> >>> On 5/26/2017 5:48 AM, Sean Mullan wrote: >>>> Just a couple of comments: >>>> >>>> - the same text is in KeyPairGeneratorSpi and >>>> AlgorithmParameterGeneratorSpi so we should add the warning in those >>>> classes too >>>> >>>> - we should add the same warning to javax.crypto.KeyGenerator and >>>> KeyGeneratorSpi >>>> >>>> - Please change "Oracle Providers" to "JDK Providers", since all of >>>> these providers are included in the JDK implementation, and we don't >>>> want to include "Oracle" in the javadocs. (Plus the name of this >>>> guide will be changed to "JDK Providers" at some point in the near >>>> future). >>>> >>>> - Suggest changing the sentence "Even ..." to "Additionally, the >>>> default value for a provider may change in a future version." >>>> >>>> - s/Thus/Therefore/ >>>> >>>> --Sean >>>> >>>> On 5/23/17 10:13 PM, Valerie Peng wrote: >>>>> Sean, >>>>> >>>>> Can you please review this javadoc-only changes for JDK 9? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180635 >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8180635/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie >>>> >>>> >>> > From valerie.peng at oracle.com Wed May 31 23:32:04 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 31 May 2017 16:32:04 -0700 Subject: [9] RFR 8180635: (doc) Clarify the compatibility and interoperability issue when using provider default values In-Reply-To: <6736995e-de23-a770-af6b-6bf2146de2ce@oracle.com> References: <3c9138f0-3d90-0fbc-fd9f-550c34891fa4@oracle.com> <2df1683e-e047-1dc8-a822-e94cb45a2011@oracle.com> <6736995e-de23-a770-af6b-6bf2146de2ce@oracle.com> Message-ID: Got it, thanks! Valerie On 5/31/2017 4:37 AM, Sean Mullan wrote: > Just remove the bold-type from "JDK Providers" as I don't > think that is necessary. All else looks good, no need to post another > review. > > --Sean > > On 5/30/17 6:35 PM, Valerie Peng wrote: >> Thanks, webrev updated again at: >> >> http://cr.openjdk.java.net/~valeriep/8180635/webrev.02/ >> >> Valerie >> On 5/30/2017 10:50 AM, Sean Mullan wrote: >>> Just a couple more comments, in this text in each class: >>> >>> * Java™ >>> * Cryptography Architecture JDK Providers Documentation >>> * document for information on the AlgorithmParameterGenerator defaults >>> * used by JDK providers. >>> >>> Don't use bold () on the document name. >>> >>> The words "Documentation" and "document" are redundant. >>> >>> Drop the JCA part. The new guide in JDK 9 will not include that in >>> the title. So, I suggest changing it to simply "JDK Providers", ex: >>> >>> * JDK Providers >>> * document for information on the AlgorithmParameterGenerator defaults >>> * used by JDK providers. >>> >>> --Sean >>> >>> On 5/26/17 6:54 PM, Valerie Peng wrote: >>>> Sean, >>>> >>>> Thanks for the wording suggestions. >>>> Webrev updated at: >>>> http://cr.openjdk.java.net/~valeriep/8180635/webrev.01/ >>>> >>>> Have a wonderful long weekend, >>>> Valerie >>>> >>>> On 5/26/2017 5:48 AM, Sean Mullan wrote: >>>>> Just a couple of comments: >>>>> >>>>> - the same text is in KeyPairGeneratorSpi and >>>>> AlgorithmParameterGeneratorSpi so we should add the warning in >>>>> those classes too >>>>> >>>>> - we should add the same warning to javax.crypto.KeyGenerator and >>>>> KeyGeneratorSpi >>>>> >>>>> - Please change "Oracle Providers" to "JDK Providers", since all >>>>> of these providers are included in the JDK implementation, and we >>>>> don't want to include "Oracle" in the javadocs. (Plus the name of >>>>> this guide will be changed to "JDK Providers" at some point in the >>>>> near future). >>>>> >>>>> - Suggest changing the sentence "Even ..." to "Additionally, the >>>>> default value for a provider may change in a future version." >>>>> >>>>> - s/Thus/Therefore/ >>>>> >>>>> --Sean >>>>> >>>>> On 5/23/17 10:13 PM, Valerie Peng wrote: >>>>>> Sean, >>>>>> >>>>>> Can you please review this javadoc-only changes for JDK 9? >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8180635 >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8180635/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>> >>>>> >>>> >> From alex.buckley at oracle.com Tue May 23 20:01:45 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 23 May 2017 13:01:45 -0700 Subject: JPMS Access Checks, Verification and the Security Manager In-Reply-To: References: <13bb0dc2-9518-b72c-385f-1db95a8edab9@oracle.com> Message-ID: <59249529.3030103@oracle.com> On 5/23/2017 7:44 AM, Volker Simonis wrote: > So maybe I rephrase my question a little more generally: > > Is it required for the verifier to do security and/or access checks > during the verification phase or could/should these checks be > postponed to runtime? The issue with verification errors due to > missing classes from Remi's previous answer is probably a corner case > of this question. Verification must perform class loading in order to check subtyping, but verification does not check access to the loaded classes. To be precise, verification in JVMS 4.10.1 does not appeal to class resolution (JVMS 5.4.3.1) nor to access control (JVMS 5.4.4). Nor does verification in JVMS 4.10.1 know what the package.access file is. What you are seeing when the Security Manager is enabled is that class loading fails (due to a package.access check in Hotspot) and so verification fails. The verifier is not performing the package.access check per se. Alex From igor.ignatyev at oracle.com Wed May 24 05:17:16 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 23 May 2017 22:17:16 -0700 Subject: RFR(XS) : 8180895 : java/security/AccessController/DoPrivAccompliceTest.java has to be improved Message-ID: <807D35FC-39D4-40BD-A7D0-A5D2FA7B39EB@oracle.com> http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html > 81 lines changed: 37 ins; 23 del; 21 mod; Hi all, could you please review the fix which improves and refactors DoPrivAccompliceTest.java test? the test had several issues: - it did not fail if the java spawned by JavaToolUtils::runJava exists w/ non-zero exit code - negative test case was not covered, i.e. the test did not check that if privileges are not granted to the right jar-file an exception is thrown - the test created files inside test.classes, which might interfere w/ other tests - the test uses JavaToolUtils testlibrary class to create a jar, start a jvm, which duplicates functionality of the common testlibrary and will be removed by 8180898[1] webrev: http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8180895 testing: affected tests [1] https://bugs.openjdk.java.net/browse/JDK-8180898 Thanks, -- Igor