From weijun.wang at oracle.com Wed Mar 1 01:02:27 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 1 Mar 2017 09:02:27 +0800 Subject: RFR 8175846: Provide javadoc descriptions for jdk.policytool and jdk.crypto.* modules Message-ID: <5d6f41bb-e9b2-17b7-8ca1-c5f1eb091cff@oracle.com> Please review the patch below. I don't know if all those jdk.crypto.* modules will be listed in the doc, but it's nice to include a comment. Thanks Max diff --git a/src/jdk.policytool/share/classes/module-info.java b/src/jdk.policytool/share/classes/module-info.java --- a/src/jdk.policytool/share/classes/module-info.java +++ b/src/jdk.policytool/share/classes/module-info.java @@ -23,6 +23,14 @@ * questions. */ +/** + * GUI tool for managing policy files. + * + * @since 9 + * @deprecated The policytool tool has been deprecated and + * is planned to be removed in a future release. + */ + at Deprecated module jdk.policytool { requires java.desktop; requires java.logging; diff --git a/src/jdk.crypto.cryptoki/share/classes/module-info.java b/src/jdk.crypto.cryptoki/share/classes/module-info.java --- a/src/jdk.crypto.cryptoki/share/classes/module-info.java +++ b/src/jdk.crypto.cryptoki/share/classes/module-info.java @@ -23,6 +23,11 @@ * questions. */ +/** + * The SunPKCS11 security provider. + * + * @since 9 + */ module jdk.crypto.cryptoki { // Depends on SunEC provider for EC related functionality requires jdk.crypto.ec; diff --git a/src/jdk.crypto.ec/share/classes/module-info.java b/src/jdk.crypto.ec/share/classes/module-info.java --- a/src/jdk.crypto.ec/share/classes/module-info.java +++ b/src/jdk.crypto.ec/share/classes/module-info.java @@ -23,6 +23,11 @@ * questions. */ +/** + * The SunEC security provider. + * + * @since 9 + */ module jdk.crypto.ec { provides java.security.Provider with sun.security.ec.SunEC; } diff --git a/src/jdk.crypto.mscapi/windows/classes/module-info.java b/src/jdk.crypto.mscapi/windows/classes/module-info.java --- a/src/jdk.crypto.mscapi/windows/classes/module-info.java +++ b/src/jdk.crypto.mscapi/windows/classes/module-info.java @@ -23,6 +23,11 @@ * questions. */ +/** + * The SunMSCAPI security provider. + * + * @since 9 + */ module jdk.crypto.mscapi { provides java.security.Provider with sun.security.mscapi.SunMSCAPI; } diff --git a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java --- a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java +++ b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java @@ -23,6 +23,11 @@ * questions. */ +/** + * The OracleUCrypto security provider. + * + * @since 9 + */ module jdk.crypto.ucrypto { provides java.security.Provider with com.oracle.security.ucrypto.UcryptoProvider; } Thanks Max From ecki at zusammenkunft.net Wed Mar 1 23:43:17 2017 From: ecki at zusammenkunft.net (Bernd) Date: Thu, 2 Mar 2017 00:43:17 +0100 Subject: JDK-8133634 ava gets SunMSCAPI entry as TrustedCertificateEntry instead of PrivateKeyEntry Message-ID: Hello, regarding the Bug https://bugs.openjdk.java.net/browse/JDK-8133634 (assigned to Vincent) I can help. When importing the P12 container on a recent Windows it gets by default imported under a CSP provider from the CNG API and not in CAPI legacy store: Import CLI or certmgr.msc (exportable or not): certutil.exe -user -f -v -importpfx "ACA PF Administrativo Activo.p12" > Consequently it does not show up as having a key in the Windows KeyStore implementation: > keytool -list -storetype Windows-MY > ... > EA=demo.empleado at cgae.redabogacia.org, .... trustedCertEntry, > Zertifikat-Fingerprint (SHA1): > 89:69:78:75:52:6A:DB:01:9B:95:42:63:19:E3:00:9E:60:5E:1D:EF > You can verify the cryptographic provider used with the Windows tool: certutil.exe -store -user my > It will list the certificate and mention "Microsoft Base Crytographic Provider 1.0" If the P12 is deleted and re-imported with the following command the key will show up in the legacy keystore: $ certutil -csp ?Microsoft Strong Cryptographic Provider? -user -f -v > -importpfx "ACA PF Administrativo Activo.p12" > ... Das Zertifikat "EA=demo.empleado at cgae.redabogacia.org, ..." wurde zum > Speicher hinzugef?gt. > Again certutil shows us the (better) provider: CertUtil.exe -store -user my > my "Eigene Zertifikate" > ================ Zertifikat 0 ================ > Seriennummer: 659d357f6f05af385114e692393b5bb0 > Aussteller: CN=ACA... Antragsteller: E=demo.empleado at cgae.redabogacia.org, .. > Kein Stammzertifikat > Zertifikathash(sha1): 89 69 78 75 52 6a db 01 9b 95 42 63 19 e3 00 9e 60 > 5e 1d ef > Schl?sselcontainer = {0F1CB13E-CA6C-46D0-9C74-25F7B3C780D9} > Eindeutiger Containername: > 512a12f4d213aef6c4cadf5a5efc19cf_74be6a0b-923e-4199-a6c6-b2089f1643c4 > Anbieter = Microsoft Base Cryptographic Provider v1.0 > And consequently keytool will list it as a key: > keytool -list -storetype Windows-MY > ... > EA=demo.empleado at cgae.redabogacia.org, CN=NOMBRE..., PrivateKeyEntry, > ... > It is very unfortunate that SunMSCAPI provider uses the old CAPI and not the CNG versions, because the new versions benefit for example from a Commons Criteria certification where the key material in stored in the priveledged KeyIso service, unreachable by the application. (And I guess it would solve a few of the problems with alternative sign formats, with unavailable smartcard stubs etc. So any idea if we see CNG support any time soon, it is available since Vista. Gruss Bernd PS: can somebody extend the JIRA with my research (attribution welcome). -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Mar 3 01:17:21 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 3 Mar 2017 09:17:21 +0800 Subject: RFR 8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms In-Reply-To: <1665c445-931b-5f91-a8d6-c3c2202ed185@oracle.com> References: <46c26a65-7886-3a64-60f1-808ae07cd028@oracle.com> <32c222a8-18a1-14d6-7f32-13afd0aefae8@oracle.com> <5ac4842f-a051-3280-8501-4b5f41a781c5@oracle.com> <1665c445-931b-5f91-a8d6-c3c2202ed185@oracle.com> Message-ID: <40348c12-6650-3014-2cdb-6e0656a19cff@oracle.com> Updated again at http://cr.openjdk.java.net/~weijun/8171319/webrev.03/ Changes: 1. No more prompt when algorithm/key is weak in keytool -importcert. This newly introduced prompt might hang a user script. Since we are thinking of backporting this change to previous releases, this is a little too dangerous. 2. WeakAlg.java test updated. 3. Other changes (that add a -noprompt) reverted. Thanks Max On 02/23/2017 11:42 AM, Weijun Wang wrote: > Updated again at > > http://cr.openjdk.java.net/~weijun/8171319/webrev.02/ > > Changes: > > 1. Combined printWeakWarningsWithoutNewLine() and printWeakWarnings() to > one method. > > 2. New X509CRLImpl.toStringWithAlgName(String name). > > Nothing more. > > Thanks > Max > > On 02/15/2017 11:04 PM, Se?n Coffey wrote: >> Hi Weijun, >> >> That's looks good to me and will be a big help for keytool usability. >> >> some thoughts : >> >> Main.java : in your printCRL method, would you consider editing the >> X509CRLImpl class to print with a customized string ? It'll make the >> code more resilient to future changes in this area >> >> i.e. something like this in X509CRLImpl : >> >> public String toString() { printCRL(null); } >> public String printCRL(String custom) { >> // transfer the toString() code to here >> // and allow for 'custom' string to be injected if non-null >> .. >> } >> >> in Main.java, I'd suggest an instanceof check for X509CRLImpl before >> calling printCRL(..). Could X509CRL.getSigAlgName() then be used for >> passing into the withWeak method call ? >> >> === >> >> Also in Main.java, maybe you could reduce >> printWeakWarningsWithoutNewLine and printWeakWarnings() to one method - >> e.g. printWeakWarnings(boolean newline) >> >> === >> >> Regards, >> Sean. >> >> On 15/02/17 01:16, Weijun Wang wrote: >>> Ping again. >>> >>> Also, must we resolve this one before ZBB? >>> >>> --Max >>> >>> On 02/09/2017 10:26 AM, Weijun Wang wrote: >>>> An update webrev is at >>>> >>>> http://cr.openjdk.java.net/~weijun/8171319/webrev.01/ >>>> >>>> The major change is that every risk warning has a owner now, i.e. >>>> instead of just saying "MD5withRSA is weak", it prints out whose >>>> algorithm is weak. For example: >>>> >>>> The generated CRL uses the MD5withRSA signature algorithm which is >>>> considered a security risk. >>>> >>>> Please take a look at the output of the newly added regression test at >>>> >>>> http://cr.openjdk.java.net/~weijun/8171319/webrev.01/examples.txt >>>> >>>> Thanks >>>> Max >>>> >>>> On 01/23/2017 06:02 PM, Weijun Wang wrote: >>>>> Hi All >>>>> >>>>> Please take a review at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8171319/webrev.00/ >>>>> >>>>> Warnings are printed to System.err when weak algorithms/keysizes are >>>>> detected during the execution, this includes input, output, and any >>>>> certs used. >>>>> >>>>> The detection applies to many keytool functions: >>>>> >>>>> - generation of certificate, certificate request, CRL >>>>> - reading (printing, listing, exporting) of above >>>>> - importing of certificate or certificates reply >>>>> >>>>> The behavior of most functions remains unchanged. The only >>>>> exception is >>>>> "keytool -importcert", where the user must reply to a prompt if weak >>>>> algorithms/keysizes are detected, unless -noprompt is specified on the >>>>> command line. >>>>> >>>>> Warnings are either printed at the end, or before a prompt. >>>>> >>>>> If there are multiple weak points, multiple warnings will be printed. >>>>> >>>>> The detection is based on the security property >>>>> jdk.certpath.disabledAlgorithms. >>>>> >>>>> For example: >>>>> >>>>> $ keytool -genkeypair -alias a -dname CN=a -keyalg RSA -sigalg >>>>> MD5withRSA >>>>> >>>>> Warning: >>>>> The MD5withRSA signature algorithm is considered a security risk. >>>>> >>>>> $ keytool -keystore ks -storepass changeit -keypass changeit -list >>>>> >>>>> Keystore type: JKS >>>>> Keystore provider: SUN >>>>> >>>>> Your keystore contains 3 entries >>>>> >>>>> b, Jan 23, 2017, PrivateKeyEntry, >>>>> Certificate fingerprint (SHA-256): >>>>> D8:46:B7:0B:8B:97:C2:DE:A2:17:62:01:27:82:2B:CE:B1:9B:12:0B:24:D5:47:BF:BD:54:EE:8A:71:29:2B:CE >>>>> >>>>> >>>>> >>>>> >>>>> a, Jan 23, 2017, PrivateKeyEntry, >>>>> Certificate fingerprint (SHA-256): >>>>> 66:70:DF:11:14:A1:96:58:92:F5:6A:10:09:B1:2F:CC:1C:CC:2D:55:47:1D:EE:74:75:AA:26:63:E4:9D:EA:83 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Warning: >>>>> 's 512-bit RSA key is considered a security risk. >>>>> 's MD5withRSA signature algorithm is considered a security risk. >>>>> >>>>> $ keytool -importcert -alias a -file b+a.certs >>>>> >>>>> Warning: >>>>> Reply #2 of 2's 512-bit RSA key is considered a security risk. >>>>> >>>>> Install reply anyway? [no]:no >>>>> Certificate reply was not installed in keystore >>>>> >>>>> Thanks >>>>> Max >> From amy.lu at oracle.com Mon Mar 6 02:48:04 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 6 Mar 2017 10:48:04 +0800 Subject: JDK 9 RFR of JDK-8176182: 4 security tests are not run Message-ID: <6068a2b1-4398-6cfa-f4f5-ea4e8e73451d@oracle.com> sun/security/ec/SignedObjectChain.java sun/security/mscapi/SignedObjectChain.java sun/security/rsa/SignedObjectChain.java sun/security/ssl/rsa/SignedObjectChain.java These tests are not compile-only tests, but due to the missed @run tag, tests are not run. Please review the patch to add @run tag to them. Note that with the added @run tag, test result show that sun/security/mscapi/SignedObjectChain.java fails. Problem list it for now. bug: https://bugs.openjdk.java.net/browse/JDK-8176182 webrev: http://cr.openjdk.java.net/~amlu/8176182/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2017-03-06 10:43:29.000000000 +0800 +++ new/test/ProblemList.txt 2017-03-06 10:43:29.000000000 +0800 @@ -215,6 +215,8 @@ javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 +sun/security/mscapi/SignedObjectChain.java 8176183 windows-all + ############################################################################ # jdk_sound --- old/test/sun/security/ec/SignedObjectChain.java 2017-03-06 10:43:30.000000000 +0800 +++ new/test/sun/security/ec/SignedObjectChain.java 2017-03-06 10:43:30.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2017, 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 @@ -24,8 +24,9 @@ /* * @test * @bug 8050374 - * @compile ../../../java/security/SignedObject/Chain.java * @summary Verify a chain of signed objects + * @compile ../../../java/security/SignedObject/Chain.java + * @run main SignedObjectChain */ public class SignedObjectChain { --- old/test/sun/security/mscapi/SignedObjectChain.java 2017-03-06 10:43:31.000000000 +0800 +++ new/test/sun/security/mscapi/SignedObjectChain.java 2017-03-06 10:43:30.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2017, 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 @@ -24,9 +24,10 @@ /* * @test * @bug 8050374 + * @summary Verify a chain of signed objects * @compile ../../../java/security/SignedObject/Chain.java * @requires os.family == "windows" - * @summary Verify a chain of signed objects + * @run main SignedObjectChain */ public class SignedObjectChain { --- old/test/sun/security/rsa/SignedObjectChain.java 2017-03-06 10:43:32.000000000 +0800 +++ new/test/sun/security/rsa/SignedObjectChain.java 2017-03-06 10:43:31.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2017, 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 @@ -24,8 +24,9 @@ /* * @test * @bug 8050374 - * @compile ../../../java/security/SignedObject/Chain.java * @summary Verify a chain of signed objects + * @compile ../../../java/security/SignedObject/Chain.java + * @run main SignedObjectChain */ public class SignedObjectChain { --- old/test/sun/security/ssl/rsa/SignedObjectChain.java 2017-03-06 10:43:32.000000000 +0800 +++ new/test/sun/security/ssl/rsa/SignedObjectChain.java 2017-03-06 10:43:32.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2017, 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 @@ -24,8 +24,9 @@ /* * @test * @bug 8050374 - * @compile ../../../../java/security/SignedObject/Chain.java * @summary Verify a chain of signed objects + * @compile ../../../../java/security/SignedObject/Chain.java + * @run main SignedObjectChain */ public class SignedObjectChain { -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Mar 6 03:52:35 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 6 Mar 2017 11:52:35 +0800 Subject: JDK 9 RFR of JDK-8176182: 4 security tests are not run In-Reply-To: <6068a2b1-4398-6cfa-f4f5-ea4e8e73451d@oracle.com> References: <6068a2b1-4398-6cfa-f4f5-ea4e8e73451d@oracle.com> Message-ID: Hi Amy Change looks good. BTW, how did you notice this? Thanks Max On 03/06/2017 10:48 AM, Amy Lu wrote: > sun/security/ec/SignedObjectChain.java > sun/security/mscapi/SignedObjectChain.java > sun/security/rsa/SignedObjectChain.java > sun/security/ssl/rsa/SignedObjectChain.java > > These tests are not compile-only tests, but due to the missed @run tag, > tests are not run. > > Please review the patch to add @run tag to them. > > Note that with the added @run tag, test result show that > sun/security/mscapi/SignedObjectChain.java fails. Problem list it for now. > > bug: https://bugs.openjdk.java.net/browse/JDK-8176182 > webrev: http://cr.openjdk.java.net/~amlu/8176182/webrev.00/ > > Thanks, > Amy > > --- old/test/ProblemList.txt 2017-03-06 10:43:29.000000000 +0800 > +++ new/test/ProblemList.txt 2017-03-06 10:43:29.000000000 +0800 > @@ -215,6 +215,8 @@ > javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 > javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 > > +sun/security/mscapi/SignedObjectChain.java 8176183 windows-all > + > ############################################################################ > > # jdk_sound > --- old/test/sun/security/ec/SignedObjectChain.java 2017-03-06 10:43:30.000000000 +0800 > +++ new/test/sun/security/ec/SignedObjectChain.java 2017-03-06 10:43:30.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2017, 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 > @@ -24,8 +24,9 @@ > /* > * @test > * @bug 8050374 > - * @compile ../../../java/security/SignedObject/Chain.java > * @summary Verify a chain of signed objects > + * @compile ../../../java/security/SignedObject/Chain.java > + * @run main SignedObjectChain > */ > public class SignedObjectChain { > > --- old/test/sun/security/mscapi/SignedObjectChain.java 2017-03-06 10:43:31.000000000 +0800 > +++ new/test/sun/security/mscapi/SignedObjectChain.java 2017-03-06 10:43:30.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2017, 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 > @@ -24,9 +24,10 @@ > /* > * @test > * @bug 8050374 > + * @summary Verify a chain of signed objects > * @compile ../../../java/security/SignedObject/Chain.java > * @requires os.family == "windows" > - * @summary Verify a chain of signed objects > + * @run main SignedObjectChain > */ > public class SignedObjectChain { > > --- old/test/sun/security/rsa/SignedObjectChain.java 2017-03-06 10:43:32.000000000 +0800 > +++ new/test/sun/security/rsa/SignedObjectChain.java 2017-03-06 10:43:31.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2017, 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 > @@ -24,8 +24,9 @@ > /* > * @test > * @bug 8050374 > - * @compile ../../../java/security/SignedObject/Chain.java > * @summary Verify a chain of signed objects > + * @compile ../../../java/security/SignedObject/Chain.java > + * @run main SignedObjectChain > */ > public class SignedObjectChain { > > --- old/test/sun/security/ssl/rsa/SignedObjectChain.java 2017-03-06 10:43:32.000000000 +0800 > +++ new/test/sun/security/ssl/rsa/SignedObjectChain.java 2017-03-06 10:43:32.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2017, 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 > @@ -24,8 +24,9 @@ > /* > * @test > * @bug 8050374 > - * @compile ../../../../java/security/SignedObject/Chain.java > * @summary Verify a chain of signed objects > + * @compile ../../../../java/security/SignedObject/Chain.java > + * @run main SignedObjectChain > */ > public class SignedObjectChain { > > > From amy.lu at oracle.com Mon Mar 6 05:34:48 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 6 Mar 2017 13:34:48 +0800 Subject: JDK 9 RFR of JDK-8176182: 4 security tests are not run In-Reply-To: References: <6068a2b1-4398-6cfa-f4f5-ea4e8e73451d@oracle.com> Message-ID: <68177779-38cb-e36b-df36-281a0d2e1d27@oracle.com> Thank you Max for your review. I noticed this issue: (Thanks to Igor) JDK-8176162: com/sun/jndi/dns/Parser.java is not executed https://bugs.openjdk.java.net/browse/JDK-8176162 So checked other jdk tests, and found more similar issues. jtreg enhancement created with the hope to get help from test harness to avoid such issue in the future: CODETOOLS-7901909: Enforce @compile/ for compile-only test, make test results Error if test has @compile or @build but no @run tag https://bugs.openjdk.java.net/browse/CODETOOLS-7901909 Thanks, Amy On 3/6/17 11:52 AM, Weijun Wang wrote: > Hi Amy > > Change looks good. > > BTW, how did you notice this? > > Thanks > Max > > On 03/06/2017 10:48 AM, Amy Lu wrote: >> sun/security/ec/SignedObjectChain.java >> sun/security/mscapi/SignedObjectChain.java >> sun/security/rsa/SignedObjectChain.java >> sun/security/ssl/rsa/SignedObjectChain.java >> >> These tests are not compile-only tests, but due to the missed @run tag, >> tests are not run. >> >> Please review the patch to add @run tag to them. >> >> Note that with the added @run tag, test result show that >> sun/security/mscapi/SignedObjectChain.java fails. Problem list it for >> now. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8176182 >> webrev: http://cr.openjdk.java.net/~amlu/8176182/webrev.00/ >> >> Thanks, >> Amy >> >> --- old/test/ProblemList.txt 2017-03-06 10:43:29.000000000 +0800 >> +++ new/test/ProblemList.txt 2017-03-06 10:43:29.000000000 +0800 >> @@ -215,6 +215,8 @@ >> javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 >> javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64 >> >> +sun/security/mscapi/SignedObjectChain.java 8176183 windows-all >> + >> ############################################################################ >> >> >> # jdk_sound >> --- old/test/sun/security/ec/SignedObjectChain.java 2017-03-06 >> 10:43:30.000000000 +0800 >> +++ new/test/sun/security/ec/SignedObjectChain.java 2017-03-06 >> 10:43:30.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2017, 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 >> @@ -24,8 +24,9 @@ >> /* >> * @test >> * @bug 8050374 >> - * @compile ../../../java/security/SignedObject/Chain.java >> * @summary Verify a chain of signed objects >> + * @compile ../../../java/security/SignedObject/Chain.java >> + * @run main SignedObjectChain >> */ >> public class SignedObjectChain { >> >> --- old/test/sun/security/mscapi/SignedObjectChain.java 2017-03-06 >> 10:43:31.000000000 +0800 >> +++ new/test/sun/security/mscapi/SignedObjectChain.java 2017-03-06 >> 10:43:30.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2017, 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 >> @@ -24,9 +24,10 @@ >> /* >> * @test >> * @bug 8050374 >> + * @summary Verify a chain of signed objects >> * @compile ../../../java/security/SignedObject/Chain.java >> * @requires os.family == "windows" >> - * @summary Verify a chain of signed objects >> + * @run main SignedObjectChain >> */ >> public class SignedObjectChain { >> >> --- old/test/sun/security/rsa/SignedObjectChain.java 2017-03-06 >> 10:43:32.000000000 +0800 >> +++ new/test/sun/security/rsa/SignedObjectChain.java 2017-03-06 >> 10:43:31.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2017, 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 >> @@ -24,8 +24,9 @@ >> /* >> * @test >> * @bug 8050374 >> - * @compile ../../../java/security/SignedObject/Chain.java >> * @summary Verify a chain of signed objects >> + * @compile ../../../java/security/SignedObject/Chain.java >> + * @run main SignedObjectChain >> */ >> public class SignedObjectChain { >> >> --- old/test/sun/security/ssl/rsa/SignedObjectChain.java 2017-03-06 >> 10:43:32.000000000 +0800 >> +++ new/test/sun/security/ssl/rsa/SignedObjectChain.java 2017-03-06 >> 10:43:32.000000000 +0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 2015, 2017, 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 >> @@ -24,8 +24,9 @@ >> /* >> * @test >> * @bug 8050374 >> - * @compile ../../../../java/security/SignedObject/Chain.java >> * @summary Verify a chain of signed objects >> + * @compile ../../../../java/security/SignedObject/Chain.java >> + * @run main SignedObjectChain >> */ >> public class SignedObjectChain { >> >> >> From sergei.kovalev at oracle.com Mon Mar 6 16:24:29 2017 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 6 Mar 2017 19:24:29 +0300 Subject: RFR(s): 8176213: 78 sun/security/krb5/auto tests failing due to undeclared dependecies Message-ID: <8e706eb2-31f1-ad51-3956-84865696510c@oracle.com> Hello Team, Please review small fix for tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8176213 Webrev: http://cr.openjdk.java.net/~skovalev/8176213/webrev.00 Issue: The tests failing due to undeclared dependencies on jdk.security.auth and jdk.security.jgss. Solution: add missed module declaration into TEST.properties file. Two of tests also required individual dependencies on jdk.httpserver and jdk.crypto.cryptoki therefore we creating the module declaration section in each individual test. -- With best regards, Sergei From weijun.wang at oracle.com Mon Mar 6 23:15:40 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 7 Mar 2017 07:15:40 +0800 Subject: RFR(s): 8176213: 78 sun/security/krb5/auto tests failing due to undeclared dependecies In-Reply-To: <8e706eb2-31f1-ad51-3956-84865696510c@oracle.com> References: <8e706eb2-31f1-ad51-3956-84865696510c@oracle.com> Message-ID: <189dabc1-c7f8-4e95-51a4-cbff68b8be92@oracle.com> Hi Sergei Two questions: 1. Can we remove the @modules section in Renew.java so that it uses the one in TEST.properties? 2. I cannot see why jdk.crypto.cryptoki is necessary for PrincipalSystemPropTest.java. What is the error? BTW, can you tell me how to make the test fail? Maybe with some special jtreg options? Thanks Max On 03/07/2017 12:24 AM, Sergei Kovalev wrote: > Hello Team, > > Please review small fix for tests. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8176213 > Webrev: http://cr.openjdk.java.net/~skovalev/8176213/webrev.00 > > Issue: The tests failing due to undeclared dependencies on > jdk.security.auth and jdk.security.jgss. > Solution: add missed module declaration into TEST.properties file. Two > of tests also required individual dependencies on jdk.httpserver and > jdk.crypto.cryptoki therefore we creating the module declaration section > in each individual test. > From sergei.kovalev at oracle.com Tue Mar 7 09:50:20 2017 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 7 Mar 2017 12:50:20 +0300 Subject: RFR(s): 8176213: 78 sun/security/krb5/auto tests failing due to undeclared dependecies In-Reply-To: <189dabc1-c7f8-4e95-51a4-cbff68b8be92@oracle.com> References: <8e706eb2-31f1-ad51-3956-84865696510c@oracle.com> <189dabc1-c7f8-4e95-51a4-cbff68b8be92@oracle.com> Message-ID: <8e487de0-0280-d90c-2ebd-f7537cc970b2@oracle.com> Hi Max, Thank you for review. 07.03.17 02:15, Weijun Wang wrote: > Hi Sergei > > Two questions: > > 1. Can we remove the @modules section in Renew.java so that it uses > the one in TEST.properties? We can however TEST.properties contains jdk.security.jgss module dependency but Renew.java doesn't. If we remove module declaration from the last one we reduce the number of configuration where the test able to run. Should I do this? > > 2. I cannot see why jdk.crypto.cryptoki is necessary for > PrincipalSystemPropTest.java. What is the error? Thank you for the question. It should be jdk.security.auth instead. > > BTW, can you tell me how to make the test fail? Maybe with some > special jtreg options? e.g.: jtreg -jdk:/usr/home/jdk9_latest -verbose:all -javaoptions:"--limit-modules java.base,java.security.jgss,jdk.security.auth" /usr/home/repos/jdk9-dev/jdk/test/sun/security/krb5/auto/principalProperty/PrincipalSystemPropTest.java If you get outjdk.security.auth from the module list the test will start failing. > > Thanks > Max > > On 03/07/2017 12:24 AM, Sergei Kovalev wrote: >> Hello Team, >> >> Please review small fix for tests. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8176213 >> Webrev: http://cr.openjdk.java.net/~skovalev/8176213/webrev.00 >> >> Issue: The tests failing due to undeclared dependencies on >> jdk.security.auth and jdk.security.jgss. >> Solution: add missed module declaration into TEST.properties file. Two >> of tests also required individual dependencies on jdk.httpserver and >> jdk.crypto.cryptoki therefore we creating the module declaration section >> in each individual test. >> -- With best regards, Sergei From weijun.wang at oracle.com Tue Mar 7 10:30:38 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 7 Mar 2017 18:30:38 +0800 Subject: RFR(s): 8176213: 78 sun/security/krb5/auto tests failing due to undeclared dependecies In-Reply-To: <8e487de0-0280-d90c-2ebd-f7537cc970b2@oracle.com> References: <8e706eb2-31f1-ad51-3956-84865696510c@oracle.com> <189dabc1-c7f8-4e95-51a4-cbff68b8be92@oracle.com> <8e487de0-0280-d90c-2ebd-f7537cc970b2@oracle.com> Message-ID: <027f641b-3e5d-4cb5-f97a-4244899580b8@oracle.com> On 03/07/2017 05:50 PM, Sergei Kovalev wrote: > Hi Max, > > Thank you for review. > > > 07.03.17 02:15, Weijun Wang wrote: >> Hi Sergei >> >> Two questions: >> >> 1. Can we remove the @modules section in Renew.java so that it uses >> the one in TEST.properties? > We can however TEST.properties contains jdk.security.jgss module > dependency but Renew.java doesn't. If we remove module declaration from > the last one we reduce the number of configuration where the test able > to run. Should I do this? I don't feel uncomfortable using a slightly bigger set. Do you mean all other tests (without its own @module) are using the exact modules in TEST.properties? No more and no less? >> >> 2. I cannot see why jdk.crypto.cryptoki is necessary for >> PrincipalSystemPropTest.java. What is the error? > Thank you for the question. It should be jdk.security.auth instead. >> >> BTW, can you tell me how to make the test fail? Maybe with some >> special jtreg options? > e.g.: > > jtreg -jdk:/usr/home/jdk9_latest -verbose:all > -javaoptions:"--limit-modules > > /usr/home/repos/jdk9-dev/jdk/test/sun/security/krb5/auto/principalProperty/PrincipalSystemPropTest.java > > > If you get outjdk.security.auth from the module list the test will start > failing. I'll try. Thanks Max >> >> Thanks >> Max >> >> On 03/07/2017 12:24 AM, Sergei Kovalev wrote: >>> Hello Team, >>> >>> Please review small fix for tests. >>> >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8176213 >>> Webrev: http://cr.openjdk.java.net/~skovalev/8176213/webrev.00 >>> >>> Issue: The tests failing due to undeclared dependencies on >>> jdk.security.auth and jdk.security.jgss. >>> Solution: add missed module declaration into TEST.properties file. Two >>> of tests also required individual dependencies on jdk.httpserver and >>> jdk.crypto.cryptoki therefore we creating the module declaration section >>> in each individual test. >>> > From sergei.kovalev at oracle.com Tue Mar 7 10:40:04 2017 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 7 Mar 2017 13:40:04 +0300 Subject: RFR(s): 8176213: 78 sun/security/krb5/auto tests failing due to undeclared dependecies In-Reply-To: <027f641b-3e5d-4cb5-f97a-4244899580b8@oracle.com> References: <8e706eb2-31f1-ad51-3956-84865696510c@oracle.com> <189dabc1-c7f8-4e95-51a4-cbff68b8be92@oracle.com> <8e487de0-0280-d90c-2ebd-f7537cc970b2@oracle.com> <027f641b-3e5d-4cb5-f97a-4244899580b8@oracle.com> Message-ID: Good point. For same reason I've removed module declaration from PrincipalSystemPropTest.java. Now it uses TETS.properties config. Please take a look. http://cr.openjdk.java.net/~skovalev/8176213/webrev.01/ 07.03.17 13:30, Weijun Wang wrote: > > > On 03/07/2017 05:50 PM, Sergei Kovalev wrote: >> Hi Max, >> >> Thank you for review. >> >> >> 07.03.17 02:15, Weijun Wang wrote: >>> Hi Sergei >>> >>> Two questions: >>> >>> 1. Can we remove the @modules section in Renew.java so that it uses >>> the one in TEST.properties? >> We can however TEST.properties contains jdk.security.jgss module >> dependency but Renew.java doesn't. If we remove module declaration from >> the last one we reduce the number of configuration where the test able >> to run. Should I do this? > > I don't feel uncomfortable using a slightly bigger set. > > Do you mean all other tests (without its own @module) are using the > exact modules in TEST.properties? No more and no less? > >>> >>> 2. I cannot see why jdk.crypto.cryptoki is necessary for >>> PrincipalSystemPropTest.java. What is the error? >> Thank you for the question. It should be jdk.security.auth instead. >>> >>> BTW, can you tell me how to make the test fail? Maybe with some >>> special jtreg options? >> e.g.: >> >> jtreg -jdk:/usr/home/jdk9_latest -verbose:all >> -javaoptions:"--limit-modules >> >> /usr/home/repos/jdk9-dev/jdk/test/sun/security/krb5/auto/principalProperty/PrincipalSystemPropTest.java >> >> >> >> If you get outjdk.security.auth from the module list the test will start >> failing. > > I'll try. > > Thanks > Max > >>> >>> Thanks >>> Max >>> >>> On 03/07/2017 12:24 AM, Sergei Kovalev wrote: >>>> Hello Team, >>>> >>>> Please review small fix for tests. >>>> >>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8176213 >>>> Webrev: http://cr.openjdk.java.net/~skovalev/8176213/webrev.00 >>>> >>>> Issue: The tests failing due to undeclared dependencies on >>>> jdk.security.auth and jdk.security.jgss. >>>> Solution: add missed module declaration into TEST.properties file. Two >>>> of tests also required individual dependencies on jdk.httpserver and >>>> jdk.crypto.cryptoki therefore we creating the module declaration >>>> section >>>> in each individual test. >>>> >> -- With best regards, Sergei From weijun.wang at oracle.com Tue Mar 7 12:53:03 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 7 Mar 2017 20:53:03 +0800 Subject: RFR(s): 8176213: 78 sun/security/krb5/auto tests failing due to undeclared dependecies In-Reply-To: References: <8e706eb2-31f1-ad51-3956-84865696510c@oracle.com> <189dabc1-c7f8-4e95-51a4-cbff68b8be92@oracle.com> <8e487de0-0280-d90c-2ebd-f7537cc970b2@oracle.com> <027f641b-3e5d-4cb5-f97a-4244899580b8@oracle.com> Message-ID: Change looks fine. Do you need me pushing it for you? Thanks Max On 03/07/2017 06:40 PM, Sergei Kovalev wrote: > Good point. For same reason I've removed module declaration from > PrincipalSystemPropTest.java. Now it uses TETS.properties config. Please > take a look. > > http://cr.openjdk.java.net/~skovalev/8176213/webrev.01/ > > > 07.03.17 13:30, Weijun Wang wrote: >> >> >> On 03/07/2017 05:50 PM, Sergei Kovalev wrote: >>> Hi Max, >>> >>> Thank you for review. >>> >>> >>> 07.03.17 02:15, Weijun Wang wrote: >>>> Hi Sergei >>>> >>>> Two questions: >>>> >>>> 1. Can we remove the @modules section in Renew.java so that it uses >>>> the one in TEST.properties? >>> We can however TEST.properties contains jdk.security.jgss module >>> dependency but Renew.java doesn't. If we remove module declaration from >>> the last one we reduce the number of configuration where the test able >>> to run. Should I do this? >> >> I don't feel uncomfortable using a slightly bigger set. >> >> Do you mean all other tests (without its own @module) are using the >> exact modules in TEST.properties? No more and no less? >> >>>> >>>> 2. I cannot see why jdk.crypto.cryptoki is necessary for >>>> PrincipalSystemPropTest.java. What is the error? >>> Thank you for the question. It should be jdk.security.auth instead. >>>> >>>> BTW, can you tell me how to make the test fail? Maybe with some >>>> special jtreg options? >>> e.g.: >>> >>> jtreg -jdk:/usr/home/jdk9_latest -verbose:all >>> -javaoptions:"--limit-modules >>> >>> /usr/home/repos/jdk9-dev/jdk/test/sun/security/krb5/auto/principalProperty/PrincipalSystemPropTest.java >>> >>> >>> >>> If you get outjdk.security.auth from the module list the test will start >>> failing. >> >> I'll try. >> >> Thanks >> Max >> >>>> >>>> Thanks >>>> Max >>>> >>>> On 03/07/2017 12:24 AM, Sergei Kovalev wrote: >>>>> Hello Team, >>>>> >>>>> Please review small fix for tests. >>>>> >>>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8176213 >>>>> Webrev: http://cr.openjdk.java.net/~skovalev/8176213/webrev.00 >>>>> >>>>> Issue: The tests failing due to undeclared dependencies on >>>>> jdk.security.auth and jdk.security.jgss. >>>>> Solution: add missed module declaration into TEST.properties file. Two >>>>> of tests also required individual dependencies on jdk.httpserver and >>>>> jdk.crypto.cryptoki therefore we creating the module declaration >>>>> section >>>>> in each individual test. >>>>> >>> > From weijun.wang at oracle.com Tue Mar 7 14:10:22 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 7 Mar 2017 22:10:22 +0800 Subject: RFR 8176296: Test sun/security/krb5/auto/Basic.java faling after adding module declaration into TEST.properties. Message-ID: <8a85fe13-dfc8-9565-67bf-1a94319587cf@oracle.com> Please review this changeset at http://cr.openjdk.java.net/~weijun/8176296/webrev.00/ It looks with jdk.security.jgss added into @modules in TEST.properties (JDK-8176213), it cannot be exclude using --limit-modules. Therefore I split Basic.java into 2 and the new test has its own @modules tag. In case you don't remember this test, it was about the Oracle JGSS-API extension. If the jdk.security.jgss module is available, the GSSContext implementation is ExtendedGSSContextImpl inside this module that can do more than GSSContextImpl defined in java.security.jgss (which will be returned when jdk.security.jgss is not available). Thanks Max From sean.coffey at oracle.com Tue Mar 7 14:20:37 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 7 Mar 2017 14:20:37 +0000 Subject: RFR 8171319: keytool should print out warnings when reading or generating cert/cert req using weak algorithms In-Reply-To: <40348c12-6650-3014-2cdb-6e0656a19cff@oracle.com> References: <46c26a65-7886-3a64-60f1-808ae07cd028@oracle.com> <32c222a8-18a1-14d6-7f32-13afd0aefae8@oracle.com> <5ac4842f-a051-3280-8501-4b5f41a781c5@oracle.com> <1665c445-931b-5f91-a8d6-c3c2202ed185@oracle.com> <40348c12-6650-3014-2cdb-6e0656a19cff@oracle.com> Message-ID: <8e3e0628-67dd-8c4f-1943-26dbd8ee9a3f@oracle.com> Looks good to me. regards, Sean. On 03/03/2017 01:17, Weijun Wang wrote: > Updated again at > > http://cr.openjdk.java.net/~weijun/8171319/webrev.03/ > > Changes: > > 1. No more prompt when algorithm/key is weak in keytool -importcert. > This newly introduced prompt might hang a user script. Since we are > thinking of backporting this change to previous releases, this is a > little too dangerous. > > 2. WeakAlg.java test updated. > > 3. Other changes (that add a -noprompt) reverted. > > Thanks > Max > > On 02/23/2017 11:42 AM, Weijun Wang wrote: >> Updated again at >> >> http://cr.openjdk.java.net/~weijun/8171319/webrev.02/ >> >> Changes: >> >> 1. Combined printWeakWarningsWithoutNewLine() and printWeakWarnings() to >> one method. >> >> 2. New X509CRLImpl.toStringWithAlgName(String name). >> >> Nothing more. >> >> Thanks >> Max >> >> On 02/15/2017 11:04 PM, Se?n Coffey wrote: >>> Hi Weijun, >>> >>> That's looks good to me and will be a big help for keytool usability. >>> >>> some thoughts : >>> >>> Main.java : in your printCRL method, would you consider editing the >>> X509CRLImpl class to print with a customized string ? It'll make the >>> code more resilient to future changes in this area >>> >>> i.e. something like this in X509CRLImpl : >>> >>> public String toString() { printCRL(null); } >>> public String printCRL(String custom) { >>> // transfer the toString() code to here >>> // and allow for 'custom' string to be injected if non-null >>> .. >>> } >>> >>> in Main.java, I'd suggest an instanceof check for X509CRLImpl before >>> calling printCRL(..). Could X509CRL.getSigAlgName() then be used for >>> passing into the withWeak method call ? >>> >>> === >>> >>> Also in Main.java, maybe you could reduce >>> printWeakWarningsWithoutNewLine and printWeakWarnings() to one method - >>> e.g. printWeakWarnings(boolean newline) >>> >>> === >>> >>> Regards, >>> Sean. >>> >>> On 15/02/17 01:16, Weijun Wang wrote: >>>> Ping again. >>>> >>>> Also, must we resolve this one before ZBB? >>>> >>>> --Max >>>> >>>> On 02/09/2017 10:26 AM, Weijun Wang wrote: >>>>> An update webrev is at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8171319/webrev.01/ >>>>> >>>>> The major change is that every risk warning has a owner now, i.e. >>>>> instead of just saying "MD5withRSA is weak", it prints out whose >>>>> algorithm is weak. For example: >>>>> >>>>> The generated CRL uses the MD5withRSA signature algorithm which is >>>>> considered a security risk. >>>>> >>>>> Please take a look at the output of the newly added regression >>>>> test at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8171319/webrev.01/examples.txt >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>> On 01/23/2017 06:02 PM, Weijun Wang wrote: >>>>>> Hi All >>>>>> >>>>>> Please take a review at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8171319/webrev.00/ >>>>>> >>>>>> Warnings are printed to System.err when weak algorithms/keysizes are >>>>>> detected during the execution, this includes input, output, and any >>>>>> certs used. >>>>>> >>>>>> The detection applies to many keytool functions: >>>>>> >>>>>> - generation of certificate, certificate request, CRL >>>>>> - reading (printing, listing, exporting) of above >>>>>> - importing of certificate or certificates reply >>>>>> >>>>>> The behavior of most functions remains unchanged. The only >>>>>> exception is >>>>>> "keytool -importcert", where the user must reply to a prompt if weak >>>>>> algorithms/keysizes are detected, unless -noprompt is specified >>>>>> on the >>>>>> command line. >>>>>> >>>>>> Warnings are either printed at the end, or before a prompt. >>>>>> >>>>>> If there are multiple weak points, multiple warnings will be >>>>>> printed. >>>>>> >>>>>> The detection is based on the security property >>>>>> jdk.certpath.disabledAlgorithms. >>>>>> >>>>>> For example: >>>>>> >>>>>> $ keytool -genkeypair -alias a -dname CN=a -keyalg RSA -sigalg >>>>>> MD5withRSA >>>>>> >>>>>> Warning: >>>>>> The MD5withRSA signature algorithm is considered a security risk. >>>>>> >>>>>> $ keytool -keystore ks -storepass changeit -keypass changeit -list >>>>>> >>>>>> Keystore type: JKS >>>>>> Keystore provider: SUN >>>>>> >>>>>> Your keystore contains 3 entries >>>>>> >>>>>> b, Jan 23, 2017, PrivateKeyEntry, >>>>>> Certificate fingerprint (SHA-256): >>>>>> D8:46:B7:0B:8B:97:C2:DE:A2:17:62:01:27:82:2B:CE:B1:9B:12:0B:24:D5:47:BF:BD:54:EE:8A:71:29:2B:CE >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> a, Jan 23, 2017, PrivateKeyEntry, >>>>>> Certificate fingerprint (SHA-256): >>>>>> 66:70:DF:11:14:A1:96:58:92:F5:6A:10:09:B1:2F:CC:1C:CC:2D:55:47:1D:EE:74:75:AA:26:63:E4:9D:EA:83 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Warning: >>>>>> 's 512-bit RSA key is considered a security risk. >>>>>> 's MD5withRSA signature algorithm is considered a security risk. >>>>>> >>>>>> $ keytool -importcert -alias a -file b+a.certs >>>>>> >>>>>> Warning: >>>>>> Reply #2 of 2's 512-bit RSA key is considered a security risk. >>>>>> >>>>>> Install reply anyway? [no]:no >>>>>> Certificate reply was not installed in keystore >>>>>> >>>>>> Thanks >>>>>> Max >>> From weijun.wang at oracle.com Tue Mar 7 14:44:11 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 7 Mar 2017 22:44:11 +0800 Subject: RFR 8175846: Provide javadoc descriptions for jdk.policytool and jdk.crypto.* modules In-Reply-To: <5d6f41bb-e9b2-17b7-8ca1-c5f1eb091cff@oracle.com> References: <5d6f41bb-e9b2-17b7-8ca1-c5f1eb091cff@oracle.com> Message-ID: <418bde6b-5670-50ed-f752-29d51301d54f@oracle.com> Ping again. On 03/01/2017 09:02 AM, Weijun Wang wrote: > Please review the patch below. I don't know if all those jdk.crypto.* > modules will be listed in the doc, but it's nice to include a comment. > > Thanks > Max > > diff --git a/src/jdk.policytool/share/classes/module-info.java > b/src/jdk.policytool/share/classes/module-info.java > --- a/src/jdk.policytool/share/classes/module-info.java > +++ b/src/jdk.policytool/share/classes/module-info.java > @@ -23,6 +23,14 @@ > * questions. > */ > > +/** > + * GUI tool for managing policy files. > + * > + * @since 9 > + * @deprecated The policytool tool has been deprecated and > + * is planned to be removed in a future release. > + */ > + at Deprecated > module jdk.policytool { > requires java.desktop; > requires java.logging; > > diff --git a/src/jdk.crypto.cryptoki/share/classes/module-info.java > b/src/jdk.crypto.cryptoki/share/classes/module-info.java > --- a/src/jdk.crypto.cryptoki/share/classes/module-info.java > +++ b/src/jdk.crypto.cryptoki/share/classes/module-info.java > @@ -23,6 +23,11 @@ > * questions. > */ > > +/** > + * The SunPKCS11 security provider. > + * > + * @since 9 > + */ > module jdk.crypto.cryptoki { > // Depends on SunEC provider for EC related functionality > requires jdk.crypto.ec; > diff --git a/src/jdk.crypto.ec/share/classes/module-info.java > b/src/jdk.crypto.ec/share/classes/module-info.java > --- a/src/jdk.crypto.ec/share/classes/module-info.java > +++ b/src/jdk.crypto.ec/share/classes/module-info.java > @@ -23,6 +23,11 @@ > * questions. > */ > > +/** > + * The SunEC security provider. > + * > + * @since 9 > + */ > module jdk.crypto.ec { > provides java.security.Provider with sun.security.ec.SunEC; > } > diff --git a/src/jdk.crypto.mscapi/windows/classes/module-info.java > b/src/jdk.crypto.mscapi/windows/classes/module-info.java > --- a/src/jdk.crypto.mscapi/windows/classes/module-info.java > +++ b/src/jdk.crypto.mscapi/windows/classes/module-info.java > @@ -23,6 +23,11 @@ > * questions. > */ > > +/** > + * The SunMSCAPI security provider. > + * > + * @since 9 > + */ > module jdk.crypto.mscapi { > provides java.security.Provider with sun.security.mscapi.SunMSCAPI; > } > diff --git a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java > b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java > --- a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java > +++ b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java > @@ -23,6 +23,11 @@ > * questions. > */ > > +/** > + * The OracleUCrypto security provider. > + * > + * @since 9 > + */ > module jdk.crypto.ucrypto { > provides java.security.Provider with > com.oracle.security.ucrypto.UcryptoProvider; > } > > Thanks > Max From vincent.x.ryan at oracle.com Tue Mar 7 14:46:13 2017 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 7 Mar 2017 14:46:13 +0000 Subject: RFR 8175846: Provide javadoc descriptions for jdk.policytool and jdk.crypto.* modules In-Reply-To: <418bde6b-5670-50ed-f752-29d51301d54f@oracle.com> References: <5d6f41bb-e9b2-17b7-8ca1-c5f1eb091cff@oracle.com> <418bde6b-5670-50ed-f752-29d51301d54f@oracle.com> Message-ID: <7B48784C-8A59-46D1-9DD5-F8953E8BE4D9@oracle.com> Your comments look fine to me. > On 7 Mar 2017, at 14:44, Weijun Wang wrote: > > Ping again. > > On 03/01/2017 09:02 AM, Weijun Wang wrote: >> Please review the patch below. I don't know if all those jdk.crypto.* >> modules will be listed in the doc, but it's nice to include a comment. >> >> Thanks >> Max >> >> diff --git a/src/jdk.policytool/share/classes/module-info.java >> b/src/jdk.policytool/share/classes/module-info.java >> --- a/src/jdk.policytool/share/classes/module-info.java >> +++ b/src/jdk.policytool/share/classes/module-info.java >> @@ -23,6 +23,14 @@ >> * questions. >> */ >> >> +/** >> + * GUI tool for managing policy files. >> + * >> + * @since 9 >> + * @deprecated The policytool tool has been deprecated and >> + * is planned to be removed in a future release. >> + */ >> + at Deprecated >> module jdk.policytool { >> requires java.desktop; >> requires java.logging; >> >> diff --git a/src/jdk.crypto.cryptoki/share/classes/module-info.java >> b/src/jdk.crypto.cryptoki/share/classes/module-info.java >> --- a/src/jdk.crypto.cryptoki/share/classes/module-info.java >> +++ b/src/jdk.crypto.cryptoki/share/classes/module-info.java >> @@ -23,6 +23,11 @@ >> * questions. >> */ >> >> +/** >> + * The SunPKCS11 security provider. >> + * >> + * @since 9 >> + */ >> module jdk.crypto.cryptoki { >> // Depends on SunEC provider for EC related functionality >> requires jdk.crypto.ec; >> diff --git a/src/jdk.crypto.ec/share/classes/module-info.java >> b/src/jdk.crypto.ec/share/classes/module-info.java >> --- a/src/jdk.crypto.ec/share/classes/module-info.java >> +++ b/src/jdk.crypto.ec/share/classes/module-info.java >> @@ -23,6 +23,11 @@ >> * questions. >> */ >> >> +/** >> + * The SunEC security provider. >> + * >> + * @since 9 >> + */ >> module jdk.crypto.ec { >> provides java.security.Provider with sun.security.ec.SunEC; >> } >> diff --git a/src/jdk.crypto.mscapi/windows/classes/module-info.java >> b/src/jdk.crypto.mscapi/windows/classes/module-info.java >> --- a/src/jdk.crypto.mscapi/windows/classes/module-info.java >> +++ b/src/jdk.crypto.mscapi/windows/classes/module-info.java >> @@ -23,6 +23,11 @@ >> * questions. >> */ >> >> +/** >> + * The SunMSCAPI security provider. >> + * >> + * @since 9 >> + */ >> module jdk.crypto.mscapi { >> provides java.security.Provider with sun.security.mscapi.SunMSCAPI; >> } >> diff --git a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >> b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >> --- a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >> +++ b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >> @@ -23,6 +23,11 @@ >> * questions. >> */ >> >> +/** >> + * The OracleUCrypto security provider. >> + * >> + * @since 9 >> + */ >> module jdk.crypto.ucrypto { >> provides java.security.Provider with >> com.oracle.security.ucrypto.UcryptoProvider; >> } >> >> Thanks >> Max From sergei.kovalev at oracle.com Tue Mar 7 14:55:13 2017 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 7 Mar 2017 17:55:13 +0300 Subject: RFR 8176296: Test sun/security/krb5/auto/Basic.java faling after adding module declaration into TEST.properties. In-Reply-To: <8a85fe13-dfc8-9565-67bf-1a94319587cf@oracle.com> References: <8a85fe13-dfc8-9565-67bf-1a94319587cf@oracle.com> Message-ID: <9e3275fb-2eed-9af1-1b6e-a879658b99b9@oracle.com> Thanks that let me see. Good to know. 07.03.17 17:10, Weijun Wang wrote: > Please review this changeset at > > http://cr.openjdk.java.net/~weijun/8176296/webrev.00/ > > It looks with jdk.security.jgss added into @modules in TEST.properties > (JDK-8176213), it cannot be exclude using --limit-modules. > > Therefore I split Basic.java into 2 and the new test has its own > @modules tag. > > In case you don't remember this test, it was about the Oracle JGSS-API > extension. If the jdk.security.jgss module is available, the > GSSContext implementation is ExtendedGSSContextImpl inside this module > that can do more than GSSContextImpl defined in java.security.jgss > (which will be returned when jdk.security.jgss is not available). > > Thanks > Max -- With best regards, Sergei From sean.mullan at oracle.com Tue Mar 7 16:07:15 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 7 Mar 2017 11:07:15 -0500 Subject: RFR 8175846: Provide javadoc descriptions for jdk.policytool and jdk.crypto.* modules In-Reply-To: <418bde6b-5670-50ed-f752-29d51301d54f@oracle.com> References: <5d6f41bb-e9b2-17b7-8ca1-c5f1eb091cff@oracle.com> <418bde6b-5670-50ed-f752-29d51301d54f@oracle.com> Message-ID: <2890fa2b-ef18-088d-5f29-0e9450cab6b5@oracle.com> On 3/7/17 9:44 AM, Weijun Wang wrote: > Ping again. Sorry I missed this before you pushed the changeset, but the @Deprecated annotation for the jdk.policytool module should have "forRemoval=true" on it, since it scheduled for removal in JDK 10: https://bugs.openjdk.java.net/browse/JDK-8147400 --Sean > > On 03/01/2017 09:02 AM, Weijun Wang wrote: >> Please review the patch below. I don't know if all those jdk.crypto.* >> modules will be listed in the doc, but it's nice to include a comment. >> >> Thanks >> Max >> >> diff --git a/src/jdk.policytool/share/classes/module-info.java >> b/src/jdk.policytool/share/classes/module-info.java >> --- a/src/jdk.policytool/share/classes/module-info.java >> +++ b/src/jdk.policytool/share/classes/module-info.java >> @@ -23,6 +23,14 @@ >> * questions. >> */ >> >> +/** >> + * GUI tool for managing policy files. >> + * >> + * @since 9 >> + * @deprecated The policytool tool has been deprecated and >> + * is planned to be removed in a future release. >> + */ >> + at Deprecated >> module jdk.policytool { >> requires java.desktop; >> requires java.logging; >> >> diff --git a/src/jdk.crypto.cryptoki/share/classes/module-info.java >> b/src/jdk.crypto.cryptoki/share/classes/module-info.java >> --- a/src/jdk.crypto.cryptoki/share/classes/module-info.java >> +++ b/src/jdk.crypto.cryptoki/share/classes/module-info.java >> @@ -23,6 +23,11 @@ >> * questions. >> */ >> >> +/** >> + * The SunPKCS11 security provider. >> + * >> + * @since 9 >> + */ >> module jdk.crypto.cryptoki { >> // Depends on SunEC provider for EC related functionality >> requires jdk.crypto.ec; >> diff --git a/src/jdk.crypto.ec/share/classes/module-info.java >> b/src/jdk.crypto.ec/share/classes/module-info.java >> --- a/src/jdk.crypto.ec/share/classes/module-info.java >> +++ b/src/jdk.crypto.ec/share/classes/module-info.java >> @@ -23,6 +23,11 @@ >> * questions. >> */ >> >> +/** >> + * The SunEC security provider. >> + * >> + * @since 9 >> + */ >> module jdk.crypto.ec { >> provides java.security.Provider with sun.security.ec.SunEC; >> } >> diff --git a/src/jdk.crypto.mscapi/windows/classes/module-info.java >> b/src/jdk.crypto.mscapi/windows/classes/module-info.java >> --- a/src/jdk.crypto.mscapi/windows/classes/module-info.java >> +++ b/src/jdk.crypto.mscapi/windows/classes/module-info.java >> @@ -23,6 +23,11 @@ >> * questions. >> */ >> >> +/** >> + * The SunMSCAPI security provider. >> + * >> + * @since 9 >> + */ >> module jdk.crypto.mscapi { >> provides java.security.Provider with sun.security.mscapi.SunMSCAPI; >> } >> diff --git a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >> b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >> --- a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >> +++ b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >> @@ -23,6 +23,11 @@ >> * questions. >> */ >> >> +/** >> + * The OracleUCrypto security provider. >> + * >> + * @since 9 >> + */ >> module jdk.crypto.ucrypto { >> provides java.security.Provider with >> com.oracle.security.ucrypto.UcryptoProvider; >> } >> >> Thanks >> Max From weijun.wang at oracle.com Tue Mar 7 23:37:42 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 8 Mar 2017 07:37:42 +0800 Subject: RFR 8175846: Provide javadoc descriptions for jdk.policytool and jdk.crypto.* modules In-Reply-To: <2890fa2b-ef18-088d-5f29-0e9450cab6b5@oracle.com> References: <5d6f41bb-e9b2-17b7-8ca1-c5f1eb091cff@oracle.com> <418bde6b-5670-50ed-f752-29d51301d54f@oracle.com> <2890fa2b-ef18-088d-5f29-0e9450cab6b5@oracle.com> Message-ID: There was no "forRemoval=true" for the sun.security.tools.policytool.Main class itself either. I'll file a bug and add it to both. Thanks Max On 03/08/2017 12:07 AM, Sean Mullan wrote: > On 3/7/17 9:44 AM, Weijun Wang wrote: >> Ping again. > > Sorry I missed this before you pushed the changeset, but the @Deprecated > annotation for the jdk.policytool module should have "forRemoval=true" > on it, since it scheduled for removal in JDK 10: > https://bugs.openjdk.java.net/browse/JDK-8147400 > > --Sean > >> >> On 03/01/2017 09:02 AM, Weijun Wang wrote: >>> Please review the patch below. I don't know if all those jdk.crypto.* >>> modules will be listed in the doc, but it's nice to include a comment. >>> >>> Thanks >>> Max >>> >>> diff --git a/src/jdk.policytool/share/classes/module-info.java >>> b/src/jdk.policytool/share/classes/module-info.java >>> --- a/src/jdk.policytool/share/classes/module-info.java >>> +++ b/src/jdk.policytool/share/classes/module-info.java >>> @@ -23,6 +23,14 @@ >>> * questions. >>> */ >>> >>> +/** >>> + * GUI tool for managing policy files. >>> + * >>> + * @since 9 >>> + * @deprecated The policytool tool has been deprecated and >>> + * is planned to be removed in a future release. >>> + */ >>> + at Deprecated >>> module jdk.policytool { >>> requires java.desktop; >>> requires java.logging; >>> >>> diff --git a/src/jdk.crypto.cryptoki/share/classes/module-info.java >>> b/src/jdk.crypto.cryptoki/share/classes/module-info.java >>> --- a/src/jdk.crypto.cryptoki/share/classes/module-info.java >>> +++ b/src/jdk.crypto.cryptoki/share/classes/module-info.java >>> @@ -23,6 +23,11 @@ >>> * questions. >>> */ >>> >>> +/** >>> + * The SunPKCS11 security provider. >>> + * >>> + * @since 9 >>> + */ >>> module jdk.crypto.cryptoki { >>> // Depends on SunEC provider for EC related functionality >>> requires jdk.crypto.ec; >>> diff --git a/src/jdk.crypto.ec/share/classes/module-info.java >>> b/src/jdk.crypto.ec/share/classes/module-info.java >>> --- a/src/jdk.crypto.ec/share/classes/module-info.java >>> +++ b/src/jdk.crypto.ec/share/classes/module-info.java >>> @@ -23,6 +23,11 @@ >>> * questions. >>> */ >>> >>> +/** >>> + * The SunEC security provider. >>> + * >>> + * @since 9 >>> + */ >>> module jdk.crypto.ec { >>> provides java.security.Provider with sun.security.ec.SunEC; >>> } >>> diff --git a/src/jdk.crypto.mscapi/windows/classes/module-info.java >>> b/src/jdk.crypto.mscapi/windows/classes/module-info.java >>> --- a/src/jdk.crypto.mscapi/windows/classes/module-info.java >>> +++ b/src/jdk.crypto.mscapi/windows/classes/module-info.java >>> @@ -23,6 +23,11 @@ >>> * questions. >>> */ >>> >>> +/** >>> + * The SunMSCAPI security provider. >>> + * >>> + * @since 9 >>> + */ >>> module jdk.crypto.mscapi { >>> provides java.security.Provider with sun.security.mscapi.SunMSCAPI; >>> } >>> diff --git a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >>> b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >>> --- a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >>> +++ b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java >>> @@ -23,6 +23,11 @@ >>> * questions. >>> */ >>> >>> +/** >>> + * The OracleUCrypto security provider. >>> + * >>> + * @since 9 >>> + */ >>> module jdk.crypto.ucrypto { >>> provides java.security.Provider with >>> com.oracle.security.ucrypto.UcryptoProvider; >>> } >>> >>> Thanks >>> Max From weijun.wang at oracle.com Wed Mar 8 03:19:09 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 8 Mar 2017 11:19:09 +0800 Subject: RFR 8176320: security/tools/jarsigner/TsacertOptionTest.java compilation error, all mach 5 tier 2 platforms broken. Message-ID: Please review this fix: diff --git a/test/sun/security/tools/jarsigner/TsacertOptionTest.java b/test/sun/security/tools/jarsigner/TsacertOptionTest.java --- a/test/sun/security/tools/jarsigner/TsacertOptionTest.java +++ b/test/sun/security/tools/jarsigner/TsacertOptionTest.java @@ -29,6 +29,7 @@ * @bug 8024302 8026037 * @summary The test signs and verifies a jar file with -tsacert option * @library /lib/testlibrary warnings + * @library /test/lib * @modules java.base/sun.security.pkcs * java.base/sun.security.timestamp * java.base/sun.security.tools.keytool This test calls a method in TimestampToken.java which uses a lib in /test/lib. The lib is in @library of TimestampToken.java therefore there is no problem running TimestampToken.java. There is also no problem running this test if TimestampToken.java is already compiled and we have the lib classes ready. But if TimestampToken.java is not already compiled, this test will not compile. This is just random. Thanks Max From xuelei.fan at oracle.com Wed Mar 8 04:21:33 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 7 Mar 2017 20:21:33 -0800 Subject: RFR 8176320: security/tools/jarsigner/TsacertOptionTest.java compilation error, all mach 5 tier 2 platforms broken. In-Reply-To: References: Message-ID: Looks fine to me. Xuelei On 3/7/2017 7:19 PM, Weijun Wang wrote: > Please review this fix: > > diff --git a/test/sun/security/tools/jarsigner/TsacertOptionTest.java > b/test/sun/security/tools/jarsigner/TsacertOptionTest.java > --- a/test/sun/security/tools/jarsigner/TsacertOptionTest.java > +++ b/test/sun/security/tools/jarsigner/TsacertOptionTest.java > @@ -29,6 +29,7 @@ > * @bug 8024302 8026037 > * @summary The test signs and verifies a jar file with -tsacert option > * @library /lib/testlibrary warnings > + * @library /test/lib > * @modules java.base/sun.security.pkcs > * java.base/sun.security.timestamp > * java.base/sun.security.tools.keytool > > This test calls a method in TimestampToken.java which uses a lib in > /test/lib. The lib is in @library of TimestampToken.java therefore there > is no problem running TimestampToken.java. There is also no problem > running this test if TimestampToken.java is already compiled and we have > the lib classes ready. But if TimestampToken.java is not already > compiled, this test will not compile. This is just random. > > Thanks > Max From joe.darcy at oracle.com Wed Mar 8 06:48:27 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 7 Mar 2017 22:48:27 -0800 Subject: 9 RFR of JDK-8176337: Mark several tests as intermittently failing In-Reply-To: References: Message-ID: Looks fine Hamlin; thanks, -Joe On 3/7/2017 7:36 PM, Hamlin Li wrote: > Would you please review below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8176337 > > webrev: http://cr.openjdk.java.net/~mli/8176337/webrev.00/ > > > These tests are failing intermittently, they should be marked > accordingly with > @key intermittent > > java/nio/channels/FileChannel/Transfer.java (JDK-8140263 > ) > java/nio/channels/FileChannel/Transfers.java (JDK-8140263 > ) > java/io/FileInputStream/LargeFileAvailable.java (JDK-8174810 > ) > java/nio/channels/FileChannel/LoopingTruncate.java (JDK-8173386 > ) > java/lang/ProcessBuilder/Basic.java (JDK-8171426 > ) > sun/security/tools/keytool/DefaultSignatureAlgorithm.java (JDK-8172657 > ) > javax/net/ssl/DTLS/CipherSuite.java (JDK-8174072 > ) > > > Thank you > > -Hamlin > From Alan.Bateman at oracle.com Wed Mar 8 14:26:40 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Mar 2017 14:26:40 +0000 Subject: 9 RFR of JDK-8176337: Mark several tests as intermittently failing In-Reply-To: References: Message-ID: On 08/03/2017 03:36, Hamlin Li wrote: > Would you please review below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8176337 > > webrev: http://cr.openjdk.java.net/~mli/8176337/webrev.00/ > > > These tests are failing intermittently, they should be marked > accordingly with > @key intermittent > > java/nio/channels/FileChannel/Transfer.java (JDK-8140263 > ) > java/nio/channels/FileChannel/Transfers.java (JDK-8140263 > ) > java/io/FileInputStream/LargeFileAvailable.java (JDK-8174810 > ) > java/nio/channels/FileChannel/LoopingTruncate.java (JDK-8173386 > ) > java/lang/ProcessBuilder/Basic.java (JDK-8171426 > ) > sun/security/tools/keytool/DefaultSignatureAlgorithm.java (JDK-8172657 > ) > javax/net/ssl/DTLS/CipherSuite.java (JDK-8174072 > ) For the FileChannel and FileInputStream tests then are the tests really failing intermittently? I've seen logs attached to several bugs reports but the tests are passing, the timeouts/failures seem to happen after the tests completes successfully. -Alan From huaming.li at oracle.com Wed Mar 8 03:36:38 2017 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 8 Mar 2017 11:36:38 +0800 Subject: 9 RFR of JDK-8176337: Mark several tests as intermittently failing Message-ID: Would you please review below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176337 webrev: http://cr.openjdk.java.net/~mli/8176337/webrev.00/ These tests are failing intermittently, they should be marked accordingly with @key intermittent java/nio/channels/FileChannel/Transfer.java (JDK-8140263 ) java/nio/channels/FileChannel/Transfers.java (JDK-8140263 ) java/io/FileInputStream/LargeFileAvailable.java (JDK-8174810 ) java/nio/channels/FileChannel/LoopingTruncate.java (JDK-8173386 ) java/lang/ProcessBuilder/Basic.java (JDK-8171426 ) sun/security/tools/keytool/DefaultSignatureAlgorithm.java (JDK-8172657 ) javax/net/ssl/DTLS/CipherSuite.java (JDK-8174072 ) Thank you -Hamlin -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Mar 8 17:52:49 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 8 Mar 2017 09:52:49 -0800 Subject: 9 RFR of JDK-8176337: Mark several tests as intermittently failing In-Reply-To: References: Message-ID: <6fda8b26-ef84-c679-5b01-81f0f4fa6243@oracle.com> > sun/security/tools/keytool/DefaultSignatureAlgorithm.java > javax/net/ssl/DTLS/CipherSuite.java The above two updates look fine to me. Thanks, Xuelei On 3/7/2017 7:36 PM, Hamlin Li wrote: > Would you please review below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8176337 > > webrev: http://cr.openjdk.java.net/~mli/8176337/webrev.00/ > > > These tests are failing intermittently, they should be marked > accordingly with > @key intermittent > > java/nio/channels/FileChannel/Transfer.java (JDK-8140263 > ) > java/nio/channels/FileChannel/Transfers.java (JDK-8140263 > ) > java/io/FileInputStream/LargeFileAvailable.java (JDK-8174810 > ) > java/nio/channels/FileChannel/LoopingTruncate.java (JDK-8173386 > ) > java/lang/ProcessBuilder/Basic.java (JDK-8171426 > ) > sun/security/tools/keytool/DefaultSignatureAlgorithm.java (JDK-8172657 > ) > javax/net/ssl/DTLS/CipherSuite.java (JDK-8174072 > ) > > > Thank you > > -Hamlin > From anthony.scarpino at oracle.com Wed Mar 8 21:15:49 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 8 Mar 2017 13:15:49 -0800 Subject: RFR 8176350: Usage constraints don't take effect when using PKIX Message-ID: <90c4f396-a4b7-c305-5c82-b981b3d28e1f@oracle.com> Hi, I need a code review of this small change.. The PKIX path for usage checking didn't pass the variant to the checkers because of a previous needed check for plugins. http://cr.openjdk.java.net/~ascarpino/8176350/webrev/ thanks Tony From amanda.jiang at oracle.com Wed Mar 8 21:20:33 2017 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Wed, 8 Mar 2017 13:20:33 -0800 Subject: RFR 8176400: Problemlist sun/security/ssl/X509KeyManager/PreferredKey.java due to JDK-8176354 Message-ID: Hi All, Could you please help to review the patch below? sun/security/ssl/X509KeyManager/PreferredKey.java failed on all platforms since related certificate in keystore has been expired. To fix the bug, the keystore should be carefully updated with new certificate since a lot of tests depended on the keystore. Temporarily add this test to problem list during fixing it. Bug: https://bugs.openjdk.java.net/browse/JDK-8176400 diff -r 4f151e0530e6 test/ProblemList.txt --- a/test/ProblemList.txt Wed Mar 08 12:14:25 2017 -0800 +++ b/test/ProblemList.txt Wed Mar 08 13:17:06 2017 -0800 @@ -219,6 +219,7 @@ sun/security/krb5/auto/Basic.java 8176296 generic-all +sun/security/ssl/X509KeyManager/PreferredKey.java 8176354 generic-all ############################################################################ # jdk_sound Thanks, Amanda -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Wed Mar 8 21:26:03 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 8 Mar 2017 13:26:03 -0800 Subject: RFR 8176400: Problemlist sun/security/ssl/X509KeyManager/PreferredKey.java due to JDK-8176354 In-Reply-To: References: Message-ID: Looks fine to me. Thanks, Xuelei On 3/8/2017 1:20 PM, Amanda Jiang wrote: > Hi All, > > Could you please help to review the patch below? > > sun/security/ssl/X509KeyManager/PreferredKey.java failed on all > platforms since related certificate in keystore has been expired. > To fix the bug, the keystore should be carefully updated with new > certificate since a lot of tests depended on the keystore. Temporarily > add this test to problem list during fixing it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176400 > > > diff -r 4f151e0530e6 test/ProblemList.txt > --- a/test/ProblemList.txt Wed Mar 08 12:14:25 2017 -0800 > +++ b/test/ProblemList.txt Wed Mar 08 13:17:06 2017 -0800 > @@ -219,6 +219,7 @@ > > sun/security/krb5/auto/Basic.java 8176296 > generic-all > > +sun/security/ssl/X509KeyManager/PreferredKey.java 8176354 > generic-all > ############################################################################ > > # jdk_sound > > > Thanks, > Amanda > > > From xuelei.fan at oracle.com Wed Mar 8 21:42:31 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 8 Mar 2017 13:42:31 -0800 Subject: RFR 8176350: Usage constraints don't take effect when using PKIX In-Reply-To: <90c4f396-a4b7-c305-5c82-b981b3d28e1f@oracle.com> References: <90c4f396-a4b7-c305-5c82-b981b3d28e1f@oracle.com> Message-ID: Looks fine to me except a minor comment. In the update of DisabledAlgorithmConstraints.java, the dumping of stack trace for every checking could increase the debug log size a lot. There is no verbose option for 'certpath' debug. What do you think if only dumping the log when the usage is not allowed? Xuelei On 3/8/2017 1:15 PM, Anthony Scarpino wrote: > Hi, > > I need a code review of this small change.. The PKIX path for usage > checking didn't pass the variant to the checkers because of a previous > needed check for plugins. > > http://cr.openjdk.java.net/~ascarpino/8176350/webrev/ > > thanks > > Tony From sean.mullan at oracle.com Wed Mar 8 21:44:17 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 8 Mar 2017 16:44:17 -0500 Subject: RFR 8176350: Usage constraints don't take effect when using PKIX In-Reply-To: <90c4f396-a4b7-c305-5c82-b981b3d28e1f@oracle.com> References: <90c4f396-a4b7-c305-5c82-b981b3d28e1f@oracle.com> Message-ID: - DisabledAlgorithmConstraints.java You can just call Thread.dumpStack (which dumps to stderr) here if debug is set. OTOH, I am concerned this will quickly fill up the log file with stack traces (which can be long). Do we really need this? --Sean On 3/8/17 4:15 PM, Anthony Scarpino wrote: > Hi, > > I need a code review of this small change.. The PKIX path for usage > checking didn't pass the variant to the checkers because of a previous > needed check for plugins. > > http://cr.openjdk.java.net/~ascarpino/8176350/webrev/ > > thanks > > Tony From artem.smotrakov at oracle.com Wed Mar 8 21:52:05 2017 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 8 Mar 2017 13:52:05 -0800 Subject: [9] RFR: 8176183: sun/security/mscapi/SignedObjectChain.java fails on Windows Message-ID: <4a8cc271-a538-7db3-15ce-a3b26814054e@oracle.com> Hello, The test fails with "Key type not supported" error on Windows only with SunMSCAPI provider. It happens because the test passes an incompatible key object to Signature instance. Please see more details in https://bugs.openjdk.java.net/browse/JDK-8176183?focusedCommentId=14058876&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14058876 The following patch updates Chain.java (which is used by SignedObjectChain.java) to use specified security provider for both key generation and singing. I ran all tests which depend on Chain.java on all generic platforms, they worked fine. Bug: https://bugs.openjdk.java.net/browse/JDK-8176183 Webrev: http://cr.openjdk.java.net/~asmotrak/8176183/webrev.00/ Artem From anthony.scarpino at oracle.com Wed Mar 8 22:52:56 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 8 Mar 2017 14:52:56 -0800 Subject: RFR 8176350: Usage constraints don't take effect when using PKIX In-Reply-To: References: <90c4f396-a4b7-c305-5c82-b981b3d28e1f@oracle.com> Message-ID: Since Sean and you are asking similar questions, I'll answer it here. It was to be consistent with by using the Debug class. If a change is made to Debug to print elsewhere, what I have now is compatible. Sending it to stderr is basically saying that Debug is a useless class and we should just print System.err.println() instead. As for why the stack trace is there, like I said in the comment, if there is a situation that should or should not have been blocked, we know what path it took. There are many methods that send data through this code and having this debug info allows us to quickly find why it happened instead of trying to recreating the situation. Other constraints deny or allow all ops. This being usage-based, where SHA1 could be blocked for one usage, but not for another on the same security property need more detailed debugging, in my opinion. About the extra data, I don't believe it's that much more and there isn't a way to find out the information that would be needed. The situation of the problem may not be reproducible in our environment because the user doesn't want to give up their certs or know their app is performing that usage. If dumpStack() is less data than printStackTrace(), I'm fine with switching as long as I get the same info. It would be nice if there was a verbose option. We could turn off AdaptiveX509Selector that prints every check in byte level detail which overflows jtreg's buffer all the time :-) Tony On 03/08/2017 01:42 PM, Xuelei Fan wrote: > Looks fine to me except a minor comment. > > In the update of DisabledAlgorithmConstraints.java, the dumping of stack > trace for every checking could increase the debug log size a lot. There > is no verbose option for 'certpath' debug. What do you think if only > dumping the log when the usage is not allowed? > > Xuelei > > On 3/8/2017 1:15 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this small change.. The PKIX path for usage >> checking didn't pass the variant to the checkers because of a previous >> needed check for plugins. >> >> http://cr.openjdk.java.net/~ascarpino/8176350/webrev/ >> >> thanks >> >> Tony From weijun.wang at oracle.com Thu Mar 9 00:50:29 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 9 Mar 2017 08:50:29 +0800 Subject: [9] RFR: 8176183: sun/security/mscapi/SignedObjectChain.java fails on Windows In-Reply-To: <4a8cc271-a538-7db3-15ce-a3b26814054e@oracle.com> References: <4a8cc271-a538-7db3-15ce-a3b26814054e@oracle.com> Message-ID: <25015ed6-18c6-0b71-edb6-eaa59be42f81@oracle.com> I remember Signature is able to automatically switch to the correct provider when its init(key) is called. Does this mean you don't need to care about Signature.getInstance(alg,provider)? Thanks Max On 03/09/2017 05:52 AM, Artem Smotrakov wrote: > Hello, > > The test fails with "Key type not supported" error on Windows only with > SunMSCAPI provider. It happens because the test passes an incompatible > key object to Signature instance. Please see more details in > > https://bugs.openjdk.java.net/browse/JDK-8176183?focusedCommentId=14058876&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14058876 > > > The following patch updates Chain.java (which is used by > SignedObjectChain.java) to use specified security provider for both key > generation and singing. > > I ran all tests which depend on Chain.java on all generic platforms, > they worked fine. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176183 > > Webrev: http://cr.openjdk.java.net/~asmotrak/8176183/webrev.00/ > > Artem > From artem.smotrakov at oracle.com Thu Mar 9 01:55:06 2017 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 8 Mar 2017 17:55:06 -0800 Subject: [9] RFR: 8176183: sun/security/mscapi/SignedObjectChain.java fails on Windows In-Reply-To: <25015ed6-18c6-0b71-edb6-eaa59be42f81@oracle.com> References: <4a8cc271-a538-7db3-15ce-a3b26814054e@oracle.com> <25015ed6-18c6-0b71-edb6-eaa59be42f81@oracle.com> Message-ID: <02a2ffbe-45ac-c107-255d-2a0f08c12b3f@oracle.com> Hi Max, I am not sure if SunMSCAPI has higher priority than SunJCE, SUN, etc on Windows. But this test is for SunMSCAPI provider, so we explicitly set this provider for Signature. Artem On 03/08/2017 04:50 PM, Weijun Wang wrote: > I remember Signature is able to automatically switch to the correct > provider when its init(key) is called. Does this mean you don't need > to care about Signature.getInstance(alg,provider)? > > Thanks > Max > > On 03/09/2017 05:52 AM, Artem Smotrakov wrote: >> Hello, >> >> The test fails with "Key type not supported" error on Windows only with >> SunMSCAPI provider. It happens because the test passes an incompatible >> key object to Signature instance. Please see more details in >> >> https://bugs.openjdk.java.net/browse/JDK-8176183?focusedCommentId=14058876&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14058876 >> >> >> >> The following patch updates Chain.java (which is used by >> SignedObjectChain.java) to use specified security provider for both key >> generation and singing. >> >> I ran all tests which depend on Chain.java on all generic platforms, >> they worked fine. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8176183 >> >> Webrev: http://cr.openjdk.java.net/~asmotrak/8176183/webrev.00/ >> >> Artem >> From weijun.wang at oracle.com Thu Mar 9 01:57:54 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 9 Mar 2017 09:57:54 +0800 Subject: [9] RFR: 8176183: sun/security/mscapi/SignedObjectChain.java fails on Windows In-Reply-To: <02a2ffbe-45ac-c107-255d-2a0f08c12b3f@oracle.com> References: <4a8cc271-a538-7db3-15ce-a3b26814054e@oracle.com> <25015ed6-18c6-0b71-edb6-eaa59be42f81@oracle.com> <02a2ffbe-45ac-c107-255d-2a0f08c12b3f@oracle.com> Message-ID: <2ebd9994-e305-c6c2-d7b7-26f6970244ec@oracle.com> On 03/09/2017 09:55 AM, Artem Smotrakov wrote: > Hi Max, > > I am not sure if SunMSCAPI has higher priority than SunJCE, SUN, etc on > Windows. But this test is for SunMSCAPI provider, so we explicitly set > this provider for Signature. OK. You fix is good then. What I was saying that even if SunMSCAPI is not the preferred provider, after you call Signature.getInstance("SHA256withRSA") the actual provider is not finally determined. When you call sig.init(key, SIGN), it will choose key's provider as its own provider. At least this is how to I understand it. Thanks Max > > Artem > > > On 03/08/2017 04:50 PM, Weijun Wang wrote: >> I remember Signature is able to automatically switch to the correct >> provider when its init(key) is called. Does this mean you don't need >> to care about Signature.getInstance(alg,provider)? >> >> Thanks >> Max >> >> On 03/09/2017 05:52 AM, Artem Smotrakov wrote: >>> Hello, >>> >>> The test fails with "Key type not supported" error on Windows only with >>> SunMSCAPI provider. It happens because the test passes an incompatible >>> key object to Signature instance. Please see more details in >>> >>> https://bugs.openjdk.java.net/browse/JDK-8176183?focusedCommentId=14058876&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14058876 >>> >>> >>> >>> The following patch updates Chain.java (which is used by >>> SignedObjectChain.java) to use specified security provider for both key >>> generation and singing. >>> >>> I ran all tests which depend on Chain.java on all generic platforms, >>> they worked fine. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176183 >>> >>> Webrev: http://cr.openjdk.java.net/~asmotrak/8176183/webrev.00/ >>> >>> Artem >>> > From artem.smotrakov at oracle.com Thu Mar 9 02:07:10 2017 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Wed, 8 Mar 2017 18:07:10 -0800 Subject: [9] RFR: 8176183: sun/security/mscapi/SignedObjectChain.java fails on Windows In-Reply-To: <2ebd9994-e305-c6c2-d7b7-26f6970244ec@oracle.com> References: <4a8cc271-a538-7db3-15ce-a3b26814054e@oracle.com> <25015ed6-18c6-0b71-edb6-eaa59be42f81@oracle.com> <02a2ffbe-45ac-c107-255d-2a0f08c12b3f@oracle.com> <2ebd9994-e305-c6c2-d7b7-26f6970244ec@oracle.com> Message-ID: <5c21e43e-bc35-932d-8cdd-f3de98f400f9@oracle.com> Thank you Max for the review. This seems to be true that the actual provider may be selected when Signature.init() is called. At least, I see that Signature.engineInitSign() may call chooseProvider() method. http://hg.openjdk.java.net/jdk9/dev/jdk/file/a54e33fc0f2d/src/java.base/share/classes/java/security/Signature.java#l1197 Artem On 03/08/2017 05:57 PM, Weijun Wang wrote: > > > On 03/09/2017 09:55 AM, Artem Smotrakov wrote: >> Hi Max, >> >> I am not sure if SunMSCAPI has higher priority than SunJCE, SUN, etc on >> Windows. But this test is for SunMSCAPI provider, so we explicitly set >> this provider for Signature. > > OK. You fix is good then. > > What I was saying that even if SunMSCAPI is not the preferred > provider, after you call Signature.getInstance("SHA256withRSA") the > actual provider is not finally determined. When you call sig.init(key, > SIGN), it will choose key's provider as its own provider. > > At least this is how to I understand it. > > Thanks > Max > >> >> Artem >> >> >> On 03/08/2017 04:50 PM, Weijun Wang wrote: >>> I remember Signature is able to automatically switch to the correct >>> provider when its init(key) is called. Does this mean you don't need >>> to care about Signature.getInstance(alg,provider)? >>> >>> Thanks >>> Max >>> >>> On 03/09/2017 05:52 AM, Artem Smotrakov wrote: >>>> Hello, >>>> >>>> The test fails with "Key type not supported" error on Windows only >>>> with >>>> SunMSCAPI provider. It happens because the test passes an incompatible >>>> key object to Signature instance. Please see more details in >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8176183?focusedCommentId=14058876&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14058876 >>>> >>>> >>>> >>>> >>>> The following patch updates Chain.java (which is used by >>>> SignedObjectChain.java) to use specified security provider for both >>>> key >>>> generation and singing. >>>> >>>> I ran all tests which depend on Chain.java on all generic platforms, >>>> they worked fine. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176183 >>>> >>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8176183/webrev.00/ >>>> >>>> Artem >>>> >> From sean.mullan at oracle.com Thu Mar 9 17:03:51 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 9 Mar 2017 12:03:51 -0500 Subject: RFR 8176350: Usage constraints don't take effect when using PKIX In-Reply-To: References: <90c4f396-a4b7-c305-5c82-b981b3d28e1f@oracle.com> Message-ID: On 3/8/17 5:52 PM, Anthony Scarpino wrote: > Since Sean and you are asking similar questions, I'll answer it here. It > was to be consistent with by using the Debug class. If a change is made > to Debug to print elsewhere, what I have now is compatible. Sending it > to stderr is basically saying that Debug is a useless class and we > should just print System.err.println() instead. Good point, although there is already code that does that, see for example AccessController/AccessControlContext.java. If we did eventually move Debug to log somewhere else, it would not be that much effort to fix these few cases. I'm ok either way you decide. > As for why the stack trace is there, like I said in the comment, if > there is a situation that should or should not have been blocked, we > know what path it took. There are many methods that send data through > this code and having this debug info allows us to quickly find why it > happened instead of trying to recreating the situation. Other > constraints deny or allow all ops. This being usage-based, where SHA1 > could be blocked for one usage, but not for another on the same security > property need more detailed debugging, in my opinion. > > About the extra data, I don't believe it's that much more and there > isn't a way to find out the information that would be needed. The > situation of the problem may not be reproducible in our environment > because the user doesn't want to give up their certs or know their app > is performing that usage. If dumpStack() is less data than > printStackTrace(), I'm fine with switching as long as I get the same info. It's a little unusual to dump a stack in debug output (AccessController/AccessControlContext is the only case I know of), but if it is helpful for future diagnosis, then we should probably keep it. > It would be nice if there was a verbose option. We could turn off > AdaptiveX509Selector that prints every check in byte level detail which > overflows jtreg's buffer all the time :-) Please file a followon RFE to do that. --Sean > > Tony > > On 03/08/2017 01:42 PM, Xuelei Fan wrote: >> Looks fine to me except a minor comment. >> >> In the update of DisabledAlgorithmConstraints.java, the dumping of stack >> trace for every checking could increase the debug log size a lot. There >> is no verbose option for 'certpath' debug. What do you think if only >> dumping the log when the usage is not allowed? >> >> Xuelei >> >> On 3/8/2017 1:15 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I need a code review of this small change.. The PKIX path for usage >>> checking didn't pass the variant to the checkers because of a previous >>> needed check for plugins. >>> >>> http://cr.openjdk.java.net/~ascarpino/8176350/webrev/ >>> >>> thanks >>> >>> Tony > From anthony.scarpino at oracle.com Thu Mar 9 18:29:40 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 9 Mar 2017 10:29:40 -0800 Subject: RFR 8176350: Usage constraints don't take effect when using PKIX In-Reply-To: <90c4f396-a4b7-c305-5c82-b981b3d28e1f@oracle.com> References: <90c4f396-a4b7-c305-5c82-b981b3d28e1f@oracle.com> Message-ID: On 03/08/2017 01:15 PM, Anthony Scarpino wrote: > Hi, > > I need a code review of this small change.. The PKIX path for usage > checking didn't pass the variant to the checkers because of a previous > needed check for plugins. > > http://cr.openjdk.java.net/~ascarpino/8176350/webrev/ > > thanks > > Tony I've updated the webrev in-place with a change that Sean and I talked about.. This change is a code cleanup related to the bug with PKIX and plugins, not a behavior change. Tony From sean.mullan at oracle.com Thu Mar 9 22:38:48 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 9 Mar 2017 17:38:48 -0500 Subject: RFR 8176350: Usage constraints don't take effect when using PKIX In-Reply-To: References: <90c4f396-a4b7-c305-5c82-b981b3d28e1f@oracle.com> Message-ID: Looks good. Minor comment in PKIXCertPathValidator.java you can combine lines 193-194. --Sean On 3/9/17 1:29 PM, Anthony Scarpino wrote: > On 03/08/2017 01:15 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this small change.. The PKIX path for usage >> checking didn't pass the variant to the checkers because of a previous >> needed check for plugins. >> >> http://cr.openjdk.java.net/~ascarpino/8176350/webrev/ >> >> thanks >> >> Tony > > I've updated the webrev in-place with a change that Sean and I talked > about.. This change is a code cleanup related to the bug with PKIX and > plugins, not a behavior change. > > Tony > From weijun.wang at oracle.com Sat Mar 11 10:28:19 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 11 Mar 2017 18:28:19 +0800 Subject: RFR 8176542: Missing @Deprecated arguments for jdk.policytool Message-ID: <5953b2a9-e57a-471f-d957-6581bee7a7ae@oracle.com> Please take a review on the patch below. Notes: 1. The current javadoc output expands the arguments into sentences like "Deprecated, for removal: This API element is subject to removal in a future version." which means there is no need to duplicate the same words in the @deprecated javadoc comment. 2. I don't want to duplicate the @deprecated javadoc comment in PolicyTool.java into module-info.java, and it does not have text now. The javadoc command has not shown an error or a warning. Thanks Max diff --git a/src/jdk.policytool/share/classes/module-info.java b/src/jdk.policytool/share/classes/module-info.java --- a/src/jdk.policytool/share/classes/module-info.java +++ b/src/jdk.policytool/share/classes/module-info.java @@ -27,10 +27,9 @@ * GUI tool for managing policy files. * * @since 9 - * @deprecated The policytool tool has been deprecated and - * is planned to be removed in a future release. + * @deprecated */ - at Deprecated + at Deprecated(since="9", forRemoval=true) module jdk.policytool { requires java.desktop; requires java.logging; diff --git a/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java b/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java --- a/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java +++ b/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java @@ -65,11 +65,12 @@ * * @see java.security.Policy * @since 1.2 - * @deprecated The policytool tool has been deprecated and - * is planned to be removed in a future release. + * @deprecated {@code policytool} has been deprecated for removal because it + * is rarely used, and it provides little value over editing policy + * files using a text editor. */ - at Deprecated + at Deprecated(since="9", forRemoval=true) public class PolicyTool { // for i18n From sean.mullan at oracle.com Mon Mar 13 11:58:23 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Mar 2017 07:58:23 -0400 Subject: RFR 8176542: Missing @Deprecated arguments for jdk.policytool In-Reply-To: <5953b2a9-e57a-471f-d957-6581bee7a7ae@oracle.com> References: <5953b2a9-e57a-471f-d957-6581bee7a7ae@oracle.com> Message-ID: <95a8e66c-c313-87e6-bde4-520b2fd9ae1e@oracle.com> Looks fine. --Sean On 3/11/17 5:28 AM, Weijun Wang wrote: > Please take a review on the patch below. > > Notes: > > 1. The current javadoc output expands the arguments into sentences like > "Deprecated, for removal: This API element is subject to removal in a > future version." which means there is no need to duplicate the same > words in the @deprecated javadoc comment. > > 2. I don't want to duplicate the @deprecated javadoc comment in > PolicyTool.java into module-info.java, and it does not have text now. > The javadoc command has not shown an error or a warning. > > Thanks > Max > > diff --git a/src/jdk.policytool/share/classes/module-info.java > b/src/jdk.policytool/share/classes/module-info.java > --- a/src/jdk.policytool/share/classes/module-info.java > +++ b/src/jdk.policytool/share/classes/module-info.java > @@ -27,10 +27,9 @@ > * GUI tool for managing policy files. > * > * @since 9 > - * @deprecated The policytool tool has been deprecated and > - * is planned to be removed in a future release. > + * @deprecated > */ > - at Deprecated > + at Deprecated(since="9", forRemoval=true) > module jdk.policytool { > requires java.desktop; > requires java.logging; > diff --git > a/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java > b/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java > > --- > a/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java > > +++ > b/src/jdk.policytool/share/classes/sun/security/tools/policytool/PolicyTool.java > > @@ -65,11 +65,12 @@ > * > * @see java.security.Policy > * @since 1.2 > - * @deprecated The policytool tool has been deprecated and > - * is planned to be removed in a future release. > + * @deprecated {@code policytool} has been deprecated for removal > because it > + * is rarely used, and it provides little value over editing policy > + * files using a text editor. > */ > > - at Deprecated > + at Deprecated(since="9", forRemoval=true) > public class PolicyTool { > > // for i18n From sean.mullan at oracle.com Mon Mar 13 14:57:14 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 13 Mar 2017 10:57:14 -0400 Subject: RFR: JDK-8176503: Disable SHA-1 TLS Server Certificates Message-ID: Please review this configuration change to disable SHA-1 TLS server certificates by default in JDK 9. In order to be disabled, the certificates must chain back to trusted root certificate in the cacerts keystore that has a " [jdk]" attribute appended to their alias name. --Sean diff --git a/src/java.base/share/conf/security/java.security b/src/java.base/share/conf/security/java.security --- a/src/java.base/share/conf/security/java.security +++ b/src/java.base/share/conf/security/java.security @@ -598,8 +598,8 @@ # jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048 # # -jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \ - DSA keySize < 1024, EC keySize < 224 +jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ + RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 # # Algorithm restrictions for signed JAR files From vincent.x.ryan at oracle.com Mon Mar 13 15:52:15 2017 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 13 Mar 2017 15:52:15 +0000 Subject: RFR: JDK-8176503: Disable SHA-1 TLS Server Certificates In-Reply-To: References: Message-ID: That change looks fine to me. Thanks. > On 13 Mar 2017, at 14:57, Sean Mullan wrote: > > Please review this configuration change to disable SHA-1 TLS server certificates by default in JDK 9. In order to be disabled, the certificates must chain back to trusted root certificate in the cacerts keystore that has a " [jdk]" attribute appended to their alias name. > > --Sean > > diff --git a/src/java.base/share/conf/security/java.security b/src/java.base/share/conf/security/java.security > --- a/src/java.base/share/conf/security/java.security > +++ b/src/java.base/share/conf/security/java.security > @@ -598,8 +598,8 @@ > # jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048 > # > # > -jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \ > - DSA keySize < 1024, EC keySize < 224 > +jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ > + RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 > > # > # Algorithm restrictions for signed JAR files From valerie.peng at oracle.com Tue Mar 14 01:24:46 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 13 Mar 2017 18:24:46 -0700 Subject: [10] RFR 8175251: Failed to load RSA private key from pkcs12 Message-ID: Hi Sean, Can you please help reviewing the fix for JDK-8175251 "Failed to load RSA private key from pkcs12" Bug: https://bugs.openjdk.java.net/browse/JDK-8175251 Webrev: http://cr.openjdk.java.net/~valeriep/8175251/webrev.00/ Thanks, Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Mar 14 01:25:42 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 13 Mar 2017 18:25:42 -0700 Subject: [9] RFR 8175251: Failed to load RSA private key from pkcs12 In-Reply-To: References: Message-ID: <073e2de8-b27c-df16-c111-9051afb0be6a@oracle.com> Re-send with the correct release version. This fix is intended for JDK-9. Thanks, Valerie On 3/13/2017 6:24 PM, Valerie Peng wrote: > > Hi Sean, > > Can you please help reviewing the fix for JDK-8175251 "Failed to load > RSA private key from pkcs12" > Bug: https://bugs.openjdk.java.net/browse/JDK-8175251 > Webrev: http://cr.openjdk.java.net/~valeriep/8175251/webrev.00/ > > Thanks, > Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Mar 14 03:34:10 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Mar 2017 11:34:10 +0800 Subject: RFR 8176296: Test sun/security/krb5/auto/Basic.java faling after adding module declaration into TEST.properties. In-Reply-To: <8a85fe13-dfc8-9565-67bf-1a94319587cf@oracle.com> References: <8a85fe13-dfc8-9565-67bf-1a94319587cf@oracle.com> Message-ID: Ping again. On 03/07/2017 10:10 PM, Weijun Wang wrote: > Please review this changeset at > > http://cr.openjdk.java.net/~weijun/8176296/webrev.00/ > > It looks with jdk.security.jgss added into @modules in TEST.properties > (JDK-8176213), it cannot be excluded using --limit-modules. > > Therefore I split Basic.java into 2 and the new test has its own > @modules tag. > > In case you don't remember this test, it was about the Oracle JGSS-API > extension. If the jdk.security.jgss module is available, the GSSContext > implementation is ExtendedGSSContextImpl inside this module that can do > more than GSSContextImpl defined in java.security.jgss (which will be > returned when jdk.security.jgss is not available). > > Thanks > Max From weijun.wang at oracle.com Tue Mar 14 03:38:27 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Mar 2017 11:38:27 +0800 Subject: RFR 8176715: sun/security/krb5/auto/HttpNegotiateServer.java does not compile Message-ID: Please review the patch below: diff --git a/test/sun/security/krb5/auto/HttpNegotiateServer.java b/test/sun/security/krb5/auto/HttpNegotiateServer.java --- a/test/sun/security/krb5/auto/HttpNegotiateServer.java +++ b/test/sun/security/krb5/auto/HttpNegotiateServer.java @@ -28,6 +28,7 @@ * java.security.jgss/sun.security.krb5.internal:+open * java.security.jgss/sun.security.jgss * java.security.jgss/sun.security.krb5:+open + * java.security.jgss/sun.security.krb5.internal.ccache * java.security.jgss/sun.security.krb5.internal.crypto * java.security.jgss/sun.security.krb5.internal.ktab * jdk.security.auth This test uses KDC.java which references a class inside sun.security.krb5.internal.ccache. Other tests in the same directory do have this package in their @modules tag (in fact, they share the same in TEST.properties) so if any of them is executed earlier, KDC.class will be generated and this test can use it. However, if this test is executed first, the compile will fail. Thanks Max From amy.lu at oracle.com Tue Mar 14 03:41:34 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 14 Mar 2017 11:41:34 +0800 Subject: RFR 8176715: sun/security/krb5/auto/HttpNegotiateServer.java does not compile In-Reply-To: References: Message-ID: Looks good. (I'm not a reviewer) Thanks, Amy On 3/14/17 11:38 AM, Weijun Wang wrote: > Please review the patch below: > > diff --git a/test/sun/security/krb5/auto/HttpNegotiateServer.java > b/test/sun/security/krb5/auto/HttpNegotiateServer.java > --- a/test/sun/security/krb5/auto/HttpNegotiateServer.java > +++ b/test/sun/security/krb5/auto/HttpNegotiateServer.java > @@ -28,6 +28,7 @@ > * java.security.jgss/sun.security.krb5.internal:+open > * java.security.jgss/sun.security.jgss > * java.security.jgss/sun.security.krb5:+open > + * java.security.jgss/sun.security.krb5.internal.ccache > * java.security.jgss/sun.security.krb5.internal.crypto > * java.security.jgss/sun.security.krb5.internal.ktab > * jdk.security.auth > > This test uses KDC.java which references a class inside > sun.security.krb5.internal.ccache. Other tests in the same directory > do have this package in their @modules tag (in fact, they share the > same in TEST.properties) so if any of them is executed earlier, > KDC.class will be generated and this test can use it. However, if this > test is executed first, the compile will fail. > > Thanks > Max From amy.lu at oracle.com Tue Mar 14 04:02:07 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 14 Mar 2017 12:02:07 +0800 Subject: RFR 8176296: Test sun/security/krb5/auto/Basic.java faling after adding module declaration into TEST.properties. In-Reply-To: References: <8a85fe13-dfc8-9565-67bf-1a94319587cf@oracle.com> Message-ID: <14e562ba-5e7f-7348-cc11-d5da0f2be35b@oracle.com> I looked at the new test: BasicLimited.java This test will fail if "jdk.security.jgss" is specified from jtreg javaoptions: jtreg ... -javaoptions:"--limit-modules java.security.jgss,jdk.security.auth,jdk.security.jgss" jdk9/test/sun/security/krb5/auto/BasicLimited.java Thanks, Amy On 3/14/17 11:34 AM, Weijun Wang wrote: > Ping again. > > On 03/07/2017 10:10 PM, Weijun Wang wrote: >> Please review this changeset at >> >> http://cr.openjdk.java.net/~weijun/8176296/webrev.00/ >> >> It looks with jdk.security.jgss added into @modules in TEST.properties >> (JDK-8176213), it cannot be excluded using --limit-modules. >> >> Therefore I split Basic.java into 2 and the new test has its own >> @modules tag. >> >> In case you don't remember this test, it was about the Oracle JGSS-API >> extension. If the jdk.security.jgss module is available, the GSSContext >> implementation is ExtendedGSSContextImpl inside this module that can do >> more than GSSContextImpl defined in java.security.jgss (which will be >> returned when jdk.security.jgss is not available). >> >> Thanks >> Max From weijun.wang at oracle.com Tue Mar 14 07:37:48 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 14 Mar 2017 15:37:48 +0800 Subject: RFR 8176296: Test sun/security/krb5/auto/Basic.java faling after adding module declaration into TEST.properties. In-Reply-To: <14e562ba-5e7f-7348-cc11-d5da0f2be35b@oracle.com> References: <8a85fe13-dfc8-9565-67bf-1a94319587cf@oracle.com> <14e562ba-5e7f-7348-cc11-d5da0f2be35b@oracle.com> Message-ID: How can you launch jtreg like this? :-) Anyway, I've updated the webrev at http://cr.openjdk.java.net/~weijun/8176296/webrev.01 The test now creates the Java process itself so you won't be able to manipulate it from outside. Thanks Max On 03/14/2017 12:02 PM, Amy Lu wrote: > I looked at the new test: BasicLimited.java > This test will fail if "jdk.security.jgss" is specified from jtreg > javaoptions: > jtreg ... -javaoptions:"--limit-modules > java.security.jgss,jdk.security.auth,jdk.security.jgss" > jdk9/test/sun/security/krb5/auto/BasicLimited.java > > Thanks, > Amy > > On 3/14/17 11:34 AM, Weijun Wang wrote: >> Ping again. >> >> On 03/07/2017 10:10 PM, Weijun Wang wrote: >>> Please review this changeset at >>> >>> http://cr.openjdk.java.net/~weijun/8176296/webrev.00/ >>> >>> It looks with jdk.security.jgss added into @modules in TEST.properties >>> (JDK-8176213), it cannot be excluded using --limit-modules. >>> >>> Therefore I split Basic.java into 2 and the new test has its own >>> @modules tag. >>> >>> In case you don't remember this test, it was about the Oracle JGSS-API >>> extension. If the jdk.security.jgss module is available, the GSSContext >>> implementation is ExtendedGSSContextImpl inside this module that can do >>> more than GSSContextImpl defined in java.security.jgss (which will be >>> returned when jdk.security.jgss is not available). >>> >>> Thanks >>> Max > From amy.lu at oracle.com Tue Mar 14 08:24:54 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 14 Mar 2017 16:24:54 +0800 Subject: RFR 8176296: Test sun/security/krb5/auto/Basic.java faling after adding module declaration into TEST.properties. In-Reply-To: References: <8a85fe13-dfc8-9565-67bf-1a94319587cf@oracle.com> <14e562ba-5e7f-7348-cc11-d5da0f2be35b@oracle.com> Message-ID: Looks good.Thank you Max! (I'm not a reviewer) Thanks, Amy On 3/14/17 3:37 PM, Weijun Wang wrote: > How can you launch jtreg like this? :-) > > Anyway, I've updated the webrev at > > http://cr.openjdk.java.net/~weijun/8176296/webrev.01 > > The test now creates the Java process itself so you won't be able to > manipulate it from outside. > > Thanks > Max > > On 03/14/2017 12:02 PM, Amy Lu wrote: >> I looked at the new test: BasicLimited.java >> This test will fail if "jdk.security.jgss" is specified from jtreg >> javaoptions: >> jtreg ... -javaoptions:"--limit-modules >> java.security.jgss,jdk.security.auth,jdk.security.jgss" >> jdk9/test/sun/security/krb5/auto/BasicLimited.java >> >> Thanks, >> Amy >> >> On 3/14/17 11:34 AM, Weijun Wang wrote: >>> Ping again. >>> >>> On 03/07/2017 10:10 PM, Weijun Wang wrote: >>>> Please review this changeset at >>>> >>>> http://cr.openjdk.java.net/~weijun/8176296/webrev.00/ >>>> >>>> It looks with jdk.security.jgss added into @modules in TEST.properties >>>> (JDK-8176213), it cannot be excluded using --limit-modules. >>>> >>>> Therefore I split Basic.java into 2 and the new test has its own >>>> @modules tag. >>>> >>>> In case you don't remember this test, it was about the Oracle JGSS-API >>>> extension. If the jdk.security.jgss module is available, the >>>> GSSContext >>>> implementation is ExtendedGSSContextImpl inside this module that >>>> can do >>>> more than GSSContextImpl defined in java.security.jgss (which will be >>>> returned when jdk.security.jgss is not available). >>>> >>>> Thanks >>>> Max >> From sean.mullan at oracle.com Tue Mar 14 11:54:51 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Mar 2017 07:54:51 -0400 Subject: RFR 8176715: sun/security/krb5/auto/HttpNegotiateServer.java does not compile In-Reply-To: References: Message-ID: <68a6dfd8-ce23-5f63-69c7-03ca452a9774@oracle.com> Looks good. --Sean On 3/13/17 11:38 PM, Weijun Wang wrote: > Please review the patch below: > > diff --git a/test/sun/security/krb5/auto/HttpNegotiateServer.java > b/test/sun/security/krb5/auto/HttpNegotiateServer.java > --- a/test/sun/security/krb5/auto/HttpNegotiateServer.java > +++ b/test/sun/security/krb5/auto/HttpNegotiateServer.java > @@ -28,6 +28,7 @@ > * java.security.jgss/sun.security.krb5.internal:+open > * java.security.jgss/sun.security.jgss > * java.security.jgss/sun.security.krb5:+open > + * java.security.jgss/sun.security.krb5.internal.ccache > * java.security.jgss/sun.security.krb5.internal.crypto > * java.security.jgss/sun.security.krb5.internal.ktab > * jdk.security.auth > > This test uses KDC.java which references a class inside > sun.security.krb5.internal.ccache. Other tests in the same directory do > have this package in their @modules tag (in fact, they share the same in > TEST.properties) so if any of them is executed earlier, KDC.class will > be generated and this test can use it. However, if this test is executed > first, the compile will fail. > > Thanks > Max From sean.mullan at oracle.com Tue Mar 14 19:54:52 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 14 Mar 2017 15:54:52 -0400 Subject: [9] RFR 8175251: Failed to load RSA private key from pkcs12 In-Reply-To: <073e2de8-b27c-df16-c111-9051afb0be6a@oracle.com> References: <073e2de8-b27c-df16-c111-9051afb0be6a@oracle.com> Message-ID: The fix looks good. --Sean On 3/13/17 9:25 PM, Valerie Peng wrote: > > Re-send with the correct release version. This fix is intended for JDK-9. > Thanks, > Valerie > > On 3/13/2017 6:24 PM, Valerie Peng wrote: >> >> Hi Sean, >> >> Can you please help reviewing the fix for JDK-8175251 "Failed to load >> RSA private key from pkcs12" >> Bug: https://bugs.openjdk.java.net/browse/JDK-8175251 >> Webrev: http://cr.openjdk.java.net/~valeriep/8175251/webrev.00/ >> >> Thanks, >> Valerie > From valerie.peng at oracle.com Tue Mar 14 20:36:19 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 14 Mar 2017 13:36:19 -0700 Subject: RFR 8176296: Test sun/security/krb5/auto/Basic.java faling after adding module declaration into TEST.properties. In-Reply-To: References: <8a85fe13-dfc8-9565-67bf-1a94319587cf@oracle.com> <14e562ba-5e7f-7348-cc11-d5da0f2be35b@oracle.com> Message-ID: Looks fine. Thanks, Valerie On 3/14/2017 1:24 AM, Amy Lu wrote: > Looks good.Thank you Max! > > (I'm not a reviewer) > > Thanks, > Amy > > On 3/14/17 3:37 PM, Weijun Wang wrote: >> How can you launch jtreg like this? :-) >> >> Anyway, I've updated the webrev at >> >> http://cr.openjdk.java.net/~weijun/8176296/webrev.01 >> >> The test now creates the Java process itself so you won't be able to >> manipulate it from outside. >> >> Thanks >> Max >> >> On 03/14/2017 12:02 PM, Amy Lu wrote: >>> I looked at the new test: BasicLimited.java >>> This test will fail if "jdk.security.jgss" is specified from jtreg >>> javaoptions: >>> jtreg ... -javaoptions:"--limit-modules >>> java.security.jgss,jdk.security.auth,jdk.security.jgss" >>> jdk9/test/sun/security/krb5/auto/BasicLimited.java >>> >>> Thanks, >>> Amy >>> >>> On 3/14/17 11:34 AM, Weijun Wang wrote: >>>> Ping again. >>>> >>>> On 03/07/2017 10:10 PM, Weijun Wang wrote: >>>>> Please review this changeset at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8176296/webrev.00/ >>>>> >>>>> It looks with jdk.security.jgss added into @modules in >>>>> TEST.properties >>>>> (JDK-8176213), it cannot be excluded using --limit-modules. >>>>> >>>>> Therefore I split Basic.java into 2 and the new test has its own >>>>> @modules tag. >>>>> >>>>> In case you don't remember this test, it was about the Oracle >>>>> JGSS-API >>>>> extension. If the jdk.security.jgss module is available, the >>>>> GSSContext >>>>> implementation is ExtendedGSSContextImpl inside this module that >>>>> can do >>>>> more than GSSContextImpl defined in java.security.jgss (which will be >>>>> returned when jdk.security.jgss is not available). >>>>> >>>>> Thanks >>>>> Max >>> > From valerie.peng at oracle.com Wed Mar 15 19:35:31 2017 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 15 Mar 2017 12:35:31 -0700 Subject: [9] RFR 8175251: Failed to load RSA private key from pkcs12 In-Reply-To: References: <073e2de8-b27c-df16-c111-9051afb0be6a@oracle.com> Message-ID: <9264ed8b-791d-f832-77a7-3d8a4e90e823@oracle.com> Sean, I added a regression test and fixed a minor issue in existing regression test. Can you please take a look? http://cr.openjdk.java.net/~valeriep/8175251/webrev.01/ Thanks, Valerie On 3/14/2017 12:54 PM, Sean Mullan wrote: > The fix looks good. > > --Sean > > On 3/13/17 9:25 PM, Valerie Peng wrote: >> >> Re-send with the correct release version. This fix is intended for >> JDK-9. >> Thanks, >> Valerie >> >> On 3/13/2017 6:24 PM, Valerie Peng wrote: >>> >>> Hi Sean, >>> >>> Can you please help reviewing the fix for JDK-8175251 "Failed to load >>> RSA private key from pkcs12" >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175251 >>> Webrev: http://cr.openjdk.java.net/~valeriep/8175251/webrev.00/ >>> >>> Thanks, >>> Valerie >> From sean.mullan at oracle.com Wed Mar 15 20:18:05 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Mar 2017 16:18:05 -0400 Subject: [9] RFR 8175251: Failed to load RSA private key from pkcs12 In-Reply-To: <9264ed8b-791d-f832-77a7-3d8a4e90e823@oracle.com> References: <073e2de8-b27c-df16-c111-9051afb0be6a@oracle.com> <9264ed8b-791d-f832-77a7-3d8a4e90e823@oracle.com> Message-ID: Looks good. --Sean On 3/15/17 3:35 PM, Valerie Peng wrote: > Sean, > I added a regression test and fixed a minor issue in existing regression > test. > Can you please take a look? > http://cr.openjdk.java.net/~valeriep/8175251/webrev.01/ > > Thanks, > Valerie > > On 3/14/2017 12:54 PM, Sean Mullan wrote: >> The fix looks good. >> >> --Sean >> >> On 3/13/17 9:25 PM, Valerie Peng wrote: >>> >>> Re-send with the correct release version. This fix is intended for >>> JDK-9. >>> Thanks, >>> Valerie >>> >>> On 3/13/2017 6:24 PM, Valerie Peng wrote: >>>> >>>> Hi Sean, >>>> >>>> Can you please help reviewing the fix for JDK-8175251 "Failed to load >>>> RSA private key from pkcs12" >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175251 >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8175251/webrev.00/ >>>> >>>> Thanks, >>>> Valerie >>> > From anthony.scarpino at oracle.com Thu Mar 16 05:04:45 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 15 Mar 2017 22:04:45 -0700 Subject: RFR 8176536: Backport weak algorithms checking Message-ID: <818e7242-aaef-0a3e-a089-9b8c3f5d17c8@oracle.com> Hi, I need a review of this large backport of the weak algorithm checking code to jdk8. In mosts cases the changes are either identical or 95% of what is in jdk9, the below two files deviate the most from jdk9 because of other jdk9 features: src/share/classes/sun/security/ssl/SSLContextImpl.java src/share/classes/sun/security/validator/PKIXValidator.java http://cr.openjdk.java.net/~ascarpino/8176536/webrev/ thanks Tony From ecki at zusammenkunft.net Thu Mar 16 23:36:52 2017 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 17 Mar 2017 00:36:52 +0100 Subject: Generate Keypairs with strong prng provider (SHA1PRNG) Message-ID: Hello, as a general precaution I wanted to document key generation best practice. The SHA1PRNG with its small state and single 20 byte seed always is a bit questionable for generating long term keys. 160 bit entropy (as long as the SecureRandom instance is used only once) is not enough for larger RSA Keys or AES192 and 256. So I was looking for a solution which works on 8 and 9 and involves more seed/state than the SHA1PRNG. On Windows the Windows-PRNG and on Linux the NativePRNGs both look better in this regard. The SecureRandom.getInstanceStrong() automatially uses them. So while I think in the long run it might be better to wrap those generators with DRBG some more I think a minimum is to use the strong variant for key generation. I peeked into keytool to see whats best practice and I noticed it does unfortunately NOT use the strong variant or a DRBG configuration: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c95ebfceb394/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java#l150 Is it really acceptable for long term keys this way? (I guess no answer means no :) Would it be possible to bump the security level for keytool in 9? Gruss Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Mar 17 00:20:29 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 Mar 2017 08:20:29 +0800 Subject: Generate Keypairs with strong prng provider (SHA1PRNG) In-Reply-To: References: Message-ID: <3bfe3849-f649-a995-0e99-df3c4716d509@oracle.com> new SecureRandom() should not return SHA1PRNG on JDK 9. If NativePRNG is the preferred provider, it will be returned. Otherwise, DRBG will be used. DRBG is preferred to SHA1PRNG on every platform. Thanks Max On 03/17/2017 07:36 AM, Bernd wrote: > Hello, > > as a general precaution I wanted to document key generation best > practice. The SHA1PRNG with its small state and single 20 byte seed > always is a bit questionable for generating long term keys. 160 bit > entropy (as long as the SecureRandom instance is used only once) is not > enough for larger RSA Keys or AES192 and 256. > > So I was looking for a solution which works on 8 and 9 and involves more > seed/state than the SHA1PRNG. On Windows the Windows-PRNG and on Linux > the NativePRNGs both look better in this regard. The > SecureRandom.getInstanceStrong() automatially uses them. > > So while I think in the long run it might be better to wrap those > generators with DRBG some more I think a minimum is to use the strong > variant for key generation. I peeked into keytool to see whats best > practice and I noticed it does unfortunately NOT use the strong variant > or a DRBG configuration: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c95ebfceb394/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java#l150 > > Is it really acceptable for long term keys this way? (I guess no answer > means no :) > > Would it be possible to bump the security level for keytool in 9? > > Gruss > Bernd > From ecki at zusammenkunft.net Fri Mar 17 02:28:32 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 17 Mar 2017 02:28:32 +0000 Subject: Generate Keypairs with strong prng provider (SHA1PRNG) In-Reply-To: <3bfe3849-f649-a995-0e99-df3c4716d509@oracle.com> References: , <3bfe3849-f649-a995-0e99-df3c4716d509@oracle.com> Message-ID: Hello, yes on Java 8 the keytool will use SHA1PRNG (on Windows) and with Java 9 it will use DRBG(128,reseed_only). I guess both are not well suited for larger permanent keys (like Keytool is supposed to create). But agreed, the Java 9 default is less problematic. Hmm.. thinking out loud. maybe the concept of a strong PRNG does not match well with nonces and personalisation. With the addition of DRBG and the wide variety of parameters, is getInstanceStrong() rather obsolete in 9 or will it be used by the platform? Instead of trusting Windows CAPI it would be nice to have a DRBG reseeding from it as the default strong secure random. Then it would also be fit for use for key generation. Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: Weijun Wang Sent: Friday, March 17, 2017 1:20:29 AM To: Bernd; security-dev at openjdk.java.net Subject: Re: Generate Keypairs with strong prng provider (SHA1PRNG) new SecureRandom() should not return SHA1PRNG on JDK 9. If NativePRNG is the preferred provider, it will be returned. Otherwise, DRBG will be used. DRBG is preferred to SHA1PRNG on every platform. Thanks Max On 03/17/2017 07:36 AM, Bernd wrote: > Hello, > > as a general precaution I wanted to document key generation best > practice. The SHA1PRNG with its small state and single 20 byte seed > always is a bit questionable for generating long term keys. 160 bit > entropy (as long as the SecureRandom instance is used only once) is not > enough for larger RSA Keys or AES192 and 256. > > So I was looking for a solution which works on 8 and 9 and involves more > seed/state than the SHA1PRNG. On Windows the Windows-PRNG and on Linux > the NativePRNGs both look better in this regard. The > SecureRandom.getInstanceStrong() automatially uses them. > > So while I think in the long run it might be better to wrap those > generators with DRBG some more I think a minimum is to use the strong > variant for key generation. I peeked into keytool to see whats best > practice and I noticed it does unfortunately NOT use the strong variant > or a DRBG configuration: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c95ebfceb394/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java#l150 > > Is it really acceptable for long term keys this way? (I guess no answer > means no :) > > Would it be possible to bump the security level for keytool in 9? > > Gruss > Bernd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Mar 17 08:53:34 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 Mar 2017 16:53:34 +0800 Subject: Generate Keypairs with strong prng provider (SHA1PRNG) In-Reply-To: References: <3bfe3849-f649-a995-0e99-df3c4716d509@oracle.com> Message-ID: I agree. JDK 9 merely introduced DRBG as a replacement of SHA1PRNG and everything else is not touched. (You can see DRBG right before SHA1PRNG in the preference order with no other in between). We'll need to find out how to make use of it. In your previous mail, you mentioned "On Windows the Windows-PRNG and on Linux the NativePRNGs both look better". I believe they are also DRBGs initialized with a static strength. Is it also 128? Thanks Max On 03/17/2017 10:28 AM, Bernd Eckenfels wrote: > Hello, > > yes on Java 8 the keytool will use SHA1PRNG (on Windows) and with Java 9 > it will use DRBG(128,reseed_only). > > I guess both are not well suited for larger permanent keys (like Keytool > is supposed to create). But agreed, the Java 9 default is less problematic. > > Hmm.. thinking out loud. maybe the concept of a strong PRNG does not > match well with nonces and personalisation. With the addition of DRBG > and the wide variety of parameters, is getInstanceStrong() rather > obsolete in 9 or will it be used by the platform? > > Instead of trusting Windows CAPI it would be nice to have a DRBG > reseeding from it as the default strong secure random. Then it would > also be fit for use for key generation. > > Gruss > Bernd > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > ------------------------------------------------------------------------ > *From:* Weijun Wang > *Sent:* Friday, March 17, 2017 1:20:29 AM > *To:* Bernd; security-dev at openjdk.java.net > *Subject:* Re: Generate Keypairs with strong prng provider (SHA1PRNG) > > new SecureRandom() should not return SHA1PRNG on JDK 9. If NativePRNG is > the preferred provider, it will be returned. Otherwise, DRBG will be > used. DRBG is preferred to SHA1PRNG on every platform. > > Thanks > Max > > > On 03/17/2017 07:36 AM, Bernd wrote: >> Hello, >> >> as a general precaution I wanted to document key generation best >> practice. The SHA1PRNG with its small state and single 20 byte seed >> always is a bit questionable for generating long term keys. 160 bit >> entropy (as long as the SecureRandom instance is used only once) is not >> enough for larger RSA Keys or AES192 and 256. >> >> So I was looking for a solution which works on 8 and 9 and involves more >> seed/state than the SHA1PRNG. On Windows the Windows-PRNG and on Linux >> the NativePRNGs both look better in this regard. The >> SecureRandom.getInstanceStrong() automatially uses them. >> >> So while I think in the long run it might be better to wrap those >> generators with DRBG some more I think a minimum is to use the strong >> variant for key generation. I peeked into keytool to see whats best >> practice and I noticed it does unfortunately NOT use the strong variant >> or a DRBG configuration: >> >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c95ebfceb394/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java#l150 >> >> Is it really acceptable for long term keys this way? (I guess no answer >> means no :) >> >> Would it be possible to bump the security level for keytool in 9? >> >> Gruss >> Bernd >> From ecki at zusammenkunft.net Fri Mar 17 09:36:21 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 17 Mar 2017 09:36:21 +0000 Subject: Generate Keypairs with strong prng provider (SHA1PRNG) In-Reply-To: References: <3bfe3849-f649-a995-0e99-df3c4716d509@oracle.com> , Message-ID: Hello, The Windows-PNRG in 8 dispatches 1:1 to the old CAPI CryptGenRandom which is not well documented or configurable (unlike the CNG variant). I think MS switched from SHA1 to AES-CTR in Vista SP1 but the configuration settings of that DRBG are not published. It does however reseeding and shares the state with all user sessions (including additional input data) so that would be a plus compared to SHA1PRNG. (Haven't looked at NativeRandom & /dev/random in a while but the situation (sans doc) is similar) I think for 9 it would be good to use DRBG with 256bit security in over sampling mode (or xor, but I think technically that would be harder to proof that the source is full entropy according to 800-90c) on top of Windows-PRNG or Linux NativeRandom as the getInstanceStrong() and then use it for explicit key generation (in tools). (It is late, but isn't there some certification requirements in the queue for key generation anyway?) (And one can only dream of a 8 backport :) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: Weijun Wang Sent: Friday, March 17, 2017 9:53:34 AM To: Bernd Eckenfels; security-dev at openjdk.java.net Subject: Re: Generate Keypairs with strong prng provider (SHA1PRNG) I agree. JDK 9 merely introduced DRBG as a replacement of SHA1PRNG and everything else is not touched. (You can see DRBG right before SHA1PRNG in the preference order with no other in between). We'll need to find out how to make use of it. In your previous mail, you mentioned "On Windows the Windows-PRNG and on Linux the NativePRNGs both look better". I believe they are also DRBGs initialized with a static strength. Is it also 128? Thanks Max On 03/17/2017 10:28 AM, Bernd Eckenfels wrote: > Hello, > > yes on Java 8 the keytool will use SHA1PRNG (on Windows) and with Java 9 > it will use DRBG(128,reseed_only). > > I guess both are not well suited for larger permanent keys (like Keytool > is supposed to create). But agreed, the Java 9 default is less problematic. > > Hmm.. thinking out loud. maybe the concept of a strong PRNG does not > match well with nonces and personalisation. With the addition of DRBG > and the wide variety of parameters, is getInstanceStrong() rather > obsolete in 9 or will it be used by the platform? > > Instead of trusting Windows CAPI it would be nice to have a DRBG > reseeding from it as the default strong secure random. Then it would > also be fit for use for key generation. > > Gruss > Bernd > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > ------------------------------------------------------------------------ > *From:* Weijun Wang > *Sent:* Friday, March 17, 2017 1:20:29 AM > *To:* Bernd; security-dev at openjdk.java.net > *Subject:* Re: Generate Keypairs with strong prng provider (SHA1PRNG) > > new SecureRandom() should not return SHA1PRNG on JDK 9. If NativePRNG is > the preferred provider, it will be returned. Otherwise, DRBG will be > used. DRBG is preferred to SHA1PRNG on every platform. > > Thanks > Max > > > On 03/17/2017 07:36 AM, Bernd wrote: >> Hello, >> >> as a general precaution I wanted to document key generation best >> practice. The SHA1PRNG with its small state and single 20 byte seed >> always is a bit questionable for generating long term keys. 160 bit >> entropy (as long as the SecureRandom instance is used only once) is not >> enough for larger RSA Keys or AES192 and 256. >> >> So I was looking for a solution which works on 8 and 9 and involves more >> seed/state than the SHA1PRNG. On Windows the Windows-PRNG and on Linux >> the NativePRNGs both look better in this regard. The >> SecureRandom.getInstanceStrong() automatially uses them. >> >> So while I think in the long run it might be better to wrap those >> generators with DRBG some more I think a minimum is to use the strong >> variant for key generation. I peeked into keytool to see whats best >> practice and I noticed it does unfortunately NOT use the strong variant >> or a DRBG configuration: >> >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c95ebfceb394/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java#l150 >> >> Is it really acceptable for long term keys this way? (I guess no answer >> means no :) >> >> Would it be possible to bump the security level for keytool in 9? >> >> Gruss >> Bernd >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Mar 17 20:06:39 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 17 Mar 2017 16:06:39 -0400 Subject: RFR 8176536: Backport weak algorithms checking In-Reply-To: <818e7242-aaef-0a3e-a089-9b8c3f5d17c8@oracle.com> References: <818e7242-aaef-0a3e-a089-9b8c3f5d17c8@oracle.com> Message-ID: Looks good to me. Please also include the recent fix to disable SHA-1 TLS Server certificates in this backport: https://bugs.openjdk.java.net/browse/JDK-8176503 --Sean On 3/16/17 1:04 AM, Anthony Scarpino wrote: > Hi, > > I need a review of this large backport of the weak algorithm checking > code to jdk8. > > In mosts cases the changes are either identical or 95% of what is in > jdk9, the below two files deviate the most from jdk9 because of other > jdk9 features: > src/share/classes/sun/security/ssl/SSLContextImpl.java > src/share/classes/sun/security/validator/PKIXValidator.java > > http://cr.openjdk.java.net/~ascarpino/8176536/webrev/ > > thanks > > Tony From anthony.scarpino at oracle.com Fri Mar 17 20:25:52 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 17 Mar 2017 13:25:52 -0700 Subject: RFR 8176536: Backport weak algorithms checking In-Reply-To: References: <818e7242-aaef-0a3e-a089-9b8c3f5d17c8@oracle.com> Message-ID: <3132BA64-EE5A-47CE-B3FF-48D611D96090@oracle.com> Oh yeah. I had forgot to resync to get your change. Thanks for the reminder. Tony > On Mar 17, 2017, at 1:06 PM, Sean Mullan wrote: > > Looks good to me. Please also include the recent fix to disable SHA-1 TLS Server certificates in this backport: https://bugs.openjdk.java.net/browse/JDK-8176503 > > --Sean > >> On 3/16/17 1:04 AM, Anthony Scarpino wrote: >> Hi, >> >> I need a review of this large backport of the weak algorithm checking >> code to jdk8. >> >> In mosts cases the changes are either identical or 95% of what is in >> jdk9, the below two files deviate the most from jdk9 because of other >> jdk9 features: >> src/share/classes/sun/security/ssl/SSLContextImpl.java >> src/share/classes/sun/security/validator/PKIXValidator.java >> >> http://cr.openjdk.java.net/~ascarpino/8176536/webrev/ >> >> thanks >> >> Tony From weijun.wang at oracle.com Sun Mar 19 00:40:59 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 19 Mar 2017 08:40:59 +0800 Subject: RFR: Two krb5 release notes Message-ID: <58c39169-6784-5f20-0418-740251bae195@oracle.com> Please take a review on these 2 release notes: https://bugs.openjdk.java.net/browse/JDK-8177084 8029994: Support "include" and "includedir" in krb5.conf https://bugs.openjdk.java.net/browse/JDK-8177083 8036779: sun.security.krb5.KdcComm interprets kdc_timeout as msec instead of sec Both were integrated quite some time ago. Thanks Max From jamil.j.nimeh at oracle.com Sun Mar 19 05:28:54 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 18 Mar 2017 22:28:54 -0700 Subject: Review: Release note for JDK-8042967 In-Reply-To: <2020df53-eaff-205e-89c5-b5623f08a0ad@oracle.com> References: <2020df53-eaff-205e-89c5-b5623f08a0ad@oracle.com> Message-ID: <11a648aa-08cc-d8da-5398-027321c5e51d@oracle.com> --Resending on the open alias Hi guys, Can someone give me a review of this release note for an RFE that Jason put into JDK 9? Release note: https://bugs.openjdk.java.net/browse/JDK-8177080 RFE: https://bugs.openjdk.java.net/browse/JDK-8042967 Thanks! --Jamil From jamil.j.nimeh at oracle.com Sun Mar 19 05:37:02 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sat, 18 Mar 2017 22:37:02 -0700 Subject: RFR: Two krb5 release notes In-Reply-To: <58c39169-6784-5f20-0418-740251bae195@oracle.com> References: <58c39169-6784-5f20-0418-740251bae195@oracle.com> Message-ID: Hi Max, On 3/18/2017 5:40 PM, Weijun Wang wrote: > Please take a review on these 2 release notes: > > https://bugs.openjdk.java.net/browse/JDK-8177084 > 8029994: Support "include" and "includedir" in krb5.conf Only one minor suggestion: replace "say, " with "for example" or "e.g.". "say, " in this context sounds too colloquial for something more formal like a release note. > > https://bugs.openjdk.java.net/browse/JDK-8177083 > 8036779: sun.security.krb5.KdcComm interprets kdc_timeout as msec > instead of sec Again, only minor suggestions: * Replace "interop" with "interoperability" * Replace "Customers concerning on interop between..." with "Customers concerned about interoperability between..." > > Both were integrated quite some time ago. > > Thanks > Max Both look good to me otherwise. --Jamil From weijun.wang at oracle.com Sun Mar 19 07:30:10 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 19 Mar 2017 15:30:10 +0800 Subject: RFR: Two krb5 release notes In-Reply-To: References: <58c39169-6784-5f20-0418-740251bae195@oracle.com> Message-ID: <08fafb23-6b25-7df2-5a6b-00c645e64a8a@oracle.com> Thanks a lot. Both updated. --Max On 03/19/2017 01:37 PM, Jamil Nimeh wrote: > Hi Max, > > On 3/18/2017 5:40 PM, Weijun Wang wrote: >> Please take a review on these 2 release notes: >> >> https://bugs.openjdk.java.net/browse/JDK-8177084 >> 8029994: Support "include" and "includedir" in krb5.conf > Only one minor suggestion: replace "say, " with "for example" or > "e.g.". "say, " in this context sounds too colloquial for something > more formal like a release note. >> >> https://bugs.openjdk.java.net/browse/JDK-8177083 >> 8036779: sun.security.krb5.KdcComm interprets kdc_timeout as msec >> instead of sec > Again, only minor suggestions: > * Replace "interop" with "interoperability" > * Replace "Customers concerning on interop between..." with "Customers > concerned about interoperability between..." >> >> Both were integrated quite some time ago. >> >> Thanks >> Max > Both look good to me otherwise. > > --Jamil > From weijun.wang at oracle.com Sun Mar 19 08:35:26 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 19 Mar 2017 16:35:26 +0800 Subject: [10] RFR 8177085: Accept including .conf files in krb5.conf's includedir Message-ID: Please review the code change at http://cr.openjdk.java.net/~weijun/8177085/webrev.00/ This is to be consistent with MIT krb5 [1] "Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. Starting in release 1.15, files with names ending in ?.conf? are also included." New case added to test. Also some rename to make it clearer. Thanks Max [1] http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html From weijun.wang at oracle.com Sun Mar 19 10:39:23 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 19 Mar 2017 18:39:23 +0800 Subject: [10] RFR 8177085: Accept including .conf files in krb5.conf's includedir In-Reply-To: References: Message-ID: Kindly please also review the release note text at https://bugs.openjdk.java.net/browse/JDK-8177088 Thanks Max On 03/19/2017 04:35 PM, Weijun Wang wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8177085/webrev.00/ > > This is to be consistent with MIT krb5 [1] > > "Including a directory includes all files within the directory whose > names consist solely of alphanumeric characters, dashes, or underscores. > Starting in release 1.15, files with names ending in ?.conf? are also > included." > > New case added to test. Also some rename to make it clearer. > > Thanks > Max > > [1] > http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html From jamil.j.nimeh at oracle.com Sun Mar 19 15:41:54 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 19 Mar 2017 08:41:54 -0700 Subject: [10] RFR 8177085: Accept including .conf files in krb5.conf's includedir In-Reply-To: References: Message-ID: <6cbab59d-c79b-3c49-62c8-ce7bd1e0da8e@oracle.com> Hi Max, Do you know if the MIT krb5 code accepts any filename with the .conf extension? So filenames with spaces and periods with a .conf suffix are fine? I just wanted to make sure because your test code doesn't have any examples that would go outside the old alphanum, +, _, - set of characters (e.g. "foo.bar yak.config") but should otherwise be OK because it ends with .conf. If that's the desired behavior then that's fine, I was more curious than anything else. Maybe not a big deal because I think even "a.conf" would run down the same codepath as "foo.bar yak.config". Nit: Test code, line 110, looks like there are a couple spaces where you're chaining methods together that you don't do elsewhere in the code. Is that intentional? Otherwise looks good. Thanks, --Jamil On 3/19/2017 1:35 AM, Weijun Wang wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8177085/webrev.00/ > > This is to be consistent with MIT krb5 [1] > > "Including a directory includes all files within the directory whose > names consist solely of alphanumeric characters, dashes, or > underscores. Starting in release 1.15, files with names ending in > ?.conf? are also included." > > New case added to test. Also some rename to make it clearer. > > Thanks > Max > > [1] > http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html From sean.mullan at oracle.com Mon Mar 20 12:49:48 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 20 Mar 2017 08:49:48 -0400 Subject: Review: Release note for JDK-8042967 In-Reply-To: <11a648aa-08cc-d8da-5398-027321c5e51d@oracle.com> References: <2020df53-eaff-205e-89c5-b5623f08a0ad@oracle.com> <11a648aa-08cc-d8da-5398-027321c5e51d@oracle.com> Message-ID: <1b72ecf8-ed41-e27e-29d6-5fffc1cc23dc@oracle.com> Can you also add NONEwithDSAinP1363Format and NONEwithECDSAinP1363Format? Looks good otherwise. --Sean On 3/19/17 1:28 AM, Jamil Nimeh wrote: > --Resending on the open alias > > Hi guys, > > Can someone give me a review of this release note for an RFE that Jason > put into JDK 9? > > Release note: https://bugs.openjdk.java.net/browse/JDK-8177080 > RFE: https://bugs.openjdk.java.net/browse/JDK-8042967 > > Thanks! > --Jamil > From jamil.j.nimeh at oracle.com Mon Mar 20 13:41:01 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 20 Mar 2017 06:41:01 -0700 Subject: Review: Release note for JDK-8042967 In-Reply-To: <1b72ecf8-ed41-e27e-29d6-5fffc1cc23dc@oracle.com> References: <2020df53-eaff-205e-89c5-b5623f08a0ad@oracle.com> <11a648aa-08cc-d8da-5398-027321c5e51d@oracle.com> <1b72ecf8-ed41-e27e-29d6-5fffc1cc23dc@oracle.com> Message-ID: <24839c63-2438-9f0a-41f3-34e708d11d14@oracle.com> You got it. Thank you for the review. --Jamil On 3/20/2017 5:49 AM, Sean Mullan wrote: > Can you also add NONEwithDSAinP1363Format and > NONEwithECDSAinP1363Format? Looks good otherwise. > > --Sean > > On 3/19/17 1:28 AM, Jamil Nimeh wrote: >> --Resending on the open alias >> >> Hi guys, >> >> Can someone give me a review of this release note for an RFE that Jason >> put into JDK 9? >> >> Release note: https://bugs.openjdk.java.net/browse/JDK-8177080 >> RFE: https://bugs.openjdk.java.net/browse/JDK-8042967 >> >> Thanks! >> --Jamil >> From xuelei.fan at oracle.com Mon Mar 20 16:23:49 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 20 Mar 2017 09:23:49 -0700 Subject: Release Note Review JDK-8028518: Increase the priorities of GCM cipher suites Message-ID: Hi, Please review the release note of JDK-8028518, "Increase the priorities of GCM cipher suites". Release note: https://bugs.openjdk.java.net/browse/JDK-8177143 RFE: https://bugs.openjdk.java.net/browse/JDK-8028518 Thanks, Xuelei From bradford.wetmore at oracle.com Mon Mar 20 17:44:13 2017 From: bradford.wetmore at oracle.com (Brad R. Wetmore) Date: Mon, 20 Mar 2017 10:44:13 -0700 Subject: Release Note Review JDK-8028518: Increase the priorities of GCM cipher suites In-Reply-To: References: Message-ID: There's some minor English adjustments that could be made. In TLS protocols, cipher suite specifies the cryptography algorithms used in TLS connections. The priorities of cipher suites define the preference order that a cipher suite may be used in a TLS connection. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. -> In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider. In the SunJSSE provider, the following cipher suites are move to the head of default enabled cipher suite list: -> In the SunJSSE provider, the following ciphersuites are now the most preferred by default: SunJSSE provider in JDK -> SunJSSE provider in the Oracle JRE There is no guarantee the cipher suites priorities to remain the same in future updates or releases. -> There is no guarantee the cipher suites priorities will remain the same in future updates or releases. Have you worked with docs to update the Oracle Providers list? 9-ea/technotes/guides/security/SunProviders.html#SunJSSEProvider It looks like the current docs (downloaded on Friday) is out of date. Brad On 3/20/2017 9:23 AM, Xuelei Fan wrote: > Hi, > > Please review the release note of JDK-8028518, "Increase the priorities > of GCM cipher suites". > > Release note: https://bugs.openjdk.java.net/browse/JDK-8177143 > RFE: https://bugs.openjdk.java.net/browse/JDK-8028518 > > Thanks, > Xuelei From xuelei.fan at oracle.com Mon Mar 20 17:53:27 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 20 Mar 2017 10:53:27 -0700 Subject: Release Note Review JDK-8028518: Increase the priorities of GCM cipher suites In-Reply-To: References: Message-ID: <0cad2a88-e70b-fe90-ed05-f120bde38a90@oracle.com> Thanks for the comments! The release note bug entry is updated accordingly. > 9-ea/technotes/guides/security/SunProviders.html#SunJSSEProvider The doc update is under review. Xuelei On 3/20/2017 10:44 AM, Brad R. Wetmore wrote: > There's some minor English adjustments that could be made. > > In TLS protocols, cipher suite specifies the cryptography algorithms > used in TLS connections. The priorities of cipher suites define the > preference order that a cipher suite may be used in a TLS connection. In > this update, GCM-based cipher suites are configured as the most > preferable default cipher suites in the SunJSSE provider. > -> > In TLS, a ciphersuite defines a specific set of cryptography algorithms > used in a TLS connection. JSSE maintains a prioritized list of > ciphersuites. In this update, GCM-based cipher suites are configured as > the most preferable default cipher suites in the SunJSSE provider. > > In the SunJSSE provider, the following cipher suites are move to the > head of default enabled cipher suite list: > -> > In the SunJSSE provider, the following ciphersuites are now the most > preferred by default: > > SunJSSE provider in JDK > -> > SunJSSE provider in the Oracle JRE > > There is no guarantee the cipher suites priorities to remain the same in > future updates or releases. > -> > There is no guarantee the cipher suites priorities will remain the same > in future updates or releases. > > > Have you worked with docs to update the Oracle Providers list? > > 9-ea/technotes/guides/security/SunProviders.html#SunJSSEProvider > > It looks like the current docs (downloaded on Friday) is out of date. > > Brad > > > > > On 3/20/2017 9:23 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the release note of JDK-8028518, "Increase the priorities >> of GCM cipher suites". >> >> Release note: https://bugs.openjdk.java.net/browse/JDK-8177143 >> RFE: https://bugs.openjdk.java.net/browse/JDK-8028518 >> >> Thanks, >> Xuelei From jamil.j.nimeh at oracle.com Mon Mar 20 18:00:23 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 20 Mar 2017 11:00:23 -0700 Subject: Release Note Review JDK-8028518: Increase the priorities of GCM cipher suites In-Reply-To: References: Message-ID: Hi Xuelei, I only have two very minor adjustments: * First paragraph, "...specific set of cryptography algorithms..." --> "...specific set of cryptographic algorithms..." * Last paragraph, "...the cipher suites priorities...." --> "...the cipher suite priorities..." --Jamil On 3/20/2017 9:23 AM, Xuelei Fan wrote: > Hi, > > Please review the release note of JDK-8028518, "Increase the > priorities of GCM cipher suites". > > Release note: https://bugs.openjdk.java.net/browse/JDK-8177143 > RFE: https://bugs.openjdk.java.net/browse/JDK-8028518 > > Thanks, > Xuelei -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Mon Mar 20 21:02:14 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 20 Mar 2017 14:02:14 -0700 Subject: RFR 8176536: Backport weak algorithms checking In-Reply-To: <3132BA64-EE5A-47CE-B3FF-48D611D96090@oracle.com> References: <818e7242-aaef-0a3e-a089-9b8c3f5d17c8@oracle.com> <3132BA64-EE5A-47CE-B3FF-48D611D96090@oracle.com> Message-ID: Hi Sean, I updated the webrev with your recent change. One you ok this, I'll request approval for backport. http://cr.openjdk.java.net/~ascarpino/8176536/webrev.01/ thanks Tony On 03/17/2017 01:25 PM, Anthony Scarpino wrote: > Oh yeah. I had forgot to resync to get your change. Thanks for the reminder. > > Tony > >> On Mar 17, 2017, at 1:06 PM, Sean Mullan wrote: >> >> Looks good to me. Please also include the recent fix to disable SHA-1 TLS Server certificates in this backport: https://bugs.openjdk.java.net/browse/JDK-8176503 >> >> --Sean >> >>> On 3/16/17 1:04 AM, Anthony Scarpino wrote: >>> Hi, >>> >>> I need a review of this large backport of the weak algorithm checking >>> code to jdk8. >>> >>> In mosts cases the changes are either identical or 95% of what is in >>> jdk9, the below two files deviate the most from jdk9 because of other >>> jdk9 features: >>> src/share/classes/sun/security/ssl/SSLContextImpl.java >>> src/share/classes/sun/security/validator/PKIXValidator.java >>> >>> http://cr.openjdk.java.net/~ascarpino/8176536/webrev/ >>> >>> thanks >>> >>> Tony > From weijun.wang at oracle.com Tue Mar 21 02:01:17 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Mar 2017 10:01:17 +0800 Subject: RFR 8177291: [doc] weak algorithms and crypto policy in JGSS docs Message-ID: <7ad916de-d962-9b02-885f-684d1b223106@oracle.com> This is not exactly a code review, I'd like you to review my suggested changes on the JGSS guides in https://bugs.openjdk.java.net/browse/JDK-8177291 If everything is OK, I can pass it to the doc writer. Thanks Max From weijun.wang at oracle.com Tue Mar 21 02:18:05 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Mar 2017 10:18:05 +0800 Subject: [10] RFR 8177085: Accept including .conf files in krb5.conf's includedir In-Reply-To: <6cbab59d-c79b-3c49-62c8-ce7bd1e0da8e@oracle.com> References: <6cbab59d-c79b-3c49-62c8-ce7bd1e0da8e@oracle.com> Message-ID: <21b728dd-0ab9-56ec-06c9-fcad98ff2ffe@oracle.com> On 03/19/2017 11:41 PM, Jamil Nimeh wrote: > Hi Max, > > Do you know if the MIT krb5 code accepts any filename with the .conf > extension? So filenames with spaces and periods with a .conf suffix are > fine? I just wanted to make sure because your test code doesn't have > any examples that would go outside the old alphanum, +, _, - set of > characters (e.g. "foo.bar yak.config") but should otherwise be OK > because it ends with .conf. If that's the desired behavior then that's > fine, I was more curious than anything else. Maybe not a big deal > because I think even "a.conf" would run down the same codepath as > "foo.bar yak.config". The MIT krb5 code has if (len >= 5 && !strcmp(filename + len - 5, ".conf")) return 1; So even a bare ".conf" is allowed. My understanding of the old rule is to exclude OS-generated files like .DS_Store and desktop.ini. Do you know of any possibilities that a "*.conf" file will be generated this way? As for the test, we can say "k4.conf" already contains "." which was not allowed before. > > Nit: Test code, line 110, looks like there are a couple spaces where > you're chaining methods together that you don't do elsewhere in the > code. Is that intentional? No. I cannot remember where the spaces come from. Maybe after breaking and joining lines in vi? Thanks Max > > Otherwise looks good. > > Thanks, > --Jamil > > On 3/19/2017 1:35 AM, Weijun Wang wrote: >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8177085/webrev.00/ >> >> This is to be consistent with MIT krb5 [1] >> >> "Including a directory includes all files within the directory whose >> names consist solely of alphanumeric characters, dashes, or >> underscores. Starting in release 1.15, files with names ending in >> ?.conf? are also included." >> >> New case added to test. Also some rename to make it clearer. >> >> Thanks >> Max >> >> [1] >> http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html >> > From sergei.kovalev at oracle.com Tue Mar 21 10:44:13 2017 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 21 Mar 2017 13:44:13 +0300 Subject: RFR(s): 8177324: Some javax/security/ tests don't have correct module dependencies Message-ID: Hi team, Please review below small fix for security tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8177324 Review: http://cr.openjdk.java.net/~skovalev/8177324/webrev.00 Issue: missed dependency declaration in some security tests. -- With best regards, Sergei From weijun.wang at oracle.com Tue Mar 21 10:54:45 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Mar 2017 18:54:45 +0800 Subject: RFR(s): 8177324: Some javax/security/ tests don't have correct module dependencies In-Reply-To: References: Message-ID: <43dcc71c-2cb6-a79d-de43-0e376fe121cb@oracle.com> The change looks good. Thanks Max On 03/21/2017 06:44 PM, Sergei Kovalev wrote: > Hi team, > > Please review below small fix for security tests. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8177324 > Review: http://cr.openjdk.java.net/~skovalev/8177324/webrev.00 > > Issue: missed dependency declaration in some security tests. > From jamil.j.nimeh at oracle.com Tue Mar 21 15:03:11 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 21 Mar 2017 08:03:11 -0700 Subject: [10] RFR 8177085: Accept including .conf files in krb5.conf's includedir In-Reply-To: <21b728dd-0ab9-56ec-06c9-fcad98ff2ffe@oracle.com> References: <6cbab59d-c79b-3c49-62c8-ce7bd1e0da8e@oracle.com> <21b728dd-0ab9-56ec-06c9-fcad98ff2ffe@oracle.com> Message-ID: Hi Max, On 3/20/2017 7:18 PM, Weijun Wang wrote: > > > On 03/19/2017 11:41 PM, Jamil Nimeh wrote: >> Hi Max, >> >> Do you know if the MIT krb5 code accepts any filename with the .conf >> extension? So filenames with spaces and periods with a .conf suffix are >> fine? I just wanted to make sure because your test code doesn't have >> any examples that would go outside the old alphanum, +, _, - set of >> characters (e.g. "foo.bar yak.config") but should otherwise be OK >> because it ends with .conf. If that's the desired behavior then that's >> fine, I was more curious than anything else. Maybe not a big deal >> because I think even "a.conf" would run down the same codepath as >> "foo.bar yak.config". > > The MIT krb5 code has > > if (len >= 5 && !strcmp(filename + len - 5, ".conf")) > return 1; > > So even a bare ".conf" is allowed. My understanding of the old rule is > to exclude OS-generated files like .DS_Store and desktop.ini. Do you > know of any possibilities that a "*.conf" file will be generated this > way? Honestly, I can't. I could see a sysadmin maybe moving a file like foo.conf maybe to .foo.conf in order to "hide" it, but that wouldn't do much now (it will still be processed) and now you have a situation where the admin has a file being processed that doesn't readily show up in a simple "ls." Point gun at foot, pull trigger. I don't have a lot of experience with Kerberos implementations, so I can't think of a case where the OS would do something like that. At least not for a system-level config file. Maybe if there was a homedir-based conf file...sometimes those are made as dot files (e.g. the local .ssh directory...but that's a directory with non-hidden conf files inside). Since you're consistent with the MIT stuff, it looks good to me. I was just curious more than anything else. > > As for the test, we can say "k4.conf" already contains "." which was > not allowed before. > >> >> Nit: Test code, line 110, looks like there are a couple spaces where >> you're chaining methods together that you don't do elsewhere in the >> code. Is that intentional? > > No. I cannot remember where the spaces come from. Maybe after breaking > and joining lines in vi? Sounds like a likely explanation to me. > > Thanks > Max > >> >> Otherwise looks good. >> >> Thanks, >> --Jamil >> >> On 3/19/2017 1:35 AM, Weijun Wang wrote: >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/8177085/webrev.00/ >>> >>> This is to be consistent with MIT krb5 [1] >>> >>> "Including a directory includes all files within the directory whose >>> names consist solely of alphanumeric characters, dashes, or >>> underscores. Starting in release 1.15, files with names ending in >>> ?.conf? are also included." >>> >>> New case added to test. Also some rename to make it clearer. >>> >>> Thanks >>> Max >>> >>> [1] >>> http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html >>> >>> >> From weijun.wang at oracle.com Tue Mar 21 15:13:30 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Mar 2017 23:13:30 +0800 Subject: [10] RFR 8177085: Accept including .conf files in krb5.conf's includedir In-Reply-To: References: <6cbab59d-c79b-3c49-62c8-ce7bd1e0da8e@oracle.com> <21b728dd-0ab9-56ec-06c9-fcad98ff2ffe@oracle.com> Message-ID: On 03/21/2017 11:03 PM, Jamil Nimeh wrote: > Honestly, I can't. I could see a sysadmin maybe moving a file like > foo.conf maybe to .foo.conf in order to "hide" it, but that wouldn't do > much now (it will still be processed) and now you have a situation where > the admin has a file being processed that doesn't readily show up in a > simple "ls." Point gun at foot, pull trigger. Hopefully this won't happen. Before supporting .conf, his old foo.conf was not processed. So he might have never written that file. > I don't have a lot of > experience with Kerberos implementations, No, I am not asking for Kerberos experiences. Just want to know if people would accidentally create these files. For example, vi will create .swp. I remember inserting a FAT USB disk into a Mac and some mysterious files will be generated (alternative streams of resources?) that is "._" plus original file names. Maybe I can report this to MIT krb5 and ask if they are afraid of it. > so I can't think of a case > where the OS would do something like that. At least not for a > system-level config file. Maybe if there was a homedir-based conf > file...sometimes those are made as dot files (e.g. the local .ssh > directory...but that's a directory with non-hidden conf files inside). Thanks Max From sean.mullan at oracle.com Tue Mar 21 16:01:04 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 21 Mar 2017 12:01:04 -0400 Subject: RFR 8176536: Backport weak algorithms checking In-Reply-To: References: <818e7242-aaef-0a3e-a089-9b8c3f5d17c8@oracle.com> <3132BA64-EE5A-47CE-B3FF-48D611D96090@oracle.com> Message-ID: Looks good. Thanks, Sean On 3/20/17 5:02 PM, Anthony Scarpino wrote: > Hi Sean, > > I updated the webrev with your recent change. One you ok this, I'll > request approval for backport. > > http://cr.openjdk.java.net/~ascarpino/8176536/webrev.01/ > > thanks > > Tony > > > On 03/17/2017 01:25 PM, Anthony Scarpino wrote: >> Oh yeah. I had forgot to resync to get your change. Thanks for the >> reminder. >> >> Tony >> >>> On Mar 17, 2017, at 1:06 PM, Sean Mullan wrote: >>> >>> Looks good to me. Please also include the recent fix to disable SHA-1 >>> TLS Server certificates in this backport: >>> https://bugs.openjdk.java.net/browse/JDK-8176503 >>> >>> --Sean >>> >>>> On 3/16/17 1:04 AM, Anthony Scarpino wrote: >>>> Hi, >>>> >>>> I need a review of this large backport of the weak algorithm checking >>>> code to jdk8. >>>> >>>> In mosts cases the changes are either identical or 95% of what is in >>>> jdk9, the below two files deviate the most from jdk9 because of other >>>> jdk9 features: >>>> src/share/classes/sun/security/ssl/SSLContextImpl.java >>>> src/share/classes/sun/security/validator/PKIXValidator.java >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8176536/webrev/ >>>> >>>> thanks >>>> >>>> Tony >> > From weijun.wang at oracle.com Wed Mar 22 00:53:39 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Mar 2017 08:53:39 +0800 Subject: [10] RFR 8177085: Accept including .conf files in krb5.conf's includedir In-Reply-To: References: <6cbab59d-c79b-3c49-62c8-ce7bd1e0da8e@oracle.com> <21b728dd-0ab9-56ec-06c9-fcad98ff2ffe@oracle.com> Message-ID: On 03/21/2017 11:13 PM, Weijun Wang wrote: > Maybe I can report this to MIT > krb5 and ask if they are afraid of it. See http://mailman.mit.edu/pipermail/krbdev/2017-March/012744.html. Do you suggest we exclude files starting with a dot now? Or we wait until MIT krb5 implements it first? Thanks Max From jamil.j.nimeh at oracle.com Wed Mar 22 03:48:22 2017 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 21 Mar 2017 20:48:22 -0700 Subject: [10] RFR 8177085: Accept including .conf files in krb5.conf's includedir In-Reply-To: References: <6cbab59d-c79b-3c49-62c8-ce7bd1e0da8e@oracle.com> <21b728dd-0ab9-56ec-06c9-fcad98ff2ffe@oracle.com> Message-ID: On 3/21/2017 5:53 PM, Weijun Wang wrote: > > > On 03/21/2017 11:13 PM, Weijun Wang wrote: >> Maybe I can report this to MIT >> krb5 and ask if they are afraid of it. > > See http://mailman.mit.edu/pipermail/krbdev/2017-March/012744.html. > > Do you suggest we exclude files starting with a dot now? Or we wait > until MIT krb5 implements it first? > > Thanks > Max > I'm a bit on the fence on this one. My gut says wait until the MIT krb5 implementation does it so we remain consistent with their implementation as it is currently. We could take the initiative given the email, however, if there's a bug/rfe that's actively being worked by the MIT krb5 guys on their end. --Jamil From weijun.wang at oracle.com Wed Mar 22 06:47:31 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Mar 2017 14:47:31 +0800 Subject: [10] RFR 8177085: Accept including .conf files in krb5.conf's includedir In-Reply-To: References: <6cbab59d-c79b-3c49-62c8-ce7bd1e0da8e@oracle.com> <21b728dd-0ab9-56ec-06c9-fcad98ff2ffe@oracle.com> Message-ID: Good, and I can push my current changeset now. Thanks Max On 03/22/2017 11:48 AM, Jamil Nimeh wrote: > > On 3/21/2017 5:53 PM, Weijun Wang wrote: >> >> >> On 03/21/2017 11:13 PM, Weijun Wang wrote: >>> Maybe I can report this to MIT >>> krb5 and ask if they are afraid of it. >> >> See http://mailman.mit.edu/pipermail/krbdev/2017-March/012744.html. >> >> Do you suggest we exclude files starting with a dot now? Or we wait >> until MIT krb5 implements it first? >> >> Thanks >> Max >> > I'm a bit on the fence on this one. My gut says wait until the MIT krb5 > implementation does it so we remain consistent with their implementation > as it is currently. We could take the initiative given the email, > however, if there's a bug/rfe that's actively being worked by the MIT > krb5 guys on their end. > > --Jamil > From weijun.wang at oracle.com Fri Mar 24 01:12:01 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 24 Mar 2017 09:12:01 +0800 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc Message-ID: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> Hi All Please take a review on 3 release notes. The content itself is pasted as quotation below. https://bugs.openjdk.java.net/browse/JDK-8176087 keytool now prints warnings when reading or generating cert/cert req using weak algorithms > In all keytool functions, if the certificate/certificate request/CRL > that is working on (whether it be the input, the output, or an > existing object) is using a weak algorithm or key, a warning will be > printed out. > > Precisely, an algorithm or a key is weak if it matches the value of > the jdk.certpath.disabledAlgorithms security property defined in > conf/security/java.security. https://bugs.openjdk.java.net/browse/JDK-8174143 Deprecate security APIs that have been superseded > The classes and interfaces in the `java.security.acl` and > `javax.security.cert` packages have been superseded by replacements > for a long time and are deprecated in JDK 9. Two methods > `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and > `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also > deprecated since they return the > `javax.security.cert.X509Certificate` type. https://bugs.openjdk.java.net/browse/JDK-8168635 rcache interop with krb5-1.15 > The hash algorithm used in the Kerberos 5 replay cache file (rcache) > is updated from MD5 to SHA256 with this change. This is also the > algorithm used by MIT krb5-1.15. This change is interoperable with > earlier releases of MIT krb5, which means Kerberos 5 acceptors from > JDK 9 and MIT krb5-1.14 can share the same rcache file. > > A new system property named jdk.krb5.rcache.useMD5 is introduced. If > the system property is set to "true", JDK 9 will still use the MD5 > hash algorithm in rcache. This is useful when both of the following > conditions are true: 1) the system has a very coarse clock and has to > depend on hash values in replay attack detection, and 2) > interoperability with earlier versions of JDK or MIT krb5 for rcache > files is required. The default value of this system property is > "false". Thanks Max From ecki at zusammenkunft.net Fri Mar 24 10:26:31 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 24 Mar 2017 10:26:31 +0000 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc In-Reply-To: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> References: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> Message-ID: I wonder if "weak key" should be replaced by "weak key length" or "short key". It might otherwise imply key quality tests which are not carried out. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: security-dev on behalf of Weijun Wang Sent: Friday, March 24, 2017 2:12:01 AM To: Security Dev OpenJDK Subject: RFR: 3 security-libs release notes on keytool/krb5/etc Hi All Please take a review on 3 release notes. The content itself is pasted as quotation below. https://bugs.openjdk.java.net/browse/JDK-8176087 keytool now prints warnings when reading or generating cert/cert req using weak algorithms > In all keytool functions, if the certificate/certificate request/CRL > that is working on (whether it be the input, the output, or an > existing object) is using a weak algorithm or key, a warning will be > printed out. > > Precisely, an algorithm or a key is weak if it matches the value of > the jdk.certpath.disabledAlgorithms security property defined in > conf/security/java.security. https://bugs.openjdk.java.net/browse/JDK-8174143 Deprecate security APIs that have been superseded > The classes and interfaces in the `java.security.acl` and > `javax.security.cert` packages have been superseded by replacements > for a long time and are deprecated in JDK 9. Two methods > `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and > `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also > deprecated since they return the > `javax.security.cert.X509Certificate` type. https://bugs.openjdk.java.net/browse/JDK-8168635 rcache interop with krb5-1.15 > The hash algorithm used in the Kerberos 5 replay cache file (rcache) > is updated from MD5 to SHA256 with this change. This is also the > algorithm used by MIT krb5-1.15. This change is interoperable with > earlier releases of MIT krb5, which means Kerberos 5 acceptors from > JDK 9 and MIT krb5-1.14 can share the same rcache file. > > A new system property named jdk.krb5.rcache.useMD5 is introduced. If > the system property is set to "true", JDK 9 will still use the MD5 > hash algorithm in rcache. This is useful when both of the following > conditions are true: 1) the system has a very coarse clock and has to > depend on hash values in replay attack detection, and 2) > interoperability with earlier versions of JDK or MIT krb5 for rcache > files is required. The default value of this system property is > "false". Thanks Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Mar 24 11:01:20 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 24 Mar 2017 19:01:20 +0800 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc In-Reply-To: References: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> Message-ID: <1ba9b353-4ba6-289e-e013-528a34aff992@oracle.com> I'll use "short key". Thanks Max On 03/24/2017 06:26 PM, Bernd Eckenfels wrote: > I wonder if "weak key" should be replaced by "weak key length" or "short > key". It might otherwise imply key quality tests which are not carried out. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > > ------------------------------------------------------------------------ > *From:* security-dev on behalf > of Weijun Wang > *Sent:* Friday, March 24, 2017 2:12:01 AM > *To:* Security Dev OpenJDK > *Subject:* RFR: 3 security-libs release notes on keytool/krb5/etc > > Hi All > > Please take a review on 3 release notes. The content itself is pasted as > quotation below. > > https://bugs.openjdk.java.net/browse/JDK-8176087 > keytool now prints warnings when reading or generating cert/cert req > using weak algorithms > >> In all keytool functions, if the certificate/certificate request/CRL >> that is working on (whether it be the input, the output, or an >> existing object) is using a weak algorithm or key, a warning will be >> printed out. >> >> Precisely, an algorithm or a key is weak if it matches the value of >> the jdk.certpath.disabledAlgorithms security property defined in >> conf/security/java.security. > > https://bugs.openjdk.java.net/browse/JDK-8174143 > Deprecate security APIs that have been superseded > >> The classes and interfaces in the `java.security.acl` and >> `javax.security.cert` packages have been superseded by replacements >> for a long time and are deprecated in JDK 9. Two methods >> `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and >> `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also >> deprecated since they return the >> `javax.security.cert.X509Certificate` type. > > https://bugs.openjdk.java.net/browse/JDK-8168635 > rcache interop with krb5-1.15 > >> The hash algorithm used in the Kerberos 5 replay cache file (rcache) >> is updated from MD5 to SHA256 with this change. This is also the >> algorithm used by MIT krb5-1.15. This change is interoperable with >> earlier releases of MIT krb5, which means Kerberos 5 acceptors from >> JDK 9 and MIT krb5-1.14 can share the same rcache file. >> >> A new system property named jdk.krb5.rcache.useMD5 is introduced. If >> the system property is set to "true", JDK 9 will still use the MD5 >> hash algorithm in rcache. This is useful when both of the following >> conditions are true: 1) the system has a very coarse clock and has to >> depend on hash values in replay attack detection, and 2) >> interoperability with earlier versions of JDK or MIT krb5 for rcache >> files is required. The default value of this system property is >> "false". > > Thanks > Max > > > From sean.mullan at oracle.com Fri Mar 24 18:56:52 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 24 Mar 2017 14:56:52 -0400 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc In-Reply-To: <1ba9b353-4ba6-289e-e013-528a34aff992@oracle.com> References: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> <1ba9b353-4ba6-289e-e013-528a34aff992@oracle.com> Message-ID: <3a9bedcb-f516-485d-37ed-1eead4a0ee5d@oracle.com> On 3/24/17 7:01 AM, Weijun Wang wrote: > I'll use "short key". I prefer the term "weak" which implies it is a risk. We already use that term in jarsigner so I think we should keep it consistent. You also print the size of the key so that describes what is wrong with it. --Sean > > Thanks > Max > > On 03/24/2017 06:26 PM, Bernd Eckenfels wrote: >> I wonder if "weak key" should be replaced by "weak key length" or "short >> key". It might otherwise imply key quality tests which are not carried >> out. >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> >> >> >> ------------------------------------------------------------------------ >> *From:* security-dev on behalf >> of Weijun Wang >> *Sent:* Friday, March 24, 2017 2:12:01 AM >> *To:* Security Dev OpenJDK >> *Subject:* RFR: 3 security-libs release notes on keytool/krb5/etc >> >> Hi All >> >> Please take a review on 3 release notes. The content itself is pasted as >> quotation below. >> >> https://bugs.openjdk.java.net/browse/JDK-8176087 >> keytool now prints warnings when reading or generating cert/cert req >> using weak algorithms >> >>> In all keytool functions, if the certificate/certificate request/CRL >>> that is working on (whether it be the input, the output, or an >>> existing object) is using a weak algorithm or key, a warning will be >>> printed out. >>> >>> Precisely, an algorithm or a key is weak if it matches the value of >>> the jdk.certpath.disabledAlgorithms security property defined in >>> conf/security/java.security. >> >> https://bugs.openjdk.java.net/browse/JDK-8174143 >> Deprecate security APIs that have been superseded >> >>> The classes and interfaces in the `java.security.acl` and >>> `javax.security.cert` packages have been superseded by replacements >>> for a long time and are deprecated in JDK 9. Two methods >>> `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and >>> `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also >>> deprecated since they return the >>> `javax.security.cert.X509Certificate` type. >> >> https://bugs.openjdk.java.net/browse/JDK-8168635 >> rcache interop with krb5-1.15 >> >>> The hash algorithm used in the Kerberos 5 replay cache file (rcache) >>> is updated from MD5 to SHA256 with this change. This is also the >>> algorithm used by MIT krb5-1.15. This change is interoperable with >>> earlier releases of MIT krb5, which means Kerberos 5 acceptors from >>> JDK 9 and MIT krb5-1.14 can share the same rcache file. >>> >>> A new system property named jdk.krb5.rcache.useMD5 is introduced. If >>> the system property is set to "true", JDK 9 will still use the MD5 >>> hash algorithm in rcache. This is useful when both of the following >>> conditions are true: 1) the system has a very coarse clock and has to >>> depend on hash values in replay attack detection, and 2) >>> interoperability with earlier versions of JDK or MIT krb5 for rcache >>> files is required. The default value of this system property is >>> "false". >> >> Thanks >> Max >> >> >> From anthony.scarpino at oracle.com Fri Mar 24 20:06:58 2017 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 24 Mar 2017 13:06:58 -0700 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc In-Reply-To: <3a9bedcb-f516-485d-37ed-1eead4a0ee5d@oracle.com> References: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> <1ba9b353-4ba6-289e-e013-528a34aff992@oracle.com> <3a9bedcb-f516-485d-37ed-1eead4a0ee5d@oracle.com> Message-ID: <6a5aa603-6fd8-c2b8-edc4-0cde0558f154@oracle.com> I'd agree with Sean, "weak" implies anything risk, the weakness isn't necessarily key length related. Tony On 03/24/2017 11:56 AM, Sean Mullan wrote: > On 3/24/17 7:01 AM, Weijun Wang wrote: >> I'll use "short key". > > I prefer the term "weak" which implies it is a risk. We already use that > term in jarsigner so I think we should keep it consistent. You also > print the size of the key so that describes what is wrong with it. > > --Sean > >> >> Thanks >> Max >> >> On 03/24/2017 06:26 PM, Bernd Eckenfels wrote: >>> I wonder if "weak key" should be replaced by "weak key length" or "short >>> key". It might otherwise imply key quality tests which are not carried >>> out. >>> >>> Gruss >>> Bernd >>> -- >>> http://bernd.eckenfels.net >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* security-dev on behalf >>> of Weijun Wang >>> *Sent:* Friday, March 24, 2017 2:12:01 AM >>> *To:* Security Dev OpenJDK >>> *Subject:* RFR: 3 security-libs release notes on keytool/krb5/etc >>> >>> Hi All >>> >>> Please take a review on 3 release notes. The content itself is pasted as >>> quotation below. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8176087 >>> keytool now prints warnings when reading or generating cert/cert req >>> using weak algorithms >>> >>>> In all keytool functions, if the certificate/certificate request/CRL >>>> that is working on (whether it be the input, the output, or an >>>> existing object) is using a weak algorithm or key, a warning will be >>>> printed out. >>>> >>>> Precisely, an algorithm or a key is weak if it matches the value of >>>> the jdk.certpath.disabledAlgorithms security property defined in >>>> conf/security/java.security. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8174143 >>> Deprecate security APIs that have been superseded >>> >>>> The classes and interfaces in the `java.security.acl` and >>>> `javax.security.cert` packages have been superseded by replacements >>>> for a long time and are deprecated in JDK 9. Two methods >>>> `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and >>>> `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also >>>> deprecated since they return the >>>> `javax.security.cert.X509Certificate` type. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8168635 >>> rcache interop with krb5-1.15 >>> >>>> The hash algorithm used in the Kerberos 5 replay cache file (rcache) >>>> is updated from MD5 to SHA256 with this change. This is also the >>>> algorithm used by MIT krb5-1.15. This change is interoperable with >>>> earlier releases of MIT krb5, which means Kerberos 5 acceptors from >>>> JDK 9 and MIT krb5-1.14 can share the same rcache file. >>>> >>>> A new system property named jdk.krb5.rcache.useMD5 is introduced. If >>>> the system property is set to "true", JDK 9 will still use the MD5 >>>> hash algorithm in rcache. This is useful when both of the following >>>> conditions are true: 1) the system has a very coarse clock and has to >>>> depend on hash values in replay attack detection, and 2) >>>> interoperability with earlier versions of JDK or MIT krb5 for rcache >>>> files is required. The default value of this system property is >>>> "false". >>> >>> Thanks >>> Max >>> >>> >>> From weijun.wang at oracle.com Sat Mar 25 00:46:03 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 25 Mar 2017 08:46:03 +0800 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc In-Reply-To: <6a5aa603-6fd8-c2b8-edc4-0cde0558f154@oracle.com> References: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> <1ba9b353-4ba6-289e-e013-528a34aff992@oracle.com> <3a9bedcb-f516-485d-37ed-1eead4a0ee5d@oracle.com> <6a5aa603-6fd8-c2b8-edc4-0cde0558f154@oracle.com> Message-ID: <00a7ab90-af72-c40c-fc42-9cf2e61d736e@oracle.com> After I said I would use short key I was also wondering how I should describe this in the keytool and jarsigner output. Now I think "weak" is more general and it covers the short length. I'll stick with it. Bernd, hopefully you find this OK. When one see "512-bit key (weak)", it means some quality test is already done. Thanks Max On 03/25/2017 04:06 AM, Anthony Scarpino wrote: > I'd agree with Sean, "weak" implies anything risk, the weakness isn't > necessarily key length related. > > Tony > > On 03/24/2017 11:56 AM, Sean Mullan wrote: >> On 3/24/17 7:01 AM, Weijun Wang wrote: >>> I'll use "short key". >> >> I prefer the term "weak" which implies it is a risk. We already use that >> term in jarsigner so I think we should keep it consistent. You also >> print the size of the key so that describes what is wrong with it. >> >> --Sean >> >>> >>> Thanks >>> Max >>> >>> On 03/24/2017 06:26 PM, Bernd Eckenfels wrote: >>>> I wonder if "weak key" should be replaced by "weak key length" or >>>> "short >>>> key". It might otherwise imply key quality tests which are not carried >>>> out. >>>> >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:* security-dev on behalf >>>> of Weijun Wang >>>> *Sent:* Friday, March 24, 2017 2:12:01 AM >>>> *To:* Security Dev OpenJDK >>>> *Subject:* RFR: 3 security-libs release notes on keytool/krb5/etc >>>> >>>> Hi All >>>> >>>> Please take a review on 3 release notes. The content itself is >>>> pasted as >>>> quotation below. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8176087 >>>> keytool now prints warnings when reading or generating cert/cert req >>>> using weak algorithms >>>> >>>>> In all keytool functions, if the certificate/certificate request/CRL >>>>> that is working on (whether it be the input, the output, or an >>>>> existing object) is using a weak algorithm or key, a warning will be >>>>> printed out. >>>>> >>>>> Precisely, an algorithm or a key is weak if it matches the value of >>>>> the jdk.certpath.disabledAlgorithms security property defined in >>>>> conf/security/java.security. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8174143 >>>> Deprecate security APIs that have been superseded >>>> >>>>> The classes and interfaces in the `java.security.acl` and >>>>> `javax.security.cert` packages have been superseded by replacements >>>>> for a long time and are deprecated in JDK 9. Two methods >>>>> `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and >>>>> `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also >>>>> deprecated since they return the >>>>> `javax.security.cert.X509Certificate` type. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8168635 >>>> rcache interop with krb5-1.15 >>>> >>>>> The hash algorithm used in the Kerberos 5 replay cache file (rcache) >>>>> is updated from MD5 to SHA256 with this change. This is also the >>>>> algorithm used by MIT krb5-1.15. This change is interoperable with >>>>> earlier releases of MIT krb5, which means Kerberos 5 acceptors from >>>>> JDK 9 and MIT krb5-1.14 can share the same rcache file. >>>>> >>>>> A new system property named jdk.krb5.rcache.useMD5 is introduced. If >>>>> the system property is set to "true", JDK 9 will still use the MD5 >>>>> hash algorithm in rcache. This is useful when both of the following >>>>> conditions are true: 1) the system has a very coarse clock and has to >>>>> depend on hash values in replay attack detection, and 2) >>>>> interoperability with earlier versions of JDK or MIT krb5 for rcache >>>>> files is required. The default value of this system property is >>>>> "false". >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> > From ecki at zusammenkunft.net Sat Mar 25 15:09:10 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 25 Mar 2017 15:09:10 +0000 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc In-Reply-To: <00a7ab90-af72-c40c-fc42-9cf2e61d736e@oracle.com> References: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> <1ba9b353-4ba6-289e-e013-528a34aff992@oracle.com> <3a9bedcb-f516-485d-37ed-1eead4a0ee5d@oracle.com> <6a5aa603-6fd8-c2b8-edc4-0cde0558f154@oracle.com>, <00a7ab90-af72-c40c-fc42-9cf2e61d736e@oracle.com> Message-ID: Sure, did not want to cause work. it is just a minor thing, I guess most people would read "weak" as "short" (even when weak key has another meaning in cryptography). It is good to have those warnings. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: security-dev on behalf of Weijun Wang Sent: Saturday, March 25, 2017 1:46:03 AM To: security-dev at openjdk.java.net Subject: Re: RFR: 3 security-libs release notes on keytool/krb5/etc After I said I would use short key I was also wondering how I should describe this in the keytool and jarsigner output. Now I think "weak" is more general and it covers the short length. I'll stick with it. Bernd, hopefully you find this OK. When one see "512-bit key (weak)", it means some quality test is already done. Thanks Max On 03/25/2017 04:06 AM, Anthony Scarpino wrote: > I'd agree with Sean, "weak" implies anything risk, the weakness isn't > necessarily key length related. > > Tony > > On 03/24/2017 11:56 AM, Sean Mullan wrote: >> On 3/24/17 7:01 AM, Weijun Wang wrote: >>> I'll use "short key". >> >> I prefer the term "weak" which implies it is a risk. We already use that >> term in jarsigner so I think we should keep it consistent. You also >> print the size of the key so that describes what is wrong with it. >> >> --Sean >> >>> >>> Thanks >>> Max >>> >>> On 03/24/2017 06:26 PM, Bernd Eckenfels wrote: >>>> I wonder if "weak key" should be replaced by "weak key length" or >>>> "short >>>> key". It might otherwise imply key quality tests which are not carried >>>> out. >>>> >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:* security-dev on behalf >>>> of Weijun Wang >>>> *Sent:* Friday, March 24, 2017 2:12:01 AM >>>> *To:* Security Dev OpenJDK >>>> *Subject:* RFR: 3 security-libs release notes on keytool/krb5/etc >>>> >>>> Hi All >>>> >>>> Please take a review on 3 release notes. The content itself is >>>> pasted as >>>> quotation below. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8176087 >>>> keytool now prints warnings when reading or generating cert/cert req >>>> using weak algorithms >>>> >>>>> In all keytool functions, if the certificate/certificate request/CRL >>>>> that is working on (whether it be the input, the output, or an >>>>> existing object) is using a weak algorithm or key, a warning will be >>>>> printed out. >>>>> >>>>> Precisely, an algorithm or a key is weak if it matches the value of >>>>> the jdk.certpath.disabledAlgorithms security property defined in >>>>> conf/security/java.security. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8174143 >>>> Deprecate security APIs that have been superseded >>>> >>>>> The classes and interfaces in the `java.security.acl` and >>>>> `javax.security.cert` packages have been superseded by replacements >>>>> for a long time and are deprecated in JDK 9. Two methods >>>>> `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and >>>>> `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also >>>>> deprecated since they return the >>>>> `javax.security.cert.X509Certificate` type. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8168635 >>>> rcache interop with krb5-1.15 >>>> >>>>> The hash algorithm used in the Kerberos 5 replay cache file (rcache) >>>>> is updated from MD5 to SHA256 with this change. This is also the >>>>> algorithm used by MIT krb5-1.15. This change is interoperable with >>>>> earlier releases of MIT krb5, which means Kerberos 5 acceptors from >>>>> JDK 9 and MIT krb5-1.14 can share the same rcache file. >>>>> >>>>> A new system property named jdk.krb5.rcache.useMD5 is introduced. If >>>>> the system property is set to "true", JDK 9 will still use the MD5 >>>>> hash algorithm in rcache. This is useful when both of the following >>>>> conditions are true: 1) the system has a very coarse clock and has to >>>>> depend on hash values in replay attack detection, and 2) >>>>> interoperability with earlier versions of JDK or MIT krb5 for rcache >>>>> files is required. The default value of this system property is >>>>> "false". >>>> >>>> Thanks >>>> Max >>>> >>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Mar 27 01:43:48 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 27 Mar 2017 09:43:48 +0800 Subject: [9] RFR 8177569: keytool should not warn if signature algorithm used in cacerts is weak Message-ID: <8fc27d22-42fc-3537-cabb-572c36021723@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8177569/webrev.00/ Since our implementation of CertPath validation does not check for the signature algorithm of a root CA, keytool should not warn about its weakness either. Thanks Max From amy.lu at oracle.com Mon Mar 27 03:06:12 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 27 Mar 2017 11:06:12 +0800 Subject: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group Message-ID: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> jdk/internal/loader jdk/internal/util com/sun/jarsigner jdk/internal/agent Somehow these are missed in TEST.group. Please review this patch to update TEST.group Tested on all platforms, TestVersionedStream.java fails on Windows, put it in ProblemList.txt for now. bug: https://bugs.openjdk.java.net/browse/JDK-8177638 webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 @@ -286,6 +286,7 @@ java/util/BitSet/BitSetStreamTest.java 8079538 generic-all +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all ############################################################################ --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 @@ -70,6 +70,7 @@ sun/reflect \ jdk/internal/reflect \ jdk/lambda \ + jdk/internal/loader \ jdk/internal/misc \ jdk/internal/ref \ jdk/internal/jimage \ @@ -87,6 +88,7 @@ jdk_util_other = \ java/util \ sun/util \ + jdk/internal/util \ -:jdk_collections \ -:jdk_concurrent \ -:jdk_stream @@ -189,6 +191,7 @@ lib/security jdk_security4 = \ + com/sun/jarsigner \ com/sun/security/jgss \ javax/security/auth/kerberos \ sun/security/krb5 \ @@ -207,7 +210,8 @@ jdk_management = \ java/lang/management \ com/sun/management \ - sun/management + sun/management \ + jdk/internal/agent jdk_instrument = \ java/lang/instrument -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Mar 27 03:25:32 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 27 Mar 2017 11:25:32 +0800 Subject: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group In-Reply-To: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> References: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> Message-ID: <17d526a5-2d55-ff25-c474-3bcaa359b0f3@oracle.com> The com/sun/jarsigner line should be added to jdk_security3. Roughly, the categories mean: 1: public APIs 2: JCE 3: implementation and private APIs 4: JGSS/krb5 Thanks Max On 03/27/2017 11:06 AM, Amy Lu wrote: > jdk/internal/loader > jdk/internal/util > com/sun/jarsigner > jdk/internal/agent > > Somehow these are missed in TEST.group. > > Please review this patch to update TEST.group > > Tested on all platforms, TestVersionedStream.java fails on Windows, put > it in ProblemList.txt for now. > > bug: https://bugs.openjdk.java.net/browse/JDK-8177638 > webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ > > Thanks, > Amy > > > --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 > +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 > @@ -286,6 +286,7 @@ > > java/util/BitSet/BitSetStreamTest.java 8079538 generic-all > > +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all > > ############################################################################ > > --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 > +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 > @@ -70,6 +70,7 @@ > sun/reflect \ > jdk/internal/reflect \ > jdk/lambda \ > + jdk/internal/loader \ > jdk/internal/misc \ > jdk/internal/ref \ > jdk/internal/jimage \ > @@ -87,6 +88,7 @@ > jdk_util_other = \ > java/util \ > sun/util \ > + jdk/internal/util \ > -:jdk_collections \ > -:jdk_concurrent \ > -:jdk_stream > @@ -189,6 +191,7 @@ > lib/security > > jdk_security4 = \ > + com/sun/jarsigner \ > com/sun/security/jgss \ > javax/security/auth/kerberos \ > sun/security/krb5 \ > @@ -207,7 +210,8 @@ > jdk_management = \ > java/lang/management \ > com/sun/management \ > - sun/management > + sun/management \ > + jdk/internal/agent > > jdk_instrument = \ > java/lang/instrument > > From amy.lu at oracle.com Mon Mar 27 05:12:27 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 27 Mar 2017 13:12:27 +0800 Subject: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group In-Reply-To: <17d526a5-2d55-ff25-c474-3bcaa359b0f3@oracle.com> References: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> <17d526a5-2d55-ff25-c474-3bcaa359b0f3@oracle.com> Message-ID: Sure. Moved to jdk_security3. webrev updated: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ Thanks, Amy On 3/27/17 11:25 AM, Weijun Wang wrote: > The com/sun/jarsigner line should be added to jdk_security3. > > Roughly, the categories mean: > > 1: public APIs > 2: JCE > 3: implementation and private APIs > 4: JGSS/krb5 > > Thanks > Max > > On 03/27/2017 11:06 AM, Amy Lu wrote: >> jdk/internal/loader >> jdk/internal/util >> com/sun/jarsigner >> jdk/internal/agent >> >> Somehow these are missed in TEST.group. >> >> Please review this patch to update TEST.group >> >> Tested on all platforms, TestVersionedStream.java fails on Windows, put >> it in ProblemList.txt for now. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8177638 >> webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ >> >> Thanks, >> Amy >> >> >> --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 >> +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 >> @@ -286,6 +286,7 @@ >> >> java/util/BitSet/BitSetStreamTest.java 8079538 generic-all >> >> +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all >> >> ############################################################################ >> >> >> --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 >> +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 >> @@ -70,6 +70,7 @@ >> sun/reflect \ >> jdk/internal/reflect \ >> jdk/lambda \ >> + jdk/internal/loader \ >> jdk/internal/misc \ >> jdk/internal/ref \ >> jdk/internal/jimage \ >> @@ -87,6 +88,7 @@ >> jdk_util_other = \ >> java/util \ >> sun/util \ >> + jdk/internal/util \ >> -:jdk_collections \ >> -:jdk_concurrent \ >> -:jdk_stream >> @@ -189,6 +191,7 @@ >> lib/security >> >> jdk_security4 = \ >> + com/sun/jarsigner \ >> com/sun/security/jgss \ >> javax/security/auth/kerberos \ >> sun/security/krb5 \ >> @@ -207,7 +210,8 @@ >> jdk_management = \ >> java/lang/management \ >> com/sun/management \ >> - sun/management >> + sun/management \ >> + jdk/internal/agent >> >> jdk_instrument = \ >> java/lang/instrument >> >> From thomas.stuefe at gmail.com Mon Mar 27 13:26:38 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 Mar 2017 15:26:38 +0200 Subject: JDK-8016345 (DNSName does not accept names with leading numbers) will-not-fix? Why? Message-ID: Hi all, just a question, I hope this is the correct mailing list. There is https://bugs.openjdk.java.net/browse/JDK-8016345, which is about DNSName not accepting host names with leading numbers, which is valid according to https://tools.ietf.org/html/rfc1123 (Section 2.1). This bug was marked as a duplicate of https://bugs.openjdk.java.net/browse/JDK-8007706, which I do not understand - what do these errors have in common? I try to understand why JDK-8016345 was marked as will-not-fix. Are there any reasons to not fix the parser in DNSName.java (because the fix itself looks trivial)? Thank you, and Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Mar 27 14:42:01 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 27 Mar 2017 10:42:01 -0400 Subject: JDK-8016345 (DNSName does not accept names with leading numbers) will-not-fix? Why? In-Reply-To: References: Message-ID: Good catch, I actually closed it as a duplicate but marked it as a duplicate of the wrong bug, it should have been https://bugs.openjdk.java.net/browse/JDK-8054380 I fixed it so 8054380 is now the duplicate. --Sean On 3/27/17 9:26 AM, Thomas St?fe wrote: > Hi all, > > just a question, I hope this is the correct mailing list. > > There is https://bugs.openjdk.java.net/browse/JDK-8016345, which is > about DNSName not accepting host names with leading numbers, which is > valid according to https://tools.ietf.org/html/rfc1123 (Section 2.1). > > This bug was marked as a duplicate > of https://bugs.openjdk.java.net/browse/JDK-8007706, which I do not > understand - what do these errors have in common? > > I try to understand why JDK-8016345 was marked as will-not-fix. Are > there any reasons to not fix the parser in DNSName.java (because the fix > itself looks trivial)? > > Thank you, and Kind Regards, Thomas From adam.petcher at oracle.com Mon Mar 27 14:46:41 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 27 Mar 2017 10:46:41 -0400 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc In-Reply-To: References: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> <1ba9b353-4ba6-289e-e013-528a34aff992@oracle.com> <3a9bedcb-f516-485d-37ed-1eead4a0ee5d@oracle.com> <6a5aa603-6fd8-c2b8-edc4-0cde0558f154@oracle.com> <00a7ab90-af72-c40c-fc42-9cf2e61d736e@oracle.com> Message-ID: <5c6afb3d-552d-06b3-730e-4f06ce668bf9@oracle.com> I like Bernd's first suggestion: instead of "weak key" use "weak key size" (or something similar). This seems like a relatively simple solution that will clarify what is actually being tested. On 3/25/2017 11:09 AM, Bernd Eckenfels wrote: > Sure, did not want to cause work. it is just a minor thing, I guess > most people would read "weak" as "short" (even when weak key has > another meaning in cryptography). It is good to have those warnings. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > ------------------------------------------------------------------------ > *From:* security-dev on behalf > of Weijun Wang > *Sent:* Saturday, March 25, 2017 1:46:03 AM > *To:* security-dev at openjdk.java.net > *Subject:* Re: RFR: 3 security-libs release notes on keytool/krb5/etc > After I said I would use short key I was also wondering how I should > describe this in the keytool and jarsigner output. Now I think "weak" is > more general and it covers the short length. I'll stick with it. > > Bernd, hopefully you find this OK. When one see "512-bit key (weak)", it > means some quality test is already done. > > Thanks > Max > > On 03/25/2017 04:06 AM, Anthony Scarpino wrote: > > I'd agree with Sean, "weak" implies anything risk, the weakness isn't > > necessarily key length related. > > > > Tony > > > > On 03/24/2017 11:56 AM, Sean Mullan wrote: > >> On 3/24/17 7:01 AM, Weijun Wang wrote: > >>> I'll use "short key". > >> > >> I prefer the term "weak" which implies it is a risk. We already use > that > >> term in jarsigner so I think we should keep it consistent. You also > >> print the size of the key so that describes what is wrong with it. > >> > >> --Sean > >> > >>> > >>> Thanks > >>> Max > >>> > >>> On 03/24/2017 06:26 PM, Bernd Eckenfels wrote: > >>>> I wonder if "weak key" should be replaced by "weak key length" or > >>>> "short > >>>> key". It might otherwise imply key quality tests which are not > carried > >>>> out. > >>>> > >>>> Gruss > >>>> Bernd > >>>> -- > >>>> http://bernd.eckenfels.net > >>>> > > >>>> > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------ > >>>> > >>>> *From:* security-dev on > behalf > >>>> of Weijun Wang > >>>> *Sent:* Friday, March 24, 2017 2:12:01 AM > >>>> *To:* Security Dev OpenJDK > >>>> *Subject:* RFR: 3 security-libs release notes on keytool/krb5/etc > >>>> > >>>> Hi All > >>>> > >>>> Please take a review on 3 release notes. The content itself is > >>>> pasted as > >>>> quotation below. > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8176087 > >>>> keytool now prints warnings when reading or generating cert/cert req > >>>> using weak algorithms > >>>> > >>>>> In all keytool functions, if the certificate/certificate request/CRL > >>>>> that is working on (whether it be the input, the output, or an > >>>>> existing object) is using a weak algorithm or key, a warning will be > >>>>> printed out. > >>>>> > >>>>> Precisely, an algorithm or a key is weak if it matches the value of > >>>>> the jdk.certpath.disabledAlgorithms security property defined in > >>>>> conf/security/java.security. > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8174143 > >>>> Deprecate security APIs that have been superseded > >>>> > >>>>> The classes and interfaces in the `java.security.acl` and > >>>>> `javax.security.cert` packages have been superseded by replacements > >>>>> for a long time and are deprecated in JDK 9. Two methods > >>>>> > `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and > >>>>> `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also > >>>>> deprecated since they return the > >>>>> `javax.security.cert.X509Certificate` type. > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8168635 > >>>> rcache interop with krb5-1.15 > >>>> > >>>>> The hash algorithm used in the Kerberos 5 replay cache file (rcache) > >>>>> is updated from MD5 to SHA256 with this change. This is also the > >>>>> algorithm used by MIT krb5-1.15. This change is interoperable with > >>>>> earlier releases of MIT krb5, which means Kerberos 5 acceptors from > >>>>> JDK 9 and MIT krb5-1.14 can share the same rcache file. > >>>>> > >>>>> A new system property named jdk.krb5.rcache.useMD5 is introduced. If > >>>>> the system property is set to "true", JDK 9 will still use the MD5 > >>>>> hash algorithm in rcache. This is useful when both of the following > >>>>> conditions are true: 1) the system has a very coarse clock and > has to > >>>>> depend on hash values in replay attack detection, and 2) > >>>>> interoperability with earlier versions of JDK or MIT krb5 for rcache > >>>>> files is required. The default value of this system property is > >>>>> "false". > >>>> > >>>> Thanks > >>>> Max > >>>> > >>>> > >>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Mar 27 14:56:58 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 Mar 2017 16:56:58 +0200 Subject: JDK-8016345 (DNSName does not accept names with leading numbers) will-not-fix? Why? In-Reply-To: References: Message-ID: Hi Sean, thank you! Is it planned to fix 8054380? I see it is still open, but the assignee (Jason Uh) is marked as inactive and the issue is dormant since creation. ..Thomas On Mon, Mar 27, 2017 at 4:42 PM, Sean Mullan wrote: > Good catch, I actually closed it as a duplicate but marked it as a > duplicate of the wrong bug, it should have been > https://bugs.openjdk.java.net/browse/JDK-8054380 > > I fixed it so 8054380 is now the duplicate. > > --Sean > > > On 3/27/17 9:26 AM, Thomas St?fe wrote: > >> Hi all, >> >> just a question, I hope this is the correct mailing list. >> >> There is https://bugs.openjdk.java.net/browse/JDK-8016345, which is >> about DNSName not accepting host names with leading numbers, which is >> valid according to https://tools.ietf.org/html/rfc1123 (Section 2.1). >> >> This bug was marked as a duplicate >> of https://bugs.openjdk.java.net/browse/JDK-8007706, which I do not >> understand - what do these errors have in common? >> >> I try to understand why JDK-8016345 was marked as will-not-fix. Are >> there any reasons to not fix the parser in DNSName.java (because the fix >> itself looks trivial)? >> >> Thank you, and Kind Regards, Thomas >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Mar 27 15:00:22 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 27 Mar 2017 23:00:22 +0800 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc In-Reply-To: <5c6afb3d-552d-06b3-730e-4f06ce668bf9@oracle.com> References: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> <1ba9b353-4ba6-289e-e013-528a34aff992@oracle.com> <3a9bedcb-f516-485d-37ed-1eead4a0ee5d@oracle.com> <6a5aa603-6fd8-c2b8-edc4-0cde0558f154@oracle.com> <00a7ab90-af72-c40c-fc42-9cf2e61d736e@oracle.com> <5c6afb3d-552d-06b3-730e-4f06ce668bf9@oracle.com> Message-ID: <98b45a71-ccff-3770-eb05-574f754de831@oracle.com> This sounds reasonable. After all, the keytool output looks like Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 512-bit RSA key (weak) so it does mean the size (instead of the bits) is weak. Thanks Max On 03/27/2017 10:46 PM, Adam Petcher wrote: > I like Bernd's first suggestion: instead of "weak key" use "weak key > size" (or something similar). This seems like a relatively simple > solution that will clarify what is actually being tested. > > > On 3/25/2017 11:09 AM, Bernd Eckenfels wrote: >> Sure, did not want to cause work. it is just a minor thing, I guess >> most people would read "weak" as "short" (even when weak key has >> another meaning in cryptography). It is good to have those warnings. >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> >> ------------------------------------------------------------------------ >> *From:* security-dev on behalf >> of Weijun Wang >> *Sent:* Saturday, March 25, 2017 1:46:03 AM >> *To:* security-dev at openjdk.java.net >> *Subject:* Re: RFR: 3 security-libs release notes on keytool/krb5/etc >> >> After I said I would use short key I was also wondering how I should >> describe this in the keytool and jarsigner output. Now I think "weak" is >> more general and it covers the short length. I'll stick with it. >> >> Bernd, hopefully you find this OK. When one see "512-bit key (weak)", it >> means some quality test is already done. >> >> Thanks >> Max >> >> On 03/25/2017 04:06 AM, Anthony Scarpino wrote: >> > I'd agree with Sean, "weak" implies anything risk, the weakness isn't >> > necessarily key length related. >> > >> > Tony >> > >> > On 03/24/2017 11:56 AM, Sean Mullan wrote: >> >> On 3/24/17 7:01 AM, Weijun Wang wrote: >> >>> I'll use "short key". >> >> >> >> I prefer the term "weak" which implies it is a risk. We already use >> that >> >> term in jarsigner so I think we should keep it consistent. You also >> >> print the size of the key so that describes what is wrong with it. >> >> >> >> --Sean >> >> >> >>> >> >>> Thanks >> >>> Max >> >>> >> >>> On 03/24/2017 06:26 PM, Bernd Eckenfels wrote: >> >>>> I wonder if "weak key" should be replaced by "weak key length" or >> >>>> "short >> >>>> key". It might otherwise imply key quality tests which are not >> carried >> >>>> out. >> >>>> >> >>>> Gruss >> >>>> Bernd >> >>>> -- >> >>>> http://bernd.eckenfels.net >> >>>> >> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> ------------------------------------------------------------------------ >> >>>> >> >>>> *From:* security-dev on >> behalf >> >>>> of Weijun Wang >> >>>> *Sent:* Friday, March 24, 2017 2:12:01 AM >> >>>> *To:* Security Dev OpenJDK >> >>>> *Subject:* RFR: 3 security-libs release notes on keytool/krb5/etc >> >>>> >> >>>> Hi All >> >>>> >> >>>> Please take a review on 3 release notes. The content itself is >> >>>> pasted as >> >>>> quotation below. >> >>>> >> >>>> https://bugs.openjdk.java.net/browse/JDK-8176087 >> >>>> keytool now prints warnings when reading or generating cert/cert req >> >>>> using weak algorithms >> >>>> >> >>>>> In all keytool functions, if the certificate/certificate request/CRL >> >>>>> that is working on (whether it be the input, the output, or an >> >>>>> existing object) is using a weak algorithm or key, a warning will be >> >>>>> printed out. >> >>>>> >> >>>>> Precisely, an algorithm or a key is weak if it matches the value of >> >>>>> the jdk.certpath.disabledAlgorithms security property defined in >> >>>>> conf/security/java.security. >> >>>> >> >>>> https://bugs.openjdk.java.net/browse/JDK-8174143 >> >>>> Deprecate security APIs that have been superseded >> >>>> >> >>>>> The classes and interfaces in the `java.security.acl` and >> >>>>> `javax.security.cert` packages have been superseded by replacements >> >>>>> for a long time and are deprecated in JDK 9. Two methods >> >>>>> >> `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and >> >>>>> `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also >> >>>>> deprecated since they return the >> >>>>> `javax.security.cert.X509Certificate` type. >> >>>> >> >>>> https://bugs.openjdk.java.net/browse/JDK-8168635 >> >>>> rcache interop with krb5-1.15 >> >>>> >> >>>>> The hash algorithm used in the Kerberos 5 replay cache file (rcache) >> >>>>> is updated from MD5 to SHA256 with this change. This is also the >> >>>>> algorithm used by MIT krb5-1.15. This change is interoperable with >> >>>>> earlier releases of MIT krb5, which means Kerberos 5 acceptors from >> >>>>> JDK 9 and MIT krb5-1.14 can share the same rcache file. >> >>>>> >> >>>>> A new system property named jdk.krb5.rcache.useMD5 is introduced. If >> >>>>> the system property is set to "true", JDK 9 will still use the MD5 >> >>>>> hash algorithm in rcache. This is useful when both of the following >> >>>>> conditions are true: 1) the system has a very coarse clock and >> has to >> >>>>> depend on hash values in replay attack detection, and 2) >> >>>>> interoperability with earlier versions of JDK or MIT krb5 for rcache >> >>>>> files is required. The default value of this system property is >> >>>>> "false". >> >>>> >> >>>> Thanks >> >>>> Max >> >>>> >> >>>> >> >>>> >> > > From sean.mullan at oracle.com Mon Mar 27 15:07:32 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 27 Mar 2017 11:07:32 -0400 Subject: JDK-8016345 (DNSName does not accept names with leading numbers) will-not-fix? Why? In-Reply-To: References: Message-ID: <6ce29d24-e6a3-cdf4-6056-6c59dd54aa6e@oracle.com> On 3/27/17 10:56 AM, Thomas St?fe wrote: > Hi Sean, > > thank you! > > Is it planned to fix 8054380? I see it is still open, but the assignee > (Jason Uh) is marked as inactive and the issue is dormant since creation. Not for JDK 9 since it is not critical. Note that this is only an issue when creating certificates with keytool and not when validating certificates. You could try using another tool to create certificates. --Sean > > ..Thomas > > On Mon, Mar 27, 2017 at 4:42 PM, Sean Mullan > wrote: > > Good catch, I actually closed it as a duplicate but marked it as a > duplicate of the wrong bug, it should have been > https://bugs.openjdk.java.net/browse/JDK-8054380 > > > I fixed it so 8054380 is now the duplicate. > > --Sean > > > On 3/27/17 9:26 AM, Thomas St?fe wrote: > > Hi all, > > just a question, I hope this is the correct mailing list. > > There is https://bugs.openjdk.java.net/browse/JDK-8016345 > , which is > about DNSName not accepting host names with leading numbers, > which is > valid according to https://tools.ietf.org/html/rfc1123 > > (Section 2.1). > > This bug was marked as a duplicate > of https://bugs.openjdk.java.net/browse/JDK-8007706 > , which I do not > understand - what do these errors have in common? > > I try to understand why JDK-8016345 was marked as will-not-fix. Are > there any reasons to not fix the parser in DNSName.java (because > the fix > itself looks trivial)? > > Thank you, and Kind Regards, Thomas > > From thomas.stuefe at gmail.com Mon Mar 27 15:41:17 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 Mar 2017 17:41:17 +0200 Subject: JDK-8016345 (DNSName does not accept names with leading numbers) will-not-fix? Why? In-Reply-To: <6ce29d24-e6a3-cdf4-6056-6c59dd54aa6e@oracle.com> References: <6ce29d24-e6a3-cdf4-6056-6c59dd54aa6e@oracle.com> Message-ID: Hi Sean, On Mon, Mar 27, 2017 at 5:07 PM, Sean Mullan wrote: > On 3/27/17 10:56 AM, Thomas St?fe wrote: > >> Hi Sean, >> >> thank you! >> >> Is it planned to fix 8054380? I see it is still open, but the assignee >> (Jason Uh) is marked as inactive and the issue is dormant since creation. >> > > Not for JDK 9 since it is not critical. Note that this is only an issue > when creating certificates with keytool and not when validating > certificates. You could try using another tool to create certificates. > > thanks for the info. So, basically, there is no particular reason I'm too blind to see not to fix the parser to accept hostnames with leading numbers, e.g., just lack of time/resources? I am asking because then we could fix it in our product downstream and maybe contribute the fix to upstream. Thanks, Thomas > --Sean > > >> ..Thomas >> >> On Mon, Mar 27, 2017 at 4:42 PM, Sean Mullan > > wrote: >> >> Good catch, I actually closed it as a duplicate but marked it as a >> duplicate of the wrong bug, it should have been >> https://bugs.openjdk.java.net/browse/JDK-8054380 >> >> >> I fixed it so 8054380 is now the duplicate. >> >> --Sean >> >> >> On 3/27/17 9:26 AM, Thomas St?fe wrote: >> >> Hi all, >> >> just a question, I hope this is the correct mailing list. >> >> There is https://bugs.openjdk.java.net/browse/JDK-8016345 >> , which is >> about DNSName not accepting host names with leading numbers, >> which is >> valid according to https://tools.ietf.org/html/rfc1123 >> > ietf.org_html_rfc1123&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8P >> QcxBKCX5YTpkKY057SbK10&r=wLZjDoZBdVMUe0-SnmtSgQUVl_gHmb_ >> 3aP58rurBKYA&m=DIIlALFx4DAHzx8FoLMhTQreVvtYOfMOHKfC_BltFn0& >> s=P6InJ7Ev_MpscdwaQI48sF2uMdTwbt124szmBQY03zE&e=> >> (Section 2.1). >> >> This bug was marked as a duplicate >> of https://bugs.openjdk.java.net/browse/JDK-8007706 >> , which I do >> not >> understand - what do these errors have in common? >> >> I try to understand why JDK-8016345 was marked as will-not-fix. >> Are >> there any reasons to not fix the parser in DNSName.java (because >> the fix >> itself looks trivial)? >> >> Thank you, and Kind Regards, Thomas >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Mar 27 18:01:04 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 27 Mar 2017 14:01:04 -0400 Subject: JDK-8016345 (DNSName does not accept names with leading numbers) will-not-fix? Why? In-Reply-To: References: <6ce29d24-e6a3-cdf4-6056-6c59dd54aa6e@oracle.com> Message-ID: <1c8c54f0-989f-ba51-048f-ca2a6b72d0d8@oracle.com> On 3/27/17 11:41 AM, Thomas St?fe wrote: > > thanks for the info. So, basically, there is no particular reason I'm > too blind to see not to fix the parser to accept hostnames with leading > numbers, e.g., just lack of time/resources? I am asking because then we > could fix it in our product downstream and maybe contribute the fix to > upstream. There is no particular reason that I am aware of. Please feel free to fix it on your side and contribute a patch. In case you are not familiar with contributing to OpenJDK, the process is described in more detail here: http://openjdk.java.net/contribute/ --Sean From joe.darcy at oracle.com Tue Mar 28 01:09:59 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 27 Mar 2017 18:09:59 -0700 Subject: RFR of 8177683: Suppress lint removal warnings in jdk.security and jdk.policytool Message-ID: Hello, The jdk.security and jdk.policytool modules use various APIs that are deprecated for removal. Until the types in question are actually removed, the lint removal warnings should be suppressed in support of having a warnings-free build. Please review the webrev: http://cr.openjdk.java.net/~darcy/8177683.0/ (This issue is a subtask of JDK-8177553: Address removal lint warnings in the JDK build. I'd prefer to get JDK-8177553 addressed in JDK 9; however, if that is not approved as part of rampdown 2, I'll push the associated changes to JDK 10.) Thanks, -Joe From richard at pointon.org.uk Tue Mar 28 16:59:20 2017 From: richard at pointon.org.uk (richard at pointon.org.uk) Date: Tue, 28 Mar 2017 17:59:20 +0100 Subject: [PATCH] 8005819: Support cross-realm MSSFU Message-ID: <93d070d7fbf3e52c6a42093bfedb1067@pointon.org.uk> Hi, I have developed a fix for the lack of cross-realm S4USelf support in OpenJDK 8 which I would like to contribute. The fix does not address realm referral as discussed in the bug and so requires both realms to be present in the krb5.conf file. Bug: https://bugs.openjdk.java.net/browse/JDK-8005819 Diff: --- ../jdk8u/jdk/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java 2016-08-22 15:58:34.720949000 +0100 +++ ../jdkpatch/jdk/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java 2016-09-16 15:11:02.967278000 +0100 @@ -54,19 +54,57 @@ Credentials ccreds) throws KrbException, IOException { String uRealm = client.getRealmString(); String localRealm = ccreds.getClient().getRealmString(); + KrbTgsReq req; if (!uRealm.equals(localRealm)) { - // TODO: we do not support kerberos referral now - throw new KrbException("Cross realm impersonation not supported"); + //get a cross realm TGT + String tname = PrincipalName.TGS_DEFAULT_SRV_NAME + PrincipalName.NAME_COMPONENT_SEPARATOR_STR + + uRealm + PrincipalName.NAME_REALM_SEPARATOR_STR + uRealm; + + Credentials foreignTGT = acquireServiceCreds(tname, ccreds); + + //get a referral TGT from the foreign realm for the user + String [] svcUPN = ccreds.getClient().getNameStrings().clone(); + svcUPN[svcUPN.length-1] += PrincipalName.NAME_REALM_SEPARATOR_STR + localRealm; + + PrincipalName svcPrinc = new PrincipalName(PrincipalName.KRB_NT_ENTERPRISE, svcUPN, new Realm(uRealm)); + + req = new KrbTgsReq( + foreignTGT, + svcPrinc, + new PAData(Krb5.PA_FOR_USER, + new PAForUserEnc(client, + foreignTGT.getSessionKey()).asn1Encode()), + client); + + if (!foreignTGT.isForwardable()) { + throw new KrbException("S4U2self needs a FORWARDABLE ticket"); + } + + Credentials referralTGT = req.sendAndGetCreds(); + + //create request to local realm for user in foreign realm using the referral TGT from the + //foreign realm + req = new KrbTgsReq( + referralTGT, + ccreds.getClient(), + new PAData(Krb5.PA_FOR_USER, + new PAForUserEnc(client, + referralTGT.getSessionKey()).asn1Encode())); } - if (!ccreds.isForwardable()) { - throw new KrbException("S4U2self needs a FORWARDABLE ticket"); + else { + //same realm + req = new KrbTgsReq( + ccreds, + ccreds.getClient(), + new PAData(Krb5.PA_FOR_USER, + new PAForUserEnc(client, + ccreds.getSessionKey()).asn1Encode())); + + if (!ccreds.isForwardable()) { + throw new KrbException("S4U2self needs a FORWARDABLE ticket"); + } } - KrbTgsReq req = new KrbTgsReq( - ccreds, - ccreds.getClient(), - new PAData(Krb5.PA_FOR_USER, - new PAForUserEnc(client, - ccreds.getSessionKey()).asn1Encode())); + Credentials creds = req.sendAndGetCreds(); if (!creds.getClient().equals(client)) { throw new KrbException("S4U2self request not honored by KDC"); --- ../jdk8u/jdk/src/share/classes/sun/security/krb5/KrbTgsReq.java 2016-08-22 15:58:34.718972000 +0100 +++ ../jdkpatch/jdk/src/share/classes/sun/security/krb5/KrbTgsReq.java 2016-09-16 15:11:02.979473000 +0100 @@ -45,6 +45,7 @@ private PrincipalName princName; private PrincipalName servName; + private PrincipalName targetName; private TGSReq tgsReqMessg; private KerberosTime ctime; private Ticket secondTicket = null; @@ -109,8 +110,31 @@ null, null, null, - extraPA); // the PA-FOR-USER + extraPA,// the PA-FOR-USER + null); } + + public KrbTgsReq(Credentials asCreds, + PrincipalName sname, + PAData extraPA, + PrincipalName tname) + throws KrbException, IOException { + this(KDCOptions.with(KDCOptions.FORWARDABLE, KDCOptions.CANONICALIZE), + asCreds, + asCreds.getClient(), + sname, + null, + null, + null, + null, + null, + null, + null, + null, + extraPA,// the PA-FOR-USER + tname); + } + // Called by Credentials, KrbCred KrbTgsReq( @@ -127,7 +151,7 @@ EncryptionKey subKey) throws KrbException, IOException { this(options, asCreds, asCreds.getClient(), sname, from, till, rtime, eTypes, addresses, - authorizationData, additionalTickets, subKey, null); + authorizationData, additionalTickets, subKey, null, null); } private KrbTgsReq( @@ -143,10 +167,12 @@ AuthorizationData authorizationData, Ticket[] additionalTickets, EncryptionKey subKey, - PAData extraPA) throws KrbException, IOException { + PAData extraPA, + PrincipalName tname) throws KrbException, IOException { princName = cname; servName = sname; + targetName = tname; ctime = KerberosTime.now(); // check if they are valid arguments. The optional fields @@ -240,8 +266,13 @@ */ public void send() throws IOException, KrbException { String realmStr = null; - if (servName != null) + if (targetName != null){ + realmStr = targetName.getRealmString(); + } + else if (servName != null) { realmStr = servName.getRealmString(); + } + KdcComm comm = new KdcComm(realmStr); ibuf = comm.send(obuf); } --- ../jdk8u/jdk/src/share/classes/sun/security/krb5/KrbKdcRep.java 2016-08-22 15:58:34.801487000 +0100 +++ ../jdkpatch/jdk/src/share/classes/sun/security/krb5/KrbKdcRep.java 2016-09-16 15:11:02.986718000 +0100 @@ -45,7 +45,8 @@ throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED); } - if (!req.reqBody.sname.equals(rep.encKDCRepPart.sname)) { + if (!req.reqBody.kdcOptions.get(KDCOptions.CANONICALIZE) && + !req.reqBody.sname.equals(rep.encKDCRepPart.sname)) { rep.encKDCRepPart.key.destroy(); throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED); } --- ../jdk8u/jdk/src/share/classes/sun/security/krb5/internal/KDCOptions.java 2016-08-22 15:58:34.758240000 +0100 +++ ../jdkpatch/jdk/src/share/classes/sun/security/krb5/internal/KDCOptions.java 2016-09-16 15:11:02.990754000 +0100 @@ -140,6 +140,7 @@ public static final int UNUSED10 = 10; public static final int UNUSED11 = 11; public static final int CNAME_IN_ADDL_TKT = 14; + public static final int CANONICALIZE = 15; public static final int RENEWABLE_OK = 27; public static final int ENC_TKT_IN_SKEY = 28; public static final int RENEW = 30; @@ -160,7 +161,8 @@ "UNUSED11", //11; null,null, "CNAME_IN_ADDL_TKT",//14; - null,null,null,null,null,null,null,null,null,null,null,null, + "CANONICALIZE", //15; + null,null,null,null,null,null,null,null,null,null,null, "RENEWABLE_OK", //27; "ENC_TKT_IN_SKEY", //28; null, --- ../jdk8u/jdk/src/share/classes/sun/security/krb5/PrincipalName.java 2016-08-22 15:58:34.708329000 +0100 +++ ../jdkpatch/jdk/src/share/classes/sun/security/krb5/PrincipalName.java 2016-09-16 15:11:02.995791000 +0100 @@ -89,6 +89,11 @@ * Unique ID */ public static final int KRB_NT_UID = 5; + + /** + * Enterprise name; may be mapped to principal name + */ + public static final int KRB_NT_ENTERPRISE = 10; /** * TGS Name From weijun.wang at oracle.com Tue Mar 28 23:25:00 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 29 Mar 2017 07:25:00 +0800 Subject: [PATCH] 8005819: Support cross-realm MSSFU In-Reply-To: <93d070d7fbf3e52c6a42093bfedb1067@pointon.org.uk> References: <93d070d7fbf3e52c6a42093bfedb1067@pointon.org.uk> Message-ID: Hi Richard I'll look into it. I used to think Kerberos referral is a must to support cross-realm MSSFU but I could be wrong. What platforms have you tested this on? MSAD? MIT krb5? Two reminders: 1. We don't have time for JDK 9 now. So this can only go into JDK 10. 2. Have you signed the Oracle Contribution Agreement at http://www.oracle.com/technetwork/community/oca-486395.html? Thanks Max On 03/29/2017 12:59 AM, richard at pointon.org.uk wrote: > Hi, > > I have developed a fix for the lack of cross-realm S4USelf support in > OpenJDK 8 which I would like to contribute. > > The fix does not address realm referral as discussed in the bug and so > requires both realms to be present in the krb5.conf file. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8005819 > > Diff: > > --- > ../jdk8u/jdk/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java > 2016-08-22 15:58:34.720949000 +0100 > +++ > ../jdkpatch/jdk/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java > 2016-09-16 15:11:02.967278000 +0100 > @@ -54,19 +54,57 @@ > Credentials ccreds) throws KrbException, IOException { > String uRealm = client.getRealmString(); > String localRealm = ccreds.getClient().getRealmString(); > + KrbTgsReq req; > if (!uRealm.equals(localRealm)) { > - // TODO: we do not support kerberos referral now > - throw new KrbException("Cross realm impersonation not > supported"); > + //get a cross realm TGT > + String tname = PrincipalName.TGS_DEFAULT_SRV_NAME + > PrincipalName.NAME_COMPONENT_SEPARATOR_STR + > + uRealm + PrincipalName.NAME_REALM_SEPARATOR_STR + > uRealm; > + > + Credentials foreignTGT = acquireServiceCreds(tname, ccreds); > + > + //get a referral TGT from the foreign realm for the user > + String [] svcUPN = > ccreds.getClient().getNameStrings().clone(); > + svcUPN[svcUPN.length-1] += > PrincipalName.NAME_REALM_SEPARATOR_STR + localRealm; > + > + PrincipalName svcPrinc = new > PrincipalName(PrincipalName.KRB_NT_ENTERPRISE, svcUPN, new Realm(uRealm)); > + > + req = new KrbTgsReq( > + foreignTGT, > + svcPrinc, > + new PAData(Krb5.PA_FOR_USER, > + new PAForUserEnc(client, > + foreignTGT.getSessionKey()).asn1Encode()), > + client); > + > + if (!foreignTGT.isForwardable()) { > + throw new KrbException("S4U2self needs a FORWARDABLE > ticket"); > + } > + > + Credentials referralTGT = req.sendAndGetCreds(); > + > + //create request to local realm for user in foreign realm > using the referral TGT from the > + //foreign realm > + req = new KrbTgsReq( > + referralTGT, > + ccreds.getClient(), > + new PAData(Krb5.PA_FOR_USER, > + new PAForUserEnc(client, > + > referralTGT.getSessionKey()).asn1Encode())); > } > - if (!ccreds.isForwardable()) { > - throw new KrbException("S4U2self needs a FORWARDABLE ticket"); > + else { > + //same realm > + req = new KrbTgsReq( > + ccreds, > + ccreds.getClient(), > + new PAData(Krb5.PA_FOR_USER, > + new PAForUserEnc(client, > + ccreds.getSessionKey()).asn1Encode())); > + > + if (!ccreds.isForwardable()) { > + throw new KrbException("S4U2self needs a FORWARDABLE > ticket"); > + } > } > - KrbTgsReq req = new KrbTgsReq( > - ccreds, > - ccreds.getClient(), > - new PAData(Krb5.PA_FOR_USER, > - new PAForUserEnc(client, > - ccreds.getSessionKey()).asn1Encode())); > + > Credentials creds = req.sendAndGetCreds(); > if (!creds.getClient().equals(client)) { > throw new KrbException("S4U2self request not honored by KDC"); > --- ../jdk8u/jdk/src/share/classes/sun/security/krb5/KrbTgsReq.java > 2016-08-22 15:58:34.718972000 +0100 > +++ > ../jdkpatch/jdk/src/share/classes/sun/security/krb5/KrbTgsReq.java > 2016-09-16 15:11:02.979473000 +0100 > @@ -45,6 +45,7 @@ > > private PrincipalName princName; > private PrincipalName servName; > + private PrincipalName targetName; > private TGSReq tgsReqMessg; > private KerberosTime ctime; > private Ticket secondTicket = null; > @@ -109,8 +110,31 @@ > null, > null, > null, > - extraPA); // the PA-FOR-USER > + extraPA,// the PA-FOR-USER > + null); > } > + > + public KrbTgsReq(Credentials asCreds, > + PrincipalName sname, > + PAData extraPA, > + PrincipalName tname) > + throws KrbException, IOException { > + this(KDCOptions.with(KDCOptions.FORWARDABLE, KDCOptions.CANONICALIZE), > + asCreds, > + asCreds.getClient(), > + sname, > + null, > + null, > + null, > + null, > + null, > + null, > + null, > + null, > + extraPA,// the PA-FOR-USER > + tname); > + } > + > > // Called by Credentials, KrbCred > KrbTgsReq( > @@ -127,7 +151,7 @@ > EncryptionKey subKey) throws KrbException, IOException { > this(options, asCreds, asCreds.getClient(), sname, > from, till, rtime, eTypes, addresses, > - authorizationData, additionalTickets, subKey, null); > + authorizationData, additionalTickets, subKey, null, null); > } > > private KrbTgsReq( > @@ -143,10 +167,12 @@ > AuthorizationData authorizationData, > Ticket[] additionalTickets, > EncryptionKey subKey, > - PAData extraPA) throws KrbException, IOException { > + PAData extraPA, > + PrincipalName tname) throws KrbException, IOException { > > princName = cname; > servName = sname; > + targetName = tname; > ctime = KerberosTime.now(); > > // check if they are valid arguments. The optional fields > @@ -240,8 +266,13 @@ > */ > public void send() throws IOException, KrbException { > String realmStr = null; > - if (servName != null) > + if (targetName != null){ > + realmStr = targetName.getRealmString(); > + } > + else if (servName != null) { > realmStr = servName.getRealmString(); > + } > + > KdcComm comm = new KdcComm(realmStr); > ibuf = comm.send(obuf); > } > --- ../jdk8u/jdk/src/share/classes/sun/security/krb5/KrbKdcRep.java > 2016-08-22 15:58:34.801487000 +0100 > +++ > ../jdkpatch/jdk/src/share/classes/sun/security/krb5/KrbKdcRep.java > 2016-09-16 15:11:02.986718000 +0100 > @@ -45,7 +45,8 @@ > throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED); > } > > - if (!req.reqBody.sname.equals(rep.encKDCRepPart.sname)) { > + if (!req.reqBody.kdcOptions.get(KDCOptions.CANONICALIZE) && > + !req.reqBody.sname.equals(rep.encKDCRepPart.sname)) { > rep.encKDCRepPart.key.destroy(); > throw new KrbApErrException(Krb5.KRB_AP_ERR_MODIFIED); > } > --- > ../jdk8u/jdk/src/share/classes/sun/security/krb5/internal/KDCOptions.java > 2016-08-22 15:58:34.758240000 +0100 > +++ > ../jdkpatch/jdk/src/share/classes/sun/security/krb5/internal/KDCOptions.java > 2016-09-16 15:11:02.990754000 +0100 > @@ -140,6 +140,7 @@ > public static final int UNUSED10 = 10; > public static final int UNUSED11 = 11; > public static final int CNAME_IN_ADDL_TKT = 14; > + public static final int CANONICALIZE = 15; > public static final int RENEWABLE_OK = 27; > public static final int ENC_TKT_IN_SKEY = 28; > public static final int RENEW = 30; > @@ -160,7 +161,8 @@ > "UNUSED11", //11; > null,null, > "CNAME_IN_ADDL_TKT",//14; > - null,null,null,null,null,null,null,null,null,null,null,null, > + "CANONICALIZE", //15; > + null,null,null,null,null,null,null,null,null,null,null, > "RENEWABLE_OK", //27; > "ENC_TKT_IN_SKEY", //28; > null, > --- > ../jdk8u/jdk/src/share/classes/sun/security/krb5/PrincipalName.java > 2016-08-22 15:58:34.708329000 +0100 > +++ > ../jdkpatch/jdk/src/share/classes/sun/security/krb5/PrincipalName.java 2016-09-16 > 15:11:02.995791000 +0100 > @@ -89,6 +89,11 @@ > * Unique ID > */ > public static final int KRB_NT_UID = 5; > + > + /** > + * Enterprise name; may be mapped to principal name > + */ > + public static final int KRB_NT_ENTERPRISE = 10; > > /** > * TGS Name From weijun.wang at oracle.com Tue Mar 28 23:30:52 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 29 Mar 2017 07:30:52 +0800 Subject: RFR of 8177683: Suppress lint removal warnings in jdk.security and jdk.policytool In-Reply-To: References: Message-ID: Hi Joe This looks fine to me. One question: - at SuppressWarnings("deprecation") + at SuppressWarnings({"deprecation", + "removal"}) // PolicyTool Why did you split the line to 2? Thanks Max On 03/28/2017 09:09 AM, joe darcy wrote: > Hello, > > The jdk.security and jdk.policytool modules use various APIs that are > deprecated for removal. Until the types in question are actually > removed, the lint removal warnings should be suppressed in support of > having a warnings-free build. Please review the webrev: > > http://cr.openjdk.java.net/~darcy/8177683.0/ > > (This issue is a subtask of JDK-8177553: Address removal lint warnings > in the JDK build. I'd prefer to get JDK-8177553 addressed in JDK 9; > however, if that is not approved as part of rampdown 2, I'll push the > associated changes to JDK 10.) > > Thanks, > > -Joe > > From joe.darcy at oracle.com Tue Mar 28 23:35:26 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 28 Mar 2017 16:35:26 -0700 Subject: RFR of 8177683: Suppress lint removal warnings in jdk.security and jdk.policytool In-Reply-To: References: Message-ID: <967f49d8-6505-cfd2-a745-bdb51bda9c3e@oracle.com> Hi Max, Since entire classes were being covered by the annotation, I wanted to make clear that the removal warnings in those cases were for PolicyTool as opposed to being for something else. Thanks, -Joe On 3/28/2017 4:30 PM, Weijun Wang wrote: > Hi Joe > > This looks fine to me. > > One question: > > - at SuppressWarnings("deprecation") > + at SuppressWarnings({"deprecation", > + "removal"}) // PolicyTool > > Why did you split the line to 2? > > Thanks > Max > > On 03/28/2017 09:09 AM, joe darcy wrote: >> Hello, >> >> The jdk.security and jdk.policytool modules use various APIs that are >> deprecated for removal. Until the types in question are actually >> removed, the lint removal warnings should be suppressed in support of >> having a warnings-free build. Please review the webrev: >> >> http://cr.openjdk.java.net/~darcy/8177683.0/ >> >> (This issue is a subtask of JDK-8177553: Address removal lint warnings >> in the JDK build. I'd prefer to get JDK-8177553 addressed in JDK 9; >> however, if that is not approved as part of rampdown 2, I'll push the >> associated changes to JDK 10.) >> >> Thanks, >> >> -Joe >> >> From weijun.wang at oracle.com Tue Mar 28 23:41:24 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 29 Mar 2017 07:41:24 +0800 Subject: RFR of 8177683: Suppress lint removal warnings in jdk.security and jdk.policytool In-Reply-To: <967f49d8-6505-cfd2-a745-bdb51bda9c3e@oracle.com> References: <967f49d8-6505-cfd2-a745-bdb51bda9c3e@oracle.com> Message-ID: But the "deprecation" argument is also for PolicyTool. -Max On 03/29/2017 07:35 AM, joe darcy wrote: > Hi Max, > > Since entire classes were being covered by the annotation, I wanted to > make clear that the removal warnings in those cases were for PolicyTool > as opposed to being for something else. > > Thanks, > > -Joe > > > On 3/28/2017 4:30 PM, Weijun Wang wrote: >> Hi Joe >> >> This looks fine to me. >> >> One question: >> >> - at SuppressWarnings("deprecation") >> + at SuppressWarnings({"deprecation", >> + "removal"}) // PolicyTool >> >> Why did you split the line to 2? >> >> Thanks >> Max >> >> On 03/28/2017 09:09 AM, joe darcy wrote: >>> Hello, >>> >>> The jdk.security and jdk.policytool modules use various APIs that are >>> deprecated for removal. Until the types in question are actually >>> removed, the lint removal warnings should be suppressed in support of >>> having a warnings-free build. Please review the webrev: >>> >>> http://cr.openjdk.java.net/~darcy/8177683.0/ >>> >>> (This issue is a subtask of JDK-8177553: Address removal lint warnings >>> in the JDK build. I'd prefer to get JDK-8177553 addressed in JDK 9; >>> however, if that is not approved as part of rampdown 2, I'll push the >>> associated changes to JDK 10.) >>> >>> Thanks, >>> >>> -Joe >>> >>> > From amy.lu at oracle.com Wed Mar 29 01:16:58 2017 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 29 Mar 2017 09:16:58 +0800 Subject: JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group In-Reply-To: References: <169a82d5-b1a4-0d05-40d6-a52fb344f564@oracle.com> <17d526a5-2d55-ff25-c474-3bcaa359b0f3@oracle.com> Message-ID: <92343987-fb71-0345-fb13-b98da6ad404e@oracle.com> Ping ~ On 3/27/17 1:12 PM, Amy Lu wrote: > Sure. Moved to jdk_security3. > > webrev updated: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ > > Thanks, > Amy > > On 3/27/17 11:25 AM, Weijun Wang wrote: >> The com/sun/jarsigner line should be added to jdk_security3. >> >> Roughly, the categories mean: >> >> 1: public APIs >> 2: JCE >> 3: implementation and private APIs >> 4: JGSS/krb5 >> >> Thanks >> Max >> >> On 03/27/2017 11:06 AM, Amy Lu wrote: >>> jdk/internal/loader >>> jdk/internal/util >>> com/sun/jarsigner >>> jdk/internal/agent >>> >>> Somehow these are missed in TEST.group. >>> >>> Please review this patch to update TEST.group >>> >>> Tested on all platforms, TestVersionedStream.java fails on Windows, put >>> it in ProblemList.txt for now. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8177638 >>> webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ >>> >>> Thanks, >>> Amy >>> >>> >>> --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 >>> +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 >>> @@ -286,6 +286,7 @@ >>> >>> java/util/BitSet/BitSetStreamTest.java 8079538 generic-all >>> >>> +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all >>> >>> ############################################################################ >>> >>> >>> --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 >>> +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 >>> @@ -70,6 +70,7 @@ >>> sun/reflect \ >>> jdk/internal/reflect \ >>> jdk/lambda \ >>> + jdk/internal/loader \ >>> jdk/internal/misc \ >>> jdk/internal/ref \ >>> jdk/internal/jimage \ >>> @@ -87,6 +88,7 @@ >>> jdk_util_other = \ >>> java/util \ >>> sun/util \ >>> + jdk/internal/util \ >>> -:jdk_collections \ >>> -:jdk_concurrent \ >>> -:jdk_stream >>> @@ -189,6 +191,7 @@ >>> lib/security >>> >>> jdk_security4 = \ >>> + com/sun/jarsigner \ >>> com/sun/security/jgss \ >>> javax/security/auth/kerberos \ >>> sun/security/krb5 \ >>> @@ -207,7 +210,8 @@ >>> jdk_management = \ >>> java/lang/management \ >>> com/sun/management \ >>> - sun/management >>> + sun/management \ >>> + jdk/internal/agent >>> >>> jdk_instrument = \ >>> java/lang/instrument >>> >>> > From weijun.wang at oracle.com Wed Mar 29 08:38:37 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 29 Mar 2017 16:38:37 +0800 Subject: [9] RFR 8177569: keytool should not warn if signature algorithm used in cacerts is weak In-Reply-To: <8fc27d22-42fc-3537-cabb-572c36021723@oracle.com> References: <8fc27d22-42fc-3537-cabb-572c36021723@oracle.com> Message-ID: Webrev updated at http://cr.openjdk.java.net/~weijun/8177569/webrev.01 Changes since last version: - Trusted cert entries in the current keystore are also trusted. See the new isTrusted() method. - A cert is treated as a root CA cert only if -trustcacerts is specified. - In the current keytool documentation, -trustcacerts is only designed for -importcert, and it should have no effect on other commands. Therefore the internal trustcacerts flag is reset when command is not IMPORTCERT. We might re-consider this in a future release (JDK-8177760). - Several checkWeak() calls are moved before keyStore change so the check is only based on original keystore content. This prevents a new cert treated trusted while it is being -import'ed. - Test modifications. Thanks Max On 03/27/2017 09:43 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8177569/webrev.00/ > > Since our implementation of CertPath validation does not check for the > signature algorithm of a root CA, keytool should not warn about its > weakness either. > > Thanks > Max From sean.mullan at oracle.com Wed Mar 29 14:33:54 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Mar 2017 10:33:54 -0400 Subject: RFR: 3 security-libs release notes on keytool/krb5/etc In-Reply-To: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> References: <5d8c3f85-35f8-2078-775a-d967697dd72b@oracle.com> Message-ID: The last two release notes look fine to me. I'll review the first one later. Thanks, Sean On 3/23/17 9:12 PM, Weijun Wang wrote: > Hi All > > Please take a review on 3 release notes. The content itself is pasted as > quotation below. > > https://bugs.openjdk.java.net/browse/JDK-8176087 > keytool now prints warnings when reading or generating cert/cert req > using weak algorithms > >> In all keytool functions, if the certificate/certificate request/CRL >> that is working on (whether it be the input, the output, or an >> existing object) is using a weak algorithm or key, a warning will be >> printed out. >> >> Precisely, an algorithm or a key is weak if it matches the value of >> the jdk.certpath.disabledAlgorithms security property defined in >> conf/security/java.security. > > https://bugs.openjdk.java.net/browse/JDK-8174143 > Deprecate security APIs that have been superseded > >> The classes and interfaces in the `java.security.acl` and >> `javax.security.cert` packages have been superseded by replacements >> for a long time and are deprecated in JDK 9. Two methods >> `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and >> `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also >> deprecated since they return the >> `javax.security.cert.X509Certificate` type. > > https://bugs.openjdk.java.net/browse/JDK-8168635 > rcache interop with krb5-1.15 > >> The hash algorithm used in the Kerberos 5 replay cache file (rcache) >> is updated from MD5 to SHA256 with this change. This is also the >> algorithm used by MIT krb5-1.15. This change is interoperable with >> earlier releases of MIT krb5, which means Kerberos 5 acceptors from >> JDK 9 and MIT krb5-1.14 can share the same rcache file. >> >> A new system property named jdk.krb5.rcache.useMD5 is introduced. If >> the system property is set to "true", JDK 9 will still use the MD5 >> hash algorithm in rcache. This is useful when both of the following >> conditions are true: 1) the system has a very coarse clock and has to >> depend on hash values in replay attack detection, and 2) >> interoperability with earlier versions of JDK or MIT krb5 for rcache >> files is required. The default value of this system property is >> "false". > > Thanks > Max > > > From xuelei.fan at oracle.com Wed Mar 29 16:13:24 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 Mar 2017 09:13:24 -0700 Subject: [9] RFR 8177569: keytool should not warn if signature algorithm used in cacerts is weak In-Reply-To: References: <8fc27d22-42fc-3537-cabb-572c36021723@oracle.com> Message-ID: I see the point that a trust anchor should be trusted. In application level, we don't actually check weakness of trust anchor because the user has made the decision to trust the cert. However, in keytool level, I think it might be nice to warning weakness in trust anchor too so that users can aware of weakness and make a good decision. Maybe, a user don't want to trust a cert again if he knows there are weakness. What do you think? Xuelei On 3/29/2017 1:38 AM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8177569/webrev.01 > > Changes since last version: > > - Trusted cert entries in the current keystore are also trusted. See the > new isTrusted() method. > > - A cert is treated as a root CA cert only if -trustcacerts is specified. > > - In the current keytool documentation, -trustcacerts is only designed > for -importcert, and it should have no effect on other commands. > Therefore the internal trustcacerts flag is reset when command is not > IMPORTCERT. We might re-consider this in a future release (JDK-8177760). > > - Several checkWeak() calls are moved before keyStore change so the > check is only based on original keystore content. This prevents a new > cert treated trusted while it is being -import'ed. > > - Test modifications. > > Thanks > Max > > On 03/27/2017 09:43 AM, Weijun Wang wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8177569/webrev.00/ >> >> Since our implementation of CertPath validation does not check for the >> signature algorithm of a root CA, keytool should not warn about its >> weakness either. >> >> Thanks >> Max From sean.mullan at oracle.com Wed Mar 29 20:36:33 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Mar 2017 16:36:33 -0400 Subject: [9] RFR 8177569: keytool should not warn if signature algorithm used in cacerts is weak In-Reply-To: References: <8fc27d22-42fc-3537-cabb-572c36021723@oracle.com> Message-ID: <6501d520-65bb-9f20-398f-3e15b4772120@oracle.com> On 3/29/17 12:13 PM, Xuelei Fan wrote: > I see the point that a trust anchor should be trusted. In application > level, we don't actually check weakness of trust anchor because the user > has made the decision to trust the cert. However, in keytool level, I > think it might be nice to warning weakness in trust anchor too so that > users can aware of weakness and make a good decision. Maybe, a user > don't want to trust a cert again if he knows there are weakness. > > What do you think? I don't think we should be checking if the signature algorithm of trust anchors or root certificates is weak. The fingerprint of these root certs are manually verified before they are imported into the cacerts file. Once installed, the key is directly trusted and the signature on the certificate is not checked when used as a trust anchor. SHA-1 and even MD5 roots may exist in the cacerts keystore and may still be needed to verify certificates still in use or to verify signed code that has been previously timestamped. These would only generate false warnings with keytool. --Sean > > Xuelei > > On 3/29/2017 1:38 AM, Weijun Wang wrote: >> Webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8177569/webrev.01 >> >> Changes since last version: >> >> - Trusted cert entries in the current keystore are also trusted. See the >> new isTrusted() method. >> >> - A cert is treated as a root CA cert only if -trustcacerts is specified. >> >> - In the current keytool documentation, -trustcacerts is only designed >> for -importcert, and it should have no effect on other commands. >> Therefore the internal trustcacerts flag is reset when command is not >> IMPORTCERT. We might re-consider this in a future release (JDK-8177760). >> >> - Several checkWeak() calls are moved before keyStore change so the >> check is only based on original keystore content. This prevents a new >> cert treated trusted while it is being -import'ed. >> >> - Test modifications. >> >> Thanks >> Max >> >> On 03/27/2017 09:43 AM, Weijun Wang wrote: >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8177569/webrev.00/ >>> >>> Since our implementation of CertPath validation does not check for the >>> signature algorithm of a root CA, keytool should not warn about its >>> weakness either. >>> >>> Thanks >>> Max From sean.mullan at oracle.com Wed Mar 29 20:39:04 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Mar 2017 16:39:04 -0400 Subject: [9] RFR 8177569: keytool should not warn if signature algorithm used in cacerts is weak In-Reply-To: References: <8fc27d22-42fc-3537-cabb-572c36021723@oracle.com> Message-ID: The updated fix looks good to me. --Sean On 3/29/17 4:38 AM, Weijun Wang wrote: > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8177569/webrev.01 > > Changes since last version: > > - Trusted cert entries in the current keystore are also trusted. See the > new isTrusted() method. > > - A cert is treated as a root CA cert only if -trustcacerts is specified. > > - In the current keytool documentation, -trustcacerts is only designed > for -importcert, and it should have no effect on other commands. > Therefore the internal trustcacerts flag is reset when command is not > IMPORTCERT. We might re-consider this in a future release (JDK-8177760). > > - Several checkWeak() calls are moved before keyStore change so the > check is only based on original keystore content. This prevents a new > cert treated trusted while it is being -import'ed. > > - Test modifications. > > Thanks > Max > > On 03/27/2017 09:43 AM, Weijun Wang wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8177569/webrev.00/ >> >> Since our implementation of CertPath validation does not check for the >> signature algorithm of a root CA, keytool should not warn about its >> weakness either. >> >> Thanks >> Max From sha.jiang at oracle.com Thu Mar 30 14:41:59 2017 From: sha.jiang at oracle.com (John Jiang) Date: Thu, 30 Mar 2017 22:41:59 +0800 Subject: RFR[9] 8165367: Additional tests for JEP 288: Disable SHA-1 Certificates Message-ID: <5181269b-89b0-08c6-9e50-8a5181eb6fb7@oracle.com> Hi, This patch includes a set of new test cases for JEP 288. The cases just focus on the usage constraints TLSSever and TLSClient with TLS communication. Issue: https://bugs.openjdk.java.net/browse/JDK-8165367 Webrev: http://cr.openjdk.java.net/~jjiang/8165367/webrev.00 Best regards, John Jiang From sean.mullan at oracle.com Fri Mar 31 12:06:54 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 31 Mar 2017 08:06:54 -0400 Subject: [10] RFR: 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) Message-ID: <1beaa71f-26ca-cad5-8684-6ec063076764@oracle.com> Please review this fix for a StackOverflowError caused by the default implementation of verify(PublicKey, Provider). bug: https://bugs.openjdk.java.net/browse/JDK-8175029 webrev: http://cr.openjdk.java.net/~mullan/webrevs/8175029/webrev.00/ Thanks, Sean From weijun.wang at oracle.com Fri Mar 31 13:08:48 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 31 Mar 2017 21:08:48 +0800 Subject: [10] RFR: 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) In-Reply-To: <1beaa71f-26ca-cad5-8684-6ec063076764@oracle.com> References: <1beaa71f-26ca-cad5-8684-6ec063076764@oracle.com> Message-ID: <12dbda01-73c4-2268-b0b1-2fa7f5cf63a6@oracle.com> Can we just move the code you just added into the public API directly? Looks like it does not reference any internal classes. --Max On 03/31/2017 08:06 PM, Sean Mullan wrote: > Please review this fix for a StackOverflowError caused by the default > implementation of verify(PublicKey, Provider). > > bug: https://bugs.openjdk.java.net/browse/JDK-8175029 > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8175029/webrev.00/ > > Thanks, > Sean From sean.mullan at oracle.com Fri Mar 31 13:11:49 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 31 Mar 2017 09:11:49 -0400 Subject: [10] RFR: 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) In-Reply-To: <12dbda01-73c4-2268-b0b1-2fa7f5cf63a6@oracle.com> References: <1beaa71f-26ca-cad5-8684-6ec063076764@oracle.com> <12dbda01-73c4-2268-b0b1-2fa7f5cf63a6@oracle.com> Message-ID: On 3/31/17 9:08 AM, Weijun Wang wrote: > Can we just move the code you just added into the public API directly? > Looks like it does not reference any internal classes. Good point, that should work! I'll try that and send out an updated webrev later. --Sean > > --Max > > On 03/31/2017 08:06 PM, Sean Mullan wrote: >> Please review this fix for a StackOverflowError caused by the default >> implementation of verify(PublicKey, Provider). >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8175029 >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8175029/webrev.00/ >> >> Thanks, >> Sean From lussnig at suche.org Mon Mar 27 21:32:29 2017 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Mon, 27 Mar 2017 23:32:29 +0200 Subject: JDK-8016345 (DNSName does not accept names with leading numbers) will-not-fix? Why? In-Reply-To: References: Message-ID: Hi, both errors have in common that there are about an change of allowed hostnames. But as for the second bug there is an big mistake. The underscore is allowed for SRV and CNAME but not for A records. For SRV records it is wide used in LDAP records for MS Domain System (PDC). But the Subject Alias is about valid hostnames so only the Number as you mentioned should be allowed as first character. Gru? Thomas On 3/27/17 3:26 PM, Thomas St?fe wrote: > Hi all, > > just a question, I hope this is the correct mailing list. > > There is https://bugs.openjdk.java.net/browse/JDK-8016345, which is > about DNSName not accepting host names with leading numbers, which is > valid according to https://tools.ietf.org/html/rfc1123 (Section 2.1). > > This bug was marked as a duplicate of > https://bugs.openjdk.java.net/browse/JDK-8007706, which I do not > understand - what do these errors have in common? > > I try to understand why JDK-8016345 was marked as will-not-fix. Are > there any reasons to not fix the parser in DNSName.java (because the > fix itself looks trivial)? > > Thank you, and Kind Regards, Thomas From sean.mullan at oracle.com Fri Mar 31 15:34:44 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 31 Mar 2017 11:34:44 -0400 Subject: [10] RFR: 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) In-Reply-To: References: <1beaa71f-26ca-cad5-8684-6ec063076764@oracle.com> <12dbda01-73c4-2268-b0b1-2fa7f5cf63a6@oracle.com> Message-ID: New webrev uploaded to address your comments: http://cr.openjdk.java.net/~mullan/webrevs/8175029/webrev.01/ --Sean On 3/31/17 9:11 AM, Sean Mullan wrote: > On 3/31/17 9:08 AM, Weijun Wang wrote: >> Can we just move the code you just added into the public API directly? >> Looks like it does not reference any internal classes. > > Good point, that should work! I'll try that and send out an updated > webrev later. > > --Sean > >> >> --Max >> >> On 03/31/2017 08:06 PM, Sean Mullan wrote: >>> Please review this fix for a StackOverflowError caused by the default >>> implementation of verify(PublicKey, Provider). >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8175029 >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8175029/webrev.00/ >>> >>> Thanks, >>> Sean From vincent.x.ryan at oracle.com Fri Mar 31 15:35:59 2017 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 31 Mar 2017 16:35:59 +0100 Subject: [10] RFR: 8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) In-Reply-To: References: <1beaa71f-26ca-cad5-8684-6ec063076764@oracle.com> <12dbda01-73c4-2268-b0b1-2fa7f5cf63a6@oracle.com> Message-ID: This fix looks fine to me. Thanks. > On 31 Mar 2017, at 16:34, Sean Mullan wrote: > > New webrev uploaded to address your comments: http://cr.openjdk.java.net/~mullan/webrevs/8175029/webrev.01/ > > --Sean > > On 3/31/17 9:11 AM, Sean Mullan wrote: >> On 3/31/17 9:08 AM, Weijun Wang wrote: >>> Can we just move the code you just added into the public API directly? >>> Looks like it does not reference any internal classes. >> >> Good point, that should work! I'll try that and send out an updated >> webrev later. >> >> --Sean >> >>> >>> --Max >>> >>> On 03/31/2017 08:06 PM, Sean Mullan wrote: >>>> Please review this fix for a StackOverflowError caused by the default >>>> implementation of verify(PublicKey, Provider). >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8175029 >>>> >>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8175029/webrev.00/ >>>> >>>> Thanks, >>>> Sean