From jai.forums2013 at gmail.com Mon Jul 1 05:38:34 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 1 Jul 2019 11:08:34 +0530 Subject: Change in behaviour of SSLSessionContext APIs in recent Java 13 EA versions Message-ID: <86a1f866-bd36-6b43-d02c-551364b8295c@gmail.com> It looks like there has been a change in behaviour in some of the APIs exposed by javax.net.ssl.SSLSessionContext, in recent EA versions of Java 13 (as well as latest upstream master). Before I proceed with the details, I would like to credit Richard Opalka, from WildFly team, as the person who originally noticed this due to its impact on WildFly project[1]. What I have now done is narrow this down to a jtreg testcase which reproduces this issue in a straightforward isolated code[2]. The issues appear (at least) in the SSLSessionContext#getSession(sessionId) and SSLSessionContext#getIds(). Both these APIs no longer return the expected output. For example, the SSLSessionContext#getSession(sessionId) returns null for a valid session id and the SSLSessionContext#getIds() just returns no session ids. The jtreg testcase in [2] opens a server over SSLSocket and a client which just expects a reply from the server. The server when it accepts the connection over the SSLSocket, gets hold of the SSLSession id from that socket and then goes on to invoke the above APIs to try and get hold of this information from the SSLSessionContext. This all works fine on Java 8, 11, 12 and some versions of 13 EA, but fails in recent versions of 13 as well as upstream master branch. As Richard points out in [1], it seems related to certain stateless session related changes in the JDK, but I don't have enough knowledge in that area nor of the changes to understand if this change in behaviour is expected or if this is genuinely a bug - hence decided to raise this in the mailing list instead of filing a JBS. [1] https://issues.jboss.org/browse/WFCORE-4532 [2] http://cr.openjdk.java.net/~jpai/webrev/sslsessioncontext/0/webrev/ -Jaikiran From weijun.wang at oracle.com Mon Jul 1 07:41:03 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 1 Jul 2019 15:41:03 +0800 Subject: RFR 8217375: jarsigner breaks old signature with long lines in manifest In-Reply-To: <1561894686.2441.49.camel@paratix.ch> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> Message-ID: <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> https://cr.openjdk.java.net/~weijun/8217375/webrev.02 uploaded. There are still several trailing spaces and I've removed them. I just ran a test job: SignTwice.java failed on Windows with `failed to clean up files after test`. Most likely a file is not closed. The src change looks good. In fact, I am wondering if we need to support ManifestDigester.get(MF_MAIN_ATTRS, b) at all. Is it possible we miss a coding error because of it? I'll take a look at the tests. Thanks, Max > On Jun 30, 2019, at 7:38 PM, Philipp Kunz wrote: > > Hi John, Max, and everyone > > Finally found some time again for this, please excuse the delay. > > Even though I think adding a keyalg parameter next to genkeypair is a different topic, it should not do any harm, and I added it. > > I find your proposal for how to print the manifests good. I preferred to display \n as well because I would otherwise think it was not there sooner or later and confuse myself. In that context also, I intentionally did not add an echoManifest method overload with a String parameter because it could and I believe also actually would confuse filenames and manifests both represented as String. Only a few times "Utils.echoManifest(Utils.readJarManifestBytes(" occurs which might be more verbose than necessary. I have also some doubts that all manifest are actually valid UTF-8. More fine-tuning might be desired. > > I also found running jarsigner slow which is why I suggested adding it as a tool like jar and others in a different thread and which was not accepted then. As for PreserveRawManifestEntryAndDigest, there is use of sun.security.tools.jarsigner.Main.main or run. Using sun.security.tools.jarsigner.Main re-uses loading of the keystore while avoiding another JVM which I believe to be almost perfect apart from the API used not looking very public. Also in terms of performance I think it should be equivalent to JarSigner::sign. When the output should be caputered, there is no way without another JVM (without the jarsigner tool). > > DigestDontIgnoreCase.getManifestBytes could reformat the manifest: agreed and changed accordingly. Now Utils.readJarManifestBytes. Note that it does not use a Manifest like before with JarFile.getManifest. > > EmptyIndividualSectionName.testNameEmptyTrusted: I honestly have no clue how this can be made to work. That is at least what I remember from when I wrote it half a year ago. We might as well come eventually to the conclusion that such a test is not necessary. The idea seems to be to invoke getTrustedAttributes("") on a manifest but it is not public. Help appreciated. > > About the several TODOs, FIXMEs, and FIXED_8217375: The tests in the patch have to be "kind of calibrated" to make sure things don't change with the patch that should not. Ideally these tests would have existed before but the have not. The tests that make sure that some cases still work the same now also contain some changes. In a usual case one would let the tests of a patch run against the old impl and see what has failed before, then apply the main source part of the patch and see something fixed, and not touching any other test guarantees that nothing else changes. In this particular case I found that not working. It is also not possible to create an independent patch with tests only because the tests closely relate to the patch. My idea was that all the FIXMEs and TODOs are removed before actually commiting the patch, after someone has confirmed that all the tests run fine against the previous impl which should make sure certain behavior has not changed. One of the tests does not even compile without the impl changes. After everyone has agreed that there are enough tests to make sure nothing changed by accident, we can remove those FIXMEs and TODOs and have then to pay close attention that no tests are removed or changed anymore. For tracking such changes, git would be an option, but in this case I figured I could not use it myself because I thought I should create a patch against the head branch and you could not see my branches anyway but maybe someone of you can create a branch and share it with me. In any case, the result should be only one commit ending up in the head branch (tip). If that sounds complicated it's what I encountered too. If someone has a better idea how to deal with it, please let me know. > > backwars - backwards - changed > > ManifestSigester - ManifestDigester - changed > > att - attr - changed > > Paths.get - Path.of - changed > > MainAttributesConfused.java - It is not necessary that a file with that name exists in order to show the effect. The signature gets confused if a manifest section exists. Such a section would be created when signing a jar file that contains a file with that name. I don't remember if I actually tried it with a file but testAddManifestMainAttributesSection shows that and how the patch makes a difference. Do you think another test should be created which signs a file with that name? > > PreserveRawManifestEntryAndDigest.java - I hope with the improved manifest encoding (\r and \n) on the console that an output overflow does not happen anymore. I remember having tried to reduce the number of tests as much as possible and justifyable already. I don't currently see a promising approach as how to substantially simplify it, hence, any hint appreciated, or I might come back to optimization at some later point. For now I was able to simplify getExpectedJarSignerOutputUpdatedContentNotValidatedBySignerA even though I would have preferred to be able to utilize OutputAnalyzer. I think to remember that verifying a jar file by opening it in verifying mode verifies all signers and in this case there is only one valid. > > Thanks for offering to look into the change in OutputAnalyzer.java because alternative would include/increase copy-paste. > > And from the other mail: > > ManifestDigester.java: if (!findSection(0, pos)) throw new IllegalStateException - moved exception back to JarSigner.SignatureFile. > > removed redundant 696 mfCreated = true; > > "You added a new check. Do you mean if the signer is the same then the SF will be rewritten anyway and there is no need to retain old MANIFEST.MF bytes?" - Yes, exactly. Added isBlockOrSF around line 900. See also WasSignedByOtherSigner test. > > "MainAttributesConfused.java, PreserveRawManifestEntryAndDigest.java, RemoveDifferentKeyAlgBlockFile.java, and SectionNameContinuedVsLineBreak.java fail on Windows because a JarFile object is not closed. You might want to use try-with-resources on them." - Hope I got them all. > > About tests timing out, I haven't encountered that but of course it has to run quick enough also on other machines. Before going into too much optimization I would appreciate and prefer to either get some (however remote or informal) confirmation that the set of test cases is appropriate or to get rid of superfluous tests before making them faster. Even more important is probably before anything else if the tests currently present are sufficient or if some test case has slipped and is still missing. > > One last note for now concerning Compatibility test. I hope it currently demonstrates what I think it should, verify jar signatures between jdk versions while preserving behavior with default parameters. The code itself requires probably a major clean-up before it can really be merged. I tried not to change more than necessary for now but it does not look now in an as good shape as how I originally encountered it. I'm also still thinking about Max's suggestion to add another test with a jarfile commited along with the tests to check compatibility but could still not yet convince myself that this would be comprehensive enough to replace the Compatibility additions. On the other hand, these compatibility test extensions have slightly more or different scope than the remainder of the patch, I guess, and leave some room for opinions and interpretation. Ideally, compatibility would have been covered with tests before and breaking signatures with increasing the manifest line width would have been noticed earlier. In my opinion there still is no better time than now to add such tests. At least we should make us confident not to break anything again this time. > > Thank you very much for all the good points. I appreciate all your input and find it very valuable. > > Regards, > Philipp > > > > > > On Fri, 2019-06-21 at 11:32 +0800, Weijun Wang wrote: >> The tests. >> >> - For all: >> >> We are thinking about removing default value for -keyalg for "keytool -genkeypair" some day, so it will be better to add an explicit "-keyalg RSA" or "-keyalg EC" now. >> >> There are several tests printing out the manifest in a sequence of "[[0]=83='S', ...". While it is precise, I find it not very easy to check. How about we just print out the string format but for each "\r" we just print "\r" literally and keep printing "\n" with a new line, like this: >> >> Signature-Version: 1.0\r >> Created-By: 13-internal (Oracle Corporation)\r >> SHA-256-Digest-Manifest: Pxklci7ELW1zzSh2jZ+oz7TPR0WK2uTsAIiHar1m6Eo=\r >> SHA-256-Digest-Manifest-Main-Attributes: ETfvdTNx3yN/ClSZz20wR0SM9ta8H7O\r >> E7U0F4uZ9JV8=\r >> \r >> Name: abc\r >> SHA-256-Digest: uTZ8UM3iJLPtl8W7+NEC/AC2auI7LP2Gu53ajj6jLgg=\r >> \r >> >> If you find running jarsigner slow, is the JarSigner::sign API any better? The verify side can also usually be replaced with open the file and read everything inside unless you want to grab certain outputs, but those can also be done with JarEntry::getSigners. >> >> - DigestDontIgnoreCase.java: >> >> getManifestBytes(). This could reformat the manifest (I understand it's irrelevant in this test), you can just return >> >> jf.getInputStream(jf.getJarEntry(JarFile.MANIFEST_NAME)).readAllBytes() >> >> - EmptyIndividualSectionName.java: >> >> Are you going to do something around testNameEmptyTrusted()? >> >> - FindHeaderEndVsManifestDigesterFindFirstSection.java: >> >> Several TODO and FIXME. >> >> 52: typo: backwars- >> >> 76: No need to maintain FIXED_8217375 anymore >> >> 229: Typo: ManifestSigester >> >> - InsufficientSectionDelimiter.java: >> >> We usually abbreviate "attribute" to "attr" instead of "att". >> >> We usually use Path.of() instead of Paths.get() these days. >> >> - MainAttributesConfused.java: >> >> Have you tried adding a file named "Manifest-Main-Attributes" into a jar and see if it would mess up anything? >> >> - PreserveRawManifestEntryAndDigest.java: >> >> This test is running for a long time. The output is also quite big and you can see "Output overflow" inside which means if there is a failure it might not show. Is it possible to simplify it? >> >> getExpectedJarSignerOutputUpdatedContentNotValidatedBySignerA(). The output might change often. If you only focus on several lines, it's better to check them with OutputAnalyzer::shouldMatch***. We can always manually construct an OutputAnalyzer object. >> >> - DigestInput.java and FindSection.java: >> >> static final boolean FIXED_8217375 = true; >> >> Is this still needed? >> >> - OutputAnalyzer.java: >> >> This is a shared utility class and you changed the behavior. It might be correct (start matching *after* the from line) but I cannot be sure if it would break anything. I'll ask people about it. >> >> Thanks, >> Max >> >> >> >> >> >>> >>> On Jun 11, 2019, at 3:08 PM, Weijun Wang < >>> weijun.wang at oracle.com >>> > wrote: >>> >>> Hi Philipp, >>> >>> I'll start reviewing this code change. Since this is a P3 bug fix, we still have a month's time (before RDP 2 starts on 7/18) to work on it. >>> >>> Also, I've included John as a reviewer. He is the author of the Compatibility.java test. >>> >>> Thanks, >>> Max >>> >>> >>>> >>>> On May 23, 2019, at 9:49 AM, Weijun Wang < >>>> weijun.wang at oracle.com >>>> > wrote: >>>> >>>> Hi Philipp, >>>> >>>> I've just uploaded your patch to >>>> >>>> >>>> http://cr.openjdk.java.net/~weijun/8217375/webrev.01/ >>> >>> >>> >> >> >> > <8217375-jarsignerbreaksexistingsignatures-20190630.patch> From anthony.scarpino at oracle.com Mon Jul 1 12:03:28 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 1 Jul 2019 05:03:28 -0700 Subject: Change in behaviour of SSLSessionContext APIs in recent Java 13 EA versions In-Reply-To: <86a1f866-bd36-6b43-d02c-551364b8295c@gmail.com> References: <86a1f866-bd36-6b43-d02c-551364b8295c@gmail.com> Message-ID: Hi Session ids can change due to the way the way stateless operates in the RFCs, particularly if a client doesn?t provide a session Id during resumption. I can take a look at your test and let you know what I find. Thanks Tony > On Jun 30, 2019, at 10:38 PM, Jaikiran Pai wrote: > > It looks like there has been a change in behaviour in some of the APIs > exposed by javax.net.ssl.SSLSessionContext, in recent EA versions of > Java 13 (as well as latest upstream master). Before I proceed with the > details, I would like to credit Richard Opalka, from WildFly team, as > the person who originally noticed this due to its impact on WildFly > project[1]. What I have now done is narrow this down to a jtreg testcase > which reproduces this issue in a straightforward isolated code[2]. > > The issues appear (at least) in the > SSLSessionContext#getSession(sessionId) and SSLSessionContext#getIds(). > Both these APIs no longer return the expected output. For example, the > SSLSessionContext#getSession(sessionId) returns null for a valid session > id and the SSLSessionContext#getIds() just returns no session ids. > > The jtreg testcase in [2] opens a server over SSLSocket and a client > which just expects a reply from the server. The server when it accepts > the connection over the SSLSocket, gets hold of the SSLSession id from > that socket and then goes on to invoke the above APIs to try and get > hold of this information from the SSLSessionContext. This all works fine > on Java 8, 11, 12 and some versions of 13 EA, but fails in recent > versions of 13 as well as upstream master branch. > > As Richard points out in [1], it seems related to certain stateless > session related changes in the JDK, but I don't have enough knowledge in > that area nor of the changes to understand if this change in behaviour > is expected or if this is genuinely a bug - hence decided to raise this > in the mailing list instead of filing a JBS. > > [1] https://issues.jboss.org/browse/WFCORE-4532 > [2] http://cr.openjdk.java.net/~jpai/webrev/sslsessioncontext/0/webrev/ > > -Jaikiran > From christoph.langer at sap.com Mon Jul 1 14:25:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 1 Jul 2019 14:25:45 +0000 Subject: [11u]: RFR: Backport of 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: <63478A16-049F-4B16-A76C-4B1BB6AFF6F5@amazon.com> References: <63478A16-049F-4B16-A76C-4B1BB6AFF6F5@amazon.com> Message-ID: Hi Paul, thanks for your review. > In CertAndKeyGen.java, does generate() need a throws declaration? It doesn't. IllegalArgumentException is a RuntimeException and as such doesn't need a throws declaration. And InvalidKeyException is obviously not needed and was removed in the original changeset as well. > Otherwise looks good. Thanks. I also asked Max Wang to have a look off list and he seems to agree as well. > We've been talking about backporting patches with CSRs and have done at > least one. Imo, 8076190 and 8213400 are good backport candidates since the > spec changes are minor. Yes, a CSR is not necessarily a showstopper for a backport. But as it is not my area of expertise and there's no other reason that makes backports of these bugs important to me, I don't want to take the additional work and responsibility for these backports. But feel free to do this ? So, I guess I'm good to push this, once approved. Cheers, Christoph From xuelei.fan at oracle.com Mon Jul 1 16:33:19 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 1 Jul 2019 09:33:19 -0700 Subject: Request for Review [14] JDK-8226976, SessionTimeOutTests uses == operator for String value check Message-ID: Hi, In the following test case, "==" is used to compare two strings. As is not a comment coding convention. I would like to use "equals()" method instead. Thanks, Xuelei $ hg diff test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java diff -r 73f1c84ca264 test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java --- a/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java Thu Jun 27 22:03:19 2019 +0200 +++ b/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java Mon Jul 01 09:29:23 2019 -0700 @@ -283,7 +283,7 @@ } System.out.print(sess + " " + lifetime); if (((timeout == 0) || (lifetime < timeout)) && - (isTimedout == "YES")) { + isTimedout.equals("YES")) { isTimedout = "Invalidated before timeout"; } From sean.mullan at oracle.com Mon Jul 1 16:42:12 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 1 Jul 2019 12:42:12 -0400 Subject: Request for Review [14] JDK-8226976, SessionTimeOutTests uses == operator for String value check In-Reply-To: References: Message-ID: Hi Xuelei, There was already an RFR post for this from Jaikiran: https://mail.openjdk.java.net/pipermail/security-dev/2019-June/020307.html --Sean On 7/1/19 12:33 PM, Xuelei Fan wrote: > Hi, > > In the following test case, "==" is used to compare two strings.? As is > not a comment coding convention.? I would like to use "equals()" method > instead. > > Thanks, > Xuelei > > > $ hg diff test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java > diff -r 73f1c84ca264 > test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java > --- a/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java Thu Jun > 27 22:03:19 2019 +0200 > +++ b/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java Mon Jul > 01 09:29:23 2019 -0700 > @@ -283,7 +283,7 @@ > ???????????? } > ???????????? System.out.print(sess + "????? " + lifetime); > ???????????? if (((timeout == 0) || (lifetime < timeout)) && > -????????????????????????????????? (isTimedout == "YES")) { > +????????????????????????????????? isTimedout.equals("YES")) { > ???????????????? isTimedout = "Invalidated before timeout"; > ???????????? } From xuelei.fan at oracle.com Mon Jul 1 16:44:36 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 1 Jul 2019 09:44:36 -0700 Subject: Request for Review [14] JDK-8226976, SessionTimeOutTests uses == operator for String value check In-Reply-To: References: Message-ID: <99a4b555-4456-891a-8acc-6181faf14bfe@oracle.com> Oops, I'm triage new bugs and missed that thread. Thanks for the remind. I will review Jaikiran's thread. Thanks, Xuelei On 7/1/2019 9:42 AM, Sean Mullan wrote: > Hi Xuelei, > > There was already an RFR post for this from Jaikiran: > https://mail.openjdk.java.net/pipermail/security-dev/2019-June/020307.html > > --Sean > > > On 7/1/19 12:33 PM, Xuelei Fan wrote: >> Hi, >> >> In the following test case, "==" is used to compare two strings.? As >> is not a comment coding convention.? I would like to use "equals()" >> method instead. >> >> Thanks, >> Xuelei >> >> >> $ hg diff test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java >> diff -r 73f1c84ca264 >> test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java >> --- a/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java Thu >> Jun 27 22:03:19 2019 +0200 >> +++ b/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java Mon >> Jul 01 09:29:23 2019 -0700 >> @@ -283,7 +283,7 @@ >> ????????????? } >> ????????????? System.out.print(sess + "????? " + lifetime); >> ????????????? if (((timeout == 0) || (lifetime < timeout)) && >> -????????????????????????????????? (isTimedout == "YES")) { >> +????????????????????????????????? isTimedout.equals("YES")) { >> ????????????????? isTimedout = "Invalidated before timeout"; >> ????????????? } From xuelei.fan at oracle.com Mon Jul 1 16:47:26 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 1 Jul 2019 09:47:26 -0700 Subject: [PATCH] JDK-8226976 - SessionTimeOutTests uses == operator for String value check In-Reply-To: <2e94b61c-f1d8-f838-ad52-39364c72fd1f@gmail.com> References: <2e94b61c-f1d8-f838-ad52-39364c72fd1f@gmail.com> Message-ID: <38fd4989-d507-e54f-ec5c-e596412097f6@oracle.com> Hi Jaikiran, Would you mind update the copyright date to 2019? Otherwise, looks good to me. Thanks, Xuelei On 6/29/2019 6:03 AM, Jaikiran Pai wrote: > While investigating a potential regression in JDK 13+, I happened to use > the test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java. This > test incorrectly uses the == operator for one of the String checks. I > have filed a bug[1] with the details and have a patch with the fix here[2]. > > Can I please get a review and a sponsor for this change? > > [1] https://bugs.openjdk.java.net/browse/JDK-8226976 > > [2] http://cr.openjdk.java.net/~jpai/webrev/8226976/0/webrev/ > > -Jaikiran > > From anthony.scarpino at oracle.com Mon Jul 1 16:58:30 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 1 Jul 2019 09:58:30 -0700 Subject: Change in behaviour of SSLSessionContext APIs in recent Java 13 EA versions In-Reply-To: <86a1f866-bd36-6b43-d02c-551364b8295c@gmail.com> References: <86a1f866-bd36-6b43-d02c-551364b8295c@gmail.com> Message-ID: <2e4163e9-8630-9d36-39c1-e44b714baabb@oracle.com> Hi, You are correct this behavior is a result of stateless resumption. The stateless servers does not keep session state information and is currently opt-out. The system property 'jdk.tls.server.enableSessionTicketExtension' set to false will return the server to stateful. The client side has a property also 'jdk.tls.client.enableSessionTicketExtension'. So in the case of using getSession() and getIds(), stateless resumption is one of the environments that session information is not available. Tony On 6/30/19 10:38 PM, Jaikiran Pai wrote: > It looks like there has been a change in behaviour in some of the APIs > exposed by javax.net.ssl.SSLSessionContext, in recent EA versions of > Java 13 (as well as latest upstream master). Before I proceed with the > details, I would like to credit Richard Opalka, from WildFly team, as > the person who originally noticed this due to its impact on WildFly > project[1]. What I have now done is narrow this down to a jtreg testcase > which reproduces this issue in a straightforward isolated code[2]. > > The issues appear (at least) in the > SSLSessionContext#getSession(sessionId) and SSLSessionContext#getIds(). > Both these APIs no longer return the expected output. For example, the > SSLSessionContext#getSession(sessionId) returns null for a valid session > id and the SSLSessionContext#getIds() just returns no session ids. > > The jtreg testcase in [2] opens a server over SSLSocket and a client > which just expects a reply from the server. The server when it accepts > the connection over the SSLSocket, gets hold of the SSLSession id from > that socket and then goes on to invoke the above APIs to try and get > hold of this information from the SSLSessionContext. This all works fine > on Java 8, 11, 12 and some versions of 13 EA, but fails in recent > versions of 13 as well as upstream master branch. > > As Richard points out in [1], it seems related to certain stateless > session related changes in the JDK, but I don't have enough knowledge in > that area nor of the changes to understand if this change in behaviour > is expected or if this is genuinely a bug - hence decided to raise this > in the mailing list instead of filing a JBS. > > [1] https://issues.jboss.org/browse/WFCORE-4532 > [2] http://cr.openjdk.java.net/~jpai/webrev/sslsessioncontext/0/webrev/ > > -Jaikiran > From ecki at zusammenkunft.net Mon Jul 1 17:51:42 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 1 Jul 2019 17:51:42 +0000 Subject: Request for Review [14] JDK-8226976, SessionTimeOutTests uses == operator for String value check In-Reply-To: References: Message-ID: Also the `is*` prefix would point to a boolean, that?s maybe a cleaner data type than a case sensitive string? -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Xuelei Fan Gesendet: Montag, Juli 1, 2019 6:44 PM An: security-dev at openjdk.java.net Betreff: Request for Review [14] JDK-8226976, SessionTimeOutTests uses == operator for String value check Hi, In the following test case, "==" is used to compare two strings. As is not a comment coding convention. I would like to use "equals()" method instead. Thanks, Xuelei $ hg diff test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java diff -r 73f1c84ca264 test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java --- a/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java Thu Jun 27 22:03:19 2019 +0200 +++ b/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java Mon Jul 01 09:29:23 2019 -0700 @@ -283,7 +283,7 @@ } System.out.print(sess + " " + lifetime); if (((timeout == 0) || (lifetime < timeout)) && - (isTimedout == "YES")) { + isTimedout.equals("YES")) { isTimedout = "Invalidated before timeout"; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Jul 1 18:01:11 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 1 Jul 2019 11:01:11 -0700 Subject: Request for Review [14] JDK-8226976, SessionTimeOutTests uses == operator for String value check In-Reply-To: References: Message-ID: On 7/1/2019 10:51 AM, Bernd Eckenfels wrote: > Also the `is*` prefix would point to a boolean, that?s maybe a cleaner > data type than a case sensitive string? > I agreed. The "isTimedout" is also used to for strings other than "YES"/"No". I don't think it is a good code convention. isTimedout = "Invalidated before timeout"; As Jaikiran had taken care of the issue in a previous thread: https://mail.openjdk.java.net/pipermail/security-dev/2019-June/020307.html I will leave it to Jaikiran if we want to make more improvement in that code review thread. Thanks, Xuelei > > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Xuelei Fan > *Gesendet:* Montag, Juli 1, 2019 6:44 PM > *An:* security-dev at openjdk.java.net > *Betreff:* Request for Review [14] JDK-8226976, SessionTimeOutTests uses > == operator for String value check > Hi, > > In the following test case, "==" is used to compare two strings. As is > not a comment coding convention. I would like to use "equals()" method > instead. > > Thanks, > Xuelei > > > $ hg diff test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java > diff -r 73f1c84ca264 > test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java > --- a/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java > Thu Jun 27 22:03:19 2019 +0200 > +++ b/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java > Mon Jul 01 09:29:23 2019 -0700 > @@ -283,7 +283,7 @@ > } > System.out.print(sess + " " + lifetime); > if (((timeout == 0) || (lifetime < timeout)) && > - (isTimedout == "YES")) { > + isTimedout.equals("YES")) { > isTimedout = "Invalidated before timeout"; > } From jai.forums2013 at gmail.com Tue Jul 2 02:05:22 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 2 Jul 2019 07:35:22 +0530 Subject: [PATCH] JDK-8226976 - SessionTimeOutTests uses == operator for String value check In-Reply-To: <38fd4989-d507-e54f-ec5c-e596412097f6@oracle.com> References: <2e94b61c-f1d8-f838-ad52-39364c72fd1f@gmail.com> <38fd4989-d507-e54f-ec5c-e596412097f6@oracle.com> Message-ID: Thank you Xuelei. Here's the updated webrev http://cr.openjdk.java.net/~jpai/webrev/8226976/01/webrev/. Updated the copyright year and also added you as the reviewer, in the commit log message. -Jaikiran On 01/07/19 10:17 PM, Xuelei Fan wrote: > Hi Jaikiran, > > Would you mind update the copyright date to 2019?? Otherwise, looks > good to me. > > Thanks, > Xuelei > > On 6/29/2019 6:03 AM, Jaikiran Pai wrote: >> While investigating a potential regression in JDK 13+, I happened to use >> the test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java. This >> test incorrectly uses the == operator for one of the String checks. I >> have filed a bug[1] with the details and have a patch with the fix >> here[2]. >> >> Can I please get a review and a sponsor for this change? >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8226976 >> >> [2] http://cr.openjdk.java.net/~jpai/webrev/8226976/0/webrev/ >> >> -Jaikiran >> >> From weijun.wang at oracle.com Tue Jul 2 02:22:11 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Jul 2019 10:22:11 +0800 Subject: RFR 8225687: Newly added sspi.cpp in JDK-6722928 still contains some small errors In-Reply-To: References: <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> <20190529172354.GH7457@twosigma.com> <20190610235635.GL7457@twosigma.com> Message-ID: <49BB2145-B65F-46CA-90A8-BA55588BD48D@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8225687/webrev.00/ Most changes are around const usage in gssapi.h. Note that this is internal so the change could only prevent any coding error and will not be visible outside JDK. Other changes are inside gss_import_name(), gss_compare_name(). I also changed some names like get_oid_set_desc -> show_oid_set. Thanks, Max > On Jun 13, 2019, at 10:48 AM, Weijun Wang wrote: > > I've filed https://bugs.openjdk.java.net/browse/JDK-8225687. > >> On Jun 11, 2019, at 7:56 AM, Nico Williams wrote: >> >> On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote: >>> Updated webrev at >>> >>> http://cr.openjdk.java.net/~weijun/6722928/webrev.08/ >> >> - src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java >> >> Ugh, I never noticed GSSUtil.useMSInterop(). This really should not >> be needed. I believe a proper implementation of RFC4178 wouldn't >> need it. > > I tried but scared away by MS-SPNG's appendix on which version of Windows supports which style of mechListMic. Now that Java only supports one underlying mechanism this field is looks not so crucial. > >> >> I can't expect you to do that, but can we have a bug opened for this? > > There was one at https://bugs.openjdk.java.net/browse/JDK-6773898. > >> >> - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java >> >> Shouldn't the sspi_bridge.dll be in the lib directory? > > The DLLs have always been in /bin. Maybe it's more easily loadable by java.exe. > >> >> - src/java.security.jgss/share/native/libj2gss/NativeFunc.h >> - src/java.security.jgss/share/native/libj2gss/gssapi.h >> >> These continue to have improper constification. >> >> There should be no function arguments of type "const gss_...". >> >> I've a PR for Heimdal to fix this in Heimdal. It was very >> mechanical: search the prototypes and function definitions for >> >> \> >> then change that to gss_const_... then fix all the warnings and >> errors that came up when building the result. > > OK. > >> >> - All remaining commentary will be about >> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp >> >> - CHECK_*() macros >> >> Macro bodies should not end in a semi-colon. > > OK. > >> >> If these were public and since these macro bodies are all if >> statements, you should wrap them in do { } while (0), but since >> they're private we can make sure that all uses are correct. >> >> - gss_import_name() doesn't check that the first two bytes of the >> input buffer are the expected token ID when the name-type is >> GSS_C_NT_EXPORTED_NAME. > > OK. > >> >> - gss_import_name() doesn't check that the third byte of the input >> buffer is 0 when the name-type is GSS_C_NT_EXPORTED_NAME. > > OK. > >> >> - gss_compare_name(), this code will not distinguish a name of the >> form 'foo@' from 'foo\@' >> >> 434 if (l1 < l2 && n2[l1] != L'@' >> 435 || l2 < l1 && n1[l2] != L'@') { >> 436 return GSS_S_COMPLETE; // different >> 437 } >> >> Honestly, this is not the most serious problem because nothing >> really should be using gss_compare_name(), but you do use it... and >> anyways, it's wrong. > > Yes, it's called in GSSLibStub.c and those are the functions I must support. > >> >> Perhaps the gss_name_struct struct should have a length of realm or >> length-of-not-realm-part field to make this check easier. >> >> - gss_compare_name(), do not use NORM_IGNORECASE > > But I do notice that "Administrator" can also be named "administrator", and "HTTP/host" can also be "http/host". > >> >> - gss_canonicalize_name() should check that mech_type is Kerberos > > OK. > >> >> I'll continue later. I'm in gss_init_sec_context(), about 58% of the >> way through. > > Please. > > Thanks, > Max > >> >> Nico >> -- > From jai.forums2013 at gmail.com Tue Jul 2 02:23:53 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 2 Jul 2019 07:53:53 +0530 Subject: Change in behaviour of SSLSessionContext APIs in recent Java 13 EA versions In-Reply-To: <2e4163e9-8630-9d36-39c1-e44b714baabb@oracle.com> References: <86a1f866-bd36-6b43-d02c-551364b8295c@gmail.com> <2e4163e9-8630-9d36-39c1-e44b714baabb@oracle.com> Message-ID: Hello Tony, On 01/07/19 10:28 PM, Anthony Scarpino wrote: > Hi, > > You are correct this behavior is a result of stateless resumption.? > The stateless servers does not keep session state information and is > currently opt-out.? Thank you for looking into this and providing the details. > The system property 'jdk.tls.server.enableSessionTicketExtension' set > to false will return the server to stateful.? The client side has a > property also 'jdk.tls.client.enableSessionTicketExtension'. > > So in the case of using getSession() and getIds(), stateless > resumption is one of the environments that session information is not > available. Do you think the class-level as well as these method level javadoc of the SSLSessionContext would need an update then? Right now the class-level javadoc states: There are SSLSessionContext parameters that affect how ?* sessions are stored: ?*
    ?*?????
  • Sessions can be set to expire after a specified ?*????? time limit. ?*?????
  • The number of sessions that can be stored in context ?*????? can be limited. ?*
?* A session can be retrieved based on its session id, and all session id's ?* in a SSLSessionContext can be listed. There's a mention about: "Not all environments will contain session contexts." but I take it as meaning that, not all environments will have the SSLSessionContext instance itself rather than the SSLSession(s) that this context holds. The method level javadocs too don't make a mention that they may not return the session ids or the SSLSession itself if the server/client is configured to be stateless. Also, do you think those system properties can be included in the release notes to explain this change? I'm not familiar with what the criteria is for adding to release notes, but I think adding this detail might help quickly diagnose this change in behaviour. -Jaikiran > > Tony > > > On 6/30/19 10:38 PM, Jaikiran Pai wrote: >> It looks like there has been a change in behaviour in some of the APIs >> exposed by javax.net.ssl.SSLSessionContext, in recent EA versions of >> Java 13 (as well as latest upstream master). Before I proceed with the >> details, I would like to credit Richard Opalka, from WildFly team, as >> the person who originally noticed this due to its impact on WildFly >> project[1]. What I have now done is narrow this down to a jtreg testcase >> which reproduces this issue in a straightforward isolated code[2]. >> >> The issues appear (at least) in the >> SSLSessionContext#getSession(sessionId) and SSLSessionContext#getIds(). >> Both these APIs no longer return the expected output. For example, the >> SSLSessionContext#getSession(sessionId) returns null for a valid session >> id and the SSLSessionContext#getIds() just returns no session ids. >> >> The jtreg testcase in [2] opens a server over SSLSocket and a client >> which just expects a reply from the server. The server when it accepts >> the connection over the SSLSocket, gets hold of the SSLSession id from >> that socket and then goes on to invoke the above APIs to try and get >> hold of this information from the SSLSessionContext. This all works fine >> on Java 8, 11, 12 and some versions of 13 EA, but fails in recent >> versions of 13 as well as upstream master branch. >> >> As Richard points out in [1], it seems related to certain stateless >> session related changes in the JDK, but I don't have enough knowledge in >> that area nor of the changes to understand if this change in behaviour >> is expected or if this is genuinely a bug - hence decided to raise this >> in the mailing list instead of filing a JBS. >> >> [1] https://issues.jboss.org/browse/WFCORE-4532 >> [2] http://cr.openjdk.java.net/~jpai/webrev/sslsessioncontext/0/webrev/ >> >> -Jaikiran >> > From weijun.wang at oracle.com Tue Jul 2 02:51:17 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Jul 2019 10:51:17 +0800 Subject: [13] RFR 8225687: Newly added sspi.cpp in JDK-6722928 still contains some small errors In-Reply-To: <49BB2145-B65F-46CA-90A8-BA55588BD48D@oracle.com> References: <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> <20190529172354.GH7457@twosigma.com> <20190610235635.GL7457@twosigma.com> <49BB2145-B65F-46CA-90A8-BA55588BD48D@oracle.com> Message-ID: <225AF060-AAAC-47B4-BAD8-37BCB22A5D50@oracle.com> "[13]" added to the subject. > On Jul 2, 2019, at 10:22 AM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8225687/webrev.00/ > > Most changes are around const usage in gssapi.h. Note that this is internal so the change could only prevent any coding error and will not be visible outside JDK. > > Other changes are inside gss_import_name(), gss_compare_name(). I also changed some names like get_oid_set_desc -> show_oid_set. > > Thanks, > Max > >> On Jun 13, 2019, at 10:48 AM, Weijun Wang wrote: >> >> I've filed https://bugs.openjdk.java.net/browse/JDK-8225687. >> >>> On Jun 11, 2019, at 7:56 AM, Nico Williams wrote: >>> >>> On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote: >>>> Updated webrev at >>>> >>>> http://cr.openjdk.java.net/~weijun/6722928/webrev.08/ >>> >>> - src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java >>> >>> Ugh, I never noticed GSSUtil.useMSInterop(). This really should not >>> be needed. I believe a proper implementation of RFC4178 wouldn't >>> need it. >> >> I tried but scared away by MS-SPNG's appendix on which version of Windows supports which style of mechListMic. Now that Java only supports one underlying mechanism this field is looks not so crucial. >> >>> >>> I can't expect you to do that, but can we have a bug opened for this? >> >> There was one at https://bugs.openjdk.java.net/browse/JDK-6773898. >> >>> >>> - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java >>> >>> Shouldn't the sspi_bridge.dll be in the lib directory? >> >> The DLLs have always been in /bin. Maybe it's more easily loadable by java.exe. >> >>> >>> - src/java.security.jgss/share/native/libj2gss/NativeFunc.h >>> - src/java.security.jgss/share/native/libj2gss/gssapi.h >>> >>> These continue to have improper constification. >>> >>> There should be no function arguments of type "const gss_...". >>> >>> I've a PR for Heimdal to fix this in Heimdal. It was very >>> mechanical: search the prototypes and function definitions for >>> >>> \>> >>> then change that to gss_const_... then fix all the warnings and >>> errors that came up when building the result. >> >> OK. >> >>> >>> - All remaining commentary will be about >>> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp >>> >>> - CHECK_*() macros >>> >>> Macro bodies should not end in a semi-colon. >> >> OK. >> >>> >>> If these were public and since these macro bodies are all if >>> statements, you should wrap them in do { } while (0), but since >>> they're private we can make sure that all uses are correct. >>> >>> - gss_import_name() doesn't check that the first two bytes of the >>> input buffer are the expected token ID when the name-type is >>> GSS_C_NT_EXPORTED_NAME. >> >> OK. >> >>> >>> - gss_import_name() doesn't check that the third byte of the input >>> buffer is 0 when the name-type is GSS_C_NT_EXPORTED_NAME. >> >> OK. >> >>> >>> - gss_compare_name(), this code will not distinguish a name of the >>> form 'foo@' from 'foo\@' >>> >>> 434 if (l1 < l2 && n2[l1] != L'@' >>> 435 || l2 < l1 && n1[l2] != L'@') { >>> 436 return GSS_S_COMPLETE; // different >>> 437 } >>> >>> Honestly, this is not the most serious problem because nothing >>> really should be using gss_compare_name(), but you do use it... and >>> anyways, it's wrong. >> >> Yes, it's called in GSSLibStub.c and those are the functions I must support. >> >>> >>> Perhaps the gss_name_struct struct should have a length of realm or >>> length-of-not-realm-part field to make this check easier. >>> >>> - gss_compare_name(), do not use NORM_IGNORECASE >> >> But I do notice that "Administrator" can also be named "administrator", and "HTTP/host" can also be "http/host". >> >>> >>> - gss_canonicalize_name() should check that mech_type is Kerberos >> >> OK. >> >>> >>> I'll continue later. I'm in gss_init_sec_context(), about 58% of the >>> way through. >> >> Please. >> >> Thanks, >> Max >> >>> >>> Nico >>> -- >> > From weijun.wang at oracle.com Tue Jul 2 02:58:14 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Jul 2019 10:58:14 +0800 Subject: [13] RFR 8227061: KDC.java test behaves incorrectly when AS-REQ contains a PAData not PA-ENC-TS-ENC Message-ID: <3A9ECC6B-EE6B-41D7-A175-992FF2282DAE@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8227061/webrev.00/ The test now iterates through all incoming PA-DATA and find out PA-ENC-TS-ENC. noteg-self. Thanks, Max From weijun.wang at oracle.com Tue Jul 2 03:13:13 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Jul 2019 11:13:13 +0800 Subject: [13] RFR 8226719: Kerberos login to Windows 2000 failed with "Inappropriate type of checksum in message" References: <6A87B5BE-9DC7-421D-BF37-4F06986F288A@oracle.com> Message-ID: <8C8BBDB2-ED25-4A32-A30F-1C81A097411B@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8226719/webrev.00/ This happens when authenticating to a Windows 2000 Server using DES encryption type. The PA_REQ_ENC_PA_REP in the reply is using RsaMd5CksumType but it is treated unsafe and rejected. Here, unsafe means un-keyed. While it's unsafe to use it as a standalone checksum but in this case the PA_REQ_ENC_PA_REP is embedded inside EncKDCRepPart which is already encrypted. Therefore an attacker will not be able to modify it without knowing the key. (Please note that when a keyed checksum is used, the key is exactly the same as the one used to encrypt the EncKDCRepPart field). This fix added a new method verifyAnyChecksum() that can verify both a keyed and an un-keyed checksum. The method is currently only used by the PA_REQ_ENC_PA_REP verification. Noreg-hard. Only reproducible when accessing a Windows 2000 Server, which is exactly how our internal SQE test caught it. Thanks, Max From jai.forums2013 at gmail.com Tue Jul 2 05:22:02 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 2 Jul 2019 10:52:02 +0530 Subject: [PATCH] JDK-8226976 - SessionTimeOutTests uses == operator for String value check In-Reply-To: References: <2e94b61c-f1d8-f838-ad52-39364c72fd1f@gmail.com> <38fd4989-d507-e54f-ec5c-e596412097f6@oracle.com> Message-ID: <470525ba-84a4-0cfb-80a8-355373c659b6@gmail.com> On 02/07/19 7:35 AM, Jaikiran Pai wrote: > Thank you Xuelei. Here's the updated webrev > http://cr.openjdk.java.net/~jpai/webrev/8226976/01/webrev/. - * Copyright (c) 2001, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2017, 2019 Oracle and/or its affiliates. All rights reserved. I just checked some other files within the JDK and can't seem to find a copyright with more than 2 years listed. So if you meant that I should change it to "...2001, 2019..." then please do let me know and I'll update it accordingly and send the updated webrev. -Jaikiran > Updated the > copyright year and also added you as the reviewer, in the commit log > message. > > -Jaikiran > > On 01/07/19 10:17 PM, Xuelei Fan wrote: >> Hi Jaikiran, >> >> Would you mind update the copyright date to 2019?? Otherwise, looks >> good to me. >> >> Thanks, >> Xuelei >> >> On 6/29/2019 6:03 AM, Jaikiran Pai wrote: >>> While investigating a potential regression in JDK 13+, I happened to use >>> the test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java. This >>> test incorrectly uses the == operator for one of the String checks. I >>> have filed a bug[1] with the details and have a patch with the fix >>> here[2]. >>> >>> Can I please get a review and a sponsor for this change? >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8226976 >>> >>> [2] http://cr.openjdk.java.net/~jpai/webrev/8226976/0/webrev/ >>> >>> -Jaikiran >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Tue Jul 2 05:28:30 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 2 Jul 2019 10:58:30 +0530 Subject: Request for Review [14] JDK-8226976, SessionTimeOutTests uses == operator for String value check In-Reply-To: References: Message-ID: <0cad9af9-f707-e13d-d785-b84b354e1add@gmail.com> Hi Xuelei, Bernd, On 01/07/19 11:31 PM, Xuelei Fan wrote: > On 7/1/2019 10:51 AM, Bernd Eckenfels wrote: >> Also the `is*` prefix would point to a boolean, that?s maybe a >> cleaner data type than a case sensitive string? >> > I agreed.? The "isTimedout" is also used to for strings other than > "YES"/"No".? I don't think it is a good code convention. > ??? isTimedout = "Invalidated before timeout"; > > As Jaikiran had taken care of the issue in a previous thread: > > https://mail.openjdk.java.net/pipermail/security-dev/2019-June/020307.html > > > I will leave it to Jaikiran if we want to make more improvement in > that code review thread. I can take up the cleanup of this testcase as a separate task. I will need to understand the current semantics[1] of some of the APIs being used in this test and how it impacts this test. [1] http://mail.openjdk.java.net/pipermail/security-dev/2019-July/020308.html -Jaikiran > > Thanks, > Xuelei > >> >> --? >> http://bernd.eckenfels.net >> ------------------------------------------------------------------------ >> *Von:* security-dev im >> Auftrag von Xuelei Fan >> *Gesendet:* Montag, Juli 1, 2019 6:44 PM >> *An:* security-dev at openjdk.java.net >> *Betreff:* Request for Review [14] JDK-8226976, SessionTimeOutTests >> uses == operator for String value check >> Hi, >> >> In the following test case, "==" is used to compare two strings. As is >> not a comment coding convention. I would like to use "equals()" method >> instead. >> >> Thanks, >> Xuelei >> >> >> $ hg diff test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java >> diff -r 73f1c84ca264 >> test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java >> --- a/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java >> Thu Jun 27 22:03:19 2019 +0200 >> +++ b/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java >> Mon Jul 01 09:29:23 2019 -0700 >> @@ -283,7 +283,7 @@ >> } >> System.out.print(sess + " " + lifetime); >> if (((timeout == 0) || (lifetime < timeout)) && >> - (isTimedout == "YES")) { >> + isTimedout.equals("YES")) { >> isTimedout = "Invalidated before timeout"; >> } From Xuelei.Fan at Oracle.Com Tue Jul 2 05:33:24 2019 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Mon, 1 Jul 2019 22:33:24 -0700 Subject: [PATCH] JDK-8226976 - SessionTimeOutTests uses == operator for String value check In-Reply-To: <470525ba-84a4-0cfb-80a8-355373c659b6@gmail.com> References: <2e94b61c-f1d8-f838-ad52-39364c72fd1f@gmail.com> <38fd4989-d507-e54f-ec5c-e596412097f6@oracle.com> <470525ba-84a4-0cfb-80a8-355373c659b6@gmail.com> Message-ID: The copyright date format is similar to ?.. 2001, 2019, ..?. Xuelei > On Jul 1, 2019, at 10:22 PM, Jaikiran Pai wrote: > > >> On 02/07/19 7:35 AM, Jaikiran Pai wrote: >> Thank you Xuelei. Here's the updated webrev >> http://cr.openjdk.java.net/~jpai/webrev/8226976/01/webrev/. > - * Copyright (c) 2001, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2017, 2019 Oracle and/or its affiliates. All rights reserved. > I just checked some other files within the JDK and can't seem to find a copyright with more than 2 years listed. So if you meant that I should change it to "...2001, 2019..." then please do let me know and I'll update it accordingly and send the updated webrev. > > -Jaikiran > > > >> Updated the >> copyright year and also added you as the reviewer, in the commit log >> message. >> >> -Jaikiran >> >> On 01/07/19 10:17 PM, Xuelei Fan wrote: >>> Hi Jaikiran, >>> >>> Would you mind update the copyright date to 2019? Otherwise, looks >>> good to me. >>> >>> Thanks, >>> Xuelei >>> >>> On 6/29/2019 6:03 AM, Jaikiran Pai wrote: >>>> While investigating a potential regression in JDK 13+, I happened to use >>>> the test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java. This >>>> test incorrectly uses the == operator for one of the String checks. I >>>> have filed a bug[1] with the details and have a patch with the fix >>>> here[2]. >>>> >>>> Can I please get a review and a sponsor for this change? >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8226976 >>>> >>>> [2] http://cr.openjdk.java.net/~jpai/webrev/8226976/0/webrev/ >>>> >>>> -Jaikiran >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Xuelei.Fan at Oracle.Com Tue Jul 2 05:35:02 2019 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Mon, 1 Jul 2019 22:35:02 -0700 Subject: Request for Review [14] JDK-8226976, SessionTimeOutTests uses == operator for String value check In-Reply-To: <0cad9af9-f707-e13d-d785-b84b354e1add@gmail.com> References: <0cad9af9-f707-e13d-d785-b84b354e1add@gmail.com> Message-ID: <9094792D-5724-4AAA-8E83-13AA646BD204@Oracle.Com> > On Jul 1, 2019, at 10:28 PM, Jaikiran Pai wrote: > > Hi Xuelei, Bernd, > >> On 01/07/19 11:31 PM, Xuelei Fan wrote: >>> On 7/1/2019 10:51 AM, Bernd Eckenfels wrote: >>> Also the `is*` prefix would point to a boolean, that?s maybe a >>> cleaner data type than a case sensitive string? >>> >> I agreed. The "isTimedout" is also used to for strings other than >> "YES"/"No". I don't think it is a good code convention. >> isTimedout = "Invalidated before timeout"; >> >> As Jaikiran had taken care of the issue in a previous thread: >> >> https://mail.openjdk.java.net/pipermail/security-dev/2019-June/020307.html >> >> >> I will leave it to Jaikiran if we want to make more improvement in >> that code review thread. > > I can take up the cleanup of this testcase as a separate task. I will > need to understand the current semantics[1] of some of the APIs being > used in this test and how it impacts this test. > It makes sense to me. Thanks for taking care of the update. Xuelei > [1] > http://mail.openjdk.java.net/pipermail/security-dev/2019-July/020308.html > > -Jaikiran > > >> >> Thanks, >> Xuelei >> >>> >>> -- >>> http://bernd.eckenfels.net >>> ------------------------------------------------------------------------ >>> *Von:* security-dev im >>> Auftrag von Xuelei Fan >>> *Gesendet:* Montag, Juli 1, 2019 6:44 PM >>> *An:* security-dev at openjdk.java.net >>> *Betreff:* Request for Review [14] JDK-8226976, SessionTimeOutTests >>> uses == operator for String value check >>> Hi, >>> >>> In the following test case, "==" is used to compare two strings. As is >>> not a comment coding convention. I would like to use "equals()" method >>> instead. >>> >>> Thanks, >>> Xuelei >>> >>> >>> $ hg diff test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java >>> diff -r 73f1c84ca264 >>> test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java >>> --- a/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java >>> Thu Jun 27 22:03:19 2019 +0200 >>> +++ b/test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java >>> Mon Jul 01 09:29:23 2019 -0700 >>> @@ -283,7 +283,7 @@ >>> } >>> System.out.print(sess + " " + lifetime); >>> if (((timeout == 0) || (lifetime < timeout)) && >>> - (isTimedout == "YES")) { >>> + isTimedout.equals("YES")) { >>> isTimedout = "Invalidated before timeout"; >>> } From jai.forums2013 at gmail.com Tue Jul 2 05:43:35 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Tue, 2 Jul 2019 11:13:35 +0530 Subject: [PATCH] JDK-8226976 - SessionTimeOutTests uses == operator for String value check In-Reply-To: References: <2e94b61c-f1d8-f838-ad52-39364c72fd1f@gmail.com> <38fd4989-d507-e54f-ec5c-e596412097f6@oracle.com> <470525ba-84a4-0cfb-80a8-355373c659b6@gmail.com> Message-ID: <32ecf2e3-ee48-84e2-aab6-542e566718cc@gmail.com> Done. Here's the updated webrev http://cr.openjdk.java.net/~jpai/webrev/8226976/02/webrev/ -Jaikiran On 02/07/19 11:03 AM, Xuelei Fan wrote: > The copyright date format is similar to ?.. 2001, 2019, ..?. > > Xuelei > > On Jul 1, 2019, at 10:22 PM, Jaikiran Pai > wrote: > >> >> On 02/07/19 7:35 AM, Jaikiran Pai wrote: >>> Thank you Xuelei. Here's the updated webrev >>> http://cr.openjdk.java.net/~jpai/webrev/8226976/01/webrev/. >> - * Copyright (c) 2001, 2017, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2001, 2017, 2019 Oracle and/or its affiliates. All rights reserved. >> >> I just checked some other files within the JDK and can't seem to find >> a copyright with more than 2 years listed. So if you meant that I >> should change it to "...2001, 2019..." then please do let me know and >> I'll update it accordingly and send the updated webrev. >> >> -Jaikiran >> >> >>> Updated the >>> copyright year and also added you as the reviewer, in the commit log >>> message. >>> >>> -Jaikiran >>> >>> On 01/07/19 10:17 PM, Xuelei Fan wrote: >>>> Hi Jaikiran, >>>> >>>> Would you mind update the copyright date to 2019?? Otherwise, looks >>>> good to me. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 6/29/2019 6:03 AM, Jaikiran Pai wrote: >>>>> While investigating a potential regression in JDK 13+, I happened to use >>>>> the test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java. This >>>>> test incorrectly uses the == operator for one of the String checks. I >>>>> have filed a bug[1] with the details and have a patch with the fix >>>>> here[2]. >>>>> >>>>> Can I please get a review and a sponsor for this change? >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8226976 >>>>> >>>>> [2] http://cr.openjdk.java.net/~jpai/webrev/8226976/0/webrev/ >>>>> >>>>> -Jaikiran >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Tue Jul 2 14:30:20 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 2 Jul 2019 07:30:20 -0700 Subject: Change in behaviour of SSLSessionContext APIs in recent Java 13 EA versions In-Reply-To: References: <86a1f866-bd36-6b43-d02c-551364b8295c@gmail.com> <2e4163e9-8630-9d36-39c1-e44b714baabb@oracle.com> Message-ID: <9250edff-78bf-3753-e93b-f7039ea583ca@oracle.com> On 7/1/19 7:23 PM, Jaikiran Pai wrote: > Hello Tony, > > On 01/07/19 10:28 PM, Anthony Scarpino wrote: >> Hi, >> >> You are correct this behavior is a result of stateless resumption. >> The stateless servers does not keep session state information and is >> currently opt-out. > > Thank you for looking into this and providing the details. > > >> The system property 'jdk.tls.server.enableSessionTicketExtension' set >> to false will return the server to stateful.? The client side has a >> property also 'jdk.tls.client.enableSessionTicketExtension'. >> >> So in the case of using getSession() and getIds(), stateless >> resumption is one of the environments that session information is not >> available. > > Do you think the class-level as well as these method level javadoc of > the SSLSessionContext would need an update then? Right now the > class-level javadoc states: > > > > There are SSLSessionContext parameters that affect how > ?* sessions are stored: > ?*
    > ?*?????
  • Sessions can be set to expire after a specified > ?*????? time limit. > ?*?????
  • The number of sessions that can be stored in context > ?*????? can be limited. > ?*
> ?* A session can be retrieved based on its session id, and all session id's > ?* in a SSLSessionContext can be listed. > > There's a mention about: > > "Not all environments will contain session contexts." > > but I take it as meaning that, not all environments will have the > SSLSessionContext instance itself rather than the SSLSession(s) that > this context holds. > > The method level javadocs too don't make a mention that they may not > return the session ids or the SSLSession itself if the server/client is > configured to be stateless. There are some javadoc changes, but maybe more will be needed. > > Also, do you think those system properties can be included in the > release notes to explain this change? I'm not familiar with what the > criteria is for adding to release notes, but I think adding this detail > might help quickly diagnose this change in behaviour. The stateless feature will be in the release notes. Tony > > -Jaikiran > >> >> Tony >> >> >> On 6/30/19 10:38 PM, Jaikiran Pai wrote: >>> It looks like there has been a change in behaviour in some of the APIs >>> exposed by javax.net.ssl.SSLSessionContext, in recent EA versions of >>> Java 13 (as well as latest upstream master). Before I proceed with the >>> details, I would like to credit Richard Opalka, from WildFly team, as >>> the person who originally noticed this due to its impact on WildFly >>> project[1]. What I have now done is narrow this down to a jtreg testcase >>> which reproduces this issue in a straightforward isolated code[2]. >>> >>> The issues appear (at least) in the >>> SSLSessionContext#getSession(sessionId) and SSLSessionContext#getIds(). >>> Both these APIs no longer return the expected output. For example, the >>> SSLSessionContext#getSession(sessionId) returns null for a valid session >>> id and the SSLSessionContext#getIds() just returns no session ids. >>> >>> The jtreg testcase in [2] opens a server over SSLSocket and a client >>> which just expects a reply from the server. The server when it accepts >>> the connection over the SSLSocket, gets hold of the SSLSession id from >>> that socket and then goes on to invoke the above APIs to try and get >>> hold of this information from the SSLSessionContext. This all works fine >>> on Java 8, 11, 12 and some versions of 13 EA, but fails in recent >>> versions of 13 as well as upstream master branch. >>> >>> As Richard points out in [1], it seems related to certain stateless >>> session related changes in the JDK, but I don't have enough knowledge in >>> that area nor of the changes to understand if this change in behaviour >>> is expected or if this is genuinely a bug - hence decided to raise this >>> in the mailing list instead of filing a JBS. >>> >>> [1] https://issues.jboss.org/browse/WFCORE-4532 >>> [2] http://cr.openjdk.java.net/~jpai/webrev/sslsessioncontext/0/webrev/ >>> >>> -Jaikiran >>> >> > From weijun.wang at oracle.com Tue Jul 2 15:04:01 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Jul 2019 23:04:01 +0800 Subject: [13] RFR 8227059: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timed out Message-ID: <09DC313A-F894-4BDB-AE40-1BB50E6D49D4@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8227059/webrev.00/ A fake DSA key pair generator with hardcoded keys. I haven't modified EC since it's quite fast. Thanks, Max From anthony.scarpino at oracle.com Tue Jul 2 17:35:33 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 2 Jul 2019 10:35:33 -0700 Subject: RFR 8226338: Updates to Stateless Resumption Message-ID: <8d314691-0ca5-307e-41a1-e6ba731abacb@oracle.com> Hi, I need a code review on some updates to the stateless resumption. 1) Changing peerSupportedSignAlgs from a String[] to Collection[] 2) Additional items added to the stateless ticket 3) Not provide a stateless ticket when the masterkey is not accessible (FIPS) or when boundValues are used 4) Be more graceful in case of stateless ticket generation failure http://cr.openjdk.java.net/~ascarpino/8226338/webrev.00/ Tony From anthony.scarpino at oracle.com Tue Jul 2 21:43:35 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 2 Jul 2019 14:43:35 -0700 Subject: RFR[13] Release Note for Stateless Resumption Message-ID: Hi, I needs a release note review of the Stateless Resumption work https://bugs.openjdk.java.net/browse/JDK-8227105 thanks Tony From weijun.wang at oracle.com Wed Jul 3 01:34:48 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jul 2019 09:34:48 +0800 Subject: [13] RFR 8226719: Kerberos login to Windows 2000 failed with "Inappropriate type of checksum in message" In-Reply-To: <8C8BBDB2-ED25-4A32-A30F-1C81A097411B@oracle.com> References: <6A87B5BE-9DC7-421D-BF37-4F06986F288A@oracle.com> <8C8BBDB2-ED25-4A32-A30F-1C81A097411B@oracle.com> Message-ID: More justification from https://tools.ietf.org/html/rfc3961#section-6.1: 6.1. Unkeyed Checksums These checksum types use no encryption keys and thus can be used in combination with any encryption type, but they may only be used with caution, in limited circumstances where the lack of a key does not provide a window for an attack, preferably as part of an encrypted message [6]. Keyed checksum algorithms are recommended. Here the PA_REQ_ENC_PA_REP is a part of an encrypted message EncKDCRepPart. Thanks, Max > On Jul 2, 2019, at 11:13 AM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8226719/webrev.00/ > > This happens when authenticating to a Windows 2000 Server using DES encryption type. The PA_REQ_ENC_PA_REP in the reply is using RsaMd5CksumType but it is treated unsafe and rejected. > > Here, unsafe means un-keyed. While it's unsafe to use it as a standalone checksum but in this case the PA_REQ_ENC_PA_REP is embedded inside EncKDCRepPart which is already encrypted. Therefore an attacker will not be able to modify it without knowing the key. (Please note that when a keyed checksum is used, the key is exactly the same as the one used to encrypt the EncKDCRepPart field). > > This fix added a new method verifyAnyChecksum() that can verify both a keyed and an un-keyed checksum. The method is currently only used by the PA_REQ_ENC_PA_REP verification. > > Noreg-hard. Only reproducible when accessing a Windows 2000 Server, which is exactly how our internal SQE test caught it. > > Thanks, > Max > > > From weijun.wang at oracle.com Wed Jul 3 02:20:46 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jul 2019 10:20:46 +0800 Subject: [13] RFR 8227059: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timed out In-Reply-To: <09DC313A-F894-4BDB-AE40-1BB50E6D49D4@oracle.com> References: <09DC313A-F894-4BDB-AE40-1BB50E6D49D4@oracle.com> Message-ID: Updated at https://cr.openjdk.java.net/~weijun/8227059/webrev.01. EC added. --Max > On Jul 2, 2019, at 11:04 PM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8227059/webrev.00/ > > A fake DSA key pair generator with hardcoded keys. I haven't modified EC since it's quite fast. > > Thanks, > Max > From valerie.peng at oracle.com Wed Jul 3 02:48:11 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 2 Jul 2019 19:48:11 -0700 Subject: RFR[13] JDK-8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support Message-ID: <63fa1e24-f926-19a2-1eea-045a0843ff9d@oracle.com> Hi Any one can help reviewing this fix? Some ECDSA certificates contains signature algorithm identifiers with non-null parameter bytes. Before RSASSA-PSS support, these parameter bytes are ignored, however, after RSASSA-PSS support, the parameter bytes are passed to the underlying signature impl and this breaks the ECDSA certificate verification. In order for the verification to succeeds, the SignatureUtil class needs to be able to parse the parameter bytes for ECDSA certificate and that SunEC provider needs to accept non-null signature parameters. Bug: https://bugs.openjdk.java.net/browse/JDK-8225745 Webrev: http://cr.openjdk.java.net/~valeriep/8225745/webrev.00/ Mach5 run is clean. Thanks, Valerie From weijun.wang at oracle.com Wed Jul 3 03:27:45 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jul 2019 11:27:45 +0800 Subject: RFR[13] JDK-8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support In-Reply-To: <63fa1e24-f926-19a2-1eea-045a0843ff9d@oracle.com> References: <63fa1e24-f926-19a2-1eea-045a0843ff9d@oracle.com> Message-ID: <761FA3AA-164F-4CC7-94CC-0EED8B6EC350@oracle.com> 368 private static boolean isCompatible(ECParameterSpec sigParams, 369 ECParameterSpec keyParams) { 370 if (sigParams == null) { 371 // no restriction on key param 372 return true; 373 } 374 return sigParams.equals(keyParams); 375 } What does "sigParams.equals(keyParams)" mean here? What is the getClass() of those 2 ECParameterSpec objects? Or maybe you mean "==" because it is always a NamedCurve stored in CurveDB? Thanks, Max > On Jul 3, 2019, at 10:48 AM, Valerie Peng wrote: > > Hi > > Any one can help reviewing this fix? Some ECDSA certificates contains signature algorithm identifiers with non-null parameter bytes. Before RSASSA-PSS support, these parameter bytes are ignored, however, after RSASSA-PSS support, the parameter bytes are passed to the underlying signature impl and this breaks the ECDSA certificate verification. In order for the verification to succeeds, the SignatureUtil class needs to be able to parse the parameter bytes for ECDSA certificate and that SunEC provider needs to accept non-null signature parameters. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225745 > Webrev: http://cr.openjdk.java.net/~valeriep/8225745/webrev.00/ > > Mach5 run is clean. > > Thanks, > Valerie From xuelei.fan at oracle.com Wed Jul 3 03:28:22 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 2 Jul 2019 20:28:22 -0700 Subject: [13] RFR 8226719: Kerberos login to Windows 2000 failed with "Inappropriate type of checksum in message" In-Reply-To: References: <6A87B5BE-9DC7-421D-BF37-4F06986F288A@oracle.com> <8C8BBDB2-ED25-4A32-A30F-1C81A097411B@oracle.com> Message-ID: <62b8f342-0d31-74b2-2f55-529a91c749a9@oracle.com> To make it clearer, I would like to have a brief comment about the unkeyed checksum checking as you cited of section 6.1 of RFC 3961, probably in Checksum.verifyAnyChecksum() or/and CksumType.verifyChecksum(). Checksum.verifyAnyChecksum(): 191 if (!cksumEngine.isSafe()) 192 throw new KrbApErrException(Krb5.KRB_AP_ERR_INAPP_CKSUM); 204 if (!cksumEngine.isSafe()) { 205 return cksumEngine.verifyChecksum(data, checksum); CksumType.java: 159 public boolean verifyChecksum(byte[] data, byte[] checksum) 160 throws KrbCryptoException { 161 throw new UnsupportedOperationException("Not supported"); 162 } I was wondering, if a CksumType object is not safe (!isSafe()) and does not implement the verifyChecksum() method, an USPOE will be thrown. For example, I'm not sure if Crc32CksumType.verifyChecksum() could be called or not in practice. Is it better to have CksumType.verifyChecksum() returns 'false'? Otherwise, looks good to me. Need no more code review from me if you have a good reason to keep it as-is, or take the comments above. Xuelei On 7/2/2019 6:34 PM, Weijun Wang wrote: > More justification from https://tools.ietf.org/html/rfc3961#section-6.1: > > 6.1. Unkeyed Checksums > > These checksum types use no encryption keys and thus can be used in > combination with any encryption type, but they may only be used with > caution, in limited circumstances where the lack of a key does not > provide a window for an attack, preferably as part of an encrypted > message [6]. Keyed checksum algorithms are recommended. > > Here the PA_REQ_ENC_PA_REP is a part of an encrypted message EncKDCRepPart. > > Thanks, > Max > > > >> On Jul 2, 2019, at 11:13 AM, Weijun Wang wrote: >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8226719/webrev.00/ >> >> This happens when authenticating to a Windows 2000 Server using DES encryption type. The PA_REQ_ENC_PA_REP in the reply is using RsaMd5CksumType but it is treated unsafe and rejected. >> >> Here, unsafe means un-keyed. While it's unsafe to use it as a standalone checksum but in this case the PA_REQ_ENC_PA_REP is embedded inside EncKDCRepPart which is already encrypted. Therefore an attacker will not be able to modify it without knowing the key. (Please note that when a keyed checksum is used, the key is exactly the same as the one used to encrypt the EncKDCRepPart field). >> >> This fix added a new method verifyAnyChecksum() that can verify both a keyed and an un-keyed checksum. The method is currently only used by the PA_REQ_ENC_PA_REP verification. >> >> Noreg-hard. Only reproducible when accessing a Windows 2000 Server, which is exactly how our internal SQE test caught it. >> >> Thanks, >> Max >> >> >> > From weijun.wang at oracle.com Wed Jul 3 03:36:50 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jul 2019 11:36:50 +0800 Subject: [13] RFR 8226719: Kerberos login to Windows 2000 failed with "Inappropriate type of checksum in message" In-Reply-To: <62b8f342-0d31-74b2-2f55-529a91c749a9@oracle.com> References: <6A87B5BE-9DC7-421D-BF37-4F06986F288A@oracle.com> <8C8BBDB2-ED25-4A32-A30F-1C81A097411B@oracle.com> <62b8f342-0d31-74b2-2f55-529a91c749a9@oracle.com> Message-ID: <0AEC8D4C-8728-47B4-BFA6-25516568959A@oracle.com> > On Jul 3, 2019, at 11:28 AM, Xuelei Fan wrote: > > To make it clearer, I would like to have a brief comment about the unkeyed checksum checking as you cited of section 6.1 of RFC 3961, probably in Checksum.verifyAnyChecksum() or/and CksumType.verifyChecksum(). > > Checksum.verifyAnyChecksum(): > 191 if (!cksumEngine.isSafe()) > 192 throw new KrbApErrException(Krb5.KRB_AP_ERR_INAPP_CKSUM); > > 204 if (!cksumEngine.isSafe()) { > 205 return cksumEngine.verifyChecksum(data, checksum); > > CksumType.java: > 159 public boolean verifyChecksum(byte[] data, byte[] checksum) > 160 throws KrbCryptoException { > 161 throw new UnsupportedOperationException("Not supported"); > 162 } OK, I'll add some. > > I was wondering, if a CksumType object is not safe (!isSafe()) and does not implement the verifyChecksum() method, an USPOE will be thrown. For example, I'm not sure if Crc32CksumType.verifyChecksum() could be called or not in practice. Is it better to have CksumType.verifyChecksum() returns 'false'? Maybe not. In KrbKdcRep::check when an exception is thrown there will be something written to debug output, but if it's false, nothing shows. In fact, before this fix the RsaMd5CksumType::verifyKeyedChecksum was called and it always returns false. I spent some time debugging and found out the reason. The USPOE would be more loudly and friendly for supporting. > > Otherwise, looks good to me. Need no more code review from me if you have a good reason to keep it as-is, or take the comments above. Thanks, Max > > Xuelei > > On 7/2/2019 6:34 PM, Weijun Wang wrote: >> More justification from https://tools.ietf.org/html/rfc3961#section-6.1: >> 6.1. Unkeyed Checksums >> These checksum types use no encryption keys and thus can be used in >> combination with any encryption type, but they may only be used with >> caution, in limited circumstances where the lack of a key does not >> provide a window for an attack, preferably as part of an encrypted >> message [6]. Keyed checksum algorithms are recommended. >> Here the PA_REQ_ENC_PA_REP is a part of an encrypted message EncKDCRepPart. >> Thanks, >> Max >>> On Jul 2, 2019, at 11:13 AM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8226719/webrev.00/ >>> >>> This happens when authenticating to a Windows 2000 Server using DES encryption type. The PA_REQ_ENC_PA_REP in the reply is using RsaMd5CksumType but it is treated unsafe and rejected. >>> >>> Here, unsafe means un-keyed. While it's unsafe to use it as a standalone checksum but in this case the PA_REQ_ENC_PA_REP is embedded inside EncKDCRepPart which is already encrypted. Therefore an attacker will not be able to modify it without knowing the key. (Please note that when a keyed checksum is used, the key is exactly the same as the one used to encrypt the EncKDCRepPart field). >>> >>> This fix added a new method verifyAnyChecksum() that can verify both a keyed and an un-keyed checksum. The method is currently only used by the PA_REQ_ENC_PA_REP verification. >>> >>> Noreg-hard. Only reproducible when accessing a Windows 2000 Server, which is exactly how our internal SQE test caught it. >>> >>> Thanks, >>> Max >>> >>> >>> From philipp.kunz at paratix.ch Wed Jul 3 08:06:54 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Wed, 03 Jul 2019 10:06:54 +0200 Subject: RFR 8217375: jarsigner breaks old signature with long lines in manifest In-Reply-To: <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> Message-ID: <1562141214.2441.54.camel@paratix.ch> Hi Max, Do I understand correctly that your question refers to ????????if (e == null && MF_MAIN_ATTRS.equals(name)) { ????????????e = getMainAttsEntry(); ????????} ? If so, because this sticks closest to the previous behavior. According to src/java.base/share/classes/module-info.java, ManifestDigester is not publicly exported but how can it then be used then in JarVerifier in java.util.jar? If you or someone can confirm that we can identify all callers, I'd prefer to remove above three lines of code. Otherwise, with above three lines, main attributes and an entry with name MF_MAIN_ATTRS will still be confused for all those code continuing to call get as before the patch if an entry with such a name exists just like before. However, with the patch, all (known) places that call ManifestDigester.get* are lines 539 and 606 in SignatureFileVerifier with the patch, 539 calling getMainAttsEntry without any ambiguity and 606 calling get(String, b) always expecting the entry for a section that is present and would otherwise not be known to pass as an argument anyway, provided the signature file does not contain more entries than the manifest or entries have not been removed from the manifest after signing, should work correctly, I guess. If we cannot get rid of those three lines, another test for those edge cases should probably be added, shouldn't it, if not to support the previous confusion at least to show it now works as expected? What exactly did you mean with "coding error"? Along with removing above three lines of code, two tests would have to be adjusted. FindHeaderEndVsManifestDigesterFindFirstSection on lne 235 and DigestInput on line 270. Regards, Philipp On Mon, 2019-07-01 at 15:41 +0800, Weijun Wang wrote: > https://cr.openjdk.java.net/~weijun/8217375/webrev.02 uploaded. There are still several trailing spaces and I've removed them. > > I just ran a test job: SignTwice.java failed on Windows with `failed to clean up files after test`. Most likely a file is not closed. > > The src change looks good. In fact, I am wondering if we need to support ManifestDigester.get(MF_MAIN_ATTRS, b) at all. Is it possible we miss a coding error because of it? > > I'll take a look at the tests. > > Thanks, > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Jul 3 10:27:18 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jul 2019 18:27:18 +0800 Subject: RFR 8217375: jarsigner breaks old signature with long lines in manifest In-Reply-To: <1562141214.2441.54.camel@paratix.ch> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> Message-ID: <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> > On Jul 3, 2019, at 4:06 PM, Philipp Kunz wrote: > > Hi Max, > > Do I understand correctly that your question refers to > if (e == null && MF_MAIN_ATTRS.equals(name)) { > e = getMainAttsEntry(); > } > ? Yes. > > If so, because this sticks closest to the previous behavior. According to src/java.base/share/classes/module-info.java, ManifestDigester is not publicly exported but how can it then be used then in JarVerifier in java.util.jar? If you or someone can confirm that we can identify all callers, I'd prefer to remove above three lines of code. It's not publicly exported therefore cannot be used by an application, but it's accessible by java.util.jar which is also in the java.base module. It can also be accessed by JDK modules listed in the "exports sun.security.util to" block of java.base/share/classes/module-info.java. Anyway any caller must be inside JDK. IntelliJ IDEA tells me its only SignatureFileVerifier and JarSigner. Hopefully whatever IDE you are using it gives the same result. > > Otherwise, with above three lines, main attributes and an entry with name MF_MAIN_ATTRS will still be confused for all those code continuing to call get as before the patch if an entry with such a name exists just like before. However, with the patch, all (known) places that call ManifestDigester.get* are lines 539 and 606 in SignatureFileVerifier with the patch, 539 calling getMainAttsEntry without any ambiguity and 606 calling get(String, b) always expecting the entry for a section that is present and would otherwise not be known to pass as an argument anyway, provided the signature file does not contain more entries than the manifest or entries have not been removed from the manifest after signing, should work correctly, I guess. If we cannot get rid of those three lines, another test for those edge cases should probably be added, shouldn't it, if not to support the previous confusion at least to show it now works as expected? > > What exactly did you mean with "coding error"? Not sure. I don't know if any bad thing would happen if a file named "Manifest-Main-Attributes" is out inside a jar file. > > Along with removing above three lines of code, two tests would have to be adjusted. FindHeaderEndVsManifestDigesterFindFirstSection on lne 235 and DigestInput on line 270. That's OK. No real app should call methods in this class directly. Thanks, Max > > Regards, > Philipp > > > > > > > On Mon, 2019-07-01 at 15:41 +0800, Weijun Wang wrote: >> https://cr.openjdk.java.net/~weijun/8217375/webrev.02 >> uploaded. There are still several trailing spaces and I've removed them. >> >> I just ran a test job: SignTwice.java failed on Windows with `failed to clean up files after test`. Most likely a file is not closed. >> >> The src change looks good. In fact, I am wondering if we need to support ManifestDigester.get(MF_MAIN_ATTRS, b) at all. Is it possible we miss a coding error because of it? >> >> I'll take a look at the tests. >> >> Thanks, >> Max >> >> From sean.mullan at oracle.com Wed Jul 3 18:50:37 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 3 Jul 2019 14:50:37 -0400 Subject: [13] RFR 8226963: More clarification on possible sequencing error in GSSContext::unwrap In-Reply-To: <78A97AA1-517A-4B2F-9A94-26DA6464BFE6@oracle.com> References: <78A97AA1-517A-4B2F-9A94-26DA6464BFE6@oracle.com> Message-ID: Looks fine. --Sean On 6/28/19 8:13 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8226963/webrev.00/ > > Looks like some users are not aware of the MessageProp parameter in unwrap and forget to check about it. This fix adds some code in the example of the GSSContext class spec. > > Thanks, > Max > From sean.mullan at oracle.com Wed Jul 3 19:17:22 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 3 Jul 2019 15:17:22 -0400 Subject: [13] RFR 8227061: KDC.java test behaves incorrectly when AS-REQ contains a PAData not PA-ENC-TS-ENC In-Reply-To: <3A9ECC6B-EE6B-41D7-A175-992FF2282DAE@oracle.com> References: <3A9ECC6B-EE6B-41D7-A175-992FF2282DAE@oracle.com> Message-ID: <11aa2f6c-daa7-2056-4a5a-4124883627a3@oracle.com> Looks fine to me. --Sean On 7/1/19 10:58 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8227061/webrev.00/ > > The test now iterates through all incoming PA-DATA and find out PA-ENC-TS-ENC. > > noteg-self. > > Thanks, > Max > From christoph.langer at sap.com Thu Jul 4 13:11:17 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 4 Jul 2019 13:11:17 +0000 Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange Message-ID: Hi, please help reviewing the backport of JDK-8216039 to jdk11u-dev. Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates, some manual work is necessary. In src/java.base/share/classes/java/security/Signature.java and src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports of jdk.internal.access have to be changed into jdk.internal.misc. The update that originally went to src/java.base/share/classes/jdk/internal/access/SharedSecrets.java obviously needs to be applied to src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new file src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java needs to be src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java in 11u. See the full webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/ The webrev for manual changes only: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/ Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039 Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Jul 5 05:14:00 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 4 Jul 2019 22:14:00 -0700 Subject: RFR 8226338: Updates to Stateless Resumption In-Reply-To: <8d314691-0ca5-307e-41a1-e6ba731abacb@oracle.com> References: <8d314691-0ca5-307e-41a1-e6ba731abacb@oracle.com> Message-ID: <3f693817-9d34-f237-61e3-c73da0daedd9@oracle.com> SSLSessionImpl.java ------------------- 526 boolean checkSessionTicket(HandshakeContext hc) { As the return value is a boolean type, the method is better to use "isSomething". Otherwise, the meaning of the code "!checkSessionTicket()" is clear and need to read the implementation code. NewSessionTicket.java --------------------- 104 // opaque ticket<1..2^16-1>; 108 if (m.remaining() < 6) { Per sectio 3.3, RFC 5077, line 104 should be: opaque ticket<0..2^16-1>; To be better understand the number 6, as you are already there, would you please update line 104 as well? I did not get the idea of the update of T13NewSessionTicketMessage.T13NewSessionTicketMessage(). It looks like that the updated code does not comply to TLS 1.3 specification of NewSessionTicket. 453 NewSessionTicketMessage nstm; 454 nstm = new T12NewSessionTicketMessage(shc, sessionTimeoutSeconds, Maybe better to use one statement. 453 NewSessionTicketMessage nstm = 454 new T12NewSessionTicketMessage(shc, sessionTimeoutSeconds, 499 if (nstm.ticket.length == 0) { Empty ticket should be not allowed in TLS 1.3. ServerHelloDone.java -------------------- 110 if (shc.statelessResumption) { 111 shc.handshakeConsumers.put(SSLHandshake.NEW_SESSION_TICKET.id, 112 SSLHandshake.NEW_SESSION_TICKET); 113 } I think the NewSessionTicket is produced by server and consumed in client side. I did not get the idea to have NST consumer in server side. Am I missing something? SessionTicketExtension.java --------------------------- 260 if (!hc.handshakeSession.checkSessionTicket(hc)) { 261 return new byte[0]; 262 } From the above line, I guess why you use empty ticket for TLS 1.3, although empty ticket is not allowed in TLS 1.3. I may suggest never use empty ticket. Always use a proper ticket in a proper NewSessionTicket message, at least in format. When there is a problem to retrieve the values, cache the session and prefer to use the case rather than the ticket for session resumption. As may be a little bit more interop friendly. 295 if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { 296 SSLLogger.fine("Encryption failed." + e.getMessage()); 297 e.printStackTrace(); // Helps with session.write() 298 } Line 297 does not use SSLLogger. It could be: SSLLogger.fine("Encryption failed", e); On 7/2/2019 10:35 AM, Anthony Scarpino wrote: > > Hi, > > I need a code review on some updates to the stateless resumption. > 1) Changing peerSupportedSignAlgs from a String[] to Collection[] > 2) Additional items added to the stateless ticket > 3) Not provide a stateless ticket when the masterkey is not accessible > (FIPS) or when boundValues are used I did not whether the update works if bound values are set after the handshake completed (i.e., after the NewSessionTicket has been produced and used). Did you have a test for the case? Thanks, Xuelei > 4) Be more graceful in case of stateless ticket generation failure > > http://cr.openjdk.java.net/~ascarpino/8226338/webrev.00/ > > Tony From weijun.wang at oracle.com Fri Jul 5 09:03:28 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 5 Jul 2019 17:03:28 +0800 Subject: RFR 8227305: Krb5Util::getTicketFromSubjectAndTgs is useless Message-ID: Please review this patch for https://bugs.openjdk.java.net/browse/JDK-8227305: diff --git a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java --- a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java +++ b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -58,82 +58,6 @@ } /** - * Retrieve the service ticket for serverPrincipal from caller's Subject - * or from Subject obtained by logging in, or if not found, via the - * Ticket Granting Service using the TGT obtained from the Subject. - * - * Caller must have permission to: - * - access and update Subject's private credentials - * - create LoginContext - * - read the auth.login.defaultCallbackHandler security property - * - * NOTE: This method is used by JSSE Kerberos Cipher Suites - */ - public static KerberosTicket getTicketFromSubjectAndTgs(GSSCaller caller, - String clientPrincipal, String serverPrincipal, String tgsPrincipal, - AccessControlContext acc) - throws LoginException, KrbException, IOException { - .... // skipped - return ticket; - } - - /** * Retrieves the ticket corresponding to the client/server principal * pair from the Subject in the specified AccessControlContext. * If the ticket can not be found in the Subject, and if Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Jul 5 15:25:06 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 5 Jul 2019 08:25:06 -0700 Subject: RFR 8227305: Krb5Util::getTicketFromSubjectAndTgs is useless In-Reply-To: References: Message-ID: Looks good to me. Xuelei On 7/5/2019 2:03 AM, Weijun Wang wrote: > Please review this patch for > https://bugs.openjdk.java.net/browse/JDK-8227305: > > *diff --git > a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java > b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java* > *--- > a/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java* > *+++ > b/src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java* > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -58,82 +58,6 @@ > ?? ? } > > > ?? ? /** > - ? ? * Retrieve the service ticket for serverPrincipal from caller's > Subject > - ? ? * or from Subject obtained by logging in, or if not found, via the > - ? ? * Ticket Granting Service using the TGT obtained from the Subject. > - ? ? * > - ? ? * Caller must have permission to: > - ? ? *? ? - access and update Subject's private credentials > - ? ? *? ? - create LoginContext > - ? ? *? ? - read the auth.login.defaultCallbackHandler security property > - ? ? * > - ? ? * NOTE: This method is used by JSSE Kerberos Cipher Suites > - ? ? */ > -? ? public static KerberosTicket getTicketFromSubjectAndTgs(GSSCaller > caller, > -? ? ? ? String clientPrincipal, String serverPrincipal, String > tgsPrincipal, > -? ? ? ? AccessControlContext acc) > -? ? ? ? throws LoginException, KrbException, IOException { > - > ? ? ? ? ?.... // skipped > > -? ? ? ? return ticket; > -? ? } > - > -? ? /** > ? ? ? * Retrieves the ticket corresponding to the client/server principal > ? ? ? * pair from the Subject in the specified AccessControlContext. > ? ? ? * If the ticket can not be found in the Subject, and if > > Thanks, > Max > From xuelei.fan at oracle.com Mon Jul 8 03:00:12 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 7 Jul 2019 20:00:12 -0700 Subject: RFR [13] JDK-8226374 Restric signature algorithms and named groups In-Reply-To: References: Message-ID: <32ca269b-8f3e-cd46-af5d-40c993a13842@oracle.com> ping ... On 6/28/2019 1:41 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > ??? http://cr.openjdk.java.net/~xuelei/8226374/webrev.00/ > > During handshaking, the selection of signature algorithms was not > checked with the algorithm constraints.? Then the available signature > algorithms may be ignored if a restricted algorithm get selected.? The > connection should be able to be established as there are available > algorithms. > > Within this update, more algorithm constraints checking are introduced > in the signature algorithms and named groups code. > > The significant changes are in NamedGroup.java and SignatureScheme.java, > in order to introduce the checking and algorithm parameters and specs. > > Thanks, > Xuelei From anthony.scarpino at oracle.com Mon Jul 8 04:14:03 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Sun, 7 Jul 2019 21:14:03 -0700 Subject: RFR 8226338: Updates to Stateless Resumption In-Reply-To: <3f693817-9d34-f237-61e3-c73da0daedd9@oracle.com> References: <8d314691-0ca5-307e-41a1-e6ba731abacb@oracle.com> <3f693817-9d34-f237-61e3-c73da0daedd9@oracle.com> Message-ID: <03e711c6-25d2-78b2-a3f9-8ff5a2461094@oracle.com> On 7/4/19 10:14 PM, Xuelei Fan wrote: > SSLSessionImpl.java > ------------------- > ?526???? boolean checkSessionTicket(HandshakeContext hc) { > As the return value is a boolean type, the method is better to use > "isSomething".? Otherwise, the meaning of the code > "!checkSessionTicket()" is clear and need to read the implementation code. I'll see if I can come up with a "is*" name > > NewSessionTicket.java > --------------------- > ?104???? //???? opaque ticket<1..2^16-1>; > ?108???? if (m.remaining() < 6) { > > Per section 3.3, RFC 5077, line 104 should be: > ???????? opaque ticket<0..2^16-1>; I'm glad you saw that because it was confusing me why a zero buffer was allowed in 5077 > > To be better understand the number 6, as you are already there, would > you please update line 104 as well? > > I did not get the idea of the update of > T13NewSessionTicketMessage.T13NewSessionTicketMessage().? It looks like > that the updated code does not comply to TLS 1.3 specification of > NewSessionTicket. > So I assume you are talking about the zero length ticket. I never noticed that 1.3 changed behavior away from zero length tickets. It would appear the spec writings made every attempt to make NST usage confusing between versions. > > ?453???????????? NewSessionTicketMessage nstm; > ?454???????????? nstm = new T12NewSessionTicketMessage(shc, > sessionTimeoutSeconds, > > Maybe better to use one statement. > ?453???????????? NewSessionTicketMessage nstm = > ?454????????????????????? new T12NewSessionTicketMessage(shc, > sessionTimeoutSeconds, > > ?499???????????? if (nstm.ticket.length == 0) { > Empty ticket should be not allowed in TLS 1.3 > > ServerHelloDone.java > -------------------- > ?110???????????? if (shc.statelessResumption) { > ?111 shc.handshakeConsumers.put(SSLHandshake.NEW_SESSION_TICKET.id, > ?112???????????????????????? SSLHandshake.NEW_SESSION_TICKET); > ?113???????????? } > > I think the NewSessionTicket is produced by server and consumed in > client side.? I did not get the idea to have NST consumer in server > side.? Am I missing something? > Hmm.. I remember making this change, and I thought it was a good idea, but clearly it does nothing. > SessionTicketExtension.java > --------------------------- > ?260???????????? if (!hc.handshakeSession.checkSessionTicket(hc)) { > ?261???????????????? return new byte[0]; > ?262???????????? } > > From the above line, I guess why you use empty ticket for TLS 1.3, > although empty ticket is not allowed in TLS 1.3. > > I may suggest never use empty ticket.? Always use a proper ticket in a > proper NewSessionTicket message, at least in format.? When there is a > problem to retrieve the values, cache the session and prefer to use the > case rather than the ticket for session resumption.?? As may be a little > bit more interop friendly. Yes, the 1.3 non-zero length sure complicates the code.. Very unfortunate. > > ?295???????????????? if (SSLLogger.isOn && > SSLLogger.isOn("ssl,handshake")) { > ?296???????????????????? SSLLogger.fine("Encryption failed." + > e.getMessage()); > ?297???????????????????? e.printStackTrace(); // Helps with > session.write() > ?298???????????????? } > > Line 297 does not use SSLLogger.? It could be: > ???????? SSLLogger.fine("Encryption failed", e); I didn't noticed logger accepted exceptions. > > On 7/2/2019 10:35 AM, Anthony Scarpino wrote: >> >> Hi, >> >> I need a code review on some updates to the stateless resumption. >> 1) Changing peerSupportedSignAlgs from a String[] to Collection[] >> 2) Additional items added to the stateless ticket >> 3) Not provide a stateless ticket when the masterkey is not accessible >> (FIPS) or when boundValues are used > I did not whether the update works if bound values are set after the > handshake completed (i.e., after the NewSessionTicket has been produced > and used).? Did you have a test for the case? It was my understanding from previous discussions that we were going to take a wait and see approach with boundValues and NST. When I took a glance at how boundValues were added, they appear to be outside of the normal flow of the ConnectionContext. > > Thanks, > Xuelei > >> 4) Be more graceful in case of stateless ticket generation failure >> >> http://cr.openjdk.java.net/~ascarpino/8226338/webrev.00/ >> >> Tony From sean.mullan at oracle.com Mon Jul 8 15:01:24 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Jul 2019 11:01:24 -0400 Subject: RFR[13] Release Note for Stateless Resumption In-Reply-To: References: Message-ID: <85f91eb3-a937-fb3c-b9a4-edc273d970f5@oracle.com> Fixed a couple of typos. Although it says "This feature is enabled by default.", I think you should also say what the default values of the 2 properties are, just to make it clear how it is enabled by default. Looks good otherwise. --Sean On 7/2/19 5:43 PM, Anthony Scarpino wrote: > Hi, > > I needs a release note review of the Stateless Resumption work > > https://bugs.openjdk.java.net/browse/JDK-8227105 > > thanks > > Tony From xuelei.fan at oracle.com Mon Jul 8 15:02:25 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Jul 2019 08:02:25 -0700 Subject: RFR [14] JDK-8227024 : Remove the deprecated javax.security.cert APIs Message-ID: <49802280-ec4d-3944-6b84-6abbb0dca492@oracle.com> Hi, Please review the following update for JDK 14: http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ and the CSR: https://bugs.openjdk.java.net/browse/JDK-8227395 The javax.security.cert APIs were deprecated in Java SE 9 and marked for removal in Java SE 13. Applications should use the java.security.cert APIs instead. Thanks, Xuelei From xuelei.fan at oracle.com Mon Jul 8 15:30:37 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Jul 2019 08:30:37 -0700 Subject: RFR[13] Release Note for Stateless Resumption In-Reply-To: <85f91eb3-a937-fb3c-b9a4-edc273d970f5@oracle.com> References: <85f91eb3-a937-fb3c-b9a4-edc273d970f5@oracle.com> Message-ID: <7c1e654f-2731-dbf0-7fe3-60d79a045f56@oracle.com> Hi, A couple of comments. In the release note, "For TLS 1.3, stateless tickets use the existing PSK resumption extension in RFC 8446[2]. TLS 1.3 will revert to the session cache if the server property is false. " In CSR, "For TLS 1.3, stateless tickets use the existing PSK resumption extension in (RFC 8446), which require no properties or settings." The above two parts of information are not consistent. ---- RFC 5077[1] RFC 8446[2] [1]: https://tools.ietf.org/html/rfc5077 [2]: https://tools.ietf.org/html/rfc8446 Just a very personal preference. May not need the cite references for RFCs, which are well known. ---- "With less session information cached, some session information may not be available." I did not get the idea. These words may be confusing and misleading. All session information should be available once the session is established. I may just remove this sentence. ---- TLS 1.2 "TLS 1.2" are mentioned multiple times. The NST extension applies to TLS 1.0 and 1.1 as well. We may want to mention TLS 1.0/1.1 as well. Maybe, we can just copy the "Specification" section in the CSR as the release note. Thanks, Xuelei On 7/8/2019 8:01 AM, Sean Mullan wrote: > Fixed a couple of typos. Although it says "This feature is enabled by > default.", I think you should also say what the default values of the 2 > properties are, just to make it clear how it is enabled by default. > > Looks good otherwise. > > --Sean > > On 7/2/19 5:43 PM, Anthony Scarpino wrote: >> Hi, >> >> I needs a release note review of the Stateless Resumption work >> >> https://bugs.openjdk.java.net/browse/JDK-8227105 >> >> thanks >> >> Tony From sean.mullan at oracle.com Mon Jul 8 15:45:32 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Jul 2019 11:45:32 -0400 Subject: RFR [13] JDK-8226374 Restric signature algorithms and named groups In-Reply-To: <32ca269b-8f3e-cd46-af5d-40c993a13842@oracle.com> References: <32ca269b-8f3e-cd46-af5d-40c993a13842@oracle.com> Message-ID: <0348d38d-2fc0-2b19-d5ef-1350bc0766a5@oracle.com> A couple of comments/question so far (not done reviewing) - Please change all instances of "Restric" to "Restrict" (proper spelling) in the bug summary and names of tests, etc - It looks like you have enhanced jdk.tls.disabledAlgorithms to allow you to restrict named groups. I think that would make this an RFE, which will require a CSR and special approval to get into JDK 13. Do you really need this to implement the fix? If not, I would separate that part out and target it to JDK 14. Also, why haven't you updated the definition of jdk.tls.disabledAlgorithms to include named groups? Thanks, Sean On 7/7/19 11:00 PM, Xuelei Fan wrote: > ping ... > > On 6/28/2019 1:41 PM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> ???? http://cr.openjdk.java.net/~xuelei/8226374/webrev.00/ >> >> During handshaking, the selection of signature algorithms was not >> checked with the algorithm constraints.? Then the available signature >> algorithms may be ignored if a restricted algorithm get selected.? The >> connection should be able to be established as there are available >> algorithms. >> >> Within this update, more algorithm constraints checking are introduced >> in the signature algorithms and named groups code. >> >> The significant changes are in NamedGroup.java and >> SignatureScheme.java, in order to introduce the checking and algorithm >> parameters and specs. >> >> Thanks, >> Xuelei From anthony.scarpino at oracle.com Mon Jul 8 16:06:13 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 8 Jul 2019 09:06:13 -0700 Subject: RFR[13] Release Note for Stateless Resumption In-Reply-To: <7c1e654f-2731-dbf0-7fe3-60d79a045f56@oracle.com> References: <85f91eb3-a937-fb3c-b9a4-edc273d970f5@oracle.com> <7c1e654f-2731-dbf0-7fe3-60d79a045f56@oracle.com> Message-ID: <337f3412-5b47-39cc-aec7-2d9bfd29c022@oracle.com> On 7/8/19 8:30 AM, Xuelei Fan wrote: > Hi, > > A couple of comments. > > In the release note, "For TLS 1.3, stateless tickets use the existing > PSK resumption extension in RFC 8446[2]. TLS 1.3 will revert to the > session cache if the server property is false. " > > In CSR, "For TLS 1.3, stateless tickets use the existing PSK resumption > extension in (RFC 8446), which require no properties or settings." > > The above two parts of information are not consistent. Correct, however, while 1.3 uses the existing ticekt mechanism for stateless and stateful without a property setting. However the contents of that ticket do depend on the property. Initially the CSR was more clear about that, but I think as it got edited in review that information was removed as it described the property and handshake message relationship more. Tony > > > ---- > RFC 5077[1] > RFC 8446[2] > [1]: https://tools.ietf.org/html/rfc5077 > [2]: https://tools.ietf.org/html/rfc8446 > > Just a very personal preference. May not need the cite references for > RFCs, which are well known. > > ---- > "With less session information cached, some session information may not > be available." > > I did not get the idea.? These words may be confusing and misleading. > All session information should be available once the session is > established.? I may just remove this sentence. > > ---- > TLS 1.2 > > "TLS 1.2" are mentioned multiple times.? The NST extension applies to > TLS 1.0 and 1.1 as well.? We may want to mention TLS 1.0/1.1 as well. > > > Maybe, we can just copy the "Specification" section in the CSR as the > release note. > > Thanks, > Xuelei > > > On 7/8/2019 8:01 AM, Sean Mullan wrote: >> Fixed a couple of typos. Although it says "This feature is enabled by >> default.", I think you should also say what the default values of the >> 2 properties are, just to make it clear how it is enabled by default. >> >> Looks good otherwise. >> >> --Sean >> >> On 7/2/19 5:43 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I needs a release note review of the Stateless Resumption work >>> >>> https://bugs.openjdk.java.net/browse/JDK-8227105 >>> >>> thanks >>> >>> Tony From xuelei.fan at oracle.com Mon Jul 8 16:30:31 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Jul 2019 09:30:31 -0700 Subject: RFR [13] JDK-8226374 Restric signature algorithms and named groups In-Reply-To: <0348d38d-2fc0-2b19-d5ef-1350bc0766a5@oracle.com> References: <32ca269b-8f3e-cd46-af5d-40c993a13842@oracle.com> <0348d38d-2fc0-2b19-d5ef-1350bc0766a5@oracle.com> Message-ID: <8adbdfa7-a48d-c2e1-4bf4-bfffd16b8fdc@oracle.com> On 7/8/2019 8:45 AM, Sean Mullan wrote: > A couple of comments/question so far (not done reviewing) > > - Please change all instances of "Restric" to "Restrict" (proper > spelling) in the bug summary and names of tests, etc > I will do it. > - It looks like you have enhanced jdk.tls.disabledAlgorithms to allow > you to restrict named groups. I think that would make this an RFE, which > will require a CSR and special approval to get into JDK 13. Do you > really need this to implement the fix? Named groups is a part of the signature algorithms for TLS 1.3. For example for signature algorithm ecdsa_secp256r1_sha256, "secp256r1" is the named groups part. It is simple to restrict named groups and signature algorithm in one update. We can go as an RFE for JDK 14. But I would prefer to have it in JDK 13 so that applications could disable RSASSA-PSS and the certificate selection could be more robust. As this does not change the public APIs and specs, I think it might be fine to go with a bug fix for JDK 13 without a CSR. > If not, I would separate that > part out and target it to JDK 14. Also, why haven't you updated the > definition of jdk.tls.disabledAlgorithms to include named groups? > The named groups will be documented in the Standard Algorithms Documentation. I think it is sufficient. I'm fine to make it an RFE in JDK 14 if you want a CSR. We could backport it later if necessary. Thanks, Xuelei > Thanks, > Sean > > On 7/7/19 11:00 PM, Xuelei Fan wrote: >> ping ... >> >> On 6/28/2019 1:41 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Could I get the following update reviewed? >>> ???? http://cr.openjdk.java.net/~xuelei/8226374/webrev.00/ >>> >>> During handshaking, the selection of signature algorithms was not >>> checked with the algorithm constraints.? Then the available signature >>> algorithms may be ignored if a restricted algorithm get selected. >>> The connection should be able to be established as there are >>> available algorithms. >>> >>> Within this update, more algorithm constraints checking are >>> introduced in the signature algorithms and named groups code. >>> >>> The significant changes are in NamedGroup.java and >>> SignatureScheme.java, in order to introduce the checking and >>> algorithm parameters and specs. >>> >>> Thanks, >>> Xuelei From xuelei.fan at oracle.com Mon Jul 8 17:00:54 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Jul 2019 10:00:54 -0700 Subject: RFR[13] Release Note for Stateless Resumption In-Reply-To: <337f3412-5b47-39cc-aec7-2d9bfd29c022@oracle.com> References: <85f91eb3-a937-fb3c-b9a4-edc273d970f5@oracle.com> <7c1e654f-2731-dbf0-7fe3-60d79a045f56@oracle.com> <337f3412-5b47-39cc-aec7-2d9bfd29c022@oracle.com> Message-ID: On 7/8/2019 9:06 AM, Anthony Scarpino wrote: > On 7/8/19 8:30 AM, Xuelei Fan wrote: >> Hi, >> >> A couple of comments. >> >> In the release note, "For TLS 1.3, stateless tickets use the existing >> PSK resumption extension in RFC 8446[2]. TLS 1.3 will revert to the >> session cache if the server property is false. " >> >> In CSR, "For TLS 1.3, stateless tickets use the existing PSK >> resumption extension in (RFC 8446), which require no properties or >> settings." >> >> The above two parts of information are not consistent. > > Correct, however, while 1.3 uses the existing ticekt mechanism for > stateless and stateful without a property setting.? However the contents > of that ticket do depend on the property. > I think for TLS 1.3, the contents of the ticket should be independent from the property. The property names "jdk.tls.server.enableSessionTicketExtension" and "jdk.tls.client.enableSessionTicketExtension" are about the ST extension. TLS 1.3 session resumption uses a different mechanism. I may missed something. Why you think the content of the ticket depending on the property? Thanks, Xuelei From sean.mullan at oracle.com Mon Jul 8 17:30:44 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Jul 2019 13:30:44 -0400 Subject: RFR [13] JDK-8226374 Restric signature algorithms and named groups In-Reply-To: <8adbdfa7-a48d-c2e1-4bf4-bfffd16b8fdc@oracle.com> References: <32ca269b-8f3e-cd46-af5d-40c993a13842@oracle.com> <0348d38d-2fc0-2b19-d5ef-1350bc0766a5@oracle.com> <8adbdfa7-a48d-c2e1-4bf4-bfffd16b8fdc@oracle.com> Message-ID: <4b6b5a96-c0ad-557a-8b0a-28ea9da60d3c@oracle.com> On 7/8/19 12:30 PM, Xuelei Fan wrote: >> - It looks like you have enhanced jdk.tls.disabledAlgorithms to allow >> you to restrict named groups. I think that would make this an RFE, >> which will require a CSR and special approval to get into JDK 13. Do >> you really need this to implement the fix? > Named groups is a part of the signature algorithms for TLS 1.3.? For > example for signature algorithm ecdsa_secp256r1_sha256, "secp256r1" is > the named groups part.? It is simple to restrict named groups and > signature algorithm in one update. So, for the reported issue in 8226374, with this fix, I can now disable the RSASSA-PSS algorithms by adding the Java Security standard name "RSASSA-PSS" to the jdk.tls.disabledAlgorithms property and it will work on client and server side. This seems consistent, with disabling other signature algorithms like MD5withRSA, SHA1withRSA, etc... But now with your fix I can also add "secp256r1" to the jdk.tls.disabledAlgorithms property and (I think) it will disable any algorithm using that curve. I am wondering why you really need this in order to fix the reported issue. > We can go as an RFE for JDK 14.? But I would prefer to have it in JDK 13 > so that applications could disable RSASSA-PSS and the certificate > selection could be more robust. Can't you still fix the issue w/o needing to disable named groups? > As this does not change the public APIs and specs, I think it might be > fine to go with a bug fix for JDK 13 without a CSR. > > >> If not, I would separate that part out and target it to JDK 14. Also, >> why haven't you updated the definition of jdk.tls.disabledAlgorithms >> to include named groups? >> > The named groups will be documented in the Standard Algorithms > Documentation.? I think it is sufficient. Named groups are not yet documented in the Standard Algorithms Doc. This was deferred to JDK 14 [1] because it required some changes in the implementation to be fixed first. > I'm fine to make it an RFE in JDK 14 if you want a CSR.? We could > backport it later if necessary. I am mainly wondering if you can just fix the specific issue in 13 (RSSSA-PSS) and add support for disabling named groups later, in JDK 14, since that seems more like an RFE to me and also depends on the standard names being defined for named curves. --Sean [1] https://bugs.openjdk.java.net/browse/JDK-8210755 From anthony.scarpino at oracle.com Mon Jul 8 17:40:04 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 8 Jul 2019 10:40:04 -0700 Subject: RFR[13] Release Note for Stateless Resumption In-Reply-To: References: <85f91eb3-a937-fb3c-b9a4-edc273d970f5@oracle.com> <7c1e654f-2731-dbf0-7fe3-60d79a045f56@oracle.com> <337f3412-5b47-39cc-aec7-2d9bfd29c022@oracle.com> Message-ID: On 7/8/19 10:00 AM, Xuelei Fan wrote: > On 7/8/2019 9:06 AM, Anthony Scarpino wrote: >> On 7/8/19 8:30 AM, Xuelei Fan wrote: >>> Hi, >>> >>> A couple of comments. >>> >>> In the release note, "For TLS 1.3, stateless tickets use the existing >>> PSK resumption extension in RFC 8446[2]. TLS 1.3 will revert to the >>> session cache if the server property is false. " >>> >>> In CSR, "For TLS 1.3, stateless tickets use the existing PSK >>> resumption extension in (RFC 8446), which require no properties or >>> settings." >>> >>> The above two parts of information are not consistent. >> >> Correct, however, while 1.3 uses the existing ticekt mechanism for >> stateless and stateful without a property setting.? However the >> contents of that ticket do depend on the property. >> > I think for TLS 1.3, the contents of the ticket should be independent > from the property.? The property names > "jdk.tls.server.enableSessionTicketExtension" and > "jdk.tls.client.enableSessionTicketExtension" are about the ST > extension.? TLS 1.3 session resumption uses a different mechanism. > > I may missed something.? Why you think the content of the ticket > depending on the property? > > Thanks, > Xuelei How else is the context going to be controlled? Otherwise 1.3 will always be stateless and the SSLSessions will always lack information that some may want. While the property name isn't entirely accurate, the result is the same for 1.2 and 1.3. I thought this was the compromise we came up with when I had 4 properties and you wanted less. Tony From xuelei.fan at oracle.com Mon Jul 8 17:58:04 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Jul 2019 10:58:04 -0700 Subject: RFR [13] JDK-8226374 Restric signature algorithms and named groups In-Reply-To: <4b6b5a96-c0ad-557a-8b0a-28ea9da60d3c@oracle.com> References: <32ca269b-8f3e-cd46-af5d-40c993a13842@oracle.com> <0348d38d-2fc0-2b19-d5ef-1350bc0766a5@oracle.com> <8adbdfa7-a48d-c2e1-4bf4-bfffd16b8fdc@oracle.com> <4b6b5a96-c0ad-557a-8b0a-28ea9da60d3c@oracle.com> Message-ID: <7ec366fb-c2f6-d7de-4b48-b14d984a831c@oracle.com> I see your points. As we can backport to JDK 13 later, it may not worthy to rollback to support the "RSASSA-PSS" algorithm restriction only in JDK 13. Applications may also run into problems that need to disable particular groups, similar to the RSASSA-PSS algorithm problem. Let's solve the problem in one update, and re-target it to JDK 14. I will file an CSR for JDK 14, and 13 backport if necessary. Thanks, Xuelei On 7/8/2019 10:30 AM, Sean Mullan wrote: > On 7/8/19 12:30 PM, Xuelei Fan wrote: >>> - It looks like you have enhanced jdk.tls.disabledAlgorithms to allow >>> you to restrict named groups. I think that would make this an RFE, >>> which will require a CSR and special approval to get into JDK 13. Do >>> you really need this to implement the fix? >> Named groups is a part of the signature algorithms for TLS 1.3.? For >> example for signature algorithm ecdsa_secp256r1_sha256, "secp256r1" is >> the named groups part.? It is simple to restrict named groups and >> signature algorithm in one update. > > So, for the reported issue in 8226374, with this fix, I can now disable > the RSASSA-PSS algorithms by adding the Java Security standard name > "RSASSA-PSS" to the jdk.tls.disabledAlgorithms property and it will work > on client and server side. This seems consistent, with disabling other > signature algorithms like MD5withRSA, SHA1withRSA, etc... > > But now with your fix I can also add "secp256r1" to the > jdk.tls.disabledAlgorithms property and (I think) it will disable any > algorithm using that curve. I am wondering why you really need this in > order to fix the reported issue. > >> We can go as an RFE for JDK 14.? But I would prefer to have it in JDK >> 13 so that applications could disable RSASSA-PSS and the certificate >> selection could be more robust. > > Can't you still fix the issue w/o needing to disable named groups? > >> As this does not change the public APIs and specs, I think it might be >> fine to go with a bug fix for JDK 13 without a CSR. >> >> >>> If not, I would separate that part out and target it to JDK 14. Also, >>> why haven't you updated the definition of jdk.tls.disabledAlgorithms >>> to include named groups? >>> >> The named groups will be documented in the Standard Algorithms >> Documentation.? I think it is sufficient. > > Named groups are not yet documented in the Standard Algorithms Doc. > This was deferred to JDK 14 [1] because it required some changes in the > implementation to be fixed first. > >> I'm fine to make it an RFE in JDK 14 if you want a CSR.? We could >> backport it later if necessary. > > I am mainly wondering if you can just fix the specific issue in 13 > (RSSSA-PSS) and add support for disabling named groups later, in JDK 14, > since that seems more like an RFE to me and also depends on the standard > names being defined for named curves. > > --Sean > > [1] https://bugs.openjdk.java.net/browse/JDK-8210755 From xuelei.fan at oracle.com Mon Jul 8 18:16:13 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Jul 2019 11:16:13 -0700 Subject: RFR[13] Release Note for Stateless Resumption In-Reply-To: References: <85f91eb3-a937-fb3c-b9a4-edc273d970f5@oracle.com> <7c1e654f-2731-dbf0-7fe3-60d79a045f56@oracle.com> <337f3412-5b47-39cc-aec7-2d9bfd29c022@oracle.com> Message-ID: <691a5986-0ed1-c45a-73be-6f7ec9aa9318@oracle.com> On 7/8/2019 10:40 AM, Anthony Scarpino wrote: > On 7/8/19 10:00 AM, Xuelei Fan wrote: >> On 7/8/2019 9:06 AM, Anthony Scarpino wrote: >>> On 7/8/19 8:30 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> A couple of comments. >>>> >>>> In the release note, "For TLS 1.3, stateless tickets use the >>>> existing PSK resumption extension in RFC 8446[2]. TLS 1.3 will >>>> revert to the session cache if the server property is false. " >>>> >>>> In CSR, "For TLS 1.3, stateless tickets use the existing PSK >>>> resumption extension in (RFC 8446), which require no properties or >>>> settings." >>>> >>>> The above two parts of information are not consistent. >>> >>> Correct, however, while 1.3 uses the existing ticekt mechanism for >>> stateless and stateful without a property setting.? However the >>> contents of that ticket do depend on the property. >>> >> I think for TLS 1.3, the contents of the ticket should be independent >> from the property.? The property names >> "jdk.tls.server.enableSessionTicketExtension" and >> "jdk.tls.client.enableSessionTicketExtension" are about the ST >> extension.? TLS 1.3 session resumption uses a different mechanism. >> >> I may missed something.? Why you think the content of the ticket >> depending on the property? >> >> Thanks, >> Xuelei > > How else is the context going to be controlled?? Otherwise 1.3 will > always be stateless I think we are not on the same page about the bound values in another code review thread, which could be related to this topic. We can talk about this point later when we have an agreement there. > and the SSLSessions will always lack information > that some may want. > I may missed something more. I don't think SSLSessions can lack information even for stateless. > While the property name isn't entirely accurate, the result is the same > for 1.2 and 1.3.? I thought this was the compromise we came up with when > I had 4 properties and you wanted less. > Sorry, I thought we had an agreement that TLS 1.3 is independent from the property. Xuelei From valerie.peng at oracle.com Mon Jul 8 19:12:31 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 8 Jul 2019 12:12:31 -0700 Subject: RFR[13] JDK-8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support In-Reply-To: <761FA3AA-164F-4CC7-94CC-0EED8B6EC350@oracle.com> References: <63fa1e24-f926-19a2-1eea-045a0843ff9d@oracle.com> <761FA3AA-164F-4CC7-94CC-0EED8B6EC350@oracle.com> Message-ID: Right, based on the current impl, a simple "==" seems to work as it's the same NamedCurve instance inside CurveDB. Well, I could also do a bit of code refactoring and add an equals utility method to ECUtil so this may work better with 3rd party provider's impl. Thanks, Valerie On 7/2/2019 8:27 PM, Weijun Wang wrote: > 368 private static boolean isCompatible(ECParameterSpec sigParams, > 369 ECParameterSpec keyParams) { > 370 if (sigParams == null) { > 371 // no restriction on key param > 372 return true; > 373 } > 374 return sigParams.equals(keyParams); > 375 } > > What does "sigParams.equals(keyParams)" mean here? What is the getClass() of those 2 ECParameterSpec objects? > > Or maybe you mean "==" because it is always a NamedCurve stored in CurveDB? > > Thanks, > Max > >> On Jul 3, 2019, at 10:48 AM, Valerie Peng wrote: >> >> Hi >> >> Any one can help reviewing this fix? Some ECDSA certificates contains signature algorithm identifiers with non-null parameter bytes. Before RSASSA-PSS support, these parameter bytes are ignored, however, after RSASSA-PSS support, the parameter bytes are passed to the underlying signature impl and this breaks the ECDSA certificate verification. In order for the verification to succeeds, the SignatureUtil class needs to be able to parse the parameter bytes for ECDSA certificate and that SunEC provider needs to accept non-null signature parameters. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225745 >> Webrev: http://cr.openjdk.java.net/~valeriep/8225745/webrev.00/ >> >> Mach5 run is clean. >> >> Thanks, >> Valerie From bradford.wetmore at oracle.com Mon Jul 8 19:28:50 2019 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 8 Jul 2019 12:28:50 -0700 Subject: RFR [14] JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: <49802280-ec4d-3944-6b84-6abbb0dca492@oracle.com> References: <49802280-ec4d-3944-6b84-6abbb0dca492@oracle.com> Message-ID: I'm not completely up on the nuances of the overall removal process, but codewise it looks good. Brad On 7/8/2019 8:02 AM, Xuelei Fan wrote: > Hi, > > Please review the following update for JDK 14: > ?? http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ > > and the CSR: > ?? https://bugs.openjdk.java.net/browse/JDK-8227395 > > The javax.security.cert APIs were deprecated in Java SE 9 and marked for > removal in Java SE 13. Applications should use the java.security.cert > APIs instead. > > Thanks, > Xuelei From stuart.marks at oracle.com Mon Jul 8 21:33:41 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 8 Jul 2019 14:33:41 -0700 Subject: RFR [14] JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: References: <49802280-ec4d-3944-6b84-6abbb0dca492@oracle.com> Message-ID: <1fff3f18-606b-8bb4-a409-09665af1911c@oracle.com> Hi, thanks for asking about this. There's not much process, but there unfortunately is some that isn't quite written down yet. :-) Essentially something must be deprecated for removal in some release prior to it actually being removed in a subsequent release. In the "old days" of multi-year releases, marking for removal in one release and removing it in the next seemed reasonable. In the new model of six-month releases, removing something in the very next release seems too soon. We're currently thinking that typically one should remove a feature no sooner than the second release after it's marked for removal, unless there's a compelling reason to remove it more quickly. In this case the bug report (JDK-8227024) says that the APIs in question were marked for removal in JDK 9. But Xuelei's message says that they were deprecated (ordinarily, i.e., not-for-removal) in JDK 9, and then deprecated for removal in JDK 13. That looks right, since the JDK 12 docs don't mention deprecation for removal. I also note that the deprecation annotation says since="9" which is the release in which deprecation first appeared, but not the release in which forRemoval=true was added. It isn't very clear whether this is the date of first deprecation or date at which forRemoval=true was added. I should think about clarifying the spec in that regard. In any case, it's probably premature to remove these APIs from JDK 14. If it's reasonable to do so, I'd suggest postponing the removal until JDK 15. s'marks On 7/8/19 12:28 PM, Bradford Wetmore wrote: > I'm not completely up on the nuances of the overall removal process, but > codewise it looks good. > > Brad > > > On 7/8/2019 8:02 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the following update for JDK 14: >> ??? http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ >> >> and the CSR: >> ??? https://bugs.openjdk.java.net/browse/JDK-8227395 >> >> The javax.security.cert APIs were deprecated in Java SE 9 and marked for >> removal in Java SE 13. Applications should use the java.security.cert APIs >> instead. >> >> Thanks, >> Xuelei From xuelei.fan at oracle.com Mon Jul 8 22:27:36 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Jul 2019 15:27:36 -0700 Subject: RFR [14] JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: <1fff3f18-606b-8bb4-a409-09665af1911c@oracle.com> References: <49802280-ec4d-3944-6b84-6abbb0dca492@oracle.com> <1fff3f18-606b-8bb4-a409-09665af1911c@oracle.com> Message-ID: Thanks for looking into the update. The "forRemoval=true" tag was added in March 2010 (JDK-8160247). It make sense to me to postpone the removal until JDK 15. I re-targeted the RFE and CSR to JDK 15. Thanks, Xuelei On 7/8/2019 2:33 PM, Stuart Marks wrote: > Hi, thanks for asking about this. > > There's not much process, but there unfortunately is some that isn't > quite written down yet. :-) Essentially something must be deprecated for > removal in some release prior to it actually being removed in a > subsequent release. In the "old days" of multi-year releases, marking > for removal in one release and removing it in the next seemed > reasonable. In the new model of six-month releases, removing something > in the very next release seems too soon. We're currently thinking that > typically one should remove a feature no sooner than the second release > after it's marked for removal, unless there's a compelling reason to > remove it more quickly. > > In this case the bug report (JDK-8227024) says that the APIs in question > were marked for removal in JDK 9. But Xuelei's message says that they > were deprecated (ordinarily, i.e., not-for-removal) in JDK 9, and then > deprecated for removal in JDK 13. That looks right, since the JDK 12 > docs don't mention deprecation for removal. > > > I also note that the deprecation annotation says since="9" which is the > release in which deprecation first appeared, but not the release in > which forRemoval=true was added. It isn't very clear whether this is the > date of first deprecation or date at which forRemoval=true was added. I > should think about clarifying the spec in that regard. > > In any case, it's probably premature to remove these APIs from JDK 14. > If it's reasonable to do so, I'd suggest postponing the removal until > JDK 15. > > s'marks > > On 7/8/19 12:28 PM, Bradford Wetmore wrote: >> I'm not completely up on the nuances of the overall removal process, >> but codewise it looks good. >> >> Brad >> >> >> On 7/8/2019 8:02 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the following update for JDK 14: >>> ??? http://cr.openjdk.java.net/~xuelei/8227024/webrev.00/ >>> >>> and the CSR: >>> ??? https://bugs.openjdk.java.net/browse/JDK-8227395 >>> >>> The javax.security.cert APIs were deprecated in Java SE 9 and marked >>> for removal in Java SE 13. Applications should use the >>> java.security.cert APIs instead. >>> >>> Thanks, >>> Xuelei From valerie.peng at oracle.com Mon Jul 8 23:50:30 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 8 Jul 2019 16:50:30 -0700 Subject: RFR 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working In-Reply-To: References: <6afc52c5-cf29-827a-0591-27714bcd6068@oracle.com> Message-ID: Hi Jamil, Sorry for the late reply. It's been a long while since I looked at this PBES2 scheme and I need to think a few things through. - line 29-30, 37, I don't see Constructor, BigInteger, and ArrayList being used? - line 158: the pbes2AlgorithmNameis initialized to null. Is it our intention to return null if toString() is called upon an PBES2 AlgorithmParameters object without init(...) call? - line 176: does "keysize" means the optional keyLength field inside the PBES2-params struct? Its value is from various sources. A proper definition would help ensure its value is correctly set. - line 207: If encoding to a DerOutputStream, why not decode using a DerInputStream? - line 203: based on RFC3370, 5911, the preferred way for HMAC is to omit the parameters instead of encoding a NULL. So, we probably should not encode a null on line 203. Also, for decode, line 520 to 522 can be moved here so that the decode can handle both cases, i.e. omitted and present NULL, for max compatibility. - line 295 - 298: if there is a comment on line 271 which explains when "keyLen" is for, then we don't need this block of comment. Essentially, keyLen holds that restricted key length value, right? KEYLEN_ANY means no restriction whatsoever. - line 376: the impl of validateEncParams() seems to allow null cipherParams as it returns immediately if its value is null. I am not sure if we should allow null cipherParam though as this cipherParam object is needed for encoding "encryptionScheme" field of the PBES2-params struct. For example, if the parameters field for AES_128_CBC must contain 16-byte IV, then a null cipherParams should be rejected. Same goes to other encryption schemes. - line 379: Since encyptionType is found using cipherAlgo and keysize in the constructor, why can't we just format encryptionType.schemeName as in getEncSchemeName()? - line 419-422: Shouldn't this check be moved up to line 414, i.e. in the block of code which handles the buggy encoding? Otherwise, it looks like a duplicate check of line 400. - line 494, 630, 735: change the check to use KEYLEN_ANY? -line 638: extra indentation? - line 725-752: Seems better to check the IV length before checking and set the keysize. - line 788: May return RC2_-1 or RC5_-1? Will send you comments for the rest of webrev separately. Thanks, Valerie || On 6/20/2019 6:59 PM, Jamil Nimeh wrote: > Hello all, > > I've updated the fix to 8076999 with the following changes: > > * We now use sun.security.x509.AlgorithmId and it internally uses > AlgorithmParameters implementations to handle the DER encoding and > decoding of encryption scheme parameters. > o This means that we need to add one new standard name and some > OID aliases for some AlgorithmParameters.? See the CSR link > below for details. > * Added a new RC5Parameter AlgorithmParameters implementation to > SunJCE, plus unit tests. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.02 > > > On 5/24/2019 3:51 PM, Jamil Nimeh wrote: >> >> Hello all, happy Friday! >> >> Please review the following CSR and code review.? This makes updates >> to the SunJCE implementation of PBES2-based AlgorithmParameters.? >> Many of the details are in the CSR (see the link below).? But a short >> list of the updates: >> >> * Add DER Encode/Decode support for the following OIDS from RFC 8018: >> o PRFs: HmacSHA512/224, HmacSHA512/256 >> o Encryption Schemes: AES-192-CBC, DES, Triple-DES, RC2, RC5 >> * Enforce init-time type consistency between AlgorithmParameterSpec >> objects and the algorithms they are used with (i.e. No using >> RC5ParameterSpec with AES-128-CBC. >> * Enforce sanity checks on AlgorithmParameterSpec objects used to >> init (e.g. IV length checks, integer range checks, etc.) >> * Fixed a bug where explicit DER decoding of the optional key >> length field in PBKDF2-params would cause the PRF to be forced to >> HmacSHA1 even if the DER indicated otherwise >> * Allow incoming DER encoded AlgorithmIdentifier structures to >> honor the OPTIONAL qualifier on the parameters field for both >> PRFs and Encryption Schemes. >> * If a null encryption scheme AlgorithmParameterSpec is provided >> during init time, omit the PBES2-params.encryptionScheme's >> parameter segment since it is OPTIONAL per the ASN.1 from RFC 5280 >> >> More details are in the CSR. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.01/ >> >> --Jamil >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Jul 9 00:09:43 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 8 Jul 2019 17:09:43 -0700 Subject: RFR[13] JDK-8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support In-Reply-To: References: <63fa1e24-f926-19a2-1eea-045a0843ff9d@oracle.com> <761FA3AA-164F-4CC7-94CC-0EED8B6EC350@oracle.com> Message-ID: <5954fdb9-e259-f8bb-3f75-64531825ab46@oracle.com> Here is the updated webrev w/ ECUtil.equals() utility method: http://cr.openjdk.java.net/~valeriep/8225745/webrev.01/ Regards, Valerie On 7/8/2019 12:12 PM, Valerie Peng wrote: > Right, based on the current impl, a simple "==" seems to work as it's > the same NamedCurve instance inside CurveDB. Well, I could also do a > bit of code refactoring and add an equals utility method to ECUtil so > this may work better with 3rd party provider's impl. > > Thanks, > Valerie > On 7/2/2019 8:27 PM, Weijun Wang wrote: >> ? 368???? private static boolean isCompatible(ECParameterSpec sigParams, >> ? 369???????????? ECParameterSpec keyParams) { >> ? 370???????? if (sigParams == null) { >> ? 371???????????? // no restriction on key param >> ? 372???????????? return true; >> ? 373???????? } >> ? 374???????? return sigParams.equals(keyParams); >> ? 375???? } >> >> What does "sigParams.equals(keyParams)" mean here? What is the >> getClass() of those 2 ECParameterSpec objects? >> >> Or maybe you mean "==" because it is always a NamedCurve stored in >> CurveDB? >> >> Thanks, >> Max >> >>> On Jul 3, 2019, at 10:48 AM, Valerie Peng >>> wrote: >>> >>> Hi >>> >>> Any one can help reviewing this fix? Some ECDSA certificates >>> contains signature algorithm identifiers with non-null parameter >>> bytes. Before RSASSA-PSS support, these parameter bytes are ignored, >>> however, after RSASSA-PSS support, the parameter bytes are passed to >>> the underlying signature impl and this breaks the ECDSA certificate >>> verification. In order for the verification to succeeds, the >>> SignatureUtil class needs to be able to parse the parameter bytes >>> for ECDSA certificate and that SunEC provider needs to accept >>> non-null signature parameters. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225745 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8225745/webrev.00/ >>> >>> Mach5 run is clean. >>> >>> Thanks, >>> Valerie From valerie.peng at oracle.com Tue Jul 9 00:24:32 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 8 Jul 2019 17:24:32 -0700 Subject: RFR[13] JDK-8181386: CipherSpi ByteBuffer to byte array conversion fails for certain data overlap conditions In-Reply-To: <5311ec31-4555-60ed-271f-c220cfff7464@oracle.com> References: <5311ec31-4555-60ed-271f-c220cfff7464@oracle.com> Message-ID: <51dccfa9-e9e3-d039-829f-5d332f8de750@oracle.com> Ping... May defer this to 14 if no one has cycles to review it. Thanks, Valerie On 6/14/2019 5:19 PM, Valerie Peng wrote: > > > Anyone can help review this fix on ByteBuffer input/output encryption? > > The fix should be self-explanatory with the comments. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181386 > > Webrev:http://cr.openjdk.java.net/~valeriep/8181386/webrev.00/ > > > Mach5 run is clean. > > Thanks, > Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Jul 9 02:45:52 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 9 Jul 2019 10:45:52 +0800 Subject: RFR[13] JDK-8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support In-Reply-To: <5954fdb9-e259-f8bb-3f75-64531825ab46@oracle.com> References: <63fa1e24-f926-19a2-1eea-045a0843ff9d@oracle.com> <761FA3AA-164F-4CC7-94CC-0EED8B6EC350@oracle.com> <5954fdb9-e259-f8bb-3f75-64531825ab46@oracle.com> Message-ID: SignatureUtil::getParamSpec(String,byte[]): 126 paramSpec = ECUtil.getECParameterSpec(p, paramBytes); ECUtil.getECParameterSpec() could return null when "parameters.getParameterSpec(ECParameterSpec.class)" throws an InvalidParameterSpecException. So the behavior is now different from the other getParamSpec(String,AlgorithmParameters) method where the exception is wrapped into a ProviderException. Does this matter? Thanks, Max > On Jul 9, 2019, at 8:09 AM, Valerie Peng wrote: > > > Here is the updated webrev w/ ECUtil.equals() utility method: > > http://cr.openjdk.java.net/~valeriep/8225745/webrev.01/ > > Regards, > Valerie > On 7/8/2019 12:12 PM, Valerie Peng wrote: >> Right, based on the current impl, a simple "==" seems to work as it's the same NamedCurve instance inside CurveDB. Well, I could also do a bit of code refactoring and add an equals utility method to ECUtil so this may work better with 3rd party provider's impl. >> >> Thanks, >> Valerie >> On 7/2/2019 8:27 PM, Weijun Wang wrote: >>> 368 private static boolean isCompatible(ECParameterSpec sigParams, >>> 369 ECParameterSpec keyParams) { >>> 370 if (sigParams == null) { >>> 371 // no restriction on key param >>> 372 return true; >>> 373 } >>> 374 return sigParams.equals(keyParams); >>> 375 } >>> >>> What does "sigParams.equals(keyParams)" mean here? What is the getClass() of those 2 ECParameterSpec objects? >>> >>> Or maybe you mean "==" because it is always a NamedCurve stored in CurveDB? >>> >>> Thanks, >>> Max >>> >>>> On Jul 3, 2019, at 10:48 AM, Valerie Peng wrote: >>>> >>>> Hi >>>> >>>> Any one can help reviewing this fix? Some ECDSA certificates contains signature algorithm identifiers with non-null parameter bytes. Before RSASSA-PSS support, these parameter bytes are ignored, however, after RSASSA-PSS support, the parameter bytes are passed to the underlying signature impl and this breaks the ECDSA certificate verification. In order for the verification to succeeds, the SignatureUtil class needs to be able to parse the parameter bytes for ECDSA certificate and that SunEC provider needs to accept non-null signature parameters. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225745 >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8225745/webrev.00/ >>>> >>>> Mach5 run is clean. >>>> >>>> Thanks, >>>> Valerie From xuelei.fan at oracle.com Tue Jul 9 03:00:22 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Jul 2019 20:00:22 -0700 Subject: RFR[13] JDK-8181386: CipherSpi ByteBuffer to byte array conversion fails for certain data overlap conditions In-Reply-To: <51dccfa9-e9e3-d039-829f-5d332f8de750@oracle.com> References: <5311ec31-4555-60ed-271f-c220cfff7464@oracle.com> <51dccfa9-e9e3-d039-829f-5d332f8de750@oracle.com> Message-ID: <574e31b1-5be7-595e-e3bd-8a32b23d5eb1@oracle.com> I looked at the code a while back. The implementation looks good but very complicated. I'm not very sure if the performance benefit really worthy it. I may just simplify it to use temporary buffer if the input and output buffer shares the array. So I was hesitated ... However, as you are already there, it may not worthy to re-write the fix as well. ;-) So, it's good to me to have it now. Please go ahead. Thanks, Xuelei On 7/8/2019 5:24 PM, Valerie Peng wrote: > Ping... > > May defer this to 14 if no one has cycles to review it. > > Thanks, > Valerie > On 6/14/2019 5:19 PM, Valerie Peng wrote: >> >> >> Anyone can help review this fix on ByteBuffer input/output encryption? >> >> The fix should be self-explanatory with the comments. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8181386 >> >> Webrev:http://cr.openjdk.java.net/~valeriep/8181386/webrev.00/ >> >> >> Mach5 run is clean. >> >> Thanks, >> Valerie From weijun.wang at oracle.com Tue Jul 9 13:03:16 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 9 Jul 2019 21:03:16 +0800 Subject: RFR 8227381: GSS login fails with PREAUTH_FAILED Message-ID: <9CF36AFE-51E7-4FE5-A097-7B5B7D8A125F@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8227381/webrev.00/ When the client is talking to an old KDC that does not support referrals and only knows DES, it fails like this: c: PA_REQ_ENC_PA_REP s: KDC_ERR_PREAUTH_FAILED c: PA_REQ_ENC_PA_REP + PA_ENC_TIMESTAMP s: KDC_ERR_PREAUTH_FAILED c: PA_ENC_TIMESTAMP using aes256-cts s: KDC_ERR_PREAUTH_FAILED c: With this fix, whenever there is a referrals state change (fallback to no referrals, change realm), the preauth state (pakey and preAuthFailedOnce) is reset, so it will be c: PA_REQ_ENC_PA_REP s: KDC_ERR_PREAUTH_FAILED c: PA_REQ_ENC_PA_REP + PA_ENC_TIMESTAMP s: KDC_ERR_PREAUTH_FAILED c: s: KDC_ERR_PREAUTH_REQUIRED suggesting des-cbc-md5 c: PA_ENC_TIMESTAMP using des-cbc-md5 s: AS-REP c: Thanks, Max From xuelei.fan at oracle.com Tue Jul 9 13:11:29 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 9 Jul 2019 06:11:29 -0700 Subject: RFR 8227381: GSS login fails with PREAUTH_FAILED In-Reply-To: <9CF36AFE-51E7-4FE5-A097-7B5B7D8A125F@oracle.com> References: <9CF36AFE-51E7-4FE5-A097-7B5B7D8A125F@oracle.com> Message-ID: Looks fine to me. Xuelei On 7/9/2019 6:03 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8227381/webrev.00/ > > When the client is talking to an old KDC that does not support referrals and only knows DES, it fails like this: > > c: PA_REQ_ENC_PA_REP > s: KDC_ERR_PREAUTH_FAILED > c: PA_REQ_ENC_PA_REP + PA_ENC_TIMESTAMP > s: KDC_ERR_PREAUTH_FAILED > c: PA_ENC_TIMESTAMP using aes256-cts > s: KDC_ERR_PREAUTH_FAILED > c: > > With this fix, whenever there is a referrals state change (fallback to no referrals, change realm), the preauth state (pakey and preAuthFailedOnce) is reset, so it will be > > c: PA_REQ_ENC_PA_REP > s: KDC_ERR_PREAUTH_FAILED > c: PA_REQ_ENC_PA_REP + PA_ENC_TIMESTAMP > s: KDC_ERR_PREAUTH_FAILED > c: > s: KDC_ERR_PREAUTH_REQUIRED suggesting des-cbc-md5 > c: PA_ENC_TIMESTAMP using des-cbc-md5 > s: AS-REP > c: > > Thanks, > Max > From weijun.wang at oracle.com Tue Jul 9 14:35:18 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 9 Jul 2019 22:35:18 +0800 Subject: [13] RFR 8225687: Newly added sspi.cpp in JDK-6722928 still contains some small errors In-Reply-To: <225AF060-AAAC-47B4-BAD8-37BCB22A5D50@oracle.com> References: <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> <20190529172354.GH7457@twosigma.com> <20190610235635.GL7457@twosigma.com> <49BB2145-B65F-46CA-90A8-BA55588BD48D@oracle.com> <225AF060-AAAC-47B4-BAD8-37BCB22A5D50@oracle.com> Message-ID: Ping again. > On Jul 2, 2019, at 10:51 AM, Weijun Wang wrote: > > "[13]" added to the subject. > >> On Jul 2, 2019, at 10:22 AM, Weijun Wang wrote: >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8225687/webrev.00/ >> >> Most changes are around const usage in gssapi.h. Note that this is internal so the change could only prevent any coding error and will not be visible outside JDK. >> >> Other changes are inside gss_import_name(), gss_compare_name(). I also changed some names like get_oid_set_desc -> show_oid_set. >> >> Thanks, >> Max > From weijun.wang at oracle.com Tue Jul 9 14:35:47 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 9 Jul 2019 22:35:47 +0800 Subject: [13] RFR 8227059: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timed out In-Reply-To: References: <09DC313A-F894-4BDB-AE40-1BB50E6D49D4@oracle.com> Message-ID: <82C01832-858C-40D7-AC05-71DAC7721409@oracle.com> Ping again. > On Jul 3, 2019, at 10:20 AM, Weijun Wang wrote: > > Updated at https://cr.openjdk.java.net/~weijun/8227059/webrev.01. EC added. > > --Max > >> On Jul 2, 2019, at 11:04 PM, Weijun Wang wrote: >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8227059/webrev.00/ >> >> A fake DSA key pair generator with hardcoded keys. I haven't modified EC since it's quite fast. >> >> Thanks, >> Max >> > From xuelei.fan at oracle.com Tue Jul 9 15:05:57 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 9 Jul 2019 08:05:57 -0700 Subject: [13] RFR 8225687: Newly added sspi.cpp in JDK-6722928 still contains some small errors In-Reply-To: References: <20190320161023.GD9177@twosigma.com> <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com> <20190529172354.GH7457@twosigma.com> <20190610235635.GL7457@twosigma.com> <49BB2145-B65F-46CA-90A8-BA55588BD48D@oracle.com> <225AF060-AAAC-47B4-BAD8-37BCB22A5D50@oracle.com> Message-ID: <6cfb3140-a283-ab87-0539-63cd4752af88@oracle.com> I looked at the code a while back. It's good to me. Xuelei On 7/9/2019 7:35 AM, Weijun Wang wrote: > Ping again. > >> On Jul 2, 2019, at 10:51 AM, Weijun Wang wrote: >> >> "[13]" added to the subject. >> >>> On Jul 2, 2019, at 10:22 AM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8225687/webrev.00/ >>> >>> Most changes are around const usage in gssapi.h. Note that this is internal so the change could only prevent any coding error and will not be visible outside JDK. >>> >>> Other changes are inside gss_import_name(), gss_compare_name(). I also changed some names like get_oid_set_desc -> show_oid_set. >>> >>> Thanks, >>> Max > >> > From xuelei.fan at oracle.com Tue Jul 9 15:15:40 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 9 Jul 2019 08:15:40 -0700 Subject: [13] RFR 8227059: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timed out In-Reply-To: <82C01832-858C-40D7-AC05-71DAC7721409@oracle.com> References: <09DC313A-F894-4BDB-AE40-1BB50E6D49D4@oracle.com> <82C01832-858C-40D7-AC05-71DAC7721409@oracle.com> Message-ID: <92475a95-4290-6d72-fb03-f7dc7433a2e6@oracle.com> It's interesting to use fake key generator. The update looks fine to me. I think, there are keytool test cases to use the real key generator for the coverage? Xuelei On 7/9/2019 7:35 AM, Weijun Wang wrote: > Ping again. > >> On Jul 3, 2019, at 10:20 AM, Weijun Wang wrote: >> >> Updated at https://cr.openjdk.java.net/~weijun/8227059/webrev.01. EC added. >> >> --Max >> >>> On Jul 2, 2019, at 11:04 PM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8227059/webrev.00/ >>> >>> A fake DSA key pair generator with hardcoded keys. I haven't modified EC since it's quite fast. >>> >>> Thanks, >>> Max >>> >> > From weijun.wang at oracle.com Tue Jul 9 15:21:08 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 9 Jul 2019 23:21:08 +0800 Subject: [13] RFR 8227059: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timed out In-Reply-To: <92475a95-4290-6d72-fb03-f7dc7433a2e6@oracle.com> References: <09DC313A-F894-4BDB-AE40-1BB50E6D49D4@oracle.com> <82C01832-858C-40D7-AC05-71DAC7721409@oracle.com> <92475a95-4290-6d72-fb03-f7dc7433a2e6@oracle.com> Message-ID: <9B2997E3-EEAD-48CB-9D0D-1C481D84B1C5@oracle.com> > On Jul 9, 2019, at 11:15 PM, Xuelei Fan wrote: > > It's interesting to use fake key generator. The update looks fine to me. > > I think, there are keytool test cases to use the real key generator for the coverage? All other tests use real generators. The fake one is used here simply because keysize is too big. Thanks, Max > > Xuelei > > On 7/9/2019 7:35 AM, Weijun Wang wrote: >> Ping again. >>> On Jul 3, 2019, at 10:20 AM, Weijun Wang wrote: >>> >>> Updated at https://cr.openjdk.java.net/~weijun/8227059/webrev.01. EC added. >>> >>> --Max >>> >>>> On Jul 2, 2019, at 11:04 PM, Weijun Wang wrote: >>>> >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8227059/webrev.00/ >>>> >>>> A fake DSA key pair generator with hardcoded keys. I haven't modified EC since it's quite fast. >>>> >>>> Thanks, >>>> Max >>>> >>> From xuelei.fan at oracle.com Tue Jul 9 15:24:37 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 9 Jul 2019 08:24:37 -0700 Subject: [13] RFR 8227059: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timed out In-Reply-To: <9B2997E3-EEAD-48CB-9D0D-1C481D84B1C5@oracle.com> References: <09DC313A-F894-4BDB-AE40-1BB50E6D49D4@oracle.com> <82C01832-858C-40D7-AC05-71DAC7721409@oracle.com> <92475a95-4290-6d72-fb03-f7dc7433a2e6@oracle.com> <9B2997E3-EEAD-48CB-9D0D-1C481D84B1C5@oracle.com> Message-ID: <4f16d357-898d-b6e1-e8de-46a11636393e@oracle.com> On 7/9/2019 8:21 AM, Weijun Wang wrote: > > >> On Jul 9, 2019, at 11:15 PM, Xuelei Fan wrote: >> >> It's interesting to use fake key generator. The update looks fine to me. >> >> I think, there are keytool test cases to use the real key generator for the coverage? > > All other tests use real generators. The fake one is used here simply because keysize is too big. > Good, and thanks for the confirm! As remind me that large key generation is still expensive in some circumstances. Xuelei > Thanks, > Max > >> >> Xuelei >> >> On 7/9/2019 7:35 AM, Weijun Wang wrote: >>> Ping again. >>>> On Jul 3, 2019, at 10:20 AM, Weijun Wang wrote: >>>> >>>> Updated at https://cr.openjdk.java.net/~weijun/8227059/webrev.01. EC added. >>>> >>>> --Max >>>> >>>>> On Jul 2, 2019, at 11:04 PM, Weijun Wang wrote: >>>>> >>>>> Please take a review at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8227059/webrev.00/ >>>>> >>>>> A fake DSA key pair generator with hardcoded keys. I haven't modified EC since it's quite fast. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>> > From jamil.j.nimeh at oracle.com Tue Jul 9 16:03:28 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 9 Jul 2019 09:03:28 -0700 Subject: RFR 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working In-Reply-To: References: <6afc52c5-cf29-827a-0591-27714bcd6068@oracle.com> Message-ID: Hi Valerie, thanks for the comments: On 7/8/2019 4:50 PM, Valerie Peng wrote: > > Hi Jamil, > > Sorry for the late reply. It's been a long while since I looked at > this PBES2 scheme and I need to think a few things through. > > > > - line 29-30, 37, I don't see Constructor, BigInteger, and ArrayList > being used? > JN: I must have removed them in my local copy of the code since I posted the .02 webrev.? They'll be gone in this next webrev. > > - line 158: the pbes2AlgorithmNameis initialized to null. Is it our > intention to return null if toString() is called upon an PBES2 > AlgorithmParameters object without init(...) call? > JN: Hmm...that's a good question.? In the case of PBES2 alg params with a fully qualified name (PBEWithAnd) the pbes2AlgorithmName is initialized to whatever static class is instantiated from SunJCE.java.? So we don't have to worry there.? In the case of actually using "PBES2" (or its OID counterpart, which is more common), it looks like even before my changes it returned null.? What do you think about returning "PBES2" instead?? Once it goes through init the field will be set to whatever it truly is based on the DER encoding received. > > - line 176: does "keysize" means the optional keyLength field inside > the PBES2-params struct? Its value is from various sources. A proper > definition would help ensure its value is correctly set. > JN: Well, keysize does mean that, but it affects the resulting toString name and can also have an impact on init-time consistency checks in some cases. Keysize is one of the challenging parts of this class, because it can be defined in multiple ways.? It can be implicit (such as in DES or DESede), it can be explicit by OID like it is for AES, and it can be defined by parameters such as in RC2 - there is one OID, no matter whether you do RC2_40, RC2_64 or RC2_128.? Or it can be not defined at all (RC5) in which case you have to assume a reasonable default (like I assume RC5_128) or hope that the KDF parameter segment asserts a key length.? So it gets set in different parts of the code depending on the algorithm and how it's specified. Maybe you can expand a bit on what you're looking for by "proper definition" and I can try to make that happen. > - line 207: If encoding to a DerOutputStream, why not decode using a > DerInputStream? > JN: There's no reason why it couldn't be done that way.? I used DerValue mainly because decoding in PBES2Parameters has been done with DerValue objects from before I started working with the code. So I kept it the same since it seemed to work well. > > - line 203: based on RFC3370, 5911, the preferred way for HMAC is to > omit the parameters instead of encoding a NULL. So, we probably should > not encode a null on line 203. Also, for decode, line 520 to 522 can > be moved here so that the decode can handle both cases, i.e. omitted > and present NULL, for max compatibility. > JN: From all the OpenSSL parameter blocks I've looked at, Hmac params will assert NULL.? There's some interesting history to AlgorithmIdentifier's optional parameter field when there are no parameters in RFC 4055, sec 2.1.? In short, a change happened in the 1997 syntax that removed "optional" which was later fixed, but by then people were getting around the now mandatory field by putting NULL in there.? Honestly, I see NULLs asserted more commonly than it being omitted for message digest and HMAC AlgorithmIdentifiers.? But that might just be me.? According to 4055, omitting the parameters field is the correct way to do it, you are correct about that. Implementations are supposed to accept both forms.? I stuck with it because a.) we were already doing that and nobody was having problems with it, b.) I see NULL asserted more frequently so it seemed like the safer way to go. I can try omitting it and see if openssl will accept it.? If it does then I can make the change permanent.? If it doesn't like it, we should probably leave the NULL in there.? I've got no idea how anyone else encodes AlgorithmIdentifiers...maybe I can play around with NSS and see what it does with Hmac parameters if I can find a tool that will encode some. > - line 295 - 298: if there is a comment on line 271 which explains > when "keyLen" is for, then we don't need this block of comment. > Essentially, keyLen holds that restricted key length value, right? > KEYLEN_ANY means no restriction whatsoever. > JN: Or it can mean that the key length is implicit (e.g. DES is always 56 bits, so I don't need to encode it in ASN.1 and I don't need toString to say DES_56...DES is fine). Maybe rather than a comment on 271, maybe a similar description for KEYLEN_ANY up on 154 might be a good way to go. > > - line 376: the impl of validateEncParams() seems to allow null > cipherParams as it returns immediately if its value is null. I am not > sure if we should allow null cipherParam though as this cipherParam > object is needed for encoding "encryptionScheme" field of the > PBES2-params struct. For example, if the parameters field for > AES_128_CBC must contain 16-byte IV, then a null cipherParams should > be rejected. Same goes to other encryption schemes. > JN: There are tests in the PKCS#12 family of tests that were breaking when I strictly enforced non-null cipherParams from the PBEParameterSpec.? I didn't want to risk messing up a use case in PKCS#12-land that didn't apply directly to what I was fixing.? What I do need to do is have it fail on encoding when null parameters are used, that will be in the next rev of the code.? I hate not being able to fail-fast, but it would at least remain consistent with how PBES2Parameters works today. > > - line 379: Since encyptionType is found using cipherAlgo and keysize > in the constructor, why can't we just format encryptionType.schemeName > as in getEncSchemeName()? > JN: Hmm...maybe we can do that.? Let me give it a try and see what happens. > > - line 419-422: Shouldn't this check be moved up to line 414, i.e. in > the block of code which handles the buggy encoding? Otherwise, it > looks like a duplicate check of line 400. > JN: I don't think so.? I think you need both.? On line 400, regardless of the structure (PBES2 AlgorithmIdentifier vs. PBES2-params) it must start with a sequence, so that check has to be there.? If it's out at the PBES2 AlgId layer (the error, which would manifest itself as an OID as the next object in the DerValue stream) then line 414 peels that away and what's next is your PBKDF2-params. Line 419 has to check if the next ASN.1 structure that sits as a peer to PBKDF2-params is also a sequence, which it has to be, therefore the check on the tag is performed before sending it in to be parsed. > - line 494, 630, 735: change the check to use KEYLEN_ANY? > JN: makes sense. > > -line 638: extra indentation? > JN: Yes, fixed. > > - line 725-752: Seems better to check the IV length before checking > and set the keysize. > JN: OK I can switch the order on those. > > - line 788: May return RC2_-1 or RC5_-1? > JN: Hmm...maybe in the DER parsing case, now that AlgorithmId/AlgorithmParameters handles the DER decoding I can't set the keysize as part of the parsing process any longer.? Let me take a closer look at it and get back to you on that one.? I think RC5 can fall into that trap, not sure about RC2. > > Will send you comments for the rest of webrev separately. > > Thanks, > > Valerie > > > > > > > > > > > > > > > > > > > > > > > > > || > > On 6/20/2019 6:59 PM, Jamil Nimeh wrote: >> Hello all, >> >> I've updated the fix to 8076999 with the following changes: >> >> * We now use sun.security.x509.AlgorithmId and it internally uses >> AlgorithmParameters implementations to handle the DER encoding >> and decoding of encryption scheme parameters. >> o This means that we need to add one new standard name and some >> OID aliases for some AlgorithmParameters.? See the CSR link >> below for details. >> * Added a new RC5Parameter AlgorithmParameters implementation to >> SunJCE, plus unit tests. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.02 >> >> >> On 5/24/2019 3:51 PM, Jamil Nimeh wrote: >>> >>> Hello all, happy Friday! >>> >>> Please review the following CSR and code review.? This makes updates >>> to the SunJCE implementation of PBES2-based AlgorithmParameters.? >>> Many of the details are in the CSR (see the link below).? But a >>> short list of the updates: >>> >>> * Add DER Encode/Decode support for the following OIDS from RFC 8018: >>> o PRFs: HmacSHA512/224, HmacSHA512/256 >>> o Encryption Schemes: AES-192-CBC, DES, Triple-DES, RC2, RC5 >>> * Enforce init-time type consistency between >>> AlgorithmParameterSpec objects and the algorithms they are used >>> with (i.e. No using RC5ParameterSpec with AES-128-CBC. >>> * Enforce sanity checks on AlgorithmParameterSpec objects used to >>> init (e.g. IV length checks, integer range checks, etc.) >>> * Fixed a bug where explicit DER decoding of the optional key >>> length field in PBKDF2-params would cause the PRF to be forced >>> to HmacSHA1 even if the DER indicated otherwise >>> * Allow incoming DER encoded AlgorithmIdentifier structures to >>> honor the OPTIONAL qualifier on the parameters field for both >>> PRFs and Encryption Schemes. >>> * If a null encryption scheme AlgorithmParameterSpec is provided >>> during init time, omit the PBES2-params.encryptionScheme's >>> parameter segment since it is OPTIONAL per the ASN.1 from RFC 5280 >>> >>> More details are in the CSR. >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.01/ >>> >>> --Jamil >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Jul 9 16:43:36 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 9 Jul 2019 09:43:36 -0700 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups Message-ID: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> Hi, Could I get the following update reviewed? webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.01/ CSR: https://bugs.openjdk.java.net/browse/JDK-8227445 During handshaking, the selection of signature algorithms was not checked with the algorithm constraints. Then the available signature algorithms may be ignored if a restricted algorithm get selected. The connection should be able to be established as there are available algorithms. Within this update, more algorithm constraints checking are introduced in the signature algorithms and named groups code. The significant changes are in NamedGroup.java and SignatureScheme.java, in order to introduce the checking and algorithm parameters and specs. Note that the following JDK 13 review thread was close out. https://mail.openjdk.java.net/pipermail/security-dev/2019-July/020348.html I targeted this enhancement to JDK 14, and come up with a CSR request. Thanks, Xuelei From stuart.marks at oracle.com Wed Jul 10 02:36:03 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 9 Jul 2019 19:36:03 -0700 Subject: RFR [14] JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: References: <49802280-ec4d-3944-6b84-6abbb0dca492@oracle.com> <1fff3f18-606b-8bb4-a409-09665af1911c@oracle.com> Message-ID: On 7/8/19 3:27 PM, Xuelei Fan wrote: > Thanks for looking into the update.? The "forRemoval=true" tag was added in > March 2010 (JDK-8160247).? It make sense to me to postpone the removal until JDK > 15. > > I re-targeted the RFE and CSR to JDK 15. March 2010?!? Oh, whew, that's just a typo, should be March 2019. :-) Thanks for re-targeting the RFE and CSR. s'marks From valerie.peng at oracle.com Wed Jul 10 02:44:42 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 9 Jul 2019 19:44:42 -0700 Subject: RFR 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working In-Reply-To: References: <6afc52c5-cf29-827a-0591-27714bcd6068@oracle.com> Message-ID: - line 174: considering add AES128/192/256 w/ CBC oids as they are used by both AlgorithmParameters and Cipher entries. - line 108 seems redundant? - line 131-132: why not simply: (iv.length != (blockSizeInBits >> 3)? - line 135: after checking iv.length, should we check for extra trailing bytes and error out if (val.data.available() > 0)? - line 191 encoder can be moved inside the block of iv-dumping code as it's only used there. - Can the tests be renamed? So it's clear that they are tests instead of some utility classes for test. - The ASN.1 encoding are generated offline using your changes? Just curious. Thanks, Valerie On 7/8/2019 4:50 PM, Valerie Peng wrote: > > Hi Jamil, > > Sorry for the late reply. It's been a long while since I looked at > this PBES2 scheme and I need to think a few things through. > > > > - line 29-30, 37, I don't see Constructor, BigInteger, and ArrayList > being used? > > - line 158: the pbes2AlgorithmNameis initialized to null. Is it our > intention to return null if toString() is called upon an PBES2 > AlgorithmParameters object without init(...) call? > > - line 176: does "keysize" means the optional keyLength field inside > the PBES2-params struct? Its value is from various sources. A proper > definition would help ensure its value is correctly set. > > - line 207: If encoding to a DerOutputStream, why not decode using a > DerInputStream? > > - line 203: based on RFC3370, 5911, the preferred way for HMAC is to > omit the parameters instead of encoding a NULL. So, we probably should > not encode a null on line 203. Also, for decode, line 520 to 522 can > be moved here so that the decode can handle both cases, i.e. omitted > and present NULL, for max compatibility. > > - line 295 - 298: if there is a comment on line 271 which explains > when "keyLen" is for, then we don't need this block of comment. > Essentially, keyLen holds that restricted key length value, right? > KEYLEN_ANY means no restriction whatsoever. > > - line 376: the impl of validateEncParams() seems to allow null > cipherParams as it returns immediately if its value is null. I am not > sure if we should allow null cipherParam though as this cipherParam > object is needed for encoding "encryptionScheme" field of the > PBES2-params struct. For example, if the parameters field for > AES_128_CBC must contain 16-byte IV, then a null cipherParams should > be rejected. Same goes to other encryption schemes. > > - line 379: Since encyptionType is found using cipherAlgo and keysize > in the constructor, why can't we just format encryptionType.schemeName > as in getEncSchemeName()? > > - line 419-422: Shouldn't this check be moved up to line 414, i.e. in > the block of code which handles the buggy encoding? Otherwise, it > looks like a duplicate check of line 400. > > - line 494, 630, 735: change the check to use KEYLEN_ANY? > > -line 638: extra indentation? > > - line 725-752: Seems better to check the IV length before checking > and set the keysize. > > - line 788: May return RC2_-1 or RC5_-1? > > Will send you comments for the rest of webrev separately. > > Thanks, > > Valerie > > > > > > > > > > > > > > > > > > > > > > > > > || > > On 6/20/2019 6:59 PM, Jamil Nimeh wrote: >> Hello all, >> >> I've updated the fix to 8076999 with the following changes: >> >> * We now use sun.security.x509.AlgorithmId and it internally uses >> AlgorithmParameters implementations to handle the DER encoding >> and decoding of encryption scheme parameters. >> o This means that we need to add one new standard name and some >> OID aliases for some AlgorithmParameters.? See the CSR link >> below for details. >> * Added a new RC5Parameter AlgorithmParameters implementation to >> SunJCE, plus unit tests. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.02 >> >> >> On 5/24/2019 3:51 PM, Jamil Nimeh wrote: >>> >>> Hello all, happy Friday! >>> >>> Please review the following CSR and code review.? This makes updates >>> to the SunJCE implementation of PBES2-based AlgorithmParameters.? >>> Many of the details are in the CSR (see the link below).? But a >>> short list of the updates: >>> >>> * Add DER Encode/Decode support for the following OIDS from RFC 8018: >>> o PRFs: HmacSHA512/224, HmacSHA512/256 >>> o Encryption Schemes: AES-192-CBC, DES, Triple-DES, RC2, RC5 >>> * Enforce init-time type consistency between >>> AlgorithmParameterSpec objects and the algorithms they are used >>> with (i.e. No using RC5ParameterSpec with AES-128-CBC. >>> * Enforce sanity checks on AlgorithmParameterSpec objects used to >>> init (e.g. IV length checks, integer range checks, etc.) >>> * Fixed a bug where explicit DER decoding of the optional key >>> length field in PBKDF2-params would cause the PRF to be forced >>> to HmacSHA1 even if the DER indicated otherwise >>> * Allow incoming DER encoded AlgorithmIdentifier structures to >>> honor the OPTIONAL qualifier on the parameters field for both >>> PRFs and Encryption Schemes. >>> * If a null encryption scheme AlgorithmParameterSpec is provided >>> during init time, omit the PBES2-params.encryptionScheme's >>> parameter segment since it is OPTIONAL per the ASN.1 from RFC 5280 >>> >>> More details are in the CSR. >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.01/ >>> >>> --Jamil >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Jul 10 03:02:51 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 9 Jul 2019 20:02:51 -0700 Subject: RFR[13] JDK-8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support In-Reply-To: References: <63fa1e24-f926-19a2-1eea-045a0843ff9d@oracle.com> <761FA3AA-164F-4CC7-94CC-0EED8B6EC350@oracle.com> <5954fdb9-e259-f8bb-3f75-64531825ab46@oracle.com> Message-ID: <0aced9da-fb09-b1f2-9c0b-40346a5d5104@oracle.com> Hmm, not sure why ECUtil discards the exception and returns null... I plan to add a check inside SignatureUtil to check for null and error out to make the EC case consistent with others. Rerunning mach5 now to double check. Thanks for noticing this. Valerie On 7/8/2019 7:45 PM, Weijun Wang wrote: > SignatureUtil::getParamSpec(String,byte[]): > > 126 paramSpec = ECUtil.getECParameterSpec(p, paramBytes); > > ECUtil.getECParameterSpec() could return null when "parameters.getParameterSpec(ECParameterSpec.class)" throws an InvalidParameterSpecException. So the behavior is now different from the other getParamSpec(String,AlgorithmParameters) method where the exception is wrapped into a ProviderException. Does this matter? > > Thanks, > Max > > >> On Jul 9, 2019, at 8:09 AM, Valerie Peng wrote: >> >> >> Here is the updated webrev w/ ECUtil.equals() utility method: >> >> http://cr.openjdk.java.net/~valeriep/8225745/webrev.01/ >> >> Regards, >> Valerie >> On 7/8/2019 12:12 PM, Valerie Peng wrote: >>> Right, based on the current impl, a simple "==" seems to work as it's the same NamedCurve instance inside CurveDB. Well, I could also do a bit of code refactoring and add an equals utility method to ECUtil so this may work better with 3rd party provider's impl. >>> >>> Thanks, >>> Valerie >>> On 7/2/2019 8:27 PM, Weijun Wang wrote: >>>> 368 private static boolean isCompatible(ECParameterSpec sigParams, >>>> 369 ECParameterSpec keyParams) { >>>> 370 if (sigParams == null) { >>>> 371 // no restriction on key param >>>> 372 return true; >>>> 373 } >>>> 374 return sigParams.equals(keyParams); >>>> 375 } >>>> >>>> What does "sigParams.equals(keyParams)" mean here? What is the getClass() of those 2 ECParameterSpec objects? >>>> >>>> Or maybe you mean "==" because it is always a NamedCurve stored in CurveDB? >>>> >>>> Thanks, >>>> Max >>>> >>>>> On Jul 3, 2019, at 10:48 AM, Valerie Peng wrote: >>>>> >>>>> Hi >>>>> >>>>> Any one can help reviewing this fix? Some ECDSA certificates contains signature algorithm identifiers with non-null parameter bytes. Before RSASSA-PSS support, these parameter bytes are ignored, however, after RSASSA-PSS support, the parameter bytes are passed to the underlying signature impl and this breaks the ECDSA certificate verification. In order for the verification to succeeds, the SignatureUtil class needs to be able to parse the parameter bytes for ECDSA certificate and that SunEC provider needs to accept non-null signature parameters. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225745 >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8225745/webrev.00/ >>>>> >>>>> Mach5 run is clean. >>>>> >>>>> Thanks, >>>>> Valerie From valerie.peng at oracle.com Wed Jul 10 03:59:48 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 9 Jul 2019 20:59:48 -0700 Subject: RFR 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working In-Reply-To: References: <6afc52c5-cf29-827a-0591-27714bcd6068@oracle.com> Message-ID: Hi Jamil, Please find replies inline below... On 7/9/2019 9:03 AM, Jamil Nimeh wrote: > Hi Valerie, thanks for the comments: > > On 7/8/2019 4:50 PM, Valerie Peng wrote: >> >> Hi Jamil, >> >> Sorry for the late reply. It's been a long while since I looked at >> this PBES2 scheme and I need to think a few things through. >> >> >> >> - line 29-30, 37, I don't see Constructor, BigInteger, and ArrayList >> being used? >> > JN: I must have removed them in my local copy of the code since I > posted the .02 webrev.? They'll be gone in this next webrev. >> >> - line 158: the pbes2AlgorithmNameis initialized to null. Is it our >> intention to return null if toString() is called upon an PBES2 >> AlgorithmParameters object without init(...) call? >> > JN: Hmm...that's a good question.? In the case of PBES2 alg params > with a fully qualified name (PBEWithAnd) the > pbes2AlgorithmName is initialized to whatever static class is > instantiated from SunJCE.java.? So we don't have to worry there. In > the case of actually using "PBES2" (or its OID counterpart, which is > more common), it looks like even before my changes it returned null.? > What do you think about returning "PBES2" instead?? Once it goes > through init the field will be set to whatever it truly is based on > the DER encoding received. Sure, PBES2 is way better than just null... >> - line 176: does "keysize" means the optional keyLength field inside >> the PBES2-params struct? Its value is from various sources. A proper >> definition would help ensure its value is correctly set. >> > JN: Well, keysize does mean that, but it affects the resulting > toString name and can also have an impact on init-time consistency > checks in some cases. > > Keysize is one of the challenging parts of this class, because it can > be defined in multiple ways.? It can be implicit (such as in DES or > DESede), it can be explicit by OID like it is for AES, and it can be > defined by parameters such as in RC2 - there is one OID, no matter > whether you do RC2_40, RC2_64 or RC2_128.? Or it can be not defined at > all (RC5) in which case you have to assume a reasonable default (like > I assume RC5_128) or hope that the KDF parameter segment asserts a key > length.? So it gets set in different parts of the code depending on > the algorithm and how it's specified. > > Maybe you can expand a bit on what you're looking for by "proper > definition" and I can try to make that happen. Well, one straightforward thought is to map "keysize" strictly based only on the optional keyLength field of the ASN.1 encoding. The keysize default value can be left to the particular cipher or key derivation impl. > >> - line 207: If encoding to a DerOutputStream, why not decode using a >> DerInputStream? >> > JN: There's no reason why it couldn't be done that way.? I used > DerValue mainly because decoding in PBES2Parameters has been done with > DerValue objects from before I started working with the code.? So I > kept it the same since it seemed to work well. DerInputStream makes more sense than DerValue as DerValue contains tag and length. Essentially you just want to get the data you want off the stream just like where you directly put out the bytes to the stream in decoding case. >> >> - line 203: based on RFC3370, 5911, the preferred way for HMAC is to >> omit the parameters instead of encoding a NULL. So, we probably >> should not encode a null on line 203. Also, for decode, line 520 to >> 522 can be moved here so that the decode can handle both cases, i.e. >> omitted and present NULL, for max compatibility. >> > JN: From all the OpenSSL parameter blocks I've looked at, Hmac params > will assert NULL.? There's some interesting history to > AlgorithmIdentifier's optional parameter field when there are no > parameters in RFC 4055, sec 2.1.? In short, a change happened in the > 1997 syntax that removed "optional" which was later fixed, but by then > people were getting around the now mandatory field by putting NULL in > there.? Honestly, I see NULLs asserted more commonly than it being > omitted for message digest and HMAC AlgorithmIdentifiers.? But that > might just be me.? According to 4055, omitting the parameters field is > the correct way to do it, you are correct about that.? Implementations > are supposed to accept both forms.? I stuck with it because a.) we > were already doing that and nobody was having problems with it, b.) I > see NULL asserted more frequently so it seemed like the safer way to go. > > I can try omitting it and see if openssl will accept it.? If it does > then I can make the change permanent.? If it doesn't like it, we > should probably leave the NULL in there.? I've got no idea how anyone > else encodes AlgorithmIdentifiers...maybe I can play around with NSS > and see what it does with Hmac parameters if I can find a tool that > will encode some. > Sure~ >> >> - line 295 - 298: if there is a comment on line 271 which explains >> when "keyLen" is for, then we don't need this block of comment. >> Essentially, keyLen holds that restricted key length value, right? >> KEYLEN_ANY means no restriction whatsoever. >> > JN: Or it can mean that the key length is implicit (e.g. DES is always > 56 bits, so I don't need to encode it in ASN.1 and I don't need > toString to say DES_56...DES is fine). > > Maybe rather than a comment on 271, maybe a similar description for > KEYLEN_ANY up on 154 might be a good way to go. >> >> - line 376: the impl of validateEncParams() seems to allow null >> cipherParams as it returns immediately if its value is null. I am not >> sure if we should allow null cipherParam though as this cipherParam >> object is needed for encoding "encryptionScheme" field of the >> PBES2-params struct. For example, if the parameters field for >> AES_128_CBC must contain 16-byte IV, then a null cipherParams should >> be rejected. Same goes to other encryption schemes. >> > JN: There are tests in the PKCS#12 family of tests that were breaking > when I strictly enforced non-null cipherParams from the > PBEParameterSpec.? I didn't want to risk messing up a use case in > PKCS#12-land that didn't apply directly to what I was fixing. What I > do need to do is have it fail on encoding when null parameters are > used, that will be in the next rev of the code.? I hate not being able > to fail-fast, but it would at least remain consistent with how > PBES2Parameters works today. Hmm, interesting, maybe PKCS#12 uses PBES2 as PBES1? Well, I don't know the history of all this. Given that we are in RPD1 phase already, I understand with the approach you chose. >> >> - line 379: Since encyptionType is found using cipherAlgo and keysize >> in the constructor, why can't we just format >> encryptionType.schemeName as in getEncSchemeName()? >> > JN: Hmm...maybe we can do that.? Let me give it a try and see what > happens. >> >> - line 419-422: Shouldn't this check be moved up to line 414, i.e. in >> the block of code which handles the buggy encoding? Otherwise, it >> looks like a duplicate check of line 400. >> > JN: I don't think so.? I think you need both.? On line 400, regardless > of the structure (PBES2 AlgorithmIdentifier vs. PBES2-params) it must > start with a sequence, so that check has to be there.? If it's out at > the PBES2 AlgId layer (the error, which would manifest itself as an > OID as the next object in the DerValue stream) then line 414 peels > that away and what's next is your PBKDF2-params. > > Line 419 has to check if the next ASN.1 structure that sits as a peer > to PBKDF2-params is also a sequence, which it has to be, therefore the > check on the tag is performed before sending it in to be parsed. > The DER code can be confusing... Let me re-phrase my comments and questions. Line 413, 414, I think we should check for SEQUENCE tag on the newly peeled "pBES2_params", agree? By calling data.getDerValue(), we are essentially peeling one layer off, right? If you still agree with me at this point, then note that pBES2_params is a local variable and its value should be the same unless explicitly re-assigned (as on line 413). Thus, per my reading of the code, the tag that you are checking on line 419 is not the one for encryption scheme, but rather the outer sequence tag encapsulating kdf and encryption scheme. Its current location is very misleading though, in between kdf and encryption scheme. To really check the tag for kdf and encryption scheme, the tag checking should be in parseKDF(...) and parseES(...) against the DerValue argument. Thanks, Valerie >> >> - line 494, 630, 735: change the check to use KEYLEN_ANY? >> > JN: makes sense. >> >> -line 638: extra indentation? >> > JN: Yes, fixed. >> >> - line 725-752: Seems better to check the IV length before checking >> and set the keysize. >> > JN: OK I can switch the order on those. >> >> - line 788: May return RC2_-1 or RC5_-1? >> > JN: Hmm...maybe in the DER parsing case, now that > AlgorithmId/AlgorithmParameters handles the DER decoding I can't set > the keysize as part of the parsing process any longer.? Let me take a > closer look at it and get back to you on that one.? I think RC5 can > fall into that trap, not sure about RC2. >> >> Will send you comments for the rest of webrev separately. >> >> Thanks, >> >> Valerie >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> || >> >> On 6/20/2019 6:59 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> I've updated the fix to 8076999 with the following changes: >>> >>> * We now use sun.security.x509.AlgorithmId and it internally uses >>> AlgorithmParameters implementations to handle the DER encoding >>> and decoding of encryption scheme parameters. >>> o This means that we need to add one new standard name and >>> some OID aliases for some AlgorithmParameters.? See the CSR >>> link below for details. >>> * Added a new RC5Parameter AlgorithmParameters implementation to >>> SunJCE, plus unit tests. >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.02 >>> >>> >>> On 5/24/2019 3:51 PM, Jamil Nimeh wrote: >>>> >>>> Hello all, happy Friday! >>>> >>>> Please review the following CSR and code review.? This makes >>>> updates to the SunJCE implementation of PBES2-based >>>> AlgorithmParameters.? Many of the details are in the CSR (see the >>>> link below).? But a short list of the updates: >>>> >>>> * Add DER Encode/Decode support for the following OIDS from RFC 8018: >>>> o PRFs: HmacSHA512/224, HmacSHA512/256 >>>> o Encryption Schemes: AES-192-CBC, DES, Triple-DES, RC2, RC5 >>>> * Enforce init-time type consistency between >>>> AlgorithmParameterSpec objects and the algorithms they are used >>>> with (i.e. No using RC5ParameterSpec with AES-128-CBC. >>>> * Enforce sanity checks on AlgorithmParameterSpec objects used to >>>> init (e.g. IV length checks, integer range checks, etc.) >>>> * Fixed a bug where explicit DER decoding of the optional key >>>> length field in PBKDF2-params would cause the PRF to be forced >>>> to HmacSHA1 even if the DER indicated otherwise >>>> * Allow incoming DER encoded AlgorithmIdentifier structures to >>>> honor the OPTIONAL qualifier on the parameters field for both >>>> PRFs and Encryption Schemes. >>>> * If a null encryption scheme AlgorithmParameterSpec is provided >>>> during init time, omit the PBES2-params.encryptionScheme's >>>> parameter segment since it is OPTIONAL per the ASN.1 from RFC 5280 >>>> >>>> More details are in the CSR. >>>> >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.01/ >>>> >>>> --Jamil >>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Jul 10 04:09:54 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 9 Jul 2019 21:09:54 -0700 Subject: RFR [14] JDK-8227024 : Remove the deprecated javax.security.cert APIs In-Reply-To: References: <49802280-ec4d-3944-6b84-6abbb0dca492@oracle.com> <1fff3f18-606b-8bb4-a409-09665af1911c@oracle.com> Message-ID: On 7/9/2019 7:36 PM, Stuart Marks wrote: > On 7/8/19 3:27 PM, Xuelei Fan wrote: >> Thanks for looking into the update.? The "forRemoval=true" tag was >> added in March 2010 (JDK-8160247).? It make sense to me to postpone >> the removal until JDK 15. >> >> I re-targeted the RFE and CSR to JDK 15. > > March 2010?!? Oh, whew, that's just a typo, should be March 2019. :-) > ;-) 2019, a typo. Xuelei From valerie.peng at oracle.com Wed Jul 10 04:12:22 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 9 Jul 2019 21:12:22 -0700 Subject: RFR[13] JDK-8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support In-Reply-To: <0aced9da-fb09-b1f2-9c0b-40346a5d5104@oracle.com> References: <63fa1e24-f926-19a2-1eea-045a0843ff9d@oracle.com> <761FA3AA-164F-4CC7-94CC-0EED8B6EC350@oracle.com> <5954fdb9-e259-f8bb-3f75-64531825ab46@oracle.com> <0aced9da-fb09-b1f2-9c0b-40346a5d5104@oracle.com> Message-ID: http://cr.openjdk.java.net/~valeriep/8225745/webrev.02/ On 7/9/2019 8:02 PM, Valerie Peng wrote: > Hmm, not sure why ECUtil discards the exception and returns null... > > I plan to add a check inside SignatureUtil to check for null and error > out to make the EC case consistent with others. Rerunning mach5 now to > double check. > > Thanks for noticing this. > Valerie > On 7/8/2019 7:45 PM, Weijun Wang wrote: >> SignatureUtil::getParamSpec(String,byte[]): >> >> ? 126???????????????????? paramSpec = ECUtil.getECParameterSpec(p, >> paramBytes); >> >> ECUtil.getECParameterSpec() could return null when >> "parameters.getParameterSpec(ECParameterSpec.class)" throws an >> InvalidParameterSpecException. So the behavior is now different from >> the other getParamSpec(String,AlgorithmParameters) method where the >> exception is wrapped into a ProviderException. Does this matter? >> >> Thanks, >> Max >> >> >>> On Jul 9, 2019, at 8:09 AM, Valerie Peng >>> wrote: >>> >>> >>> Here is the updated webrev w/ ECUtil.equals() utility method: >>> >>> http://cr.openjdk.java.net/~valeriep/8225745/webrev.01/ >>> >>> Regards, >>> Valerie >>> On 7/8/2019 12:12 PM, Valerie Peng wrote: >>>> Right, based on the current impl, a simple "==" seems to work as >>>> it's the same NamedCurve instance inside CurveDB. Well, I could >>>> also do a bit of code refactoring and add an equals utility method >>>> to ECUtil so this may work better with 3rd party provider's impl. >>>> >>>> Thanks, >>>> Valerie >>>> On 7/2/2019 8:27 PM, Weijun Wang wrote: >>>>> ?? 368???? private static boolean isCompatible(ECParameterSpec >>>>> sigParams, >>>>> ?? 369???????????? ECParameterSpec keyParams) { >>>>> ?? 370???????? if (sigParams == null) { >>>>> ?? 371???????????? // no restriction on key param >>>>> ?? 372???????????? return true; >>>>> ?? 373???????? } >>>>> ?? 374???????? return sigParams.equals(keyParams); >>>>> ?? 375???? } >>>>> >>>>> What does "sigParams.equals(keyParams)" mean here? What is the >>>>> getClass() of those 2 ECParameterSpec objects? >>>>> >>>>> Or maybe you mean "==" because it is always a NamedCurve stored in >>>>> CurveDB? >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> On Jul 3, 2019, at 10:48 AM, Valerie Peng >>>>>> wrote: >>>>>> >>>>>> Hi >>>>>> >>>>>> Any one can help reviewing this fix? Some ECDSA certificates >>>>>> contains signature algorithm identifiers with non-null parameter >>>>>> bytes. Before RSASSA-PSS support, these parameter bytes are >>>>>> ignored, however, after RSASSA-PSS support, the parameter bytes >>>>>> are passed to the underlying signature impl and this breaks the >>>>>> ECDSA certificate verification. In order for the verification to >>>>>> succeeds, the SignatureUtil class needs to be able to parse the >>>>>> parameter bytes for ECDSA certificate and that SunEC provider >>>>>> needs to accept non-null signature parameters. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225745 >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8225745/webrev.00/ >>>>>> >>>>>> Mach5 run is clean. >>>>>> >>>>>> Thanks, >>>>>> Valerie From weijun.wang at oracle.com Wed Jul 10 10:12:33 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Jul 2019 18:12:33 +0800 Subject: RFR[13] JDK-8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support In-Reply-To: References: <63fa1e24-f926-19a2-1eea-045a0843ff9d@oracle.com> <761FA3AA-164F-4CC7-94CC-0EED8B6EC350@oracle.com> <5954fdb9-e259-f8bb-3f75-64531825ab46@oracle.com> <0aced9da-fb09-b1f2-9c0b-40346a5d5104@oracle.com> Message-ID: <888F7C22-CF48-4605-8D54-219EBF06F0F1@oracle.com> The change looks fine to me. Thanks, Max > On Jul 10, 2019, at 12:12 PM, Valerie Peng wrote: > > http://cr.openjdk.java.net/~valeriep/8225745/webrev.02/ From anthony.scarpino at oracle.com Wed Jul 10 14:57:33 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 10 Jul 2019 07:57:33 -0700 Subject: RFR 8227530: Session Resumption without Server-Side State off by default Message-ID: <145f4dda-d500-6f6b-6145-ec166cd7af0a@oracle.com> Hi Can I have a CSR review of this very simple change to turn stateless session resumption off by default https://bugs.openjdk.java.net/browse/JDK-8227530 Tony From xuelei.fan at oracle.com Wed Jul 10 15:18:39 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 10 Jul 2019 08:18:39 -0700 Subject: RFR 8227530: Session Resumption without Server-Side State off by default In-Reply-To: <145f4dda-d500-6f6b-6145-ec166cd7af0a@oracle.com> References: <145f4dda-d500-6f6b-6145-ec166cd7af0a@oracle.com> Message-ID: <1e6f87f1-16e8-3931-b9f4-625c79436c9e@oracle.com> I may move the content under the "Specification" section to the "Solution" section, as it is about the implementation details. Not a big concern of mine. You can leave it as-is. I added myself as the reviewer. Thanks, Xuelei On 7/10/2019 7:57 AM, Anthony Scarpino wrote: > Hi > > Can I have a CSR review of this very simple change to turn stateless > session resumption off by default > > https://bugs.openjdk.java.net/browse/JDK-8227530 > > Tony From sean.mullan at oracle.com Wed Jul 10 15:29:50 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 Jul 2019 11:29:50 -0400 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> Message-ID: <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> I think we should modify the description of the jdk.tls.disabledAlgorithms property to state that named groups can also be restricted. For example: diff -r a7b9d6d4940e src/java.base/share/conf/security/java.security --- a/src/java.base/share/conf/security/java.security Thu Jun 20 09:35:41 2019 -0700 +++ b/src/java.base/share/conf/security/java.security Wed Jul 10 11:21:32 2019 -0400 @@ -678,7 +678,7 @@ # when using SSL/TLS/DTLS. This section describes the mechanism for disabling # algorithms during SSL/TLS/DTLS security parameters negotiation, including # protocol version negotiation, cipher suites selection, peer authentication -# and key exchange mechanisms. +# and key exchange mechanisms, and named groups. # # Disabled algorithms will not be negotiated for SSL/TLS connections, even # if they are enabled explicitly in an application. This should also be in the CSR. Also, in the CSR you list all the different signature algorithms that could be disabled, but you use the TLS names, and not the standard JCE names. I found this a bit confusing, since if you added those exact TLS names to jdk.tls.disabledAlgorithms, I don't think it will work, or if it does we need additional changes to the jdk.tls.disabledAlgorithms definition - and maybe that is what we should do? Also, I don't think it is possible to disable individual RSASSA-PSS algorithms, I think you can just disable all or none of them because the parameters are specified separately and not part of the standard JCE name. Similar to other algorithms - how would I just disable ecdsa_secp256r1_sha256 and nothing else? Is that an issue? Thanks, Sean On 7/9/19 12:43 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.01/ > CSR:??? https://bugs.openjdk.java.net/browse/JDK-8227445 > > During handshaking, the selection of signature algorithms was not > checked with the algorithm constraints.? Then the available signature > algorithms may be ignored if a restricted algorithm get selected.? The > connection should be able to be established as there are available > algorithms. > > Within this update, more algorithm constraints checking are introduced > in the signature algorithms and named groups code. > > The significant changes are in NamedGroup.java and SignatureScheme.java, > in order to introduce the checking and algorithm parameters and specs. > > Note that the following JDK 13 review thread was close out. > > https://mail.openjdk.java.net/pipermail/security-dev/2019-July/020348.html > > I targeted this enhancement to JDK 14, and come up with a CSR request. > > Thanks, > Xuelei From anthony.scarpino at oracle.com Wed Jul 10 15:52:55 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 10 Jul 2019 08:52:55 -0700 Subject: RFR 8227530: Session Resumption without Server-Side State off by default In-Reply-To: <1e6f87f1-16e8-3931-b9f4-625c79436c9e@oracle.com> References: <145f4dda-d500-6f6b-6145-ec166cd7af0a@oracle.com> <1e6f87f1-16e8-3931-b9f4-625c79436c9e@oracle.com> Message-ID: <32ec5a20-e694-5c95-fba2-c85588594613@oracle.com> Given the section descriptions say the Solution is an overview and the Specification is code, I'd prefer to leave it as is. If you can set yourself as review, I will propose it. thanks Tony On 7/10/19 8:18 AM, Xuelei Fan wrote: > I may move the content under the "Specification" section to the > "Solution" section, as it is about the implementation details.? Not a > big concern of mine.? You can leave it as-is. I added myself as the > reviewer. > > Thanks, > Xuelei > > On 7/10/2019 7:57 AM, Anthony Scarpino wrote: >> Hi >> >> Can I have a CSR review of this very simple change to turn stateless >> session resumption off by default >> >> https://bugs.openjdk.java.net/browse/JDK-8227530 >> >> Tony From sean.mullan at oracle.com Wed Jul 10 17:58:28 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 Jul 2019 13:58:28 -0400 Subject: RFR 8227530: Session Resumption without Server-Side State off by default In-Reply-To: <32ec5a20-e694-5c95-fba2-c85588594613@oracle.com> References: <145f4dda-d500-6f6b-6145-ec166cd7af0a@oracle.com> <1e6f87f1-16e8-3931-b9f4-625c79436c9e@oracle.com> <32ec5a20-e694-5c95-fba2-c85588594613@oracle.com> Message-ID: <73cc7843-5f1c-ae78-af8a-12b6f87ebb4b@oracle.com> Tony, I think we should leave stateless on for JDK 14 (or the main JDK repo) since that way we will continue to get more testing on it. If you push this to 13, it will be automatically pushed to JDK 14 which would change that default. Check with the gatekeeper to make an exception for this so it won't be forward-ported (contact me directly for more info). --Sean On 7/10/19 11:52 AM, Anthony Scarpino wrote: > Given the section descriptions say the Solution is an overview and the > Specification is code, I'd prefer to leave it as is. > > If you can set yourself as review, I will propose it. > > thanks > > Tony > > On 7/10/19 8:18 AM, Xuelei Fan wrote: >> I may move the content under the "Specification" section to the >> "Solution" section, as it is about the implementation details.? Not a >> big concern of mine.? You can leave it as-is. I added myself as the >> reviewer. >> >> Thanks, >> Xuelei >> >> On 7/10/2019 7:57 AM, Anthony Scarpino wrote: >>> Hi >>> >>> Can I have a CSR review of this very simple change to turn stateless >>> session resumption off by default >>> >>> https://bugs.openjdk.java.net/browse/JDK-8227530 >>> >>> Tony > From xuelei.fan at oracle.com Thu Jul 11 15:56:45 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 11 Jul 2019 08:56:45 -0700 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> Message-ID: <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> On 7/10/2019 8:29 AM, Sean Mullan wrote: > I think we should modify the description of the > jdk.tls.disabledAlgorithms property to state that named groups can also > be restricted. For example: > > diff -r a7b9d6d4940e src/java.base/share/conf/security/java.security > --- a/src/java.base/share/conf/security/java.security?? Thu Jun 20 > 09:35:41 2019 -0700 > +++ b/src/java.base/share/conf/security/java.security?? Wed Jul 10 > 11:21:32 2019 -0400 > @@ -678,7 +678,7 @@ > ?# when using SSL/TLS/DTLS.? This section describes the mechanism for > disabling > ?# algorithms during SSL/TLS/DTLS security parameters negotiation, > including > ?# protocol version negotiation, cipher suites selection, peer > authentication > -# and key exchange mechanisms. > +# and key exchange mechanisms, and named groups. > ?# > ?# Disabled algorithms will not be negotiated for SSL/TLS connections, > even > ?# if they are enabled explicitly in an application. > > This should also be in the CSR. > I updated CSR for the java.security update. > Also, in the CSR you list all the different signature algorithms that > could be disabled, but you use the TLS names, and not the standard JCE > names. I found this a bit confusing, since if you added those exact TLS > names to jdk.tls.disabledAlgorithms, I don't think it will work, or if > it does we need additional changes to the jdk.tls.disabledAlgorithms > definition - and maybe that is what we should do?? Also, I don't think > it is possible to disable individual RSASSA-PSS algorithms, I think you > can just disable all or none of them because the parameters are > specified separately and not part of the standard JCE name. Similar to > other algorithms - how would I just disable ecdsa_secp256r1_sha256 and > nothing else? Is that an issue? > Yes, it is an issue now. The AlgorithmConstraints is able to accept parameters, but the current jdk.tls.disabledAlgorithms property cannot. That's also why I used the TLS names (ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256, etc) rather than standard names (SHA256withECDSA, RSASSA-PSS). I agree with you that it is confusing. The use of rsa_pss_rsae_sha256 may be fine, but the name "dsa_sha256" rather then "SHA256withDSA" could be confusing. I was planned to add TLS signature algorithms into the standard names, as we will do for the named groups. But it looks like a duplicate of the crypto Signature algorithms. It is an option to support crypto Signature algorithm with the specific parameters, for example "SHA256withECDSAofSECP256R1", "SHA256withRSASSA-PSS". I don't like it as a provider need to enum all known parameters. Maybe, we can introduce something new in jdk.tls.disabledAlgorithms. For example, "signature_algorithm with parameters" ("SHA256withECDSA with Secp256R1", "RSASSA-PSS with SHA256"). However, it does not sound generic or simple. We may want to introduce new system property or APIs to customize the signature algorithms of TLS connections. Using the TLS signature algorithms is an acceptable option to me, but it is far from satisfied because the duplication with the crypto Signature algorithm. Let's discuss the issue more. Any feedback are welcome! Thanks, Xuelei > Thanks, > Sean > > > On 7/9/19 12:43 PM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> >> webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.01/ >> CSR:??? https://bugs.openjdk.java.net/browse/JDK-8227445 >> >> During handshaking, the selection of signature algorithms was not >> checked with the algorithm constraints.? Then the available signature >> algorithms may be ignored if a restricted algorithm get selected.? The >> connection should be able to be established as there are available >> algorithms. >> >> Within this update, more algorithm constraints checking are introduced >> in the signature algorithms and named groups code. >> >> The significant changes are in NamedGroup.java and >> SignatureScheme.java, in order to introduce the checking and algorithm >> parameters and specs. >> >> Note that the following JDK 13 review thread was close out. >> >> https://mail.openjdk.java.net/pipermail/security-dev/2019-July/020348.html >> >> >> I targeted this enhancement to JDK 14, and come up with a CSR request. >> >> Thanks, >> Xuelei From christoph.langer at sap.com Thu Jul 11 21:08:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 11 Jul 2019 21:08:14 +0000 Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange In-Reply-To: References: Message-ID: Ping... would somebody please eyeball this backport? No regressions seen in testing... Thanks Christoph From: Langer, Christoph Sent: Donnerstag, 4. Juli 2019 15:11 To: jdk-updates-dev at openjdk.java.net Cc: security-dev Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange Hi, please help reviewing the backport of JDK-8216039 to jdk11u-dev. Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates, some manual work is necessary. In src/java.base/share/classes/java/security/Signature.java and src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports of jdk.internal.access have to be changed into jdk.internal.misc. The update that originally went to src/java.base/share/classes/jdk/internal/access/SharedSecrets.java obviously needs to be applied to src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new file src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java needs to be src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java in 11u. See the full webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/ The webrev for manual changes only: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/ Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039 Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jul 11 21:11:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 11 Jul 2019 21:11:46 +0000 Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange In-Reply-To: References: Message-ID: Ping... Can somebody please have a look at this backport? Regression testing shows no problems... Thanks Christoph From: Langer, Christoph Sent: Donnerstag, 4. Juli 2019 15:11 To: jdk-updates-dev at openjdk.java.net Cc: security-dev Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange Hi, please help reviewing the backport of JDK-8216039 to jdk11u-dev. Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates, some manual work is necessary. In src/java.base/share/classes/java/security/Signature.java and src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports of jdk.internal.access have to be changed into jdk.internal.misc. The update that originally went to src/java.base/share/classes/jdk/internal/access/SharedSecrets.java obviously needs to be applied to src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new file src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java needs to be src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java in 11u. See the full webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/ The webrev for manual changes only: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/ Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039 Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jul 12 12:24:18 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 Jul 2019 08:24:18 -0400 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> Message-ID: On 7/11/19 11:56 AM, Xuelei Fan wrote: >> Also, in the CSR you list all the different signature algorithms that >> could be disabled, but you use the TLS names, and not the standard JCE >> names. I found this a bit confusing, since if you added those exact >> TLS names to jdk.tls.disabledAlgorithms, I don't think it will work, >> or if it does we need additional changes to the >> jdk.tls.disabledAlgorithms definition - and maybe that is what we >> should do?? Also, I don't think it is possible to disable individual >> RSASSA-PSS algorithms, I think you can just disable all or none of >> them because the parameters are specified separately and not part of >> the standard JCE name. Similar to other algorithms - how would I just >> disable ecdsa_secp256r1_sha256 and nothing else? Is that an issue? >> > Yes, it is an issue now.? The AlgorithmConstraints is able to accept > parameters, but the current jdk.tls.disabledAlgorithms property cannot. > That's also why I used the TLS names (ecdsa_secp256r1_sha256, > rsa_pss_rsae_sha256, etc) rather than standard names (SHA256withECDSA, > RSASSA-PSS). > > I agree with you that it is confusing.? The use of rsa_pss_rsae_sha256 > may be fine, but the name "dsa_sha256" rather then "SHA256withDSA" could > be confusing. > > I was planned to add TLS signature algorithms into the standard names, > as we will do for the named groups.? But it looks like a duplicate of > the crypto Signature algorithms. I would lean towards this option. We could extend the jdk.tls.disabledAlgorithms property to allow you to specify TLS signature schemes as defined in https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme We would also need to add a section to the Standard Names specification listing these schemes. The reason I like this option is because it fits well with the TLS namespace, and it is more flexible than the JCE names and we can more easily restrict new TLS signature schemes that are defined later. --Sean > > It is an option to support crypto Signature algorithm with the specific > parameters, for example "SHA256withECDSAofSECP256R1", > "SHA256withRSASSA-PSS".? I don't like it as a provider need to enum all > known parameters. > > Maybe, we can introduce something new in jdk.tls.disabledAlgorithms. For > example, "signature_algorithm with parameters" ("SHA256withECDSA with > Secp256R1", "RSASSA-PSS with SHA256").? However, it does not sound > generic or simple. > > We may want to introduce new system property or APIs to customize the > signature algorithms of TLS connections.? Using the TLS signature > algorithms is an acceptable option to me, but it is far from satisfied > because the duplication with the crypto Signature algorithm. > > Let's discuss the issue more.? Any feedback are welcome! > > Thanks, > Xuelei > >> Thanks, >> Sean >> >> >> On 7/9/19 12:43 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Could I get the following update reviewed? >>> >>> webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.01/ >>> CSR:??? https://bugs.openjdk.java.net/browse/JDK-8227445 >>> >>> During handshaking, the selection of signature algorithms was not >>> checked with the algorithm constraints.? Then the available signature >>> algorithms may be ignored if a restricted algorithm get selected. >>> The connection should be able to be established as there are >>> available algorithms. >>> >>> Within this update, more algorithm constraints checking are >>> introduced in the signature algorithms and named groups code. >>> >>> The significant changes are in NamedGroup.java and >>> SignatureScheme.java, in order to introduce the checking and >>> algorithm parameters and specs. >>> >>> Note that the following JDK 13 review thread was close out. >>> >>> https://mail.openjdk.java.net/pipermail/security-dev/2019-July/020348.html >>> >>> >>> I targeted this enhancement to JDK 14, and come up with a CSR request. >>> >>> Thanks, >>> Xuelei From xuelei.fan at oracle.com Fri Jul 12 16:14:33 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 12 Jul 2019 09:14:33 -0700 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> Message-ID: On 7/12/2019 5:24 AM, Sean Mullan wrote: > On 7/11/19 11:56 AM, Xuelei Fan wrote: > >>> Also, in the CSR you list all the different signature algorithms that >>> could be disabled, but you use the TLS names, and not the standard >>> JCE names. I found this a bit confusing, since if you added those >>> exact TLS names to jdk.tls.disabledAlgorithms, I don't think it will >>> work, or if it does we need additional changes to the >>> jdk.tls.disabledAlgorithms definition - and maybe that is what we >>> should do?? Also, I don't think it is possible to disable individual >>> RSASSA-PSS algorithms, I think you can just disable all or none of >>> them because the parameters are specified separately and not part of >>> the standard JCE name. Similar to other algorithms - how would I just >>> disable ecdsa_secp256r1_sha256 and nothing else? Is that an issue? >>> >> Yes, it is an issue now.? The AlgorithmConstraints is able to accept >> parameters, but the current jdk.tls.disabledAlgorithms property >> cannot. That's also why I used the TLS names (ecdsa_secp256r1_sha256, >> rsa_pss_rsae_sha256, etc) rather than standard names (SHA256withECDSA, >> RSASSA-PSS). >> >> I agree with you that it is confusing.? The use of rsa_pss_rsae_sha256 >> may be fine, but the name "dsa_sha256" rather then "SHA256withDSA" >> could be confusing. >> >> I was planned to add TLS signature algorithms into the standard names, >> as we will do for the named groups.? But it looks like a duplicate of >> the crypto Signature algorithms. > > I would lean towards this option. We could extend the > jdk.tls.disabledAlgorithms property to allow you to specify TLS > signature schemes as defined in > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme > > > We would also need to add a section to the Standard Names specification > listing these schemes. > > The reason I like this option is because it fits well with the TLS > namespace, and it is more flexible than the JCE names and we can more > easily restrict new TLS signature schemes that are defined later. I agreed that is is more straightforward. Okay, let's go with option. Between file a new enhancement for Standard Names documentation or update the doc this time, do you have a preference? Maybe, we can update the doc together with JDKJDK-8210755? https://bugs.openjdk.java.net/browse/JDK-8210755 Thanks, Xuelei From hohensee at amazon.com Mon Jul 1 15:36:59 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 1 Jul 2019 15:36:59 +0000 Subject: [11u]: RFR: Backport of 8215694: keytool cannot generate RSASSA-PSS certificates In-Reply-To: References: <63478A16-049F-4B16-A76C-4B1BB6AFF6F5@amazon.com> Message-ID: Yes. Thanks, Paul. ?On 7/1/19, 7:26 AM, "Langer, Christoph" wrote: Hi Paul, thanks for your review. > In CertAndKeyGen.java, does generate() need a throws declaration? It doesn't. IllegalArgumentException is a RuntimeException and as such doesn't need a throws declaration. And InvalidKeyException is obviously not needed and was removed in the original changeset as well. > Otherwise looks good. Thanks. I also asked Max Wang to have a look off list and he seems to agree as well. > We've been talking about backporting patches with CSRs and have done at > least one. Imo, 8076190 and 8213400 are good backport candidates since the > spec changes are minor. Yes, a CSR is not necessarily a showstopper for a backport. But as it is not my area of expertise and there's no other reason that makes backports of these bugs important to me, I don't want to take the additional work and responsibility for these backports. But feel free to do this ? So, I guess I'm good to push this, once approved. Cheers, Christoph From hohensee at amazon.com Thu Jul 11 23:44:10 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Jul 2019 23:44:10 +0000 Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange In-Reply-To: References: Message-ID: <22D9906C-9FD2-4525-9C41-393431A96682@amazon.com> Looks good. Paul ?On 7/11/19, 2:14 PM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Ping... Can somebody please have a look at this backport? Regression testing shows no problems... Thanks Christoph From: Langer, Christoph Sent: Donnerstag, 4. Juli 2019 15:11 To: jdk-updates-dev at openjdk.java.net Cc: security-dev Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange Hi, please help reviewing the backport of JDK-8216039 to jdk11u-dev. Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates, some manual work is necessary. In src/java.base/share/classes/java/security/Signature.java and src/java.base/share/classes/sun/security/util/SignatureUtil.java the imports of jdk.internal.access have to be changed into jdk.internal.misc. The update that originally went to src/java.base/share/classes/jdk/internal/access/SharedSecrets.java obviously needs to be applied to src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java. The new file src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java needs to be src/java.base/share/classes/jdk/internal/misc/JavaSecuritySignatureAccess.java in 11u. See the full webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.full.0/ The webrev for manual changes only: http://cr.openjdk.java.net/~clanger/webrevs/8216039.11u.manual.0/ Original Bug: https://bugs.openjdk.java.net/browse/JDK-8216039 Thanks Christoph From vladimir.kozlov at oracle.com Mon Jul 15 16:30:14 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Jul 2019 09:30:14 -0700 Subject: RFR: 8227615: [TESTBUG] Fix jtreg "jdk/sun/security/util/FilePermCompat/CompatImpact.java" failing with graal issue. In-Reply-To: References: Message-ID: <2a08e281-0f6f-d993-8213-c62f3e573559@oracle.com> Good. Thanks, Vladimir On 7/15/19 2:32 AM, Xiaohong Gong (Arm Technology China) wrote: > Hi, > > Please help to review this small patch: > Webrev: http://cr.openjdk.java.net/~pli/rfr/8227615/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8227615 > > Jtreg test "jdk/sun/security/util/FilePermCompat/CompatImpact.java" fails due to access denied to JVMCI runtime with graal mode. > This patch fixes the permission issue by making the application's own policy extending the default system policy. Besides it also fixes > the stderr file couldn't be found issue by renaming the file name to the right one. > > Thanks, > Xiaohong Gong > From anthony.scarpino at oracle.com Mon Jul 15 23:04:54 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 15 Jul 2019 16:04:54 -0700 Subject: RFR 8226338: Updates to Stateless Resumption In-Reply-To: <03e711c6-25d2-78b2-a3f9-8ff5a2461094@oracle.com> References: <8d314691-0ca5-307e-41a1-e6ba731abacb@oracle.com> <3f693817-9d34-f237-61e3-c73da0daedd9@oracle.com> <03e711c6-25d2-78b2-a3f9-8ff5a2461094@oracle.com> Message-ID: I've updated the webrev http://cr.openjdk.java.net/~ascarpino/8226338/webrev.01/ As I need to push this by wednesday, please review it soon. There are fixes for the comments that were made, added a NST for boundVaules, a very basic test to make sure the post handshake NST is sent after boundValues have changed. There is no change to invalidate() as these is not enough time to address that. Tony On 7/7/19 9:14 PM, Anthony Scarpino wrote: > On 7/4/19 10:14 PM, Xuelei Fan wrote: >> SSLSessionImpl.java >> ------------------- >> ??526???? boolean checkSessionTicket(HandshakeContext hc) { >> As the return value is a boolean type, the method is better to use >> "isSomething".? Otherwise, the meaning of the code >> "!checkSessionTicket()" is clear and need to read the implementation >> code. > > I'll see if I can come up with a "is*" name > >> >> NewSessionTicket.java >> --------------------- >> ??104???? //???? opaque ticket<1..2^16-1>; >> ??108???? if (m.remaining() < 6) { >> >> Per section 3.3, RFC 5077, line 104 should be: >> ????????? opaque ticket<0..2^16-1>; > > I'm glad you saw that because it was confusing me why a zero buffer was > allowed in 5077 > >> >> To be better understand the number 6, as you are already there, would >> you please update line 104 as well? >> >> I did not get the idea of the update of >> T13NewSessionTicketMessage.T13NewSessionTicketMessage().? It looks >> like that the updated code does not comply to TLS 1.3 specification of >> NewSessionTicket. >> > > So I assume you are talking about the zero length ticket.? I never > noticed that 1.3 changed behavior away from zero length tickets.? It > would appear the spec writings made every attempt to make NST usage > confusing between versions. > >> >> ??453???????????? NewSessionTicketMessage nstm; >> ??454???????????? nstm = new T12NewSessionTicketMessage(shc, >> sessionTimeoutSeconds, >> >> Maybe better to use one statement. >> ??453???????????? NewSessionTicketMessage nstm = >> ??454????????????????????? new T12NewSessionTicketMessage(shc, >> sessionTimeoutSeconds, >> >> ??499???????????? if (nstm.ticket.length == 0) { >> Empty ticket should be not allowed in TLS 1.3 > >> ServerHelloDone.java >> -------------------- >> ??110???????????? if (shc.statelessResumption) { >> ??111 shc.handshakeConsumers.put(SSLHandshake.NEW_SESSION_TICKET.id, >> ??112???????????????????????? SSLHandshake.NEW_SESSION_TICKET); >> ??113???????????? } >> >> I think the NewSessionTicket is produced by server and consumed in >> client side.? I did not get the idea to have NST consumer in server >> side.? Am I missing something? >> > > Hmm.. I remember making this change, and I thought it was a good idea, > but clearly it does nothing. > >> SessionTicketExtension.java >> --------------------------- >> ??260???????????? if (!hc.handshakeSession.checkSessionTicket(hc)) { >> ??261???????????????? return new byte[0]; >> ??262???????????? } >> >> ?From the above line, I guess why you use empty ticket for TLS 1.3, >> although empty ticket is not allowed in TLS 1.3. >> >> I may suggest never use empty ticket.? Always use a proper ticket in a >> proper NewSessionTicket message, at least in format.? When there is a >> problem to retrieve the values, cache the session and prefer to use >> the case rather than the ticket for session resumption.?? As may be a >> little bit more interop friendly. > > Yes, the 1.3 non-zero length sure complicates the code.. Very unfortunate. > >> >> ??295???????????????? if (SSLLogger.isOn && >> SSLLogger.isOn("ssl,handshake")) { >> ??296???????????????????? SSLLogger.fine("Encryption failed." + >> e.getMessage()); >> ??297???????????????????? e.printStackTrace(); // Helps with >> session.write() >> ??298???????????????? } >> >> Line 297 does not use SSLLogger.? It could be: >> ????????? SSLLogger.fine("Encryption failed", e); > > I didn't noticed logger accepted exceptions. > >> >> On 7/2/2019 10:35 AM, Anthony Scarpino wrote: >>> >>> Hi, >>> >>> I need a code review on some updates to the stateless resumption. >>> 1) Changing peerSupportedSignAlgs from a String[] to Collection[] >>> 2) Additional items added to the stateless ticket >>> 3) Not provide a stateless ticket when the masterkey is not >>> accessible (FIPS) or when boundValues are used >> I did not whether the update works if bound values are set after the >> handshake completed (i.e., after the NewSessionTicket has been >> produced and used).? Did you have a test for the case? > > It was my understanding from previous discussions that we were going to > take a wait and see approach with boundValues and NST. > > When I took a glance at how boundValues were added, they appear to be > outside of the normal flow of the ConnectionContext. > >> >> Thanks, >> Xuelei >> >>> 4) Be more graceful in case of stateless ticket generation failure >>> >>> http://cr.openjdk.java.net/~ascarpino/8226338/webrev.00/ >>> >>> Tony > From anthony.scarpino at oracle.com Mon Jul 15 23:10:29 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 15 Jul 2019 16:10:29 -0700 Subject: RFR[13] Release Note for Stateless Resumption In-Reply-To: References: <85f91eb3-a937-fb3c-b9a4-edc273d970f5@oracle.com> <7c1e654f-2731-dbf0-7fe3-60d79a045f56@oracle.com> <337f3412-5b47-39cc-aec7-2d9bfd29c022@oracle.com> Message-ID: <16ad0bfd-0267-296d-0f15-a192a5803ca2@oracle.com> On 7/8/19 10:00 AM, Xuelei Fan wrote: > On 7/8/2019 9:06 AM, Anthony Scarpino wrote: >> On 7/8/19 8:30 AM, Xuelei Fan wrote: >>> Hi, >>> >>> A couple of comments. >>> >>> In the release note, "For TLS 1.3, stateless tickets use the existing >>> PSK resumption extension in RFC 8446[2]. TLS 1.3 will revert to the >>> session cache if the server property is false. " >>> >>> In CSR, "For TLS 1.3, stateless tickets use the existing PSK >>> resumption extension in (RFC 8446), which require no properties or >>> settings." >>> >>> The above two parts of information are not consistent. >> >> Correct, however, while 1.3 uses the existing ticekt mechanism for >> stateless and stateful without a property setting.? However the >> contents of that ticket do depend on the property. >> > I think for TLS 1.3, the contents of the ticket should be independent > from the property.? The property names > "jdk.tls.server.enableSessionTicketExtension" and > "jdk.tls.client.enableSessionTicketExtension" are about the ST > extension.? TLS 1.3 session resumption uses a different mechanism. > > I may missed something.? Why you think the content of the ticket > depending on the property? > > Thanks, > Xuelei The release notes have been changed and to reflect the planned not enabled by default state. Tony From mbalao at redhat.com Tue Jul 16 00:47:36 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 15 Jul 2019 21:47:36 -0300 Subject: RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found Message-ID: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> Hi, I'd like to propose the following fix for JDK-8227437 [1] (*): * http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.00/ JDK-8227437 bug appeared after the OpenJDK Kerberos client supported RFC-6806 [2]. When requesting a TGT (ticket-granting-ticket), there may be client name canonicalization and/or realm referrals. When requesting a TGS (ticket-granting-service), there may be realm referrals. As a result, the client or service names we use to request a ticket may be different than those we get in the returned ticket. I.e.: we may use the subject principal "subject at REALM-1.COM" as a client name to request a TGT and get a ticket whose client name is "subject-canonical at REALM-2.COM". Even though the ticket credentials belong to the subject, we are unable to locate them based on the client or service names when there is a change. In the previous example, we will use "subject at REALM-1.COM" subject principal as a client name to find the ticket but the actual ticket has a "subject-canonical at REALM-2.COM" client name. To fix this problem, we now save the original client and service names as "alias" fields in Credentials and KerberosTicket objects (if there is a change). This allows to find subject credentials properly. Note: client and service alias information is not populated (saved or retrieved) across credentials caches: file-based-caches [3][4], Windows native cache or macOS native cache. As a result, the client name must match the subject principal for the credential to be found (see Credentials::acquireTGTFromCache). If the credential is not found, a request to the KDC may be issued. Testing: * ReferralsTest extended to cover this bug * Regression testing on jdk/sun/security/krb5 passed * Tested in my local Windows 2016 referrals environment Look forward to your comments. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8227437 [2] - https://bugs.openjdk.java.net/browse/JDK-8215032 [3] - https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html [4] - https://web.mit.edu/kerberos/krb5-devel/doc/formats/ccache_file_format.html (*) - we have worked together with Max (@weijun) during the last week to come up with this version. From weijun.wang at oracle.com Tue Jul 16 01:21:16 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Jul 2019 09:21:16 +0800 Subject: RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found In-Reply-To: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> References: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> Message-ID: <5106D27F-4C7E-491E-81BF-E2C8395E752A@oracle.com> Hi Martin, There is only one place I don't quite understand. In SubjectComber::findAux, you have 151 while (iterator.hasNext()) { 152 Object obj = iterator.next(); 153 if (obj instanceof KerberosTicket) { 155 KerberosTicket ticket = (KerberosTicket)obj; 164 if (!ticket.isCurrent()) { ... 186 } else { ... 195 KerberosPrincipal clientAlias = KerberosSecrets 196 .getJavaxSecurityAuthKerberosAccess() 197 .kerberosTicketGetClientAlias(ticket); 198 if (clientPrincipal == null || 199 clientPrincipal.equals( 200 ticket.getClient().getName()) || 201 (clientAlias != null && 202 clientPrincipal.equals( 203 clientAlias.getName()))) { ... 207 // Record names so that tickets will 208 // all belong to same principals 209 if (clientPrincipal == null) { 210 if (clientAlias == null) { 211 clientPrincipal = 212 ticket.getClient().getName(); 213 } else { 214 clientPrincipal = 215 clientAlias.getName(); 216 } 217 } ... 227 answer.add(credClass.cast(ticket)); 228 } 229 } 230 } 231 } 232 } 233 } Suppose we have 2 tickets: client1(clientAlias1) -> ... client1 -> ... // I don't know why this one has no alias and clientPrincipal is null at the beginning. Now, when the 1st ticket is checked, the if check on lines 198-203 will succeed, and clientPrincipal is assigned clientAlias1 on line 214. Next, when the 2nd ticket is checked, because it has no alias and client1 != clientPrincipal (now clientAlias1), it will not be added. Is this intended? Why not simply assign ticket.getClient().getName() to clientPrincipal? Thanks, Max > On Jul 16, 2019, at 8:47 AM, Martin Balao wrote: > > Hi, > > I'd like to propose the following fix for JDK-8227437 [1] (*): > > * http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.00/ > > JDK-8227437 bug appeared after the OpenJDK Kerberos client supported > RFC-6806 [2]. > > When requesting a TGT (ticket-granting-ticket), there may be client name > canonicalization and/or realm referrals. When requesting a TGS > (ticket-granting-service), there may be realm referrals. As a result, > the client or service names we use to request a ticket may be different > than those we get in the returned ticket. I.e.: we may use the subject > principal "subject at REALM-1.COM" as a client name to request a TGT and > get a ticket whose client name is "subject-canonical at REALM-2.COM". > > Even though the ticket credentials belong to the subject, we are unable > to locate them based on the client or service names when there is a > change. In the previous example, we will use "subject at REALM-1.COM" > subject principal as a client name to find the ticket but the actual > ticket has a "subject-canonical at REALM-2.COM" client name. > > To fix this problem, we now save the original client and service names > as "alias" fields in Credentials and KerberosTicket objects (if there is > a change). This allows to find subject credentials properly. > > Note: client and service alias information is not populated (saved or > retrieved) across credentials caches: file-based-caches [3][4], Windows > native cache or macOS native cache. As a result, the client name must > match the subject principal for the credential to be found (see > Credentials::acquireTGTFromCache). If the credential is not found, a > request to the KDC may be issued. > > Testing: > > * ReferralsTest extended to cover this bug > > * Regression testing on jdk/sun/security/krb5 passed > > * Tested in my local Windows 2016 referrals environment > > Look forward to your comments. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8227437 > [2] - https://bugs.openjdk.java.net/browse/JDK-8215032 > [3] - https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html > [4] - > https://web.mit.edu/kerberos/krb5-devel/doc/formats/ccache_file_format.html > > (*) - we have worked together with Max (@weijun) during the last week to > come up with this version. From weijun.wang at oracle.com Tue Jul 16 02:16:07 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Jul 2019 10:16:07 +0800 Subject: RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found In-Reply-To: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> References: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> Message-ID: <944810B3-053D-48B4-AB55-81D55F35D55E@oracle.com> Another thing. Although we later found out more issues with the name change, this bug was originally filed on S4U2proxy, so I suggest we add a test for this purpose. This can demonstrated with private static void JAAS() throws Exception { Context c = Context.fromUserPass("normal", password, false); c.startAsClient("andrew", GSSUtil.GSS_KRB5_MECH_OID); Context s = Context.fromUserPass("drew", password, true); s.startAsServer(GSSUtil.GSS_KRB5_MECH_OID); Context.handshake(c, s); s.delegated(); } Here the principals are added as kdc1.addPrincipal("normal", password); kdc1.addPrincipal("andrew", password); kdc1.registerAlias("drew", "andrew@" + realmKDC1); You can surely use your existing names/aliases. Note: I cannot call 'c.startAsClient("drew", GSSUtil.GSS_KRB5_MECH_OID)' above because KDC.java does not support aliases in getPassword(). We can enhance this later if useful. Thanks, Max > On Jul 16, 2019, at 8:47 AM, Martin Balao wrote: > > http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.00/ From xuelei.fan at oracle.com Tue Jul 16 02:50:42 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 15 Jul 2019 19:50:42 -0700 Subject: RFR 8226338: Updates to Stateless Resumption In-Reply-To: References: <8d314691-0ca5-307e-41a1-e6ba731abacb@oracle.com> <3f693817-9d34-f237-61e3-c73da0daedd9@oracle.com> <03e711c6-25d2-78b2-a3f9-8ff5a2461094@oracle.com> Message-ID: > http://cr.openjdk.java.net/~ascarpino/8226338/webrev.01/ NewSessionTicket.java --------------------- - 189 if (m.remaining() < 14) { + 189 if (m.remaining() < 9) { I did not get the point of this update. I think 14 should be fine so that to fail earlier if no sufficient data. 317 public byte[] produce(ConnectionContext context) ... 324 public byte[] produce(ServerHandshakeContext shc) ... 433 public byte[] produce(PostHandshakeContext hc) ... I did not get the point to use three methods here. Read more inlines, please. On 7/15/2019 4:04 PM, Anthony Scarpino wrote: > I've updated the webrev > > http://cr.openjdk.java.net/~ascarpino/8226338/webrev.01/ > > As I need to push this by wednesday, please review it soon. > > There are fixes for the comments that were made, added a NST for > boundVaules, a very basic test to make sure the post handshake NST is > sent after boundValues have changed. > Did you mean send a new NST of the boundValues is changed? What if the previous NST was used for resumption? Thanks, Xuelei > There is no change to invalidate() as these is not enough time to > address that. > > Tony > > On 7/7/19 9:14 PM, Anthony Scarpino wrote: >> On 7/4/19 10:14 PM, Xuelei Fan wrote: >>> SSLSessionImpl.java >>> ------------------- >>> ??526???? boolean checkSessionTicket(HandshakeContext hc) { >>> As the return value is a boolean type, the method is better to use >>> "isSomething".? Otherwise, the meaning of the code >>> "!checkSessionTicket()" is clear and need to read the implementation >>> code. >> >> I'll see if I can come up with a "is*" name >> >>> >>> NewSessionTicket.java >>> --------------------- >>> ??104???? //???? opaque ticket<1..2^16-1>; >>> ??108???? if (m.remaining() < 6) { >>> >>> Per section 3.3, RFC 5077, line 104 should be: >>> ????????? opaque ticket<0..2^16-1>; >> >> I'm glad you saw that because it was confusing me why a zero buffer >> was allowed in 5077 >> >>> >>> To be better understand the number 6, as you are already there, would >>> you please update line 104 as well? >>> >>> I did not get the idea of the update of >>> T13NewSessionTicketMessage.T13NewSessionTicketMessage().? It looks >>> like that the updated code does not comply to TLS 1.3 specification >>> of NewSessionTicket. >>> >> >> So I assume you are talking about the zero length ticket.? I never >> noticed that 1.3 changed behavior away from zero length tickets.? It >> would appear the spec writings made every attempt to make NST usage >> confusing between versions. >> >>> >>> ??453???????????? NewSessionTicketMessage nstm; >>> ??454???????????? nstm = new T12NewSessionTicketMessage(shc, >>> sessionTimeoutSeconds, >>> >>> Maybe better to use one statement. >>> ??453???????????? NewSessionTicketMessage nstm = >>> ??454????????????????????? new T12NewSessionTicketMessage(shc, >>> sessionTimeoutSeconds, >>> >>> ??499???????????? if (nstm.ticket.length == 0) { >>> Empty ticket should be not allowed in TLS 1.3 > >>> ServerHelloDone.java >>> -------------------- >>> ??110???????????? if (shc.statelessResumption) { >>> ??111 shc.handshakeConsumers.put(SSLHandshake.NEW_SESSION_TICKET.id, >>> ??112???????????????????????? SSLHandshake.NEW_SESSION_TICKET); >>> ??113???????????? } >>> >>> I think the NewSessionTicket is produced by server and consumed in >>> client side.? I did not get the idea to have NST consumer in server >>> side.? Am I missing something? >>> >> >> Hmm.. I remember making this change, and I thought it was a good idea, >> but clearly it does nothing. >> >>> SessionTicketExtension.java >>> --------------------------- >>> ??260???????????? if (!hc.handshakeSession.checkSessionTicket(hc)) { >>> ??261???????????????? return new byte[0]; >>> ??262???????????? } >>> >>> ?From the above line, I guess why you use empty ticket for TLS 1.3, >>> although empty ticket is not allowed in TLS 1.3. >>> >>> I may suggest never use empty ticket.? Always use a proper ticket in >>> a proper NewSessionTicket message, at least in format.? When there is >>> a problem to retrieve the values, cache the session and prefer to use >>> the case rather than the ticket for session resumption.?? As may be a >>> little bit more interop friendly. >> >> Yes, the 1.3 non-zero length sure complicates the code.. Very >> unfortunate. >> >>> >>> ??295???????????????? if (SSLLogger.isOn && >>> SSLLogger.isOn("ssl,handshake")) { >>> ??296???????????????????? SSLLogger.fine("Encryption failed." + >>> e.getMessage()); >>> ??297???????????????????? e.printStackTrace(); // Helps with >>> session.write() >>> ??298???????????????? } >>> >>> Line 297 does not use SSLLogger.? It could be: >>> ????????? SSLLogger.fine("Encryption failed", e); >> >> I didn't noticed logger accepted exceptions. >> >>> >>> On 7/2/2019 10:35 AM, Anthony Scarpino wrote: >>>> >>>> Hi, >>>> >>>> I need a code review on some updates to the stateless resumption. >>>> 1) Changing peerSupportedSignAlgs from a String[] to Collection[] >>>> 2) Additional items added to the stateless ticket >>>> 3) Not provide a stateless ticket when the masterkey is not >>>> accessible (FIPS) or when boundValues are used >>> I did not whether the update works if bound values are set after the >>> handshake completed (i.e., after the NewSessionTicket has been >>> produced and used).? Did you have a test for the case? >> >> It was my understanding from previous discussions that we were going >> to take a wait and see approach with boundValues and NST. >> >> When I took a glance at how boundValues were added, they appear to be >> outside of the normal flow of the ConnectionContext. >> >>> >>> Thanks, >>> Xuelei >>> >>>> 4) Be more graceful in case of stateless ticket generation failure >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8226338/webrev.00/ >>>> >>>> Tony >> > From anthony.scarpino at oracle.com Tue Jul 16 04:00:10 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 15 Jul 2019 21:00:10 -0700 Subject: RFR 8226338: Updates to Stateless Resumption In-Reply-To: References: <8d314691-0ca5-307e-41a1-e6ba731abacb@oracle.com> <3f693817-9d34-f237-61e3-c73da0daedd9@oracle.com> <03e711c6-25d2-78b2-a3f9-8ff5a2461094@oracle.com> Message-ID: On 7/15/19 7:50 PM, Xuelei Fan wrote: > > http://cr.openjdk.java.net/~ascarpino/8226338/webrev.01/ > > NewSessionTicket.java > --------------------- > -??? 189??? if (m.remaining() < 14) { > +??? 189??? if (m.remaining() < 9) { > > I did not get the point of this update.? I think 14 should be fine so > that to fail earlier if no sufficient data. > I will revert it. I'm not going to argue with you about this.. I thought it might have provided better debugging. > > ?317 public byte[] produce(ConnectionContext context) ... > ?324 public byte[] produce(ServerHandshakeContext shc) ... > ?433 public byte[] produce(PostHandshakeContext hc) ... > > I did not get the point to use three methods here.? Read more inlines, > please. I had decided to separate them because I want multiple instanceOf checks, but will merge them. > > On 7/15/2019 4:04 PM, Anthony Scarpino wrote: >> I've updated the webrev >> >> http://cr.openjdk.java.net/~ascarpino/8226338/webrev.01/ >> >> As I need to push this by wednesday, please review it soon. >> >> There are fixes for the comments that were made, added a NST for >> boundVaules, a very basic test to make sure the post handshake NST is >> sent after boundValues have changed. >> > Did you mean send a new NST of the boundValues is changed?? What if the > previous NST was used for resumption? Yes. It is up to the client to manage which NST it uses. If you want some mechanism of keeping track tickets. It will have to go into 14. Update: http://cr.openjdk.java.net/~ascarpino/8226338/webrev.02/ Tony From xuelei.fan at oracle.com Tue Jul 16 04:41:11 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 15 Jul 2019 21:41:11 -0700 Subject: RFR 8226338: Updates to Stateless Resumption In-Reply-To: References: <8d314691-0ca5-307e-41a1-e6ba731abacb@oracle.com> <3f693817-9d34-f237-61e3-c73da0daedd9@oracle.com> <03e711c6-25d2-78b2-a3f9-8ff5a2461094@oracle.com> Message-ID: > I will revert it. I'm not going to argue with you about this.. I thought > it might have provided better debugging. > >> >> ??317 public byte[] produce(ConnectionContext context) ... >> ??324 public byte[] produce(ServerHandshakeContext shc) ... >> ??433 public byte[] produce(PostHandshakeContext hc) ... >> >> I did not get the point to use three methods here.? Read more inlines, >> please. > > I had decided to separate them because I want multiple instanceOf > checks, but will merge them. > Not a concern of mine to separate them if necessary. I thought it is related to the following bound values issue and did not get the idea. >> >> On 7/15/2019 4:04 PM, Anthony Scarpino wrote: >>> I've updated the webrev >>> >>> http://cr.openjdk.java.net/~ascarpino/8226338/webrev.01/ >>> >>> As I need to push this by wednesday, please review it soon. >>> >>> There are fixes for the comments that were made, added a NST for >>> boundVaules, a very basic test to make sure the post handshake NST is >>> sent after boundValues have changed. >>> >> Did you mean send a new NST of the boundValues is changed?? What if >> the previous NST was used for resumption? > > Yes.? It is up to the client to manage which NST it uses.? If you want > some mechanism of keeping track tickets.? It will have to go into 14. > Sorry for the confusing. I did not mean to keeping track to tickets. For TLS 1.2, I think the current update does not solve the boundVaules issue, right? I see these lines in SSLSessionImpl.java. 1363 if (protocolVersion.useTLS13PlusSpec()) { 1364 updateNST = true; 1365 } which limit the scope to TLS 1.3+ versions only. Why sending a new NST solves the bound values problem? I did not find the code that restores the bound values set after the handshaking in session resumption. The bound values are still missed if using stateless ticket, right? I may miss something. Xuelei > Update: > http://cr.openjdk.java.net/~ascarpino/8226338/webrev.02/ > > Tony From weijun.wang at oracle.com Wed Jul 17 00:32:48 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Jul 2019 08:32:48 +0800 Subject: [13] RFR 8227595: keytool/fakegen/DefaultSignatureAlgorithm.java fails due to "exitValue = 6" Message-ID: <75C94E6E-D4B0-4C3B-ACE2-F1FD41C86A2A@oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8227595 The test cannot use the included fake keypair generator because on Solaris the SunPKCS11-Solaris is more preferred. Like what I have done [1] for the PSS.java test nearby, exclude the test from Solaris as well. I've also taken this chance to add a clarification on why the fake generator does not help here. Please review the patch below. Thanks, Max diff --git a/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java b/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java --- a/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java +++ b/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java @@ -23,16 +23,21 @@ /* * @test - * @bug 8138766 8227059 + * @bug 8138766 8227059 8227595 * @summary New default -sigalg for keytool * @library /test/lib * @build java.base/sun.security.rsa.RSAKeyPairGenerator * java.base/sun.security.provider.DSAKeyPairGenerator * jdk.crypto.ec/sun.security.ec.ECKeyPairGenerator + * @requires os.family != "solaris" * @run main DefaultSignatureAlgorithm * @modules jdk.crypto.ec */ +// This test is excluded from Solaris because the RSA key pair generator +// is extremely slow there with a big keysize. Please note the fake +// KeyPairGenerator will not be used because of provider preferences. + import jdk.test.lib.Asserts; import jdk.test.lib.SecurityTools; import jdk.test.lib.process.OutputAnalyzer; diff --git a/test/jdk/sun/security/tools/keytool/fakegen/PSS.java b/test/jdk/sun/security/tools/keytool/fakegen/PSS.java --- a/test/jdk/sun/security/tools/keytool/fakegen/PSS.java +++ b/test/jdk/sun/security/tools/keytool/fakegen/PSS.java @@ -34,7 +34,8 @@ */ // This test is excluded from Solaris because the 8192-bit RSA key pair -// generator is extremely slow there. +// generator is extremely slow there. Please note the fake +// KeyPairGenerator will not be used because of provider preferences. import jdk.test.lib.Asserts; import jdk.test.lib.SecurityTools; [1] http://hg.openjdk.java.net/jdk/jdk/rev/271ee240244c -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbalao at redhat.com Wed Jul 17 02:19:29 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 16 Jul 2019 23:19:29 -0300 Subject: RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found In-Reply-To: <944810B3-053D-48B4-AB55-81D55F35D55E@oracle.com> References: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> <944810B3-053D-48B4-AB55-81D55F35D55E@oracle.com> Message-ID: <1fb04033-cfca-251e-31b4-f704443b69f1@redhat.com> Hi Max, Thanks for your feedback. Here we have webrev.01: http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.01/ I've done the following changes: * Extended ReferralsTest to test credentials delegation (through CredentialsUtil::acquireS4U2proxyCreds) * See this change in ReferralsTest.java * KDC enhanced to allow referrals when CNAME_IN_ADDL_TKT flag is set * ReferralsTest uses this new feature * See this change in KDC.java * Fixed a bug in referral TGTs Credentials (no server alias should be there) * See this change in KrbTgsRep.java * Fixed a bug in ReferralsCache * cache was not per client principal (we were returning referral tickets issued for different clients) * See this change in CredentialsUtil.java and ReferralsCache.java * Fixed a bug in Krb5LoginModule * If we get a TGT from a ccache, that TGT will not have client alias and its cname may be different than the subject principal. If we commit this ticket in the subject private credentials, we will not find it. * My proposal is to force the subject principal as an alias if: cname differs from the subject principal AND there is no client alias. * See this change in Krb5LoginModule.java -- In regards to SubjectComber::findAux, I understand your concerns but cannot figure out how that situation would be possible. I'll try to explain my reasoning as detailed as possible and why I believe the client alias (if there is one) is a better choice there. Let's say we have a Subject called "client1", whose principal is "client1 at REALM-1.COM". This Subject has 2 KerberosTicket private credentials: 1) TGT cname: client1-canonical at REALM-1.COM, clientAlias: client1 at REALM-1.COM 2) TGT cname: client1 at REALM-1.COM, clientAlias: null We want to retrieve all tickets for this Subject so we call SubjectComber::find with clientPrincipal == null. As you said, ticket #1 is retrieved after check in line 198 (clientPrincipal == null). Now, clientPrincipal will be equal to "client1 at REALM-1.COM" because of the assignment in line 214 (clientPrincipal = clientAlias.getName();). In the second iteration, we will get the ticket #2 because clientPrincipal (client1 at REALM-1.COM) matches the ticket cname (client1 at REALM-1.COM). If we do "clientPrincipal = ticket.getClient().getName()" in line 214, clientPrincipal would be client1-canonical at REALM-1.COM and we will not get ticket #2 (whose cname is client1 at REALM-1.COM). Why did I assume that ticket #2 has a "client1 at REALM-1.COM" cname and not something different? cname may be anything BUT if it were different than the subject principal (client1 at REALM-1.COM), then it must have an alias and we will get it through the alias. My reasoning is that we should track all the tickets to the subject principal (either because their cname matches the subject principal or because we set an alias). If someone forces a ticket without an alias and without a cname that matches the subject principal, we will not retrieve it... but that's because the invariant is broken. We may also broke the invariant in the same way by adding a ticket with a cname different than ticket.getClient().getName(). Thanks, Martin.- From anthony.scarpino at oracle.com Wed Jul 17 03:12:49 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 16 Jul 2019 20:12:49 -0700 Subject: RFR[13]: 8227551 Session Resumption without Server-Side State off by default Message-ID: Please review the change to set stateless session resumption off default http://cr.openjdk.java.net/~ascarpino/8227551/webrev/ Thanks Tony From weijun.wang at oracle.com Wed Jul 17 03:23:49 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Jul 2019 11:23:49 +0800 Subject: RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found In-Reply-To: <1fb04033-cfca-251e-31b4-f704443b69f1@redhat.com> References: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> <944810B3-053D-48B4-AB55-81D55F35D55E@oracle.com> <1fb04033-cfca-251e-31b4-f704443b69f1@redhat.com> Message-ID: Krb5Context.java and Krb5LoginModule.java: There is no need to set the aliases, already done inside Krb5Util.credsToTicket(serviceCreds). The case in Krb5LoginModule.java is more complicated, due to your change in webrev.01. See below. > > * Fixed a bug in referral TGTs Credentials (no server alias should be > there) > * See this change in KrbTgsRep.java But this is not harmful, right? The referral TGTs are not stored in a Subject and its alias is not used. > * Fixed a bug in Krb5LoginModule > * If we get a TGT from a ccache, that TGT will not have client alias > and its cname may be different than the subject principal. If we commit > this ticket in the subject private credentials, we will not find it. > * My proposal is to force the subject principal as an alias if: cname > differs from the subject principal AND there is no client alias. > * See this change in Krb5LoginModule.java KerberosPrincipal kClient = new KerberosPrincipal( cred.getClient().getName()); if (!princSet.contains(kClient)) { kClientAlias = kClient; } Looks like this ticket's name and alias will be the same? Is this useful? > > -- > > In regards to SubjectComber::findAux, I understand your concerns but > cannot figure out how that situation would be possible. I'll try to > explain my reasoning as detailed as possible and why I believe the > client alias (if there is one) is a better choice there. > > Let's say we have a Subject called "client1", whose principal is > "client1 at REALM-1.COM". This Subject has 2 KerberosTicket private > credentials: > > 1) TGT cname: client1-canonical at REALM-1.COM, clientAlias: > client1 at REALM-1.COM > > 2) TGT cname: client1 at REALM-1.COM, clientAlias: null > > We want to retrieve all tickets for this Subject so we call > SubjectComber::find with clientPrincipal == null. > > As you said, ticket #1 is retrieved after check in line 198 > (clientPrincipal == null). Now, clientPrincipal will be equal to > "client1 at REALM-1.COM" because of the assignment in line 214 > (clientPrincipal = clientAlias.getName();). > > In the second iteration, we will get the ticket #2 because > clientPrincipal (client1 at REALM-1.COM) matches the ticket cname > (client1 at REALM-1.COM). > > If we do "clientPrincipal = ticket.getClient().getName()" in line 214, > clientPrincipal would be client1-canonical at REALM-1.COM and we will not > get ticket #2 (whose cname is client1 at REALM-1.COM). > > Why did I assume that ticket #2 has a "client1 at REALM-1.COM" cname and > not something different? cname may be anything BUT if it were different > than the subject principal (client1 at REALM-1.COM), then it must have an > alias and we will get it through the alias. OK, this is how I understand it. With the current implementation, yes it always has an alias. Or, if CANONICALIZE is not set (who knows why), then there will be no alias and the alias is the name. If so, then you are correct. Thanks, Max > > My reasoning is that we should track all the tickets to the subject > principal (either because their cname matches the subject principal or > because we set an alias). > > If someone forces a ticket without an alias and without a cname that > matches the subject principal, we will not retrieve it... but that's > because the invariant is broken. We may also broke the invariant in the > same way by adding a ticket with a cname different than > ticket.getClient().getName(). > > Thanks, > Martin.- From sha.jiang at oracle.com Wed Jul 17 03:43:57 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 17 Jul 2019 11:43:57 +0800 Subject: RFR[13]: 8227551 Session Resumption without Server-Side State off by default In-Reply-To: References: Message-ID: <7679722e-a0ec-56c2-5625-08719aac8048@oracle.com> Hi Tony, Just a minor comment. ?242???????????? if (st.compareToIgnoreCase("true") == 0) { ?243???????????????? statelessSession = true; ?244???????????? } Could it simply use the below statement? statelessSession = st.equalsIgnoreCase("true"); Best regards, John Jiang On 2019/7/17 11:12, Anthony Scarpino wrote: > Please review the change to set stateless session resumption off default > > http://cr.openjdk.java.net/~ascarpino/8227551/webrev/ > > Thanks > > Tony > From mbalao at redhat.com Wed Jul 17 06:58:57 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 17 Jul 2019 03:58:57 -0300 Subject: RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found In-Reply-To: References: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> <944810B3-053D-48B4-AB55-81D55F35D55E@oracle.com> <1fb04033-cfca-251e-31b4-f704443b69f1@redhat.com> Message-ID: <340a2b06-8ab0-bb4d-d3c7-e3f51d1542c3@redhat.com> Hi Max, Webrev.02 is ready: http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.02/ On 7/17/19 12:23 AM, Weijun Wang wrote: > Krb5Context.java and Krb5LoginModule.java: > > There is no need to set the aliases, already done inside Krb5Util.credsToTicket(serviceCreds). The case in Krb5LoginModule.java is more complicated, due to your change in webrev.01. See below. > Duplicated alias set removed from Krb5Context.java. Thanks. In regards to Krb5LoginModule.java, I made a mistake when generating Webrev.01 (my idea was to set a client alias equal to "principal"). However, I decided to remove it for Webrev.02. When we retrieve the ticket from the cache, we use either "principal" or null (but then we assign "principal" to whatever cname the ticket has). As a result, the ticket cname will match "principal" and setting it as an alias adds nothing. Sorry for the noise here. >> >> * Fixed a bug in referral TGTs Credentials (no server alias should be >> there) >> * See this change in KrbTgsRep.java > > But this is not harmful, right? The referral TGTs are not stored in a Subject and its alias is not used. Right. Not harmful but not correct. Found it a bit confusing when debugging. As you said, referral TGTs are not stored. > >> * Fixed a bug in Krb5LoginModule >> * If we get a TGT from a ccache, that TGT will not have client alias >> and its cname may be different than the subject principal. If we commit >> this ticket in the subject private credentials, we will not find it. >> * My proposal is to force the subject principal as an alias if: cname >> differs from the subject principal AND there is no client alias. >> * See this change in Krb5LoginModule.java > > KerberosPrincipal kClient = new KerberosPrincipal( > cred.getClient().getName()); > if (!princSet.contains(kClient)) { > kClientAlias = kClient; > } > > Looks like this ticket's name and alias will be the same? Is this useful? > Removed. See above. > > Or, if CANONICALIZE is not set (who knows why), then there will be no alias and the alias is the name. Yes, if we send no CANONICALIZE (i.e.: because of the fallback scheme), we will have no client alias but the ticket cname will then be equal to the subject (kerberos) principal. Regression testing in jdk/sun/security/krb5 category passed. Are we good to go with Webrev.02? Thanks, Martin.- From weijun.wang at oracle.com Wed Jul 17 07:30:56 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 17 Jul 2019 15:30:56 +0800 Subject: RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found In-Reply-To: <340a2b06-8ab0-bb4d-d3c7-e3f51d1542c3@redhat.com> References: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> <944810B3-053D-48B4-AB55-81D55F35D55E@oracle.com> <1fb04033-cfca-251e-31b4-f704443b69f1@redhat.com> <340a2b06-8ab0-bb4d-d3c7-e3f51d1542c3@redhat.com> Message-ID: There is still a kerberosTicketSetClientAlias() call in Krb5LoginModule.java. Otherwise looks fine. I'll run some internal test now. Thanks, Max > On Jul 17, 2019, at 2:58 PM, Martin Balao wrote: > > Hi Max, > > Webrev.02 is ready: > http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.02/ > > On 7/17/19 12:23 AM, Weijun Wang wrote: >> Krb5Context.java and Krb5LoginModule.java: >> >> There is no need to set the aliases, already done inside Krb5Util.credsToTicket(serviceCreds). The case in Krb5LoginModule.java is more complicated, due to your change in webrev.01. See below. >> > > Duplicated alias set removed from Krb5Context.java. Thanks. > > In regards to Krb5LoginModule.java, I made a mistake when generating > Webrev.01 (my idea was to set a client alias equal to "principal"). > However, I decided to remove it for Webrev.02. When we retrieve the > ticket from the cache, we use either "principal" or null (but then we > assign "principal" to whatever cname the ticket has). As a result, the > ticket cname will match "principal" and setting it as an alias adds > nothing. Sorry for the noise here. > >>> >>> * Fixed a bug in referral TGTs Credentials (no server alias should be >>> there) >>> * See this change in KrbTgsRep.java >> >> But this is not harmful, right? The referral TGTs are not stored in a Subject and its alias is not used. > > Right. Not harmful but not correct. Found it a bit confusing when > debugging. As you said, referral TGTs are not stored. > >> >>> * Fixed a bug in Krb5LoginModule >>> * If we get a TGT from a ccache, that TGT will not have client alias >>> and its cname may be different than the subject principal. If we commit >>> this ticket in the subject private credentials, we will not find it. >>> * My proposal is to force the subject principal as an alias if: cname >>> differs from the subject principal AND there is no client alias. >>> * See this change in Krb5LoginModule.java >> >> KerberosPrincipal kClient = new KerberosPrincipal( >> cred.getClient().getName()); >> if (!princSet.contains(kClient)) { >> kClientAlias = kClient; >> } >> >> Looks like this ticket's name and alias will be the same? Is this useful? >> > > Removed. See above. > >> >> Or, if CANONICALIZE is not set (who knows why), then there will be no alias and the alias is the name. > > Yes, if we send no CANONICALIZE (i.e.: because of the fallback scheme), > we will have no client alias but the ticket cname will then be equal to > the subject (kerberos) principal. > > Regression testing in jdk/sun/security/krb5 category passed. > > Are we good to go with Webrev.02? > > Thanks, > Martin.- From xuelei.fan at oracle.com Wed Jul 17 13:29:10 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 17 Jul 2019 06:29:10 -0700 Subject: RFR[13]: 8227551 Session Resumption without Server-Side State off by default In-Reply-To: <7679722e-a0ec-56c2-5625-08719aac8048@oracle.com> References: <7679722e-a0ec-56c2-5625-08719aac8048@oracle.com> Message-ID: On 7/16/2019 8:43 PM, sha.jiang at oracle.com wrote: > Hi Tony, > Just a minor comment. > > ?242???????????? if (st.compareToIgnoreCase("true") == 0) { > ?243???????????????? statelessSession = true; > ?244???????????? } > Could it simply use the below statement? > statelessSession = st.equalsIgnoreCase("true"); > +1. Looks good to me. Xuelei > Best regards, > John Jiang > > On 2019/7/17 11:12, Anthony Scarpino wrote: >> Please review the change to set stateless session resumption off default >> >> http://cr.openjdk.java.net/~ascarpino/8227551/webrev/ >> >> Thanks >> >> Tony >> From mbalao at redhat.com Wed Jul 17 16:07:07 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 17 Jul 2019 13:07:07 -0300 Subject: RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found In-Reply-To: References: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> <944810B3-053D-48B4-AB55-81D55F35D55E@oracle.com> <1fb04033-cfca-251e-31b4-f704443b69f1@redhat.com> <340a2b06-8ab0-bb4d-d3c7-e3f51d1542c3@redhat.com> Message-ID: On 7/17/19 4:30 AM, Weijun Wang wrote: > There is still a kerberosTicketSetClientAlias() call in Krb5LoginModule.java. Otherwise looks fine. > Hi Max, Missed that one. Fixed at: http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.03/ Please let me know if we are okay to go. Thanks, Martin.- From anthony.scarpino at oracle.com Wed Jul 17 18:06:35 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 17 Jul 2019 11:06:35 -0700 Subject: RFR[13]: 8227551 Session Resumption without Server-Side State off by default In-Reply-To: <7679722e-a0ec-56c2-5625-08719aac8048@oracle.com> References: <7679722e-a0ec-56c2-5625-08719aac8048@oracle.com> Message-ID: <5c99ec15-f259-4c43-008e-47a512534422@oracle.com> I'm going to take a suggestion posted by Jamil privately to instead use statelessSession = Boolean.parseBoolean(st); Given it's a one liner and the tests have all passed, I'm not going to repost the webrev Tony On 7/16/19 8:43 PM, sha.jiang at oracle.com wrote: > Hi Tony, > Just a minor comment. > > ?242???????????? if (st.compareToIgnoreCase("true") == 0) { > ?243???????????????? statelessSession = true; > ?244???????????? } > Could it simply use the below statement? > statelessSession = st.equalsIgnoreCase("true"); > > Best regards, > John Jiang > > On 2019/7/17 11:12, Anthony Scarpino wrote: >> Please review the change to set stateless session resumption off default >> >> http://cr.openjdk.java.net/~ascarpino/8227551/webrev/ >> >> Thanks >> >> Tony >> From jamil.j.nimeh at oracle.com Wed Jul 17 22:02:40 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 17 Jul 2019 15:02:40 -0700 Subject: RFR 8226338: Updates to Stateless Resumption In-Reply-To: <8d314691-0ca5-307e-41a1-e6ba731abacb@oracle.com> References: <8d314691-0ca5-307e-41a1-e6ba731abacb@oracle.com> Message-ID: <645fefc6-95f1-4ad9-d79d-7f654cf57240@oracle.com> FInished up with .03, looks good! --Jamil On 7/2/19 10:35 AM, Anthony Scarpino wrote: > > Hi, > > I need a code review on some updates to the stateless resumption. > 1) Changing peerSupportedSignAlgs from a String[] to Collection[] > 2) Additional items added to the stateless ticket > 3) Not provide a stateless ticket when the masterkey is not accessible > (FIPS) or when boundValues are used > 4) Be more graceful in case of stateless ticket generation failure > > http://cr.openjdk.java.net/~ascarpino/8226338/webrev.00/ > > Tony From RAJAN.HALADE at ORACLE.COM Wed Jul 17 22:40:27 2019 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Wed, 17 Jul 2019 15:40:27 -0700 Subject: RFR: 8228337: problemList failing/ignored manual tests in security-libs Message-ID: <5A10DF5B-23BF-40EC-A7D9-E7D222E94443@ORACLE.COM> Please review this problemList update to add earlier ignored manual regression tests. These tests require special setup/hardware and few have outdated JDK and need update. webrev: http://cr.openjdk.java.net/~rhalade/8228337/webrev.00/ Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Wed Jul 17 22:50:11 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 17 Jul 2019 15:50:11 -0700 Subject: RFR: 8228337: problemList failing/ignored manual tests in security-libs In-Reply-To: <5A10DF5B-23BF-40EC-A7D9-E7D222E94443@ORACLE.COM> References: <5A10DF5B-23BF-40EC-A7D9-E7D222E94443@ORACLE.COM> Message-ID: <25b723d5-037b-a149-b45e-52de95054d08@oracle.com> On 7/17/19 3:40 PM, Rajan Halade wrote: > Please review this problemList update to add earlier ignored manual > regression tests. These tests require special setup/hardware and few > have outdated JDK and need update. > > webrev: http://cr.openjdk.java.net/~rhalade/8228337/webrev.00/ > > Thanks, > Rajan Looks good Tony From weijun.wang at oracle.com Wed Jul 17 23:06:11 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Jul 2019 07:06:11 +0800 Subject: RFR 8227437: S4U2proxy cannot continue because server's TGT cannot be found In-Reply-To: References: <8d04012c-198e-f3a3-888b-955ae854cc31@redhat.com> <944810B3-053D-48B4-AB55-81D55F35D55E@oracle.com> <1fb04033-cfca-251e-31b4-f704443b69f1@redhat.com> <340a2b06-8ab0-bb4d-d3c7-e3f51d1542c3@redhat.com> Message-ID: <3A9642AD-D4C5-47AC-9BAB-B26B4B24056C@oracle.com> Update the copyright year of the 2 C files to 2019 and you can push the change. Thanks, Max > On Jul 18, 2019, at 12:07 AM, Martin Balao wrote: > > On 7/17/19 4:30 AM, Weijun Wang wrote: >> There is still a kerberosTicketSetClientAlias() call in Krb5LoginModule.java. Otherwise looks fine. >> > > Hi Max, > > Missed that one. > > Fixed at: > http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.webrev.03/ > > Please let me know if we are okay to go. > > Thanks, > Martin.- > From weijun.wang at oracle.com Thu Jul 18 01:18:45 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 18 Jul 2019 09:18:45 +0800 Subject: [13] RFR 8228342: Add SignTwice.java to problem list Message-ID: <97748FE4-892A-413C-BB1D-D582C86E9FE0@oracle.com> The new test included in JDK-8217375 fails intermittently on Windows so it was put into problem list at adding time, but I mistakenly use 8217375 in the entry. I've just created 2 new issues: 8228341: SignTwice.java fails intermittently on Windows 8228342: Add SignTwice.java to problem list Here is the patch for 8228342, please take a review: diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -661,7 +661,7 @@ sun/security/tools/keytool/KeyToolTest.java 8224644 solaris-all sun/security/tools/keytool/WeakAlg.java 8224644 solaris-all -sun/security/tools/jarsigner/compatibility/SignTwice.java 8217375 windows-all +sun/security/tools/jarsigner/compatibility/SignTwice.java 8228341 windows-all sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java 8212096 generic-all Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Jul 18 04:52:58 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 17 Jul 2019 21:52:58 -0700 Subject: [13] RFR 8228342: Add SignTwice.java to problem list In-Reply-To: <97748FE4-892A-413C-BB1D-D582C86E9FE0@oracle.com> References: <97748FE4-892A-413C-BB1D-D582C86E9FE0@oracle.com> Message-ID: It looks good to me. Xuelei On 7/17/2019 6:18 PM, Weijun Wang wrote: > The new test included in JDK-8217375 fails intermittently on Windows so > it was put into problem list at adding time, but I mistakenly > use?8217375 in the entry. I've just created 2 new issues: > > 8228341: SignTwice.java fails intermittently on Windows > 8228342: Add SignTwice.java to problem list > > Here is the patch for?8228342, please take a review: > > *diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt* > *--- a/test/jdk/ProblemList.txt* > *+++ b/test/jdk/ProblemList.txt* > @@ -661,7 +661,7 @@ > ?sun/security/tools/keytool/KeyToolTest.java > 8224644 solaris-all > ?sun/security/tools/keytool/WeakAlg.java > 8224644 solaris-all > > > -sun/security/tools/jarsigner/compatibility/SignTwice.java ? ? ? 8217375 > windows-all > +sun/security/tools/jarsigner/compatibility/SignTwice.java ? ? ? 8228341 > windows-all > ?sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java > 8026393 generic-all > > > ?javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java > 8212096 generic-all > > Thanks, > Max > From anthony.scarpino at oracle.com Thu Jul 18 17:49:48 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 18 Jul 2019 10:49:48 -0700 Subject: RFR[14] Re-enable Stateless Resumption On by default for merge to mainline Message-ID: <8f59c04a-50df-74ce-a607-ef50013b0c51@oracle.com> This is a changeset for preventing Stateless Resumption from being turned off when JDK-8227551 is merged from 13 into the mainline repo. This is the way the gatekeepers asked me to do it as oppose to withholding 8227551 from the mainline merge. http://cr.openjdk.java.net/~ascarpino/8228396/webrev/ Thanks Tony From jamil.j.nimeh at oracle.com Thu Jul 18 18:29:08 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 18 Jul 2019 11:29:08 -0700 Subject: RFR[14] Re-enable Stateless Resumption On by default for merge to mainline In-Reply-To: <8f59c04a-50df-74ce-a607-ef50013b0c51@oracle.com> References: <8f59c04a-50df-74ce-a607-ef50013b0c51@oracle.com> Message-ID: <1517efc5-d128-7f14-4567-159797ab4396@oracle.com> Looks good, Tony. --Jamil On 7/18/19 10:49 AM, Anthony Scarpino wrote: > This is a changeset for preventing Stateless Resumption from being > turned off when JDK-8227551 is merged from 13 into the mainline repo. > This is the way the gatekeepers asked me to do it as oppose to > withholding 8227551 from the mainline merge. > > http://cr.openjdk.java.net/~ascarpino/8228396/webrev/ > > Thanks > > Tony From anthony.scarpino at oracle.com Thu Jul 18 19:02:23 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 18 Jul 2019 12:02:23 -0700 Subject: RFR[13] 8228399: Remove mistaken open.iml Message-ID: <3b0f5368-610e-5342-d6dd-cdfee7365751@oracle.com> A mistaken file got added into my push of 8227551, which did not show up in the webrev. I'm not sure why that happened. Nevertheless, I need a review to have it removed http://cr.openjdk.java.net/~ascarpino/8228399/webrev/ thanks Tony From Xuelei.Fan at Oracle.Com Thu Jul 18 19:15:28 2019 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Thu, 18 Jul 2019 12:15:28 -0700 Subject: RFR[13] 8228399: Remove mistaken open.iml In-Reply-To: <3b0f5368-610e-5342-d6dd-cdfee7365751@oracle.com> References: <3b0f5368-610e-5342-d6dd-cdfee7365751@oracle.com> Message-ID: Good to me. Xuelei > On Jul 18, 2019, at 12:02 PM, Anthony Scarpino wrote: > > A mistaken file got added into my push of 8227551, which did not show up in the webrev. I'm not sure why that happened. Nevertheless, I need a review to have it removed > > http://cr.openjdk.java.net/~ascarpino/8228399/webrev/ > > thanks > > Tony From jai.forums2013 at gmail.com Fri Jul 19 06:48:14 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 19 Jul 2019 12:18:14 +0530 Subject: RFR[14] Re-enable Stateless Resumption On by default for merge to mainline In-Reply-To: <8f59c04a-50df-74ce-a607-ef50013b0c51@oracle.com> References: <8f59c04a-50df-74ce-a607-ef50013b0c51@oracle.com> Message-ID: Hello Tony, I'm not a reviewer, but just checking - is this following change intentional: - statelessSession = Boolean.parseBoolean(st); + if (st.compareToIgnoreCase("false") == 0) { + statelessSession = false; + } The Boolean.parseBoolean, that's in JDK 13, should work here too. -Jaikiran On 18/07/19 11:19 PM, Anthony Scarpino wrote: > This is a changeset for preventing Stateless Resumption from being > turned off when JDK-8227551 is merged from 13 into the mainline repo. > This is the way the gatekeepers asked me to do it as oppose to > withholding 8227551 from the mainline merge. > > http://cr.openjdk.java.net/~ascarpino/8228396/webrev/ > > Thanks > > Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Fri Jul 19 08:22:48 2019 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 19 Jul 2019 13:52:48 +0530 Subject: RFR[14] Re-enable Stateless Resumption On by default for merge to mainline In-Reply-To: References: <8f59c04a-50df-74ce-a607-ef50013b0c51@oracle.com> Message-ID: <555c4239-dc16-9910-9f79-1e94ff957f75@gmail.com> Actually, looking at this current code in JDK 14 (default branch), it uses the "compareToIgnoreCase" version. So I guess, you did this change to match with what's already there. So please ignore my previous comment. -Jaikiran On 19/07/19 12:18 PM, Jaikiran Pai wrote: > > Hello Tony, > > I'm not a reviewer, but just checking - is this following change > intentional: > > - statelessSession = Boolean.parseBoolean(st); > + if (st.compareToIgnoreCase("false") == 0) { > + statelessSession = false; > + } > > The Boolean.parseBoolean, that's in JDK 13, should work here too. > > -Jaikiran > On 18/07/19 11:19 PM, Anthony Scarpino wrote: >> This is a changeset for preventing Stateless Resumption from being >> turned off when JDK-8227551 is merged from 13 into the mainline repo. >> This is the way the gatekeepers asked me to do it as oppose to >> withholding 8227551 from the mainline merge. >> >> http://cr.openjdk.java.net/~ascarpino/8228396/webrev/ >> >> Thanks >> >> Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Fri Jul 19 16:59:01 2019 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 19 Jul 2019 09:59:01 -0700 Subject: RFR[14] Re-enable Stateless Resumption On by default for merge to mainline In-Reply-To: <555c4239-dc16-9910-9f79-1e94ff957f75@gmail.com> References: <8f59c04a-50df-74ce-a607-ef50013b0c51@oracle.com> <555c4239-dc16-9910-9f79-1e94ff957f75@gmail.com> Message-ID: <0236ff15-2b0e-7cc5-5b75-1ff0d4d08ebd@oracle.com> Boolean.parseBoolean will only return true on "true", any other entries will return false. Since in this case true is the default, I would rather any other entry than "false" to revert to the default. Therefore going back to the old way is better. Tony On 7/19/19 1:22 AM, Jaikiran Pai wrote: > Actually, looking at this current code in JDK 14 (default branch), it > uses the "compareToIgnoreCase" version. So I guess, you did this change > to match with what's already there. So please ignore my previous comment. > > -Jaikiran > > On 19/07/19 12:18 PM, Jaikiran Pai wrote: >> >> Hello Tony, >> >> I'm not a reviewer, but just checking - is this following change >> intentional: >> >> - statelessSession = Boolean.parseBoolean(st); >> + if (st.compareToIgnoreCase("false") == 0) { >> + statelessSession = false; >> + } >> >> The Boolean.parseBoolean, that's in JDK 13, should work here too. >> >> -Jaikiran >> On 18/07/19 11:19 PM, Anthony Scarpino wrote: >>> This is a changeset for preventing Stateless Resumption from being >>> turned off when JDK-8227551 is merged from 13 into the mainline repo. >>> This is the way the gatekeepers asked me to do it as oppose to >>> withholding 8227551 from the mainline merge. >>> >>> http://cr.openjdk.java.net/~ascarpino/8228396/webrev/ >>> >>> Thanks >>> >>> Tony From xuelei.fan at oracle.com Fri Jul 19 17:03:06 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 19 Jul 2019 10:03:06 -0700 Subject: RFR[14] Re-enable Stateless Resumption On by default for merge to mainline In-Reply-To: <0236ff15-2b0e-7cc5-5b75-1ff0d4d08ebd@oracle.com> References: <8f59c04a-50df-74ce-a607-ef50013b0c51@oracle.com> <555c4239-dc16-9910-9f79-1e94ff957f75@gmail.com> <0236ff15-2b0e-7cc5-5b75-1ff0d4d08ebd@oracle.com> Message-ID: The system property parsing behavior should be consistent between JDK 13 and 14. Xuelei On 7/19/2019 9:59 AM, Anthony Scarpino wrote: > Boolean.parseBoolean will only return true on "true", any other entries > will return false.?? Since in this case true is the default, I would > rather any other entry than "false" to revert to the default.? Therefore > going back to the old way is better. > > Tony > > On 7/19/19 1:22 AM, Jaikiran Pai wrote: >> Actually, looking at this current code in JDK 14 (default branch), it >> uses the "compareToIgnoreCase" version. So I guess, you did this >> change to match with what's already there. So please ignore my >> previous comment. >> >> -Jaikiran >> >> On 19/07/19 12:18 PM, Jaikiran Pai wrote: >>> >>> Hello Tony, >>> >>> I'm not a reviewer, but just checking - is this following change >>> intentional: >>> >>> -??????????? statelessSession = Boolean.parseBoolean(st); >>> +??????????? if (st.compareToIgnoreCase("false") == 0) { >>> +??????????????? statelessSession = false; >>> +??????????? } >>> >>> The Boolean.parseBoolean, that's in JDK 13, should work here too. >>> >>> -Jaikiran >>> On 18/07/19 11:19 PM, Anthony Scarpino wrote: >>>> This is a changeset for preventing Stateless Resumption from being >>>> turned off when JDK-8227551 is merged from 13 into the mainline >>>> repo. This is the way the gatekeepers asked me to do it as oppose to >>>> withholding 8227551 from the mainline merge. >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8228396/webrev/ >>>> >>>> Thanks >>>> >>>> Tony > From weijun.wang at oracle.com Sun Jul 21 00:08:04 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 21 Jul 2019 08:08:04 +0800 Subject: RFR 8217375: jarsigner breaks old signature with long lines in manifest In-Reply-To: <1563655790.2506.7.camel@paratix.ch> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> Message-ID: <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> Hi Philipp, I just took a brief look at the new patch. Looks like the src change has no behavior change (even in JarSigner.java with so many line changes). This is good. John and I have reviewed all the tests and we sent out some feedbacks in previous mails, and it's definitely a part of the whole review process. The single reason I integrated your changeset earlier this week is because RDP 2 starts at July 18 and after the date only P1-P2 src change would be approved but we can still modify the tests. Before pushing the change, I ran all tests, modified 2 regex patterns, and added one to problem list to make sure it makes no (or, as little as possible) noise (esp for other people running the tests). I haven't made any big change to the tests (including removing those FIXED_xxxxxxx flags) myself because I was still waiting for your reply. Thanks for coming back, so that we can start enhancing the tests now. Some test (Ex: PreserveRawManifestEntryAndDigest.java) still spends a lot of time and could intermittently time out. I'll file a new bug and post the interdiff between the integrated change and your new patch as the webrev.00 of it. Thanks, Max > On Jul 21, 2019, at 4:49 AM, Philipp Kunz wrote: > > Hi Max and everyone, > > ? Indeed, [^\"] does not work with quotes inside CN. I agree to your change. > ? I went through the patch again myself and tried to understand what I did half a year ago and added and changed some comments and renamed a few identifiers so that I hope it becomes clearer. Particularly PreserveRawManifestEntryAndDigest is worth mentioning and had a bug in lineWidth70. Noteworthy is the test case with emptyJarTrailingSeqAddFile which is now better documented. > ? I also renamed atts to attrs. > ? It also still works without the Resources changes. > ? I removed testNameEmptyTrusted from EmptyIndividualSectionName after having convinced myself it is not necessary. Any other opinion on this welcome. > ? I moved some common functions used in many tests to Utils. Utils.echoManifest now prints manifests with non-printable characters escaped in Java style but that was in the previous patch already I think. It's used in more tests now than before. > ? I added a test testAddManifestMainAttributesFile in MainAttributesConfused that shows where the problems were with a file named Manifest-Main-Attributes inside a signed jar and that it works now. > ? I increased the timeout of PreserveRawManifestEntryAndDigest after it timed out on my machine a few times. The current timeout value is still pretty much arbitrary. > ? I defined KS_ARGS in various tests to be re-used with repeated jarsigner command line arguments. > > > > I'm sorry for recently not responding quickly. I admit that my personal interest has not increased with the latest development of webstart and I also have other duties or distractions. I welcome everyone to contribute missing parts or a review or an opinion. As I currently see it, the following parts are not yet complete. > > 1. I suggest Compatibility test be run with different JDK versions configured just like before with a focus on TSA now also with jar signinig compatibility across JDK versions on a central and powerful test infrastructure which is achieved by invoking Compatibility test again with different arguments. SignTwice is an example for that with only one JDK version. > > 2. Compatibility test should probably be thoroughly refactored. This can be done well after the merge in my opinion if no seriously harmful changes are revealed in a review. > > 3. I still did not have time to pick up Max's idea to add a jar file in binary form to the sources that would allow to test a current JDK version against it by trying to reproduce it identically. That would at least make incompatibilities detected earlier than with Compatibility test. How much such a test would overlap with the current Compatibility test once integrated in a build like before with TSA can be told only after it exists. In my opinion this makes a lot of sense in any case. > > 4. Somehow I still have not the feeling that someone has thoroughly reviewed the whole patch. It was mentioned that the main source changes look good but is that what a review takes? There are so many subtle changes mostly in ManifestDigester that I doubt there is way around a close look into the tests. It may be all right to check the details only after all the trivial checks passed but that patch has accumulated so much effort until now I really would appreciate some confirmation that everything looks somewhat promising so far, however non-committal. I might have missed a hint and feel still quite new as openjdk contributor. > > 5. Remove all the FIXED_8217375 stuff. In my opinion this requires that after the patch is more or less stable that someone verifies that all the test cases that did not exist before the patch continue to pass unchanged and test coverage is appropriate to calibrate existing behavior. Usually tests should exist before but this here is certainly one and hopefully a rare exception. It would be of no use if some tests were wrong claiming some behavior has not changed and with signed jars and digesting manifests every single difference invalidates the signatures without mercy. Actually removing the FIXED_8217375 stuff is then trivial. > > > Lot of fuzzy talk written, please accept my apology for spamming this way. I always appreciate any comment, hint, advice or anything. > > Regards, > Philipp > > > > On Tue, 2019-07-16 at 21:29 +0800, Weijun Wang wrote: >> I made another small change >> >> diff -iu b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java >> --- b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java >> +++ b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java >> @@ -717,7 +717,7 @@ >> + " Digest algorithm: " + signItem.expectedDigestAlg() >> + (signItem.tsaIndex < 0 ? "" : >> ")|(" >> - + "Timestamped by \"[^\"]+\" on .*" >> + + "Timestamped by \".+\" on .*" >> + ")|(" >> + " Timestamp digest algorithm: " >> + signItem.expectedTsaDigestAlg() >> >> This is because there can be quotation marks inside CN. For example, >> >> Timestamped by "CN="Sectigo RSA Time Stamping Signer #1", O=Sectigo Limited, L=Salford, ST=Greater Manchester, C=GB" on Tue Jul 16 12:23:29 UTC 2019 >> >> Thanks, >> Max >> >> >> >>> >>> On Jul 16, 2019, at 2:13 PM, Weijun Wang < >>> weijun.wang at oracle.com >>> > wrote: >>> >>> I'd also like to revert the changes to src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java. Your change strips some trailing whitespaces but not all of them. This will trigger a re-translation of all Resources files and I think that is unnecessary. >>> >>> Will any of your new tests fail because of the revert? I'll run all tests soon. >>> >>> Thanks, >>> Max >>> >>> >>> >>>> >>>> On Jul 16, 2019, at 11:34 AM, Weijun Wang < >>>> weijun.wang at oracle.com >>>> > wrote: >>>> >>>> 7/18 is near. If there is no new webrev, I'll push webrev.02 with SignTwice.java disabled. We can still modify tests before 8/8. >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>>> >>>>> On Jul 10, 2019, at 10:34 AM, Weijun Wang < >>>>> weijun.wang at oracle.com >>>>> > wrote: >>>>> >>>>> [off the list] >>>>> >>>>> Hi Philipp, >>>>> >>>>> Do you have a new patch? The RDP 2 [1] starts on 7/18 and after that we will only be able to fix P1-P2 bugs after approvals. >>>>> >>>>> Let's get the changeset integrated before RDP 2 once there is no problem in src/. We can adjust the tests before RC (8/8). >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> [1] >>>>> https://openjdk.java.net/jeps/3#rdp-2 >>>>> >>>>> >>>>> >>>>>> >>>>>> On Jul 3, 2019, at 6:27 PM, Weijun Wang < >>>>>> weijun.wang at oracle.com >>>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On Jul 3, 2019, at 4:06 PM, Philipp Kunz < >>>>>>> philipp.kunz at paratix.ch >>>>>>> > wrote: >>>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>> Do I understand correctly that your question refers to >>>>>>> if (e == null && MF_MAIN_ATTRS.equals(name)) { >>>>>>> e = getMainAttsEntry(); >>>>>>> } >>>>>>> ? >>>>>>> >>>>>> >>>>>> >>>>>> Yes. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> If so, because this sticks closest to the previous behavior. According to src/java.base/share/classes/module-info.java, ManifestDigester is not publicly exported but how can it then be used then in JarVerifier in java.util.jar? If you or someone can confirm that we can identify all callers, I'd prefer to remove above three lines of code. >>>>>>> >>>>>> >>>>>> >>>>>> It's not publicly exported therefore cannot be used by an application, but it's accessible by java.util.jar which is also in the java.base module. >>>>>> >>>>>> It can also be accessed by JDK modules listed in the "exports sun.security.util to" block of java.base/share/classes/module-info.java. >>>>>> >>>>>> Anyway any caller must be inside JDK. IntelliJ IDEA tells me its only SignatureFileVerifier and JarSigner. Hopefully whatever IDE you are using it gives the same result. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Otherwise, with above three lines, main attributes and an entry with name MF_MAIN_ATTRS will still be confused for all those code continuing to call get as before the patch if an entry with such a name exists just like before. However, with the patch, all (known) places that call ManifestDigester.get* are lines 539 and 606 in SignatureFileVerifier with the patch, 539 calling getMainAttsEntry without any ambiguity and 606 calling get(String, b) always expecting the entry for a section that is present and would otherwise not be known to pass as an argument anyway, provided the signature file does not contain more entries than the manifest or entries have not been removed from the manifest after signing, should work correctly, I guess. If we cannot get rid of those three lines, another test for those edge cases should probably be added, shouldn't it, if not to support the previous confusion at least to show it now works as expected? >>>>>>> >>>>>>> What exactly did you mean with "coding error"? >>>>>>> >>>>>> >>>>>> >>>>>> Not sure. I don't know if any bad thing would happen if a file named "Manifest-Main-Attributes" is out inside a jar file. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Along with removing above three lines of code, two tests would have to be adjusted. FindHeaderEndVsManifestDigesterFindFirstSection on lne 235 and DigestInput on line 270. >>>>>>> >>>>>> >>>>>> >>>>>> That's OK. No real app should call methods in this class directly. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Philipp >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, 2019-07-01 at 15:41 +0800, Weijun Wang wrote: >>>>>>> >>>>>>>> >>>>>>>> https://cr.openjdk.java.net/~weijun/8217375/webrev.02 >>>>>>>> >>>>>>>> uploaded. There are still several trailing spaces and I've removed them. >>>>>>>> >>>>>>>> I just ran a test job: SignTwice.java failed on Windows with `failed to clean up files after test`. Most likely a file is not closed. >>>>>>>> >>>>>>>> The src change looks good. In fact, I am wondering if we need to support ManifestDigester.get(MF_MAIN_ATTRS, b) at all. Is it possible we miss a coding error because of it? >>>>>>>> >>>>>>>> I'll take a look at the tests. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > <8217375-jarsignerbreaksexistingsignatures-20190719.patch> From weijun.wang at oracle.com Sun Jul 21 00:10:50 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 21 Jul 2019 08:10:50 +0800 Subject: RFR 8217375: jarsigner breaks old signature with long lines in manifest In-Reply-To: <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> Message-ID: <60536758-8EF3-44B3-B115-C734279E3A8F@oracle.com> > On Jul 21, 2019, at 8:08 AM, Weijun Wang wrote: > > Hi Philipp, > > I just took a brief look at the new patch. Looks like the src change has no behavior change (even in JarSigner.java with so many line changes). This is good. Ah, I noticed the ManifestDigester::get will not return the main attributes anymore. That's a clean up and I think the current code would not reach that path. --Max > > John and I have reviewed all the tests and we sent out some feedbacks in previous mails, and it's definitely a part of the whole review process. The single reason I integrated your changeset earlier this week is because RDP 2 starts at July 18 and after the date only P1-P2 src change would be approved but we can still modify the tests. Before pushing the change, I ran all tests, modified 2 regex patterns, and added one to problem list to make sure it makes no (or, as little as possible) noise (esp for other people running the tests). I haven't made any big change to the tests (including removing those FIXED_xxxxxxx flags) myself because I was still waiting for your reply. Thanks for coming back, so that we can start enhancing the tests now. Some test (Ex: PreserveRawManifestEntryAndDigest.java) still spends a lot of time and could intermittently time out. > > I'll file a new bug and post the interdiff between the integrated change and your new patch as the webrev.00 of it. > > Thanks, > Max > >> On Jul 21, 2019, at 4:49 AM, Philipp Kunz wrote: >> >> Hi Max and everyone, >> >> ? Indeed, [^\"] does not work with quotes inside CN. I agree to your change. >> ? I went through the patch again myself and tried to understand what I did half a year ago and added and changed some comments and renamed a few identifiers so that I hope it becomes clearer. Particularly PreserveRawManifestEntryAndDigest is worth mentioning and had a bug in lineWidth70. Noteworthy is the test case with emptyJarTrailingSeqAddFile which is now better documented. >> ? I also renamed atts to attrs. >> ? It also still works without the Resources changes. >> ? I removed testNameEmptyTrusted from EmptyIndividualSectionName after having convinced myself it is not necessary. Any other opinion on this welcome. >> ? I moved some common functions used in many tests to Utils. Utils.echoManifest now prints manifests with non-printable characters escaped in Java style but that was in the previous patch already I think. It's used in more tests now than before. >> ? I added a test testAddManifestMainAttributesFile in MainAttributesConfused that shows where the problems were with a file named Manifest-Main-Attributes inside a signed jar and that it works now. >> ? I increased the timeout of PreserveRawManifestEntryAndDigest after it timed out on my machine a few times. The current timeout value is still pretty much arbitrary. >> ? I defined KS_ARGS in various tests to be re-used with repeated jarsigner command line arguments. >> >> >> >> I'm sorry for recently not responding quickly. I admit that my personal interest has not increased with the latest development of webstart and I also have other duties or distractions. I welcome everyone to contribute missing parts or a review or an opinion. As I currently see it, the following parts are not yet complete. >> >> 1. I suggest Compatibility test be run with different JDK versions configured just like before with a focus on TSA now also with jar signinig compatibility across JDK versions on a central and powerful test infrastructure which is achieved by invoking Compatibility test again with different arguments. SignTwice is an example for that with only one JDK version. >> >> 2. Compatibility test should probably be thoroughly refactored. This can be done well after the merge in my opinion if no seriously harmful changes are revealed in a review. >> >> 3. I still did not have time to pick up Max's idea to add a jar file in binary form to the sources that would allow to test a current JDK version against it by trying to reproduce it identically. That would at least make incompatibilities detected earlier than with Compatibility test. How much such a test would overlap with the current Compatibility test once integrated in a build like before with TSA can be told only after it exists. In my opinion this makes a lot of sense in any case. >> >> 4. Somehow I still have not the feeling that someone has thoroughly reviewed the whole patch. It was mentioned that the main source changes look good but is that what a review takes? There are so many subtle changes mostly in ManifestDigester that I doubt there is way around a close look into the tests. It may be all right to check the details only after all the trivial checks passed but that patch has accumulated so much effort until now I really would appreciate some confirmation that everything looks somewhat promising so far, however non-committal. I might have missed a hint and feel still quite new as openjdk contributor. >> >> 5. Remove all the FIXED_8217375 stuff. In my opinion this requires that after the patch is more or less stable that someone verifies that all the test cases that did not exist before the patch continue to pass unchanged and test coverage is appropriate to calibrate existing behavior. Usually tests should exist before but this here is certainly one and hopefully a rare exception. It would be of no use if some tests were wrong claiming some behavior has not changed and with signed jars and digesting manifests every single difference invalidates the signatures without mercy. Actually removing the FIXED_8217375 stuff is then trivial. >> >> >> Lot of fuzzy talk written, please accept my apology for spamming this way. I always appreciate any comment, hint, advice or anything. >> >> Regards, >> Philipp >> >> >> >> On Tue, 2019-07-16 at 21:29 +0800, Weijun Wang wrote: >>> I made another small change >>> >>> diff -iu b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java >>> --- b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java >>> +++ b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java >>> @@ -717,7 +717,7 @@ >>> + " Digest algorithm: " + signItem.expectedDigestAlg() >>> + (signItem.tsaIndex < 0 ? "" : >>> ")|(" >>> - + "Timestamped by \"[^\"]+\" on .*" >>> + + "Timestamped by \".+\" on .*" >>> + ")|(" >>> + " Timestamp digest algorithm: " >>> + signItem.expectedTsaDigestAlg() >>> >>> This is because there can be quotation marks inside CN. For example, >>> >>> Timestamped by "CN="Sectigo RSA Time Stamping Signer #1", O=Sectigo Limited, L=Salford, ST=Greater Manchester, C=GB" on Tue Jul 16 12:23:29 UTC 2019 >>> >>> Thanks, >>> Max >>> >>> >>> >>>> >>>> On Jul 16, 2019, at 2:13 PM, Weijun Wang < >>>> weijun.wang at oracle.com >>>>> wrote: >>>> >>>> I'd also like to revert the changes to src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java. Your change strips some trailing whitespaces but not all of them. This will trigger a re-translation of all Resources files and I think that is unnecessary. >>>> >>>> Will any of your new tests fail because of the revert? I'll run all tests soon. >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>> >>>>> >>>>> On Jul 16, 2019, at 11:34 AM, Weijun Wang < >>>>> weijun.wang at oracle.com >>>>>> wrote: >>>>> >>>>> 7/18 is near. If there is no new webrev, I'll push webrev.02 with SignTwice.java disabled. We can still modify tests before 8/8. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>>> >>>>>> On Jul 10, 2019, at 10:34 AM, Weijun Wang < >>>>>> weijun.wang at oracle.com >>>>>>> wrote: >>>>>> >>>>>> [off the list] >>>>>> >>>>>> Hi Philipp, >>>>>> >>>>>> Do you have a new patch? The RDP 2 [1] starts on 7/18 and after that we will only be able to fix P1-P2 bugs after approvals. >>>>>> >>>>>> Let's get the changeset integrated before RDP 2 once there is no problem in src/. We can adjust the tests before RC (8/8). >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> [1] >>>>>> https://openjdk.java.net/jeps/3#rdp-2 >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On Jul 3, 2019, at 6:27 PM, Weijun Wang < >>>>>>> weijun.wang at oracle.com >>>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Jul 3, 2019, at 4:06 PM, Philipp Kunz < >>>>>>>> philipp.kunz at paratix.ch >>>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> Do I understand correctly that your question refers to >>>>>>>> if (e == null && MF_MAIN_ATTRS.equals(name)) { >>>>>>>> e = getMainAttsEntry(); >>>>>>>> } >>>>>>>> ? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> If so, because this sticks closest to the previous behavior. According to src/java.base/share/classes/module-info.java, ManifestDigester is not publicly exported but how can it then be used then in JarVerifier in java.util.jar? If you or someone can confirm that we can identify all callers, I'd prefer to remove above three lines of code. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> It's not publicly exported therefore cannot be used by an application, but it's accessible by java.util.jar which is also in the java.base module. >>>>>>> >>>>>>> It can also be accessed by JDK modules listed in the "exports sun.security.util to" block of java.base/share/classes/module-info.java. >>>>>>> >>>>>>> Anyway any caller must be inside JDK. IntelliJ IDEA tells me its only SignatureFileVerifier and JarSigner. Hopefully whatever IDE you are using it gives the same result. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Otherwise, with above three lines, main attributes and an entry with name MF_MAIN_ATTRS will still be confused for all those code continuing to call get as before the patch if an entry with such a name exists just like before. However, with the patch, all (known) places that call ManifestDigester.get* are lines 539 and 606 in SignatureFileVerifier with the patch, 539 calling getMainAttsEntry without any ambiguity and 606 calling get(String, b) always expecting the entry for a section that is present and would otherwise not be known to pass as an argument anyway, provided the signature file does not contain more entries than the manifest or entries have not been removed from the manifest after signing, should work correctly, I guess. If we cannot get rid of those three lines, another test for those edge cases should probably be added, shouldn't it, if not to support the previous confusion at least to show it now works as expected? >>>>>>>> >>>>>>>> What exactly did you mean with "coding error"? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Not sure. I don't know if any bad thing would happen if a file named "Manifest-Main-Attributes" is out inside a jar file. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Along with removing above three lines of code, two tests would have to be adjusted. FindHeaderEndVsManifestDigesterFindFirstSection on lne 235 and DigestInput on line 270. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> That's OK. No real app should call methods in this class directly. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Philipp >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, 2019-07-01 at 15:41 +0800, Weijun Wang wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> https://cr.openjdk.java.net/~weijun/8217375/webrev.02 >>>>>>>>> >>>>>>>>> uploaded. There are still several trailing spaces and I've removed them. >>>>>>>>> >>>>>>>>> I just ran a test job: SignTwice.java failed on Windows with `failed to clean up files after test`. Most likely a file is not closed. >>>>>>>>> >>>>>>>>> The src change looks good. In fact, I am wondering if we need to support ManifestDigester.get(MF_MAIN_ATTRS, b) at all. Is it possible we miss a coding error because of it? >>>>>>>>> >>>>>>>>> I'll take a look at the tests. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> <8217375-jarsignerbreaksexistingsignatures-20190719.patch> > From weijun.wang at oracle.com Mon Jul 22 02:02:51 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Jul 2019 10:02:51 +0800 Subject: [13] RFR 8228456: Enhance tests after JDK-8217375 In-Reply-To: <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8228456/webrev.00/ The change is contributed by Philipp Kunz. Since we are now in RDP 2 and we are not allowed to fix non-test P3 (and lower) bugs. I've removed all src/ changes in Philipp's patch (If I read correctly, is mostly on renaming methods, and brings no behavior change) and made necessary change in test codes to use original method names. I haven't read the changes yet. I only made sure they pass on my own system. Oracle's test farm is in maintenance during the weekend. Thanks, Max From bert.eisen.1952 at gmail.com Mon Jul 22 13:23:19 2019 From: bert.eisen.1952 at gmail.com (Bert Eisen) Date: Mon, 22 Jul 2019 14:23:19 +0100 Subject: Is Digicert's continued use of the "Distrusted" certificates for code signing still valid? In-Reply-To: References: Message-ID: Hi Sean. Thanks for looking into this issue. I was wondering if there had been any further updates? Regards Bert On Tue, 25 Jun 2019 at 19:08, Bert Eisen wrote: > Hello, > > I?m trying to understand why Digicert are still issuing signing > certificates from the distrusted Symantec root CAs and as a consequence if > the java code signing is still meaningful? I know for sure that they are > still issing certificates from the distrusted "thawte Primary Root CA - G3" > root, because i'm trying to verify the signing certificate that has just > been issued to the company that I work for. > > The root CA?s were distrusted by Google following the discovery of a > number of invalid certificates incorrectly issued by Symantec and their > partners[1]. And the subsequent investigation by Google reviled that > Symantec?s partners were allowed to issue certificates without appropriate > controls or adequate security processed. It would appear that only > certificates used for protecting websites are listed in the Sectigo search > engine [ https://crt.sh/], thus it is unclear what other > types of certificates have been issued. Ultimately this means that you > should not ?Trust? any certificate issued from those roots. > > According to the Thawte Certification practice statement v3.7.20[2], (as > refernced by the G3 root certificate,) it describes the CA as being > ?inactive?. In addition the policy document also describes the > intermediate code signing certificate ?thawte SHA256 Code Signing CA - G2? > has having have a daily updates to its CRL, but the URL seems to point to > the wrong crl distribution list, which is only being updated every 3 months. > > Which brings us onto the java code signing. In response to the Googles > distrust statement, the JDK and the SunJSSE provider has been updated[3] to > explicitly reject TLS sessions rooted in the affected CAs, however it > stopped short of removing the CA?s completely. This means that jar files > signed by the affected roots are still considered valid and pass all > verification checks without warning. > > Given that the Trust has been eroded from the affected roots, a third > party can no-longer believe with certainty that the signed code hasn?t been > tampered with or has originated from the party named in the certificate. > As such I believe that digicert should not be continuing to issue > certifcates from those CAs and that java (and other platforms) should > deprecate the use of the affected CA?s. At the very least the the JDK > shoud warn of code and other artefacts that have been signed since the > distrust date. > > Regards > Bert > > [1] > > https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html > [2] > > https://www.thawte.com/assets/documents/repository/cps/Thawte_CPS_3_7.20.pdf > [3] > https://bugs.openjdk.java.net/browse/JDK-8207258?subTaskView=all > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Jul 22 17:55:59 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 22 Jul 2019 13:55:59 -0400 Subject: RFR[14] Re-enable Stateless Resumption On by default for merge to mainline In-Reply-To: References: <8f59c04a-50df-74ce-a607-ef50013b0c51@oracle.com> <555c4239-dc16-9910-9f79-1e94ff957f75@gmail.com> <0236ff15-2b0e-7cc5-5b75-1ff0d4d08ebd@oracle.com> Message-ID: I agree we should be consistent. With this change setting the property to "foo" would be false in JDK 13 and true in JDK 14. Typically I think boolean properties are true only if set to "true" (ignoring case), and anything else is false. In hindsight I probably would have also treated the empty String as "true" but it is not critical. --Sean On 7/19/19 1:03 PM, Xuelei Fan wrote: > The system property parsing behavior should be consistent between JDK 13 > and 14. > > Xuelei > > On 7/19/2019 9:59 AM, Anthony Scarpino wrote: >> Boolean.parseBoolean will only return true on "true", any other >> entries will return false.?? Since in this case true is the default, I >> would rather any other entry than "false" to revert to the default. >> Therefore going back to the old way is better. >> >> Tony >> >> On 7/19/19 1:22 AM, Jaikiran Pai wrote: >>> Actually, looking at this current code in JDK 14 (default branch), it >>> uses the "compareToIgnoreCase" version. So I guess, you did this >>> change to match with what's already there. So please ignore my >>> previous comment. >>> >>> -Jaikiran >>> >>> On 19/07/19 12:18 PM, Jaikiran Pai wrote: >>>> >>>> Hello Tony, >>>> >>>> I'm not a reviewer, but just checking - is this following change >>>> intentional: >>>> >>>> -??????????? statelessSession = Boolean.parseBoolean(st); >>>> +??????????? if (st.compareToIgnoreCase("false") == 0) { >>>> +??????????????? statelessSession = false; >>>> +??????????? } >>>> >>>> The Boolean.parseBoolean, that's in JDK 13, should work here too. >>>> >>>> -Jaikiran >>>> On 18/07/19 11:19 PM, Anthony Scarpino wrote: >>>>> This is a changeset for preventing Stateless Resumption from being >>>>> turned off when JDK-8227551 is merged from 13 into the mainline >>>>> repo. This is the way the gatekeepers asked me to do it as oppose >>>>> to withholding 8227551 from the mainline merge. >>>>> >>>>> http://cr.openjdk.java.net/~ascarpino/8228396/webrev/ >>>>> >>>>> Thanks >>>>> >>>>> Tony >> From weijun.wang at oracle.com Tue Jul 23 06:09:22 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 23 Jul 2019 14:09:22 +0800 Subject: [13] RFR 8227595: keytool/fakegen/DefaultSignatureAlgorithm.java fails due to "exitValue = 6" In-Reply-To: <75C94E6E-D4B0-4C3B-ACE2-F1FD41C86A2A@oracle.com> References: <75C94E6E-D4B0-4C3B-ACE2-F1FD41C86A2A@oracle.com> Message-ID: <1C40F943-606F-484F-B80A-1B0B507048CA@oracle.com> Ping again. > On Jul 17, 2019, at 8:32 AM, Weijun Wang wrote: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8227595 > > The test cannot use the included fake keypair generator because on Solaris the SunPKCS11-Solaris is more preferred. Like what I have done [1] for the PSS.java test nearby, exclude the test from Solaris as well. I've also taken this chance to add a clarification on why the fake generator does not help here. Please review the patch below. > > Thanks, > Max > > diff --git a/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java b/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java > --- a/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java > +++ b/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java > @@ -23,16 +23,21 @@ > > /* > * @test > - * @bug 8138766 8227059 > + * @bug 8138766 8227059 8227595 > * @summary New default -sigalg for keytool > * @library /test/lib > * @build java.base/sun.security.rsa.RSAKeyPairGenerator > * java.base/sun.security.provider.DSAKeyPairGenerator > * jdk.crypto.ec/sun.security.ec.ECKeyPairGenerator > + * @requires os.family != "solaris" > * @run main DefaultSignatureAlgorithm > * @modules jdk.crypto.ec > */ > > +// This test is excluded from Solaris because the RSA key pair generator > +// is extremely slow there with a big keysize. Please note the fake > +// KeyPairGenerator will not be used because of provider preferences. > + > import jdk.test.lib.Asserts; > import jdk.test.lib.SecurityTools; > import jdk.test.lib.process.OutputAnalyzer; > diff --git a/test/jdk/sun/security/tools/keytool/fakegen/PSS.java b/test/jdk/sun/security/tools/keytool/fakegen/PSS.java > --- a/test/jdk/sun/security/tools/keytool/fakegen/PSS.java > +++ b/test/jdk/sun/security/tools/keytool/fakegen/PSS.java > @@ -34,7 +34,8 @@ > */ > > // This test is excluded from Solaris because the 8192-bit RSA key pair > -// generator is extremely slow there. > +// generator is extremely slow there. Please note the fake > +// KeyPairGenerator will not be used because of provider preferences. > > import jdk.test.lib.Asserts; > import jdk.test.lib.SecurityTools; > > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/271ee240244c From weijun.wang at oracle.com Tue Jul 23 06:28:20 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 23 Jul 2019 14:28:20 +0800 Subject: [13] RFR 8228341: SignTwice.java fails intermittently on Windows Message-ID: Please review the patch below. This test signs the same jar multiple times. It's mainly about making sure the manifest and signature file can be updated correctly. There is no need to try different key algorithms. We can also use a faster digest algorithm. Thanks, Max diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -661,7 +661,6 @@ sun/security/tools/keytool/KeyToolTest.java 8224644 solaris-all sun/security/tools/keytool/WeakAlg.java 8224644 solaris-all -sun/security/tools/jarsigner/compatibility/SignTwice.java 8228341 windows-all sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java 8212096 generic-all diff --git a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java --- a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java +++ b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java @@ -36,7 +36,7 @@ * @test * @library /test/lib ../warnings * @compile Compatibility.java - * @run main/othervm + * @run main/othervm/timeout=600 * -Djava.security.properties=./java.security * -Duser.language=en * -Duser.country=US @@ -46,8 +46,8 @@ * -DtestComprehensiveJarContents=true * -DtestJarUpdate=true * -Dstrict=true - * -DkeyAlgs=EC;#RSA;#DSA; - * -DdigestAlgs=SHA-512 + * -DkeyAlgs=EC;0 + * -DdigestAlgs=SHA-256 * SignTwice */ public class SignTwice { -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Jul 23 11:34:18 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 23 Jul 2019 07:34:18 -0400 Subject: [13] RFR 8228341: SignTwice.java fails intermittently on Windows In-Reply-To: References: Message-ID: <44fa5684-e1ec-e27e-7751-eb0cc57c417b@oracle.com> Looks fine to me. --Sean On 7/23/19 2:28 AM, Weijun Wang wrote: > Please review the patch below. This test signs the same jar multiple > times. It's mainly about making sure the manifest and signature file can > be updated correctly. There is no need to try different key algorithms. > We can also use a faster digest algorithm. > > Thanks, > Max > > *diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt* > *--- a/test/jdk/ProblemList.txt* > *+++ b/test/jdk/ProblemList.txt* > @@ -661,7 +661,6 @@ > ?sun/security/tools/keytool/KeyToolTest.java > 8224644 solaris-all > ?sun/security/tools/keytool/WeakAlg.java > 8224644 solaris-all > > > -sun/security/tools/jarsigner/compatibility/SignTwice.java ? ? ? 8228341 > windows-all > ?sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java > 8026393 generic-all > > > ?javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java > 8212096 generic-all > *diff --git > a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java > b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java* > *--- a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java* > *+++ b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java* > @@ -36,7 +36,7 @@ > ? * @test > ? * @library /test/lib ../warnings > ? * @compile Compatibility.java > - * @run main/othervm > + * @run main/othervm/timeout=600 > ? *? -Djava.security.properties=./java.security > ? *? -Duser.language=en > ? *? -Duser.country=US > @@ -46,8 +46,8 @@ > ? *? -DtestComprehensiveJarContents=true > ? *? -DtestJarUpdate=true > ? *? -Dstrict=true > - *? -DkeyAlgs=EC;#RSA;#DSA; > - *? -DdigestAlgs=SHA-512 > + *? -DkeyAlgs=EC;0 > + *? -DdigestAlgs=SHA-256 > ? *? SignTwice > ? */ > ?public class SignTwice { > From sean.mullan at oracle.com Tue Jul 23 12:25:06 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 23 Jul 2019 08:25:06 -0400 Subject: [13] RFR 8227595: keytool/fakegen/DefaultSignatureAlgorithm.java fails due to "exitValue = 6" In-Reply-To: <75C94E6E-D4B0-4C3B-ACE2-F1FD41C86A2A@oracle.com> References: <75C94E6E-D4B0-4C3B-ACE2-F1FD41C86A2A@oracle.com> Message-ID: <10af90f7-8538-28b7-8b0c-553ef4b2b5f3@oracle.com> Looks fine to me. --Sean On 7/16/19 8:32 PM, Weijun Wang wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8227595 > > The test cannot use the included fake keypair generator because on > Solaris the SunPKCS11-Solaris is more preferred. Like what I have done > [1] for the PSS.java test nearby, exclude the test from Solaris as well. > I've also taken this chance to add a clarification on why the fake > generator does not help here. Please review the patch below. > > Thanks, > Max > > *diff --git > a/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java > b/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java* > *--- > a/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java* > *+++ > b/test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java* > @@ -23,16 +23,21 @@ > > > ?/* > ? * @test > - * @bug 8138766 8227059 > + * @bug 8138766 8227059 8227595 > ? * @summary New default -sigalg for keytool > ? * @library /test/lib > ? * @build java.base/sun.security.rsa.RSAKeyPairGenerator > ? *? ? ? ? java.base/sun.security.provider.DSAKeyPairGenerator > ? *? ? ? ? jdk.crypto.ec/sun.security.ec.ECKeyPairGenerator > + * @requires os.family != "solaris" > ? * @run main DefaultSignatureAlgorithm > ? * @modules jdk.crypto.ec > ? */ > > > +// This test is excluded from Solaris because the RSA key pair generator > +// is extremely slow there with a big keysize. Please note the fake > +// KeyPairGenerator will not be used because of provider preferences. > + > ?import jdk.test.lib.Asserts; > ?import jdk.test.lib.SecurityTools; > ?import jdk.test.lib.process.OutputAnalyzer; > *diff --git a/test/jdk/sun/security/tools/keytool/fakegen/PSS.java > b/test/jdk/sun/security/tools/keytool/fakegen/PSS.java* > *--- a/test/jdk/sun/security/tools/keytool/fakegen/PSS.java* > *+++ b/test/jdk/sun/security/tools/keytool/fakegen/PSS.java* > @@ -34,7 +34,8 @@ > ? */ > > > ?// This test is excluded from Solaris because the 8192-bit RSA key pair > -// generator is extremely slow there. > +// generator is extremely slow there. Please note the fake > +// KeyPairGenerator will not be used because of provider preferences. > > > ?import jdk.test.lib.Asserts; > ?import jdk.test.lib.SecurityTools; > > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/271ee240244c From sean.mullan at oracle.com Tue Jul 23 16:19:45 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 23 Jul 2019 12:19:45 -0400 Subject: Is Digicert's continued use of the "Distrusted" certificates for code signing still valid? In-Reply-To: References: Message-ID: <5cefb018-c292-472d-ed71-2faf08e889fe@oracle.com> Hi Bert, On 7/22/19 9:23 AM, Bert Eisen wrote: > Hi Sean. > Thanks for looking into this issue.? I was wondering if there had been > any further updates? > Regards > Bert Sorry, not yet. I was on vacation recently. I hope to have an update in the next couple of weeks. Thanks, Sean > On Tue, 25 Jun 2019 at 19:08, Bert Eisen > wrote: > > Hello, > > I?m trying to understand why Digicert are still issuing signing > certificates from the distrusted Symantec root CAs and as a > consequence if the java code signing is still meaningful?? I know > for sure that they are still issing certificates from the distrusted > "thawte Primary Root CA - G3" root, because i'm trying to verify the > signing certificate that has just been issued to the company that I > work for. > > The root CA?s were distrusted by Google following the discovery of a > number of invalid certificates incorrectly issued by Symantec and > their partners[1].? And the subsequent investigation by Google > reviled that Symantec?s partners were allowed to issue certificates > without appropriate controls or adequate security processed.? It > would appear that only certificates used for protecting websites are > listed in the Sectigo search engine > [https://crt.sh/], thus it is unclear what other > types of certificates have been issued.? Ultimately this means that > you should not ?Trust? any certificate issued from those roots. > > According to the Thawte Certification practice statement v3.7.20[2], > (as refernced by the G3 root certificate,) it describes the CA as > being ?inactive?.? In addition the policy document also describes > the intermediate code signing certificate ?thawte SHA256 Code > Signing CA - G2? has having have a daily updates to its CRL, but the > URL seems to point to the wrong crl distribution list, which is only > being updated every 3 months. > > Which brings us onto the java code signing.? In response to the > Googles distrust statement, the JDK and the SunJSSE provider has > been updated[3] to explicitly reject TLS sessions rooted in the > affected CAs, however it stopped short of removing the CA?s > completely.? This means that jar files signed by the affected roots > are still considered valid and pass all verification checks without > warning. > > Given that the Trust has been eroded from the affected roots, a > third party can no-longer believe with certainty that the signed > code hasn?t been tampered with or has originated from the party > named in the certificate.? As such I believe that digicert should > not be continuing to issue certifcates from those CAs and that java > (and other platforms) should deprecate the use of the affected > CA?s.? At the very least the the JDK shoud warn of code and other > artefacts that have been signed since the distrust date. > > Regards > Bert > > [1] > https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html > [2] > https://www.thawte.com/assets/documents/repository/cps/Thawte_CPS_3_7.20.pdf > [3] > https://bugs.openjdk.java.net/browse/JDK-8207258?subTaskView=all > From mbalao at redhat.com Tue Jul 23 17:01:22 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 23 Jul 2019 14:01:22 -0300 Subject: [11u] RFR: 8223482: Unsupported ciphersuites may be offered by a TLS client In-Reply-To: <778861d5-cc04-ee7a-4bb8-eaba161adda0@redhat.com> References: <778861d5-cc04-ee7a-4bb8-eaba161adda0@redhat.com> Message-ID: CC'ing security-dev. Thanks, Martin.- On 7/18/19 4:38 PM, Martin Balao wrote: > Hi, > > I'd like to request a review for the jdk11u backport of 8223482 [1]: > > http://cr.openjdk.java.net/~mbalao/webrevs/8223482/8223482.jdk11u.webrev.00/ > > There are 2 changes compared to the JDK version [2]: > > * SSLCipher.java > * "Cipher.getInstance" replaced with "JsseJce.getCipher" in > SSLCipher::isTransformationAvailable > * JDK-11 has SunJSSE experimental FIPS support (which was removed in > JDK), so we are able to check if the transformation is supported by > SunJSSE's crypto provider. We don't need to check if it's supported by > any provider because SunJSSE's crypto provider is the one that will be > used for the TLS connection. > > * TestTLS12.java (FipsModeTLS12.java in JDK): > * The change in TestTLS12::initialize does not apply to JDK-11 > * In JDK-11, we don't remove security providers because we are able > to set the one that has to be used in SunJSSE (due to SunJSSE > experimental FIPS support). > > Testing: > > * No regressions found in: > * jdk/sun/security/pkcs11 > * jdk/javax/net/ssl > * jdk/com/sun/crypto/provider/TLS > > * TestTLS12 updated to cover this patch > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8223482 > [2] - http://hg.openjdk.java.net/jdk/jdk/rev/d0f73fccf5f3 > From valerie.peng at oracle.com Wed Jul 24 02:38:16 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 23 Jul 2019 19:38:16 -0700 Subject: [14]RFR 8180392: SunJCE provider should throw exceptions for unsupported mode and padding combinations Message-ID: <5d6cbe15-4d50-ea2f-e1b2-3d0581ea32b4@oracle.com> Anyone have spare cycles to review this fix? Fix is straight forward - instead of relying on the supported mode and padding info from provider, javax.crypto.Cipher class now instantiates the CipherSpi object to make sure the particular mode and padding combination is supported. Bug: https://bugs.openjdk.java.net/browse/JDK-8180392 Webrev: http://cr.openjdk.java.net/~valeriep/8180392/webrev.00/ Thanks, Valerie From xuelei.fan at oracle.com Wed Jul 24 03:33:42 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 23 Jul 2019 20:33:42 -0700 Subject: [14]RFR 8180392: SunJCE provider should throw exceptions for unsupported mode and padding combinations In-Reply-To: <5d6cbe15-4d50-ea2f-e1b2-3d0581ea32b4@oracle.com> References: <5d6cbe15-4d50-ea2f-e1b2-3d0581ea32b4@oracle.com> Message-ID: <3a52cc5c-dc04-122e-b745-cd1673569501@oracle.com> Looks fine to me. Xuelei On 7/23/2019 7:38 PM, Valerie Peng wrote: > Anyone have spare cycles to review this fix? Fix is straight forward - > instead of relying on the supported mode and padding info from provider, > javax.crypto.Cipher class now instantiates the CipherSpi object to make > sure the particular mode and padding combination is supported. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8180392 > > Webrev: http://cr.openjdk.java.net/~valeriep/8180392/webrev.00/ > > Thanks, > Valerie From matthias.baesken at sap.com Wed Jul 24 11:16:52 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 24 Jul 2019 11:16:52 +0000 Subject: RFR : [XS] 8228578: fix CFData object leak in macosx KeystoreImpl.m Message-ID: Hello, please review the following small patch . In KeystoreImpl.m we call CFDataCreate at one place. According to https://developer.apple.com/documentation/corefoundation/1542359-cfdatacreate?language=objc the return value of CFDataCreate is : "A new CFData object, or NULL if there was a problem creating the object. Ownership follows the The Create Rule." Following the "Create Rule" , we have to release the return value to avoid leaks. Or do I miss something ? Bug / (no webrev currently because I have some technical issues at the moment with webrev creation, getting connection reset by peer for some reason ) https://bugs.openjdk.java.net/browse/JDK-8228578 patch is attached, and change also below . Thanks, Matthias Change : # HG changeset patch # Parent 042dfb697624926507649a4a8ad17a5e6730ba04 8228578: fix CFData object leak in macosx KeystoreImpl.m diff -r 042dfb697624 -r 9f43fea81900 src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m --- a/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m Tue Jul 23 20:03:03 2019 -0700 +++ b/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m Wed Jul 24 12:36:12 2019 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -562,6 +562,9 @@ err = SecKeychainItemImport(cfDataToImport, NULL, &dataFormat, NULL, 0, ¶mBlock, defaultKeychain, &createdItems); + if (cfDataToImport != NULL) { + CFRelease(cfDataToImport); + } if (err == noErr) { SecKeychainItemRef anItem = (SecKeychainItemRef)CFArrayGetValueAtIndex(createdItems, 0); -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: keystoreimpl.m.patch Type: application/octet-stream Size: 1162 bytes Desc: keystoreimpl.m.patch URL: From matthias.baesken at sap.com Wed Jul 24 11:35:30 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 24 Jul 2019 11:35:30 +0000 Subject: RFR : [XS] 8228578: fix CFData object leak in macosx KeystoreImpl.m Message-ID: Hello, here is the webrev for easier review . Bug/webrev (after my webrev creation works again) : http://cr.openjdk.java.net/~mbaesken/webrevs/8228578.0/ https://bugs.openjdk.java.net/browse/JDK-8228578 Best regards, Matthias From: Baesken, Matthias Sent: Mittwoch, 24. Juli 2019 13:17 To: security-dev at openjdk.java.net Cc: 'naoto.sato at oracle.com' Subject: RFR : [XS] 8228578: fix CFData object leak in macosx KeystoreImpl.m Hello, please review the following small patch . In KeystoreImpl.m we call CFDataCreate at one place. According to https://developer.apple.com/documentation/corefoundation/1542359-cfdatacreate?language=objc the return value of CFDataCreate is : "A new CFData object, or NULL if there was a problem creating the object. Ownership follows the The Create Rule." Following the "Create Rule" , we have to release the return value to avoid leaks. Or do I miss something ? Bug / (no webrev currently because I have some technical issues at the moment with webrev creation, getting connection reset by peer for some reason ) https://bugs.openjdk.java.net/browse/JDK-8228578 patch is attached, and change also below . Thanks, Matthias Change : # HG changeset patch # Parent 042dfb697624926507649a4a8ad17a5e6730ba04 8228578: fix CFData object leak in macosx KeystoreImpl.m diff -r 042dfb697624 -r 9f43fea81900 src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m --- a/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m Tue Jul 23 20:03:03 2019 -0700 +++ b/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m Wed Jul 24 12:36:12 2019 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -562,6 +562,9 @@ err = SecKeychainItemImport(cfDataToImport, NULL, &dataFormat, NULL, 0, ¶mBlock, defaultKeychain, &createdItems); + if (cfDataToImport != NULL) { + CFRelease(cfDataToImport); + } if (err == noErr) { SecKeychainItemRef anItem = (SecKeychainItemRef)CFArrayGetValueAtIndex(createdItems, 0); -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Jul 24 13:41:06 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 24 Jul 2019 21:41:06 +0800 Subject: RFR : [XS] 8228578: fix CFData object leak in macosx KeystoreImpl.m In-Reply-To: References: Message-ID: <21487949-33F3-4AE4-959D-FEE2453C5E3F@oracle.com> This looks fine to me. You might want to add a noreg-* label to the bug. Maybe noreg-cleanup? Thanks, Max > On Jul 24, 2019, at 7:35 PM, Baesken, Matthias wrote: > > Hello, here is the webrev for easier review . > > Bug/webrev (after my webrev creation works again) : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228578.0/ > > https://bugs.openjdk.java.net/browse/JDK-8228578 > > Best regards, Matthias > > From: Baesken, Matthias > Sent: Mittwoch, 24. Juli 2019 13:17 > To: security-dev at openjdk.java.net > Cc: 'naoto.sato at oracle.com' > Subject: RFR : [XS] 8228578: fix CFData object leak in macosx KeystoreImpl.m > > Hello, please review the following small patch . > > In KeystoreImpl.m we call CFDataCreate at one place. According to > > https://developer.apple.com/documentation/corefoundation/1542359-cfdatacreate?language=objc > > the return value of CFDataCreate is : "A new CFData object, or NULL if there was a problem creating the object. Ownership follows the The Create Rule." > > Following the "Create Rule" , we have to release the return value to avoid leaks. > Or do I miss something ? > > > Bug / (no webrev currently because I have some technical issues at the moment with webrev creation, getting connection reset by peer for some reason ) > > https://bugs.openjdk.java.net/browse/JDK-8228578 > > patch is attached, and change also below . > > Thanks, Matthias > > > > Change : > > # HG changeset patch > # Parent 042dfb697624926507649a4a8ad17a5e6730ba04 > 8228578: fix CFData object leak in macosx KeystoreImpl.m > > diff -r 042dfb697624 -r 9f43fea81900 src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m > --- a/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m Tue Jul 23 20:03:03 2019 -0700 > +++ b/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m Wed Jul 24 12:36:12 2019 +0200 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -562,6 +562,9 @@ > > err = SecKeychainItemImport(cfDataToImport, NULL, &dataFormat, NULL, > 0, ¶mBlock, defaultKeychain, &createdItems); > + if (cfDataToImport != NULL) { > + CFRelease(cfDataToImport); > + } > > if (err == noErr) { > SecKeychainItemRef anItem = (SecKeychainItemRef)CFArrayGetValueAtIndex(createdItems, 0); From sean.mullan at oracle.com Wed Jul 24 15:30:35 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 24 Jul 2019 11:30:35 -0400 Subject: [13] RFR 8228456: Enhance tests after JDK-8217375 In-Reply-To: References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> Message-ID: <194a8681-6c67-4d1d-4338-a92bfc5da06c@oracle.com> On 7/21/19 10:02 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8228456/webrev.00/ > > The change is contributed by Philipp Kunz. Since we are now in RDP 2 and we are not allowed to fix non-test P3 (and lower) bugs. I've removed all src/ changes in Philipp's patch (If I read correctly, is mostly on renaming methods, and brings no behavior change) and made necessary change in test codes to use original method names. It is a pretty large set of changes though. If they are not needed to fix any issues in 13, I would recommend pushing to the jdk mainline. We can always decide to backport to 13 or 13u later once we get more assurance they are stable. > I haven't read the changes yet. I only made sure they pass on my own system. Oracle's test farm is in maintenance during the weekend. Since you are not the contributor, I think it is ok for you to be the main Reviewer. --Sean From jamil.j.nimeh at oracle.com Wed Jul 24 20:03:06 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 24 Jul 2019 13:03:06 -0700 Subject: RFR 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working In-Reply-To: References: <6afc52c5-cf29-827a-0591-27714bcd6068@oracle.com> Message-ID: Hi Valerie, I don't recall if I ever responded to you on this as I stepped away from this to work another issue.? Comments are in-line, and I have another email following this one with more because you had extra comments in that other email. Thanks, --Jamil On 7/9/2019 7:44 PM, Valerie Peng wrote: > > > > - line 174: considering add AES128/192/256 w/ CBC oids as they are > used by both AlgorithmParameters and Cipher entries. > JN: I'm not exactly sure what you're asking for here.? The 3 OIDs in that call to createAliasesWithOid are the OIDs for AES128/192/256-CBC.? If you're asking me to use the variables "aes128Oid", "aes192Oid" and "aes256Oid" then I cannot use those just by themselves.? They'd end up having to get "2" appended to them, just as it is done for the AES//CBC Cipher lines around 245-290.? Is there some advantage to doing that over what's currently there?? Am I missing the point of what you're asking for? > > > > - line 108 seems redundant? > > - line 131-132: why not simply: (iv.length != (blockSizeInBits >> 3)? > JN: I like your approach much better, I'll fix that. > > - line 135: after checking iv.length, should we check for extra > trailing bytes and error out if (val.data.available() > 0)? > JN: It turns out not to be necessary.? The encapsulation of the DER encoded data into the DerValue as the first thing done already checks to make sure there's no extra data.? I did add a test to RC5ParametersTests that adds another block of DER-encoded data so at least we test that specific case explicitly. > > - line 191 encoder can be moved inside the block of iv-dumping code as > it's only used there. > JN: No problem.? Will do. > > > > > > - Can the tests be renamed? So it's clear that they are tests instead > of some utility classes for test. > JN: Sure, I can just make it Tests.java > > - The ASN.1 encoding are generated offline using your changes? Just > curious. > JN: The ASN.1 encodings for PBES2Parameters was done using OpenSSL. For RC5Parameters, I did those by hand since OpenSSL doesn't automatically generate them through any tool like the pkcs8 command.? Fortunately they're small ASN.1 structures, so it's pretty easy to crank out with a hex editor. > Thanks, > Valerie > On 7/8/2019 4:50 PM, Valerie Peng wrote: >> >> Hi Jamil, >> >> Sorry for the late reply. It's been a long while since I looked at >> this PBES2 scheme and I need to think a few things through. >> >> >> >> - line 29-30, 37, I don't see Constructor, BigInteger, and ArrayList >> being used? >> >> - line 158: the pbes2AlgorithmNameis initialized to null. Is it our >> intention to return null if toString() is called upon an PBES2 >> AlgorithmParameters object without init(...) call? >> >> - line 176: does "keysize" means the optional keyLength field inside >> the PBES2-params struct? Its value is from various sources. A proper >> definition would help ensure its value is correctly set. >> >> - line 207: If encoding to a DerOutputStream, why not decode using a >> DerInputStream? >> >> - line 203: based on RFC3370, 5911, the preferred way for HMAC is to >> omit the parameters instead of encoding a NULL. So, we probably >> should not encode a null on line 203. Also, for decode, line 520 to >> 522 can be moved here so that the decode can handle both cases, i.e. >> omitted and present NULL, for max compatibility. >> >> - line 295 - 298: if there is a comment on line 271 which explains >> when "keyLen" is for, then we don't need this block of comment. >> Essentially, keyLen holds that restricted key length value, right? >> KEYLEN_ANY means no restriction whatsoever. >> >> - line 376: the impl of validateEncParams() seems to allow null >> cipherParams as it returns immediately if its value is null. I am not >> sure if we should allow null cipherParam though as this cipherParam >> object is needed for encoding "encryptionScheme" field of the >> PBES2-params struct. For example, if the parameters field for >> AES_128_CBC must contain 16-byte IV, then a null cipherParams should >> be rejected. Same goes to other encryption schemes. >> >> - line 379: Since encyptionType is found using cipherAlgo and keysize >> in the constructor, why can't we just format >> encryptionType.schemeName as in getEncSchemeName()? >> >> - line 419-422: Shouldn't this check be moved up to line 414, i.e. in >> the block of code which handles the buggy encoding? Otherwise, it >> looks like a duplicate check of line 400. >> >> - line 494, 630, 735: change the check to use KEYLEN_ANY? >> >> -line 638: extra indentation? >> >> - line 725-752: Seems better to check the IV length before checking >> and set the keysize. >> >> - line 788: May return RC2_-1 or RC5_-1? >> >> Will send you comments for the rest of webrev separately. >> >> Thanks, >> >> Valerie >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> || >> >> On 6/20/2019 6:59 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> I've updated the fix to 8076999 with the following changes: >>> >>> * We now use sun.security.x509.AlgorithmId and it internally uses >>> AlgorithmParameters implementations to handle the DER encoding >>> and decoding of encryption scheme parameters. >>> o This means that we need to add one new standard name and >>> some OID aliases for some AlgorithmParameters.? See the CSR >>> link below for details. >>> * Added a new RC5Parameter AlgorithmParameters implementation to >>> SunJCE, plus unit tests. >>> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.02 >>> >>> >>> On 5/24/2019 3:51 PM, Jamil Nimeh wrote: >>>> >>>> Hello all, happy Friday! >>>> >>>> Please review the following CSR and code review.? This makes >>>> updates to the SunJCE implementation of PBES2-based >>>> AlgorithmParameters.? Many of the details are in the CSR (see the >>>> link below).? But a short list of the updates: >>>> >>>> * Add DER Encode/Decode support for the following OIDS from RFC 8018: >>>> o PRFs: HmacSHA512/224, HmacSHA512/256 >>>> o Encryption Schemes: AES-192-CBC, DES, Triple-DES, RC2, RC5 >>>> * Enforce init-time type consistency between >>>> AlgorithmParameterSpec objects and the algorithms they are used >>>> with (i.e. No using RC5ParameterSpec with AES-128-CBC. >>>> * Enforce sanity checks on AlgorithmParameterSpec objects used to >>>> init (e.g. IV length checks, integer range checks, etc.) >>>> * Fixed a bug where explicit DER decoding of the optional key >>>> length field in PBKDF2-params would cause the PRF to be forced >>>> to HmacSHA1 even if the DER indicated otherwise >>>> * Allow incoming DER encoded AlgorithmIdentifier structures to >>>> honor the OPTIONAL qualifier on the parameters field for both >>>> PRFs and Encryption Schemes. >>>> * If a null encryption scheme AlgorithmParameterSpec is provided >>>> during init time, omit the PBES2-params.encryptionScheme's >>>> parameter segment since it is OPTIONAL per the ASN.1 from RFC 5280 >>>> >>>> More details are in the CSR. >>>> >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.01/ >>>> >>>> --Jamil >>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Wed Jul 24 20:04:40 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 24 Jul 2019 13:04:40 -0700 Subject: RFR 8076999: SunJCE support of password-based encryption scheme 2 params (PBES2) not working In-Reply-To: References: <6afc52c5-cf29-827a-0591-27714bcd6068@oracle.com> Message-ID: <2e3f9de9-34b4-51a6-5146-f0aa2c64227a@oracle.com> Hi Valerie, part 2 of my comments (also in-line): Thanks, --Jamil On 7/9/2019 8:59 PM, Valerie Peng wrote: > > Hi Jamil, > > Please find replies inline below... > > On 7/9/2019 9:03 AM, Jamil Nimeh wrote: >> Hi Valerie, thanks for the comments: >> >> On 7/8/2019 4:50 PM, Valerie Peng wrote: >>> >>> Hi Jamil, >>> >>> Sorry for the late reply. It's been a long while since I looked at >>> this PBES2 scheme and I need to think a few things through. >>> >>> >>> >>> - line 29-30, 37, I don't see Constructor, BigInteger, and ArrayList >>> being used? >>> >> JN: I must have removed them in my local copy of the code since I >> posted the .02 webrev.? They'll be gone in this next webrev. >>> >>> - line 158: the pbes2AlgorithmNameis initialized to null. Is it our >>> intention to return null if toString() is called upon an PBES2 >>> AlgorithmParameters object without init(...) call? >>> >> JN: Hmm...that's a good question.? In the case of PBES2 alg params >> with a fully qualified name (PBEWithAnd) the >> pbes2AlgorithmName is initialized to whatever static class is >> instantiated from SunJCE.java.? So we don't have to worry there.? In >> the case of actually using "PBES2" (or its OID counterpart, which is >> more common), it looks like even before my changes it returned null. >> What do you think about returning "PBES2" instead?? Once it goes >> through init the field will be set to whatever it truly is based on >> the DER encoding received. > > Sure, PBES2 is way better than just null... > >>> - line 176: does "keysize" means the optional keyLength field inside >>> the PBES2-params struct? Its value is from various sources. A proper >>> definition would help ensure its value is correctly set. >>> >> JN: Well, keysize does mean that, but it affects the resulting >> toString name and can also have an impact on init-time consistency >> checks in some cases. >> >> Keysize is one of the challenging parts of this class, because it can >> be defined in multiple ways.? It can be implicit (such as in DES or >> DESede), it can be explicit by OID like it is for AES, and it can be >> defined by parameters such as in RC2 - there is one OID, no matter >> whether you do RC2_40, RC2_64 or RC2_128.? Or it can be not defined >> at all (RC5) in which case you have to assume a reasonable default >> (like I assume RC5_128) or hope that the KDF parameter segment >> asserts a key length.? So it gets set in different parts of the code >> depending on the algorithm and how it's specified. >> >> Maybe you can expand a bit on what you're looking for by "proper >> definition" and I can try to make that happen. > > Well, one straightforward thought is to map "keysize" strictly based > only on the optional keyLength field of the ASN.1 encoding. The > keysize default value can be left to the particular cipher or key > derivation impl. > JN: I think for certain ciphers, you run into a chicken/egg problem if the key length is not defined.? If you were using something with a variable key length where that length can be defined in the encryption scheme parameters (RC2 is the example I am thinking of), if the encoding does not specify a PBKDF2 key length you cannot safely assume a default value as your default length may not agree with what you later parse in encryption scheme parameters section. From what I have seen for RC2, openssl appears to always encode the key length, but that is just one data point.? I don't know how it would handle an inbound PBES2 parameters with an omitted key length though. Since it is a "convenience" field, I'm hesitant to make it the only source of information to use for the key length, especially where things like RC2's parameters have a more clear definition of what effective key bits means.? Where the key length is already defined by the cipher/OID, then a default value makes sense, and any declared value I would think would have to be consistent.? Having not (yet) tried to use edge cases where we mismatch key length against the implicit value, it's hard to know what to do here.? I will give it a try and see what openssl does with these kinds of PKCS#8 keys. >> >>> - line 207: If encoding to a DerOutputStream, why not decode using a >>> DerInputStream? >>> >> JN: There's no reason why it couldn't be done that way.? I used >> DerValue mainly because decoding in PBES2Parameters has been done >> with DerValue objects from before I started working with the code.? >> So I kept it the same since it seemed to work well. > DerInputStream makes more sense than DerValue as DerValue contains tag > and length. Essentially you just want to get the data you want off the > stream just like where you directly put out the bytes to the stream in > decoding case. JN: Since we are only doing HMAC-SHA* variants that have no parameters, and that's the only place ParamProcessor is used anymore, I'm just going to remove the whole thing and directly handle the optional null in parseKDF.? I'll omit the NULL entirely in engineGetEncoded.? If the specs ever allow for PRFs that have parameters we can go back and deal with ParamProcessor then.? It made more sense to have it when encryption schemes had their own ParamProcessors but that's handled by AlgorithmId / AlgorithmParameters now. >>> >>> - line 203: based on RFC3370, 5911, the preferred way for HMAC is to >>> omit the parameters instead of encoding a NULL. So, we probably >>> should not encode a null on line 203. Also, for decode, line 520 to >>> 522 can be moved here so that the decode can handle both cases, i.e. >>> omitted and present NULL, for max compatibility. >>> >> JN: From all the OpenSSL parameter blocks I've looked at, Hmac params >> will assert NULL.? There's some interesting history to >> AlgorithmIdentifier's optional parameter field when there are no >> parameters in RFC 4055, sec 2.1.? In short, a change happened in the >> 1997 syntax that removed "optional" which was later fixed, but by >> then people were getting around the now mandatory field by putting >> NULL in there.? Honestly, I see NULLs asserted more commonly than it >> being omitted for message digest and HMAC AlgorithmIdentifiers.? But >> that might just be me.? According to 4055, omitting the parameters >> field is the correct way to do it, you are correct about that.? >> Implementations are supposed to accept both forms.? I stuck with it >> because a.) we were already doing that and nobody was having problems >> with it, b.) I see NULL asserted more frequently so it seemed like >> the safer way to go. >> >> I can try omitting it and see if openssl will accept it.? If it does >> then I can make the change permanent.? If it doesn't like it, we >> should probably leave the NULL in there.? I've got no idea how anyone >> else encodes AlgorithmIdentifiers...maybe I can play around with NSS >> and see what it does with Hmac parameters if I can find a tool that >> will encode some. >> > Sure~ >>> >>> - line 295 - 298: if there is a comment on line 271 which explains >>> when "keyLen" is for, then we don't need this block of comment. >>> Essentially, keyLen holds that restricted key length value, right? >>> KEYLEN_ANY means no restriction whatsoever. >>> >> JN: Or it can mean that the key length is implicit (e.g. DES is >> always 56 bits, so I don't need to encode it in ASN.1 and I don't >> need toString to say DES_56...DES is fine). >> >> Maybe rather than a comment on 271, maybe a similar description for >> KEYLEN_ANY up on 154 might be a good way to go. >>> >>> - line 376: the impl of validateEncParams() seems to allow null >>> cipherParams as it returns immediately if its value is null. I am >>> not sure if we should allow null cipherParam though as this >>> cipherParam object is needed for encoding "encryptionScheme" field >>> of the PBES2-params struct. For example, if the parameters field for >>> AES_128_CBC must contain 16-byte IV, then a null cipherParams should >>> be rejected. Same goes to other encryption schemes. >>> >> JN: There are tests in the PKCS#12 family of tests that were breaking >> when I strictly enforced non-null cipherParams from the >> PBEParameterSpec.? I didn't want to risk messing up a use case in >> PKCS#12-land that didn't apply directly to what I was fixing.? What I >> do need to do is have it fail on encoding when null parameters are >> used, that will be in the next rev of the code.? I hate not being >> able to fail-fast, but it would at least remain consistent with how >> PBES2Parameters works today. > Hmm, interesting, maybe PKCS#12 uses PBES2 as PBES1? Well, I don't > know the history of all this. Given that we are in RPD1 phase already, > I understand with the approach you chose. >>> >>> - line 379: Since encyptionType is found using cipherAlgo and >>> keysize in the constructor, why can't we just format >>> encryptionType.schemeName as in getEncSchemeName()? >>> >> JN: Hmm...maybe we can do that.? Let me give it a try and see what >> happens. >>> >>> - line 419-422: Shouldn't this check be moved up to line 414, i.e. >>> in the block of code which handles the buggy encoding? Otherwise, it >>> looks like a duplicate check of line 400. >>> >> JN: I don't think so.? I think you need both.? On line 400, >> regardless of the structure (PBES2 AlgorithmIdentifier vs. >> PBES2-params) it must start with a sequence, so that check has to be >> there.? If it's out at the PBES2 AlgId layer (the error, which would >> manifest itself as an OID as the next object in the DerValue stream) >> then line 414 peels that away and what's next is your PBKDF2-params. >> >> Line 419 has to check if the next ASN.1 structure that sits as a peer >> to PBKDF2-params is also a sequence, which it has to be, therefore >> the check on the tag is performed before sending it in to be parsed. >> > The DER code can be confusing... Let me re-phrase my comments and > questions. > > Line 413, 414, I think we should check for SEQUENCE tag on the newly > peeled "pBES2_params", agree? > JN: Yes, I think that's a sensible check to perform. > > By calling data.getDerValue(), we are essentially peeling one layer > off, right? If you still agree with me at this point, then note that > pBES2_params is a local variable and its value should be the same > unless explicitly re-assigned (as on line 413). Thus, per my reading > of the code, the tag that you are checking on line 419 is not the one > for encryption scheme, but rather the outer sequence tag encapsulating > kdf and encryption scheme. Its current location is very misleading > though, in between kdf and encryption scheme. To really check the tag > for kdf and encryption scheme, the tag checking should be in > parseKDF(...) and parseES(...) against the DerValue argument. > JN: Ah, I think I see what you're getting at.? I think you may be right - let me see if I can rework this a bit.? It might make more sense to start at the very beginning with a DerInputStream.getSequence and then see what element zero is.? if it's an OID, we can just skip to the next object (the outer sequence) and do another DerInputStream.getSequence() which should give us the two AlgorithmIdentifiers.? That might be a more straightforward parsing approach.? Let me experiment a bit and see what I can come up with. > Thanks, > Valerie >>> >>> - line 494, 630, 735: change the check to use KEYLEN_ANY? >>> >> JN: makes sense. >>> >>> -line 638: extra indentation? >>> >> JN: Yes, fixed. >>> >>> - line 725-752: Seems better to check the IV length before checking >>> and set the keysize. >>> >> JN: OK I can switch the order on those. >>> >>> - line 788: May return RC2_-1 or RC5_-1? >>> >> JN: Hmm...maybe in the DER parsing case, now that >> AlgorithmId/AlgorithmParameters handles the DER decoding I can't set >> the keysize as part of the parsing process any longer.? Let me take a >> closer look at it and get back to you on that one.? I think RC5 can >> fall into that trap, not sure about RC2. >>> >>> Will send you comments for the rest of webrev separately. >>> >>> Thanks, >>> >>> Valerie >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> || >>> >>> On 6/20/2019 6:59 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> I've updated the fix to 8076999 with the following changes: >>>> >>>> * We now use sun.security.x509.AlgorithmId and it internally uses >>>> AlgorithmParameters implementations to handle the DER encoding >>>> and decoding of encryption scheme parameters. >>>> o This means that we need to add one new standard name and >>>> some OID aliases for some AlgorithmParameters. See the CSR >>>> link below for details. >>>> * Added a new RC5Parameter AlgorithmParameters implementation to >>>> SunJCE, plus unit tests. >>>> >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.02 >>>> >>>> >>>> On 5/24/2019 3:51 PM, Jamil Nimeh wrote: >>>>> >>>>> Hello all, happy Friday! >>>>> >>>>> Please review the following CSR and code review.? This makes >>>>> updates to the SunJCE implementation of PBES2-based >>>>> AlgorithmParameters.? Many of the details are in the CSR (see the >>>>> link below).? But a short list of the updates: >>>>> >>>>> * Add DER Encode/Decode support for the following OIDS from RFC >>>>> 8018: >>>>> o PRFs: HmacSHA512/224, HmacSHA512/256 >>>>> o Encryption Schemes: AES-192-CBC, DES, Triple-DES, RC2, RC5 >>>>> * Enforce init-time type consistency between >>>>> AlgorithmParameterSpec objects and the algorithms they are >>>>> used with (i.e. No using RC5ParameterSpec with AES-128-CBC. >>>>> * Enforce sanity checks on AlgorithmParameterSpec objects used >>>>> to init (e.g. IV length checks, integer range checks, etc.) >>>>> * Fixed a bug where explicit DER decoding of the optional key >>>>> length field in PBKDF2-params would cause the PRF to be forced >>>>> to HmacSHA1 even if the DER indicated otherwise >>>>> * Allow incoming DER encoded AlgorithmIdentifier structures to >>>>> honor the OPTIONAL qualifier on the parameters field for both >>>>> PRFs and Encryption Schemes. >>>>> * If a null encryption scheme AlgorithmParameterSpec is provided >>>>> during init time, omit the PBES2-params.encryptionScheme's >>>>> parameter segment since it is OPTIONAL per the ASN.1 from RFC 5280 >>>>> >>>>> More details are in the CSR. >>>>> >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8221936 >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076999 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8076999/webrev.01/ >>>>> >>>>> --Jamil >>>>> >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp.kunz at paratix.ch Sat Jul 20 20:49:50 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sat, 20 Jul 2019 22:49:50 +0200 Subject: RFR 8217375: jarsigner breaks old signature with long lines in manifest In-Reply-To: References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> Message-ID: <1563655790.2506.7.camel@paratix.ch> Hi Max and everyone, ?* Indeed, [^\"] does not work with quotes inside CN. I agree to your change. ?* I went through the patch again myself and tried to understand what I did half a year ago and added and changed some comments and renamed a few identifiers so that I hope it becomes clearer. Particularly PreserveRawManifestEntryAndDigest is worth mentioning and had a bug in lineWidth70. Noteworthy is the test case with emptyJarTrailingSeqAddFile which is now better documented. ?* I also renamed atts to attrs. ?* It also still works without the Resources changes. ?* I removed testNameEmptyTrusted from EmptyIndividualSectionName after having convinced myself it is not necessary. Any other opinion on this welcome. ?* I moved some common functions used in many tests to Utils. Utils.echoManifest now prints manifests with non-printable characters escaped in Java style but that was in the previous patch already I think. It's used in more tests now than before. ?* I added a test testAddManifestMainAttributesFile in MainAttributesConfused that shows where the problems were with a file named Manifest-Main-Attributes inside a signed jar and that it works now. ?* I increased the timeout of PreserveRawManifestEntryAndDigest after it timed out on my machine a few times. The current timeout value is still pretty much arbitrary. ?* I defined KS_ARGS in various tests to be re-used with repeated jarsigner command line arguments. I'm sorry for recently not responding quickly. I admit that my personal interest has not increased with the latest development of webstart and I also have other duties or distractions. I welcome everyone to contribute missing parts or a review or an opinion. As I currently see it, the following parts are not?yet complete. 1. I suggest Compatibility test be run with different JDK versions configured just like before with a focus on TSA now also with jar signinig compatibility across JDK versions on a central and powerful test infrastructure which is achieved by invoking Compatibility test again with different arguments. SignTwice is an example for that with only one JDK version. 2. Compatibility test should probably be thoroughly refactored. This can be done well after the merge in my opinion if no seriously harmful changes are revealed in a review. 3. I still did not have time to pick up Max's idea to add a jar file in binary form to the sources that would allow to test a current JDK version against it by trying to reproduce it identically. That would at least make incompatibilities detected earlier than with Compatibility test. How much such a test would overlap with the current Compatibility test once integrated in a build like before with TSA can be told only after it exists. In my opinion this makes a lot of sense in any case. 4. Somehow I still have not the feeling that someone has thoroughly reviewed the whole patch. It was mentioned that the main source changes look good but is that what a review takes? There are so many subtle changes mostly in ManifestDigester that I doubt there is way around a close look into the tests. It may be all right to check the details only after all the trivial checks passed but that patch has accumulated so much effort until now I really would appreciate some confirmation that everything looks somewhat promising so far, however non-committal. I might have missed a hint and feel still quite new as openjdk contributor. 5. Remove all the FIXED_8217375 stuff. In my opinion this requires that after the patch is more or less stable that someone verifies that all the test cases that did not exist before the patch continue to pass unchanged and test coverage is appropriate to calibrate existing behavior. Usually tests should exist before but this here is certainly one and hopefully a rare exception. It would be of no use if some tests were wrong claiming some behavior has not changed and with signed jars and digesting manifests every single difference invalidates the signatures without mercy. Actually removing the FIXED_8217375 stuff is then trivial. Lot of fuzzy talk written, please accept my apology for spamming this way. I always appreciate any comment, hint, advice or anything. Regards,Philipp On Tue, 2019-07-16 at 21:29 +0800, Weijun Wang wrote: > I made another small change > > diff -iu > b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.j > ava > b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.j > ava > --- > b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.j > ava > +++ > b/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.j > ava > @@ -717,7 +717,7 @@ > ?????????????????????+ "??Digest algorithm: " + > signItem.expectedDigestAlg() > ?????????????????????+ (signItem.tsaIndex < 0 ? "" : > ???????????????????????")|(" > -????????????????????+ "Timestamped by \"[^\"]+\" on .*" > +????????????????????+ "Timestamped by \".+\" on .*" > ?????????????????????+ ")|(" > ?????????????????????+ "??Timestamp digest algorithm: " > ?????????????????????????????+ signItem.expectedTsaDigestAlg() > > This is because there can be quotation marks inside CN. For example, > > ? Timestamped by "CN="Sectigo RSA Time Stamping Signer #1", O=Sectigo > Limited, L=Salford, ST=Greater Manchester, C=GB" on Tue Jul 16 > 12:23:29 UTC 2019 > > Thanks, > Max > > > > On Jul 16, 2019, at 2:13 PM, Weijun Wang > > wrote: > > > > I'd also like to revert the changes to > > src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resource > > s.java. Your change strips some trailing whitespaces but not all of > > them. This will trigger a re-translation of all Resources files and > > I think that is unnecessary. > > > > Will any of your new tests fail because of the revert? I'll run all > > tests soon. > > > > Thanks, > > Max > > > > > > > On Jul 16, 2019, at 11:34 AM, Weijun Wang > > > wrote: > > > > > > 7/18 is near. If there is no new webrev, I'll push webrev.02 with > > > SignTwice.java disabled. We can still modify tests before 8/8. > > > > > > Thanks, > > > Max > > > > > > > On Jul 10, 2019, at 10:34 AM, Weijun Wang > > > om> wrote: > > > > > > > > [off the list] > > > > > > > > Hi Philipp, > > > > > > > > Do you have a new patch? The RDP 2 [1] starts on 7/18 and after > > > > that we will only be able to fix P1-P2 bugs after approvals. > > > > > > > > Let's get the changeset integrated before RDP 2 once there is > > > > no problem in src/. We can adjust the tests before RC (8/8). > > > > > > > > Thanks, > > > > Max > > > > > > > > [1] https://openjdk.java.net/jeps/3#rdp-2 > > > > > > > > > On Jul 3, 2019, at 6:27 PM, Weijun Wang > > > > om> wrote: > > > > > > > > > > > > > > > > > > > > > On Jul 3, 2019, at 4:06 PM, Philipp Kunz > > > > > tix.ch> wrote: > > > > > > > > > > > > Hi Max, > > > > > > > > > > > > Do I understand correctly that your question refers to > > > > > > ????if (e == null && MF_MAIN_ATTRS.equals(name)) { > > > > > > ????????e = getMainAttsEntry(); > > > > > > ????} > > > > > > ? > > > > > > > > > > Yes. > > > > > > > > > > > If so, because this sticks closest to the previous > > > > > > behavior. According to src/java.base/share/classes/module- > > > > > > info.java, ManifestDigester is not publicly exported but > > > > > > how can it then be used then in JarVerifier in > > > > > > java.util.jar? If you or someone can confirm that we can > > > > > > identify all callers, I'd prefer to remove above three > > > > > > lines of code. > > > > > > > > > > It's not publicly exported therefore cannot be used by an > > > > > application, but it's accessible by java.util.jar which is > > > > > also in the java.base module. > > > > > > > > > > It can also be accessed by JDK modules listed in the "exports > > > > > sun.security.util to" block of > > > > > java.base/share/classes/module-info.java. > > > > > > > > > > Anyway any caller must be inside JDK. IntelliJ IDEA tells me > > > > > its only SignatureFileVerifier and JarSigner. Hopefully > > > > > whatever IDE you are using it gives the same result. > > > > > > > > > > > Otherwise, with above three lines, main attributes and an > > > > > > entry with name MF_MAIN_ATTRS will still be confused for > > > > > > all those code continuing to call get as before the patch > > > > > > if an entry with such a name exists just like before. > > > > > > However, with the patch, all (known) places that call > > > > > > ManifestDigester.get* are lines 539 and 606 in > > > > > > SignatureFileVerifier with the patch, 539 calling > > > > > > getMainAttsEntry without any ambiguity and 606 calling > > > > > > get(String, b) always expecting the entry for a section > > > > > > that is present and would otherwise not be known to pass as > > > > > > an argument anyway, provided the signature file does not > > > > > > contain more entries than the manifest or entries have not > > > > > > been removed from the manifest after signing, should work > > > > > > correctly, I guess. If we cannot get rid of those three > > > > > > lines, another test for those edge cases should probably be > > > > > > added, shouldn't it, if not to support the previous > > > > > > confusion at least to show it now works as expected? > > > > > > > > > > > > What exactly did you mean with "coding error"? > > > > > > > > > > Not sure. I don't know if any bad thing would happen if a > > > > > file named "Manifest-Main-Attributes" is out inside a jar > > > > > file. > > > > > > > > > > > Along with removing above three lines of code, two tests > > > > > > would have to be adjusted. > > > > > > FindHeaderEndVsManifestDigesterFindFirstSection on lne 235 > > > > > > and DigestInput on line 270. > > > > > > > > > > That's OK. No real app should call methods in this class > > > > > directly. > > > > > > > > > > Thanks, > > > > > Max > > > > > > > > > > > Regards, > > > > > > Philipp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2019-07-01 at 15:41 +0800, Weijun Wang wrote: > > > > > > > https://cr.openjdk.java.net/~weijun/8217375/webrev.02 > > > > > > > uploaded. There are still several trailing spaces and > > > > > > > I've removed them. > > > > > > > > > > > > > > I just ran a test job: SignTwice.java failed on Windows > > > > > > > with `failed to clean up files after test`. Most likely a > > > > > > > file is not closed. > > > > > > > > > > > > > > The src change looks good. In fact, I am wondering if we > > > > > > > need to support ManifestDigester.get(MF_MAIN_ATTRS, b) at > > > > > > > all. Is it possible we miss a coding error because of it? > > > > > > > > > > > > > > I'll take a look at the tests. > > > > > > > > > > > > > > Thanks, > > > > > > > Max > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 8217375-jarsignerbreaksexistingsignatures-20190719.patch Type: text/x-patch Size: 313248 bytes Desc: not available URL: From weijun.wang at oracle.com Thu Jul 25 00:27:28 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jul 2019 08:27:28 +0800 Subject: [13] RFR 8228456: Enhance tests after JDK-8217375 In-Reply-To: <194a8681-6c67-4d1d-4338-a92bfc5da06c@oracle.com> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> <194a8681-6c67-4d1d-4338-a92bfc5da06c@oracle.com> Message-ID: <10B3528C-CE25-4A51-BB50-AB9622CA3394@oracle.com> > On Jul 24, 2019, at 11:30 PM, Sean Mullan wrote: > > On 7/21/19 10:02 PM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8228456/webrev.00/ >> The change is contributed by Philipp Kunz. Since we are now in RDP 2 and we are not allowed to fix non-test P3 (and lower) bugs. I've removed all src/ changes in Philipp's patch (If I read correctly, is mostly on renaming methods, and brings no behavior change) and made necessary change in test codes to use original method names. > > It is a pretty large set of changes though. > > If they are not needed to fix any issues in 13, I would recommend pushing to the jdk mainline. We can always decide to backport to 13 or 13u later once we get more assurance they are stable. Most of them are cleanups. The only big change is on PreserveRawManifestEntryAndDigest.java which is failing intermittently on solaris-sparc now. Therefore I think we should fix it in 13. > >> I haven't read the changes yet. I only made sure they pass on my own system. Oracle's test farm is in maintenance during the weekend. > > Since you are not the contributor, I think it is ok for you to be the main Reviewer. Yes, I understand. Thanks, Max > > --Sean From weijun.wang at oracle.com Thu Jul 25 03:32:02 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jul 2019 11:32:02 +0800 Subject: [13] RFR 8228602: Add sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java to problem list Message-ID: The new test introduced by JDK-8217375 fails a lot on solaris-sparc, please review this patch to add it to the problem list. Please note that I use "solaris-all" instead of "solaris-sparcv9". Every other line related to solaris uses solaris-all and I cannot be sure if solaris-sparcv9 would work. The bug related is at https://bugs.openjdk.java.net/browse/JDK-8228431 . This bug is https://bugs.openjdk.java.net/browse/JDK-8228602 . Thanks, Max diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -662,6 +662,7 @@ sun/security/tools/keytool/WeakAlg.java 8224644 solaris-all sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all +sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java 8228431 solaris-all javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java 8212096 generic-all javax/net/ssl/SSLSocket/Tls13PacketSize.java 8224718 generic-all -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Thu Jul 25 09:09:57 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 25 Jul 2019 09:09:57 +0000 Subject: RFR : [XS] 8228578: fix CFData object leak in macosx KeystoreImpl.m In-Reply-To: <21487949-33F3-4AE4-959D-FEE2453C5E3F@oracle.com> References: <21487949-33F3-4AE4-959D-FEE2453C5E3F@oracle.com> Message-ID: Thanks for the review . Do I need a second review for this one ? Best regards, Matthias > -----Original Message----- > From: Weijun Wang > Sent: Mittwoch, 24. Juli 2019 15:41 > To: Baesken, Matthias > Cc: security-dev at openjdk.java.net; naoto.sato at oracle.com > Subject: Re: RFR : [XS] 8228578: fix CFData object leak in macosx > KeystoreImpl.m > > This looks fine to me. > > You might want to add a noreg-* label to the bug. Maybe noreg-cleanup? > > Thanks, > Max > > > On Jul 24, 2019, at 7:35 PM, Baesken, Matthias > wrote: > > > > Hello, here is the webrev for easier review . > > > > Bug/webrev (after my webrev creation works again) : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228578.0/ > > > > https://bugs.openjdk.java.net/browse/JDK-8228578 > > > > Best regards, Matthias > > > > From: Baesken, Matthias > > Sent: Mittwoch, 24. Juli 2019 13:17 > > To: security-dev at openjdk.java.net > > Cc: 'naoto.sato at oracle.com' > > Subject: RFR : [XS] 8228578: fix CFData object leak in macosx > KeystoreImpl.m > > > > Hello, please review the following small patch . > > > > In KeystoreImpl.m we call CFDataCreate at one place. According to > > > > https://developer.apple.com/documentation/corefoundation/1542359- > cfdatacreate?language=objc > > > > the return value of CFDataCreate is : "A new CFData object, or NULL if > there was a problem creating the object. Ownership follows the The Create > Rule." > > > > Following the "Create Rule" , we have to release the return value to avoid > leaks. > > Or do I miss something ? > > > > > > Bug / (no webrev currently because I have some technical issues at the > moment with webrev creation, getting connection reset by peer for some > reason ) > > > > https://bugs.openjdk.java.net/browse/JDK-8228578 > > > > patch is attached, and change also below . > > > > Thanks, Matthias > > > > > > > > Change : > > > > # HG changeset patch > > # Parent 042dfb697624926507649a4a8ad17a5e6730ba04 > > 8228578: fix CFData object leak in macosx KeystoreImpl.m > > > > diff -r 042dfb697624 -r 9f43fea81900 > src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m > > --- a/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m Tue > Jul 23 20:03:03 2019 -0700 > > +++ b/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m > Wed Jul 24 12:36:12 2019 +0200 > > @@ -1,5 +1,5 @@ > > /* > > - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. > > + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. > > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > * > > * This code is free software; you can redistribute it and/or modify it > > @@ -562,6 +562,9 @@ > > > > err = SecKeychainItemImport(cfDataToImport, NULL, &dataFormat, > NULL, > > 0, ¶mBlock, defaultKeychain, &createdItems); > > + if (cfDataToImport != NULL) { > > + CFRelease(cfDataToImport); > > + } > > > > if (err == noErr) { > > SecKeychainItemRef anItem = > (SecKeychainItemRef)CFArrayGetValueAtIndex(createdItems, 0); From weijun.wang at oracle.com Thu Jul 25 09:29:48 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jul 2019 17:29:48 +0800 Subject: RFR : [XS] 8228578: fix CFData object leak in macosx KeystoreImpl.m In-Reply-To: References: <21487949-33F3-4AE4-959D-FEE2453C5E3F@oracle.com> Message-ID: <8FDB838F-5485-4EB5-9B8B-9A9BD8B3240D@oracle.com> I don't think so. --Max > On Jul 25, 2019, at 5:09 PM, Baesken, Matthias wrote: > > Thanks for the review . > Do I need a second review for this one ? > > > Best regards, Matthias > > >> -----Original Message----- >> From: Weijun Wang >> Sent: Mittwoch, 24. Juli 2019 15:41 >> To: Baesken, Matthias >> Cc: security-dev at openjdk.java.net; naoto.sato at oracle.com >> Subject: Re: RFR : [XS] 8228578: fix CFData object leak in macosx >> KeystoreImpl.m >> >> This looks fine to me. >> >> You might want to add a noreg-* label to the bug. Maybe noreg-cleanup? >> >> Thanks, >> Max >> >>> On Jul 24, 2019, at 7:35 PM, Baesken, Matthias >> wrote: >>> >>> Hello, here is the webrev for easier review . >>> >>> Bug/webrev (after my webrev creation works again) : >>> >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8228578.0/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8228578 >>> >>> Best regards, Matthias >>> >>> From: Baesken, Matthias >>> Sent: Mittwoch, 24. Juli 2019 13:17 >>> To: security-dev at openjdk.java.net >>> Cc: 'naoto.sato at oracle.com' >>> Subject: RFR : [XS] 8228578: fix CFData object leak in macosx >> KeystoreImpl.m >>> >>> Hello, please review the following small patch . >>> >>> In KeystoreImpl.m we call CFDataCreate at one place. According to >>> >>> https://developer.apple.com/documentation/corefoundation/1542359- >> cfdatacreate?language=objc >>> >>> the return value of CFDataCreate is : "A new CFData object, or NULL if >> there was a problem creating the object. Ownership follows the The Create >> Rule." >>> >>> Following the "Create Rule" , we have to release the return value to avoid >> leaks. >>> Or do I miss something ? >>> >>> >>> Bug / (no webrev currently because I have some technical issues at the >> moment with webrev creation, getting connection reset by peer for some >> reason ) >>> >>> https://bugs.openjdk.java.net/browse/JDK-8228578 >>> >>> patch is attached, and change also below . >>> >>> Thanks, Matthias >>> >>> >>> >>> Change : >>> >>> # HG changeset patch >>> # Parent 042dfb697624926507649a4a8ad17a5e6730ba04 >>> 8228578: fix CFData object leak in macosx KeystoreImpl.m >>> >>> diff -r 042dfb697624 -r 9f43fea81900 >> src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m >>> --- a/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m Tue >> Jul 23 20:03:03 2019 -0700 >>> +++ b/src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m >> Wed Jul 24 12:36:12 2019 +0200 >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. >>> + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or modify it >>> @@ -562,6 +562,9 @@ >>> >>> err = SecKeychainItemImport(cfDataToImport, NULL, &dataFormat, >> NULL, >>> 0, ¶mBlock, defaultKeychain, &createdItems); >>> + if (cfDataToImport != NULL) { >>> + CFRelease(cfDataToImport); >>> + } >>> >>> if (err == noErr) { >>> SecKeychainItemRef anItem = >> (SecKeychainItemRef)CFArrayGetValueAtIndex(createdItems, 0); > From sean.mullan at oracle.com Thu Jul 25 11:35:47 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 25 Jul 2019 07:35:47 -0400 Subject: [13] RFR 8228602: Add sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java to problem list In-Reply-To: References: Message-ID: <6de21e7c-f38a-2cfe-6635-daeb00c24698@oracle.com> Can you add some more info to the bug and also add links to the 2 bugs you mention below? Also, should the subcomponent for this and 8228431 be "java.security"? Otherwise it looks ok. --Sean On 7/24/19 11:32 PM, Weijun Wang wrote: > The new test introduced by JDK-8217375 > ?fails a lot on > solaris-sparc, please review this patch to add it to the problem list. > Please note that I use "solaris-all" instead of "solaris-sparcv9". Every > other line related to solaris uses solaris-all and I cannot be sure if > solaris-sparcv9 would work. > > The bug related is at https://bugs.openjdk.java.net/browse/JDK-8228431. > This bug is https://bugs.openjdk.java.net/browse/JDK-8228602. > > Thanks, > Max > > *diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt* > *--- a/test/jdk/ProblemList.txt* > *+++ b/test/jdk/ProblemList.txt* > @@ -662,6 +662,7 @@ > ?sun/security/tools/keytool/WeakAlg.java > 8224644 solaris-all > > > ?sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java > 8026393 generic-all > +sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java > 8228431 solaris-all > > > ?javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java > 8212096 generic-all > ?javax/net/ssl/SSLSocket/Tls13PacketSize.java > 8224718 generic-all > From sha.jiang at oracle.com Thu Jul 25 11:48:54 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 25 Jul 2019 19:48:54 +0800 Subject: RFR[13] JDK-8228403: SignTwice.java failed with java.io.FileNotFoundException: File name too long Message-ID: Hi, The Java runtime version of JDK builds may be long, then the path to the generated jars, which use this version as part of file name, would be too long. This fix takes the jar names to use Java version, which should be much shorter. Now, the report table displays the Java versions and the associated indices in the JDK list. Please take a look at the report sample: http://cr.openjdk.java.net/~jjiang/8228403/webrev.00/report/report.html Webrev: http://cr.openjdk.java.net/~jjiang/8228403/webrev.00/ Issue : https://bugs.openjdk.java.net/browse/JDK-8228403 Best regards, John Jiang From sean.mullan at oracle.com Thu Jul 25 12:18:08 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 25 Jul 2019 08:18:08 -0400 Subject: [13] RFR 8228456: Enhance tests after JDK-8217375 In-Reply-To: <10B3528C-CE25-4A51-BB50-AB9622CA3394@oracle.com> References: <1547972414.2363.9.camel@paratix.ch> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> <194a8681-6c67-4d1d-4338-a92bfc5da06c@oracle.com> <10B3528C-CE25-4A51-BB50-AB9622CA3394@oracle.com> Message-ID: <59d21781-c542-aa97-825c-d9bf1b3d7758@oracle.com> On 7/24/19 8:27 PM, Weijun Wang wrote: > > >> On Jul 24, 2019, at 11:30 PM, Sean Mullan wrote: >> >> On 7/21/19 10:02 PM, Weijun Wang wrote: >>> Please take a review at >>> http://cr.openjdk.java.net/~weijun/8228456/webrev.00/ >>> The change is contributed by Philipp Kunz. Since we are now in RDP 2 and we are not allowed to fix non-test P3 (and lower) bugs. I've removed all src/ changes in Philipp's patch (If I read correctly, is mostly on renaming methods, and brings no behavior change) and made necessary change in test codes to use original method names. >> >> It is a pretty large set of changes though. >> >> If they are not needed to fix any issues in 13, I would recommend pushing to the jdk mainline. We can always decide to backport to 13 or 13u later once we get more assurance they are stable. > > Most of them are cleanups. The only big change is on PreserveRawManifestEntryAndDigest.java which is failing intermittently on solaris-sparc now. Therefore I think we should fix it in 13. Ok, if you think it is low-risk. >> >>> I haven't read the changes yet. I only made sure they pass on my own system. Oracle's test farm is in maintenance during the weekend. >> >> Since you are not the contributor, I think it is ok for you to be the main Reviewer. > > Yes, I understand. > > Thanks, > Max > >> >> --Sean > From weijun.wang at oracle.com Thu Jul 25 13:19:56 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jul 2019 21:19:56 +0800 Subject: [13] RFR 8228602: Add sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java to problem list In-Reply-To: <6de21e7c-f38a-2cfe-6635-daeb00c24698@oracle.com> References: <6de21e7c-f38a-2cfe-6635-daeb00c24698@oracle.com> Message-ID: > On Jul 25, 2019, at 7:35 PM, Sean Mullan wrote: > > Can you add some more info to the bug and also add links to the 2 bugs you mention below? OK. > Also, should the subcomponent for this and 8228431 be "java.security"? jarsigner is based on jdk.security.jarsigner.JarSigner. And do we use this subcomponent in any query? --Max > > Otherwise it looks ok. > > --Sean > > On 7/24/19 11:32 PM, Weijun Wang wrote: >> The new test introduced by JDK-8217375 fails a lot on solaris-sparc, please review this patch to add it to the problem list. Please note that I use "solaris-all" instead of "solaris-sparcv9". Every other line related to solaris uses solaris-all and I cannot be sure if solaris-sparcv9 would work. >> The bug related is at https://bugs.openjdk.java.net/browse/JDK-8228431. This bug is https://bugs.openjdk.java.net/browse/JDK-8228602. >> Thanks, >> Max >> *diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt* >> *--- a/test/jdk/ProblemList.txt* >> *+++ b/test/jdk/ProblemList.txt* >> @@ -662,6 +662,7 @@ >> sun/security/tools/keytool/WeakAlg.java 8224644 solaris-all >> sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all >> +sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java 8228431 solaris-all >> javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java 8212096 generic-all >> javax/net/ssl/SSLSocket/Tls13PacketSize.java 8224718 generic-all From weijun.wang at oracle.com Thu Jul 25 09:38:58 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jul 2019 17:38:58 +0800 Subject: [13] RFR 8228456: Enhance tests after JDK-8217375 In-Reply-To: References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> Message-ID: <670DD939-5FF1-4455-8990-3987693AD14B@oracle.com> Hi Philipp, Most are fine but PreserveRawManifestEntryAndDigest.java is still very slow and fails intermittently. The problem is due to jarsignerProc(). Since you have parallel=true for the test providers, many jarsigner processes would run at the same time and some of our test machines cannot load so many processes (they are also running other jobs). I read about the place when jarsignerProc() is called and seems you want to make sure the first file is signed by A and the second is not. Can we do this using JarFile API? Does you have other things to check in getExpectedJarSignerOutputUpdatedContentNotValidatedBySignerA()? How about we remove the `jarsigner -verify` call? Like this: // double-check reading the files with a verifying JarFile try (JarFile jar = new JarFile(jarFilename4, true)) { if (firstAddedFilename != null) { JarEntry je1 = jar.getJarEntry(firstAddedFilename); jar.getInputStream(je1).readAllBytes(); - assertTrue(je1.getCodeSigners().length > 0); + CodeSigner[] ss = je1.getCodeSigners(); + assertTrue(ss.length == 2); + assertTrue(containsSignerA(ss)); } if (secondAddedFilename != null) { JarEntry je2 = jar.getJarEntry(secondAddedFilename); jar.getInputStream(je2).readAllBytes(); - assertTrue(je2.getCodeSigners().length > 0); + CodeSigner[] ss = je2.getCodeSigners(); + assertTrue(ss.length == 1); + assertFalse(containsSignerA(ss)); } } @@ -392,6 +380,17 @@ } } + private static boolean containsSignerA(CodeSigner[] ss) { + for (CodeSigner s : ss) { + X509Certificate x = (X509Certificate) + s.getSignerCertPath().getCertificates().get(0); + if (x.getSubjectX500Principal().toString().equals("CN=A")) { + return true; + } + } + return false; + } + Thanks, Max > On Jul 22, 2019, at 10:02 AM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8228456/webrev.00/ > > The change is contributed by Philipp Kunz. Since we are now in RDP 2 and we are not allowed to fix non-test P3 (and lower) bugs. I've removed all src/ changes in Philipp's patch (If I read correctly, is mostly on renaming methods, and brings no behavior change) and made necessary change in test codes to use original method names. > > I haven't read the changes yet. I only made sure they pass on my own system. Oracle's test farm is in maintenance during the weekend. > > Thanks, > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Thu Jul 25 15:45:24 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 25 Jul 2019 08:45:24 -0700 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> Message-ID: I updated the CSR and webrev per the review comments accordingly. webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.02/ CSR: https://bugs.openjdk.java.net/browse/JDK-8227445 Thanks, Xuelei On 7/12/2019 9:14 AM, Xuelei Fan wrote: > On 7/12/2019 5:24 AM, Sean Mullan wrote: >> On 7/11/19 11:56 AM, Xuelei Fan wrote: >> >>>> Also, in the CSR you list all the different signature algorithms >>>> that could be disabled, but you use the TLS names, and not the >>>> standard JCE names. I found this a bit confusing, since if you added >>>> those exact TLS names to jdk.tls.disabledAlgorithms, I don't think >>>> it will work, or if it does we need additional changes to the >>>> jdk.tls.disabledAlgorithms definition - and maybe that is what we >>>> should do?? Also, I don't think it is possible to disable individual >>>> RSASSA-PSS algorithms, I think you can just disable all or none of >>>> them because the parameters are specified separately and not part of >>>> the standard JCE name. Similar to other algorithms - how would I >>>> just disable ecdsa_secp256r1_sha256 and nothing else? Is that an issue? >>>> >>> Yes, it is an issue now.? The AlgorithmConstraints is able to accept >>> parameters, but the current jdk.tls.disabledAlgorithms property >>> cannot. That's also why I used the TLS names (ecdsa_secp256r1_sha256, >>> rsa_pss_rsae_sha256, etc) rather than standard names >>> (SHA256withECDSA, RSASSA-PSS). >>> >>> I agree with you that it is confusing.? The use of >>> rsa_pss_rsae_sha256 may be fine, but the name "dsa_sha256" rather >>> then "SHA256withDSA" could be confusing. >>> >>> I was planned to add TLS signature algorithms into the standard >>> names, as we will do for the named groups.? But it looks like a >>> duplicate of the crypto Signature algorithms. >> >> I would lean towards this option. We could extend the >> jdk.tls.disabledAlgorithms property to allow you to specify TLS >> signature schemes as defined in >> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme >> >> >> We would also need to add a section to the Standard Names >> specification listing these schemes. >> >> The reason I like this option is because it fits well with the TLS >> namespace, and it is more flexible than the JCE names and we can more >> easily restrict new TLS signature schemes that are defined later. > I agreed that is is more straightforward.? Okay, let's go with option. > > Between file a new enhancement for Standard Names documentation or > update the doc this time, do you have a preference?? Maybe, we can > update the doc together with JDKJDK-8210755? > ?? https://bugs.openjdk.java.net/browse/JDK-8210755 > > Thanks, > Xuelei From sean.mullan at oracle.com Thu Jul 25 16:15:40 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 25 Jul 2019 12:15:40 -0400 Subject: RFR: 8191138: Remove deprecated java.security.acl APIs Message-ID: <5cb4e551-562c-9d0b-5cb8-46512b2eeaf1@oracle.com> Please review this change to remove the deprecated java.security.acl APIs. These APIs have long had a warning in the javadocs (since at least JDK 1.3.1 and possibly earlier) indicating that they were superseded by other APIs. They were initially deprecated in JDK 9 and marked for removal in JDK 10, so enough time has passed to allow for removal. Several external projects that were using the APIs have also either resolved the issues or have a plan to remove the dependencies. CSR: https://bugs.openjdk.java.net/browse/JDK-8217101 Issue: https://bugs.openjdk.java.net/browse/JDK-8191138 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191138/webrev.00/ Thanks, Sean From sean.mullan at oracle.com Thu Jul 25 18:36:37 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 25 Jul 2019 14:36:37 -0400 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> Message-ID: <748a353d-7d27-0045-6b07-e188728f8e30@oracle.com> On 7/25/19 11:45 AM, Xuelei Fan wrote: > I updated the CSR and webrev per the review comments accordingly. > > webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.02/ Not done reviewing yet, but here are a couple of comments so far: * test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java 96 } catch (Exception exp) { 97 continue; 98 } Can you check for an expected exception here? Same comment on lines 111-113 of RestrictSignatureScheme.java * src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java 114 if ((namedGroup == null) || (!namedGroup.isAvailable)) { You don't do this check for null and isAvailable in other places, for example ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() - should you? > CSR:??? https://bugs.openjdk.java.net/browse/JDK-8227445 In the CSR, the Notes 1-3 are very similar. I only think you need to mention that the names will be standardized in a subsequent CSR - and maybe you can point or add a link to the issue that has been filed for that. I don't think you need the other 2 notes. --Sean > > Thanks, > Xuelei > > On 7/12/2019 9:14 AM, Xuelei Fan wrote: >> On 7/12/2019 5:24 AM, Sean Mullan wrote: >>> On 7/11/19 11:56 AM, Xuelei Fan wrote: >>> >>>>> Also, in the CSR you list all the different signature algorithms >>>>> that could be disabled, but you use the TLS names, and not the >>>>> standard JCE names. I found this a bit confusing, since if you >>>>> added those exact TLS names to jdk.tls.disabledAlgorithms, I don't >>>>> think it will work, or if it does we need additional changes to the >>>>> jdk.tls.disabledAlgorithms definition - and maybe that is what we >>>>> should do?? Also, I don't think it is possible to disable >>>>> individual RSASSA-PSS algorithms, I think you can just disable all >>>>> or none of them because the parameters are specified separately and >>>>> not part of the standard JCE name. Similar to other algorithms - >>>>> how would I just disable ecdsa_secp256r1_sha256 and nothing else? >>>>> Is that an issue? >>>>> >>>> Yes, it is an issue now.? The AlgorithmConstraints is able to accept >>>> parameters, but the current jdk.tls.disabledAlgorithms property >>>> cannot. That's also why I used the TLS names >>>> (ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256, etc) rather than >>>> standard names (SHA256withECDSA, RSASSA-PSS). >>>> >>>> I agree with you that it is confusing.? The use of >>>> rsa_pss_rsae_sha256 may be fine, but the name "dsa_sha256" rather >>>> then "SHA256withDSA" could be confusing. >>>> >>>> I was planned to add TLS signature algorithms into the standard >>>> names, as we will do for the named groups.? But it looks like a >>>> duplicate of the crypto Signature algorithms. >>> >>> I would lean towards this option. We could extend the >>> jdk.tls.disabledAlgorithms property to allow you to specify TLS >>> signature schemes as defined in >>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme >>> >>> >>> We would also need to add a section to the Standard Names >>> specification listing these schemes. >>> >>> The reason I like this option is because it fits well with the TLS >>> namespace, and it is more flexible than the JCE names and we can more >>> easily restrict new TLS signature schemes that are defined later. >> I agreed that is is more straightforward.? Okay, let's go with option. >> >> Between file a new enhancement for Standard Names documentation or >> update the doc this time, do you have a preference?? Maybe, we can >> update the doc together with JDKJDK-8210755? >> ??? https://bugs.openjdk.java.net/browse/JDK-8210755 >> >> Thanks, >> Xuelei From mandy.chung at oracle.com Thu Jul 25 19:34:02 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 25 Jul 2019 12:34:02 -0700 Subject: RFR: 8191138: Remove deprecated java.security.acl APIs In-Reply-To: <5cb4e551-562c-9d0b-5cb8-46512b2eeaf1@oracle.com> References: <5cb4e551-562c-9d0b-5cb8-46512b2eeaf1@oracle.com> Message-ID: <62836693-344e-aafc-972a-414a6d487b59@oracle.com> On 7/25/19 9:15 AM, Sean Mullan wrote: > Please review this change to remove the deprecated java.security.acl > APIs. These APIs have long had a warning in the javadocs (since at > least JDK 1.3.1 and possibly earlier) indicating that they were > superseded by other APIs. They were initially deprecated in JDK 9 and > marked for removal in JDK 10, so enough time has passed to allow for > removal. Several external projects that were using the APIs have also > either resolved the issues or have a plan to remove the dependencies. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8217101 > Issue: https://bugs.openjdk.java.net/browse/JDK-8191138 > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191138/webrev.00/ +1 It's good to know that external projects have either removed or plan to remove their dependency on java.security.acl API. Mandy From weijun.wang at oracle.com Fri Jul 26 02:23:19 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Jul 2019 10:23:19 +0800 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> Message-ID: Is it possible to add one group name and one signature scheme to the Example in java.security? --Max > On Jul 25, 2019, at 11:45 PM, Xuelei Fan wrote: > > I updated the CSR and webrev per the review comments accordingly. > > webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.02/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8227445 > > Thanks, > Xuelei From xuelei.fan at oracle.com Fri Jul 26 02:44:45 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 25 Jul 2019 19:44:45 -0700 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> Message-ID: <5abd4972-47f1-2ee6-e03a-dcdeb4e80edf@oracle.com> On 7/25/2019 7:23 PM, Weijun Wang wrote: > Is it possible to add one group name and one signature scheme to the Example in java.security? > Good point. I will add the items for each in the example in the next webrev. Thanks, Xuelei > --Max > >> On Jul 25, 2019, at 11:45 PM, Xuelei Fan wrote: >> >> I updated the CSR and webrev per the review comments accordingly. >> >> webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.02/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8227445 >> >> Thanks, >> Xuelei > From weijun.wang at oracle.com Fri Jul 26 07:48:15 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Jul 2019 15:48:15 +0800 Subject: [13] RFR 8228456: Enhance tests after JDK-8217375 In-Reply-To: References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> Message-ID: > On Jul 22, 2019, at 10:02 AM, Weijun Wang wrote: > > http://cr.openjdk.java.net/~weijun/8228456/webrev.00/ Another problem of PreserveRawManifestEntryAndDigest.java is that there are too many output and most part of the test output is "overflow"ed. Is the Utils.echoManifest() calls really necessary? All jar files can be retained and we can inspect the content later. Or, you can redirect the manifest text and all output of jarsigner calls into separate text files. --Max From sean.coffey at oracle.com Fri Jul 26 10:32:55 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 26 Jul 2019 11:32:55 +0100 Subject: RFR: 8228645: Don't run sun/security/pkcs11/Cipher/TestKATForGCM.java on buggy NSS solaris versions Message-ID: <3fcdcfe6-f6ab-7658-1b23-a9dcedc5e765@oracle.com> The sun/security/pkcs11/Cipher/TestKATForGCM.java testcase can fail when running on older, buggy NSS libraries. In particular on Solaris 11.2 and earlier. Most of our solaris testing occurs on 11.3 OS but we should discount failures seen in Solaris 11.2 test runs. https://bugs.openjdk.java.net/browse/JDK-8228645 http://cr.openjdk.java.net/~coffeys/webrev.8228645/webrev/ regards, Sean. From xuelei.fan at oracle.com Fri Jul 26 14:08:14 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 26 Jul 2019 07:08:14 -0700 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: <748a353d-7d27-0045-6b07-e188728f8e30@oracle.com> References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> <748a353d-7d27-0045-6b07-e188728f8e30@oracle.com> Message-ID: New webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.03/ On 7/25/2019 11:36 AM, Sean Mullan wrote: > On 7/25/19 11:45 AM, Xuelei Fan wrote: >> I updated the CSR and webrev per the review comments accordingly. >> >> webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.02/ > > Not done reviewing yet, but here are a couple of comments so far: > > * test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java > > ? 96???????????? } catch (Exception exp) { > ? 97???????????????? continue; > ? 98???????????? } > > Can you check for an expected exception here? Same comment on lines > 111-113 of RestrictSignatureScheme.java > As the test is a client-server structure, the exception may be different for each run (client or server which thread dies first). I updated to use "SSLException | IllegalStateException". SSLException is the general exception, but IllegalStateException is the exception thrown by client or server thread when it dies and failed to wrap the SSLException. The normal case for the signature schemes and named groups should have been covered by other test cases, it may not worthy to analysis the exception stack for exactly exception, which is not reliable if the exception stack get changed in the future. > * src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java > > 114???????????? if ((namedGroup == null) || (!namedGroup.isAvailable)) { > > You don't do this check for null and isAvailable in other places, for > example ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() - > should you? > Good point! Currently, the restriction is only checked for the supported group extension. I should add more check points in other places where named groups are used, for example client key exchange and certificate. Stay tune for the next webrev. >> CSR:??? https://bugs.openjdk.java.net/browse/JDK-8227445 > > In the CSR, the Notes 1-3 are very similar. I only think you need to > mention that the names will be standardized in a subsequent CSR - and > maybe you can point or add a link to the issue that has been filed for > that. I don't think you need the other 2 notes. > Updated. Thanks, Xuelei > --Sean > >> >> Thanks, >> Xuelei >> >> On 7/12/2019 9:14 AM, Xuelei Fan wrote: >>> On 7/12/2019 5:24 AM, Sean Mullan wrote: >>>> On 7/11/19 11:56 AM, Xuelei Fan wrote: >>>> >>>>>> Also, in the CSR you list all the different signature algorithms >>>>>> that could be disabled, but you use the TLS names, and not the >>>>>> standard JCE names. I found this a bit confusing, since if you >>>>>> added those exact TLS names to jdk.tls.disabledAlgorithms, I don't >>>>>> think it will work, or if it does we need additional changes to >>>>>> the jdk.tls.disabledAlgorithms definition - and maybe that is what >>>>>> we should do?? Also, I don't think it is possible to disable >>>>>> individual RSASSA-PSS algorithms, I think you can just disable all >>>>>> or none of them because the parameters are specified separately >>>>>> and not part of the standard JCE name. Similar to other algorithms >>>>>> - how would I just disable ecdsa_secp256r1_sha256 and nothing >>>>>> else? Is that an issue? >>>>>> >>>>> Yes, it is an issue now.? The AlgorithmConstraints is able to >>>>> accept parameters, but the current jdk.tls.disabledAlgorithms >>>>> property cannot. That's also why I used the TLS names >>>>> (ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256, etc) rather than >>>>> standard names (SHA256withECDSA, RSASSA-PSS). >>>>> >>>>> I agree with you that it is confusing.? The use of >>>>> rsa_pss_rsae_sha256 may be fine, but the name "dsa_sha256" rather >>>>> then "SHA256withDSA" could be confusing. >>>>> >>>>> I was planned to add TLS signature algorithms into the standard >>>>> names, as we will do for the named groups.? But it looks like a >>>>> duplicate of the crypto Signature algorithms. >>>> >>>> I would lean towards this option. We could extend the >>>> jdk.tls.disabledAlgorithms property to allow you to specify TLS >>>> signature schemes as defined in >>>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme >>>> >>>> >>>> We would also need to add a section to the Standard Names >>>> specification listing these schemes. >>>> >>>> The reason I like this option is because it fits well with the TLS >>>> namespace, and it is more flexible than the JCE names and we can >>>> more easily restrict new TLS signature schemes that are defined later. >>> I agreed that is is more straightforward.? Okay, let's go with option. >>> >>> Between file a new enhancement for Standard Names documentation or >>> update the doc this time, do you have a preference?? Maybe, we can >>> update the doc together with JDKJDK-8210755? >>> ??? https://bugs.openjdk.java.net/browse/JDK-8210755 >>> >>> Thanks, >>> Xuelei From sean.mullan at oracle.com Fri Jul 26 14:10:31 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Jul 2019 10:10:31 -0400 Subject: RFR[13] JDK-8228403: SignTwice.java failed with java.io.FileNotFoundException: File name too long In-Reply-To: References: Message-ID: <8b17e5e7-6628-801f-a696-cb7161a0e87a@oracle.com> Looks fine to me. --Sean On 7/25/19 7:48 AM, sha.jiang at oracle.com wrote: > Hi, > The Java runtime version of JDK builds may be long, then the path to the > generated jars, which use this version as part of file name, would be > too long. > This fix takes the jar names to use Java version, which should be much > shorter. > > Now, the report table displays the Java versions and the associated > indices in the JDK list. > Please take a look at the report sample: > http://cr.openjdk.java.net/~jjiang/8228403/webrev.00/report/report.html > > Webrev: http://cr.openjdk.java.net/~jjiang/8228403/webrev.00/ > Issue : https://bugs.openjdk.java.net/browse/JDK-8228403 > > Best regards, > John Jiang > From weijun.wang at oracle.com Fri Jul 26 14:57:31 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Jul 2019 22:57:31 +0800 Subject: [13] RFR 8228431: sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java fails intermittently on solaris Message-ID: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8228431/webrev.00/ The no-native-provider.conf file put SUN and SunRsaSign as the first 2 security providers and thus shadows the OracleUcrypto and SunPKCS11 providers used by Solaris. Please note that duplicated provider names are silently ignored so this is harmless. On other platforms, the first 2 providers are already SUN and SunRsaSign. I ran the test 200 times on solaris-sparcv9 and it does not fail once. Before this fix, it always fails on this platform. An alternative fix is to simply exclude the test from solaris-sparc using `@requires os.family != "solaris"`. I've fixed some other security/tools test failures using this solution. The reason is that these tests are testing platform-independent behaviors so it's OK to skip one platform. I don't think this test is platform-dependent in any way. Thanks, Max From weijun.wang at oracle.com Fri Jul 26 15:24:12 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 26 Jul 2019 23:24:12 +0800 Subject: [14] RFR 8228659: Record which Java methods are called by native codes in JGSS and JAAS Message-ID: <624CB9FE-FD3C-42D0-A9C0-BB05BE5F44B3@oracle.com> Please review the change at http://cr.openjdk.java.net/~weijun/8228659/webrev.00/ Most of the change is new comments on internal Java methods called by native code. I also take this chance to simply Ticket creation in nativeccache.c and NativeCreds.c. There is no need to call `new Ticket(new DerValue(byteArray))` which is identical to `new Ticket(byteArray)`. I added the label noreg-doc but does not feel really comfortable. There is no public document here. noreg-comment or noreg-clarification would be better, if they exists. Please advise. Thanks, Max From valerie.peng at oracle.com Fri Jul 26 21:08:53 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 26 Jul 2019 14:08:53 -0700 Subject: RFR: 8228645: Don't run sun/security/pkcs11/Cipher/TestKATForGCM.java on buggy NSS solaris versions In-Reply-To: <3fcdcfe6-f6ab-7658-1b23-a9dcedc5e765@oracle.com> References: <3fcdcfe6-f6ab-7658-1b23-a9dcedc5e765@oracle.com> Message-ID: Changes look good to me. Thanks, Valerie On 7/26/2019 3:32 AM, Se?n Coffey wrote: > The sun/security/pkcs11/Cipher/TestKATForGCM.java testcase can fail > when running > on older, buggy NSS libraries. In particular on Solaris 11.2 and > earlier. Most of our > solaris testing occurs on 11.3 OS but we should discount failures seen > in Solaris 11.2 > test runs. > > https://bugs.openjdk.java.net/browse/JDK-8228645 > http://cr.openjdk.java.net/~coffeys/webrev.8228645/webrev/ > > regards, > Sean. > From valerie.peng at oracle.com Fri Jul 26 22:05:35 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 26 Jul 2019 15:05:35 -0700 Subject: [13] RFR 8228668: compiler/codegen/aes/TestAESMain.java failed with GCM mode must be used with NoPadding Message-ID: <326378c5-2743-5b5c-9ef4-d61a5d964456@oracle.com> Any one can help review this? It's for updating a hotspot regression test to use NoPadding when using AES GCM mode. The regression test started failing after JDK8180392 "SunJCE provider should throw exceptions for unsupported mode and padding combinations" is integrated. Also removed some dead code in the other regression test. Bug: https://bugs.openjdk.java.net/browse/JDK-8228668 Webrev: http://cr.openjdk.java.net/~valeriep/8228668/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Fri Jul 26 22:07:03 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 26 Jul 2019 15:07:03 -0700 Subject: [14] RFR 8228668: compiler/codegen/aes/TestAESMain.java failed with GCM mode must be used with NoPadding In-Reply-To: <326378c5-2743-5b5c-9ef4-d61a5d964456@oracle.com> References: <326378c5-2743-5b5c-9ef4-d61a5d964456@oracle.com> Message-ID: Sorry, should be for JDK 14. Fixed the subject. Valerie On 7/26/2019 3:05 PM, Valerie Peng wrote: > Any one can help review this? It's for updating a hotspot regression > test to use NoPadding when using AES GCM mode. > > The regression test started failing after JDK8180392 "SunJCE provider > should throw exceptions for unsupported mode and padding combinations" > is integrated. Also removed some dead code in the other regression test. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228668 > > Webrev: http://cr.openjdk.java.net/~valeriep/8228668/webrev.00/ > > Thanks, > Valerie From xuelei.fan at oracle.com Fri Jul 26 23:17:38 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 26 Jul 2019 16:17:38 -0700 Subject: [14] RFR 8228668: compiler/codegen/aes/TestAESMain.java failed with GCM mode must be used with NoPadding In-Reply-To: References: <326378c5-2743-5b5c-9ef4-d61a5d964456@oracle.com> Message-ID: Looks good to me. Just a nit: 58 "NoPadding":"PKCS5Padding"); I may use a white space before and after the "?" and ":" operators. Xuelei On 7/26/2019 3:07 PM, Valerie Peng wrote: > Sorry, should be for JDK 14. Fixed the subject. > > Valerie > > On 7/26/2019 3:05 PM, Valerie Peng wrote: >> Any one can help review this? It's for updating a hotspot regression >> test to use NoPadding when using AES GCM mode. >> >> The regression test started failing after JDK8180392 "SunJCE provider >> should throw exceptions for unsupported mode and padding combinations" >> is integrated. Also removed some dead code in the other regression test. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228668 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8228668/webrev.00/ >> >> Thanks, >> Valerie From philipp.kunz at paratix.ch Sun Jul 28 14:23:13 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sun, 28 Jul 2019 16:23:13 +0200 Subject: [13] RFR 8228341: SignTwice.java fails intermittently on Windows In-Reply-To: References: Message-ID: <1564323793.2665.10.camel@paratix.ch> Hi Max, Glad to see SignTwice being taken from ProblemList. Is it working now with the timeout added or does it still fail on windows? > I just ran a test job: SignTwice.java failed on Windows with `failed to clean up files after test`. Most likely a file is not closed. For the key algs, "-DkeyAlgs=EC;" or "-DkeyAlgs=EC" might be shorter for the same effect, but "-DkeyAlgs=EC;0" is all right as well. However, "-DdigestAlgs=SHA-256" will (far as I remember) not result in a digest that exceeds the maximum manifest line width in its encoded form as a base64 string and makes a difference. I strongly suggest to keep "-DdigestAlgs=SHA-512" or any other digest algorithm that tests line breaking of digests in signed jar file manifests. Regards,Philipp On Tue, 2019-07-23 at 14:28 +0800, Weijun Wang wrote: > Please review the patch below. This test signs the same jar multiple > times. It's mainly about making sure the manifest and signature file > can be updated correctly. There is no need to try different key > algorithms. We can also use a faster digest algorithm. > Thanks, > Max > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -661,7 +661,6 @@ > ?sun/security/tools/keytool/KeyToolTest.java ? ? ? ? ? ? ? ? ? ? > 8224644 solaris-all > ?sun/security/tools/keytool/WeakAlg.java ? ? ? ? ? ? ? ? ? ? ? ? > 8224644 solaris-all > ? > -sun/security/tools/jarsigner/compatibility/SignTwice.java ? ? ? > 8228341 windows-all > ?sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java? ? ? > 8026393 generic-all > ? > ?javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java ? ? ? > 8212096 generic-all > diff --git > a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java > b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java > --- > a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java > +++ > b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java > @@ -36,7 +36,7 @@ > ? * @test > ? * @library /test/lib ../warnings > ? * @compile Compatibility.java > - * @run main/othervm > + * @run main/othervm/timeout=600 > ? *? -Djava.security.properties=./java.security > ? *? -Duser.language=en > ? *? -Duser.country=US > @@ -46,8 +46,8 @@ > ? *? -DtestComprehensiveJarContents=true > ? *? -DtestJarUpdate=true > ? *? -Dstrict=true > - *? -DkeyAlgs=EC;#RSA;#DSA; > - *? -DdigestAlgs=SHA-512 > + *? -DkeyAlgs=EC;0 > + *? -DdigestAlgs=SHA-256 > ? *? SignTwice > ? */ > ?public class SignTwice { > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp.kunz at paratix.ch Sun Jul 28 14:36:00 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sun, 28 Jul 2019 16:36:00 +0200 Subject: [13] RFR 8228431: sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java fails intermittently on solaris In-Reply-To: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> References: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> Message-ID: <1564324560.2665.12.camel@paratix.ch> Hi Max, While it's nice to see that your fix works around the problem, this does not look like the final remedy. I'm also quite surprised that only PreserveRawManifestEntryAndDigest should be affected whereas a number of other tests use the same kind of signing. With some luck, that PreserveRawManifestEntryAndDigest test helps with a hint to find the actual root cause.?I have a gut feeling somehow that the problem here might not only affect tests and I'd rather opt for filing another bug now, which may as well be investigated and solved later and independently. As the patch looks now, the resulting code will not mention that the "security.provider" settings were introduced only for solaris. The next poor guy who reads it will wonder why it is there and not understand. Perfect would be a reference to a bug probably yet to be created as already suggested or otherwise I'd welcome to see at least a comment with some explanation of what we currently know. Regards, Philipp On Fri, 2019-07-26 at 22:57 +0800, Weijun Wang wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8228431/webrev.00/ > > The no-native-provider.conf file put SUN and SunRsaSign as the first 2 security providers and thus shadows the OracleUcrypto and SunPKCS11 providers used by Solaris. Please note that duplicated provider names are silently ignored so this is harmless. On other platforms, the first 2 providers are already SUN and SunRsaSign. > > I ran the test 200 times on solaris-sparcv9 and it does not fail once. Before this fix, it always fails on this platform. > > An alternative fix is to simply exclude the test from solaris-sparc using `@requires os.family != "solaris"`. I've fixed some other security/tools test failures using this solution. The reason is that these tests are testing platform-independent behaviors so it's OK to skip one platform. I don't think this test is platform-dependent in any way. > > Thanks, > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp.kunz at paratix.ch Sun Jul 28 15:28:50 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sun, 28 Jul 2019 17:28:50 +0200 Subject: [13] RFR 8228456: Enhance tests after JDK-8217375 In-Reply-To: <670DD939-5FF1-4455-8990-3987693AD14B@oracle.com> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> <670DD939-5FF1-4455-8990-3987693AD14B@oracle.com> Message-ID: <1564327730.2665.14.camel@paratix.ch> Hi Max, jarsignerProc is definitively a spot where significant amount of time is spent in the test unlike what is before and what is after it. Have you measured how much your change would make the test faster? My bet is it would not be significant. Tell me if I'm wrong.As I see it, we are, at least to some extent, back to a discussion we already started. > I also found running jarsigner slow which is why I suggested adding it as a tool like jar and others in a different thread and which was not accepted then. As for PreserveRawManifestEntryAndDigest, there is use of sun.security.tools.jarsigner.Main.main or run.> Using sun.security.tools.jarsigner.Main re-uses loading of the keystore while avoiding another JVM which I believe to be almost perfect apart from the API used not looking very public. Also in terms of performance I think it should be equivalent to JarSigner::sign.> When the output should be caputered, there is no way without another JVM (without the jarsigner tool). https://mail.openjdk.java.net/pipermail/security-dev/2019-June/020398.h tml In the current discussion's context, I'd like to precise: If jarsigner exits with a non-zero exit code, it calls System.exit which is not suitable at all for a test. It's actually more about the call to System.exit that requires it to be run in a child process and not so much the desire to analyze the output. I remember having measured each check/assertion's impact on performance individually and only jarsignerProc is significant. All other checks and jarsigner operations only add comparatively minor performance impact not worth in my opinion to optimize in a test. On the other hand, I admit that there might be too much of checking the jars and its signers in PreserveRawManifestEntryAndDigest from a code- style, readability and maintainability point of view. We might consider removing the parallel=true or add a threadPoolSize parameter to it with a suitable value that fits the test machines. Regards,Philipp On Thu, 2019-07-25 at 17:38 +0800, Weijun Wang wrote: > Hi Philipp, > > Most are fine but?PreserveRawManifestEntryAndDigest.java is still > very slow and fails intermittently. > The problem is due to jarsignerProc(). Since you have parallel=true > for the test providers, many jarsigner processes would run at the > same time and some of our test machines cannot load so many processes > (they are also running other jobs). > > I read about the place when jarsignerProc() is called and seems you > want to make sure the first file is signed by A and the second is > not. Can we do this using JarFile API? Does you have other things to > check > in?getExpectedJarSignerOutputUpdatedContentNotValidatedBySignerA()? > > How about we remove the `jarsigner -verify` call? Like this: > > ? ? ? ? ?// double-check reading the files with a verifying JarFile?? > ? ? ? try (JarFile jar = new JarFile(jarFilename4, true)) {?? ? ? ? ? > ? if (firstAddedFilename != null) {?? ? ? ? ? ? ? ? JarEntry je1 = > jar.getJarEntry(firstAddedFilename);?? ? ? ? ? ? ? ? > jar.getInputStream(je1).readAllBytes();-? ? ? ? ? ? ? ? > assertTrue(je1.getCodeSigners().length > 0);+? ? ? ? ? ? ? ? > CodeSigner[] ss = je1.getCodeSigners();+? ? ? ? ? ? ? ? > assertTrue(ss.length == 2);+? ? ? ? ? ? ? ? > assertTrue(containsSignerA(ss));?? ? ? ? ? ? }?? ? ? ? ? ? if > (secondAddedFilename != null) {?? ? ? ? ? ? ? ? JarEntry je2 = > jar.getJarEntry(secondAddedFilename);?? ? ? ? ? ? ? ? > jar.getInputStream(je2).readAllBytes();-? ? ? ? ? ? ? ? > assertTrue(je2.getCodeSigners().length > 0);+? ? ? ? ? ? ? ? > CodeSigner[] ss = je2.getCodeSigners();+? ? ? ? ? ? ? ? > assertTrue(ss.length == 1);+? ? ? ? ? ? ? ? > assertFalse(containsSignerA(ss));?? ? ? ? ? ? }?? ? ? ? }? > @@ -392,6 +380,17 @@?? ? ? ? }?? ? }? > +? ? private static boolean containsSignerA(CodeSigner[] ss) {+? ? ? > ? for (CodeSigner s : ss) {+? ? ? ? ? ? X509Certificate x = > (X509Certificate)+? ? ? ? ? ? ? ? ? ? > s.getSignerCertPath().getCertificates().get(0);+? ? ? ? ? ? if > (x.getSubjectX500Principal().toString().equals("CN=A")) {+? ? ? ? ? ? > ? ? return true;+? ? ? ? ? ? }+? ? ? ? }+? ? ? ? return false;+? ? }+ > Thanks,Max > > On Jul 22, 2019, at 10:02 AM, Weijun Wang > > wrote: > > > > Please take a review at > > > > ? http://cr.openjdk.java.net/~weijun/8228456/webrev.00/ > > > > The change is contributed by Philipp Kunz. Since we are now in RDP > > 2 and we are not allowed to fix non-test P3 (and lower) bugs. I've > > removed all src/ changes in Philipp's patch (If I?read correctly, > > is mostly on renaming methods, and brings no behavior change) and > > made necessary change in test codes to use original method names. > > > > I haven't read the changes yet. I only made sure they pass on my > > own system. Oracle's test farm is in maintenance during the > > weekend. > > > > Thanks, > > Max > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp.kunz at paratix.ch Sun Jul 28 16:12:38 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sun, 28 Jul 2019 18:12:38 +0200 Subject: RFR 8217375: jarsigner breaks old signature with long lines in manifest In-Reply-To: <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> Message-ID: <1564330358.2665.17.camel@paratix.ch> Hi Max and John, Just saw it now and it sounds very reassuring that you say you reviewed all the tests. Thank you so much for that non-trivial piece of work of quite some amount. Now I see the FIXED_xxx stuff appearing in the head branch which it was not intended to originally. For example: http://hg.openjdk.java.net/jdk/jdk/file/5e637f790bb8/test/jdk/sun/secur ity/util/ManifestDigester/FindSection.java#l54 In my opinion this should have been used to "calibrate the tests", meaning to switch the flag, check where it is used manually and run the new tests against the old src, in order to confirm that ManifestDigester's and other classes's behavior has not changed in an undesired way, before merging it. If that "calibration" still works now successfully, the flags and the code becoming unreachable without them can and also should now be removed. This is probably something occurring hardly ever but ManifestDigester had almost no test coverage before 8217375 and I would not feel comfortable unless a reviewer confirms that all the new tests actually and correctly conserve behavior that should not change as intended. See also https://mail.openjdk.java.net/pipermail/security-dev/2019-July/020 453.html. It's not exactly dramatic that the FIXED_xxx stuff has now found its way to the head branch but it will never ever be useful again. It's also not exactly urgent but could it be removed? This is most certainly exceptional but if I may suggest it with all modesty and due respect, I'd see and welcome it as a confirmation of a successful review of the "calibration" if someone else would remove it. How does that sound or what would you or any policy or existing procedure suggest? Regards, Philipp On Sun, 2019-07-21 at 08:08 +0800, Weijun Wang wrote: > Hi Philipp, > > I just took a brief look at the new patch. Looks like the src change has no behavior change (even in JarSigner.java with so many line changes). This is good. > > John and I have reviewed all the tests and we sent out some feedbacks in previous mails, and it's definitely a part of the whole review process. The single reason I integrated your changeset earlier this week is because RDP 2 starts at July 18 and after the date only P1-P2 src change would be approved but we can still modify the tests. Before pushing the change, I ran all tests, modified 2 regex patterns, and added one to problem list to make sure it makes no (or, as little as possible) noise (esp for other people running the tests). I haven't made any big change to the tests (including removing those FIXED_xxxxxxx flags) myself because I was still waiting for your reply. Thanks for coming back, so that we can start enhancing the tests now. Some test (Ex: PreserveRawManifestEntryAndDigest.java) still spends a lot of time and could intermittently time out. > > I'll file a new bug and post the interdiff between the integrated change and your new patch as the webrev.00 of it. > > Thanks, > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Sun Jul 28 17:42:32 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 28 Jul 2019 10:42:32 -0700 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> <748a353d-7d27-0045-6b07-e188728f8e30@oracle.com> Message-ID: On 7/26/2019 7:08 AM, Xuelei Fan wrote: > New webrev: > http://cr.openjdk.java.net/~xuelei/8226374/webrev.03/ > > >> * src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java >> >> 114???????????? if ((namedGroup == null) || (!namedGroup.isAvailable)) { >> >> You don't do this check for null and isAvailable in other places, for >> example ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() >> - should you? >> > Good point!? Currently, the restriction is only checked for the > supported group extension.? I should add more check points in other > places where named groups are used, for example client key exchange and > certificate.? Stay tune for the next webrev. > The ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() should be fine as the namedGroup has been checked in the previous steps (X509Authentication.X509PossessionGenerator.createServerPossession()). However, I missed the check for certificate. The consumer of certificate should check the named groups to make sure the supported named group is used. It was not a problem in the past as the supported named groups are used to indicate the EC curve or DH group is able to be handled in both side. It could be a problem now when we want to restrict named groups. The named groups used in a certificate should be checked in key manager and trust manager for TLS 1.2 and prior versions. Similar to the signature schemes for TLS 1.3. As may required new APIs (SSLParameters.getPeerSupportedNamedGroups()) for a generic solution. Would you mind if I file a new RFE and make the improvement in JDK 14 later? Thanks, Xuelei From vladimir.kozlov at oracle.com Sun Jul 28 22:30:53 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 28 Jul 2019 15:30:53 -0700 Subject: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. In-Reply-To: <8D6F463991A1574A8A803B8DA605414F4118A53C@ORSMSX111.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791296149EE6@fmsmsx123.amr.corp.intel.com> <6563F381B547594081EF9DE181D079129615C797@fmsmsx123.amr.corp.intel.com> <7944585b-924c-ee2f-7880-ea8566c2b608@oracle.com> <8D6F463991A1574A8A803B8DA605414F411880D8@ORSMSX111.amr.corp.intel.com> <8D6F463991A1574A8A803B8DA605414F4118A53C@ORSMSX111.amr.corp.intel.com> Message-ID: <11bc5dad-0787-193b-fe69-9bf568f377f0@oracle.com> CCing to security-dev since you touched their class. Please answer Sean's question in the bug report. I don't think .jcheck/conf change should be part of this. Thanks, Vladimir On 7/23/19 1:44 PM, Rukmannagari, Shravya wrote: > Hi Vladimir, > I have updated the patch as per your suggestions. The JMH test test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java has been modified to add support for different key lengths. Please take a look and let me know if you have any questions or comments. http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.01/ > > Thanks, > Shravya. > > -----Original Message----- > From: Rukmannagari, Shravya > Sent: Monday, July 22, 2019 7:52 AM > To: Vladimir Kozlov ; Kamath, Smita ; 'Anthony Scarpino' > Cc: Viswanathan, Sandhya ; Deshpande, Vivek R ; 'hotspot compiler' ; Shemy, Regev > Subject: RE: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. > > Hi Vladimir, > For checking the correctness, we have run the hotspot/jtreg/compiler/codegen/aes/TestAESMain.java and the entire jtreg test suite. For the JMH benchmark tests, test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java tests ECB for a key length of 128. I will extend the test for other key lengths and send out an updated patch. > > Thanks, > Shravya. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, July 18, 2019 4:02 PM > To: Kamath, Smita ; 'Anthony Scarpino' > Cc: Viswanathan, Sandhya ; Rukmannagari, Shravya ; Deshpande, Vivek R ; 'hotspot compiler' ; Shemy, Regev > Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. > > Hi Smita > > I looked on changes and they seem fine in general (mostrly copy/past of cipherBlockChaining code). > > Few comments: > > Don't use _AVX3 in macroasm method names because you have only avx512 implementation. > > Indentions are bad in inline_electronicCodeBook_AESCrypt(). > > Add test to check results of optimization. > > Would be nice to have JMH test to see performance benefits. > > You also need to add checks to Graal's test [1] to prevent failure until this intrinsic is implemented in Graal. > > Thanks, > Vladimir > > [1] > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java > > On 6/26/19 4:27 PM, Kamath, Smita wrote: >> Hi All, >> >> Could you please review AES-ECB implemented using AVX512+VAES instructions. >> >> Thanks and Regards, >> >> Smita Kamath >> >> *From:* Kamath, Smita >> *Sent:* Tuesday, June 11, 2019 4:23 PM >> *To:* 'Vladimir Kozlov' ; Anthony Scarpino >> >> *Cc:* Viswanathan, Sandhya ; Shravya >> Rukmannagari >> (shravya.rukmannagari at intel.com) ; >> hotspot compiler ; Shemy, Regev >> >> *Subject:* RFR(S) JDK-8225625: AES Electronic Codebook (ECB) >> encryption and decryption optimizations using AVX512 + VAES instructions. >> >> Hi Vladimir, >> >> As per Intel Architecture Instruction Set Reference [1] Vector AES >> Encrypt and Decrypt Operations will be supported in future Intel ISA. >> We would like to contribute optimizations for AES-ECB algorithm to >> support encryption and decryption operations using AVX512+VAES instructions. These optimizations are for x86_64 architecture that have AVX512-VAES enabled. >> >> Shravya(cc'ed) and I are co-contributors. Shay >> Gueron(shay.gueron at intel.com >> ) and Regev Shemy (regev.shemy at intel.com >> ) are the authors of the algorithm. >> >> I have tested the algorithm with Intel SDE [2] to confirm encoding and >> semantics are correctly implemented. >> >> Please take a look and let me know if you have any questions or comments. >> >> http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.00/ >> >> Bug Id: https://bugs.openjdk.java.net/browse/JDK-8225625 >> >> [1] >> https://software.intel.com/sites/default/files/managed/ad/01/253666-sd >> m-vol-2a.pdf ?(Page 152 - 159) >> >> [2] >> https://software.intel.com/en-us/articles/intel-software-development-e >> mulator >> >> Regards, >> >> Smita Kamath >> From weijun.wang at oracle.com Mon Jul 29 01:43:26 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 29 Jul 2019 09:43:26 +0800 Subject: [13] RFR 8228341: SignTwice.java fails intermittently on Windows In-Reply-To: <1564323793.2665.10.camel@paratix.ch> References: <1564323793.2665.10.camel@paratix.ch> Message-ID: > On Jul 28, 2019, at 10:23 PM, Philipp Kunz wrote: > > Hi Max, > > Glad to see SignTwice being taken from ProblemList. Is it working now with the timeout added or does it still fail on windows? It hasn't failed in the last few days. > > > I just ran a test job: SignTwice.java failed on Windows with `failed to clean up files after test`. Most likely a file is not closed. > > For the key algs, "-DkeyAlgs=EC;" or "-DkeyAlgs=EC" might be shorter for the same effect, but "-DkeyAlgs=EC;0" is all right as well. > > However, "-DdigestAlgs=SHA-256" will (far as I remember) not result in a digest that exceeds the maximum manifest line width in its encoded form as a base64 string and makes a difference. I strongly suggest to keep "-DdigestAlgs=SHA-512" or any other digest algorithm that tests line breaking of digests in signed jar file manifests. OK, I'll revert it some day, maybe as a part of JDK-8228456. However, I believe that since SignTwice always uses the same JDK to sign and verify, the line width issue will not be a problem itself, right? Thanks, Max > > Regards, > Philipp > > > > > > > On Tue, 2019-07-23 at 14:28 +0800, Weijun Wang wrote: >> Please review the patch below. This test signs the same jar multiple times. It's mainly about making sure the manifest and signature file can be updated correctly. There is no need to try different key algorithms. We can also use a faster digest algorithm. >> >> Thanks, >> Max >> >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -661,7 +661,6 @@ >> sun/security/tools/keytool/KeyToolTest.java 8224644 solaris-all >> sun/security/tools/keytool/WeakAlg.java 8224644 solaris-all >> >> -sun/security/tools/jarsigner/compatibility/SignTwice.java 8228341 windows-all >> sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all >> >> javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java 8212096 generic-all >> diff --git a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java >> --- a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java >> +++ b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java >> @@ -36,7 +36,7 @@ >> * @test >> * @library /test/lib ../warnings >> * @compile Compatibility.java >> - * @run main/othervm >> + * @run main/othervm/timeout=600 >> * -Djava.security.properties=./java.security >> * -Duser.language=en >> * -Duser.country=US >> @@ -46,8 +46,8 @@ >> * -DtestComprehensiveJarContents=true >> * -DtestJarUpdate=true >> * -Dstrict=true >> - * -DkeyAlgs=EC;#RSA;#DSA; >> - * -DdigestAlgs=SHA-512 >> + * -DkeyAlgs=EC;0 >> + * -DdigestAlgs=SHA-256 >> * SignTwice >> */ >> public class SignTwice { >> From weijun.wang at oracle.com Mon Jul 29 01:52:21 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 29 Jul 2019 09:52:21 +0800 Subject: [13] RFR 8228431: sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java fails intermittently on solaris In-Reply-To: <1564324560.2665.12.camel@paratix.ch> References: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> <1564324560.2665.12.camel@paratix.ch> Message-ID: <9DA802F2-F80E-48D7-9687-95258F652283@oracle.com> > On Jul 28, 2019, at 10:36 PM, Philipp Kunz wrote: > > Hi Max, > > While it's nice to see that your fix works around the problem, this does not look like the final remedy. I'm also quite surprised that only PreserveRawManifestEntryAndDigest should be affected whereas a number of other tests use the same kind of signing. With some luck, that PreserveRawManifestEntryAndDigest test helps with a hint to find the actual root cause. I have a gut feeling somehow that the problem here might not only affect tests and I'd rather opt for filing another bug now, which may as well be investigated and solved later and independently. The change has obviously stop the test failure so there must be something wrong with the native library. I'll ping the owner of that library. > > As the patch looks now, the resulting code will not mention that the "security.provider" settings were introduced only for solaris. The next poor guy who reads it will wonder why it is there and not understand. Perfect would be a reference to a bug probably yet to be created as already suggested or otherwise I'd welcome to see at least a comment with some explanation of what we currently know. I'll add some comment to the no-native-provider.conf file itself. Thanks, Max > > Regards, > Philipp > > > On Fri, 2019-07-26 at 22:57 +0800, Weijun Wang wrote: >> Please review the fix at >> >> >> http://cr.openjdk.java.net/~weijun/8228431/webrev.00/ >> >> >> The no-native-provider.conf file put SUN and SunRsaSign as the first 2 security providers and thus shadows the OracleUcrypto and SunPKCS11 providers used by Solaris. Please note that duplicated provider names are silently ignored so this is harmless. On other platforms, the first 2 providers are already SUN and SunRsaSign. >> >> I ran the test 200 times on solaris-sparcv9 and it does not fail once. Before this fix, it always fails on this platform. >> >> An alternative fix is to simply exclude the test from solaris-sparc using `@requires os.family != "solaris"`. I've fixed some other security/tools test failures using this solution. The reason is that these tests are testing platform-independent behaviors so it's OK to skip one platform. I don't think this test is platform-dependent in any way. >> >> Thanks, >> Max >> >> From weijun.wang at oracle.com Mon Jul 29 02:20:14 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 29 Jul 2019 10:20:14 +0800 Subject: [13] RFR 8228456: Enhance tests after JDK-8217375 In-Reply-To: <1564327730.2665.14.camel@paratix.ch> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> <670DD939-5FF1-4455-8990-3987693AD14B@oracle.com> <1564327730.2665.14.camel@paratix.ch> Message-ID: > On Jul 28, 2019, at 11:28 PM, Philipp Kunz wrote: > > Hi Max, > > jarsignerProc is definitively a spot where significant amount of time is spent in the test unlike what is before and what is after it. Have you measured how much your change would make the test faster? My bet is it would not be significant. Tell me if I'm wrong. There is some difference. I first applied your recent patch, then my no-native-library.conf patch and run that test 40 times: mean duration is 153 seconds. Then I apply the change in this mail, it's 59 seconds. > As I see it, we are, at least to some extent, back to a discussion we already started. Not exactly. Please note that I haven't called "jarsigner -verify" at all, no matter inside the VM or as a separate process. I simply look into the CodeSigner (and you have already obtained them) to check the number and names. > ... > We might consider removing the parallel=true or add a threadPoolSize parameter to it with a suitable value that fits the test machines. Turns out parallel=true is irrelevant with the failure of this test. It's all about the native library. And after the disabling of native libraries, even running jarsigner as a proc is now acceptable. This makes the fix of this bug non urgent. I am thinking of fixing it in JDK 14, which means I can include your other src changes. Thanks, Max > > Regards, > Philipp > > > > On Thu, 2019-07-25 at 17:38 +0800, Weijun Wang wrote: >> Hi Philipp, >> >> Most are fine but PreserveRawManifestEntryAndDigest.java is still very slow and fails intermittently. >> >> The problem is due to jarsignerProc(). Since you have parallel=true for the test providers, many jarsigner processes would run at the same time and some of our test machines cannot load so many processes (they are also running other jobs). >> >> I read about the place when jarsignerProc() is called and seems you want to make sure the first file is signed by A and the second is not. Can we do this using JarFile API? Does you have other things to check in getExpectedJarSignerOutputUpdatedContentNotValidatedBySignerA()? >> >> How about we remove the `jarsigner -verify` call? Like this: >> >> // double-check reading the files with a verifying JarFile >> try (JarFile jar = new JarFile(jarFilename4, true)) { >> if (firstAddedFilename != null) { >> JarEntry je1 = jar.getJarEntry(firstAddedFilename); >> jar.getInputStream(je1).readAllBytes(); >> - assertTrue(je1.getCodeSigners().length > 0); >> + CodeSigner[] ss = je1.getCodeSigners(); >> + assertTrue(ss.length == 2); >> + assertTrue(containsSignerA(ss)); >> } >> if (secondAddedFilename != null) { >> JarEntry je2 = jar.getJarEntry(secondAddedFilename); >> jar.getInputStream(je2).readAllBytes(); >> - assertTrue(je2.getCodeSigners().length > 0); >> + CodeSigner[] ss = je2.getCodeSigners(); >> + assertTrue(ss.length == 1); >> + assertFalse(containsSignerA(ss)); >> } >> } >> >> @@ -392,6 +380,17 @@ >> } >> } >> >> + private static boolean containsSignerA(CodeSigner[] ss) { >> + for (CodeSigner s : ss) { >> + X509Certificate x = (X509Certificate) >> + s.getSignerCertPath().getCertificates().get(0); >> + if (x.getSubjectX500Principal().toString().equals("CN=A")) { >> + return true; >> + } >> + } >> + return false; >> + } >> + >> >> Thanks, >> Max >> >>> On Jul 22, 2019, at 10:02 AM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8228456/webrev.00/ >>> >>> The change is contributed by Philipp Kunz. Since we are now in RDP 2 and we are not allowed to fix non-test P3 (and lower) bugs. I've removed all src/ changes in Philipp's patch (If I read correctly, is mostly on renaming methods, and brings no behavior change) and made necessary change in test codes to use original method names. >>> >>> I haven't read the changes yet. I only made sure they pass on my own system. Oracle's test farm is in maintenance during the weekend. >>> >>> Thanks, >>> Max >>> >> From weijun.wang at oracle.com Mon Jul 29 02:56:50 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 29 Jul 2019 10:56:50 +0800 Subject: RFR 8217375: jarsigner breaks old signature with long lines in manifest In-Reply-To: <1564330358.2665.17.camel@paratix.ch> References: <1547972414.2363.9.camel@paratix.ch> <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com> <1548019729.2363.13.camel@paratix.ch> <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com> <1551972450.2495.29.camel@paratix.ch> <3E4EBC5A-20D4-4826-AD20-435355023450@oracle.com> <1561894686.2441.49.camel@paratix.ch> <842B0A6C-1442-44A3-A362-C957A1585A67@oracle.com> <1562141214.2441.54.camel@paratix.ch> <74C03AB4-2986-4F36-B616-A845EFBE1F7B@oracle.com> <09E4D929-6715-43E5-B876-4DF4210FB167@oracle.com> <8DD16FC2-8426-4785-BB5B-7517132AF247@oracle.com> <1563655790.2506.7.camel@paratix.ch> <8A9A149A-FEBB-4158-843C-21C42CBAB547@oracle.com> <1564330358.2665.17.camel@paratix.ch> Message-ID: The FIXED_xxx looks like something undone but it also points out what kinds of fixes you have done. It confirms what parts of the original code used to fail and how they behave correctly now. It's like the test auto-verifies the regression being fixed. We can remove it in JDK 14. Are you OK with delaying "8228456: Enhance tests after JDK-8217375" to JDK 14? Thanks, Max > On Jul 29, 2019, at 12:12 AM, Philipp Kunz wrote: > > Hi Max and John, > > Just saw it now and it sounds very reassuring that you say you reviewed all the tests. Thank you so much for that non-trivial piece of work of quite some amount. > > Now I see the FIXED_xxx stuff appearing in the head branch which it was not intended to originally. For example: > http://hg.openjdk.java.net/jdk/jdk/file/5e637f790bb8/test/jdk/sun/security/util/ManifestDigester/FindSection.java#l54 > > In my opinion this should have been used to "calibrate the tests", meaning to switch the flag, check where it is used manually and run the new tests against the old src, in order to confirm that ManifestDigester's and other classes's behavior has not changed in an undesired way, before merging it. > If that "calibration" still works now successfully, the flags and the code becoming unreachable without them can and also should now be removed. > > This is probably something occurring hardly ever but ManifestDigester had almost no test coverage before 8217375 and I would not feel comfortable unless a reviewer confirms that all the new tests actually and correctly conserve behavior that should not change as intended. See also https://mail.openjdk.java.net/pipermail/security-dev/2019-July/020453.html. > > It's not exactly dramatic that the FIXED_xxx stuff has now found its way to the head branch but it will never ever be useful again. It's also not exactly urgent but could it be removed? This is most certainly exceptional but if I may suggest it with all modesty and due respect, I'd see and welcome it as a confirmation of a successful review of the "calibration" if someone else would remove it. How does that sound or what would you or any policy or existing procedure suggest? > > Regards, > Philipp > > > > On Sun, 2019-07-21 at 08:08 +0800, Weijun Wang wrote: >> Hi Philipp, >> >> I just took a brief look at the new patch. Looks like the src change has no behavior change (even in JarSigner.java with so many line changes). This is good. >> >> John and I have reviewed all the tests and we sent out some feedbacks in previous mails, and it's definitely a part of the whole review process. The single reason I integrated your changeset earlier this week is because RDP 2 starts at July 18 and after the date only P1-P2 src change would be approved but we can still modify the tests. Before pushing the change, I ran all tests, modified 2 regex patterns, and added one to problem list to make sure it makes no (or, as little as possible) noise (esp for other people running the tests). I haven't made any big change to the tests (including removing those FIXED_xxxxxxx flags) myself because I was still waiting for your reply. Thanks for coming back, so that we can start enhancing the tests now. Some test (Ex: PreserveRawManifestEntryAndDigest.java) still spends a lot of time and could intermittently time out. >> >> I'll file a new bug and post the interdiff between the integrated change and your new patch as the webrev.00 of it. >> >> Thanks, >> Max >> >> From philipp.kunz at paratix.ch Mon Jul 29 06:54:48 2019 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Mon, 29 Jul 2019 08:54:48 +0200 Subject: [13] Re: RFR 8217375: jarsigner breaks old signature with long lines in manifest In-Reply-To: References: <1564323793.2665.10.camel@paratix.ch> Message-ID: <1564383288.2445.8.camel@paratix.ch> Hi Max, Yes, you are right. I confused it with an invocation of Compatibility test I imagine should be done (maybe already is) like the previously existing one for TSA compatibility. See some related mails below. Invoking SignTwice with only the current jdk does not actually verify any kind of compatibility in between different JDK versions and might possibly even be skipped altogether. I thought of it as a template for how to call it with several JDKs. Regards, Philipp Date: Sun, 09 Jun 2019 12:05:47 +0200Subject: Re: Jarsigner compatibility issue invalidating existing signaturesTo: Weijun Wang From: Philipp Kunz > Hi Max, > > Bug 8217375 is about compatibility between different jdk versions and > cannot easily be tested inside just one jdk version like most other > bugs. To get a really meaningful test I figure either lots of signed > jar files have to be checked in, or the code that is changed and was > used to sign jars has to be moved into the tests, or the current test > uses previous jdk versions to produce and verify signed jars. The > last option is the one I chose to prefer and I found that > Compatibility test is a very close match I considered a pretty good > fit. > > Rather than extending Compatibility test, we could as well create > some similar new test, but in my opinion it would duplicate too much. > Compatibility test already comes with a list of previous jdks which > can be re-used to verify inter-jdk-version signature compatibility. I > would not opt to build up another such a configuration prerequisite > and?would rather?re-use that existing infrastructure. > > I already got quite an impression of the time it takes even with a > small number of jdks. This is why I added new parameters to run the > test with, all of which with the idea to default to values resulting > in the previous behavior. If I did everything right, no-one would or > should even notice the difference when running Compatibility with the > same parameters as before. > > Eventually I suggest that more tests are run which involve > combinations of different jdk versions and that will sure add some > time to process. Not all possible combinations of different > parameters will have to be actually tested. For example I don't see > necessity to try all possible combinations of TSA digests and > signature algorithms because I consider them independent. What > exactly should be tested is probably worth to discuss in more detail. > > I don't currently have an updated version of the fix but I'll be glad > to provide one with the first consent how to update it. > BTW, did you not post your message to the mailing list intentionally? > > Regards, > Philipp Date: Tue, 11 Jun 2019 08:41:52 +0200Subject: Re: Jarsigner compatibility issue invalidating existing signaturesTo: Weijun Wang From: Philipp Kunz > Hi Max, > > In any case I prefer to include the change to Compatibility. I don't > know if my role as a contributor would entitle me to insist but I > certainly welcome if you could ask Compatibility's reviewer and > maintainer. The P3 priority it got might help. > > On the other hand, it might be feasible to cover those cases with > some binary jars checked into the tests. I see it as a lesser > desirable alternative but it might work. I'm still thinking about how > these tests should look like in detail. > > Regards, > Philipp Date: Thu, 23 May 2019 09:49:02 +0800Subject: Re: Jarsigner compatibility issue invalidating existing signaturesTo: Philipp Kunz

From: Weijun Wang > Hi Philipp, > > ... > > Is it necessary to update Compatibility.java? This test is maintained > by SQE and they run it with a script internally. The test is already > spending a lot of time and I do not want to add more. > > ... > > Thanks, > Max On Mon, 2019-07-29 at 09:43 +0800, Weijun Wang wrote: > > On Jul 28, 2019, at 10:23 PM, Philipp Kunz > > wrote: > > > > Hi Max, > > > > Glad to see SignTwice being taken from ProblemList. Is it working > > now with the timeout added or does it still fail on windows? > > It hasn't failed in the last few days. > > > > I just ran a test job: SignTwice.java failed on Windows with > > > `failed to clean up files after test`. Most likely a file is not > > > closed. > > > > For the key algs, "-DkeyAlgs=EC;" or "-DkeyAlgs=EC" might be > > shorter for the same effect, but "-DkeyAlgs=EC;0" is all right as > > well. > > > > However, "-DdigestAlgs=SHA-256" will (far as I remember) not result > > in a digest that exceeds the maximum manifest line width in its > > encoded form as a base64 string and makes a difference. I strongly > > suggest to keep "-DdigestAlgs=SHA-512" or any other digest > > algorithm that tests line breaking of digests in signed jar file > > manifests. > > OK, I'll revert it some day, maybe as a part of JDK-8228456. > > However, I believe that since SignTwice always uses the same JDK to > sign and verify, the line width issue will not be a problem itself, > right? > > Thanks, > Max > > > Regards, > > Philipp > > > > > > > > > > > > > > On Tue, 2019-07-23 at 14:28 +0800, Weijun Wang wrote: > > > Please review the patch below. This test signs the same jar > > > multiple times. It's mainly about making sure the manifest and > > > signature file can be updated correctly. There is no need to try > > > different key algorithms. We can also use a faster digest > > > algorithm. > > > > > > Thanks, > > > Max > > > > > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > > > --- a/test/jdk/ProblemList.txt > > > +++ b/test/jdk/ProblemList.txt > > > @@ -661,7 +661,6 @@ > > > ?sun/security/tools/keytool/KeyToolTest.java????????????????????? > > > 8224644 solaris-all > > > ?sun/security/tools/keytool/WeakAlg.java????????????????????????? > > > 8224644 solaris-all > > > ? > > > -sun/security/tools/jarsigner/compatibility/SignTwice.java??????? > > > 8228341 windows-all > > > ?sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java?????? > > > 8026393 generic-all > > > ? > > > ?javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java??????? > > > 8212096 generic-all > > > diff --git > > > a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.j > > > ava > > > b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.j > > > ava > > > --- > > > a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.j > > > ava > > > +++ > > > b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.j > > > ava > > > @@ -36,7 +36,7 @@ > > > ? * @test > > > ? * @library /test/lib ../warnings > > > ? * @compile Compatibility.java > > > - * @run main/othervm > > > + * @run main/othervm/timeout=600 > > > ? *??-Djava.security.properties=./java.security > > > ? *??-Duser.language=en > > > ? *??-Duser.country=US > > > @@ -46,8 +46,8 @@ > > > ? *??-DtestComprehensiveJarContents=true > > > ? *??-DtestJarUpdate=true > > > ? *??-Dstrict=true > > > - *??-DkeyAlgs=EC;#RSA;#DSA; > > > - *??-DdigestAlgs=SHA-512 > > > + *??-DkeyAlgs=EC;0 > > > + *??-DdigestAlgs=SHA-256 > > > ? *??SignTwice > > > ? */ > > > ?public class SignTwice { > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Jul 29 14:57:36 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 29 Jul 2019 10:57:36 -0400 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> <748a353d-7d27-0045-6b07-e188728f8e30@oracle.com> Message-ID: <0cd49f35-f636-9f4c-c324-191a5a6dbc0d@oracle.com> On 7/28/19 1:42 PM, Xuelei Fan wrote: > On 7/26/2019 7:08 AM, Xuelei Fan wrote: >> New webrev: >> http://cr.openjdk.java.net/~xuelei/8226374/webrev.03/ >> > >> >>> * >>> src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java >>> >>> 114???????????? if ((namedGroup == null) || (!namedGroup.isAvailable)) { >>> >>> You don't do this check for null and isAvailable in other places, for >>> example >>> ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() - >>> should you? >>> >> Good point!? Currently, the restriction is only checked for the >> supported group extension.? I should add more check points in other >> places where named groups are used, for example client key exchange >> and certificate.? Stay tune for the next webrev. >> > The ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() > should be fine as the namedGroup has been checked in the previous steps > (X509Authentication.X509PossessionGenerator.createServerPossession()). > > However, I missed the check for certificate.? The consumer of > certificate should check the named groups to make sure the supported > named group is used.? It was not a problem in the past as the supported > named groups are used to indicate the EC curve or DH group is able to be > handled in both side. > > It could be a problem now when we want to restrict named groups.? The > named groups used in a certificate should be checked in key manager and > trust manager for TLS 1.2 and prior versions.? Similar to the signature > schemes for TLS 1.3.? As may required new APIs > (SSLParameters.getPeerSupportedNamedGroups()) for a generic solution. > > Would you mind if I file a new RFE and make the improvement in JDK 14 > later? Ok. I had a comment/question on the CSR [1]. In the Solution section, you list the legacy signature schemes as: dsa_sha256 ecdsa_sha224 rsa_sha224 dsa_sha224 ecdsa_sha1 rsa_pkcs1_sha1 dsa_sha1 rsa_md5 However, the IANA registry for TLS defines them differently: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 Can you clarify why we have this difference and how the JDK uses these legacy algorithms? I don't want to define them as standard names unless I can reference a TLS specification. Thanks, Sean From xuelei.fan at oracle.com Mon Jul 29 15:55:56 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 29 Jul 2019 08:55:56 -0700 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: <0cd49f35-f636-9f4c-c324-191a5a6dbc0d@oracle.com> References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> <748a353d-7d27-0045-6b07-e188728f8e30@oracle.com> <0cd49f35-f636-9f4c-c324-191a5a6dbc0d@oracle.com> Message-ID: On 7/29/2019 7:57 AM, Sean Mullan wrote: > On 7/28/19 1:42 PM, Xuelei Fan wrote: >> On 7/26/2019 7:08 AM, Xuelei Fan wrote: >>> New webrev: >>> http://cr.openjdk.java.net/~xuelei/8226374/webrev.03/ >>> >> >>> >>>> * >>>> src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java >>>> >>>> 114???????????? if ((namedGroup == null) || >>>> (!namedGroup.isAvailable)) { >>>> >>>> You don't do this check for null and isAvailable in other places, >>>> for example >>>> ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() - >>>> should you? >>>> >>> Good point!? Currently, the restriction is only checked for the >>> supported group extension.? I should add more check points in other >>> places where named groups are used, for example client key exchange >>> and certificate.? Stay tune for the next webrev. >>> >> The ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() >> should be fine as the namedGroup has been checked in the previous >> steps >> (X509Authentication.X509PossessionGenerator.createServerPossession()). >> >> However, I missed the check for certificate.? The consumer of >> certificate should check the named groups to make sure the supported >> named group is used.? It was not a problem in the past as the >> supported named groups are used to indicate the EC curve or DH group >> is able to be handled in both side. >> >> It could be a problem now when we want to restrict named groups.? The >> named groups used in a certificate should be checked in key manager >> and trust manager for TLS 1.2 and prior versions.? Similar to the >> signature schemes for TLS 1.3.? As may required new APIs >> (SSLParameters.getPeerSupportedNamedGroups()) for a generic solution. >> >> Would you mind if I file a new RFE and make the improvement in JDK 14 >> later? > > Ok. I had a comment/question on the CSR [1]. In the Solution section, > you list the legacy signature schemes as: > > dsa_sha256 > ecdsa_sha224 > rsa_sha224 > dsa_sha224 > ecdsa_sha1 > rsa_pkcs1_sha1 > dsa_sha1 > rsa_md5 > > However, the IANA registry for TLS defines them differently: > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 > > > Can you clarify why we have this difference and how the JDK uses these > legacy algorithms? I added some description above these legacy signature schemes. https://bugs.openjdk.java.net/browse/JDK-8227445 > I don't want to define them as standard names unless > I can reference a TLS specification. > These names should not be used for future applications. It's fine to me if they are not part of the standard names. Thanks, Xuelei From xuelei.fan at oracle.com Mon Jul 29 17:48:44 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 29 Jul 2019 10:48:44 -0700 Subject: Request for Review [14] JDK-8228742 Get back javax/net/ssl/SSLSocket/Tls13PacketSize.java Message-ID: Hi, Could I have the following udpate reviewed? http://cr.openjdk.java.net/~xuelei/8228742/webrev.00/ The test javax/net/ssl/SSLSocket/Tls13PacketSize.java was problem listed for JDK-8224718, which has been fixed in the duplicated JDK-8224829. The test can be back now. Thanks, Xuelei From sean.mullan at oracle.com Mon Jul 29 18:08:12 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 29 Jul 2019 14:08:12 -0400 Subject: Request for Review [14] JDK-8228742 Get back javax/net/ssl/SSLSocket/Tls13PacketSize.java In-Reply-To: References: Message-ID: <04c82e4a-e64e-455e-adf2-c36ffdfaca63@oracle.com> I would suggest changing synopsis to "Remove javax/net/ssl/SSLSocket/Tls13PacketSize.java from ProblemList". I would also add a link to JDK-8224829. Looks fine otherwise. --Sean On 7/29/19 1:48 PM, Xuelei Fan wrote: > Hi, > > Could I have the following udpate reviewed? > ?? http://cr.openjdk.java.net/~xuelei/8228742/webrev.00/ > > The test javax/net/ssl/SSLSocket/Tls13PacketSize.java was problem listed > for JDK-8224718, which has been fixed in the duplicated JDK-8224829. The > test can be back now. > > Thanks, > Xuelei From xuelei.fan at oracle.com Mon Jul 29 18:21:49 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 29 Jul 2019 11:21:49 -0700 Subject: Request for Review [14] JDK-8228742 Get back javax/net/ssl/SSLSocket/Tls13PacketSize.java In-Reply-To: <04c82e4a-e64e-455e-adf2-c36ffdfaca63@oracle.com> References: <04c82e4a-e64e-455e-adf2-c36ffdfaca63@oracle.com> Message-ID: <90a2d431-2eb7-cb73-6a3b-e78034f4d107@oracle.com> Updated. Thanks, Xuelei On 7/29/2019 11:08 AM, Sean Mullan wrote: > I would suggest changing synopsis to "Remove > javax/net/ssl/SSLSocket/Tls13PacketSize.java from ProblemList". I would > also add a link to JDK-8224829. > > Looks fine otherwise. > > --Sean > > On 7/29/19 1:48 PM, Xuelei Fan wrote: >> Hi, >> >> Could I have the following udpate reviewed? >> ??? http://cr.openjdk.java.net/~xuelei/8228742/webrev.00/ >> >> The test javax/net/ssl/SSLSocket/Tls13PacketSize.java was problem >> listed for JDK-8224718, which has been fixed in the duplicated >> JDK-8224829. The test can be back now. >> >> Thanks, >> Xuelei From valerie.peng at oracle.com Mon Jul 29 19:05:41 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 29 Jul 2019 12:05:41 -0700 Subject: [14] RFR 8228668: compiler/codegen/aes/TestAESMain.java failed with GCM mode must be used with NoPadding In-Reply-To: References: <326378c5-2743-5b5c-9ef4-d61a5d964456@oracle.com> Message-ID: Sure, thanks for review~ Valerie On 7/26/2019 4:17 PM, Xuelei Fan wrote: > Looks good to me. > > Just a nit: > > ? 58????????? "NoPadding":"PKCS5Padding"); > I may use a white space before and after the "?" and ":" operators. > > Xuelei > > On 7/26/2019 3:07 PM, Valerie Peng wrote: >> Sorry, should be for JDK 14. Fixed the subject. >> >> Valerie >> >> On 7/26/2019 3:05 PM, Valerie Peng wrote: >>> Any one can help review this? It's for updating a hotspot regression >>> test to use NoPadding when using AES GCM mode. >>> >>> The regression test started failing after JDK8180392 "SunJCE >>> provider should throw exceptions for unsupported mode and padding >>> combinations" is integrated. Also removed some dead code in the >>> other regression test. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228668 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8228668/webrev.00/ >>> >>> Thanks, >>> Valerie From RAJAN.HALADE at ORACLE.COM Mon Jul 29 22:06:23 2019 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Mon, 29 Jul 2019 15:06:23 -0700 Subject: RFR: 8228755: ProblemList sun/security/tools/jarsigner/Warning.java Message-ID: Please review this patch to problem list Warning.java. I am not able to reproduce the failure and will require more time to find root cause and fix. diff -r f459f98aa30d test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Mon Jul 29 20:18:43 2019 +0000 +++ b/test/jdk/ProblemList.txt Mon Jul 29 15:03:16 2019 -0700 @@ -661,6 +661,8 @@ sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java 8228431 solaris-all +sun/security/tools/jarsigner/Warning.java 8228745 generic-all + javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java 8212096 generic-all javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon Jul 29 23:04:34 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 29 Jul 2019 16:04:34 -0700 Subject: RFR: 8228755: ProblemList sun/security/tools/jarsigner/Warning.java In-Reply-To: References: Message-ID: <2c08d828-e254-3e53-45c8-ef8b5247692f@oracle.com> Looks good to me. Xuelei On 7/29/2019 3:06 PM, Rajan Halade wrote: > Please review this patch to problem list Warning.java. I am not able to > reproduce the failure and will require more time to find root cause and fix. > > diff -r f459f98aa30d test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txtMon Jul 29 20:18:43 2019 +0000 > +++ b/test/jdk/ProblemList.txtMon Jul 29 15:03:16 2019 -0700 > @@ -661,6 +661,8 @@ > ?sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java > 8026393 generic-all > ?sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java > 8228431 solaris-all > > > +sun/security/tools/jarsigner/Warning.java ? ? ? ? ? ? ? ? ? ? ? 8228745 > generic-all > + > ?javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java > 8212096 generic-all > ?javax/net/ssl/DTLS/PacketLossRetransmission.java > 8169086 macosx-x64 > ?javax/net/ssl/DTLS/RespondToRetransmit.java > 8169086 macosx-x64 > > Thanks, > Rajan From weijun.wang at oracle.com Tue Jul 30 02:03:37 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 30 Jul 2019 10:03:37 +0800 Subject: [14] RFR 8228745: sun/security/tools/jarsigner/Warning.java test timeout Message-ID: Turns out a previous code change accidentally ignore the input of a process, and this test calls this method. Please review the patch below: diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -661,8 +661,6 @@ sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java 8228431 solaris-all -sun/security/tools/jarsigner/Warning.java 8228745 generic-all - javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java 8212096 generic-all javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 diff --git a/test/lib/jdk/test/lib/process/ProcessTools.java b/test/lib/jdk/test/lib/process/ProcessTools.java --- a/test/lib/jdk/test/lib/process/ProcessTools.java +++ b/test/lib/jdk/test/lib/process/ProcessTools.java @@ -360,7 +360,7 @@ * @return The {@linkplain OutputAnalyzer} instance wrapping the process. */ public static OutputAnalyzer executeProcess(ProcessBuilder pb, String input) throws Exception { - return executeProcess(pb, null, null); + return executeProcess(pb, input, null); } /** Noreg-self. Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue Jul 30 03:12:47 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 29 Jul 2019 20:12:47 -0700 Subject: [14] RFR 8228745: sun/security/tools/jarsigner/Warning.java test timeout In-Reply-To: References: Message-ID: <4a575496-82ca-6820-3fdb-898a4b8d719e@oracle.com> Looks good to me. Xuelei On 7/29/2019 7:03 PM, Weijun Wang wrote: > Turns out a previous code change accidentally ignore the input of a > process, and this test calls this method. > > Please review the patch below: > > *diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt* > *--- a/test/jdk/ProblemList.txt* > *+++ b/test/jdk/ProblemList.txt* > @@ -661,8 +661,6 @@ > ?sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java > 8026393 generic-all > ?sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java > 8228431 solaris-all > > > -sun/security/tools/jarsigner/Warning.java ? ? ? ? ? ? ? ? ? ? ? 8228745 > generic-all > - > ?javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java > 8212096 generic-all > ?javax/net/ssl/DTLS/PacketLossRetransmission.java > 8169086 macosx-x64 > ?javax/net/ssl/DTLS/RespondToRetransmit.java > 8169086 macosx-x64 > *diff --git a/test/lib/jdk/test/lib/process/ProcessTools.java > b/test/lib/jdk/test/lib/process/ProcessTools.java* > *--- a/test/lib/jdk/test/lib/process/ProcessTools.java* > *+++ b/test/lib/jdk/test/lib/process/ProcessTools.java* > @@ -360,7 +360,7 @@ > ? ? ? * @return The {@linkplain OutputAnalyzer} instance wrapping the > process. > ? ? ? */ > ?? ? public static OutputAnalyzer executeProcess(ProcessBuilder pb, > String input) throws Exception { > -? ? ? ? return executeProcess(pb, null, null); > +? ? ? ? return executeProcess(pb, input, null); > ?? ? } > > > ?? ? /** > > Noreg-self. > > Thanks, > Max > From sean.mullan at oracle.com Tue Jul 30 17:33:41 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 30 Jul 2019 13:33:41 -0400 Subject: RFR: 8210755: Define standard names for EC curves and TLS signature schemes Message-ID: <1e5b7e3a-3aa0-5f74-9330-9d2b7ac0ee6d@oracle.com> Please review this change to define standard names for EC curves, TLS signature schemes, and TLS named groups. These names (which are Strings) are used in security APIs (ECGenParameterSpec) and system/security properties (jdk.tls.namedGroups and jdk.tls.disabledAlgorithms). webrev: http://cr.openjdk.java.net/~mullan/webrevs/8210755/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8228752 The webrev changes just include links from the APIs to the new sections in the Standard Algorithm Names specification. See the CSR for details on the new algorithms and changes to the specification. Thanks, Sean From xuelei.fan at oracle.com Tue Jul 30 20:16:23 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 30 Jul 2019 13:16:23 -0700 Subject: RFR: 8210755: Define standard names for EC curves and TLS signature schemes In-Reply-To: <1e5b7e3a-3aa0-5f74-9330-9d2b7ac0ee6d@oracle.com> References: <1e5b7e3a-3aa0-5f74-9330-9d2b7ac0ee6d@oracle.com> Message-ID: Both webrev and CSR look good to me. Xuelei On 7/30/2019 10:33 AM, Sean Mullan wrote: > Please review this change to define standard names for EC curves, TLS > signature schemes, and TLS named groups. > > These names (which are Strings) are used in security APIs > (ECGenParameterSpec) and system/security properties (jdk.tls.namedGroups > and jdk.tls.disabledAlgorithms). > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8210755/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8228752 > > The webrev changes just include links from the APIs to the new sections > in the Standard Algorithm Names specification. See the CSR for details > on the new algorithms and changes to the specification. > > Thanks, > Sean From weijun.wang at oracle.com Wed Jul 31 04:31:54 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 31 Jul 2019 12:31:54 +0800 Subject: [13] RFR 8228431: sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java fails intermittently on solaris In-Reply-To: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> References: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> Message-ID: <97441EBB-3F30-49CD-988B-4C8D49EFAF12@oracle.com> Ping again. This is the only security bug that must be resolved in JDK 13. Please. Thanks, Max > On Jul 26, 2019, at 10:57 PM, Weijun Wang wrote: > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8228431/webrev.00/ > > The no-native-provider.conf file put SUN and SunRsaSign as the first 2 security providers and thus shadows the OracleUcrypto and SunPKCS11 providers used by Solaris. Please note that duplicated provider names are silently ignored so this is harmless. On other platforms, the first 2 providers are already SUN and SunRsaSign. > > I ran the test 200 times on solaris-sparcv9 and it does not fail once. Before this fix, it always fails on this platform. > > An alternative fix is to simply exclude the test from solaris-sparc using `@requires os.family != "solaris"`. I've fixed some other security/tools test failures using this solution. The reason is that these tests are testing platform-independent behaviors so it's OK to skip one platform. I don't think this test is platform-dependent in any way. > > Thanks, > Max > From xuelei.fan at oracle.com Wed Jul 31 05:11:23 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 30 Jul 2019 22:11:23 -0700 Subject: [13] RFR 8228431: sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java fails intermittently on solaris In-Reply-To: <97441EBB-3F30-49CD-988B-4C8D49EFAF12@oracle.com> References: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> <97441EBB-3F30-49CD-988B-4C8D49EFAF12@oracle.com> Message-ID: <713ea305-3832-c85b-2651-769711d0b44c@oracle.com> Just a minimal comment. You can leave it as is. No more code review required for me. PreserveRawManifestEntryAndDigest.java -------------------------------------- I'm not very sure of line 63: 63 * @run main jdk.test.lib.FileInstaller ... 64 * @run testng/othervm/timeout=1200 ... It's OK but I don't like the dependency between line 63 and 64. The following code could be used in the test code if you want to avoid line 63. System.getProperty("test.src", ".") + "/no-native-provider.conf" But it may not worthy an update here. Is it required to remove the copied file in 63? I'm fine as well if you want to exclude the test for Solaris platforms (my preference). But please file a new bug if you find something unusual for Solaris platforms. Thanks, Xuelei On 7/30/2019 9:31 PM, Weijun Wang wrote: > Ping again. > > This is the only security bug that must be resolved in JDK 13. Please. > > Thanks, > Max > >> On Jul 26, 2019, at 10:57 PM, Weijun Wang wrote: >> >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/8228431/webrev.00/ >> >> The no-native-provider.conf file put SUN and SunRsaSign as the first 2 security providers and thus shadows the OracleUcrypto and SunPKCS11 providers used by Solaris. Please note that duplicated provider names are silently ignored so this is harmless. On other platforms, the first 2 providers are already SUN and SunRsaSign. >> >> I ran the test 200 times on solaris-sparcv9 and it does not fail once. Before this fix, it always fails on this platform. >> >> An alternative fix is to simply exclude the test from solaris-sparc using `@requires os.family != "solaris"`. I've fixed some other security/tools test failures using this solution. The reason is that these tests are testing platform-independent behaviors so it's OK to skip one platform. I don't think this test is platform-dependent in any way. >> >> Thanks, >> Max >> > From weijun.wang at oracle.com Wed Jul 31 06:48:42 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 31 Jul 2019 14:48:42 +0800 Subject: [13] RFR 8228431: sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java fails intermittently on solaris In-Reply-To: <713ea305-3832-c85b-2651-769711d0b44c@oracle.com> References: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> <97441EBB-3F30-49CD-988B-4C8D49EFAF12@oracle.com> <713ea305-3832-c85b-2651-769711d0b44c@oracle.com> Message-ID: <30FE7A0D-9C16-4B85-A1F7-F50313E23DE1@oracle.com> > On Jul 31, 2019, at 1:11 PM, Xuelei Fan wrote: > > I'm fine as well if you want to exclude the test for Solaris platforms (my preference). But please file a new bug if you find something unusual for Solaris platforms. Why file a new bug if this one already exists? Since the bug is now in problem list for solaris, and I am quite confident this is related to ucrypto. Is it better to leave it open and delay it to a future release? I can now reproduce the failure on a solaris machine but if I simplify the test into only the single method that triggers the error, the test succeeds. Maybe many calls into ucrypto has corrupted the internal state and a final update call destroys it. Thanks, Max From Xuelei.Fan at Oracle.Com Wed Jul 31 06:58:33 2019 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 30 Jul 2019 23:58:33 -0700 Subject: [13] RFR 8228431: sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java fails intermittently on solaris In-Reply-To: <30FE7A0D-9C16-4B85-A1F7-F50313E23DE1@oracle.com> References: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> <97441EBB-3F30-49CD-988B-4C8D49EFAF12@oracle.com> <713ea305-3832-c85b-2651-769711d0b44c@oracle.com> <30FE7A0D-9C16-4B85-A1F7-F50313E23DE1@oracle.com> Message-ID: > On Jul 30, 2019, at 11:48 PM, Weijun Wang wrote: > > > >> On Jul 31, 2019, at 1:11 PM, Xuelei Fan wrote: >> >> I'm fine as well if you want to exclude the test for Solaris platforms (my preference). But please file a new bug if you find something unusual for Solaris platforms. > > Why file a new bug if this one already exists? > > Since the bug is now in problem list for solaris, and I am quite confident this is related to ucrypto. Is it better to leave it open and delay it to a future release? I agreed it is better. Xuelei > I can now reproduce the failure on a solaris machine but if I simplify the test into only the single method that triggers the error, the test succeeds. Maybe many calls into ucrypto has corrupted the internal state and a final update call destroys it. > > Thanks, > Max > > From valerie.peng at oracle.com Wed Jul 31 17:30:55 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 31 Jul 2019 10:30:55 -0700 Subject: [13] RFR 8228431: sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java fails intermittently on solaris In-Reply-To: <30FE7A0D-9C16-4B85-A1F7-F50313E23DE1@oracle.com> References: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> <97441EBB-3F30-49CD-988B-4C8D49EFAF12@oracle.com> <713ea305-3832-c85b-2651-769711d0b44c@oracle.com> <30FE7A0D-9C16-4B85-A1F7-F50313E23DE1@oracle.com> Message-ID: I think it's easier to just skip this test for Solaris if this test runs fine on all other non-Solaris platforms. Just my .02, Valerie On 7/30/2019 11:48 PM, Weijun Wang wrote: > >> On Jul 31, 2019, at 1:11 PM, Xuelei Fan wrote: >> >> I'm fine as well if you want to exclude the test for Solaris platforms (my preference). But please file a new bug if you find something unusual for Solaris platforms. > Why file a new bug if this one already exists? > > Since the bug is now in problem list for solaris, and I am quite confident this is related to ucrypto. Is it better to leave it open and delay it to a future release? I can now reproduce the failure on a solaris machine but if I simplify the test into only the single method that triggers the error, the test succeeds. Maybe many calls into ucrypto has corrupted the internal state and a final update call destroys it. > > Thanks, > Max > > From vladimir.kozlov at oracle.com Wed Jul 31 21:38:26 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 31 Jul 2019 14:38:26 -0700 Subject: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. In-Reply-To: <8D6F463991A1574A8A803B8DA605414F4118E5B4@ORSMSX111.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791296149EE6@fmsmsx123.amr.corp.intel.com> <6563F381B547594081EF9DE181D079129615C797@fmsmsx123.amr.corp.intel.com> <7944585b-924c-ee2f-7880-ea8566c2b608@oracle.com> <8D6F463991A1574A8A803B8DA605414F411880D8@ORSMSX111.amr.corp.intel.com> <8D6F463991A1574A8A803B8DA605414F4118A53C@ORSMSX111.amr.corp.intel.com> <11bc5dad-0787-193b-fe69-9bf568f377f0@oracle.com> <8D6F463991A1574A8A803B8DA605414F4118E5B4@ORSMSX111.amr.corp.intel.com> Message-ID: <680c3821-de1e-5f17-0e8b-765837eca888@oracle.com> Good. Lets wait review from security team. Thank you Vladimir On 7/31/19 2:20 PM, Rukmannagari, Shravya wrote: > Hi Vladimir, > Thanks a lot for the review. I have responded to the JBS bug with the use cases for ECB. Please find the updated webrev with no changes to the config file. > http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.02/ > > Thanks, > Shravya. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Sunday, July 28, 2019 3:31 PM > To: Rukmannagari, Shravya ; Kamath, Smita ; 'Anthony Scarpino' > Cc: Viswanathan, Sandhya ; Deshpande, Vivek R ; 'hotspot compiler' ; Shemy, Regev ; OpenJDK Security > Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. > > CCing to security-dev since you touched their class. > > Please answer Sean's question in the bug report. > > I don't think .jcheck/conf change should be part of this. > > Thanks, > Vladimir > > On 7/23/19 1:44 PM, Rukmannagari, Shravya wrote: >> Hi Vladimir, >> I have updated the patch as per your suggestions. The JMH test >> test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java has been >> modified to add support for different key lengths. Please take a look >> and let me know if you have any questions or comments. >> http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.01/ >> >> Thanks, >> Shravya. >> >> -----Original Message----- >> From: Rukmannagari, Shravya >> Sent: Monday, July 22, 2019 7:52 AM >> To: Vladimir Kozlov ; Kamath, Smita >> ; 'Anthony Scarpino' >> >> Cc: Viswanathan, Sandhya ; Deshpande, >> Vivek R ; 'hotspot compiler' >> ; Shemy, Regev >> >> Subject: RE: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. >> >> Hi Vladimir, >> For checking the correctness, we have run the hotspot/jtreg/compiler/codegen/aes/TestAESMain.java and the entire jtreg test suite. For the JMH benchmark tests, test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java tests ECB for a key length of 128. I will extend the test for other key lengths and send out an updated patch. >> >> Thanks, >> Shravya. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, July 18, 2019 4:02 PM >> To: Kamath, Smita ; 'Anthony Scarpino' >> >> Cc: Viswanathan, Sandhya ; >> Rukmannagari, Shravya ; Deshpande, >> Vivek R ; 'hotspot compiler' >> ; Shemy, Regev >> >> Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. >> >> Hi Smita >> >> I looked on changes and they seem fine in general (mostrly copy/past of cipherBlockChaining code). >> >> Few comments: >> >> Don't use _AVX3 in macroasm method names because you have only avx512 implementation. >> >> Indentions are bad in inline_electronicCodeBook_AESCrypt(). >> >> Add test to check results of optimization. >> >> Would be nice to have JMH test to see performance benefits. >> >> You also need to add checks to Graal's test [1] to prevent failure until this intrinsic is implemented in Graal. >> >> Thanks, >> Vladimir >> >> [1] >> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspo >> t.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java >> >> On 6/26/19 4:27 PM, Kamath, Smita wrote: >>> Hi All, >>> >>> Could you please review AES-ECB implemented using AVX512+VAES instructions. >>> >>> Thanks and Regards, >>> >>> Smita Kamath >>> >>> *From:* Kamath, Smita >>> *Sent:* Tuesday, June 11, 2019 4:23 PM >>> *To:* 'Vladimir Kozlov' ; Anthony >>> Scarpino >>> *Cc:* Viswanathan, Sandhya ; Shravya >>> Rukmannagari >>> (shravya.rukmannagari at intel.com) ; >>> hotspot compiler ; Shemy, >>> Regev >>> *Subject:* RFR(S) JDK-8225625: AES Electronic Codebook (ECB) >>> encryption and decryption optimizations using AVX512 + VAES instructions. >>> >>> Hi Vladimir, >>> >>> As per Intel Architecture Instruction Set Reference [1] Vector AES >>> Encrypt and Decrypt Operations will be supported in future Intel ISA. >>> We would like to contribute optimizations for AES-ECB algorithm to >>> support encryption and decryption operations using AVX512+VAES instructions. These optimizations are for x86_64 architecture that have AVX512-VAES enabled. >>> >>> Shravya(cc'ed) and I are co-contributors. Shay >>> Gueron(shay.gueron at intel.com >>> ) and Regev Shemy >>> (regev.shemy at intel.com >>> ) are the authors of the algorithm. >>> >>> I have tested the algorithm with Intel SDE [2] to confirm encoding >>> and semantics are correctly implemented. >>> >>> Please take a look and let me know if you have any questions or comments. >>> >>> http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.00/ >>> >>> Bug Id: https://bugs.openjdk.java.net/browse/JDK-8225625 >>> >>> [1] >>> https://software.intel.com/sites/default/files/managed/ad/01/253666-s >>> d >>> m-vol-2a.pdf ?(Page 152 - 159) >>> >>> [2] >>> https://software.intel.com/en-us/articles/intel-software-development- >>> e >>> mulator >>> >>> Regards, >>> >>> Smita Kamath >>> From shravya.rukmannagari at intel.com Wed Jul 31 21:20:47 2019 From: shravya.rukmannagari at intel.com (Rukmannagari, Shravya) Date: Wed, 31 Jul 2019 21:20:47 -0000 Subject: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. In-Reply-To: <11bc5dad-0787-193b-fe69-9bf568f377f0@oracle.com> References: <6563F381B547594081EF9DE181D0791296149EE6@fmsmsx123.amr.corp.intel.com> <6563F381B547594081EF9DE181D079129615C797@fmsmsx123.amr.corp.intel.com> <7944585b-924c-ee2f-7880-ea8566c2b608@oracle.com> <8D6F463991A1574A8A803B8DA605414F411880D8@ORSMSX111.amr.corp.intel.com> <8D6F463991A1574A8A803B8DA605414F4118A53C@ORSMSX111.amr.corp.intel.com> <11bc5dad-0787-193b-fe69-9bf568f377f0@oracle.com> Message-ID: <8D6F463991A1574A8A803B8DA605414F4118E5B4@ORSMSX111.amr.corp.intel.com> Hi Vladimir, Thanks a lot for the review. I have responded to the JBS bug with the use cases for ECB. Please find the updated webrev with no changes to the config file. http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.02/ Thanks, Shravya. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Sunday, July 28, 2019 3:31 PM To: Rukmannagari, Shravya ; Kamath, Smita ; 'Anthony Scarpino' Cc: Viswanathan, Sandhya ; Deshpande, Vivek R ; 'hotspot compiler' ; Shemy, Regev ; OpenJDK Security Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. CCing to security-dev since you touched their class. Please answer Sean's question in the bug report. I don't think .jcheck/conf change should be part of this. Thanks, Vladimir On 7/23/19 1:44 PM, Rukmannagari, Shravya wrote: > Hi Vladimir, > I have updated the patch as per your suggestions. The JMH test > test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java has been > modified to add support for different key lengths. Please take a look > and let me know if you have any questions or comments. > http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.01/ > > Thanks, > Shravya. > > -----Original Message----- > From: Rukmannagari, Shravya > Sent: Monday, July 22, 2019 7:52 AM > To: Vladimir Kozlov ; Kamath, Smita > ; 'Anthony Scarpino' > > Cc: Viswanathan, Sandhya ; Deshpande, > Vivek R ; 'hotspot compiler' > ; Shemy, Regev > > Subject: RE: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. > > Hi Vladimir, > For checking the correctness, we have run the hotspot/jtreg/compiler/codegen/aes/TestAESMain.java and the entire jtreg test suite. For the JMH benchmark tests, test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java tests ECB for a key length of 128. I will extend the test for other key lengths and send out an updated patch. > > Thanks, > Shravya. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, July 18, 2019 4:02 PM > To: Kamath, Smita ; 'Anthony Scarpino' > > Cc: Viswanathan, Sandhya ; > Rukmannagari, Shravya ; Deshpande, > Vivek R ; 'hotspot compiler' > ; Shemy, Regev > > Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. > > Hi Smita > > I looked on changes and they seem fine in general (mostrly copy/past of cipherBlockChaining code). > > Few comments: > > Don't use _AVX3 in macroasm method names because you have only avx512 implementation. > > Indentions are bad in inline_electronicCodeBook_AESCrypt(). > > Add test to check results of optimization. > > Would be nice to have JMH test to see performance benefits. > > You also need to add checks to Graal's test [1] to prevent failure until this intrinsic is implemented in Graal. > > Thanks, > Vladimir > > [1] > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspo > t.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java > > On 6/26/19 4:27 PM, Kamath, Smita wrote: >> Hi All, >> >> Could you please review AES-ECB implemented using AVX512+VAES instructions. >> >> Thanks and Regards, >> >> Smita Kamath >> >> *From:* Kamath, Smita >> *Sent:* Tuesday, June 11, 2019 4:23 PM >> *To:* 'Vladimir Kozlov' ; Anthony >> Scarpino >> *Cc:* Viswanathan, Sandhya ; Shravya >> Rukmannagari >> (shravya.rukmannagari at intel.com) ; >> hotspot compiler ; Shemy, >> Regev >> *Subject:* RFR(S) JDK-8225625: AES Electronic Codebook (ECB) >> encryption and decryption optimizations using AVX512 + VAES instructions. >> >> Hi Vladimir, >> >> As per Intel Architecture Instruction Set Reference [1] Vector AES >> Encrypt and Decrypt Operations will be supported in future Intel ISA. >> We would like to contribute optimizations for AES-ECB algorithm to >> support encryption and decryption operations using AVX512+VAES instructions. These optimizations are for x86_64 architecture that have AVX512-VAES enabled. >> >> Shravya(cc'ed) and I are co-contributors. Shay >> Gueron(shay.gueron at intel.com >> ) and Regev Shemy >> (regev.shemy at intel.com >> ) are the authors of the algorithm. >> >> I have tested the algorithm with Intel SDE [2] to confirm encoding >> and semantics are correctly implemented. >> >> Please take a look and let me know if you have any questions or comments. >> >> http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.00/ >> >> Bug Id: https://bugs.openjdk.java.net/browse/JDK-8225625 >> >> [1] >> https://software.intel.com/sites/default/files/managed/ad/01/253666-s >> d >> m-vol-2a.pdf ?(Page 152 - 159) >> >> [2] >> https://software.intel.com/en-us/articles/intel-software-development- >> e >> mulator >> >> Regards, >> >> Smita Kamath >>